| 2022-05-05 00:03:09 +0200 | <energizer> | if i wanted to make a MyFrac type that can be constructed with either `fracOfFloat 1.5` or `fracOfPair 3 2` i can do that. but it seems in some way unnecessary that these need different names. Is it possible to use the same name `fracOf` for both and apply type inference to figure out which implementation to use? |
| 2022-05-05 00:04:05 +0200 | <dminuoso> | With a surrogate typeclass, yes. |
| 2022-05-05 00:04:11 +0200 | <dminuoso> | It's not going to be pretty |
| 2022-05-05 00:04:12 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2022-05-05 00:04:22 +0200 | <dminuoso> | This gets a bit into printf territory here |
| 2022-05-05 00:05:55 +0200 | fendor | (~fendor@77.119.174.56.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2022-05-05 00:09:41 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-05-05 00:12:06 +0200 | shapr | (~user@184.81.59.2) |
| 2022-05-05 00:13:34 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 240 seconds) |
| 2022-05-05 00:13:40 +0200 | moonsheep | (~user@185.154.9.192) |
| 2022-05-05 00:16:20 +0200 | acidjnk | (~acidjnk@p200300d0c7068b77514ff9727fbe3410.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-05-05 00:17:04 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-05-05 00:17:19 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) (Ping timeout: 256 seconds) |
| 2022-05-05 00:17:33 +0200 | sleym | (~sleym@user/sleym) (Quit: sleym) |
| 2022-05-05 00:18:31 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) |
| 2022-05-05 00:20:20 +0200 | lispy | (~lispy@82.212.115.91) (Quit: Client closed) |
| 2022-05-05 00:20:51 +0200 | CiaoSen | (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-05-05 00:24:41 +0200 | machinedgod | (~machinedg@24.105.81.50) |
| 2022-05-05 00:25:37 +0200 | Ram-Z_ | (~Ram-Z@li1814-254.members.linode.com) |
| 2022-05-05 00:26:55 +0200 | Ram-Z | (~Ram-Z@li1814-254.members.linode.com) (Ping timeout: 260 seconds) |
| 2022-05-05 00:27:06 +0200 | moonsheep | (~user@185.154.9.192) (ERC 5.4 (IRC client for GNU Emacs 28.1)) |
| 2022-05-05 00:27:52 +0200 | <jackdk> | I recommend not doing this thing |
| 2022-05-05 00:30:10 +0200 | zincy | (~zincy@host86-160-236-152.range86-160.btcentralplus.com) (Remote host closed the connection) |
| 2022-05-05 00:30:20 +0200 | xaotuk | (~sasha@2a06:5b00:15fe:9b00::2) (Ping timeout: 260 seconds) |
| 2022-05-05 00:32:17 +0200 | Flonk | (~Flonk@vps-zap441517-1.zap-srv.com) (Quit: Ping timeout (120 seconds)) |
| 2022-05-05 00:32:29 +0200 | tzh_ | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-05-05 00:32:37 +0200 | Flonk | (~Flonk@vps-zap441517-1.zap-srv.com) |
| 2022-05-05 00:32:38 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-05-05 00:32:40 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Ping timeout: 260 seconds) |
| 2022-05-05 00:32:48 +0200 | <geekosaur> | so do I |
| 2022-05-05 00:33:32 +0200 | <geekosaur> | it's fragile, it breaks type inference, it breaks partial application, the implementation is ugly as sin |
| 2022-05-05 00:39:53 +0200 | nut | (~haskellfi@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 256 seconds) |
| 2022-05-05 00:43:39 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Quit: ec) |
| 2022-05-05 00:45:58 +0200 | zeenk | (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) (Quit: Konversation terminated!) |
| 2022-05-05 00:46:15 +0200 | Ranhir | (~Ranhir@157.97.53.139) (Remote host closed the connection) |
| 2022-05-05 00:48:44 +0200 | Ranhir | (~Ranhir@157.97.53.139) |
| 2022-05-05 00:49:09 +0200 | hololeap_ | (~hololeap@user/hololeap) |
| 2022-05-05 00:49:09 +0200 | dzdcnfzd | (~dzdcnfzd@2600:387:5:803::8a) (Quit: Client closed) |
| 2022-05-05 00:49:36 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Quit: ZNC - https://znc.in) |
| 2022-05-05 00:50:03 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-05-05 00:50:31 +0200 | Ranhir | (~Ranhir@157.97.53.139) (Client Quit) |
| 2022-05-05 00:52:37 +0200 | hololeap | (~hololeap@user/hololeap) (Read error: Connection reset by peer) |
| 2022-05-05 00:53:41 +0200 | Ranhir | (~Ranhir@157.97.53.139) |
| 2022-05-05 00:55:22 +0200 | <abastro[m]> | Printf implementation meets my eye tho |
| 2022-05-05 00:55:39 +0200 | <abastro[m]> | It looks good |
| 2022-05-05 00:59:54 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-05 01:03:50 +0200 | Topsi | (~Topsi@dyndsl-095-033-017-123.ewe-ip-backbone.de) (Read error: Connection reset by peer) |
| 2022-05-05 01:04:45 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 260 seconds) |
| 2022-05-05 01:05:29 +0200 | werneta | (~werneta@137.79.215.173) (Ping timeout: 256 seconds) |
| 2022-05-05 01:05:55 +0200 | shapr | (~user@184.81.59.2) (Ping timeout: 260 seconds) |
| 2022-05-05 01:08:40 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-05-05 01:12:39 +0200 | <abastro[m]> | > printf "cpu-%03d" 35 |
| 2022-05-05 01:12:41 +0200 | <lambdabot> | error: |
| 2022-05-05 01:12:41 +0200 | <lambdabot> | • Ambiguous type variable ‘a0’ arising from a use of ‘show_M735548023158... |
| 2022-05-05 01:12:41 +0200 | <lambdabot> | prevents the constraint ‘(Show a0)’ from being solved. |
| 2022-05-05 01:14:01 +0200 | tommd | (~tommd@97-120-41-123.ptld.qwest.net) |
| 2022-05-05 01:14:02 +0200 | <geekosaur> | > printf "cpu-%03d" 35 :: String -- remember what I said about type inference |
| 2022-05-05 01:14:04 +0200 | <lambdabot> | "cpu-035" |
| 2022-05-05 01:14:47 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-05-05 01:18:33 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) (Ping timeout: 276 seconds) |
| 2022-05-05 01:18:35 +0200 | <dminuoso> | Honestly, that was quite ironic right there. |
| 2022-05-05 01:18:36 +0200 | <abastro[m]> | Strange, type defaulting should work |
| 2022-05-05 01:18:40 +0200 | <dminuoso> | "it looks good" |
| 2022-05-05 01:18:55 +0200 | <abastro[m]> | Ye it still looks good |
| 2022-05-05 01:19:08 +0200 | <abastro[m]> | Ambiguous type variable because type not defaultwd |
| 2022-05-05 01:19:11 +0200 | <dminuoso> | *bam* ambiguous type variable, and some really obscure show_M735548023158... |
| 2022-05-05 01:19:19 +0200 | <dminuoso> | Really good user experience. |
| 2022-05-05 01:19:32 +0200 | <abastro[m]> | > printf "cpu-%03d" 35 :: IO () |
| 2022-05-05 01:19:34 +0200 | <lambdabot> | <IO ()> |
| 2022-05-05 01:19:49 +0200 | <abastro[m]> | Oh so lambdabot really cannot execute? |
| 2022-05-05 01:19:57 +0200 | <geekosaur> | really can't |
| 2022-05-05 01:20:06 +0200 | <geekosaur> | yahb could but is still MIA |
| 2022-05-05 01:20:13 +0200 | <geekosaur> | % "hello" |
| 2022-05-05 01:20:30 +0200 | dcoutts__ | (~duncan@host81-156-211-196.range81-156.btcentralplus.com) (Ping timeout: 260 seconds) |
| 2022-05-05 01:21:04 +0200 | <geekosaur> | also String is not among the default defaults unless OverloadedStrings is enabled |
| 2022-05-05 01:21:30 +0200 | <geekosaur> | @let {-# LANGUAGE OverloadedStrings #-} |
| 2022-05-05 01:21:31 +0200 | <lambdabot> | Defined. |
| 2022-05-05 01:21:45 +0200 | <geekosaur> | > printf "cpu-%03d" 35 |
| 2022-05-05 01:21:47 +0200 | <lambdabot> | error: |
| 2022-05-05 01:21:47 +0200 | <lambdabot> | • Ambiguous type variable ‘a0’ arising from a use of ‘show_M908856889501... |
| 2022-05-05 01:21:47 +0200 | <lambdabot> | prevents the constraint ‘(Show a0)’ from being solved. |
| 2022-05-05 01:22:31 +0200 | <geekosaur> | and still doesn't work anyway because it can't default through PrintfType, iirc |
| 2022-05-05 01:22:46 +0200 | <geekosaur> | @let {-# LANGUAGE ExtendedDefaultRules #-} |
| 2022-05-05 01:22:47 +0200 | <lambdabot> | Defined. |
| 2022-05-05 01:22:50 +0200 | <geekosaur> | > printf "cpu-%03d" 35 |
| 2022-05-05 01:22:52 +0200 | <lambdabot> | error: |
| 2022-05-05 01:22:52 +0200 | <lambdabot> | • Ambiguous type variable ‘a0’ arising from a use of ‘show_M292047623486... |
| 2022-05-05 01:22:52 +0200 | <lambdabot> | prevents the constraint ‘(Show a0)’ from being solved. |
| 2022-05-05 01:22:58 +0200 | <geekosaur> | right, no fixing this one |
| 2022-05-05 01:23:41 +0200 | <abastro[m]> | Now that rather convinces me that we need better string formatting tools |
| 2022-05-05 01:23:52 +0200 | <abastro[m]> | Perhaps built-in ones rather than defined in base |
| 2022-05-05 01:24:24 +0200 | <abastro[m]> | `"foo " ++ show foo ++ " is ..."` is extremely unergonomic |
| 2022-05-05 01:29:00 +0200 | <sm> | there are a bunch of packages adding interpolatable, multi line string literals. They mostly/all use TH/QQ though, limiting their usefulness (slowing compilation, reducing portability..). I sure would love to have python/js-like ergonomic interpolatable string literals just built in |
| 2022-05-05 01:29:08 +0200 | inversed_ | (~inversed@176.248.27.211) |
| 2022-05-05 01:29:34 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 240 seconds) |
| 2022-05-05 01:29:48 +0200 | <abastro[m]> | Indeed, those implemented by libs would inherently suffer from type inference anyway |
| 2022-05-05 01:29:59 +0200 | <abastro[m]> | But meh, haskell is not designed for practical industrial usage |
| 2022-05-05 01:30:20 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) |
| 2022-05-05 01:30:22 +0200 | inversed | (~inversed@176.248.27.211) (Ping timeout: 272 seconds) |
| 2022-05-05 01:30:25 +0200 | mmhat | (~mmh@2001:4090:a242:802a:ee08:6bff:fe09:5315) (Quit: WeeChat 3.5) |
| 2022-05-05 01:30:38 +0200 | <sm> | that would be a nice ghc improvement project for someone interested in improving haskell uptake |
| 2022-05-05 01:30:53 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-39.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-05-05 01:31:37 +0200 | <sm> | I think that statement is partly true, partly false |
| 2022-05-05 01:32:34 +0200 | <sm> | that was one of the explicit goals for the language, and that's why it is as practical as it is |
| 2022-05-05 01:32:54 +0200 | grimey | (~grimey@162.255.84.96) |
| 2022-05-05 01:33:07 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-05-05 01:33:47 +0200 | <sm> | haskell's unique strengths make it best-in-class for practical industrial usage in some ways |
| 2022-05-05 01:33:52 +0200 | <dminuoso> | 01:29:59 abastro[m] | But meh, haskell is not designed for practical industrial usage |
| 2022-05-05 01:34:05 +0200 | <dminuoso> | It's beyond me how this misconception keeps making its way into peoples head. |
| 2022-05-05 01:34:14 +0200 | <dminuoso> | What makes you think "it was not designed for practical industrial usage"? |
| 2022-05-05 01:34:41 +0200 | <abastro[m]> | Its primary purpose is not industrial success |
| 2022-05-05 01:35:24 +0200 | <geekosaur> | I'm unconvinced that wiring it into ghc can improve things greatly, unless it's e.g. done in a way that simply forbids the problematic uses |
| 2022-05-05 01:35:27 +0200 | <dminuoso> | You mean in the beginning? Or now? |
| 2022-05-05 01:35:35 +0200 | werneta | (~werneta@137.79.199.110) |
| 2022-05-05 01:35:41 +0200 | <abastro[m]> | Also nowadays everyone knows the "Avoid success at all costs" |
| 2022-05-05 01:35:47 +0200 | <geekosaur> | inparticular anything that does the kind of interpolation the TH/QQ based stuff does will use the TH/QQ machinery anyway |
| 2022-05-05 01:35:49 +0200 | <dminuoso> | That's a meme at best. |
| 2022-05-05 01:36:04 +0200 | <hpc> | it's times like these i wish lambdabot still had @faq |
| 2022-05-05 01:36:10 +0200 | <abastro[m]> | Associate in whichever way, it means the lang is not aimed at being successful |
| 2022-05-05 01:36:17 +0200 | <EvanR> | abastro[m], when the string building needs grow beyond simply showing stuff, the ++ form ends up being relatively not bad |
| 2022-05-05 01:36:39 +0200 | <hpc> | abastro[m]: it's meant as a joke, and means to not get stuck in a situation where improvement becomes impossible |
| 2022-05-05 01:36:46 +0200 | <geekosaur> | abastro[m] wants their meme and you can't take it away from them |
| 2022-05-05 01:36:47 +0200 | <abastro[m]> | Well, it indeed looks bad |
| 2022-05-05 01:36:53 +0200 | <hpc> | like how python almost died going from 2 to 3 |
| 2022-05-05 01:36:58 +0200 | <hpc> | and how perl /did/ die going from 5 to 6 |
| 2022-05-05 01:37:11 +0200 | <monochrom> | People manufacture excuses. |
| 2022-05-05 01:37:25 +0200 | <abastro[m]> | hpc: Well, didn't it make pointless changes like AMP possible? |
| 2022-05-05 01:37:33 +0200 | q0r | (~q0r@pool-108-26-33-153.syrcny.east.verizon.net) |
| 2022-05-05 01:37:34 +0200 | <monochrom> | No FAQ can prevail over FUD rationalizations. |
| 2022-05-05 01:37:37 +0200 | Kaiepi | (~kaiepi@156.34.47.253) (Read error: Connection reset by peer) |
| 2022-05-05 01:37:41 +0200 | <EvanR> | "foo %s bar" % whatever.str isn't much easier to type and is a bit gimmicky |
| 2022-05-05 01:38:01 +0200 | <monochrom> | Just look at flatearthers. Has any roundearth FAQ ever changed their minds? |
| 2022-05-05 01:38:28 +0200 | <EvanR> | >Haskell wasn't designed for industrial usage |
| 2022-05-05 01:38:36 +0200 | <EvanR> | Indeed "haskell was discovered, not invented" |
| 2022-05-05 01:38:44 +0200 | <EvanR> | "I think you can tell" |
| 2022-05-05 01:38:59 +0200 | <abastro[m]> | See, one of the biggest reason ppl say haskell is unpractical is how often it makes breaking changes which looks pointless |
| 2022-05-05 01:39:01 +0200 | <dminuoso> | Dont confuse "designed for" with "not suitable for" |
| 2022-05-05 01:39:09 +0200 | <dminuoso> | Haskell is perfectly suitable for industrial usage. |
| 2022-05-05 01:39:12 +0200 | <sm> | it's true that haskell appears not to care as much about developer ergonomics as say rust or ruby did. That's partly historical accident (slow growth, slow to find a killer app), partly that it's harder because haskell is doing more difficult things |
| 2022-05-05 01:39:13 +0200 | <abastro[m]> | It does refactor the code, but does it hold practical value? |
| 2022-05-05 01:39:29 +0200 | <geekosaur> | define practical value |
| 2022-05-05 01:39:29 +0200 | <abastro[m]> | Yea, I meant "not designed for" dminuoso |
| 2022-05-05 01:39:42 +0200 | <dminuoso> | So? |
| 2022-05-05 01:39:44 +0200 | <abastro[m]> | sm: Exactly |
| 2022-05-05 01:39:46 +0200 | <dolio> | This is complete nonsense. |
| 2022-05-05 01:39:47 +0200 | <hpc> | monochrom: not only is the earth flat, it's dymaxion-shaped |
| 2022-05-05 01:39:49 +0200 | <geekosaur> | you sound like the sort of person whose argumwnts will add up to "it's not javascript" in the end |
| 2022-05-05 01:39:55 +0200 | <dminuoso> | It doesnt matter what the design goals are, it just matters what its suitable for. |
| 2022-05-05 01:39:56 +0200 | <monochrom> | Here is what's really designed against industrial use: Spending time on repeatedly harping "not designed for industrial use". |
| 2022-05-05 01:39:59 +0200 | <hpc> | spacetime is just magnificently odd to make it appear spherical :D |
| 2022-05-05 01:40:05 +0200 | <dminuoso> | C was not designed for industrial usage either. |
| 2022-05-05 01:40:08 +0200 | <dminuoso> | It was very successful |
| 2022-05-05 01:40:13 +0200 | <monochrom> | Like, why waste time arguing. |
| 2022-05-05 01:40:26 +0200 | <abastro[m]> | Well, I meant how it is often against practical change |
| 2022-05-05 01:40:27 +0200 | <hpc> | you know what was actually designed for industrial usage? cobol |
| 2022-05-05 01:40:32 +0200 | <EvanR> | does industrial usage mean web tech |
| 2022-05-05 01:40:38 +0200 | q0r | (~q0r@pool-108-26-33-153.syrcny.east.verizon.net) (Quit: Connection closed) |
| 2022-05-05 01:40:41 +0200 | <EvanR> | or like, controlling factory robots |
| 2022-05-05 01:40:50 +0200 | <EvanR> | no, they should not be the same thing |
| 2022-05-05 01:41:03 +0200 | <monochrom> | You can invest time improving Haskell industrial use. Or you can invest time working with another language for industrial use. Either way is rational. |
| 2022-05-05 01:41:06 +0200 | <dminuoso> | Facebook runs their global spam fighting engine processing millions of events per second, doing hundreds of millions of checks per second - all on Haskell. |
| 2022-05-05 01:41:21 +0200 | <monochrom> | But keep whining about this topic? That I don't understand. |
| 2022-05-05 01:41:27 +0200 | <dminuoso> | I think that's one hell of an example how useful Haskell is as a tool. *shrugs* |
| 2022-05-05 01:41:28 +0200 | <sm> | perhaps a good time to link this excellent recent https://www.reddit.com/r/haskell/comments/uhdl5a/11_companies_that_use_haskell_in_production post |
| 2022-05-05 01:41:29 +0200 | <monochrom> | Do you have a life? |
| 2022-05-05 01:41:39 +0200 | <geekosaur> | "someone doesn't agree with me on the internet" |
| 2022-05-05 01:41:52 +0200 | <abastro[m]> | Well |
| 2022-05-05 01:42:28 +0200 | <abastro[m]> | This somewhat adds up to "elitism" they say |
| 2022-05-05 01:42:38 +0200 | <EvanR> | ??? |
| 2022-05-05 01:42:47 +0200 | <monochrom> | Why should we care? |
| 2022-05-05 01:42:50 +0200 | <EvanR> | that sounds out of the blue |
| 2022-05-05 01:42:59 +0200 | <EvanR> | here's evidence against your claim. |
| 2022-05-05 01:43:02 +0200 | <EvanR> | no, you're elitist |
| 2022-05-05 01:43:03 +0200 | <abastro[m]> | Yea, you might not care |
| 2022-05-05 01:43:32 +0200 | <monochrom> | I'm quite ready to ban. This is a waste of our time. |
| 2022-05-05 01:43:36 +0200 | <EvanR> | or is elitist like "that's unsustainable" in that it's a polymorphic refutation against anything |
| 2022-05-05 01:43:37 +0200 | <abastro[m]> | Just saying that how ppl get such impression on haskell |
| 2022-05-05 01:43:38 +0200 | <dolio> | +1 |
| 2022-05-05 01:44:21 +0200 | geekosaur | declines to repeat himself |
| 2022-05-05 01:44:31 +0200 | <EvanR> | evidence against elitist haskell: forall is a key word |
| 2022-05-05 01:44:34 +0200 | <geekosaur> | monochrom, agreed |
| 2022-05-05 01:44:42 +0200 | <monochrom> | And BTW to answer those who said I was too trigger-happy last time: I saw good regulars leaving this channel precisely because we fed the trolls instead of banning. |
| 2022-05-05 01:44:59 +0200 | <monochrom> | quchen was one of those who left, for example. |
| 2022-05-05 01:45:03 +0200 | <hpc> | EvanR: haskell isn't real - evidence: exists is not a keyword |
| 2022-05-05 01:45:07 +0200 | <hpc> | we've all been duped i tell you! |
| 2022-05-05 01:45:09 +0200 | <EvanR> | lol |
| 2022-05-05 01:45:14 +0200 | <dminuoso> | It's quite surprising how people without much knowledge of a language frequently seem to be the leading experts about why that language is good or bad. |
| 2022-05-05 01:46:28 +0200 | <EvanR> | if you have too much knowledge, you're elitist |
| 2022-05-05 01:46:29 +0200 | <hpc> | dminuoso: it's a zero-knowledge proof :P |
| 2022-05-05 01:47:51 +0200 | <dminuoso> | I mean there is some truth in that the Haskell community can be intimidating, because we attract a far higher frequency of academics/very involved researchers. |
| 2022-05-05 01:48:07 +0200 | <hpc> | oh, also on the topic of hasksell in industry, my coworkers wouldn't even know they've been running haskell code if i didn't tell them (shellcheck) |
| 2022-05-05 01:48:27 +0200 | <EvanR> | best not to, tell them |
| 2022-05-05 01:48:30 +0200 | <dminuoso> | shellcheck is written in Haskell? :o |
| 2022-05-05 01:48:34 +0200 | <EvanR> | they might react like abastro[m] |
| 2022-05-05 01:48:43 +0200 | <hpc> | https://github.com/koalaman/shellcheck |
| 2022-05-05 01:48:57 +0200 | <monochrom> | Approximately only xmonad users are painfully aware that here is a program written in Haskell. |
| 2022-05-05 01:49:15 +0200 | <monochrom> | Pandoc users don't notice, for example. |
| 2022-05-05 01:49:22 +0200 | <EvanR> | yeah it's weird, "the only reason I care about haskell is I'm forced to use it for xmonad" |
| 2022-05-05 01:49:24 +0200 | <monochrom> | ghcup users probably don't notice either, heh. |
| 2022-05-05 01:49:33 +0200 | <dminuoso> | `here`? |
| 2022-05-05 01:49:59 +0200 | <EvanR> | here: command not found |
| 2022-05-05 01:50:00 +0200 | <monochrom> | Oh, as in "here is a program written in Haskell: xmonad" |
| 2022-05-05 01:51:00 +0200 | <monochrom> | But the same can be said of Linux. How many people know that by now virtually all home routers run Linux? |
| 2022-05-05 01:51:12 +0200 | <dminuoso> | Not just home routers. |
| 2022-05-05 01:51:22 +0200 | <hpc> | also phones |
| 2022-05-05 01:51:23 +0200 | <dminuoso> | Expensive 7 digit backbone routing plattforms run linux too. |
| 2022-05-05 01:51:37 +0200 | <hpc> | all intel processors have an embedded copy of minix |
| 2022-05-05 01:52:04 +0200 | <hpc> | and your car, and your tv, and your watch |
| 2022-05-05 01:52:34 +0200 | <hpc> | your car might even have multiple instances of linux |
| 2022-05-05 01:52:35 +0200 | <EvanR> | all intel processors include a slow, bug ridden, informally specified, implementation of half of minix? |
| 2022-05-05 01:52:52 +0200 | <hpc> | EvanR: nope, they have the whole thing, it's part of their management engine stuff |
| 2022-05-05 01:52:55 +0200 | <dminuoso> | IME |
| 2022-05-05 01:53:06 +0200 | <dminuoso> | The absolutely disgusting dark side of modern processors. |
| 2022-05-05 01:53:17 +0200 | <EvanR> | modern CPU is spooky big |
| 2022-05-05 01:53:38 +0200 | <hpc> | although if you really want to use that quote, all intel instructions include a slow, bug ridden, informally specified implementation of half a turing machine |
| 2022-05-05 01:53:44 +0200 | <hpc> | or a full one as the case may be |
| 2022-05-05 01:54:21 +0200 | <EvanR> | can the instruction go into an infinite loop and be killed by a watchdog ? xD |
| 2022-05-05 01:54:40 +0200 | <hpc> | almost, it can go through interrupt operations indefinitely |
| 2022-05-05 01:55:11 +0200 | <hpc> | https://github.com/jbangert/trapcc |
| 2022-05-05 01:56:49 +0200 | <monochrom> | Yikes haha. |
| 2022-05-05 01:57:14 +0200 | <hpc> | https://www.youtube.com/playlist?list=PLowKtXNTBypGqImE405J2565dvjafglHU - the microcode stuff near the end of this playlist can give you a feel for how easy it is to happen |
| 2022-05-05 01:57:14 +0200 | <monochrom> | But I'm curious about the "cc" part. trap-with-current-continuation? :) |
| 2022-05-05 01:57:26 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 01:57:34 +0200 | <hpc> | (or how easy it would be if your cpu arch had intel's level of history attached to it) |
| 2022-05-05 01:57:40 +0200 | <hpc> | but also the whole playlist is really interesting |
| 2022-05-05 01:58:14 +0200 | <hpc> | accidental turing completeness is a hell of a thing |
| 2022-05-05 01:58:33 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-05-05 01:58:58 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::aa1d) (Ping timeout: 250 seconds) |
| 2022-05-05 01:59:00 +0200 | machinedgod | (~machinedg@24.105.81.50) (Ping timeout: 246 seconds) |
| 2022-05-05 02:01:20 +0200 | werneta | (~werneta@137.79.199.110) (Ping timeout: 260 seconds) |
| 2022-05-05 02:02:47 +0200 | alp_ | (~alp@user/alp) |
| 2022-05-05 02:04:24 +0200 | frost | (~frost@user/frost) |
| 2022-05-05 02:04:35 +0200 | Katarushisu | (~Katarushi@cpc147334-finc20-2-0-cust27.4-2.cable.virginm.net) (Quit: Ping timeout (120 seconds)) |
| 2022-05-05 02:04:54 +0200 | Katarushisu | (~Katarushi@cpc147334-finc20-2-0-cust27.4-2.cable.virginm.net) |
| 2022-05-05 02:08:36 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) (Ping timeout: 248 seconds) |
| 2022-05-05 02:12:00 +0200 | frost | (~frost@user/frost) (Quit: Client closed) |
| 2022-05-05 02:12:35 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-05-05 02:12:35 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-05-05 02:12:35 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-05-05 02:14:34 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.5) |
| 2022-05-05 02:14:46 +0200 | <EvanR> | in satisfactory there's an intermediate item called "AI limiter". Maybe we need "Turing completeness limiter" |
| 2022-05-05 02:15:22 +0200 | <monochrom> | We have timeouts. Is that good enough? :) |
| 2022-05-05 02:15:25 +0200 | <dminuoso> | Is that like a circuit board component I can solder on, EvanR? |
| 2022-05-05 02:15:39 +0200 | <EvanR> | yes |
| 2022-05-05 02:15:52 +0200 | <monochrom> | Right? If my computer is unresponsive for a minute, I unplug it. My limiter. |
| 2022-05-05 02:16:10 +0200 | xff0x | (~xff0x@om126167102105.29.openmobile.ne.jp) |
| 2022-05-05 02:16:11 +0200 | <monochrom> | Except for laptops. That's harder. |
| 2022-05-05 02:16:28 +0200 | <EvanR> | the level of automation there is also like satisfactory (low) |
| 2022-05-05 02:16:35 +0200 | <dminuoso> | We actually did have turbo button many eons ago. |
| 2022-05-05 02:16:47 +0200 | zyklotomic | (~ethan@res380d-128-61-86-82.res.gatech.edu) (Ping timeout: 256 seconds) |
| 2022-05-05 02:16:49 +0200 | <dminuoso> | A precursor to turing limiters. |
| 2022-05-05 02:16:53 +0200 | <monochrom> | Oh w00t turbo button. Yeah I had one. |
| 2022-05-05 02:17:06 +0200 | <EvanR> | people used it like a limiter |
| 2022-05-05 02:17:10 +0200 | <monochrom> | Err wait how is that limiting haha |
| 2022-05-05 02:17:19 +0200 | <EvanR> | by default you leave turbo on |
| 2022-05-05 02:17:33 +0200 | <dminuoso> | Yes, the turbo button was just a limiter with an inverted name. |
| 2022-05-05 02:17:33 +0200 | zyklotomic | (~ethan@res380d-128-61-84-187.res.gatech.edu) |
| 2022-05-05 02:17:36 +0200 | <EvanR> | then when necessary go "subturbo" |
| 2022-05-05 02:17:39 +0200 | <monochrom> | OK that's throttling if you turn it off. But it doesn't stop. |
| 2022-05-05 02:17:42 +0200 | <dminuoso> | Turbo sounds more positive than throttle. |
| 2022-05-05 02:18:05 +0200 | <monochrom> | The reset button is closer to a limiter. |
| 2022-05-05 02:18:12 +0200 | <EvanR> | they should bring back that marketing |
| 2022-05-05 02:18:16 +0200 | <dminuoso> | The power button is a turing limiter. |
| 2022-05-05 02:18:21 +0200 | <monochrom> | Yeah. |
| 2022-05-05 02:18:24 +0200 | <dminuoso> | Press it, and turing completeness is limited to 0. |
| 2022-05-05 02:18:33 +0200 | <EvanR> | your ISP will no longer throttle you, rather, they will take away your turbo |
| 2022-05-05 02:20:04 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-05-05 02:20:18 +0200 | <EvanR> | you guys are joking about limiting turing completeness by turning it off, unplugging it, or activate the self destruct ordinance. And a great idea goes out the window xD |
| 2022-05-05 02:21:52 +0200 | <dminuoso> | That was not a joke. |
| 2022-05-05 02:22:07 +0200 | <dminuoso> | But an odinance turing limiter sounds exciting. Tell me more. |
| 2022-05-05 02:22:09 +0200 | <dminuoso> | Do you have a video? |
| 2022-05-05 02:23:45 +0200 | <hpc> | ah yes, the principle of explosion |
| 2022-05-05 02:24:29 +0200 | <monochrom> | EvanR: What is the great idea? |
| 2022-05-05 02:24:55 +0200 | <monochrom> | Ordinance has detonational semantics >:) |
| 2022-05-05 02:25:35 +0200 | <monochrom> | https://mail.haskell.org/pipermail/haskell-cafe/2011-January/088315.html |
| 2022-05-05 02:27:48 +0200 | tommd | (~tommd@97-120-41-123.ptld.qwest.net) (Ping timeout: 248 seconds) |
| 2022-05-05 02:27:49 +0200 | <hpc> | musical semantics is genius |
| 2022-05-05 02:28:04 +0200 | <dminuoso> | @remember monochrom Ordinance has detonational semantics >:) |
| 2022-05-05 02:28:04 +0200 | <lambdabot> | I will remember. |
| 2022-05-05 02:29:46 +0200 | <seydar> | another day, another attempt to implement blurhash |
| 2022-05-05 02:33:06 +0200 | <seydar> | Axman6 described it as "super compressed JPG", so now i'm trying to understand the JuicyPixels implementation of JPG encoding |
| 2022-05-05 02:36:17 +0200 | shapr | (~user@184.81.59.2) |
| 2022-05-05 02:45:37 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) |
| 2022-05-05 02:53:38 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-05 02:58:51 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-05-05 02:59:05 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 260 seconds) |
| 2022-05-05 03:01:14 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) |
| 2022-05-05 03:02:07 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-05 03:02:28 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) (Ping timeout: 248 seconds) |
| 2022-05-05 03:06:11 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 03:06:24 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2022-05-05 03:06:27 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) (Ping timeout: 276 seconds) |
| 2022-05-05 03:09:54 +0200 | kaiepi | (~Kaiepi@156.34.47.253) |
| 2022-05-05 03:12:23 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2022-05-05 03:12:35 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2022-05-05 03:12:35 +0200 | allbery_b | (~geekosaur@xmonad/geekosaur) |
| 2022-05-05 03:12:38 +0200 | allbery_b | geekosaur |
| 2022-05-05 03:15:29 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) |
| 2022-05-05 03:20:36 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 248 seconds) |
| 2022-05-05 03:25:20 +0200 | gurkenglas | (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) (Ping timeout: 260 seconds) |
| 2022-05-05 03:29:11 +0200 | stackdroid18 | (14094@user/stackdroid) (Quit: hasta la vista... tchau!) |
| 2022-05-05 03:29:17 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 03:35:27 +0200 | <sm[i]> | > <monochrom> And BTW to answer those who said I was too trigger-happy last time: I saw good regulars leaving this channel precisely because we fed the trolls instead of banning. |
| 2022-05-05 03:35:28 +0200 | <lambdabot> | <hint>:1:1: error: parse error on input ‘<’ |
| 2022-05-05 03:36:02 +0200 | <sm[i]> | I am usually one of those. I get that it's a fine line and difficult to judge sometimes. |
| 2022-05-05 03:36:33 +0200 | <sm[i]> | for me, when a channel becomes too intolerant and cliquish, it's the sign of an calcifying community and time to move on |
| 2022-05-05 03:36:59 +0200 | <sm[i]> | avoid either extreme, and cool the temperature, is the goal for a channel op I think |
| 2022-05-05 03:37:39 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 276 seconds) |
| 2022-05-05 03:37:45 +0200 | shapr | (~user@184.81.59.2) (Remote host closed the connection) |
| 2022-05-05 03:38:03 +0200 | shapr | (~user@184.81.59.2) |
| 2022-05-05 03:38:24 +0200 | andrey_ | (~andrey@p200300dbcf1053000b1abd83a6152638.dip0.t-ipconnect.de) |
| 2022-05-05 03:38:50 +0200 | <sm[i]> | monochrom, sometimes I get the feeling you enjoy the ban hammer a little more than a good op should. Just my humble and respectful 2c |
| 2022-05-05 03:38:55 +0200 | <EvanR> | seydar, that was me, too at least |
| 2022-05-05 03:40:51 +0200 | andrey__ | (~andrey@p508d5cc9.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2022-05-05 03:41:58 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) |
| 2022-05-05 03:42:27 +0200 | shapr | (~user@184.81.59.2) (Ping timeout: 256 seconds) |
| 2022-05-05 03:42:56 +0200 | shapr | (~user@184.81.59.2) |
| 2022-05-05 03:43:00 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 248 seconds) |
| 2022-05-05 03:45:04 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-05-05 03:47:54 +0200 | <EvanR> | /mode +b nutter This hurts the community more than it hurts you |
| 2022-05-05 03:47:58 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 03:48:35 +0200 | kaiepi | (~Kaiepi@156.34.47.253) (Ping timeout: 256 seconds) |
| 2022-05-05 03:52:36 +0200 | alp_ | (~alp@user/alp) (Ping timeout: 252 seconds) |
| 2022-05-05 03:52:48 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 260 seconds) |
| 2022-05-05 03:53:15 +0200 | tommd | (~tommd@97-120-41-123.ptld.qwest.net) |
| 2022-05-05 03:57:45 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 248 seconds) |
| 2022-05-05 04:00:49 +0200 | Unicorn_Princess | (~Unicorn_P@93-103-228-248.dynamic.t-2.net) (Quit: Leaving) |
| 2022-05-05 04:09:43 +0200 | shapr | (~user@184.81.59.2) (Ping timeout: 260 seconds) |
| 2022-05-05 04:15:14 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-05-05 04:15:14 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-05-05 04:15:14 +0200 | finn_elija | FinnElija |
| 2022-05-05 04:19:42 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 04:19:50 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-05 04:19:54 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-05-05 04:19:54 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-05-05 04:19:54 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-05-05 04:26:52 +0200 | AlexNoo_ | (~AlexNoo@178.34.163.12) |
| 2022-05-05 04:27:43 +0200 | euandreh | (~euandreh@2804:14c:33:9fe5:2165:73d6:1630:f174) (Quit: WeeChat 3.5) |
| 2022-05-05 04:28:04 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 240 seconds) |
| 2022-05-05 04:28:58 +0200 | AlexZenon | (~alzenon@178.34.162.108) (Ping timeout: 272 seconds) |
| 2022-05-05 04:29:12 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-05-05 04:30:12 +0200 | AlexNoo | (~AlexNoo@178.34.162.108) (Ping timeout: 246 seconds) |
| 2022-05-05 04:30:52 +0200 | Alex_test | (~al_test@178.34.162.108) (Ping timeout: 272 seconds) |
| 2022-05-05 04:32:09 +0200 | AlexZenon | (~alzenon@178.34.163.12) |
| 2022-05-05 04:34:23 +0200 | Alex_test | (~al_test@178.34.163.12) |
| 2022-05-05 04:36:48 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 276 seconds) |
| 2022-05-05 04:41:39 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 04:45:21 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-05-05 04:52:35 +0200 | xff0x | (~xff0x@om126167102105.29.openmobile.ne.jp) (Read error: Connection reset by peer) |
| 2022-05-05 04:56:04 +0200 | td_ | (~td@muedsl-82-207-238-011.citykom.de) (Ping timeout: 248 seconds) |
| 2022-05-05 04:57:55 +0200 | td_ | (~td@muedsl-82-207-238-115.citykom.de) |
| 2022-05-05 04:58:40 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 260 seconds) |
| 2022-05-05 05:00:00 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::aa1d) |
| 2022-05-05 05:00:05 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-05-05 05:00:15 +0200 | tommd | (~tommd@97-120-41-123.ptld.qwest.net) (Ping timeout: 252 seconds) |
| 2022-05-05 05:02:34 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 240 seconds) |
| 2022-05-05 05:07:23 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-05-05 05:09:02 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 05:13:41 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-05-05 05:18:15 +0200 | euandreh | (~euandreh@2804:14c:33:9fe5:2165:73d6:1630:f174) |
| 2022-05-05 05:19:12 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 05:19:45 +0200 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-05-05 05:24:52 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 248 seconds) |
| 2022-05-05 05:29:25 +0200 | pavonia | (~user@user/siracusa) |
| 2022-05-05 05:29:33 +0200 | jao | (~jao@211.68.17.95.dynamic.jazztel.es) (Ping timeout: 256 seconds) |
| 2022-05-05 05:34:39 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-05-05 05:35:04 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-05 05:39:01 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-05-05 05:40:39 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 05:41:19 +0200 | img | (~img@user/img) |
| 2022-05-05 05:45:19 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 256 seconds) |
| 2022-05-05 05:48:09 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) |
| 2022-05-05 05:51:13 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 05:53:15 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-05-05 05:54:53 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-05 05:55:00 +0200 | lechner | (lechner@debian/lechner) (Quit: WeeChat 3.5) |
| 2022-05-05 05:55:15 +0200 | lechner | (lechner@debian/lechner) |
| 2022-05-05 05:56:06 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 276 seconds) |
| 2022-05-05 05:58:00 +0200 | lechner | (lechner@debian/lechner) (Client Quit) |
| 2022-05-05 05:58:14 +0200 | lechner | (lechner@debian/lechner) |
| 2022-05-05 05:59:07 +0200 | EvanR | (~EvanR@user/evanr) (Remote host closed the connection) |
| 2022-05-05 05:59:27 +0200 | EvanR | (~EvanR@user/evanr) |
| 2022-05-05 06:00:39 +0200 | benin | (~benin@183.82.29.230) |
| 2022-05-05 06:01:18 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 06:06:30 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Ping timeout: 276 seconds) |
| 2022-05-05 06:08:24 +0200 | notzmv | (~zmv@user/notzmv) |
| 2022-05-05 06:13:54 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-05-05 06:14:40 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-05-05 06:15:37 +0200 | coot | (~coot@213.134.190.95) |
| 2022-05-05 06:25:04 +0200 | bahamas | (~lucian@84.232.141.55) |
| 2022-05-05 06:32:43 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 06:35:08 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) (Client Quit) |
| 2022-05-05 06:40:26 +0200 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-05-05 06:43:48 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 248 seconds) |
| 2022-05-05 06:46:42 +0200 | zaquest | (~notzaques@5.130.79.72) |
| 2022-05-05 06:47:46 +0200 | mbuf | (~Shakthi@27.58.129.52) |
| 2022-05-05 06:50:54 +0200 | dunj3 | (~dunj3@kingdread.de) (Quit: ZNC 1.7.2+deb3 - https://znc.in) |
| 2022-05-05 07:01:09 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-05-05 07:03:09 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-05-05 07:04:32 +0200 | Vajb | (~Vajb@2001:999:400:9bc1:d5dd:7e53:33b:56) |
| 2022-05-05 07:07:19 +0200 | jargon | (~jargon@174-22-206-112.phnx.qwest.net) (Quit: Nini. ZZzz...) |
| 2022-05-05 07:09:08 +0200 | Me-me | (~me-me@tunnel690570-pt.tunnel.tserv12.mia1.ipv6.he.net) (Changing host) |
| 2022-05-05 07:09:08 +0200 | Me-me | (~me-me@user/me-me) |
| 2022-05-05 07:11:39 +0200 | cdman | (~dcm@user/dmc/x-4369397) |
| 2022-05-05 07:35:55 +0200 | forell | (~forell@user/forell) (Ping timeout: 256 seconds) |
| 2022-05-05 07:41:55 +0200 | bliminse | (~bliminse@host86-164-128-238.range86-164.btcentralplus.com) (Quit: leaving) |
| 2022-05-05 07:46:44 +0200 | x_kuru | (~xkuru@user/xkuru) (Read error: Connection reset by peer) |
| 2022-05-05 07:52:26 +0200 | gpncarl | (~gpncarl@120.244.220.74) |
| 2022-05-05 07:56:16 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) |
| 2022-05-05 07:56:50 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-05-05 07:58:52 +0200 | [Leary] | (~Leary]@122-58-228-205-vdsl.sparkbb.co.nz) (Remote host closed the connection) |
| 2022-05-05 07:59:16 +0200 | [Leary] | (~Leary]@122-58-228-205-vdsl.sparkbb.co.nz) |
| 2022-05-05 08:00:48 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) (Ping timeout: 250 seconds) |
| 2022-05-05 08:02:56 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-05-05 08:03:15 +0200 | michalz | (~michalz@185.246.204.105) |
| 2022-05-05 08:04:09 +0200 | gpncarl | (~gpncarl@120.244.220.74) (Ping timeout: 276 seconds) |
| 2022-05-05 08:06:05 +0200 | acidjnk | (~acidjnk@p200300d0c7068b437523c7c9ae2c8004.dip0.t-ipconnect.de) |
| 2022-05-05 08:08:30 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-05-05 08:12:46 +0200 | forell | (~forell@user/forell) |
| 2022-05-05 08:19:57 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-05-05 08:20:21 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-05-05 08:40:59 +0200 | Wstfgl0 | (~me-me@v.working.name) |
| 2022-05-05 08:43:06 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:e8a7:5207:d6e5:3f9a) |
| 2022-05-05 08:43:27 +0200 | Me-me | (~me-me@user/me-me) (Killed (NickServ (GHOST command used by Wstfgl0!~me-me@v.working.name))) |
| 2022-05-05 08:43:30 +0200 | Wstfgl0 | Me-me |
| 2022-05-05 08:43:37 +0200 | Me-me | (~me-me@v.working.name) (Changing host) |
| 2022-05-05 08:43:37 +0200 | Me-me | (~me-me@user/me-me) |
| 2022-05-05 08:46:27 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-05-05 08:47:37 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-05 08:49:41 +0200 | kenran | (~kenran@ip-037-024-119-190.um08.pools.vodafone-ip.de) |
| 2022-05-05 08:56:55 +0200 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-05-05 09:02:34 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-05 09:05:03 +0200 | alp_ | (~alp@user/alp) |
| 2022-05-05 09:05:41 +0200 | odnes | (~odnes@5-203-254-76.pat.nym.cosmote.net) |
| 2022-05-05 09:07:24 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Ping timeout: 246 seconds) |
| 2022-05-05 09:08:06 +0200 | bahamas | (~lucian@84.232.141.55) |
| 2022-05-05 09:16:44 +0200 | Gilbert189 | (~Gilbert18@user/Gilbert189) |
| 2022-05-05 09:22:24 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2022-05-05 09:22:57 +0200 | shriekingnoise | (~shrieking@201.231.16.156) (Quit: Quit) |
| 2022-05-05 09:25:42 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-05 09:32:32 +0200 | jonathanx | (~jonathan@dyn-5-sc.cdg.chalmers.se) |
| 2022-05-05 09:33:12 +0200 | kaph | (~kaph@net-2-42-128-205.cust.vodafonedsl.it) |
| 2022-05-05 09:34:23 +0200 | chele | (~chele@user/chele) |
| 2022-05-05 09:35:45 +0200 | fendor | (~fendor@91.141.58.225.wireless.dyn.drei.com) |
| 2022-05-05 09:39:34 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 240 seconds) |
| 2022-05-05 09:39:55 +0200 | nek0 | (~nek0@nek0.eu) (Quit: Ping timeout (120 seconds)) |
| 2022-05-05 09:40:13 +0200 | nek0 | (~nek0@nek0.eu) |
| 2022-05-05 09:47:09 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-05 09:47:19 +0200 | mmhat | (~mmh@2001:4090:a242:802a:ee08:6bff:fe09:5315) |
| 2022-05-05 09:47:41 +0200 | sus | (zero@user/zeromomentum) (Quit: the lounge - https://webirc.envs.net) |
| 2022-05-05 09:47:43 +0200 | machinedgod | (~machinedg@24.105.81.50) |
| 2022-05-05 09:48:17 +0200 | sus | (zero@user/zeromomentum) |
| 2022-05-05 09:50:34 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
| 2022-05-05 09:51:52 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-05-05 09:52:03 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 276 seconds) |
| 2022-05-05 09:53:07 +0200 | kaiepi | (~Kaiepi@156.34.47.253) |
| 2022-05-05 09:53:12 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-05-05 09:53:16 +0200 | Gilbert189 | (~Gilbert18@user/Gilbert189) (Quit: Leaving) |
| 2022-05-05 09:53:26 +0200 | dyeplexer | (~dyeplexer@user/dyeplexer) |
| 2022-05-05 09:54:25 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 260 seconds) |
| 2022-05-05 09:57:45 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) |
| 2022-05-05 09:58:32 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2022-05-05 10:02:12 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) (Ping timeout: 248 seconds) |
| 2022-05-05 10:03:17 +0200 | tzh_ | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2022-05-05 10:03:33 +0200 | <absence> | is it possible to enable GHC.Stats with a function call, or is passing the rts option -T the only way? |
| 2022-05-05 10:03:49 +0200 | bgs | (~bgs@cpe-212-85-160-171.cable.telemach.net) (Ping timeout: 256 seconds) |
| 2022-05-05 10:03:51 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 252 seconds) |
| 2022-05-05 10:04:04 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
| 2022-05-05 10:05:49 +0200 | bgs | (~bgs@cpe-212-85-160-171.cable.telemach.net) |
| 2022-05-05 10:06:43 +0200 | gpncarl | (~gpncarl@120.244.220.74) |
| 2022-05-05 10:07:55 +0200 | raym | (~raym@user/raym) (Ping timeout: 260 seconds) |
| 2022-05-05 10:09:35 +0200 | raym | (~raym@user/raym) |
| 2022-05-05 10:11:05 +0200 | gpncarl | (~gpncarl@120.244.220.74) (Ping timeout: 248 seconds) |
| 2022-05-05 10:12:51 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2022-05-05 10:12:52 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::aa1d) (Ping timeout: 248 seconds) |
| 2022-05-05 10:14:55 +0200 | __monty__ | (~toonn@user/toonn) |
| 2022-05-05 10:16:19 +0200 | ubert | (~Thunderbi@p200300ecdf1588a56901cfb4252abec6.dip0.t-ipconnect.de) |
| 2022-05-05 10:16:47 +0200 | acidjnk | (~acidjnk@p200300d0c7068b437523c7c9ae2c8004.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-05-05 10:16:53 +0200 | ccntrq | (~Thunderbi@2a01:e34:eccb:b060:8a52:6111:fb65:b9eb) |
| 2022-05-05 10:17:52 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2022-05-05 10:19:11 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2022-05-05 10:19:34 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2022-05-05 10:19:36 +0200 | kaiepi | (~Kaiepi@156.34.47.253) (Read error: Connection reset by peer) |
| 2022-05-05 10:22:42 +0200 | kaiepi | (~Kaiepi@156.34.47.253) |
| 2022-05-05 10:22:47 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-05 10:24:11 +0200 | ubert | (~Thunderbi@p200300ecdf1588a56901cfb4252abec6.dip0.t-ipconnect.de) (Quit: ubert) |
| 2022-05-05 10:26:26 +0200 | kaiepi | (~Kaiepi@156.34.47.253) (Client Quit) |
| 2022-05-05 10:26:48 +0200 | bahamas | (~lucian@92.85.13.88) |
| 2022-05-05 10:28:24 +0200 | kaiepi | (~Kaiepi@156.34.47.253) |
| 2022-05-05 10:28:36 +0200 | kenran | (~kenran@ip-037-024-119-190.um08.pools.vodafone-ip.de) (Quit: WeeChat info:version) |
| 2022-05-05 10:29:56 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-05-05 10:33:32 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) |
| 2022-05-05 10:34:25 +0200 | [Leary] | (~Leary]@122-58-228-205-vdsl.sparkbb.co.nz) (Remote host closed the connection) |
| 2022-05-05 10:34:25 +0200 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) |
| 2022-05-05 10:36:48 +0200 | <apache2> | speaking of intel instructions |
| 2022-05-05 10:37:40 +0200 | <apache2> | in the manuals for x86, x86_64, etc they have a description of what each assembly mnemonic does in a sort of pseudo-code language |
| 2022-05-05 10:37:47 +0200 | <apache2> | does that have a name, and has anybody implemented it? |
| 2022-05-05 10:40:07 +0200 | <apache2> | aand to get back on track: I managed to introduce some kind of bug in my code which resulted in an endless loop over an recursive list when trying to add a character to a Text string, the let binding stuff is pretty magical |
| 2022-05-05 10:40:35 +0200 | <apache2> | I found it by bisection, commenting out parts until something worked again |
| 2022-05-05 10:40:46 +0200 | [Leary] | (~Leary]@122-58-228-205-vdsl.sparkbb.co.nz) |
| 2022-05-05 10:40:52 +0200 | <apache2> | is there some sort of profiler / debugger / something to help diagnose problems like that? |
| 2022-05-05 10:49:09 +0200 | mjacob | (~mjacob@adrastea.uberspace.de) (Ping timeout: 256 seconds) |
| 2022-05-05 10:49:43 +0200 | tomku|two | (~tomku@user/tomku) (Ping timeout: 256 seconds) |
| 2022-05-05 10:49:51 +0200 | tomku | (~tomku@user/tomku) |
| 2022-05-05 10:49:56 +0200 | mjacob | (~mjacob@adrastea.uberspace.de) |
| 2022-05-05 10:52:11 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2022-05-05 10:52:32 +0200 | <merijn> | apache2: Depends how the endless loop happens :p |
| 2022-05-05 10:53:02 +0200 | <merijn> | apache2: ghci has a built in debugger, but it's not used super much |
| 2022-05-05 10:53:29 +0200 | <merijn> | Because |
| 2022-05-05 10:53:34 +0200 | <merijn> | @quote cmccann stream.of.con |
| 2022-05-05 10:53:35 +0200 | <lambdabot> | cmccann says: you want a debugger? GHC has one. Except that stepping through lazy evaluation is like listening to a stream of consciousness narrative told by a 5-year-old with ADHD. |
| 2022-05-05 10:54:00 +0200 | <merijn> | There's also profiling support, but I dunno how well that works to catch infinite loops |
| 2022-05-05 10:56:08 +0200 | teo | (~teo@user/teo) |
| 2022-05-05 10:57:27 +0200 | teo | (~teo@user/teo) (Client Quit) |
| 2022-05-05 10:58:18 +0200 | teo | (~teo@user/teo) |
| 2022-05-05 11:00:02 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-05-05 11:00:06 +0200 | corisco[m] | (~coriscokd@2001:470:69fc:105::1:dea6) (Quit: You have been kicked for being idle) |
| 2022-05-05 11:00:23 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-05-05 11:02:04 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 240 seconds) |
| 2022-05-05 11:02:32 +0200 | <kuribas> | the ghc debugger is also not how I want to debug. |
| 2022-05-05 11:02:37 +0200 | ccntrq | (~Thunderbi@2a01:e34:eccb:b060:8a52:6111:fb65:b9eb) (Remote host closed the connection) |
| 2022-05-05 11:02:40 +0200 | <kuribas> | I don't care about the order ghc uses to evaluate things. |
| 2022-05-05 11:03:01 +0200 | <kuribas> | So I would want to be able to specify what part of the eval tree to evaluate next. |
| 2022-05-05 11:03:10 +0200 | <kuribas> | "stepping" feels to imperative. |
| 2022-05-05 11:03:24 +0200 | ccntrq | (~Thunderbi@2a01:e34:eccb:b060:8a52:6111:fb65:b9eb) |
| 2022-05-05 11:04:27 +0200 | <kuribas> | As long as the debugger keeps the right semantics, so a bottom will not quit the whole evaluation. |
| 2022-05-05 11:04:27 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-05-05 11:04:33 +0200 | gpncarl | (~gpncarl@120.244.220.74) |
| 2022-05-05 11:05:12 +0200 | <kuribas> | for example snd (undefined, 4), I should be able to evaluate the first argument, without it stopping evaluating the whole thing. |
| 2022-05-05 11:05:17 +0200 | ubert | (~Thunderbi@2a02:8109:9880:303c:ad62:b99:9259:5795) |
| 2022-05-05 11:05:44 +0200 | <sm> | apache2: another way is to sprinkle the likely code with trace statements, inspecting output and code can get you pretty far |
| 2022-05-05 11:06:20 +0200 | <kuribas> | yeah, Debug.Trace is the best |
| 2022-05-05 11:06:52 +0200 | <kuribas> | when messing around on the repl didn't produce anything interesting. |
| 2022-05-05 11:07:52 +0200 | <sm> | then there's setting stack/heap size artificially low to force termination, would that help here ? |
| 2022-05-05 11:08:11 +0200 | <merijn> | Depends if it's actually leaking memory |
| 2022-05-05 11:08:24 +0200 | frost | (~frost@user/frost) |
| 2022-05-05 11:09:03 +0200 | <kuribas> | ah an endless loop, those are the worst to debug. |
| 2022-05-05 11:09:15 +0200 | <merijn> | hey! |
| 2022-05-05 11:09:20 +0200 | <merijn> | you don't know it's endless! :D |
| 2022-05-05 11:09:44 +0200 | <sm> | and is there a way to send it a signal/exception to force termination, with a traceback ? |
| 2022-05-05 11:10:11 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-05-05 11:10:25 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-05-05 11:10:27 +0200 | <merijn> | Depends how picky you are about the definition of each of the words in that sentence :p |
| 2022-05-05 11:10:35 +0200 | <sm> | heh |
| 2022-05-05 11:10:51 +0200 | <merijn> | sm: async exception are only detected during allocation/GC |
| 2022-05-05 11:10:53 +0200 | <sm> | figures it wouldn't be simple |
| 2022-05-05 11:11:07 +0200 | <merijn> | It's possible to get code stuck in an allocationless loop that will thus never detect async exceptions |
| 2022-05-05 11:11:23 +0200 | <sm> | good to know |
| 2022-05-05 11:11:44 +0200 | <merijn> | sm: It should be possible to implement support for stacktraces of an active thread, but that'll be some engineering work |
| 2022-05-05 11:11:50 +0200 | <sm> | ctrl c would probably work though ? |
| 2022-05-05 11:11:53 +0200 | <merijn> | sm: hah |
| 2022-05-05 11:11:57 +0200 | <merijn> | Absolutely not |
| 2022-05-05 11:12:12 +0200 | <merijn> | Arguably ctrl-c doesn't work at all in the current state of things :p |
| 2022-05-05 11:12:38 +0200 | <sm> | uh.. ctl z ? sometimes only that that works |
| 2022-05-05 11:12:40 +0200 | <merijn> | There's something that approximately resembless "working" that has essentially no sensible semantics |
| 2022-05-05 11:13:04 +0200 | <merijn> | sm: So ctrl-z from terminal does work, because that's handled in the kernel |
| 2022-05-05 11:13:16 +0200 | <merijn> | And has actual sensible semantics |
| 2022-05-05 11:14:02 +0200 | <merijn> | sm: The problem is that ctrl-c sends SIGINT and signals are delivered (non-deterministically!) to "a" thread in the process. So you have no clue which runtime thread gets the signal |
| 2022-05-05 11:15:04 +0200 | <sm> | could you instrument haskell code with a handler for ctrl z ? |
| 2022-05-05 11:15:40 +0200 | <merijn> | sm: No, because ctrl-z causes the kernel scheduler to stop scheduling your process, so there's no handler to run |
| 2022-05-05 11:15:50 +0200 | <merijn> | Because the process itself gets suspended and doesn't execute anything |
| 2022-05-05 11:16:20 +0200 | <sm> | thanks, makes sense |
| 2022-05-05 11:16:29 +0200 | sm | grasps at straws.. could you enable some RTS logging/real-time profiling to show some of the functions executing ? |
| 2022-05-05 11:16:35 +0200 | <merijn> | sm: There's a bunch of issues on the GHC tracker on fixing the signal handling to be, you know, sensible and predictable. But since, as of yet, no one is paying me to hack on GHC it's "on my to do list" |
| 2022-05-05 11:16:54 +0200 | <merijn> | Which is code for saying "I will never do it, because I don't have the energy/attention span for that" :p |
| 2022-05-05 11:16:59 +0200 | dut | (~dut@user/dut) |
| 2022-05-05 11:17:08 +0200 | <sm> | 👍🏻 |
| 2022-05-05 11:18:23 +0200 | acidjnk | (~acidjnk@p200300d0c7068b437523c7c9ae2c8004.dip0.t-ipconnect.de) |
| 2022-05-05 11:18:45 +0200 | <merijn> | I outlined (I think I did, anyway?) what a "proper" approach would look like |
| 2022-05-05 11:20:13 +0200 | <sm> | merijn: I'm not seeing that, just mention of the debugger and profiling ? |
| 2022-05-05 11:20:28 +0200 | <merijn> | Man, gitlab doesn't have a way to list all issues I commented on? |
| 2022-05-05 11:21:09 +0200 | <sm> | oh I assumed you were talking about this infinite loop debugging puzzle |
| 2022-05-05 11:21:28 +0200 | <merijn> | sm: Well, I was more referring to "proper" signal handling. But that would also open the way for more complex operations like "getting stack trace dumped out from all threads" |
| 2022-05-05 11:21:48 +0200 | <merijn> | Which sounds doable enough *iff* you have a sensible async infrastructure |
| 2022-05-05 11:22:01 +0200 | pretty_d1 | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-05-05 11:22:02 +0200 | <sm> | that sure sounds useful and good for "haskell in production" |
| 2022-05-05 11:22:07 +0200 | pretty_d1 | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Client Quit) |
| 2022-05-05 11:22:35 +0200 | <merijn> | argh |
| 2022-05-05 11:22:41 +0200 | <merijn> | I hate gitlab |
| 2022-05-05 11:22:55 +0200 | <sm> | hope younger sponsored businesses HF or one of the big haskell using corps |
| 2022-05-05 11:23:12 +0200 | <sm> | I hope you get ... |
| 2022-05-05 11:23:30 +0200 | <sm> | dang it iphone |
| 2022-05-05 11:23:34 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-05 11:23:35 +0200 | <merijn> | How can you not allow me to search for issues I commented on...I have no idea what this issue was named, just that I wrote some stuff |
| 2022-05-05 11:23:38 +0200 | merijn | sighs |
| 2022-05-05 11:23:42 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Ping timeout: 276 seconds) |
| 2022-05-05 11:23:58 +0200 | sm | throws his hands up at technology |
| 2022-05-05 11:24:33 +0200 | <merijn> | Right, so a write-up exists somewhere, just don't ask me where... >.> |
| 2022-05-05 11:27:13 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-05-05 11:29:21 +0200 | <sm> | haskell should have a periodic vote & funding round for projects, like cardano's project catalyst |
| 2022-05-05 11:29:55 +0200 | jollygood | (www-data@2607:5300:60:8be::1) |
| 2022-05-05 11:31:55 +0200 | <jollygood> | hi.I tried 9.2.2 on stack on windows, and I am getting weird error: |
| 2022-05-05 11:31:59 +0200 | <jollygood> | Stack has not been tested with GHC versions above 9.0, and using 9.2.2, this may fail. Found an invalid compiler at "ghc-9.2.2.exe": Received ExitFailure (-1073741515) when running Raw command: "ghc-9.2.2.exe" --info |
| 2022-05-05 11:32:20 +0200 | <jollygood> | I am using nightly-2022-05-05 resolver |
| 2022-05-05 11:33:23 +0200 | <sm> | the first sentence can usually be ignored. Try to run that exe yourself with that flag, does it work ? |
| 2022-05-05 11:34:15 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-05-05 11:34:57 +0200 | <jollygood> | it doesn't give me any errors, or any output |
| 2022-05-05 11:35:33 +0200 | gurkenglas | (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) |
| 2022-05-05 11:36:33 +0200 | <sm> | what about --version, or --help ? does the exe file look ok ? is the date what you expect ? was it installed by stack ? |
| 2022-05-05 11:37:15 +0200 | <jollygood> | no output no matter what arguments I pass to it |
| 2022-05-05 11:37:41 +0200 | <jollygood> | yes it was installed by stack |
| 2022-05-05 11:38:34 +0200 | <sm> | sounds invalid alright. I'd check stack and ghc issue trackers and maybe ask #ghc |
| 2022-05-05 11:39:47 +0200 | <sm> | and maybe try installing it with ghcup and configuring stack to use that |
| 2022-05-05 11:40:12 +0200 | <jollygood> | ghci doesn't work either, it just returns. |
| 2022-05-05 11:40:56 +0200 | xaotuk | (~sasha@2a06:5b00:15fe:9b00::2) |
| 2022-05-05 11:41:36 +0200 | jonathanx | (~jonathan@dyn-5-sc.cdg.chalmers.se) (Remote host closed the connection) |
| 2022-05-05 11:42:18 +0200 | <maerwald> | what's the best book on haskell concurrency and performance? |
| 2022-05-05 11:42:43 +0200 | <sm> | simon marlow's of course |
| 2022-05-05 11:42:43 +0200 | <merijn> | The best book on concurrency is Simon Marlow's paralle and concurrent Haskell |
| 2022-05-05 11:42:59 +0200 | <kuribas> | +1 |
| 2022-05-05 11:43:03 +0200 | <Hecate> | yeah that's the best you've got at the moment |
| 2022-05-05 11:43:05 +0200 | <merijn> | it talks about *efficiency* for the things covered, but that's not the same as performance |
| 2022-05-05 11:43:12 +0200 | <sm> | ack |
| 2022-05-05 11:43:15 +0200 | <merijn> | I don't think there's really any book on Haskell performance |
| 2022-05-05 11:43:38 +0200 | <kuribas> | first learn performance in a general sense. |
| 2022-05-05 11:43:41 +0200 | <merijn> | That said, I don't think there's any decent book on performance in other languages either :p |
| 2022-05-05 11:44:12 +0200 | <merijn> | Which is kinda a problem, I learned through osmosis, but then sometimes people ask me "where/how did you learn this stuff and how can I learn?" and then I don't have an answer |
| 2022-05-05 11:44:17 +0200 | <kuribas> | optimize queries, use the right algorithms, then do linear optimizations (cache locality etc). |
| 2022-05-05 11:44:35 +0200 | <merijn> | See, I actually think that's wrong :p |
| 2022-05-05 11:44:44 +0200 | mbuf | (~Shakthi@27.58.129.52) (Quit: Leaving) |
| 2022-05-05 11:45:05 +0200 | <kuribas> | merijn: are you going to say, profile first? :-) |
| 2022-05-05 11:45:05 +0200 | <merijn> | If you *truly* care about performance you can't write your code first and then optimise after. You gotta design your code "from the inner loop outwards" |
| 2022-05-05 11:45:10 +0200 | <sm> | "hire me as coach for one meelleon dollars" |
| 2022-05-05 11:45:32 +0200 | <kuribas> | merijn: also first, do you need to care about performance? |
| 2022-05-05 11:45:33 +0200 | <merijn> | kuribas: Profiling is important, but you can't profile and optimise your way out of every performance problem |
| 2022-05-05 11:45:36 +0200 | gensyst | (gensyst@user/gensyst) |
| 2022-05-05 11:45:59 +0200 | <merijn> | So, actually one of the most interesting and enlightening things I learned from Google was during my interview there |
| 2022-05-05 11:46:04 +0200 | <kuribas> | you need a good architecture first. |
| 2022-05-05 11:46:13 +0200 | <merijn> | One of the interviews was the "non-abstract large scale systems design" interview |
| 2022-05-05 11:46:41 +0200 | <merijn> | Which was basically, "here's some ballpark requirements and numbers, design a ballpark system design" |
| 2022-05-05 11:46:50 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-05 11:47:06 +0200 | <merijn> | i.e. estimate the required computational/latency stuff from some napkin math and estimate what'd you'd *roughly* need |
| 2022-05-05 11:47:19 +0200 | <sm> | kuribas++ |
| 2022-05-05 11:47:55 +0200 | <merijn> | The architecture needs of high performance code can be radically different depending on the performance needed |
| 2022-05-05 11:48:02 +0200 | <merijn> | So you can't just decide architecture first |
| 2022-05-05 11:48:42 +0200 | <sm> | if you want a system to be fast, it's a good idea to think about the whole system first |
| 2022-05-05 11:48:55 +0200 | <gensyst> | I want to create a "machine" with its own state, so I can do initMachine :: m state and then updateMachine :: MyDataType -> state -> m state and along the way queryMachine :: state -> SomeOutputType. How can I do this without exposing the state type to the outside world? |
| 2022-05-05 11:48:55 +0200 | <merijn> | "hollistic systems design" |
| 2022-05-05 11:49:02 +0200 | <kuribas> | merijn: first a prototype? |
| 2022-05-05 11:49:09 +0200 | <merijn> | I will write that on my resume, next to "software zymurgist" |
| 2022-05-05 11:49:28 +0200 | <merijn> | kuribas: I mean, you don't necessarily need a prototype to make decisions like that |
| 2022-05-05 11:49:35 +0200 | <merijn> | IFF you know what you're doing |
| 2022-05-05 11:49:51 +0200 | robosexual | (~robosexua@92.248.229.56) |
| 2022-05-05 11:49:53 +0200 | <gensyst> | AND in such a way that the state type is still known (internally by the type checker) to be the same across all those function calls. |
| 2022-05-05 11:50:02 +0200 | <merijn> | Like, if you know the main computational load is "a bunch of matrix math" the architecture should be "how do I most efficiently feed data into BLAS" |
| 2022-05-05 11:50:42 +0200 | <merijn> | gensyst: You can use a record with an existential type to get something like that |
| 2022-05-05 11:51:16 +0200 | <jollygood> | issue is with ghc not with stack: https://gitlab.haskell.org/ghc/ghc/-/issues/21196 |
| 2022-05-05 11:52:13 +0200 | <sm> | aha, there's that 9.2 showstopper so was wondering about. nice one |
| 2022-05-05 11:52:25 +0200 | bahamas | (~lucian@92.85.13.88) (Ping timeout: 248 seconds) |
| 2022-05-05 11:52:34 +0200 | <kuribas> | gensyst: not that if you want things to be checked at compile time, the *must* be exposed. |
| 2022-05-05 11:54:02 +0200 | <gensyst> | So I ask for the impossible? |
| 2022-05-05 11:54:12 +0200 | <merijn> | kuribas: Wrong |
| 2022-05-05 11:54:15 +0200 | <merijn> | Hold on |
| 2022-05-05 11:54:20 +0200 | <merijn> | I'm finishing a sketch |
| 2022-05-05 11:54:27 +0200 | <sm> | Hold his beer |
| 2022-05-05 11:54:49 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-05 11:55:21 +0200 | <kuribas> | merijn: well, putting the type in a GADT is still "exposing" the state. |
| 2022-05-05 11:56:21 +0200 | <merijn> | hmm |
| 2022-05-05 11:56:24 +0200 | <merijn> | pastebin is slow |
| 2022-05-05 11:57:41 +0200 | <merijn> | Not tested, probably contains a typo, etc. but something like: https://dpaste.org/ppZAC |
| 2022-05-05 11:58:18 +0200 | <merijn> | That way the internal state 's' can be any type not visible to users of StateMachine |
| 2022-05-05 11:58:47 +0200 | <merijn> | But now it's time for my lunch walk, so I let the hard work of explanation to someone else :p |
| 2022-05-05 11:59:19 +0200 | <kuribas> | you still have the same state type everywhere, so it doesn't check the states. |
| 2022-05-05 11:59:31 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) |
| 2022-05-05 12:00:05 +0200 | <merijn> | Either you or I misunderstood the question :p |
| 2022-05-05 12:00:12 +0200 | <kuribas> | well, if he meant, parametrize over state, that your solution would work. |
| 2022-05-05 12:00:24 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 248 seconds) |
| 2022-05-05 12:03:15 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-05 12:03:53 +0200 | jonathanx | (~jonathan@dyn-5-sc.cdg.chalmers.se) |
| 2022-05-05 12:04:08 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) (Ping timeout: 248 seconds) |
| 2022-05-05 12:04:20 +0200 | sweater | (~sweater@206.81.18.26) (Remote host closed the connection) |
| 2022-05-05 12:06:39 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.5) |
| 2022-05-05 12:07:59 +0200 | sweater | (~sweater@206.81.18.26) |
| 2022-05-05 12:09:28 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Ping timeout: 248 seconds) |
| 2022-05-05 12:12:27 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-05-05 12:12:59 +0200 | <gensyst> | merijn, hmm the idea of combining such "internal" funcs with other "external" funcs didn't occur to me |
| 2022-05-05 12:13:03 +0200 | <gensyst> | i'll try it out |
| 2022-05-05 12:13:33 +0200 | flinner | (~flinner@user/flinner) |
| 2022-05-05 12:14:23 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-05-05 12:16:31 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-05-05 12:16:55 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-05-05 12:21:34 +0200 | flinner | (~flinner@user/flinner) (Quit: Using Circe, the loveliest of all IRC clients) |
| 2022-05-05 12:27:24 +0200 | gurkenglas | (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) (Ping timeout: 276 seconds) |
| 2022-05-05 12:30:56 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-05 12:33:53 +0200 | mmhat | (~mmh@2001:4090:a242:802a:ee08:6bff:fe09:5315) (Ping timeout: 256 seconds) |
| 2022-05-05 12:34:53 +0200 | merijn | (~merijn@86.86.29.250) (Ping timeout: 260 seconds) |
| 2022-05-05 12:36:53 +0200 | crazazy | (~user@130.89.171.62) |
| 2022-05-05 12:47:00 +0200 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Ping timeout: 248 seconds) |
| 2022-05-05 12:47:04 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-05-05 12:47:30 +0200 | mmhat | (~mmh@2001:4090:a242:800a:ee08:6bff:fe09:5315) |
| 2022-05-05 12:48:03 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds) |
| 2022-05-05 12:48:21 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2022-05-05 12:54:02 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-05-05 12:56:22 +0200 | CiaoSen | (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-05-05 13:01:34 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-05-05 13:04:35 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-05-05 13:09:18 +0200 | <gensyst> | merijn, It's line 13 (utilizing the earlier pattern match) that perplexes me. Why does this work? Yet for some reason if you do the exact same thing without pattern matching, it stops working: https://dpaste.org/AM1WW |
| 2022-05-05 13:09:24 +0200 | <gensyst> | because of "escaped type variables" |
| 2022-05-05 13:09:27 +0200 | <gensyst> | but why..... |
| 2022-05-05 13:09:38 +0200 | <gensyst> | why are they any less "escaped" with pattern matching |
| 2022-05-05 13:15:08 +0200 | acidjnk | (~acidjnk@p200300d0c7068b437523c7c9ae2c8004.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-05-05 13:19:17 +0200 | <merijn> | gensyst: That's part of ExistentialQuantification |
| 2022-05-05 13:19:38 +0200 | <merijn> | gensyst: Basically, the type 's' is only "in scope" after you pattern match on StateMachine |
| 2022-05-05 13:20:07 +0200 | <merijn> | gensyst: It's complaining about "escaping", because what you wrote makes 's' "visible" outside a pattern match, but the type system cannot deal with that |
| 2022-05-05 13:20:59 +0200 | <merijn> | gensyst: So when you pattern match on StateMachine you (temporarily and in a limited scope) get a vision of 's', but you're not allowed to let anyone else notice 's', because then the type checker would have to know what it is |
| 2022-05-05 13:21:32 +0200 | <merijn> | In my version, we make 's' visible by pattern matching, but then carefully pack things back up and hidden for the outside world before returning anything |
| 2022-05-05 13:22:09 +0200 | bahamas | (~lucian@84.232.141.55) |
| 2022-05-05 13:23:04 +0200 | <gensyst> | merijn, ok but wouldn't it be possible to expose the stuff we got from the pattern match to the outside world? (I have tried and the compiler will complain similarly about "escaped type variables" if we try). So the point is that in my (incorrect) method, those things for some reason get escaped earlier, even if we don't really escape them in the end. |
| 2022-05-05 13:23:09 +0200 | <gensyst> | Do you see what I mean? |
| 2022-05-05 13:23:24 +0200 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2022-05-05 13:23:34 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-05 13:23:41 +0200 | <merijn> | gensyst: You are allowed to expose anything *other than* 's' just fine |
| 2022-05-05 13:24:29 +0200 | <merijn> | gensyst: Theoretically you could (maybe) make a complicated analysis to make that work, but then the question is: Is that worth the maintenance effort? |
| 2022-05-05 13:24:43 +0200 | <merijn> | Especially since there's a simple workaround of "just write out the pattern match" |
| 2022-05-05 13:25:22 +0200 | <gensyst> | merijn, hmm, but how does the pattern match makes this easier for the compiler? |
| 2022-05-05 13:25:52 +0200 | briandaed | (~briandaed@109.95.142.93.r.toneticgroup.pl) |
| 2022-05-05 13:26:09 +0200 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) |
| 2022-05-05 13:28:09 +0200 | <merijn> | gensyst: The 'forall s' part says "there is *a* type 's', don't have to care what, but it's the same in all the bits of this datatype". When you pattern match the compiler plucks a temporary (opaque! so it doesn't know what it is) type out of thin air and checks the code as if you're using that in all the functions. If you would use "currentState myMachine :: s" (i.e. using the accessor function on a |
| 2022-05-05 13:28:15 +0200 | <merijn> | StateMachine record) it does that too, but now it escapes |
| 2022-05-05 13:29:05 +0200 | <merijn> | If you do it *twice* "querymachine myMachine (currenState myMachine)" then it creates *two* separate opaque type for each access and then goes "hey, these aren't the same" (because that type is only equivalent to itself) |
| 2022-05-05 13:29:33 +0200 | <merijn> | gensyst: You'd need to somehow see in the compiler that "really, these two reifications of the opaque type 's' happen in the same scope and refer to the same 's'" |
| 2022-05-05 13:29:37 +0200 | <merijn> | But that logic is *hard* |
| 2022-05-05 13:30:02 +0200 | <merijn> | Well, except when you simply tie it to pattern matching and sharing the opaque type accross all field members when you do the pattern match! Then it's easy |
| 2022-05-05 13:30:09 +0200 | <merijn> | So that's what's done |
| 2022-05-05 13:30:59 +0200 | <merijn> | (to you it's obvious they *are* the same, but the compiler has no logic for proving that, it just temporarily inserts opaque types unequal to every other type) |
| 2022-05-05 13:35:22 +0200 | robosexual | (~robosexua@92.248.229.56) (Quit: WeeChat 3.5) |
| 2022-05-05 13:35:23 +0200 | <gensyst> | merijn, But even in your code, doesn't a new s (s2) get created when you create a *new* StateMachine? |
| 2022-05-05 13:35:37 +0200 | <gensyst> | so here it seems the compiler *can* deduce that those s are the same |
| 2022-05-05 13:36:04 +0200 | <merijn> | gensyst: No? Because all the function types can be typechecked fine |
| 2022-05-05 13:36:25 +0200 | <merijn> | gensyst: So it knows the result of 'updateInternalMachine' returns the *same* 's' as it received as input |
| 2022-05-05 13:36:35 +0200 | chomwitt | (~chomwitt@2a02:587:dc19:d600:6d5a:79e9:ac14:c3a8) |
| 2022-05-05 13:36:58 +0200 | <merijn> | gensyst: Imagine all the 's' variables are replaced with an imaginary "concrete" (I dislike that word, but fine) S type |
| 2022-05-05 13:37:27 +0200 | <merijn> | The compiler has no idea *what* S is, which constructors it has, etc. It just knows "type S exists and these functions take S as argument" and then typechecks that |
| 2022-05-05 13:37:59 +0200 | <merijn> | So it knows the "new" state 'result' has the same type as the old currenState (because typechecking proves that) |
| 2022-05-05 13:38:06 +0200 | <merijn> | It just has no idea what that is |
| 2022-05-05 13:39:00 +0200 | <merijn> | gensyst: Without the pattern match you end up instead getting type S for the use of currentState and S' for the use of 'updateInternalMachine', and S and S' are not the same (at least, there's no way to prove that) |
| 2022-05-05 13:40:12 +0200 | <gensyst> | ah! ok now i get what you mean by "twice" |
| 2022-05-05 13:40:18 +0200 | <gensyst> | interesting. |
| 2022-05-05 13:40:51 +0200 | <gensyst> | the pattern matching guarantees same for all |
| 2022-05-05 13:41:01 +0200 | <gensyst> | in an easy way |
| 2022-05-05 13:41:47 +0200 | <merijn> | gensyst: Right! |
| 2022-05-05 13:43:08 +0200 | <gensyst> | Thank you very much. |
| 2022-05-05 13:47:27 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 240 seconds) |
| 2022-05-05 13:47:27 +0200 | <apache2> | merijn: I guess profiling would work for this |
| 2022-05-05 13:48:08 +0200 | <apache2> | kuribas: Debug.Trace is kind of hard to integrate though, I haven't gotten it to work reliably (and it's probably because I'm missing something) |
| 2022-05-05 13:48:28 +0200 | <apache2> | sm: I set ulimit -v to get it to crash rather than bog down the whole machine |
| 2022-05-05 13:48:52 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-05 13:49:47 +0200 | <apache2> | sorry I''m 200 years behind the backlog |
| 2022-05-05 13:52:28 +0200 | mmhat | (~mmh@2001:4090:a242:800a:ee08:6bff:fe09:5315) (Ping timeout: 260 seconds) |
| 2022-05-05 13:53:41 +0200 | <apache2> | would be nice with a signal handler for ctrl+t like in bsd libc |
| 2022-05-05 13:54:50 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Read error: Connection reset by peer) |
| 2022-05-05 13:55:15 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-05 13:57:20 +0200 | zero | (~z@user/zero) |
| 2022-05-05 14:01:08 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) |
| 2022-05-05 14:04:20 +0200 | dsrt^ | (~dsrt@173-160-94-253-atlanta.hfc.comcastbusiness.net) |
| 2022-05-05 14:06:21 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-05-05 14:06:34 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 240 seconds) |
| 2022-05-05 14:06:40 +0200 | AlexNoo_ | AlexNoo |
| 2022-05-05 14:07:03 +0200 | <geekosaur> | apache2, I keep wishing linux would add the necessary support for that, but they refuse |
| 2022-05-05 14:07:55 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-05-05 14:08:30 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-05-05 14:10:00 +0200 | <geekosaur> | (it's not just libc, the tty driver needs tpgrp SIGSTAT support, but Linus considers it evil) |
| 2022-05-05 14:11:05 +0200 | <exarkun> | someone just needs to build a userspace tty driver so it can stop being the kernel's business at all, right? |
| 2022-05-05 14:11:32 +0200 | <geekosaur> | someone did: readline |
| 2022-05-05 14:11:48 +0200 | <geekosaur> | but the kernel still needs to sort out who "owns" the tty and is active |
| 2022-05-05 14:12:04 +0200 | <geekosaur> | ("who" being a process) |
| 2022-05-05 14:13:24 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 248 seconds) |
| 2022-05-05 14:13:49 +0200 | dcoutts__ | (~duncan@host81-156-211-196.range81-156.btcentralplus.com) |
| 2022-05-05 14:14:39 +0200 | mmhat | (~mmh@2001:4090:a246:806c:ee08:6bff:fe09:5315) |
| 2022-05-05 14:15:03 +0200 | frost | (~frost@user/frost) (Quit: Client closed) |
| 2022-05-05 14:16:17 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-05-05 14:16:37 +0200 | <kuribas> | apache2: you don't "integrate" it, you just add trace statements, debug (on the repl), then remove the statements. |
| 2022-05-05 14:17:22 +0200 | <geekosaur> | I can see Linus's point, the tty driver having to walk the processes in the tpgrp and determine the (most likely) active one is pretty grody and a bit unreliable. but damn would it be useful |
| 2022-05-05 14:17:57 +0200 | <[exa]> | they're moving it finally? |
| 2022-05-05 14:18:48 +0200 | <geekosaur> | ? |
| 2022-05-05 14:18:59 +0200 | [exa] | reads the rest of the scrollback |
| 2022-05-05 14:19:10 +0200 | <[exa]> | ah ok no changes ._. |
| 2022-05-05 14:20:16 +0200 | <geekosaur> | pretty sure it won't be happening while Linus is in charge |
| 2022-05-05 14:20:23 +0200 | frost | (~frost@user/frost) |
| 2022-05-05 14:20:31 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 256 seconds) |
| 2022-05-05 14:21:11 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-05 14:21:24 +0200 | <exarkun> | geekosaur: Yea I meant all of that other "grody" stuff should be userspace too. |
| 2022-05-05 14:22:12 +0200 | jao | (~jao@211.68.17.95.dynamic.jazztel.es) |
| 2022-05-05 14:22:50 +0200 | <geekosaur> | userspace doesn't have enough access, and shouldn't |
| 2022-05-05 14:23:19 +0200 | <[exa]> | I hope they will eventually tie signals as OOB to file descriptors, as they should be |
| 2022-05-05 14:23:36 +0200 | <[exa]> | ^ wishful thinking for next 50+ years |
| 2022-05-05 14:23:54 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-05-05 14:24:01 +0200 | <geekosaur> | it requires determining when a process (that might be on your uid but not readable) is blocked |
| 2022-05-05 14:24:11 +0200 | <geekosaur> | and what it's blocked on |
| 2022-05-05 14:25:58 +0200 | acidjnk | (~acidjnk@p200300d0c7068b43e18f8794d20d12cb.dip0.t-ipconnect.de) |
| 2022-05-05 14:27:57 +0200 | <apache2> | geekosaur: I see |
| 2022-05-05 14:28:03 +0200 | <apache2> | geekosaur: I guess the shell could do it too |
| 2022-05-05 14:28:20 +0200 | <apache2> | find the pg of the pty slave and send a USRINFO1 or whatever |
| 2022-05-05 14:28:48 +0200 | <apache2> | kuribas: oh, Debug.Trace shows up in the repl? |
| 2022-05-05 14:29:20 +0200 | <apache2> | [exa]: they have signalfd which is how sensible programs handle signals in the last few years |
| 2022-05-05 14:29:35 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 2022-05-05 14:30:39 +0200 | <apache2> | it's not quite oob |
| 2022-05-05 14:30:51 +0200 | <apache2> | but close |
| 2022-05-05 14:32:36 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-05 14:34:40 +0200 | <kuribas> | apache2: yes, it goes to stderr |
| 2022-05-05 14:35:05 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) (Ping timeout: 248 seconds) |
| 2022-05-05 14:37:20 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Ping timeout: 260 seconds) |
| 2022-05-05 14:37:26 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-05-05 14:37:48 +0200 | dcoutts__ | (~duncan@host81-156-211-196.range81-156.btcentralplus.com) (Ping timeout: 246 seconds) |
| 2022-05-05 14:38:15 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-05-05 14:42:09 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-05 14:48:52 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-05-05 14:49:14 +0200 | coot | (~coot@213.134.190.95) |
| 2022-05-05 14:50:10 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 2022-05-05 14:52:21 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Ping timeout: 276 seconds) |
| 2022-05-05 14:52:35 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-05-05 14:55:32 +0200 | odnes | (~odnes@5-203-254-76.pat.nym.cosmote.net) (Ping timeout: 248 seconds) |
| 2022-05-05 15:00:14 +0200 | <[exa]> | apache2: ah that is cool |
| 2022-05-05 15:03:10 +0200 | bahamas | (~lucian@84.232.141.55) |
| 2022-05-05 15:04:15 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) |
| 2022-05-05 15:07:48 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 248 seconds) |
| 2022-05-05 15:07:48 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 248 seconds) |
| 2022-05-05 15:07:48 +0200 | xff0x | (~xff0x@om126167084162.29.openmobile.ne.jp) |
| 2022-05-05 15:09:37 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-05-05 15:11:43 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-05 15:11:53 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-05-05 15:12:00 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-05-05 15:13:09 +0200 | odnes | (~odnes@5-203-254-76.pat.nym.cosmote.net) |
| 2022-05-05 15:16:55 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-05-05 15:20:10 +0200 | Unicorn_Princess | (~Unicorn_P@93-103-228-248.dynamic.t-2.net) |
| 2022-05-05 15:23:42 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-05-05 15:27:14 +0200 | tlamer | (~tlamer@ip-94-112-134-89.net.upcbroadband.cz) |
| 2022-05-05 15:33:44 +0200 | Topsi | (~Topsi@dyndsl-037-138-064-083.ewe-ip-backbone.de) |
| 2022-05-05 15:33:59 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) |
| 2022-05-05 15:36:55 +0200 | gpncarl | (~gpncarl@120.244.220.74) (Ping timeout: 260 seconds) |
| 2022-05-05 15:37:58 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-05-05 15:37:59 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-05-05 15:37:59 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-05-05 15:41:55 +0200 | bahamas | (~lucian@84.232.141.55) |
| 2022-05-05 15:42:00 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-05-05 15:42:19 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-05-05 15:46:43 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 260 seconds) |
| 2022-05-05 15:48:22 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-05 15:51:02 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) |
| 2022-05-05 15:55:43 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-05-05 16:00:16 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:e8a7:5207:d6e5:3f9a) (Quit: WeeChat 2.8) |
| 2022-05-05 16:00:48 +0200 | acidjnk | (~acidjnk@p200300d0c7068b43e18f8794d20d12cb.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-05-05 16:04:55 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2022-05-05 16:09:55 +0200 | xkuru | (~xkuru@user/xkuru) |
| 2022-05-05 16:15:09 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-05-05 16:17:04 +0200 | kaiepi | (~Kaiepi@156.34.47.253) (Remote host closed the connection) |
| 2022-05-05 16:18:19 +0200 | kaiepi | (~Kaiepi@156.34.47.253) |
| 2022-05-05 16:20:00 +0200 | frost | (~frost@user/frost) (Ping timeout: 252 seconds) |
| 2022-05-05 16:20:39 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 256 seconds) |
| 2022-05-05 16:21:52 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Quit: _) |
| 2022-05-05 16:22:09 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-05-05 16:28:14 +0200 | odnes_ | (~odnes@5-203-254-76.pat.nym.cosmote.net) |
| 2022-05-05 16:28:53 +0200 | odnes | (~odnes@5-203-254-76.pat.nym.cosmote.net) (Read error: Connection reset by peer) |
| 2022-05-05 16:30:47 +0200 | vicfred | (~vicfred@user/vicfred) |
| 2022-05-05 16:31:43 +0200 | xff0x | (~xff0x@om126167084162.29.openmobile.ne.jp) (Read error: Connection reset by peer) |
| 2022-05-05 16:37:07 +0200 | xff0x | (~xff0x@om126167084162.29.openmobile.ne.jp) |
| 2022-05-05 16:38:43 +0200 | CiaoSen | (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-05-05 16:39:18 +0200 | kaiepi | (~Kaiepi@156.34.47.253) (Ping timeout: 260 seconds) |
| 2022-05-05 16:49:01 +0200 | moonsheep | (~user@iespladelestany.xtec.cat) |
| 2022-05-05 16:51:08 +0200 | spacenautx | (~spacenaut@user/spacenautx) |
| 2022-05-05 16:52:11 +0200 | cdman | (~dcm@user/dmc/x-4369397) (Quit: Leaving) |
| 2022-05-05 16:52:48 +0200 | odnes_ | (~odnes@5-203-254-76.pat.nym.cosmote.net) (Read error: Connection reset by peer) |
| 2022-05-05 16:53:11 +0200 | odnes | (~odnes@5-203-254-76.pat.nym.cosmote.net) |
| 2022-05-05 16:55:52 +0200 | vicfred | (~vicfred@user/vicfred) (Quit: Leaving) |
| 2022-05-05 16:57:02 +0200 | shriekingnoise | (~shrieking@201.231.16.156) |
| 2022-05-05 16:57:43 +0200 | <juhp[m]> | "(if ... then ... else ...)-syntax in pattern" <- never seen the error before - boggling - no idea how I managed to make it |
| 2022-05-05 16:58:28 +0200 | <juhp[m]> | The code is just: return $ if ok then classified else [] |
| 2022-05-05 16:59:11 +0200 | <juhp[m]> | Completely perfluxed |
| 2022-05-05 16:59:13 +0200 | <geekosaur> | would have to see a bit more, I think. sometimes it means the error is in whatever precedes it |
| 2022-05-05 17:00:00 +0200 | <juhp[m]> | aha - following it says "Possibly caused by a missing 'do'?" |
| 2022-05-05 17:00:33 +0200 | <geekosaur> | as written that doesn't require do, so I have to assume whatever precedes it does |
| 2022-05-05 17:02:23 +0200 | <juhp[m]> | well it is in a do block: the preceding like is: ok <- prompt "install above" |
| 2022-05-05 17:02:35 +0200 | <dminuoso> | % f (if c then a else b) = _ |
| 2022-05-05 17:03:12 +0200 | <dminuoso> | juhp[m]: is there an if-then-else before? |
| 2022-05-05 17:03:15 +0200 | <dminuoso> | if yes, that would explain it |
| 2022-05-05 17:03:40 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-05-05 17:03:40 +0200 | <juhp[m]> | let me check more carefully |
| 2022-05-05 17:04:00 +0200 | <dminuoso> | Because if you remove the line break, then you have something like `if x then a else b ok <- prompt ...` |
| 2022-05-05 17:04:16 +0200 | Ether17 | (~Ether17@45.248.151.237) |
| 2022-05-05 17:04:21 +0200 | <juhp[m]> | basically it's something like https://github.com/juhp/koji-tool/blob/main/src/Install.hs#L204 |
| 2022-05-05 17:04:26 +0200 | <dminuoso> | Who knows in what state the parser is to consider this a pattern match |
| 2022-05-05 17:04:51 +0200 | <juhp[m]> | Just I put similar do block under the All case and then this... |
| 2022-05-05 17:05:10 +0200 | <geekosaur> | I was thinking of it's on the line it says then two lines in what was supposed to be a do, with the do missing, so the second is taken as a definition of $ |
| 2022-05-05 17:05:13 +0200 | <juhp[m]> | Let me try to revert back.... quite weird |
| 2022-05-05 17:05:40 +0200 | <juhp[m]> | I tried replacing $ but it didn't seem to help |
| 2022-05-05 17:06:14 +0200 | <dminuoso> | juhp[m]: ah yes, imagine you forget the do above |
| 2022-05-05 17:06:58 +0200 | <dminuoso> | if yes == Yes then return install else do mapM_ printInstalled install ok <- prompt "install above" |
| 2022-05-05 17:07:10 +0200 | <dminuoso> | I can see how this diagnostic might fire |
| 2022-05-05 17:10:17 +0200 | <juhp[m]> | So what is the solution? I still don't see it |
| 2022-05-05 17:10:35 +0200 | <dminuoso> | 17:00:00 juhp[m] | aha - following it says "Possibly caused by a missing 'do'? |
| 2022-05-05 17:10:57 +0200 | <juhp[m]> | okay |
| 2022-05-05 17:11:08 +0200 | moonsheep | (~user@iespladelestany.xtec.cat) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)) |
| 2022-05-05 17:12:47 +0200 | moonsheep | (~user@iespladelestany.xtec.cat) |
| 2022-05-05 17:13:11 +0200 | dsrt^ | (~dsrt@173-160-94-253-atlanta.hfc.comcastbusiness.net) (Remote host closed the connection) |
| 2022-05-05 17:14:19 +0200 | <juhp[m]> | Sorry!! Afaict it was caused by an incorrect <- in the following case which should have been a let :-( ugghh |
| 2022-05-05 17:14:40 +0200 | <juhp[m]> | s/case/pattern/ |
| 2022-05-05 17:14:51 +0200 | <juhp[m]> | Rather confusing error message |
| 2022-05-05 17:15:18 +0200 | <juhp[m]> | Thanks a lot, dminuoso and geekosaur ! |
| 2022-05-05 17:15:34 +0200 | hololeap_ | (~hololeap@user/hololeap) (Ping timeout: 240 seconds) |
| 2022-05-05 17:15:47 +0200 | <juhp[m]> | Never seen that before (apparently it was introduced in 2020) |
| 2022-05-05 17:15:54 +0200 | <dminuoso> | juhp[m]: you might want to follow a different style |
| 2022-05-05 17:16:10 +0200 | <dminuoso> | the kind of interleaved if-then-else + do-notation + early-return is not very idiomatic |
| 2022-05-05 17:16:35 +0200 | <dminuoso> | it's hard to follow, even for yourself as you have just seen. :) |
| 2022-05-05 17:16:41 +0200 | <Athas> | It is possible to get `cabal install` to behave more sanely (i.e. just copy the damn binaries built by 'cabal build'), or is there an alternative command I can run to do that? |
| 2022-05-05 17:16:44 +0200 | <juhp[m]> | dminuoso: right - any pointers would be welcome |
| 2022-05-05 17:16:46 +0200 | <juhp[m]> | indeed |
| 2022-05-05 17:17:27 +0200 | <juhp[m]> | Athas: you mean not generate a tarball? dunno |
| 2022-05-05 17:17:52 +0200 | <dminuoso> | Athas: cp $(cabal -v0 list-bin) |
| 2022-05-05 17:17:52 +0200 | Vajb | (~Vajb@2001:999:400:9bc1:d5dd:7e53:33b:56) (Read error: Connection reset by peer) |
| 2022-05-05 17:18:01 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-05-05 17:18:36 +0200 | <dminuoso> | Depending on your cabal version, you might have to specify the cabal component for list-bin |
| 2022-05-05 17:18:48 +0200 | <juhp[m]> | Athas: I started project on github called system-cabal but it is still alpha/beta-ish, which somewhat addresses this |
| 2022-05-05 17:18:55 +0200 | hololeap_ | (~hololeap@user/hololeap) |
| 2022-05-05 17:19:32 +0200 | <dminuoso> | I mean it can be as simple as some `cabal build foo:exe:bar && cp $(cabal -v0 list-bin foo:exe:bar) ~/.local/bin/` *shrugs* |
| 2022-05-05 17:19:38 +0200 | <Athas> | dminuoso: I feared it would be something like that. |
| 2022-05-05 17:19:40 +0200 | <juhp[m]> | Athas: otherwise stack install ;o) :) |
| 2022-05-05 17:19:52 +0200 | <Athas> | Yes, that is the competition. |
| 2022-05-05 17:20:05 +0200 | <dminuoso> | Athas: So I guess you're looking for a simple `cabal copy-bin`? |
| 2022-05-05 17:20:09 +0200 | odnes | (~odnes@5-203-254-76.pat.nym.cosmote.net) (Remote host closed the connection) |
| 2022-05-05 17:20:30 +0200 | <Athas> | dminuoso: yes. |
| 2022-05-05 17:20:46 +0200 | <Athas> | Maybe I'll just create a shell script in my project root that abbreviates these hopeless commands. |
| 2022-05-05 17:21:07 +0200 | <dminuoso> | Haha, I was about to give you a command that was going to start `echo "#!/bin/bash\n ....` |
| 2022-05-05 17:21:47 +0200 | <Athas> | I am trying to fully migrate my project to cabal, but I don't want to hugely inconvenience my collaborators. |
| 2022-05-05 17:21:48 +0200 | <dminuoso> | Luckily we have list-bin nowadays, so the pipefitting is easy |
| 2022-05-05 17:23:04 +0200 | hololeap_ | (~hololeap@user/hololeap) (Ping timeout: 240 seconds) |
| 2022-05-05 17:23:36 +0200 | <Athas> | Hey, maybe I'll make it a Makefile and they can just pretend it's a C program. |
| 2022-05-05 17:23:41 +0200 | <juhp[m]> | I still feel my parse error is almost a bug? - I mean why would it mistaken the next case pattern as some other pattern just because it is missing a do |
| 2022-05-05 17:23:57 +0200 | <juhp[m]> | lol |
| 2022-05-05 17:24:14 +0200 | <geekosaur> | indentation |
| 2022-05-05 17:24:31 +0200 | <geekosaur> | I'd still like to see the whole context |
| 2022-05-05 17:24:33 +0200 | <dminuoso> | juhp[m]: Its an LALR generated parser for a whitespace sensitive language. Parser errors are always harsh in this situhation. |
| 2022-05-05 17:24:50 +0200 | <juhp[m]> | okay right, I see thanks |
| 2022-05-05 17:25:22 +0200 | liz_ | (~liz@host109-151-128-120.range109-151.btcentralplus.com) |
| 2022-05-05 17:25:36 +0200 | <juhp[m]> | geekosaur: I can push the code now that it compiles I guess :) |
| 2022-05-05 17:26:18 +0200 | hololeap_ | (~hololeap@user/hololeap) |
| 2022-05-05 17:31:48 +0200 | jonathanx | (~jonathan@dyn-5-sc.cdg.chalmers.se) (Remote host closed the connection) |
| 2022-05-05 17:39:39 +0200 | MajorBiscuit | (~MajorBisc@86-88-79-148.fixed.kpn.net) |
| 2022-05-05 17:40:52 +0200 | Null_A | (~null_a@2601:645:8700:2290:b1c9:2c49:e327:d981) |
| 2022-05-05 17:41:49 +0200 | dcoutts__ | (~duncan@host81-156-211-196.range81-156.btcentralplus.com) |
| 2022-05-05 17:45:45 +0200 | jinsun | (~jinsun@user/jinsun) |
| 2022-05-05 17:48:41 +0200 | kaiepi | (~Kaiepi@156.34.47.253) |
| 2022-05-05 17:50:28 +0200 | jinsun | (~jinsun@user/jinsun) (Ping timeout: 248 seconds) |
| 2022-05-05 17:52:37 +0200 | dzdcnfzd | (~dzdcnfzd@2600:387:5:807::73) |
| 2022-05-05 17:53:33 +0200 | xff0x | (~xff0x@om126167084162.29.openmobile.ne.jp) (Read error: Connection reset by peer) |
| 2022-05-05 17:53:36 +0200 | <dzdcnfzd> | Can anyone figure out how to write this function: `almostBind :: Monad m => FreeT f m a -> (FreeT f Identity a -> FreeT f m b) -> FreeT f m b` |
| 2022-05-05 17:53:52 +0200 | <dzdcnfzd> | Sorry, `Functor f` too |
| 2022-05-05 17:54:50 +0200 | <dzdcnfzd> | Also `Traversable f` |
| 2022-05-05 17:55:13 +0200 | ubert | (~Thunderbi@2a02:8109:9880:303c:ad62:b99:9259:5795) (Remote host closed the connection) |
| 2022-05-05 17:55:32 +0200 | jinsun | (~jinsun@user/jinsun) |
| 2022-05-05 17:56:41 +0200 | jollygood | (www-data@2607:5300:60:8be::1) (Quit: CGI:IRC (Session timeout)) |
| 2022-05-05 17:58:37 +0200 | <monochrom> | If it is not "\m k -> m >>= \a -> k (pure a)" then you need to say what it should do. |
| 2022-05-05 17:59:24 +0200 | <c_wraith> | you might need a runIdentity in there |
| 2022-05-05 18:00:06 +0200 | unclechu | (~unclechu@2001:470:69fc:105::354) (Quit: You have been kicked for being idle) |
| 2022-05-05 18:00:39 +0200 | <c_wraith> | oh, I see. that's more like almostAp than almostBind |
| 2022-05-05 18:01:18 +0200 | kaiepi | (~Kaiepi@156.34.47.253) (Read error: Connection reset by peer) |
| 2022-05-05 18:01:31 +0200 | <monochrom> | I don't know what else "almost bind" could mean. |
| 2022-05-05 18:01:44 +0200 | Ether17 | (~Ether17@45.248.151.237) (Quit: Client closed) |
| 2022-05-05 18:02:43 +0200 | <c_wraith> | that type feels very monad-control |
| 2022-05-05 18:03:07 +0200 | <dzdcnfzd> | I called it almostBind because the type signature looks like bind to me |
| 2022-05-05 18:03:10 +0200 | <dzdcnfzd> | no deep reason |
| 2022-05-05 18:03:17 +0200 | kaiepi | (~Kaiepi@156.34.47.253) |
| 2022-05-05 18:03:17 +0200 | <c_wraith> | it's closer to ap than bind |
| 2022-05-05 18:03:32 +0200 | <dzdcnfzd> | But `"\m k -> m >>= \a -> k (pure a)"` works! |
| 2022-05-05 18:03:39 +0200 | <dzdcnfzd> | Thanks monochrom! |
| 2022-05-05 18:04:21 +0200 | <geekosaur> | well, it does something. but is that something what you needed? |
| 2022-05-05 18:04:22 +0200 | <dzdcnfzd> | c_wraith: Yeah, it is, actually |
| 2022-05-05 18:04:33 +0200 | <dzdcnfzd> | Yes, I think :) |
| 2022-05-05 18:05:33 +0200 | <dzdcnfzd> | My specific use case is that I'm running in a transformer stack that looks like `FreeT f (Except String) ()` where `f` is a nice, well-behaved functor |
| 2022-05-05 18:06:22 +0200 | <dzdcnfzd> | I have a function `foo` which returns values of type `FreeT f (Except String) ()` |
| 2022-05-05 18:06:37 +0200 | jinsun | (~jinsun@user/jinsun) (Read error: Connection reset by peer) |
| 2022-05-05 18:06:50 +0200 | <dzdcnfzd> | I need to apply them to an action of type `FreeT f (Except String) ()` which expects an argument of type `FreeT f Identity ()` |
| 2022-05-05 18:06:52 +0200 | jinsun | (~jinsun@user/jinsun) |
| 2022-05-05 18:07:17 +0200 | <dzdcnfzd> | But if I get a `Left` value from `foo` I want the whole computation to collapse |
| 2022-05-05 18:07:46 +0200 | MajorBiscuit | (~MajorBisc@86-88-79-148.fixed.kpn.net) (Quit: WeeChat 3.4) |
| 2022-05-05 18:08:57 +0200 | <dzdcnfzd> | I think this works |
| 2022-05-05 18:09:03 +0200 | <dzdcnfzd> | the free monad still confuses me |
| 2022-05-05 18:11:04 +0200 | <dzdcnfzd> | The only thing I'm worried about, and this might be dumb (like I said, free monad and monad transformers generally are new to me) is whether I'll end up with the `arg` left over in my computation |
| 2022-05-05 18:11:22 +0200 | <dzdcnfzd> | whereas I really only want it to be applied to `k` |
| 2022-05-05 18:11:30 +0200 | <dzdcnfzd> | Does that make any sense or no? |
| 2022-05-05 18:12:38 +0200 | xaotuk | (~sasha@2a06:5b00:15fe:9b00::2) (Ping timeout: 260 seconds) |
| 2022-05-05 18:14:18 +0200 | xaotuk | (~sasha@net224-32-245-109.mbb.telenor.rs) |
| 2022-05-05 18:17:27 +0200 | <dzdcnfzd> | This is a comparison of what I'm doing with the suggestion: https://paste.tomsmeding.com/E9eWj957 |
| 2022-05-05 18:17:40 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) (Ping timeout: 248 seconds) |
| 2022-05-05 18:18:32 +0200 | <dzdcnfzd> | I actually think they may be different |
| 2022-05-05 18:21:14 +0200 | MajorBiscuit | (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) |
| 2022-05-05 18:23:22 +0200 | benin | (~benin@183.82.29.230) (Quit: The Lounge - https://thelounge.chat) |
| 2022-05-05 18:23:50 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2022-05-05 18:24:26 +0200 | <k`> | So I get the feeling that `Pointed` is generally considered a mistake, but what about `Copointed` ? Seems like it's harder to get `copoint` 'wrong'. |
| 2022-05-05 18:25:00 +0200 | <geekosaur> | it's not a mistake, it just doesn't pull its weight |
| 2022-05-05 18:25:15 +0200 | <k`> | Sorry, that's what I meant by 'mistake'. 'Not worth it'. |
| 2022-05-05 18:25:47 +0200 | <geekosaur> | if we were being strict about typeclasses, it'd be there and Applicative would be `Pointed f, Apply f => Applicative f` with no methods |
| 2022-05-05 18:26:04 +0200 | <geekosaur> | but typeclasses have a cost that nobody wants to pay |
| 2022-05-05 18:27:28 +0200 | <k`> | I really don't mind paying, but the price seems more like folks getting `point` wrong (e.g. creating a singleton for a zipping Apply). |
| 2022-05-05 18:27:33 +0200 | <c_wraith> | Note that the cost isn't technical. |
| 2022-05-05 18:28:39 +0200 | <c_wraith> | The cost is in communication. if Applicative was defined as Pointed + Apply and some laws, do you expect those laws to hold if Applicative doesn't appear in the type declaration? |
| 2022-05-05 18:29:51 +0200 | <c_wraith> | If you compose two functions, one of which uses only Apply and the other uses only Pointed, does the result depend on Applicative? |
| 2022-05-05 18:30:25 +0200 | dyeplexer | (~dyeplexer@user/dyeplexer) (Ping timeout: 256 seconds) |
| 2022-05-05 18:31:26 +0200 | <c_wraith> | none of these things are technical issues with whether it will compile or not. They're issues of communication and expectations. |
| 2022-05-05 18:32:26 +0200 | <k`> | Clearly you need to put an Applicative constraint on the result if you want to be sure. Unless you're OK with documentation like 'If it's also Apply, it MUST follow these laws.' and 'If it's also Pointed, it must follow these laws.'. |
| 2022-05-05 18:33:18 +0200 | <k`> | Then `Applicative` degrades to `class (Pointed m, Apply m)=> Applicative m; instance (Pointed m, Apply m)=> Applicative m`. |
| 2022-05-05 18:33:56 +0200 | <k`> | And since all these laws are unenforced conventions, maybe that's OK. But folks already tend to get things wrong... |
| 2022-05-05 18:34:13 +0200 | <c_wraith> | It's a very slippery slope to expect people to keep an MxN matrix of laws in their head |
| 2022-05-05 18:34:34 +0200 | <c_wraith> | since as you say, it's hard enough to keep N sets of laws in your head |
| 2022-05-05 18:34:47 +0200 | <c_wraith> | Why make it worse? |
| 2022-05-05 18:35:12 +0200 | <Bulby[m]> | Pointed and Apply 😱 |
| 2022-05-05 18:35:13 +0200 | <Bulby[m]> | not real right |
| 2022-05-05 18:35:42 +0200 | <k`> | Anyway, getting back to my original question, what about `Copointed`. I'm honestly not sure how to mess that up, even if you do have `instance (Copointed m, Extend m)=> Comonad m` . |
| 2022-05-05 18:36:46 +0200 | <Bulby[m]> | k`: enum and bounded do something similar in its documentation |
| 2022-05-05 18:36:46 +0200 | <edwardk> | k` i can come up with Copointed and Extend instances for the same type that are incompatible. we've had them emerge in practice. |
| 2022-05-05 18:37:45 +0200 | <edwardk> | the scalaz community tried this at one point for the record. |
| 2022-05-05 18:37:54 +0200 | <k`> | edwardk: Good to know! What kind of problems? First vs last element? |
| 2022-05-05 18:38:34 +0200 | <edwardk> | Pointed still plays a role, but it is pretty hard to find useful instances. the main usecase that comes to mind is that a PointedFunctor is basically exactly what you want to quantify over for an 'affine traversal' |
| 2022-05-05 18:38:46 +0200 | <Bulby[m]> | there are types that in conjunction with other types require new the laws to be compatible |
| 2022-05-05 18:38:47 +0200 | <Bulby[m]> | not require, it's just a "law" |
| 2022-05-05 18:39:00 +0200 | <edwardk> | first vs. last. vs. something that gives you back an infinite container |
| 2022-05-05 18:39:29 +0200 | <k`> | So you extend, get an infinite container, copoint, and loop forever? |
| 2022-05-05 18:40:24 +0200 | <Bulby[m]> | What is a pointed? Is that `pure`? |
| 2022-05-05 18:40:41 +0200 | <c_wraith> | yes |
| 2022-05-05 18:41:04 +0200 | <Bulby[m]> | where does that term come from |
| 2022-05-05 18:41:12 +0200 | <edwardk> | it is easy to wind up with a set where you can pick a point in the set (pointed set), and another where you have a binary operation on the set (a magma), and not have magically picked the right point to be the unit of the magma when you stick those features together to get a unital magma, or that is the unit of the semigroup when you go to upgrade to a monoid. if you _only_ have the vocabulary for the operations and no vocabulary for the |
| 2022-05-05 18:41:12 +0200 | <edwardk> | laws, you easily step wrong when you expect those laws to hold |
| 2022-05-05 18:42:21 +0200 | <edwardk> | instance (Applicative f, Monoid a) => Monoid (f a) -- seems like a great idea until you go to realize it makes for a shit choice of monoid for [a], and precludes ever getting Maybe a to be the lifting of a semigroup with a fresh unit. |
| 2022-05-05 18:43:27 +0200 | <Bulby[m]> | Where does the term pointed come from? |
| 2022-05-05 18:43:33 +0200 | <k`> | That makes sense. |
| 2022-05-05 18:43:44 +0200 | <edwardk> | https://en.wikipedia.org/wiki/Pointed_set |
| 2022-05-05 18:43:55 +0200 | <edwardk> | a 'pointed functor' is the same idea |
| 2022-05-05 18:44:15 +0200 | dyeplexer | (~dyeplexer@user/dyeplexer) |
| 2022-05-05 18:44:30 +0200 | moonsheep | (~user@iespladelestany.xtec.cat) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)) |
| 2022-05-05 18:45:18 +0200 | <Bulby[m]> | so `pure` "preserves the point" |
| 2022-05-05 18:45:28 +0200 | <k`> | I've been wondering about the value of a 'lawless' class with `empty :: forall a. m a`, and it seems to do real well until you get to the possibility of somebody defining `empty = Const mempty`, when it needs to be `Const anihilatingElement` (with no inherent laws to tell you that). |
| 2022-05-05 18:46:14 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-39.elisa-laajakaista.fi) |
| 2022-05-05 18:46:34 +0200 | <k`> | Bulby[m]: But in practice, `point` often gets (mis)defined as `singleton`. |
| 2022-05-05 18:47:27 +0200 | <edwardk> | Bulby[m]: a functor maps objects to objects, and provides a mapping of arrows to arrows. a pointed functor, gives you a mapping pure :: a -> f a -- with the obvious laws connecting that to the arrows in the category. pure . f = fmap f . pure |
| 2022-05-05 18:47:27 +0200 | <Bulby[m]> | you can do whatever as long as it represents the input value? |
| 2022-05-05 18:47:39 +0200 | <edwardk> | fortunately the latter is a free theorem in haskell so we don't need to tie it down |
| 2022-05-05 18:48:12 +0200 | <edwardk> | so I don't even require it to be a Functor here, as there are Pointed structures that _aren't_ functors. e.g. Set |
| 2022-05-05 18:48:25 +0200 | <edwardk> | the problem with Pointed culturally is that it leads to folks doing things like foldMap point |
| 2022-05-05 18:48:28 +0200 | <edwardk> | er foldMap pure |
| 2022-05-05 18:48:31 +0200 | <edwardk> | what does that mean? |
| 2022-05-05 18:48:45 +0200 | <edwardk> | there's no law relating the monoid on 'f a' with the 'a' in any capacity |
| 2022-05-05 18:48:55 +0200 | <edwardk> | when f = [] vs. Maybe vs. Set you get TOTALLY unrelated answers |
| 2022-05-05 18:49:32 +0200 | <edwardk> | there's very little you can do parametrically in a given pointed functor usefully |
| 2022-05-05 18:49:44 +0200 | <k`> | So you need `getAlt . foldMap (Alt . pure)` |
| 2022-05-05 18:50:00 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-05-05 18:50:17 +0200 | <edwardk> | on the other hand, something that takes advantage of the 'associative' structure of say Applicative-without-pure, which is called 'Apply' in one of my packages, that? you can do lots with. |
| 2022-05-05 18:50:45 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-05-05 18:50:59 +0200 | <edwardk> | the issue is haskell is generally bad at making classes that mix two such general extension directions, class Functor f => Applicative f. is what we have today |
| 2022-05-05 18:51:11 +0200 | <k`> | (I'm still wishing that `Apply` would be slotted into the Functor hierarchy.) |
| 2022-05-05 18:51:13 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-05-05 18:51:33 +0200 | arjun | (~arjun@user/arjun) |
| 2022-05-05 18:51:33 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-05-05 18:51:48 +0200 | <edwardk> | but if we wanted class (Apply f, Pointed f) => Applicative f -- we'd be dealing with the fact that almsot all the uses of it would infer the weaker (Apply f, Pointed f) constraint set, despite generally needing the laws of Applicative that tell us the point is related to the <*> to be useful or canonical |
| 2022-05-05 18:52:30 +0200 | <edwardk> | so the best we can do is make new operations that have their own laws that re-export the ones from those superclasses in order to get inference to do the right thing |
| 2022-05-05 18:52:34 +0200 | <edwardk> | which is a bit of a mess |
| 2022-05-05 18:52:53 +0200 | dut | (~dut@user/dut) (Ping timeout: 260 seconds) |
| 2022-05-05 18:53:23 +0200 | <edwardk> | pure f <*> m = f <$> m -- works for Applicative, but not (Apply f, Pointed f) |
| 2022-05-05 18:54:56 +0200 | <k`> | So what are your thoughts on just saying "If it's also `Apply`, it must obey the law `pure f <*> mx = fmap f m`? |
| 2022-05-05 18:55:22 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-05 18:55:27 +0200 | <Bulby[m]> | what is a free theorm 😭 |
| 2022-05-05 18:56:00 +0200 | <geekosaur> | https://people.mpi-sws.org/~dreyer/tor/papers/wadler.pdf |
| 2022-05-05 18:56:20 +0200 | <k`> | Bulby[m]: I think basically if your instance isn't a GADT, it's guaranteed to be true because you can't care about the element type. |
| 2022-05-05 18:56:25 +0200 | <geekosaur> | it's a theorem that follows directly from a type |
| 2022-05-05 18:56:31 +0200 | <k`> | In this case. |
| 2022-05-05 18:57:00 +0200 | <sclv> | right. its a theorem about a function which holds for any function of that type, because any implementation that satisfies the type must satisfy the theorem. |
| 2022-05-05 18:57:01 +0200 | zeenk | (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) |
| 2022-05-05 18:57:35 +0200 | Guest|68 | (~Guest|68@144.48.23.93) |
| 2022-05-05 18:57:45 +0200 | econo | (uid147250@user/econo) |
| 2022-05-05 19:00:11 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-05-05 19:00:55 +0200 | <monochrom> | http://www.vex.net/~trebla/haskell/abs-type-param.html |
| 2022-05-05 19:01:23 +0200 | <k`> | In this case, unless you're using a GADT or create an illegal Functor, it's impossible for `fmap f (point x)` to be anything other than `point (f x)`. GADTs mess it up because your 'x :: a' could actually be restricted to 'x :: (Integer ~ a)=> a'. |
| 2022-05-05 19:01:53 +0200 | <Bulby[m]> | sorcery |
| 2022-05-05 19:03:59 +0200 | Guest|68 | (~Guest|68@144.48.23.93) (Quit: Connection closed) |
| 2022-05-05 19:07:09 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-05 19:08:00 +0200 | x_kuru | (~xkuru@user/xkuru) |
| 2022-05-05 19:11:33 +0200 | xkuru | (~xkuru@user/xkuru) (Ping timeout: 260 seconds) |
| 2022-05-05 19:12:52 +0200 | dzdcnfzd | (~dzdcnfzd@2600:387:5:807::73) (Quit: Client closed) |
| 2022-05-05 19:13:18 +0200 | euandreh | (~euandreh@2804:14c:33:9fe5:2165:73d6:1630:f174) (Ping timeout: 260 seconds) |
| 2022-05-05 19:17:28 +0200 | alx741 | (~alx741@host-181-198-243-150.netlife.ec) |
| 2022-05-05 19:17:30 +0200 | alx741 | (~alx741@host-181-198-243-150.netlife.ec) (Client Quit) |
| 2022-05-05 19:18:34 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-05-05 19:19:17 +0200 | alx741 | (~alx741@host-181-198-243-150.netlife.ec) |
| 2022-05-05 19:19:33 +0200 | alx741 | (~alx741@host-181-198-243-150.netlife.ec) (Client Quit) |
| 2022-05-05 19:19:33 +0200 | euandreh | (~euandreh@2804:14c:33:9fe5:2165:73d6:1630:f174) |
| 2022-05-05 19:23:58 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-05-05 19:25:37 +0200 | seydar | (~seydar@154-27-113-252.starry-inc.net) |
| 2022-05-05 19:26:31 +0200 | arjun | (~arjun@user/arjun) (Ping timeout: 256 seconds) |
| 2022-05-05 19:26:58 +0200 | amesgen[m] | (~amesgenm]@2001:470:69fc:105::82b) |
| 2022-05-05 19:28:19 +0200 | <seydar> | I'm having trouble translating some nested loops into Haskell |
| 2022-05-05 19:28:20 +0200 | <seydar> | https://paste.tomsmeding.com/VGyql1tq |
| 2022-05-05 19:30:18 +0200 | <seydar> | lines 53 and 63 are where I do some list comprehensions, and I feel like I'm getting them wrong, because when I swap the x and y declarations in line 63, I get a little bit closer to the right answer, but that's clearly not correct according to the C code |
| 2022-05-05 19:31:37 +0200 | <monochrom> | I think a toy example helps understand the general case. |
| 2022-05-05 19:31:56 +0200 | <monochrom> | > [(i, j) | i <- [0,1,2], j <- ['a', 'b', c']] |
| 2022-05-05 19:31:58 +0200 | <lambdabot> | error: |
| 2022-05-05 19:31:58 +0200 | <lambdabot> | • Variable not in scope: c' :: Char |
| 2022-05-05 19:31:58 +0200 | <lambdabot> | • Perhaps you meant one of these: |
| 2022-05-05 19:32:06 +0200 | <monochrom> | > [(i, j) | i <- [0,1,2], j <- ['a', 'b', 'c']] |
| 2022-05-05 19:32:08 +0200 | <lambdabot> | [(0,'a'),(0,'b'),(0,'c'),(1,'a'),(1,'b'),(1,'c'),(2,'a'),(2,'b'),(2,'c')] |
| 2022-05-05 19:32:12 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2022-05-05 19:32:29 +0200 | <monochrom> | It means that i is the outer loop. |
| 2022-05-05 19:32:45 +0200 | <dminuoso> | Also |
| 2022-05-05 19:33:03 +0200 | stackdroid18 | (14094@user/stackdroid) |
| 2022-05-05 19:33:53 +0200 | <seydar> | monochrom: right, i agree, which is why i'm confused as to why my answer gets closer to correct when i mislabel the loops |
| 2022-05-05 19:34:05 +0200 | <monochrom> | So the problem is elsewhere? |
| 2022-05-05 19:34:57 +0200 | <seydar> | I... don't know. I'm convinced that the problem is in the list comprehensions, since everything else seems to be right, but I know that the `bases` variable is ultimately wrong |
| 2022-05-05 19:35:02 +0200 | <monochrom> | "closer to correct (but still incorrect)" is code for very subtle and deep mistake. |
| 2022-05-05 19:35:47 +0200 | <seydar> | my individual `basis` function is correct, i've tested that out |
| 2022-05-05 19:36:05 +0200 | <seydar> | but then I'm unable to put together a larger `bases` list correctly |
| 2022-05-05 19:40:35 +0200 | <seydar> | okay, i've confirmed that `bases` is getting produced correctly. i've compared outputs with a 5x4 image instead of playing guessing games on a 1199x1198 image |
| 2022-05-05 19:41:23 +0200 | <monochrom> | And yet you can't argue against [(i, j) | i <- [0,1,2], j <- ['a', 'b', c']] = [(0,'a'),(0,'b'),(0,'c'),(1,'a'),(1,'b'),(1,'c'),(2,'a'),(2,'b'),(2,'c')] |
| 2022-05-05 19:41:33 +0200 | <monochrom> | So the problem is elseelseelsewhere? |
| 2022-05-05 19:42:16 +0200 | <monochrom> | Or a very hard to catch typo somewhere. |
| 2022-05-05 19:43:05 +0200 | <monochrom> | This is when you throw in a lot of Debug.Trace stuff or split code into more units to perform actually seriously unit testing. |
| 2022-05-05 19:43:08 +0200 | <seydar> | right, the C loop has x as the inner loop and y as the outer (lines 68 and 69 in the C), which matches the haskell (line 63) |
| 2022-05-05 19:43:08 +0200 | AlexNoo | (~AlexNoo@178.34.163.12) (Read error: Connection reset by peer) |
| 2022-05-05 19:43:51 +0200 | AlexNoo | (~AlexNoo@178.34.163.12) |
| 2022-05-05 19:44:37 +0200 | <monochrom> | Also, use smaller inputs so you get smaller outputs so you don't just gross over "this is close enough". |
| 2022-05-05 19:45:06 +0200 | <seydar> | you're right |
| 2022-05-05 19:45:15 +0200 | <seydar> | gonna switch it to be 1x1 components |
| 2022-05-05 19:45:21 +0200 | <monochrom> | Generally being a good scientist and using the scientific method. |
| 2022-05-05 19:46:01 +0200 | <seydar> | i prefer to commune with the code and see if there's some middle ground between what the compiler wants and what i want |
| 2022-05-05 19:46:27 +0200 | <seydar> | okay well turns out my code is wildly fucked up when i go to 1x1, so that's prolly a good place to start since it removes the problem of the list comprehension |
| 2022-05-05 19:49:08 +0200 | AlexNoo | (~AlexNoo@178.34.163.12) (Read error: Connection reset by peer) |
| 2022-05-05 19:49:40 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-05 19:49:54 +0200 | AlexNoo | (~AlexNoo@178.34.163.12) |
| 2022-05-05 19:52:26 +0200 | <seydar> | fixed it for 1x1 -- there was an unrelated bug that wasn't converting the linear pixels back to sRGB |
| 2022-05-05 19:53:32 +0200 | <seydar> | so now it's looking like the bug is back to the list comprehension part where i try to replicate nested loops |
| 2022-05-05 19:53:46 +0200 | <seydar> | is there a better, more haskelly way to do nested loops? |
| 2022-05-05 19:54:13 +0200 | <monochrom> | No. |
| 2022-05-05 19:54:41 +0200 | <monochrom> | Worse and less haskelly ways, plenty. |
| 2022-05-05 19:55:00 +0200 | agumonkey | (~user@88.163.231.79) |
| 2022-05-05 19:55:44 +0200 | <k`> | I usually end up writing `for t $ \ x -> ... for s $ \ y -> ...` -- probably worse and less Haskelly. |
| 2022-05-05 19:56:38 +0200 | <monochrom> | Are you sure you want "for" as opposed to "for_"? |
| 2022-05-05 19:56:57 +0200 | <k`> | Right, looping for effects only, `for_`. |
| 2022-05-05 19:57:34 +0200 | <monochrom> | But it's incomparable to the [(i, j) | i <- [0,1,2], j <- ['a', 'b', c']] kind. |
| 2022-05-05 19:58:35 +0200 | <monochrom> | So yes "for" is worse and less Haskelly than "for_" when effect-only. |
| 2022-05-05 19:59:12 +0200 | <k`> | I mean, you can also use `t >>= \ x -> ... s >>= \ y -> ...` when you need Monadic powers. |
| 2022-05-05 19:59:20 +0200 | crazazy | (~user@130.89.171.62) (Ping timeout: 248 seconds) |
| 2022-05-05 19:59:43 +0200 | <k`> | And I honestly can remember what list comprehension desurgars to `mzip`. |
| 2022-05-05 19:59:46 +0200 | <mrianbloom> | Is there an easy way to do size-type wrappers for arrays in Haskell? |
| 2022-05-05 20:00:36 +0200 | <mrianbloom> | These would be types that allow you to enforce that two arrays have the same dimensions. |
| 2022-05-05 20:00:57 +0200 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) |
| 2022-05-05 20:01:12 +0200 | raym | (~raym@user/raym) (Ping timeout: 246 seconds) |
| 2022-05-05 20:03:06 +0200 | raym | (~raym@user/raym) |
| 2022-05-05 20:07:26 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-05-05 20:08:27 +0200 | <EvanR> | you can use numbers at the type level, that's pretty easy |
| 2022-05-05 20:08:42 +0200 | <EvanR> | doing anything more than using numbers at the type level, ymmv xD |
| 2022-05-05 20:10:04 +0200 | MajorBiscuit | (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) (Quit: WeeChat 3.4) |
| 2022-05-05 20:10:42 +0200 | <EvanR> | https://hackage.haskell.org/package/sized-vector-1.4.3.1 |
| 2022-05-05 20:10:56 +0200 | <EvanR> | deprecated in favor of |
| 2022-05-05 20:14:31 +0200 | <juhp[m]> | geekosaur: I updated https://github.com/juhp/koji-tool/blob/main/src/Install.hs#L202 : I think it was indeed a missing do + some indentation issue, since I can't reproduce it again now |
| 2022-05-05 20:15:35 +0200 | <agumonkey> | he\\o |
| 2022-05-05 20:16:49 +0200 | <juhp[m]> | (it would be somewhere within the current last commit, but since corrected - I should have saved the broken code for reference) |
| 2022-05-05 20:19:55 +0200 | x_kuru_ | (~xkuru@user/xkuru) |
| 2022-05-05 20:21:29 +0200 | <juhp[m]> | Anyway has been some fun refactoring :-) |
| 2022-05-05 20:23:51 +0200 | x_kuru | (~xkuru@user/xkuru) (Ping timeout: 276 seconds) |
| 2022-05-05 20:24:49 +0200 | <sm> | "With this paper we have tried to convey that some domain-driven design concepts are applicable and beneficial to functional languages, even strongly typed ones like Haskell. Types don’t replace proper design or GHC would have been modular to begin with." |
| 2022-05-05 20:25:34 +0200 | hololeap_ | (~hololeap@user/hololeap) (Ping timeout: 240 seconds) |
| 2022-05-05 20:25:55 +0200 | <sm> | I guess hsyl isn't here, but.. this paper is a gem 💎 |
| 2022-05-05 20:26:03 +0200 | <sm> | https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf |
| 2022-05-05 20:26:29 +0200 | <mrianbloom> | thanks EvanR |
| 2022-05-05 20:27:46 +0200 | CiaoSen | (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-05-05 20:28:34 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2022-05-05 20:28:42 +0200 | hololeap_ | (~hololeap@user/hololeap) |
| 2022-05-05 20:32:05 +0200 | x_kuru | (~xkuru@user/xkuru) |
| 2022-05-05 20:32:09 +0200 | x_kuru_ | (~xkuru@user/xkuru) (Read error: Connection reset by peer) |
| 2022-05-05 20:34:14 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-05 20:34:16 +0200 | odnes | (~odnes@5-203-254-76.pat.nym.cosmote.net) |
| 2022-05-05 20:37:52 +0200 | kenran | (~kenran@200116b82b2708000a1d989028fc8790.dip.versatel-1u1.de) |
| 2022-05-05 20:39:08 +0200 | zeenk | (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) (Quit: Konversation terminated!) |
| 2022-05-05 20:42:25 +0200 | Inoperable | (~PLAYER_1@fancydata.science) (Quit: All your buffer are belong to us!) |
| 2022-05-05 20:43:40 +0200 | xaotuk | (~sasha@net224-32-245-109.mbb.telenor.rs) (Ping timeout: 260 seconds) |
| 2022-05-05 20:43:48 +0200 | alp_ | (~alp@user/alp) (Ping timeout: 248 seconds) |
| 2022-05-05 20:43:52 +0200 | Inoperable | (~PLAYER_1@fancydata.science) |
| 2022-05-05 20:45:31 +0200 | teddyc | (theodorc@cassarossa.samfundet.no) (Quit: WeeChat 3.0) |
| 2022-05-05 20:46:49 +0200 | dyeplexer | (~dyeplexer@user/dyeplexer) (Remote host closed the connection) |
| 2022-05-05 20:50:33 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2022-05-05 20:51:16 +0200 | hololeap_ | (~hololeap@user/hololeap) (Remote host closed the connection) |
| 2022-05-05 20:53:38 +0200 | spacenautx | (~spacenaut@user/spacenautx) (Quit: WeeChat 3.5) |
| 2022-05-05 20:55:33 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) |
| 2022-05-05 20:56:36 +0200 | hololeap_ | (~hololeap@user/hololeap) |
| 2022-05-05 21:03:12 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:6c7f:24ed:3788:2a1e) |
| 2022-05-05 21:04:23 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-05 21:05:45 +0200 | coot | (~coot@213.134.190.95) |
| 2022-05-05 21:06:16 +0200 | yauhsien | (~yauhsien@61-231-34-25.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-05 21:07:54 +0200 | mxs | (~mxs@user/mxs) (Remote host closed the connection) |
| 2022-05-05 21:08:02 +0200 | mxs | (~mxs@user/mxs) |
| 2022-05-05 21:13:12 +0200 | acidjnk | (~acidjnk@p200300d0c7068b43f1a15e75027d04fd.dip0.t-ipconnect.de) |
| 2022-05-05 21:14:31 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-05-05 21:16:52 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-05 21:18:07 +0200 | zero | zzz |
| 2022-05-05 21:21:42 +0200 | alp_ | (~alp@user/alp) |
| 2022-05-05 21:24:36 +0200 | mxs | (~mxs@user/mxs) (Remote host closed the connection) |
| 2022-05-05 21:24:45 +0200 | mxs | (~mxs@user/mxs) |
| 2022-05-05 21:25:35 +0200 | bahamas | (~lucian@84.232.141.55) |
| 2022-05-05 21:26:54 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 276 seconds) |
| 2022-05-05 21:27:07 +0200 | zer0bitz | (~zer0bitz@2001:2003:f444:8f00:98db:b5ce:843:b259) (Ping timeout: 256 seconds) |
| 2022-05-05 21:27:52 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-05 21:28:04 +0200 | hololeap_ | (~hololeap@user/hololeap) (Ping timeout: 240 seconds) |
| 2022-05-05 21:31:15 +0200 | hololeap_ | (~hololeap@user/hololeap) |
| 2022-05-05 21:31:39 +0200 | <maerwald> | sm: my opinion is that good design cannot happen up-front, unless you really do the same thing for the second time. Good codebases need a rewrite. I'd rather start with a monolith than with a very modular design, because a monolith is easier to grow and refactor. |
| 2022-05-05 21:32:19 +0200 | agumonkey | (~user@88.163.231.79) (Ping timeout: 256 seconds) |
| 2022-05-05 21:32:34 +0200 | <sm> | I agree on the first part, certainly |
| 2022-05-05 21:33:21 +0200 | <sm> | except for the kind of "obvious" design you can bring from experience with similar projects |
| 2022-05-05 21:33:44 +0200 | abhinav | (~abhinav@c-67-169-139-16.hsd1.ca.comcast.net) |
| 2022-05-05 21:34:01 +0200 | <maerwald> | with overly modular design you easily navigate yourself into "API locks", where you suddenly can't make drastical changes anymore. That is fine if you're confident that your module boundaries are correct. But if you're wrong about your boundaries, god help you |
| 2022-05-05 21:34:51 +0200 | abhinav | abhixec |
| 2022-05-05 21:34:51 +0200 | briandaed | (~briandaed@109.95.142.93.r.toneticgroup.pl) (Ping timeout: 260 seconds) |
| 2022-05-05 21:35:23 +0200 | quintasan | (~quassel@quintasan.pl) () |
| 2022-05-05 21:35:33 +0200 | quintasan | (~quassel@quintasan.pl) |
| 2022-05-05 21:35:35 +0200 | <sm> | well, I think it's assumed that boundaries are part of what you can change |
| 2022-05-05 21:35:59 +0200 | <maerwald> | but programmers don't like to be "wrong", so they get obsessed with up-front design and then do worse things |
| 2022-05-05 21:36:04 +0200 | quintasan | (~quassel@quintasan.pl) (Client Quit) |
| 2022-05-05 21:36:16 +0200 | quintasan | (~quassel@quintasan.pl) |
| 2022-05-05 21:36:36 +0200 | <sm> | and if not, that's of course a problem, ideally solvable but if not, to be worked around (as with all the "expedient, safe" fixes to ghc over the years) |
| 2022-05-05 21:37:22 +0200 | briandaed | (~briandaed@109.95.142.93.r.toneticgroup.pl) |
| 2022-05-05 21:37:46 +0200 | <sm> | often that's all we can afford at a point in time, or so it appears, but inevitably tech debt builds and eventually deeper cleanup is needed |
| 2022-05-05 21:37:55 +0200 | <maerwald> | "this codebase needs a rewrite" is a success story... it means the codebase has survived so long and is so popular, that it *deserves* a rewrite! |
| 2022-05-05 21:38:23 +0200 | <maerwald> | also, I'm not talking about GHC... I know nothing about it :) |
| 2022-05-05 21:38:23 +0200 | <sm> | agreed! |
| 2022-05-05 21:39:18 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-05 21:39:30 +0200 | <sm> | I know more after reading that paper ! might even understand some #ghc talk :) |
| 2022-05-05 21:41:14 +0200 | <dibblego> | <edwardk> Pointed still plays a role, but it is pretty hard to find useful instances. the main usecase that comes to mind is that a PointedFunctor is basically exactly what you want to quantify over for an 'affine traversal' |
| 2022-05-05 21:41:27 +0200 | <dibblego> | but what is the use-case for an affine traversal? |
| 2022-05-05 21:41:34 +0200 | hololeap_ | (~hololeap@user/hololeap) (Ping timeout: 240 seconds) |
| 2022-05-05 21:43:22 +0200 | <dminuoso> | AffineTraversal in the presence of Traversal is useful for the same reason that Maybe is useful in the presence of []/ |
| 2022-05-05 21:43:25 +0200 | xaotuk | (~sasha@net224-32-245-109.mbb.telenor.rs) |
| 2022-05-05 21:44:39 +0200 | hololeap_ | (~hololeap@user/hololeap) |
| 2022-05-05 21:47:14 +0200 | michalz | (~michalz@185.246.204.105) (Remote host closed the connection) |
| 2022-05-05 21:47:34 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 240 seconds) |
| 2022-05-05 21:47:39 +0200 | michalz | (~michalz@185.246.204.101) |
| 2022-05-05 21:48:04 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-05 21:48:24 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-05-05 21:48:31 +0200 | <darkling> | I'm new to Haskell, but what I'm having most trouble with at the moment is converting the marvellous new structures and intuitions into actual use-cases. |
| 2022-05-05 21:49:28 +0200 | abhixec | (~abhinav@c-67-169-139-16.hsd1.ca.comcast.net) (Remote host closed the connection) |
| 2022-05-05 21:50:25 +0200 | <darkling> | I'm mostly OK with the maths-centric approaches -- I trained as a mathematician -- but linking the way I'd write the code "normally" to this new strangely-named zoo of magic is proving tricky. |
| 2022-05-05 21:50:49 +0200 | <Cale> | hmm |
| 2022-05-05 21:51:06 +0200 | <geekosaur> | have you looked at _Real World Haskell_? |
| 2022-05-05 21:51:14 +0200 | <geekosaur> | @where rwh |
| 2022-05-05 21:51:14 +0200 | <lambdabot> | http://www.realworldhaskell.org/blog/ http://book.realworldhaskell.org/read/ |
| 2022-05-05 21:51:47 +0200 | <dminuoso> | Perhaps it might be useful to dispel the magic. Every bit of Haskell code can easily be inspected, and since evaluation amounts to just substituting for a definition - very much like in math - you can trivially follow code. |
| 2022-05-05 21:52:17 +0200 | <darkling> | Thanks. I'll add that to the reading list. I'm working through LYAH at the moment, in conjunction with "What I wish I knew when I started Haskell", and the Typeclassopedia, and a textbook on Category Theory. |
| 2022-05-05 21:53:14 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-05-05 21:53:44 +0200 | <darkling> | dminuoso: I'm overstating the magic part here. It's more that I can't (yet) use those tools as building blocks, so they appear to stand alone. |
| 2022-05-05 21:53:47 +0200 | <Cale> | darkling: I guess one thing you might start with is that a lot of imperative loops end up being frozen into lists |
| 2022-05-05 21:53:51 +0200 | odnes | (~odnes@5-203-254-76.pat.nym.cosmote.net) (Remote host closed the connection) |
| 2022-05-05 21:54:15 +0200 | odnes | (~odnes@5-203-254-76.pat.nym.cosmote.net) |
| 2022-05-05 21:54:19 +0200 | roconnor | (~roconnor@coq/roconnor) (Ping timeout: 240 seconds) |
| 2022-05-05 21:54:36 +0200 | <Cale> | Just as a loop either doesn't occur (e.g. because its loop condition isn't met), or it consists of a single iteration followed by another loop, a list is either empty, or consists of a single element followed by another list. |
| 2022-05-05 21:54:39 +0200 | <dminuoso> | darkling: Oh that. Just imagine this to be a natural language, its writing and reading that automatically builds up intuition. |
| 2022-05-05 21:54:55 +0200 | <darkling> | I've done quite a bit of Erlang, so I'm happy with the functional idioms. |
| 2022-05-05 21:54:57 +0200 | <Cale> | So, in some sense, lists are like "loops waiting to happen" |
| 2022-05-05 21:55:08 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-05 21:55:13 +0200 | <Cale> | (and especially so if they're lazy lists) |
| 2022-05-05 21:55:27 +0200 | <darkling> | The laziness is very attractive. :) |
| 2022-05-05 21:55:29 +0200 | <geekosaur> | I would also mention that category theory is not as useful as some claim |
| 2022-05-05 21:55:56 +0200 | <darkling> | geekosaur: I had the book a few years ago, independent of Haskell. This is just the impetus to read the book. |
| 2022-05-05 21:56:00 +0200 | <geekosaur> | knowing CT won't help you one bit with understanding IO, in particular |
| 2022-05-05 21:56:26 +0200 | <dminuoso> | darkling: Erlang is almost, but not quite, entirely unlike Haskell. |
| 2022-05-05 21:56:31 +0200 | <EvanR> | so you want to write hello world in haskell, let me first introduce you to javascript's callback system |
| 2022-05-05 21:56:48 +0200 | <Cale> | haha |
| 2022-05-05 21:56:50 +0200 | <darkling> | EvanR: Please, don't. $day_job is mostly JS/TS. :) |
| 2022-05-05 21:57:40 +0200 | <dminuoso> | 21:54:56 Cale | So, in some sense, lists are like "loops waiting to happen" |
| 2022-05-05 21:57:48 +0200 | <dminuoso> | I file this under "monad tutorial fallacy" |
| 2022-05-05 21:58:01 +0200 | <Cale> | hm? |
| 2022-05-05 21:58:03 +0200 | <darkling> | dminuoso: I've already done the brain jump from imperative to functional, though. :) |
| 2022-05-05 21:58:33 +0200 | <Cale> | darkling: I guess I'm confused about your original question in that case |
| 2022-05-05 21:58:39 +0200 | odnes | (~odnes@5-203-254-76.pat.nym.cosmote.net) (Client Quit) |
| 2022-05-05 21:59:03 +0200 | <Cale> | Did you have specific Haskell gadgets that you wanted a use-case for? |
| 2022-05-05 21:59:29 +0200 | <geekosaur> | there are still jumps to be made, though. I came in knowing enough SML/NJ to be able to understand programs written in it, but laziness and IO still made for a huge jump needed |
| 2022-05-05 21:59:29 +0200 | <dminuoso> | Cale: So thinking of lists as loops is an intution that we develop after we already understand how to use them. It's similar to "Monads are Burritos", it's an intuition that only helps if you already understand it. |
| 2022-05-05 22:00:09 +0200 | <Cale> | dminuoso: Well, that was the conclusion of a very specific analogy I was making, though perhaps it requires examples to really get. |
| 2022-05-05 22:00:11 +0200 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2022-05-05 22:00:17 +0200 | <Cale> | (but darkling already seems familiar) |
| 2022-05-05 22:00:24 +0200 | <EvanR> | I knew about lazy wrappers in scheme, that made haskell not seem like a cold turkey |
| 2022-05-05 22:00:55 +0200 | <geekosaur> | I don't think that's necessarily true, dminuoso. I mean, what do you do with a list in any language? You loop over it |
| 2022-05-05 22:00:57 +0200 | <dminuoso> | Cale: Right, Im not sure examples really suffice. Without being very comfortable with laziness, Im not convinced most beginners would get the gist of it. |
| 2022-05-05 22:01:03 +0200 | <geekosaur> | in Hasekll that's the whole point of a list |
| 2022-05-05 22:01:05 +0200 | <Cale> | I will say that there are a lot of libraries of general abstract nonsense on Hackage that I would rarely or never use. |
| 2022-05-05 22:01:44 +0200 | <Cale> | (but others that I would) |
| 2022-05-05 22:02:00 +0200 | <darkling> | Cale: There's a lot made of the Functor/Applicative/Monad stuff, but I'm finding it hard to see where those things fit into the way I'd do things without them. |
| 2022-05-05 22:02:10 +0200 | <dminuoso> | geekosaur: They are also very useful for other things like random access, keeping a bag of things - if your list implementation has nice asymptotics and ergonomics for that interface. |
| 2022-05-05 22:02:29 +0200 | <Cale> | darkling: Ah, are you familiar with the general concept of a combinator library? |
| 2022-05-05 22:02:34 +0200 | <darkling> | Maybe I just need to practice the basic language without them and then spot the patterns where they'd help reduce mess/boilerplate. |
| 2022-05-05 22:02:38 +0200 | <dminuoso> | In Haskell they dont, which means the "loopy interface" is way more prominent, simply because you cant do much else with it if you intend to scale |
| 2022-05-05 22:02:50 +0200 | <dminuoso> | And that might not be so obvious in other languages |
| 2022-05-05 22:03:06 +0200 | <sm> | darkling: maybe it's a good time for a tour through some practical haskell code bases ? |
| 2022-05-05 22:03:12 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:6c7f:24ed:3788:2a1e) (Quit: WeeChat 2.8) |
| 2022-05-05 22:03:17 +0200 | <dminuoso> | In Haskell we actively construct lists for the purpose of deconstructing element by element, you rarely do this in most common traditional languages |
| 2022-05-05 22:03:25 +0200 | <darkling> | Cale: Not entirely. I've brushed around the concept of combinators in (IIRC) lambda calculus, but never looked into it in detail. |
| 2022-05-05 22:03:38 +0200 | <geekosaur> | we need an updated RWH that covers things like pandoc and hledger |
| 2022-05-05 22:03:44 +0200 | <darkling> | I was a mathematician, not a formal computer scientist (despite lecturing as the latter). |
| 2022-05-05 22:04:03 +0200 | <darkling> | All the CS I know is autodidactic. |
| 2022-05-05 22:04:22 +0200 | <k`> | darkling: You could just take a look at how Text.ParserCombinators.ReadP does parsing. |
| 2022-05-05 22:04:36 +0200 | <Cale> | darkling: Ah, this "combinator" is in a less technical sense. The idea is that you build a library where you start with a bunch of basic building block computations of some type, they may even be too simple to be useful on their own, and then you have a bunch of operations for combining them in various ways. |
| 2022-05-05 22:05:12 +0200 | <sm> | ("practice the basic language and spot the patterns" is good too) |
| 2022-05-05 22:05:17 +0200 | <EvanR> | code reuse in haskell is better than normal, and people blame how the basic nuts and bolts like lists and eithers are "very dumb" |
| 2022-05-05 22:05:42 +0200 | <EvanR> | there's like no room for interpretation and so incompatible "cleverness" to proliferate |
| 2022-05-05 22:05:46 +0200 | <Cale> | darkling: Functor/Applicative/Monad capture patterns that frequently arise when you're building libraries in that style |
| 2022-05-05 22:06:05 +0200 | <geekosaur> | http://book.realworldhaskell.org/read/using-parsec.html |
| 2022-05-05 22:06:14 +0200 | <geekosaur> | nice use of combinators |
| 2022-05-05 22:06:16 +0200 | <EvanR> | darkling, I was trying to respond to your thing about boilerplate but then the phone wrong |
| 2022-05-05 22:06:20 +0200 | <EvanR> | rang |
| 2022-05-05 22:07:49 +0200 | <Cale> | For example, in the case of parsers, you might have a parametric type (Parser t) of parsers whose result(s) will have type t |
| 2022-05-05 22:08:35 +0200 | <Cale> | and then that will be an instance of Functor, because if we have a function (a -> b), we can apply that function to the results of a parser of type Parser a to obtain a parser of type Parser b |
| 2022-05-05 22:10:01 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 248 seconds) |
| 2022-05-05 22:10:17 +0200 | <darkling> | If I've understood, that's the kind of thing where my immediate reaction is to first execute the Parser a to get an a, and then run the a -> b over that result. |
| 2022-05-05 22:10:56 +0200 | <darkling> | But with the Functor, you can manipulate the Parser a directly to get the Parser b as a stand-alone thing. |
| 2022-05-05 22:11:46 +0200 | <darkling> | So it's kind of an associative flip: transform(parse(input)) to (transform.parse)(input). |
| 2022-05-05 22:13:16 +0200 | <Cale> | Yeah, depending on how the parser itself is encoded, it might be more or less involved. But with some of the simplest functional representations of parsers, it will be little more than function composition with a bit of dressing around it. |
| 2022-05-05 22:14:04 +0200 | hololeap_ | (~hololeap@user/hololeap) (Ping timeout: 240 seconds) |
| 2022-05-05 22:14:05 +0200 | <darkling> | That puts the tool (Functor) in a much better context, where I feel I could actually use one. :) |
| 2022-05-05 22:14:40 +0200 | <Cale> | If we look at Monad, it'll provide us with return :: a -> Parser a which will construct a parser that consumes none of the input, but immediately returns the given value as its (sole) result |
| 2022-05-05 22:14:59 +0200 | <Cale> | as well as (>>=) :: Parser a -> (a -> Parser b) -> Parser b |
| 2022-05-05 22:15:01 +0200 | <k`> | Then up from Functor, Applicative lets you combine the results of two parsers or make a dummy parser that produces a result purely (without consuming input). |
| 2022-05-05 22:15:06 +0200 | <Cale> | which will take a parser that has results of type a |
| 2022-05-05 22:15:17 +0200 | <Cale> | and a function from values of type a to parsers with results of type b |
| 2022-05-05 22:15:52 +0200 | <Cale> | and it will glue those together in the sensible way: making a parser which runs the first parser to get a value of type a, then applies the function to decide which parser to run next, and run that on whatever is left of the input |
| 2022-05-05 22:16:42 +0200 | <Cale> | This sort of "deciding what to do next based on the result of a previous computation" is what characterises monads in this setting. |
| 2022-05-05 22:17:30 +0200 | <darkling> | And that's the ordering dependency that's the intuition of the do-construct? |
| 2022-05-05 22:17:35 +0200 | <Cale> | Yeah |
| 2022-05-05 22:18:22 +0200 | hololeap_ | (~hololeap@user/hololeap) |
| 2022-05-05 22:19:01 +0200 | Guest1767 | (~Polo@user/polo) |
| 2022-05-05 22:19:10 +0200 | Guest1767 | (~Polo@user/polo) (Client Quit) |
| 2022-05-05 22:19:11 +0200 | <maerwald> | well, applicative also decides on what to do next, in a sense, except not for the effect flow |
| 2022-05-05 22:19:43 +0200 | <maerwald> | just for the values |
| 2022-05-05 22:20:07 +0200 | kenran | (~kenran@200116b82b2708000a1d989028fc8790.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2022-05-05 22:20:13 +0200 | <darkling> | I think I should stop now, before my brain overflows. |
| 2022-05-05 22:20:36 +0200 | <Cale> | Yeah, you can't wholesale decide what happens next with applicative, it's just that one computation gets to decide how to transform the result of another (but both are happening regardless of the results) |
| 2022-05-05 22:20:36 +0200 | <darkling> | But many thanks for the conversation, ladies and gentlemen. I'm sure I'll be back. |
| 2022-05-05 22:21:22 +0200 | <darkling> | I probably need to read through this conversation again tomorrow, and see if I can advance the rest of the reading based on it. |
| 2022-05-05 22:21:52 +0200 | <Cale> | Yeah, this is the kind of thing that really you need 5 or 10 examples before you truly get it. |
| 2022-05-05 22:22:13 +0200 | <maerwald> | yeah... with monad you can decide which parser to pick based on the previous value, with applicative the parsers you run are pre-defined |
| 2022-05-05 22:23:02 +0200 | <Cale> | (i.e. different whole libraries that use the same operations, but do completely different things with them) |
| 2022-05-05 22:23:28 +0200 | emanon42 | (~emanon42@103.120.19.44) |
| 2022-05-05 22:23:30 +0200 | mixfix41 | (~sdenyninn@user/mixfix41) |
| 2022-05-05 22:25:32 +0200 | <seydar> | yo this Debug.Trace thing is pretty cool |
| 2022-05-05 22:25:37 +0200 | <seydar> | i feel so dirty using it |
| 2022-05-05 22:25:42 +0200 | gpncarl | (~gpncarl@120.244.220.74) |
| 2022-05-05 22:25:45 +0200 | <EvanR> | it's quite impure |
| 2022-05-05 22:27:21 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) |
| 2022-05-05 22:29:45 +0200 | gpncarl | (~gpncarl@120.244.220.74) (Ping timeout: 248 seconds) |
| 2022-05-05 22:30:47 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-05 22:32:33 +0200 | Polo | (~Polo@user/polo) |
| 2022-05-05 22:32:36 +0200 | <Cale> | It's really useful for extracting the arguments to a pure function in the case that something is going wrong (and the arguments are hard to guess), and then from there you can work out why it's producing an incorrect result. |
| 2022-05-05 22:33:08 +0200 | briandaed | (~briandaed@109.95.142.93.r.toneticgroup.pl) (Remote host closed the connection) |
| 2022-05-05 22:36:59 +0200 | <darkling> | There's a lot to be said for a bunch of carefully-placed printfs. :) |
| 2022-05-05 22:39:54 +0200 | coot | (~coot@213.134.190.95) |
| 2022-05-05 22:43:10 +0200 | Polo | (~Polo@user/polo) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-05-05 22:48:04 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 248 seconds) |
| 2022-05-05 22:49:11 +0200 | <sm> | seydar: it's an essential haskell dev tool, nothing to be ashamed of. You may want to add pretty-simple or pretty-show later |
| 2022-05-05 22:53:25 +0200 | teddyc | (theodorc@cassarossa.samfundet.no) |
| 2022-05-05 22:56:39 +0200 | <seydar> | sm: ooh, good tip, thank you |
| 2022-05-05 22:56:47 +0200 | <seydar> | what IO does trace* write to? |
| 2022-05-05 22:57:03 +0200 | <seydar> | it doesn't appear to be writing to stdout or stderr |
| 2022-05-05 22:57:06 +0200 | <seydar> | unless i'm high |
| 2022-05-05 22:57:12 +0200 | <sm> | stderr |
| 2022-05-05 22:57:19 +0200 | <sm> | some more ideas at https://hackage.haskell.org/package/hledger-lib-1.25/docs/Hledger-Utils-Debug.html |
| 2022-05-05 22:59:06 +0200 | <seydar> | weird, i am unable to redirect 2>&1 the way i'd expect to |
| 2022-05-05 22:59:37 +0200 | <EvanR> | wouldn't that have no effect usually |
| 2022-05-05 22:59:44 +0200 | <EvanR> | still prints out |
| 2022-05-05 23:01:19 +0200 | <sm> | eh.. you're writing 2>&1 at the right place (towards the end of the command line) ? bash is weird with that |
| 2022-05-05 23:01:48 +0200 | <geekosaur> | what exactly are you doing and what are you expecting? |
| 2022-05-05 23:02:00 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-05-05 23:02:12 +0200 | <seydar> | `ghc Encode && ./Encode cat.jpg 2>&1 hs.out` |
| 2022-05-05 23:02:23 +0200 | <seydar> | i'm expecting my output to all go to hs.out |
| 2022-05-05 23:02:30 +0200 | <Clint> | then you have the syntax wrong |
| 2022-05-05 23:02:53 +0200 | <geekosaur> | first off, you did not redirect into hs,out so it won't be stdout |
| 2022-05-05 23:03:24 +0200 | <geekosaur> | second off, 2>&1 must follow a redirection of stdout, otherwise you redirect stderr to the old stdout and then redirect stdout to a different place |
| 2022-05-05 23:03:42 +0200 | <sm> | aHA |
| 2022-05-05 23:03:46 +0200 | <seydar> | AHHH |
| 2022-05-05 23:05:21 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2022-05-05 23:05:33 +0200 | sm | remembers a command line is a small stateful procedural program |
| 2022-05-05 23:06:12 +0200 | zyklotomic | (~ethan@res380d-128-61-84-187.res.gatech.edu) (Ping timeout: 248 seconds) |
| 2022-05-05 23:08:06 +0200 | zyklotomic | (~ethan@res388d-128-61-89-205.res.gatech.edu) |
| 2022-05-05 23:08:37 +0200 | <seydar> | https://paste.tomsmeding.com/IXOwurpv |
| 2022-05-05 23:08:38 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 250 seconds) |
| 2022-05-05 23:08:47 +0200 | <seydar> | i'm getting output that i don't expect. namely, things aren't happening in the order that i'd expect |
| 2022-05-05 23:09:02 +0200 | <seydar> | i'd expect a tuple followed by 20 floats |
| 2022-05-05 23:09:21 +0200 | <seydar> | going from (0, 0) -> (0, 1) -> (1, 0) -> (1, 1) |
| 2022-05-05 23:09:26 +0200 | <sm> | welcome to the wacky world of haskell lazy evaluation |
| 2022-05-05 23:09:29 +0200 | <seydar> | but that is not at _all_ what's happening |
| 2022-05-05 23:09:46 +0200 | <darkling> | There's no synchronisation guarantee between stdout and stderr -- both can be buffered. |
| 2022-05-05 23:10:16 +0200 | <seydar> | darkling: that is good to know, but all relevant output here is going to STDERR, so i don't think that's the issue |
| 2022-05-05 23:10:21 +0200 | <darkling> | You pretty much always have to interpret the two streams' outputs with a certain amount of fuzz. |
| 2022-05-05 23:11:02 +0200 | <geekosaur> | or set NoBuffering on both |
| 2022-05-05 23:11:20 +0200 | <darkling> | If it's all going to the same stream, then it should be properly ordered, but I guess sm's observation takes over here, and "properly ordered" still has unexpected results. |
| 2022-05-05 23:11:44 +0200 | <seydar> | how do i make something eager? |
| 2022-05-05 23:12:05 +0200 | <sm> | a simple way is to print it |
| 2022-05-05 23:12:06 +0200 | <geekosaur> | not guaranteed if you did it via redirection, because each Handle is still buffered independently even if they end up writing to the same place |
| 2022-05-05 23:12:41 +0200 | <sm> | (not trace it) |
| 2022-05-05 23:13:29 +0200 | <seydar> | sm: dammit, now i have to copy everything and move it to an IO () function |
| 2022-05-05 23:14:23 +0200 | <sm> | ie, using print in the IO monad. There's also `seq`, deepseq, and such like |
| 2022-05-05 23:14:28 +0200 | <geekosaur> | also, sadly, GNU stdbuf doesn't work on haskell programs because they don't use glibc's buffering stuff |
| 2022-05-05 23:14:56 +0200 | <sm> | when you're just debugging, the lazy ordering usually isn't a big problem, in fact it gives good insight into program execution |
| 2022-05-05 23:15:08 +0200 | <sm> | labeling the values can help |
| 2022-05-05 23:15:32 +0200 | <EvanR> | % let x = trace "foo" 1; y = trace "bar" 2 in (x,y) |
| 2022-05-05 23:15:40 +0200 | <geekosaur> | no yahb still |
| 2022-05-05 23:15:46 +0200 | <EvanR> | YAAAAAHB |
| 2022-05-05 23:16:13 +0200 | <sm> | if you really want guaranteed definite ordered output, then that's logging and yes requires IO |
| 2022-05-05 23:16:13 +0200 | <geekosaur> | no mniip still. hope they're enjoying their vacation or whatever |
| 2022-05-05 23:16:30 +0200 | <geekosaur> | (hoping it's that and not, say, a hospital stay) |
| 2022-05-05 23:17:04 +0200 | hololeap_ | (~hololeap@user/hololeap) (Ping timeout: 240 seconds) |
| 2022-05-05 23:17:06 +0200 | geekosaur | wonders if there are enough pieces in mniip's github to assemble a new yahb |
| 2022-05-05 23:17:30 +0200 | <EvanR> | if tony stark dies, no one is iron man |
| 2022-05-05 23:17:57 +0200 | <EvanR> | (spoiler alert) |
| 2022-05-05 23:18:25 +0200 | <geekosaur> | I found the bot core there and the sandboxing stuff, but I don't think it has how to glue them together into a yahb |
| 2022-05-05 23:19:27 +0200 | <EvanR> | mniip's biosignature unlocks a hidden vault which release autoscripts to glue all the pieces together onto them (or whoever can fake access) |
| 2022-05-05 23:19:36 +0200 | <geekosaur> | (or even how to sandbox a ghci) |
| 2022-05-05 23:21:28 +0200 | hololeap_ | (~hololeap@user/hololeap) |
| 2022-05-05 23:23:55 +0200 | eraziel | (~eraziel@modemcable169.17-58-74.mc.videotron.ca) |
| 2022-05-05 23:24:03 +0200 | <seydar> | "traceShow (y, x) `seq` traceShowId bases" did not have the effect i thought it would. only the second trace statement was executed |
| 2022-05-05 23:25:58 +0200 | <monochrom> | (Mixing up conversations) So yahb is Iron Man??!! |
| 2022-05-05 23:27:19 +0200 | <sm> | welcome to the second level of the wacky world of haskell lazy evaluation! |
| 2022-05-05 23:27:46 +0200 | <sm> | replace seq with $ there I think |
| 2022-05-05 23:28:37 +0200 | <eraziel> | what's a good way to ensure a small chunk of code runs uninterrupted ? doing this right now `finally (pure ()) thingIdLikeToRunUninterrupted` |
| 2022-05-05 23:28:50 +0200 | <eraziel> | the `pure ()` part seems off |
| 2022-05-05 23:30:12 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-05-05 23:30:28 +0200 | <monochrom> | Yeah this one seems to be a simple misunderstanding of traceShow. Consider giving it two arguments. |
| 2022-05-05 23:30:29 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-05 23:30:31 +0200 | <EvanR> | before you complain that yahb was autonomous and could be commanded by anybody here, iron man has automated clones |
| 2022-05-05 23:31:34 +0200 | <monochrom> | Ooohhh!!! So yahb is Jarvis... |
| 2022-05-05 23:32:37 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-05-05 23:32:38 +0200 | gensyst | (gensyst@user/gensyst) (Quit: Leaving) |
| 2022-05-05 23:34:20 +0200 | <seydar> | okay so it looks like all of my life's woes come from the fact that i can't get the ordering right in this list comprehension |
| 2022-05-05 23:34:33 +0200 | <seydar> | it is ordering... non-deterministically |
| 2022-05-05 23:35:10 +0200 | <seydar> | it is ordering deterministically according to an unknown god |
| 2022-05-05 23:35:41 +0200 | <sm> | trace more things to see what the heck it's doing |
| 2022-05-05 23:35:42 +0200 | <darkling> | Did you forget to feed the shoggoths? |
| 2022-05-05 23:36:34 +0200 | hololeap_ | (~hololeap@user/hololeap) (Ping timeout: 240 seconds) |
| 2022-05-05 23:37:27 +0200 | <seydar> | sm: this is the result of my tracing |
| 2022-05-05 23:37:27 +0200 | Katarushisu | (~Katarushi@cpc147334-finc20-2-0-cust27.4-2.cable.virginm.net) (Quit: The Lounge - https://thelounge.chat) |
| 2022-05-05 23:37:30 +0200 | <EvanR> | yeah don't confuse non-determinism with "not what I thought I ordered" |
| 2022-05-05 23:38:06 +0200 | Katarushisu | (~Katarushi@cpc147334-finc20-2-0-cust27.4-2.cable.virginm.net) |
| 2022-05-05 23:38:09 +0200 | <monochrom> | Ugh list comprehension data order is orthogonal to evaluate order if that's what you mean. |
| 2022-05-05 23:38:46 +0200 | <monochrom> | Or rather s/data order/linked list order/ |
| 2022-05-05 23:39:20 +0200 | <seydar> | okay i don't think this is the source of my bug |
| 2022-05-05 23:39:30 +0200 | hololeap_ | (~hololeap@user/hololeap) |
| 2022-05-05 23:39:40 +0200 | <sm> | I'd trace more till it makes sense. Things get evaluated when needed and not before, This is often surprising to a human |
| 2022-05-05 23:40:02 +0200 | <EvanR> | unless the human was raised by lazy wolves or something |
| 2022-05-05 23:41:02 +0200 | <sm> | unless raised by lazy wolves 🐺 |
| 2022-05-05 23:41:02 +0200 | <seydar> | what's that eager version of haskell called? |
| 2022-05-05 23:41:07 +0200 | emanon42 | (~emanon42@103.120.19.44) (Quit: The Lounge - https://thelounge.chat) |
| 2022-05-05 23:41:22 +0200 | <EvanR> | purescript |
| 2022-05-05 23:43:18 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-05 23:43:21 +0200 | emanon42 | (~emanon42@103.120.19.44) |
| 2022-05-05 23:43:25 +0200 | <monochrom> | sm: The context is effectless pure code that processes lists and number crunching, the observation is that the resulting numbers are wrong and/or the numbers are in a wrong order in the resulting lists. Lazy evaluation could be seen as nondeterministic but not to the point of being nondeterminitic in answers, we are not talking about unsafeInterleaveIO. |
| 2022-05-05 23:43:30 +0200 | <seydar> | time for my favorite game: bug or floating point error |
| 2022-05-05 23:44:10 +0200 | <EvanR> | floating point problem between chair and keyboard |
| 2022-05-05 23:44:25 +0200 | <monochrom> | I did suggest using Debug.Trace but the purpose was to observe and check intermediate numbers, not to confuse wrong numbers with wrong evaluation order. |
| 2022-05-05 23:44:42 +0200 | <seydar> | monochrom: this new level of hell is all thanks to Debug.Trace |
| 2022-05-05 23:44:47 +0200 | <sm> | ah, thanks |
| 2022-05-05 23:45:10 +0200 | <EvanR> | you realize purity was instituted because otherwise laziness would be ridiculous |
| 2022-05-05 23:45:12 +0200 | <monochrom> | This case needs zero understanding of evaluation orders. It doesn't matter at all. |
| 2022-05-05 23:45:56 +0200 | <EvanR> | but really Debug.Trace is really very mild in terms of side effects |
| 2022-05-05 23:46:12 +0200 | <seydar> | monochrom: i'm coming around to that conclusion. i just had a moment of public panic |
| 2022-05-05 23:48:27 +0200 | <dibblego> | dminuoso: show me the use-case |
| 2022-05-05 23:49:09 +0200 | <seydar> | also you guys aren't gonna believe this but the evaluation order that i thought was crazy actually makes perfect sense |
| 2022-05-05 23:49:17 +0200 | <dibblego> | (also, I have heard the []/Maybe argument before and after analysis, typically the claimant learns that it is not a good argument -- there are better arguments, though they also still fail) |
| 2022-05-05 23:49:38 +0200 | zeenk | (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) |
| 2022-05-05 23:50:05 +0200 | <sm> | welcome to level 3! |
| 2022-05-05 23:51:16 +0200 | <EvanR> | you're dangerously close to being unable to return to normal programming languages |
| 2022-05-05 23:52:24 +0200 | <EvanR> | you can go back once you get to level 6 |
| 2022-05-05 23:52:27 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-05 23:52:31 +0200 | Polo | (~Polo@user/polo) |
| 2022-05-05 23:53:05 +0200 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-05-05 23:55:39 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-05-05 23:56:33 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-05-05 23:58:01 +0200 | <seydar> | i like the cthulu^H^H^H^H^H^Hhaskell forces you to write top-down |
| 2022-05-05 23:58:57 +0200 | <seydar> | i'm reading some C code right now and constantly asking "what are you trying to say" |
| 2022-05-05 23:59:04 +0200 | Topsi | (~Topsi@dyndsl-037-138-064-083.ewe-ip-backbone.de) (Read error: Connection reset by peer) |