| 2022-12-08 00:00:20 +0100 | <huskle> | oh ffs! |
| 2022-12-08 00:00:30 +0100 | <huskle> | there were two random seed creations |
| 2022-12-08 00:00:41 +0100 | <huskle> | and i only put one of them to generate strictly positive seeds |
| 2022-12-08 00:00:44 +0100 | <huskle> | it works now!@ |
| 2022-12-08 00:02:44 +0100 | srk- | (~sorki@user/srk) |
| 2022-12-08 00:03:25 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 00:05:55 +0100 | srk | (~sorki@user/srk) (Ping timeout: 260 seconds) |
| 2022-12-08 00:05:56 +0100 | srk- | srk |
| 2022-12-08 00:07:42 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-12-08 00:09:28 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-12-08 00:09:41 +0100 | <masterbuilder> | Do you guys think "What I wish I knew When Learning Haskell" is a good introductory book? For somebody not unfamiliar with FP, the Haskell book felt very slow at least in the beginning |
| 2022-12-08 00:10:22 +0100 | <huskle> | https://paste.tomsmeding.com/78JboB5O |
| 2022-12-08 00:10:33 +0100 | <huskle> | totally more excellent! |
| 2022-12-08 00:10:42 +0100 | <huskle> | can i have good marks on my assignment? |
| 2022-12-08 00:11:16 +0100 | <huskle> | masterbuilder: maybe you are used to VR books which are more fast paced |
| 2022-12-08 00:11:40 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-12-08 00:12:07 +0100 | <monochrom> | https://www.google.com/search?q=wish+knew+haskell already exist and is not big enough to be a book. |
| 2022-12-08 00:12:11 +0100 | <EvanR> | it's funny how generics, reflection, and polymorphism means something totally different depending on language |
| 2022-12-08 00:12:30 +0100 | <masterbuilder> | huskle: what is a VR book? |
| 2022-12-08 00:12:48 +0100 | <EvanR> | like they took concepts and scrambled them with a group theory table |
| 2022-12-08 00:12:49 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-12-08 00:13:14 +0100 | <huskle> | masterbuilder: like a regular book except blasted through your mind with ladar |
| 2022-12-08 00:13:22 +0100 | <EvanR> | then ruby added literal "concepts" |
| 2022-12-08 00:13:30 +0100 | <huskle> | lidar* |
| 2022-12-08 00:13:32 +0100 | <huskle> | whatever it is |
| 2022-12-08 00:13:35 +0100 | <monochrom> | "equality, fairness" mean totally opposite things to opposite people, too. :) |
| 2022-12-08 00:13:42 +0100 | <huskle> | blasted through your mind is the important part |
| 2022-12-08 00:13:44 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 00:13:49 +0100 | <huskle> | never mind how they combine the lazers and radar |
| 2022-12-08 00:13:53 +0100 | festive_kurbus | (~festive_k@user/kurbus) (Quit: Client closed) |
| 2022-12-08 00:14:34 +0100 | <huskle> | both of which have `a' in the second charicter so iv no idea why its called lidar and not ladar |
| 2022-12-08 00:14:45 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 00:14:48 +0100 | <masterbuilder> | huskle: Lol, well idk, I just want something that talks about the challenging aspects of Haskell and yet is not an "advanced book", the syntax is familiar to me but I still lack many fundamentals probably |
| 2022-12-08 00:15:22 +0100 | <EvanR> | maybe you're ready to tackle A Gentle Introduction xD |
| 2022-12-08 00:15:30 +0100 | <masterbuilder> | seems like the haskell book is meant to be a first programming book almost, which is fine |
| 2022-12-08 00:15:38 +0100 | <masterbuilder> | EvanR: anything but? |
| 2022-12-08 00:15:46 +0100 | <EvanR> | I thought it was pretty tame |
| 2022-12-08 00:15:54 +0100 | <EvanR> | but had already read SICP |
| 2022-12-08 00:16:06 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) (Quit: opticblast) |
| 2022-12-08 00:16:09 +0100 | <huskle> | masterbuilder: there are no challenging parts of haskell, this is an uncommon misconception |
| 2022-12-08 00:16:20 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) |
| 2022-12-08 00:16:23 +0100 | <huskle> | everyone knows haskell is the central language in computing |
| 2022-12-08 00:16:25 +0100 | <geekosaur> | it does things like jump into pattern matching assuming you already know what it is |
| 2022-12-08 00:16:35 +0100 | <masterbuilder> | the type system is a bit more elaborate than most languages |
| 2022-12-08 00:16:38 +0100 | <mauke> | https://www.haskell.org/tutorial/index.html this one? |
| 2022-12-08 00:16:40 +0100 | <huskle> | thats why lisp was based on it originally before they made C++ |
| 2022-12-08 00:16:42 +0100 | <monochrom> | I wouldn't say learning Haskell is easy. But I wouldn't say learning any programming at all is easy either. |
| 2022-12-08 00:17:02 +0100 | <monochrom> | I could say though that some instant-gratification languages sugar-coat it. |
| 2022-12-08 00:17:13 +0100 | <huskle> | the type system is fine... |
| 2022-12-08 00:17:23 +0100 | <huskle> | most languages dont have one. this is not fine |
| 2022-12-08 00:17:38 +0100 | <EvanR> | lisp was based on what before who made C++ |
| 2022-12-08 00:17:45 +0100 | <monochrom> | More generally, as in everything in life, the greatest challenge is expectation management. |
| 2022-12-08 00:17:46 +0100 | <mauke> | having a unitype is still a system |
| 2022-12-08 00:17:50 +0100 | <EvanR> | I can't complete that thought |
| 2022-12-08 00:18:01 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-12-08 00:18:02 +0100 | <huskle> | i mean, your probably not going to start writting associated type families strait away |
| 2022-12-08 00:18:03 +0100 | <masterbuilder> | well I don't know anything about type/cat theory, any books that explore those through haskell? |
| 2022-12-08 00:18:11 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-12-08 00:18:16 +0100 | <huskle> | or wondering why the hell your not allowed to make instances on data families |
| 2022-12-08 00:18:41 +0100 | <huskle> | masterbuilder: yeah, the stuff by van larhoven or whatever he's called |
| 2022-12-08 00:18:48 +0100 | <mauke> | masterbuilder: don't know about books, but there's a series of video lectures on youtube |
| 2022-12-08 00:18:49 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2022-12-08 00:18:50 +0100 | <monochrom> | There is a "math and logic through haskell" book. |
| 2022-12-08 00:18:56 +0100 | <huskle> | bartoz |
| 2022-12-08 00:19:02 +0100 | <mauke> | masterbuilder: category theory by bartosz milewski |
| 2022-12-08 00:19:05 +0100 | <huskle> | https://bartoszmilewski.com/2021/04/01/traversals-1-van-laarhoven-and-existentials/ |
| 2022-12-08 00:19:17 +0100 | <EvanR> | I went through a lot of bartosz and never got to the part where programming came up |
| 2022-12-08 00:19:24 +0100 | <monochrom> | And yeah there are bartoz lectures and articles explaining cat theory in programmer terms. |
| 2022-12-08 00:19:30 +0100 | <huskle> | its crazyness |
| 2022-12-08 00:19:36 +0100 | <huskle> | why would anyone ask for that!? |
| 2022-12-08 00:19:39 +0100 | <EvanR> | just like I went through a lot of intro category theory and never got to any applications xD |
| 2022-12-08 00:19:41 +0100 | <monochrom> | not haskell-specific but certainly FP-specific. |
| 2022-12-08 00:19:48 +0100 | <huskle> | its the kind of stuff we basically resent edkmett associating us to |
| 2022-12-08 00:19:59 +0100 | <huskle> | hes all profunctors this and yoneda that |
| 2022-12-08 00:20:12 +0100 | money_ | (~money@user/polo) |
| 2022-12-08 00:20:18 +0100 | <huskle> | im like "wheres my biplate!?" |
| 2022-12-08 00:20:56 +0100 | <masterbuilder> | thanks for the links |
| 2022-12-08 00:20:59 +0100 | <monochrom> | I don't resent that. |
| 2022-12-08 00:21:07 +0100 | <EvanR> | yoneda dawg I heard you like functors in your functors |
| 2022-12-08 00:21:16 +0100 | <huskle> | i do! i had to bloody describe stacks ffs! |
| 2022-12-08 00:21:36 +0100 | <huskle> | https://ncatlab.org/nlab/show/Deligne-Mumford+stack |
| 2022-12-08 00:21:59 +0100 | <monochrom> | What I resent is how humans have polarized extremist opinions either way. |
| 2022-12-08 00:22:05 +0100 | srk- | (~sorki@user/srk) |
| 2022-12-08 00:22:21 +0100 | <masterbuilder> | in terms of books that get you writing haskell and learning the language without boring you though, is the gentle introduction the best option? |
| 2022-12-08 00:22:32 +0100 | <huskle> | i hate how elon musk isnt allowed to say he'll kill all his detractors |
| 2022-12-08 00:22:35 +0100 | <EvanR> | I like it for just getting to the point |
| 2022-12-08 00:22:38 +0100 | <monochrom> | Why do grown-ups still act like hormonized teenagers "this is the worst thing ever!" "this is the best thing ever!". |
| 2022-12-08 00:22:48 +0100 | srk | (~sorki@user/srk) (Ping timeout: 268 seconds) |
| 2022-12-08 00:22:50 +0100 | <huskle> | because we are on drugs! |
| 2022-12-08 00:22:53 +0100 | <masterbuilder> | I can write some basic haskell programs but I can't say I really understand the language in any meaningful way |
| 2022-12-08 00:23:02 +0100 | <huskle> | its called DDS |
| 2022-12-08 00:23:17 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-12-08 00:23:19 +0100 | <huskle> | https://en.wikipedia.org/wiki/Dopamine_dysregulation_syndrome |
| 2022-12-08 00:23:30 +0100 | <EvanR> | masterbuilder, well maybe you want to look into the denotational semantics or into the compiler intermediate languages for "more" |
| 2022-12-08 00:23:33 +0100 | <monochrom> | I think the gentle introduction is not boring. |
| 2022-12-08 00:23:46 +0100 | <huskle> | you should have more compassion, not everone is mentally capable of neutrality |
| 2022-12-08 00:24:02 +0100 | <masterbuilder> | EvanR: oof I tried to get into denotational semantics once, kind of dense |
| 2022-12-08 00:24:08 +0100 | <masterbuilder> | but interesting |
| 2022-12-08 00:24:09 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-12-08 00:24:21 +0100 | <monochrom> | I think someone did opine that, though, HPFFP is drawn out, therefore boring. >:) |
| 2022-12-08 00:24:39 +0100 | <EvanR> | dense is often what I complain about youtube videos not being |
| 2022-12-08 00:24:47 +0100 | srk- | srk |
| 2022-12-08 00:24:48 +0100 | <EvanR> | they're quite diluted these days |
| 2022-12-08 00:25:07 +0100 | <EvanR> | give me a high dose of information please |
| 2022-12-08 00:25:08 +0100 | michalz | (~michalz@185.246.204.77) (Remote host closed the connection) |
| 2022-12-08 00:25:24 +0100 | <monochrom> | Yeah I can pause when I need to. |
| 2022-12-08 00:25:56 +0100 | <monochrom> | Stop being entertaining. Just get to the point already. |
| 2022-12-08 00:26:37 +0100 | <huskle> | im starting a study into predicting structural activity relationships in a functional reactive model of the brain... if anyones interested |
| 2022-12-08 00:26:46 +0100 | <huskle> | based on some earlier work on sloppy modeling |
| 2022-12-08 00:26:59 +0100 | <huskle> | in the words of box "all models are wrong, but some are useful" |
| 2022-12-08 00:27:06 +0100 | <hpc> | monochrom: don't you know #haskell encourages pointfree style? :D |
| 2022-12-08 00:27:13 +0100 | <monochrom> | hahaha |
| 2022-12-08 00:28:32 +0100 | <monochrom> | My useful model is: people's minds have a backend that's more than 70% correct, and a not-gate as the frontend. |
| 2022-12-08 00:28:33 +0100 | <huskle> | did you know that certain serotonin receptors are hypothesized to work by mediating the activity at dopamine receptors? |
| 2022-12-08 00:28:48 +0100 | <hpc> | (also i still kind of like LYAH - it doesn't have any exercises, but i always felt those were too artificial for me to really want to do anyway) |
| 2022-12-08 00:28:54 +0100 | <huskle> | you have enough of that going on and you end up with an overdetermined system |
| 2022-12-08 00:29:21 +0100 | <huskle> | so we want to resparsify it, to get an effective model for the brain chemistry more conducive for denovo drug design |
| 2022-12-08 00:29:31 +0100 | <monochrom> | I come up with my own exercises. |
| 2022-12-08 00:30:18 +0100 | <hpc> | yeah, the best exercises are just having something of your own that you're motiviated to solve |
| 2022-12-08 00:30:24 +0100 | <monochrom> | But I'm scientific-method minded, I treat my understanding as hypotheses so I test them, even try to refute them. There are my exercises. |
| 2022-12-08 00:30:35 +0100 | <huskle> | its a big graph of up/down regulation, and its too big and needs pruning. basically, and rotating. not using "a quotient stack of a scheme over the étale site all whose automorphism groups are finite groups" |
| 2022-12-08 00:30:36 +0100 | <hpc> | ah, that's different from me |
| 2022-12-08 00:30:38 +0100 | <sm> | ha.. I asked chatgpt to condense HPFFP into six pages for me, it spun a while then kicked me out |
| 2022-12-08 00:30:50 +0100 | <monochrom> | haha |
| 2022-12-08 00:31:00 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-12-08 00:31:10 +0100 | <monochrom> | I think six pages is unfair though. I think 200 pages is more fair. |
| 2022-12-08 00:31:26 +0100 | eudjhsh | (~nsanos@94.142.179.159) |
| 2022-12-08 00:31:35 +0100 | eudjhsh | (~nsanos@94.142.179.159) () |
| 2022-12-08 00:32:30 +0100 | <huskle> | recently was desgned a class of drugs called dopamine disinhibitors, for people with parkisnons-like symptoms |
| 2022-12-08 00:32:35 +0100 | <sm> | I think it is having a meltdown |
| 2022-12-08 00:32:45 +0100 | <huskle> | what, your gpt3 bot? |
| 2022-12-08 00:32:52 +0100 | <huskle> | maybe you need to treat it better |
| 2022-12-08 00:33:04 +0100 | <huskle> | stop trying to feed it hormones or whatever your doing to it |
| 2022-12-08 00:33:07 +0100 | <sm> | the chatgpt AI generally |
| 2022-12-08 00:33:28 +0100 | <sm> | it was just a little summary, no big deal |
| 2022-12-08 00:33:40 +0100 | <monochrom> | Author: C. Allen, J. Moronuki, and ChatGPT. Title: HPFFPfromHPFFP. |
| 2022-12-08 00:33:47 +0100 | <huskle> | thats why elon had to fire all the twitter birds, because they were messing up the codebase with latte's |
| 2022-12-08 00:33:59 +0100 | <huskle> | and complacency |
| 2022-12-08 00:34:19 +0100 | <sm> | it's probably working through all the exercises and getting stuck on tooling issues |
| 2022-12-08 00:34:41 +0100 | <huskle> | the reprecussions of all the moderation glitches could have caused an outbreak of unfettered jibbering |
| 2022-12-08 00:35:12 +0100 | <monochrom> | ChatGPT learned lambda calculus and discovered the Y combinator and played with it and is still in the infinite loop... :) |
| 2022-12-08 00:35:16 +0100 | <huskle> | and we would all end up living in Lanarks "Unthank", which i think is based on glasgow |
| 2022-12-08 00:36:10 +0100 | <huskle> | monochrom: i know! and it was using curly braces! it had to be stopped! |
| 2022-12-08 00:38:21 +0100 | <huskle> | all the neural-link satalites were going to fall out the sky! |
| 2022-12-08 00:39:13 +0100 | <sm> | off topic but.. after seeing a few examples and using chatgpt3 a little myself... suddenly I am expecting all software to understand my natural language... it's quite jarring |
| 2022-12-08 00:39:54 +0100 | <hpc> | i don't even expect humans to understand my natural language :P |
| 2022-12-08 00:40:07 +0100 | <sm> | maybe it was like this when early text adventurers first played an infocom game |
| 2022-12-08 00:40:28 +0100 | bobbingbob | (~dfadsva@2604:3d09:207f:f650::7b3a) (Ping timeout: 260 seconds) |
| 2022-12-08 00:41:07 +0100 | <EvanR> | oh I threw so much nonsense at zork |
| 2022-12-08 00:41:21 +0100 | <EvanR> | command interpreters have only gone down hill from there |
| 2022-12-08 00:42:14 +0100 | <huskle> | In book three, Lanark cannot remember his past, and so in the prologue (at the end of book three) Lanark asks an oracle to tell him who he is, with the oracle stating he will tell him about Duncan Thaw. This ends book one and takes the reader to Thaw's story, thereby suggesting that Thaw and Lanark are perhaps the same person. There are also marked |
| 2022-12-08 00:42:14 +0100 | <huskle> | similarities between Unthank and Glasgow, again suggesting that both places are the same. Both localities are dystopian and both are ultimately apocalyptic for the characters - ending in destruction and death. |
| 2022-12-08 00:44:49 +0100 | <huskle> | any (if not all) of the other denizens of Unthank suffer from similar literal |
| 2022-12-08 00:44:49 +0100 | <huskle> | manifestations of their psychic-affective maladies; Lanark comes to find, sometimes to his |
| 2022-12-08 00:44:50 +0100 | <huskle> | horror, that each person he encounters is diseased. Each of these physically corresponds to |
| 2022-12-08 00:44:50 +0100 | <huskle> | something that is broken about their emotional state, but unlike Thaw/Lanark, I am only able to |
| 2022-12-08 00:44:51 +0100 | <huskle> | make conjecture about the childhood etiology of other characters’ diseases, and so will be |
| 2022-12-08 00:44:51 +0100 | <huskle> | positioning my interpretation squarely in their affect and in their politicized bodies. Likewise, |
| 2022-12-08 00:44:52 +0100 | <huskle> | Lanark’s etiology is both in Thaw’s childhood and the events that led up to his suicide, as well as |
| 2022-12-08 00:44:52 +0100 | <huskle> | his political body in the semi-dystopia of Unthank. |
| 2022-12-08 00:45:18 +0100 | <huskle> | its about as much gibberish as the original |
| 2022-12-08 00:45:28 +0100 | <huskle> | adios amigos! |
| 2022-12-08 00:45:32 +0100 | huskle | (~huskle@250.79-105-213.static.virginmediabusiness.co.uk) (Quit: Connection closed) |
| 2022-12-08 00:48:15 +0100 | tomokojun | (~tomokojun@static-198-54-134-86.cust.tzulo.com) (Remote host closed the connection) |
| 2022-12-08 00:48:30 +0100 | crazazy` | (~user@130.89.173.127) |
| 2022-12-08 00:48:34 +0100 | tomokojun | (~tomokojun@static-198-54-134-86.cust.tzulo.com) |
| 2022-12-08 00:49:16 +0100 | <EvanR> | what just happened |
| 2022-12-08 00:49:36 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 00:50:33 +0100 | crazazy | (~user@130.89.171.62) (Ping timeout: 268 seconds) |
| 2022-12-08 00:50:42 +0100 | Lears | (~Leary]@user/Leary/x-0910699) |
| 2022-12-08 00:50:52 +0100 | <monochrom> | tangent :) |
| 2022-12-08 00:51:02 +0100 | money | polo |
| 2022-12-08 00:51:03 +0100 | <monochrom> | This is what's wrong with compassion. |
| 2022-12-08 00:51:04 +0100 | [Leary] | (~Leary]@user/Leary/x-0910699) (Write error: Broken pipe) |
| 2022-12-08 00:53:01 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-12-08 00:55:29 +0100 | zant1 | (~zant@62.214.20.26) |
| 2022-12-08 01:00:28 +0100 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-12-08 01:00:47 +0100 | polo | money |
| 2022-12-08 01:01:29 +0100 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) |
| 2022-12-08 01:02:38 +0100 | Guest75 | (~Guest75@192.46.237.51) (Ping timeout: 260 seconds) |
| 2022-12-08 01:03:23 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) |
| 2022-12-08 01:03:45 +0100 | son0p | (~ff@2604:3d08:5b7f:5540::a58f) |
| 2022-12-08 01:05:31 +0100 | <sm> | Resist the AIs' mind waves, do not propagate their gospel of confusion. Clarity! Sobriety! Humanity! |
| 2022-12-08 01:12:17 +0100 | dsrt^ | (~dsrt@76.145.185.103) |
| 2022-12-08 01:12:51 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:4198:e7b5:35c5:87c6) |
| 2022-12-08 01:13:57 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:4198:e7b5:35c5:87c6) (Client Quit) |
| 2022-12-08 01:14:35 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a767ca9aed60fa8d1f2.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-12-08 01:26:00 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:3354:8194:6cd8:a3c2) |
| 2022-12-08 01:26:40 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:3354:8194:6cd8:a3c2) () |
| 2022-12-08 01:28:48 +0100 | <EvanR> | so a list is 1 + t + t^2 + t^3 + ... |
| 2022-12-08 01:29:06 +0100 | <EvanR> | the derivative of this is 0 + 1 + 2t + 3t^2 + 4t^3 + ... |
| 2022-12-08 01:29:22 +0100 | <EvanR> | which is list * (1 + 2 + 3 + 4 + ...), what the hell is this factor |
| 2022-12-08 01:30:02 +0100 | <monochrom> | No, not list * (1 + 2 + 3 + 4 + ...) |
| 2022-12-08 01:30:16 +0100 | <EvanR> | oh bad math |
| 2022-12-08 01:30:32 +0100 | <EvanR> | list * list ? |
| 2022-12-08 01:31:27 +0100 | tremon | (~tremon@83-84-18-241.cable.dynamic.v4.ziggo.nl) (Quit: getting boxed in) |
| 2022-12-08 01:32:09 +0100 | <monochrom> | Yeah. |
| 2022-12-08 01:32:33 +0100 | <monochrom> | But the zipper differentiation is not doing that. |
| 2022-12-08 01:32:54 +0100 | <monochrom> | Err, wait, maybe it does. |
| 2022-12-08 01:35:29 +0100 | <jackdk> | https://www.slideshare.net/JayCoskey/zippers-derivatives-of-regular-types see slides 7 and 8, but I don't remember my differentiation well enough to see how it all works |
| 2022-12-08 01:39:00 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2022-12-08 01:42:24 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:6f8b:1377:1cdb:d8cd) |
| 2022-12-08 01:43:00 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:6f8b:1377:1cdb:d8cd) () |
| 2022-12-08 01:44:33 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-12-08 01:45:34 +0100 | <EvanR> | yeah they take a shortcut through actual calculus with the 1/(1-x) trick |
| 2022-12-08 01:45:43 +0100 | <EvanR> | which is hilarious |
| 2022-12-08 01:45:46 +0100 | zant1 | (~zant@62.214.20.26) (Ping timeout: 256 seconds) |
| 2022-12-08 01:47:11 +0100 | <jackdk> | every derivation of list zippers via differentiation does this, and I've never seen it explained in detail |
| 2022-12-08 01:47:37 +0100 | zant1 | (~zant@62.214.20.26) |
| 2022-12-08 01:47:53 +0100 | <EvanR> | list * list = (1 + t + t^2 + ...) squared... |
| 2022-12-08 01:48:42 +0100 | <EvanR> | that plus that times t, plus that times t^2, plus... |
| 2022-12-08 01:48:58 +0100 | <EvanR> | ok that adds up to 1 + 2t + 3t^2 + ... |
| 2022-12-08 01:49:05 +0100 | <EvanR> | cool |
| 2022-12-08 01:49:58 +0100 | <EvanR> | that results in a type that can be used as one hole contexts |
| 2022-12-08 01:51:04 +0100 | <EvanR> | but what is this one hole context really, is it like splitting the list into two parts, or is it the original list with 1 item missing, and you have to pair that item to get a zipper, in addition to the two lists |
| 2022-12-08 01:51:17 +0100 | geekosaur | scans back and notes that he would not particularly expect either clarity or sobriety from humans… |
| 2022-12-08 01:51:56 +0100 | <EvanR> | if it's just two parts, does this mean the derivative type always contains some form of sensible substructure of what goes in the hole |
| 2022-12-08 01:52:34 +0100 | <EvanR> | I mean, unless you take the derivative of Bool or something and get Void |
| 2022-12-08 01:52:34 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:7966:11d5:2610:f5db) |
| 2022-12-08 01:53:08 +0100 | zant1 | (~zant@62.214.20.26) (Ping timeout: 256 seconds) |
| 2022-12-08 01:54:44 +0100 | jargon_ | (~jargon@174-22-192-24.phnx.qwest.net) |
| 2022-12-08 01:55:50 +0100 | jargon | (~jargon@184.101.177.18) (Ping timeout: 260 seconds) |
| 2022-12-08 01:59:03 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:7966:11d5:2610:f5db) (Quit: WeeChat 3.7.1) |
| 2022-12-08 01:59:45 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:7966:11d5:2610:f5db) |
| 2022-12-08 02:00:30 +0100 | crazazy` | (~user@130.89.173.127) (Ping timeout: 256 seconds) |
| 2022-12-08 02:02:08 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:7966:11d5:2610:f5db) (Client Quit) |
| 2022-12-08 02:02:22 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:7966:11d5:2610:f5db) |
| 2022-12-08 02:02:41 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:7966:11d5:2610:f5db) () |
| 2022-12-08 02:05:56 +0100 | Maeda_ | (~Maeda@91-161-10-149.subs.proxad.net) (Ping timeout: 248 seconds) |
| 2022-12-08 02:06:02 +0100 | <iqubic> | what's going on here? I'm a very confused girl. |
| 2022-12-08 02:06:45 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:7966:11d5:2610:f5db) |
| 2022-12-08 02:07:04 +0100 | ericsagnes | (~ericsagne@2405:6580:8a0:1e00:7966:11d5:2610:f5db) (Client Quit) |
| 2022-12-08 02:07:09 +0100 | cods | (~fred@82-65-232-44.subs.proxad.net) (Ping timeout: 260 seconds) |
| 2022-12-08 02:07:21 +0100 | cods | (~fred@82-65-232-44.subs.proxad.net) |
| 2022-12-08 02:07:38 +0100 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) |
| 2022-12-08 02:07:55 +0100 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) |
| 2022-12-08 02:08:14 +0100 | <geekosaur> | I'm not sure anyone else is less confused |
| 2022-12-08 02:08:56 +0100 | <geekosaur> | trying to decipher http://strictlypositive.org/diff.pdf |
| 2022-12-08 02:09:37 +0100 | mvk | (~mvk@2607:fea8:5ce3:8500::efb) |
| 2022-12-08 02:09:39 +0100 | mvk | (~mvk@2607:fea8:5ce3:8500::efb) (Client Quit) |
| 2022-12-08 02:09:42 +0100 | <EvanR> | yeah, coming from one direction you have zipper data structure and how that works for something not as trivial as a list, coming from the other direction "the derivative of a type is its type of one hole contexts" (mcbride paper) |
| 2022-12-08 02:09:47 +0100 | geekosaur | worked his way through the paper once and thought he sort-of understood it… |
| 2022-12-08 02:09:51 +0100 | <EvanR> | they collide somewhere and it works |
| 2022-12-08 02:10:21 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-12-08 02:10:56 +0100 | <geekosaur> | (it's somehow extending type algebra to type calculus) |
| 2022-12-08 02:11:58 +0100 | <iqubic> | I know what a zipper is, but I don't understand what that paper is doing. |
| 2022-12-08 02:12:12 +0100 | <geekosaur> | the point being, neither does anyone else 🙂 |
| 2022-12-08 02:12:12 +0100 | iqubic | is a very confused lady indeed. |
| 2022-12-08 02:12:16 +0100 | aliosablack | (~chomwitt@2a02:587:7a0c:6a00:1ac0:4dff:fedb:a3f1) (Ping timeout: 252 seconds) |
| 2022-12-08 02:12:33 +0100 | <iqubic> | Do you think Coner McBride understands the paper? |
| 2022-12-08 02:13:31 +0100 | <geekosaur> | probably, but that doesn't guarantee anyone else does. zippers are useful but how you get them from that is … not entirely clear |
| 2022-12-08 02:13:49 +0100 | <geekosaur> | much less how you get them for things like trees, which are harder to differentiate |
| 2022-12-08 02:14:16 +0100 | <geekosaur> | or at least harder to interpret the derivative in terms of one-hole contexts |
| 2022-12-08 02:14:44 +0100 | <iqubic> | Yeah... I don't know what that paper is doing. I'm not gonna be able to help you. |
| 2022-12-08 02:14:49 +0100 | <geekosaur> | I am not very mathy and haven't touched differentiation since 1983 |
| 2022-12-08 02:14:53 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-12-08 02:14:53 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-12-08 02:14:53 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-12-08 02:16:28 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-12-08 02:16:28 +0100 | <albet70> | c_wraith , it is >>= not >> in the docs |
| 2022-12-08 02:16:44 +0100 | Luj39 | (~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) |
| 2022-12-08 02:16:56 +0100 | RemiYuko | (~licht@user/akechishiro) (Ping timeout: 246 seconds) |
| 2022-12-08 02:17:10 +0100 | Luj3 | (~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) (Ping timeout: 252 seconds) |
| 2022-12-08 02:17:10 +0100 | Luj39 | Luj3 |
| 2022-12-08 02:17:32 +0100 | <sclv> | people understand the abstract combinatorics of species, and it turns out this stuff with types is a special case of it |
| 2022-12-08 02:17:51 +0100 | RemiYuko | (~licht@user/akechishiro) |
| 2022-12-08 02:17:59 +0100 | <c_wraith> | albet70: sure, but (x >> y) is (x >>= \_ -> y), so what you want is a direct consequence |
| 2022-12-08 02:18:27 +0100 | <c_wraith> | albet70: it's just a couple substitutions to rewrite it |
| 2022-12-08 02:21:17 +0100 | tomokojun | (~tomokojun@static-198-54-134-86.cust.tzulo.com) (Quit: じゃあね〜。) |
| 2022-12-08 02:28:09 +0100 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) (Ping timeout: 260 seconds) |
| 2022-12-08 02:28:13 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 252 seconds) |
| 2022-12-08 02:40:32 +0100 | king_gs | (~Thunderbi@187.201.204.122) |
| 2022-12-08 02:49:12 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-12-08 02:49:50 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2022-12-08 02:50:56 +0100 | king_gs | (~Thunderbi@187.201.204.122) (Ping timeout: 256 seconds) |
| 2022-12-08 02:52:05 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-12-08 02:52:55 +0100 | califax | (~califax@user/califx) |
| 2022-12-08 02:53:26 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:556e:28e8:6695:53e8) (Remote host closed the connection) |
| 2022-12-08 02:53:44 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:556e:28e8:6695:53e8) |
| 2022-12-08 02:55:50 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-12-08 02:59:25 +0100 | king_gs | (~Thunderbi@187.201.204.122) |
| 2022-12-08 03:00:00 +0100 | mncheck | (~mncheck@193.224.205.254) (Ping timeout: 256 seconds) |
| 2022-12-08 03:04:23 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 264 seconds) |
| 2022-12-08 03:04:39 +0100 | notzmv | (~zmv@user/notzmv) |
| 2022-12-08 03:06:31 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-12-08 03:14:37 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-12-08 03:17:00 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 256 seconds) |
| 2022-12-08 03:19:43 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2022-12-08 03:20:52 +0100 | <EvanR> | ok yeah, there is an actual hole. The sub structure that was where the hole is isn't in the derivative |
| 2022-12-08 03:22:00 +0100 | <EvanR> | if t(x) = (x,x,x) = x^3, t' = 3x^2 = (3, x, x). Two of the x and a Trool to tell you which one is missing |
| 2022-12-08 03:22:47 +0100 | <EvanR> | the 1 + 2x + 3x^2 + 4x^3 + ... is saying the same thing but for any number of elements |
| 2022-12-08 03:23:48 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-12-08 03:34:02 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-12-08 03:34:16 +0100 | codaraxis__ | (~codaraxis@user/codaraxis) |
| 2022-12-08 03:34:51 +0100 | <iqubic> | Are we still talking about derivatives of data types? |
| 2022-12-08 03:34:53 +0100 | <iqubic> | Are we still talking about derivatives of data types? |
| 2022-12-08 03:36:24 +0100 | codaraxis | (~codaraxis@user/codaraxis) (Ping timeout: 260 seconds) |
| 2022-12-08 03:36:50 +0100 | <EvanR> | the singular we, I guess |
| 2022-12-08 03:36:57 +0100 | money_ | (~money@user/polo) (Quit: money_) |
| 2022-12-08 03:38:32 +0100 | codaraxis__ | (~codaraxis@user/codaraxis) (Ping timeout: 256 seconds) |
| 2022-12-08 03:44:27 +0100 | <monochrom> | Are we still asking about what we're talking about? >:) |
| 2022-12-08 03:45:41 +0100 | king_gs | (~Thunderbi@187.201.204.122) (Ping timeout: 268 seconds) |
| 2022-12-08 03:46:54 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 260 seconds) |
| 2022-12-08 03:50:35 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-12-08 03:50:49 +0100 | <Lears> | I haven't read the paper, but I think the idea is relatively straightforward to implement in practice without any algebraic tricks. E.g. `data Tree a = Empty | Leaf a | Branch (Tree a) (Tree a)` ==> Tree x = 1 + x + Tree x * Tree x ==> Tree' x = 0 + 1 + Tree' x * Tree x + Tree x * Tree' x ==> `data TreeContext a = OnEmpty !Void | OnLeaf | OnLeftBranch (TreeContext a) (Tree a) | OnRightBranch (Tree a) (TreeContext a)` |
| 2022-12-08 03:50:51 +0100 | razetime | (~quassel@49.207.203.213) |
| 2022-12-08 03:51:55 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt https://tinyurl.com/4m8d4kd5) |
| 2022-12-08 03:53:13 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-12-08 03:55:27 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-12-08 03:55:43 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:556e:28e8:6695:53e8) (Remote host closed the connection) |
| 2022-12-08 03:56:02 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:556e:28e8:6695:53e8) |
| 2022-12-08 03:58:10 +0100 | <Lears> | s/(TreeContext a)/!(TreeContext a)/ in the branch fields, I guess. Then if we have `data StrictPair a b = StrictPair !a !b`, `StrictPair a (TreeContext a)` should "do the right thing" re `Empty`. |
| 2022-12-08 04:00:08 +0100 | <iqubic> | Yeah, implementing a zipper is easy. Doing the math is hard. |
| 2022-12-08 04:00:54 +0100 | <Lears> | What is "the math" here beyond the trivial differentiation steps in the middle? |
| 2022-12-08 04:01:33 +0100 | <Lears> | Unless you mean writing the paper to demonstrate the notion in general. |
| 2022-12-08 04:01:34 +0100 | <EvanR> | I feel the urge to take "What's the problem?!" to your demonstration xD |
| 2022-12-08 04:01:40 +0100 | <EvanR> | tack* |
| 2022-12-08 04:01:53 +0100 | <EvanR> | but yeah it's making sense now |
| 2022-12-08 04:02:20 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-12-08 04:02:48 +0100 | <EvanR> | the part where the 1-hole context of a list, given above as a series, becomes 2 lists via analytics is like... a weird side-show, funny but distracting |
| 2022-12-08 04:03:27 +0100 | hueso | (~root@user/hueso) (Ping timeout: 260 seconds) |
| 2022-12-08 04:03:34 +0100 | <iqubic> | How do you take the derivative of a list? What does that look like? |
| 2022-12-08 04:03:55 +0100 | <c_wraith> | you convert the type to algebraic form, then take the derivative of that. |
| 2022-12-08 04:03:57 +0100 | <EvanR> | first the list type is list(x) = 1 + x * list(x) |
| 2022-12-08 04:04:16 +0100 | <iqubic> | Where does the 1 come from? Is that Nil? |
| 2022-12-08 04:04:23 +0100 | <EvanR> | to avoid the side-show, lets rewrite it as 1 + x + x^2 + x^3 + ... |
| 2022-12-08 04:04:32 +0100 | <iqubic> | Yeah, that makes sense. |
| 2022-12-08 04:04:41 +0100 | <EvanR> | yeah 1 is unit or () |
| 2022-12-08 04:04:53 +0100 | <EvanR> | it stands for empty list |
| 2022-12-08 04:05:44 +0100 | <EvanR> | and now you can take the derivative |
| 2022-12-08 04:05:52 +0100 | <iqubic> | A list is either the empty list (1), 1 element (x^1) or 2 elements (x^2), or 3 (x^3) all the way up to N elements (x^n). |
| 2022-12-08 04:06:07 +0100 | <EvanR> | or N+1 elements, and so on |
| 2022-12-08 04:06:48 +0100 | <iqubic> | Yeah... |
| 2022-12-08 04:07:30 +0100 | hueso | (~root@user/hueso) |
| 2022-12-08 04:07:58 +0100 | <iqubic> | But what do you do with the derivative of the form "1 + 2x + 3x^2 + 4x^3 + ... + (n-1)x^n" |
| 2022-12-08 04:08:32 +0100 | <EvanR> | well that's the sum of context types for the singleton, the pair, the triple, etc |
| 2022-12-08 04:08:48 +0100 | <EvanR> | do with it what you will xD |
| 2022-12-08 04:09:23 +0100 | <EvanR> | that type holds the same information as two lists of x |
| 2022-12-08 04:09:25 +0100 | <iqubic> | I guess at that point you try to construct the ADT that has that form? |
| 2022-12-08 04:09:37 +0100 | <EvanR> | either one is enough to implement the list zipper |
| 2022-12-08 04:09:47 +0100 | <iqubic> | Yeah, I see. |
| 2022-12-08 04:11:17 +0100 | <EvanR> | with that out of the way, time for the sideshow. 1 + x + x^2 + ... = 1 / (1 - x), and the derivative of that is (1 / (1 - x))^2 xD |
| 2022-12-08 04:11:33 +0100 | <EvanR> | (two lists) |
| 2022-12-08 04:12:29 +0100 | <iqubic> | Huh?? How do you do subtraction and division with ADTs? Aren't they called "sums of products" for a reasion? |
| 2022-12-08 04:12:40 +0100 | <iqubic> | s/reasion/reason/ |
| 2022-12-08 04:13:23 +0100 | <EvanR> | another satisfied customer! next! |
| 2022-12-08 04:13:52 +0100 | <iqubic> | I'm not satisfied at all. If anything, I'm more confused. |
| 2022-12-08 04:14:23 +0100 | <EvanR> | I tried to clearly demark where we went from making sense to borderline farce xD |
| 2022-12-08 04:14:59 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-12-08 04:15:12 +0100 | <EvanR> | maybe it's related to how 1 + 2 + 3 + 4 + ... = -1/12 xD |
| 2022-12-08 04:15:16 +0100 | <byorgey> | it's not a farce at all. =) 1 / (1 - x) can't be interpreted directly as a type, but it's a perfectly good representation of a formal power series. Combinatoricists have been doing this for a long time. |
| 2022-12-08 04:16:04 +0100 | <byorgey> | exercise for the reader: start from list(x) = 1 + x * list(x) and differentiate both sides |
| 2022-12-08 04:16:09 +0100 | <iqubic> | Oh, hey there byorgey. Welcome into to our ramblings on ADTs. We're trying to puzzle out exactly what's so "algebraic" about them |
| 2022-12-08 04:16:22 +0100 | <EvanR> | yeah that's where the formula comes from, or could come from |
| 2022-12-08 04:17:43 +0100 | <EvanR> | iqubic, you bought the formula list(x) = 1 + x * list(x), which I agree with. But maybe we read too much into it already at that stage |
| 2022-12-08 04:18:27 +0100 | <byorgey> | Types are algebraic because they form a very nice semiring. |
| 2022-12-08 04:18:40 +0100 | <iqubic> | They do? |
| 2022-12-08 04:18:49 +0100 | <EvanR> | 0, 1, +, * |
| 2022-12-08 04:19:05 +0100 | <iqubic> | Right. Yes. That's right. |
| 2022-12-08 04:19:36 +0100 | <iqubic> | Or in this case, Void, Unit, Either, (,) |
| 2022-12-08 04:20:17 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-12-08 04:21:31 +0100 | <byorgey> | And because there are homomorphisms between the semiring of types (or subsemirings like the semiring of finite types) to other nice semirings like the natural numbers, finite sets, etc., a lot of the "algebraic" machinery we know and love from those settings (exponent laws, derivatives, etc.) works nicely with types as well. |
| 2022-12-08 04:21:47 +0100 | hueso | (~root@user/hueso) (Quit: hueso) |
| 2022-12-08 04:21:53 +0100 | <iqubic> | I'm beginning to see that, yeah. |
| 2022-12-08 04:22:23 +0100 | <EvanR> | full disclosure, last night I saw the AoC puzzle and said damn that needs a zipper! But I had no idea how to do it, and my friend has such a hard time in Language X I told him to just take the derivative of the tree. So here I am trying to even understand it xD |
| 2022-12-08 04:22:40 +0100 | <byorgey> | EvanR: yeah, I did it with a zipper =) |
| 2022-12-08 04:22:54 +0100 | <byorgey> | but I didn't derive it myself, I just used the rosezipper package |
| 2022-12-08 04:23:11 +0100 | <iqubic> | I didn't use a zipper. I found it too hard to parse the input into a zipper. |
| 2022-12-08 04:23:18 +0100 | <EvanR> | apparently the elixir library they tried first couldn't handle the directory name attached to the names |
| 2022-12-08 04:23:28 +0100 | <EvanR> | attached to the nodes |
| 2022-12-08 04:23:47 +0100 | <byorgey> | I parsed the input into a sequence of commands, then I interpreted the commands in a state monad with a zipper as the state. |
| 2022-12-08 04:24:49 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 2022-12-08 04:24:59 +0100 | <EvanR> | do semirings explain 1 / (1 - x) or recursive equations? |
| 2022-12-08 04:25:22 +0100 | <iqubic> | Ah. I see. I did a similar thing, but instead of using a zipper I converted the sequence of commands into a (Map [String] [Int]) where I stored only the file sizes. |
| 2022-12-08 04:26:07 +0100 | <EvanR> | ok I guess that's a second level of ring |
| 2022-12-08 04:26:24 +0100 | <iqubic> | What's the second level? |
| 2022-12-08 04:26:36 +0100 | <EvanR> | polynomial ring |
| 2022-12-08 04:26:54 +0100 | <iqubic> | I'm not familiar with that structure. |
| 2022-12-08 04:27:06 +0100 | hueso | (~root@user/hueso) |
| 2022-12-08 04:27:10 +0100 | <byorgey> | EvanR: star semirings do, I think. |
| 2022-12-08 04:27:44 +0100 | <byorgey> | https://dl.acm.org/doi/10.1145/2544174.2500613 |
| 2022-12-08 04:28:25 +0100 | <EvanR> | a 3 second google indicates this star is the kleene star? |
| 2022-12-08 04:28:35 +0100 | <byorgey> | yes. |
| 2022-12-08 04:28:43 +0100 | <EvanR> | mind blown |
| 2022-12-08 04:28:45 +0100 | <byorgey> | aka List |
| 2022-12-08 04:29:15 +0100 | <byorgey> | ^^^ that paper I linked is one of my favorite. |
| 2022-12-08 04:29:29 +0100 | king_gs | (~Thunderbi@187.201.204.122) |
| 2022-12-08 04:30:37 +0100 | <EvanR> | I use lock picking on this publication |
| 2022-12-08 04:30:43 +0100 | <albet70> | in ActionM ()'s do notation, if I want to use 'catch' to catch exception, 1. does it need 'liftIO'? since catch :: IO a -> ... 2. if with liftIO, liftIO the whole catch line? |
| 2022-12-08 04:30:56 +0100 | <EvanR> | % randomRIO (1,20) |
| 2022-12-08 04:30:56 +0100 | <yahb2> | <interactive>:46:1: error: ; Variable not in scope: randomRIO :: (a0, b0) -> t |
| 2022-12-08 04:31:54 +0100 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-12-08 04:31:54 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-12-08 04:31:54 +0100 | finn_elija | FinnElija |
| 2022-12-08 04:32:20 +0100 | <iqubic> | Kleene star is such a complicated name for such a simple concept, LOL |
| 2022-12-08 04:32:38 +0100 | <EvanR> | is it? simple |
| 2022-12-08 04:33:13 +0100 | <byorgey> | oh, is it paywalled? oops, try https://scholar.archive.org/work/c2l6m5cvdrh4di2xj3steer6ua/access/wayback/https://www.cl.cam.ac.u… |
| 2022-12-08 04:33:46 +0100 | <byorgey> | it is simple yet deep/profound, just like monads. |
| 2022-12-08 04:33:49 +0100 | <iqubic> | byorgey: The original link was paywalled, but I can view the paper at that link. |
| 2022-12-08 04:33:51 +0100 | <EvanR> | thanks |
| 2022-12-08 04:34:04 +0100 | <iqubic> | Even Posix Regex has a Kleene star |
| 2022-12-08 04:34:40 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-12-08 04:35:25 +0100 | <EvanR> | a* = 1 + aa* |
| 2022-12-08 04:35:47 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-12-08 04:35:51 +0100 | <EvanR> | list(x) = 1 + x * list(x) |
| 2022-12-08 04:35:51 +0100 | <iqubic> | Yeah, that makes sense. |
| 2022-12-08 04:37:51 +0100 | <iqubic> | byorgey: I'll get around to reading that after Advent of Code. |
| 2022-12-08 04:39:04 +0100 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) (Remote host closed the connection) |
| 2022-12-08 04:40:20 +0100 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) |
| 2022-12-08 04:43:15 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2022-12-08 04:44:35 +0100 | td_ | (~td@83.135.9.15) (Ping timeout: 264 seconds) |
| 2022-12-08 04:45:42 +0100 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-12-08 04:46:26 +0100 | td_ | (~td@83.135.9.14) |
| 2022-12-08 04:51:29 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-12-08 04:51:29 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-12-08 04:51:29 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-12-08 04:59:00 +0100 | king_gs | (~Thunderbi@187.201.204.122) (Read error: Connection reset by peer) |
| 2022-12-08 04:59:06 +0100 | king_gs1 | (~Thunderbi@2806:103e:29:94a4:81e0:429b:22ec:cf13) |
| 2022-12-08 04:59:34 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 256 seconds) |
| 2022-12-08 05:01:24 +0100 | king_gs1 | king_gs |
| 2022-12-08 05:10:47 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 268 seconds) |
| 2022-12-08 05:13:35 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2022-12-08 05:20:51 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-12-08 05:27:14 +0100 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-12-08 05:27:27 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-12-08 05:27:27 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-12-08 05:27:27 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-12-08 05:27:53 +0100 | king_gs | (~Thunderbi@2806:103e:29:94a4:81e0:429b:22ec:cf13) (Quit: king_gs) |
| 2022-12-08 05:28:06 +0100 | king_gs | (~Thunderbi@187.201.204.122) |
| 2022-12-08 05:31:59 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 264 seconds) |
| 2022-12-08 05:33:00 +0100 | ddellacosta | (~ddellacos@static-198-44-136-134.cust.tzulo.com) (Ping timeout: 256 seconds) |
| 2022-12-08 05:44:04 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 248 seconds) |
| 2022-12-08 05:47:14 +0100 | mbuf | (~Shakthi@49.205.85.230) |
| 2022-12-08 05:47:15 +0100 | king_gs | (~Thunderbi@187.201.204.122) (Read error: Connection reset by peer) |
| 2022-12-08 05:47:38 +0100 | king_gs | (~Thunderbi@2806:103e:29:94a4:81e0:429b:22ec:cf13) |
| 2022-12-08 05:53:15 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) (Read error: Connection reset by peer) |
| 2022-12-08 05:53:41 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-12-08 05:55:14 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 2022-12-08 05:58:59 +0100 | king_gs | (~Thunderbi@2806:103e:29:94a4:81e0:429b:22ec:cf13) (Ping timeout: 264 seconds) |
| 2022-12-08 06:04:48 +0100 | tvandinther | (~tvandinth@111.69.34.210) (Ping timeout: 260 seconds) |
| 2022-12-08 06:06:54 +0100 | srk | (~sorki@user/srk) (Ping timeout: 268 seconds) |
| 2022-12-08 06:06:55 +0100 | <freeside> | update from running my naive but reasonably well optimized Unboxed Vector implementation of 2019/day/16: my runtime was growing linearly with input size, but interestingly, the most recent jump from 65000 to 650000 caused a 100-fold increase in runtime for only a 10x increase in input size |
| 2022-12-08 06:07:00 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-12-08 06:07:49 +0100 | <jackdk> | Sounds like you've got an O(n^2) algo in there somewher |
| 2022-12-08 06:08:03 +0100 | <freeside> | yeah, definitely feels that way, except it didn't show up for the smaller n |
| 2022-12-08 06:08:21 +0100 | <freeside> | that's the funny thing about ^ i guess |
| 2022-12-08 06:11:13 +0100 | <freeside> | well, at least i've moved the O(n^2) from space to time, lol |
| 2022-12-08 06:11:50 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt https://tinyurl.com/4m8d4kd5) |
| 2022-12-08 06:23:33 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Ping timeout: 268 seconds) |
| 2022-12-08 06:23:47 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) |
| 2022-12-08 06:29:53 +0100 | <int-e> | freeside: you may have jumped a level in the cache hierarchy. |
| 2022-12-08 06:32:18 +0100 | johnw | (~johnw@2600:1700:cf00:db0:1da8:bc45:1742:a938) (Quit: ZNC - http://znc.in) |
| 2022-12-08 06:33:42 +0100 | <int-e> | Hmm. But you said naive... if you implement that naively, it should be quadratic, shouldn't it? |
| 2022-12-08 06:38:53 +0100 | <freeside> | good point. anyway, i think i have found my bug, i should be letting above and calling below |
| 2022-12-08 06:40:07 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 252 seconds) |
| 2022-12-08 06:42:15 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 260 seconds) |
| 2022-12-08 06:51:20 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-12-08 07:02:32 +0100 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 2022-12-08 07:06:47 +0100 | jpds2 | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 255 seconds) |
| 2022-12-08 07:07:58 +0100 | jpds2 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-12-08 07:09:38 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-12-08 07:11:39 +0100 | <int-e> | freeside: (\x -> genBase y x+1) lacks parentheses? |
| 2022-12-08 07:12:02 +0100 | <freeside> | i keep flipping between the (Int,Int) form and the Int -> Int form |
| 2022-12-08 07:12:16 +0100 | <freeside> | is there any performance advantage to either, or do they get desugared by the compiler? |
| 2022-12-08 07:12:57 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
| 2022-12-08 07:14:05 +0100 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-12-08 07:14:06 +0100 | <int-e> | I'd trust the compiler more for the curried (untupled) version. |
| 2022-12-08 07:14:54 +0100 | <int-e> | But there's a reasonably good chance that the compiler will generate the same worker either way in this particular instance. |
| 2022-12-08 07:16:29 +0100 | <int-e> | In any case, this particular problem has a trick that allows it to be solved in millions rather than billions or trillions of operations.. |
| 2022-12-08 07:16:40 +0100 | <freeside> | i think it is time for me to do Clever Algo Tricks to exploit the properties of the input. The neat thing about the input is that working from bottom to top immediately suggests a sort of optimized fold, where we simply add a single value from the upper row to the running output. https://github.com/mengwong/adventofcode/commit/71d6e5a83f092c58aee8126ed31a05b600c8b80d#commitcom… |
| 2022-12-08 07:16:51 +0100 | <int-e> | (relying on a special property of the input) |
| 2022-12-08 07:17:33 +0100 | <freeside> | is there a version of fold that logs each step to a running list? i will go dig in the Data.List docs, or perhaps the Data.Vector docs |
| 2022-12-08 07:18:05 +0100 | <freeside> | the last row is known to produce a 0 result, then the row above that is just the last val in the input list, then the row above that produces that last val plus the previous val, etc. |
| 2022-12-08 07:18:26 +0100 | <freeside> | i will go think of a succint way to express that after my next meeting and a cup of coffee |
| 2022-12-08 07:18:33 +0100 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 265 seconds) |
| 2022-12-08 07:18:36 +0100 | <jackdk> | one of teh scans, maybe? |
| 2022-12-08 07:19:35 +0100 | <freeside> | things get messy once we move to the upper right quadrant though, i feel like there is a version of that cache that could rely on the "angled" boundary between the regions |
| 2022-12-08 07:20:18 +0100 | <freeside> | the slope of the 0-to-1 boundary is -1; the slope of the 1-to-0 boundary is -0.5; the slope of the 0-to-(-) boundary is -0.25; and so on |
| 2022-12-08 07:20:21 +0100 | <int-e> | freeside: here's a slightly bigger version of that matrix rendered a bit differently... maybe that sparks an inspiration? http://paste.debian.net/1263255/ ...incidentally the sole comment in my solution for that part. |
| 2022-12-08 07:20:45 +0100 | <freeside> | that matrix shows the derivative of the computation, basically |
| 2022-12-08 07:21:37 +0100 | <freeside> | a second derivative would show only a single diagonal of + running down the page |
| 2022-12-08 07:22:08 +0100 | <freeside> | conceptually, a sort of hamming encoding |
| 2022-12-08 07:22:50 +0100 | <int-e> | freeside: have you looked at the given message index at all? |
| 2022-12-08 07:23:35 +0100 | <freeside> | beyond the x div y mod 4 in my genBase, you mean? |
| 2022-12-08 07:23:40 +0100 | codaraxis | (~codaraxis@user/codaraxis) |
| 2022-12-08 07:24:44 +0100 | <int-e> | hmm. oh it's called "message offset" in the problem |
| 2022-12-08 07:24:46 +0100 | <freeside> | i will think on this. thank you. i now have to attend a meeting. |
| 2022-12-08 07:25:06 +0100 | <int-e> | anyway, there's something there that simplifies the problem considerably |
| 2022-12-08 07:25:50 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-12-08 07:38:33 +0100 | Scraeling | (~Scraeling@user/scraeling) |
| 2022-12-08 07:47:28 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds) |
| 2022-12-08 07:54:51 +0100 | <iqubic> | One of these days I should update my 2D grid code from "Map (V2 Int) a" to something better, but IDK what a better type would be. |
| 2022-12-08 07:59:09 +0100 | <dsal> | Mine is `ByteString` |
| 2022-12-08 08:00:29 +0100 | <iqubic> | Did you use a ByteString for today? |
| 2022-12-08 08:03:28 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2022-12-08 08:03:33 +0100 | <dsal> | Yeah. A big part of my time sink was trying to remember how I built this thing. It's kind of messy. |
| 2022-12-08 08:03:43 +0100 | <dsal> | At least displaying it is |
| 2022-12-08 08:03:45 +0100 | shriekingnoise | (~shrieking@186.137.167.202) (Quit: Quit) |
| 2022-12-08 08:04:19 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-12-08 08:05:52 +0100 | <iqubic> | My grid implementation was super slow because I think Map is slow. |
| 2022-12-08 08:06:28 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 248 seconds) |
| 2022-12-08 08:06:51 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2022-12-08 08:07:34 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-12-08 08:11:39 +0100 | <iqubic> | How do you have a 2D ByteString? |
| 2022-12-08 08:13:30 +0100 | <int-e> | Map was good enough today |
| 2022-12-08 08:15:27 +0100 | <int-e> | iqubic: I suppose you could have a vector of ByteStrings |
| 2022-12-08 08:17:06 +0100 | <dsal> | iqubic: Ix |
| 2022-12-08 08:17:19 +0100 | <iqubic> | How does Ix help you? |
| 2022-12-08 08:17:27 +0100 | <int-e> | :t ix |
| 2022-12-08 08:17:27 +0100 | <dsal> | It adds Ds to a 1D thing. |
| 2022-12-08 08:17:28 +0100 | <lambdabot> | (Ixed m, Applicative f) => Index m -> (IxValue m -> f (IxValue m)) -> m -> f m |
| 2022-12-08 08:17:46 +0100 | <dsal> | :t Ix.index |
| 2022-12-08 08:17:47 +0100 | <lambdabot> | error: |
| 2022-12-08 08:17:47 +0100 | <lambdabot> | Not in scope: ‘Ix.index’ |
| 2022-12-08 08:17:47 +0100 | <lambdabot> | Perhaps you meant one of these: |
| 2022-12-08 08:17:56 +0100 | <int-e> | :t index |
| 2022-12-08 08:17:57 +0100 | <lambdabot> | Ix a => (a, a) -> a -> Int |
| 2022-12-08 08:18:04 +0100 | <dsal> | Oh. Convenient. |
| 2022-12-08 08:18:08 +0100 | <iqubic> | Oh does it add Ds? |
| 2022-12-08 08:18:42 +0100 | <int-e> | > map index ((0,0),(3,3)) [(0,0),(0,1),(1,0),(3,3),(4,1)] |
| 2022-12-08 08:18:43 +0100 | <lambdabot> | error: |
| 2022-12-08 08:18:43 +0100 | <lambdabot> | • Couldn't match expected type ‘[(a3, b2)] -> t’ |
| 2022-12-08 08:18:43 +0100 | <lambdabot> | with actual type ‘[a0 -> Int]’ |
| 2022-12-08 08:19:02 +0100 | <int-e> | > map (index ((0,0),(3,3))) [(0,0),(0,1),(1,0),(3,3),(4,1)] |
| 2022-12-08 08:19:04 +0100 | <lambdabot> | [0,1,4,15,*Exception: Error in array index |
| 2022-12-08 08:19:12 +0100 | <dsal> | That time you went too far. |
| 2022-12-08 08:19:42 +0100 | <int-e> | I just wanted to show where exactly the bounds are. |
| 2022-12-08 08:19:52 +0100 | <dsal> | :t ragne |
| 2022-12-08 08:19:53 +0100 | <lambdabot> | error: |
| 2022-12-08 08:19:53 +0100 | <lambdabot> | • Variable not in scope: ragne |
| 2022-12-08 08:19:53 +0100 | <lambdabot> | • Perhaps you meant ‘range’ (imported from Data.Ix) |
| 2022-12-08 08:19:53 +0100 | <dsal> | :t range |
| 2022-12-08 08:19:54 +0100 | <lambdabot> | Ix a => (a, a) -> [a] |
| 2022-12-08 08:19:58 +0100 | <int-e> | So the last pair was supposed to be out of range. |
| 2022-12-08 08:20:03 +0100 | <dsal> | :t ragne |
| 2022-12-08 08:20:04 +0100 | <lambdabot> | error: |
| 2022-12-08 08:20:04 +0100 | <lambdabot> | • Variable not in scope: ragne |
| 2022-12-08 08:20:04 +0100 | <lambdabot> | • Perhaps you meant ‘range’ (imported from Data.Ix) |
| 2022-12-08 08:20:07 +0100 | <dsal> | haha. I should go to sleep |
| 2022-12-08 08:20:17 +0100 | <int-e> | > range ((0,0,0),(1,1,1)) |
| 2022-12-08 08:20:19 +0100 | <lambdabot> | [(0,0,0),(0,0,1),(0,1,0),(0,1,1),(1,0,0),(1,0,1),(1,1,0),(1,1,1)] |
| 2022-12-08 08:21:21 +0100 | <dsal> | So for these "square" problems, I just `BS.readFile` and then make bounds with `BS.elemIndices 10 b` |
| 2022-12-08 08:21:40 +0100 | <dsal> | No data structure is more efficient than no data structure. |
| 2022-12-08 08:21:55 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-12-08 08:24:50 +0100 | <iqubic> | I see.. |
| 2022-12-08 08:24:57 +0100 | <dsal> | I'm kind of annoyed I had to write a `takeUntil` and also that I spent a while trying to even figure out what to call it. |
| 2022-12-08 08:25:15 +0100 | <iqubic> | She says, not really understanding. |
| 2022-12-08 08:25:23 +0100 | <iqubic> | dsal: I feel you |
| 2022-12-08 08:25:40 +0100 | <dsal> | heh |
| 2022-12-08 08:25:52 +0100 | <dsal> | Just give it a shot. Ix does the magic here. |
| 2022-12-08 08:26:33 +0100 | <iqubic> | I'm sure it does. |
| 2022-12-08 08:29:01 +0100 | <glguy> | I prefer UArray with a 2d coordinate indeed for the grid problems like these |
| 2022-12-08 08:29:06 +0100 | <int-e> | dsal: I ultimately went for `span` and testing whether the remainder was empty. |
| 2022-12-08 08:29:48 +0100 | <dsal> | Hmm... Yeah, span is a thing I always forget. |
| 2022-12-08 08:29:53 +0100 | <glguy> | https://github.com/glguy/advent/blob/main/solutions/src/2022/08.hs |
| 2022-12-08 08:30:15 +0100 | <dsal> | glguy :That's where I started. This is slightly inconvenient, but I like the "just read the file" data structure. |
| 2022-12-08 08:30:27 +0100 | <glguy> | I'm not consistent on when I use break or span |
| 2022-12-08 08:30:34 +0100 | <xerox> | I takeWhile the coords https://github.com/mrtnpaolo/advent-of-code-2022/blob/master/execs/Day08.hs |
| 2022-12-08 08:30:55 +0100 | razetime_ | (~quassel@49.207.203.213) |
| 2022-12-08 08:32:10 +0100 | dsrt^ | (~dsrt@76.145.185.103) (Remote host closed the connection) |
| 2022-12-08 08:32:29 +0100 | <dsal> | I made this thing out of my clunky file reader: https://www.irccloud.com/pastebin/yS4bux1k/thing.hs |
| 2022-12-08 08:34:44 +0100 | meinside | (uid24933@id-24933.helmsley.irccloud.com) |
| 2022-12-08 08:35:46 +0100 | <glguy> | I didn't end up bothering with digitToInt; we just needed comparisons :) |
| 2022-12-08 08:36:22 +0100 | <xerox> | hehe |
| 2022-12-08 08:40:30 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 08:47:40 +0100 | <dsal> | Yeah, I can't remember why I did that. I think that was just part of how I was debugging. |
| 2022-12-08 08:50:49 +0100 | zeenk | (~zeenk@2a02:2f04:a30d:4300::7fe) |
| 2022-12-08 08:53:01 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
| 2022-12-08 08:53:29 +0100 | nschoe | (~q@141.101.51.197) |
| 2022-12-08 08:56:13 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2022-12-08 09:00:27 +0100 | mncheck | (~mncheck@193.224.205.254) |
| 2022-12-08 09:01:47 +0100 | ft | (~ft@p508dbd59.dip0.t-ipconnect.de) (Quit: leaving) |
| 2022-12-08 09:05:51 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 265 seconds) |
| 2022-12-08 09:07:10 +0100 | kenran | (~user@user/kenran) |
| 2022-12-08 09:09:09 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-12-08 09:10:40 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 268 seconds) |
| 2022-12-08 09:11:10 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-12-08 09:11:55 +0100 | kenran | (~user@user/kenran) (Ping timeout: 252 seconds) |
| 2022-12-08 09:13:45 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:9ec2:49f5:ac35:545a) |
| 2022-12-08 09:14:09 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 2022-12-08 09:14:15 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-12-08 09:18:13 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-12-08 09:22:18 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-12-08 09:25:55 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a767ca9aed60fa8d1f2.dip0.t-ipconnect.de) |
| 2022-12-08 09:29:32 +0100 | michalz | (~michalz@185.246.204.93) |
| 2022-12-08 09:33:24 +0100 | coot | (~coot@213.134.171.3) |
| 2022-12-08 09:39:47 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-12-08 09:46:35 +0100 | avicenzi | (~avicenzi@2a00:ca8:a1f:b004::c32) |
| 2022-12-08 09:49:57 +0100 | zant1 | (~zant@62.214.20.26) |
| 2022-12-08 09:54:18 +0100 | razetime_ | (~quassel@49.207.203.213) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-12-08 10:04:47 +0100 | raehik | (~raehik@92.40.212.207.threembb.co.uk) |
| 2022-12-08 10:07:59 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-12-08 10:18:23 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) (Remote host closed the connection) |
| 2022-12-08 10:18:50 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-12-08 10:19:12 +0100 | Scraeling | (~Scraeling@user/scraeling) (Quit: Scraeling) |
| 2022-12-08 10:21:05 +0100 | raehik | (~raehik@92.40.212.207.threembb.co.uk) (Ping timeout: 255 seconds) |
| 2022-12-08 10:21:15 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 265 seconds) |
| 2022-12-08 10:23:42 +0100 | califax | (~califax@user/califx) |
| 2022-12-08 10:32:03 +0100 | MajorBiscuit | (~MajorBisc@145.94.137.174) |
| 2022-12-08 10:35:08 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 10:35:20 +0100 | alexiscott | (~user@4.red-83-36-45.dynamicip.rima-tde.net) |
| 2022-12-08 10:37:38 +0100 | raehik | (~raehik@92.40.212.159.threembb.co.uk) |
| 2022-12-08 10:38:18 +0100 | paulpaul1076 | (~textual@95-29-5-111.broadband.corbina.ru) (Read error: Connection reset by peer) |
| 2022-12-08 10:39:59 +0100 | Ellenor | (ellenor@callbox.trd.is) |
| 2022-12-08 10:40:05 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2022-12-08 10:43:24 +0100 | raehik | (~raehik@92.40.212.159.threembb.co.uk) (Ping timeout: 260 seconds) |
| 2022-12-08 10:44:57 +0100 | raehik | (~raehik@92.40.213.222.threembb.co.uk) |
| 2022-12-08 10:45:20 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 10:46:41 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-12-08 10:51:22 +0100 | causal | (~user@50.35.85.7) (Quit: WeeChat 3.7.1) |
| 2022-12-08 10:51:48 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-12-08 10:51:48 +0100 | raehik | (~raehik@92.40.213.222.threembb.co.uk) (Ping timeout: 268 seconds) |
| 2022-12-08 10:54:35 +0100 | VY2 | (~user@213.24.126.232) |
| 2022-12-08 11:00:17 +0100 | jakalx | (~jakalx@base.jakalx.net) (Disconnected: Replaced by new connection) |
| 2022-12-08 11:00:21 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-12-08 11:03:41 +0100 | russruss | (~russruss@my.russellmcc.com) |
| 2022-12-08 11:04:41 +0100 | russruss | (~russruss@my.russellmcc.com) (Client Quit) |
| 2022-12-08 11:07:22 +0100 | russruss | (~russruss@my.russellmcc.com) |
| 2022-12-08 11:13:35 +0100 | mmhat | (~mmh@p200300f1c73b51dfee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-12-08 11:14:05 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2022-12-08 11:16:13 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2022-12-08 11:16:18 +0100 | notzmv | (~zmv@user/notzmv) |
| 2022-12-08 11:16:39 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 260 seconds) |
| 2022-12-08 11:18:02 +0100 | kavvadias | (~kavvadias@2001:9e8:630f:d300:9b55:5cee:bc98:2a71) |
| 2022-12-08 11:18:50 +0100 | CiaoSen | (~Jura@p200300c95747e0002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-12-08 11:18:52 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) |
| 2022-12-08 11:19:39 +0100 | aliosablack | (~chomwitt@2a02:587:7a0c:6a00:1ac0:4dff:fedb:a3f1) |
| 2022-12-08 11:23:07 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) (Ping timeout: 248 seconds) |
| 2022-12-08 11:23:10 +0100 | cybersoul | (~cybersoul@2405:201:680a:b01d:8ad:2a0c:230c:f77) |
| 2022-12-08 11:25:38 +0100 | Ybombinator | (~Ybombinat@81.198.69.124) |
| 2022-12-08 11:33:17 +0100 | zeenk | (~zeenk@2a02:2f04:a30d:4300::7fe) (Quit: Konversation terminated!) |
| 2022-12-08 11:34:22 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a767ca9aed60fa8d1f2.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-12-08 11:41:58 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 265 seconds) |
| 2022-12-08 11:42:22 +0100 | raehik | (~raehik@92.40.169.175.threembb.co.uk) |
| 2022-12-08 11:45:25 +0100 | kavvadias | (~kavvadias@2001:9e8:630f:d300:9b55:5cee:bc98:2a71) (Quit: Client closed) |
| 2022-12-08 11:48:16 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-12-08 11:48:19 +0100 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2022-12-08 11:54:05 +0100 | <dminuoso> | Repa is quite nice for working with 2-dimensional data |
| 2022-12-08 11:54:37 +0100 | <dminuoso> | It lets you have unboxed vectors beneath, but with a comfortable high level 2-dimensional index style |
| 2022-12-08 11:55:01 +0100 | <dminuoso> | (It nicely extends to arbitrary dimensions too) |
| 2022-12-08 11:56:06 +0100 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 3.7.1) |
| 2022-12-08 11:57:33 +0100 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) |
| 2022-12-08 11:58:12 +0100 | mmhat | (~mmh@p200300f1c73b51dfee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1) |
| 2022-12-08 12:00:45 +0100 | raehik | (~raehik@92.40.169.175.threembb.co.uk) (Ping timeout: 260 seconds) |
| 2022-12-08 12:02:08 +0100 | VY2 | (~user@213.24.126.232) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.2)) |
| 2022-12-08 12:04:00 +0100 | Ybombinator | (~Ybombinat@81.198.69.124) (Ping timeout: 256 seconds) |
| 2022-12-08 12:04:08 +0100 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) |
| 2022-12-08 12:04:34 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 12:07:00 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 12:07:29 +0100 | Ybombinator | (~Ybombinat@85.254.75.8) |
| 2022-12-08 12:07:42 +0100 | AndreasK | (sid320732@id-320732.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-12-08 12:09:24 +0100 | meooow_ | (~meooow@165.232.184.169) (Remote host closed the connection) |
| 2022-12-08 12:09:57 +0100 | meooow | (~meooow@2400:6180:100:d0::ad9:e001) |
| 2022-12-08 12:14:46 +0100 | <Ybombinator> | "sum (x:xs) = x + sum xs" is a folding function, right? |
| 2022-12-08 12:14:52 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2022-12-08 12:16:50 +0100 | dextaa5 | (~DV@user/dextaa) |
| 2022-12-08 12:17:05 +0100 | <mauke> | foldr |
| 2022-12-08 12:17:19 +0100 | <Ybombinator> | ah |
| 2022-12-08 12:17:44 +0100 | <mauke> | > foldr (+) 0 [a, b, c] |
| 2022-12-08 12:17:46 +0100 | <lambdabot> | a + (b + (c + 0)) |
| 2022-12-08 12:17:53 +0100 | Sindai | (~Sindai@2a01cb0583e8cd000544677d81e0b920.ipv6.abo.wanadoo.fr) |
| 2022-12-08 12:18:01 +0100 | <mauke> | > foldl (+) 0 [a, b, c] |
| 2022-12-08 12:18:03 +0100 | <lambdabot> | 0 + a + b + c |
| 2022-12-08 12:18:50 +0100 | dextaa | (~DV@user/dextaa) (Ping timeout: 260 seconds) |
| 2022-12-08 12:18:50 +0100 | dextaa5 | dextaa |
| 2022-12-08 12:19:19 +0100 | <Ybombinator> | yeah thanks |
| 2022-12-08 12:19:33 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-12-08 12:20:20 +0100 | Sindai | (~Sindai@2a01cb0583e8cd000544677d81e0b920.ipv6.abo.wanadoo.fr) (Quit: Client closed) |
| 2022-12-08 12:21:57 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-12-08 12:25:44 +0100 | akegalj | (~akegalj@141-136-183-112.dsl.iskon.hr) |
| 2022-12-08 12:29:28 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a76b0b8eea36f8bd0e7.dip0.t-ipconnect.de) |
| 2022-12-08 12:32:22 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.7.1) |
| 2022-12-08 12:40:27 +0100 | aliosablack | (~chomwitt@2a02:587:7a0c:6a00:1ac0:4dff:fedb:a3f1) (Ping timeout: 248 seconds) |
| 2022-12-08 12:42:00 +0100 | nyr | (~nyr@91.196.39.241) |
| 2022-12-08 12:45:10 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-12-08 12:46:52 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt https://tinyurl.com/4m8d4kd5) |
| 2022-12-08 12:51:14 +0100 | nyr | (~nyr@91.196.39.241) (Quit: WeeChat 3.7.1) |
| 2022-12-08 12:52:15 +0100 | nyr | (~nyr@91.196.39.241) |
| 2022-12-08 12:52:37 +0100 | chomwitt | (~chomwitt@athedsl-351826.home.otenet.gr) |
| 2022-12-08 12:54:31 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-12-08 13:00:47 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-12-08 13:02:07 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-12-08 13:02:12 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 265 seconds) |
| 2022-12-08 13:04:44 +0100 | nyr | (~nyr@91.196.39.241) (Quit: WeeChat 3.7.1) |
| 2022-12-08 13:05:40 +0100 | <dminuoso> | Mmm, is there a nice way to build a literal list with elements possibly depending on some ambient condition? |
| 2022-12-08 13:05:56 +0100 | <dminuoso> | Some kind of `[a, b ? if foo, c ? if bar]` |
| 2022-12-08 13:06:37 +0100 | <dminuoso> | My current solution involves just using a dlist where just conditionally concatenate an emptyDList or a `singleton foo` |
| 2022-12-08 13:07:00 +0100 | <dminuoso> | catMaybes is another one, but that feels awkward as well |
| 2022-12-08 13:07:23 +0100 | Guest75 | (Guest75@2a01:7e01::f03c:92ff:fe5d:7b18) |
| 2022-12-08 13:14:04 +0100 | alexiscott | (~user@4.red-83-36-45.dynamicip.rima-tde.net) (Remote host closed the connection) |
| 2022-12-08 13:17:53 +0100 | <Cale> | concat [[a], [b | foo], [c | bar]] |
| 2022-12-08 13:18:49 +0100 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 2022-12-08 13:29:35 +0100 | <dminuoso> | Cale: Mmm I like that. |
| 2022-12-08 13:29:48 +0100 | <Lears> | dminuoso: I'm not sure what you want with "literal" here, but I always end up writing `mwhen :: Monoid a => Bool -> a -> a` and using it all over the place; something like `[a] <> mwhen foo [b] <> mwhen bar [c]`. |
| 2022-12-08 13:31:14 +0100 | <dminuoso> | Lears: Heh I actually use exactly that mwhen in some of my prettyprinter uses |
| 2022-12-08 13:31:23 +0100 | <dminuoso> | Didn't occur to me to use it with lists |
| 2022-12-08 13:38:13 +0100 | <jackdk> | Lears: I like `fold :: Monoid m => Maybe m -> m` as a similar trick |
| 2022-12-08 13:39:06 +0100 | shriekingnoise | (~shrieking@186.137.167.202) |
| 2022-12-08 13:42:20 +0100 | <merijn> | dminuoso, Lears: Yeah, it's a super useful function, my campaign to get it in base stranded on naming difficulties, though |
| 2022-12-08 13:43:00 +0100 | <merijn> | mwhen/mif were some candidates, but I'm not sure |
| 2022-12-08 13:43:07 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-12-08 13:45:06 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 13:45:36 +0100 | <Lears> | While we're at it, I also like `mfor :: (Foldable f, Monoid b) => f a -> (a -> b) -> b; mfor = flip foldMap`; and `whenA`/`forA` variants on Applicatives, using `Ap` internally. I believe these are the best names in terms of established conventions and clash avoidance. |
| 2022-12-08 13:52:09 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-12-08 13:53:47 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-12-08 14:00:31 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 14:08:30 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-12-08 14:27:47 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2022-12-08 14:28:37 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:556e:28e8:6695:53e8) (Remote host closed the connection) |
| 2022-12-08 14:28:55 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2022-12-08 14:29:32 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-12-08 14:31:38 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-12-08 14:31:56 +0100 | zeenk | (~zeenk@2a02:2f04:a30d:4300::7fe) |
| 2022-12-08 14:32:50 +0100 | <jackdk> | I sometimes call `mfor` `paMdolf`. Relude has a `foldMapA` which is often very handy |
| 2022-12-08 14:34:05 +0100 | jpds2 | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 255 seconds) |
| 2022-12-08 14:35:16 +0100 | CiaoSen | (~Jura@p200300c95747e0002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-12-08 14:35:26 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2022-12-08 14:37:24 +0100 | <dminuoso> | jackdk: I see, so what you're really after is -XFlippedIdentifiers, where `pamf` is automatically replaced by `flip fmap` |
| 2022-12-08 14:37:35 +0100 | <dminuoso> | Wouldn't that be a fun language thing. |
| 2022-12-08 14:38:20 +0100 | <dminuoso> | Palindrome identifiers better be commutative |
| 2022-12-08 14:38:25 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-12-08 14:39:13 +0100 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-12-08 14:39:40 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-12-08 14:40:08 +0100 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) |
| 2022-12-08 14:40:17 +0100 | califax | (~califax@user/califx) |
| 2022-12-08 14:41:21 +0100 | <opqdonut> | lovely |
| 2022-12-08 14:45:40 +0100 | califax | (~califax@user/califx) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-12-08 14:45:47 +0100 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) (Ping timeout: 255 seconds) |
| 2022-12-08 14:46:41 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds) |
| 2022-12-08 14:48:08 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2022-12-08 14:49:58 +0100 | <[exa]> | > dɐɯɟ (Just 5) negate |
| 2022-12-08 14:50:00 +0100 | <lambdabot> | error: |
| 2022-12-08 14:50:00 +0100 | <lambdabot> | Variable not in scope: dɐɯɟ :: Maybe a0 -> (a1 -> a1) -> t |
| 2022-12-08 14:50:01 +0100 | <Profpatsch> | Player-205[m]: The (999 :: Word8) == 231 is the same as 999 `mod` 256 == 231 |
| 2022-12-08 14:50:16 +0100 | <Profpatsch> | Because a Word8 can only fit 256 |
| 2022-12-08 14:50:23 +0100 | <Profpatsch> | 255 |
| 2022-12-08 14:50:38 +0100 | <[exa]> | I can't wait for `for = dɐɯ` |
| 2022-12-08 14:50:43 +0100 | califax | (~califax@user/califx) |
| 2022-12-08 14:50:46 +0100 | <int-e> | Hecate: I think the idea is that since 999 is too big to fit into a Word8, only the 99 part should be parsed. Which... I guess is a possible design choice, though I would definitely not agree that reads @Word8 "999" == [(99, "9")] is a *good* choice |
| 2022-12-08 14:50:56 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-12-08 14:50:57 +0100 | <Profpatsch> | Haskell uses the common behaviour of modular arithmetic for the underlying function |
| 2022-12-08 14:51:42 +0100 | <int-e> | (I'd have more sympathy with a parse error, but that's not the choice the library designers made.) |
| 2022-12-08 14:53:31 +0100 | <Profpatsch> | int-e: for Enum/Bounded types, the docs say “The calls succ maxBound and pred minBound should result in a runtime error.” |
| 2022-12-08 14:53:38 +0100 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 246 seconds) |
| 2022-12-08 14:53:43 +0100 | <Profpatsch> | and “fromEnum and toEnum should give a runtime error if the result value is not representable in the result type” |
| 2022-12-08 14:53:50 +0100 | <Hecate> | int-e: hence my question about the presence of this pattern elsewhere, I'm quite susoucuiys about it |
| 2022-12-08 14:53:54 +0100 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 2022-12-08 14:53:59 +0100 | <Profpatsch> | So arguably GHC wrapping integer literals is the wrong behaviour |
| 2022-12-08 14:55:04 +0100 | <int-e> | Hecate: Right, but that's a question for Player205[m]. |
| 2022-12-08 14:55:20 +0100 | <Hecate> | aye |
| 2022-12-08 14:57:19 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a76b0b8eea36f8bd0e7.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-12-08 14:57:51 +0100 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) |
| 2022-12-08 14:57:53 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-12-08 14:58:43 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-12-08 14:58:43 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-12-08 15:00:05 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2022-12-08 15:00:37 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2022-12-08 15:02:43 +0100 | califax | (~califax@user/califx) |
| 2022-12-08 15:02:59 +0100 | jpds2 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-12-08 15:05:05 +0100 | <dminuoso> | Profpatsch: Indeed, and this is actually common in other parser combinator libraries sadly |
| 2022-12-08 15:05:38 +0100 | <dminuoso> | https://hackage.haskell.org/package/attoparsec-0.14.4/docs/Data-Attoparsec-Text.html#v:decimal |
| 2022-12-08 15:05:40 +0100 | <dminuoso> | decimal :: Integral a => Parser a |
| 2022-12-08 15:05:42 +0100 | <Profpatsch> | dminuoso: It’s highly non-trivial to not get random wrapping |
| 2022-12-08 15:05:50 +0100 | <Profpatsch> | like, it’s easy to make a mistake |
| 2022-12-08 15:05:50 +0100 | <dminuoso> | It's not. |
| 2022-12-08 15:05:57 +0100 | <dminuoso> | I think its very trivial |
| 2022-12-08 15:06:06 +0100 | festive_kurbus | (~festive_k@user/kurbus) |
| 2022-12-08 15:06:36 +0100 | <Profpatsch> | dminuoso: let’s say wrapping behaviour is pervasive simply because it’s the default & the easiest thing to reach for |
| 2022-12-08 15:06:44 +0100 | <Profpatsch> | and it looks correct for simple examples |
| 2022-12-08 15:06:57 +0100 | <dminuoso> | I think the basic problem lies in the type annotation for this. |
| 2022-12-08 15:07:01 +0100 | <Profpatsch> | and it silently corrupts your data :) |
| 2022-12-08 15:07:18 +0100 | <dminuoso> | So the main problem in `decimal` from attoparsec, is that the type is incredibly deceiptful |
| 2022-12-08 15:07:23 +0100 | <dminuoso> | If instead it read: |
| 2022-12-08 15:07:28 +0100 | <dminuoso> | `decimal :: Parser Integer` |
| 2022-12-08 15:07:42 +0100 | <dminuoso> | Then it would be dead obvious if you wanted to turn this into a Word8 you either have to check bounds, or accept some overflow behavior. |
| 2022-12-08 15:07:46 +0100 | <Profpatsch> | dminuoso: yes, our internal parsers wrap it like this |
| 2022-12-08 15:08:05 +0100 | <Profpatsch> | the base problem is that `fromInteger` should not exist |
| 2022-12-08 15:08:13 +0100 | <Profpatsch> | It’s a design issue in `Num` |
| 2022-12-08 15:08:21 +0100 | <dminuoso> | https://hackage.haskell.org/package/int-cast should be part of base. |
| 2022-12-08 15:08:46 +0100 | <Profpatsch> | fromIntegral |
| 2022-12-08 15:08:58 +0100 | <Profpatsch> | (fromIntegral and fromInteger both existing is another design problem) |
| 2022-12-08 15:09:26 +0100 | <dminuoso> | Profpatsch: another problem with the attoparsec style is that it provides for denial of service vectors |
| 2022-12-08 15:09:42 +0100 | <Profpatsch> | dminuoso: It depends |
| 2022-12-08 15:09:52 +0100 | <Profpatsch> | if you are parsing Scientific -> Integer then yes |
| 2022-12-08 15:09:55 +0100 | <dminuoso> | Since even if you do explicit bounds checks, it will first attempt to parse an arbitrarily long number |
| 2022-12-08 15:09:57 +0100 | <Profpatsch> | but if you are going Text -> Integer |
| 2022-12-08 15:09:58 +0100 | <int-e> | > read ('"' : repeat ' ') :: Int |
| 2022-12-08 15:10:04 +0100 | <lambdabot> | mueval-core: Time limit exceeded |
| 2022-12-08 15:10:22 +0100 | <Profpatsch> | then you need the same (or rather: more) memory just for having the Text first |
| 2022-12-08 15:10:28 +0100 | <Profpatsch> | so I’d argue it’s not a DoS |
| 2022-12-08 15:10:43 +0100 | <dminuoso> | Profpatsch: Which is why my flatparser `readInt` will directly just calculate the number along the way and fail on overflow, rather than going through Integer first. |
| 2022-12-08 15:11:04 +0100 | <dminuoso> | Profpatsch: Not necessarily, in megaparsec or attoparsec it could be streamed. |
| 2022-12-08 15:11:12 +0100 | <Profpatsch> | unless you parse incrementally, but then you already have a problem in your setup if you can be passed a number that explodes your RAM |
| 2022-12-08 15:11:14 +0100 | money | (money@user/polo) () |
| 2022-12-08 15:11:50 +0100 | <Profpatsch> | As I said, parsing numbers is a highly nontrivial thing to do unfortunately :( |
| 2022-12-08 15:12:02 +0100 | <dminuoso> | I dont think of it as highly nontrivial. |
| 2022-12-08 15:12:02 +0100 | Ybombinator | (~Ybombinat@85.254.75.8) (Ping timeout: 268 seconds) |
| 2022-12-08 15:12:10 +0100 | <dminuoso> | Its very trivial, you just need to be explicit about what you want |
| 2022-12-08 15:12:21 +0100 | <Profpatsch> | like, if you are parsing a JSON then your json can already blow up your memory |
| 2022-12-08 15:12:30 +0100 | <Profpatsch> | unless you have e.g. a http body size restriction |
| 2022-12-08 15:12:38 +0100 | <Profpatsch> | same for Text -> Integer |
| 2022-12-08 15:12:51 +0100 | <Profpatsch> | But Scientific -> Integer is a different class of exploitable |
| 2022-12-08 15:13:02 +0100 | <Profpatsch> | cause the memory blowup is not linear with input size |
| 2022-12-08 15:13:32 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-12-08 15:13:37 +0100 | <dminuoso> | Besides, part of why I dont like roundtripping through Integer is that by default you will pay some performance penalties. |
| 2022-12-08 15:14:16 +0100 | <Profpatsch> | dminuoso: I agree, I will replace Atto with your library if it ever becomes a performance bottleneck :) |
| 2022-12-08 15:14:52 +0100 | <Profpatsch> | Integer is like two orders of magnitude less performant than an unboxed Int64 |
| 2022-12-08 15:14:52 +0100 | dminuoso | has replaced most of his attoparsec usages with flatparse already :) |
| 2022-12-08 15:14:57 +0100 | <Profpatsch> | maybe more |
| 2022-12-08 15:15:11 +0100 | <dminuoso> | Profpatsch: Well, depending on usage its probably not a big deal since if you immediately case-of it will disappear anyway |
| 2022-12-08 15:15:58 +0100 | <dminuoso> | At any rate, the bigger problem in attoparsec is not going through Integer, its that it will automatically fromIntegral for you. |
| 2022-12-08 15:16:00 +0100 | <Profpatsch> | dminuoso: hm, if you want to go back to `Int` again, then you have to either have a branch & throw an error manually, or you are back to wrapping behaviour. |
| 2022-12-08 15:16:06 +0100 | <dminuoso> | Yup |
| 2022-12-08 15:16:14 +0100 | <Profpatsch> | So either slow or wrong |
| 2022-12-08 15:16:18 +0100 | <dminuoso> | well "fsvo" slow. |
| 2022-12-08 15:16:27 +0100 | <dminuoso> | It's only going to be a bunch of cpu instructions realistically |
| 2022-12-08 15:16:40 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 256 seconds) |
| 2022-12-08 15:16:47 +0100 | <Profpatsch> | In a tight parsing loop that’s a lot |
| 2022-12-08 15:17:11 +0100 | <Profpatsch> | But then why are you using Haskell in the first place :P |
| 2022-12-08 15:18:58 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-12-08 15:19:20 +0100 | <dminuoso> | Sure, but if you're already in that tight of a loop and that branch cost becomes relevant, you probably should not be using attoparsec anyway |
| 2022-12-08 15:19:32 +0100 | festive_kurbus | (~festive_k@user/kurbus) (Quit: Client closed) |
| 2022-12-08 15:20:06 +0100 | cybersoul | (~cybersoul@2405:201:680a:b01d:8ad:2a0c:230c:f77) (Quit: Leaving) |
| 2022-12-08 15:20:06 +0100 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Remote host closed the connection) |
| 2022-12-08 15:21:13 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-12-08 15:22:29 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) |
| 2022-12-08 15:27:15 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) (Ping timeout: 260 seconds) |
| 2022-12-08 15:30:50 +0100 | raehik | (~raehik@213.86.197.10) |
| 2022-12-08 15:44:23 +0100 | kenran | (~user@user/kenran) |
| 2022-12-08 15:46:59 +0100 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-12-08 15:47:39 +0100 | califax | (~califax@user/califx) (Read error: Connection reset by peer) |
| 2022-12-08 15:47:39 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-12-08 15:47:39 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Write error: Connection reset by peer) |
| 2022-12-08 15:47:39 +0100 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) (Write error: Connection reset by peer) |
| 2022-12-08 15:47:39 +0100 | jpds2 | (~jpds@gateway/tor-sasl/jpds) (Write error: Connection reset by peer) |
| 2022-12-08 15:51:06 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-12-08 15:51:06 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-12-08 15:51:06 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-12-08 15:53:30 +0100 | raehik | (~raehik@213.86.197.10) (Ping timeout: 260 seconds) |
| 2022-12-08 15:56:07 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-12-08 15:57:20 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 246 seconds) |
| 2022-12-08 15:58:04 +0100 | danza | (~francesco@93.176.139.150) |
| 2022-12-08 15:59:14 +0100 | <kuribas> | integers in sbcl (CL) are pretty fast |
| 2022-12-08 15:59:40 +0100 | <kuribas> | it uses machine integers until an overflow occurs, then switches to bigints |
| 2022-12-08 15:59:51 +0100 | <merijn> | kuribas: I mean, so does GHC :p |
| 2022-12-08 15:59:59 +0100 | <kuribas> | merijn: then why is it so much slower? |
| 2022-12-08 16:00:16 +0100 | <merijn> | Citation Needed? |
| 2022-12-08 16:01:18 +0100 | <kuribas> | merijn: above comment by ProfPatch |
| 2022-12-08 16:01:26 +0100 | <kuribas> | Profpatsch |
| 2022-12-08 16:01:55 +0100 | <kuribas> | <Profpatsch> Integer is like two orders of magnitude less performant than an unboxed Int64 |
| 2022-12-08 16:02:09 +0100 | <kuribas> | perhaps when storing them in a vector... |
| 2022-12-08 16:02:19 +0100 | <merijn> | It Depends (TM) on a billion things |
| 2022-12-08 16:02:19 +0100 | <kuribas> | looping over an unboxed vector is pretty fast. |
| 2022-12-08 16:02:23 +0100 | <[exa]> | was the integer boxed? |
| 2022-12-08 16:02:35 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 248 seconds) |
| 2022-12-08 16:03:11 +0100 | <merijn> | kuribas: I mean, SBCL and GHC use (or at least used) the same bigint implementation :p |
| 2022-12-08 16:03:14 +0100 | <merijn> | kuribas: https://www.wilfred.me.uk/blog/2014/10/20/the-fastest-bigint-in-the-west/ |
| 2022-12-08 16:03:55 +0100 | <merijn> | ah, wait, sbcl doesn't use GMP |
| 2022-12-08 16:04:26 +0100 | <kuribas> | merijn: but sbcl uses machine integers until they overflow, then it switches to bigint. |
| 2022-12-08 16:04:44 +0100 | <kuribas> | merijn: I suppose ghc always uses bigint for Integer? |
| 2022-12-08 16:04:44 +0100 | <c_wraith> | so does Integer, last I checked |
| 2022-12-08 16:04:50 +0100 | <kuribas> | right |
| 2022-12-08 16:04:51 +0100 | <merijn> | kuribas: GHC uses machine integers and overflows into GMP |
| 2022-12-08 16:05:16 +0100 | <merijn> | kuribas: https://hackage.haskell.org/package/ghc-bignum-1.3/docs/src/GHC.Num.Integer.html#Integer |
| 2022-12-08 16:06:10 +0100 | Chai-T-Rex | (~ChaiTRex@user/chaitrex) |
| 2022-12-08 16:06:33 +0100 | califax | (~califax@user/califx) |
| 2022-12-08 16:07:49 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-12-08 16:08:10 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-12-08 16:09:10 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-12-08 16:11:48 +0100 | jpds2 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-12-08 16:12:06 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) |
| 2022-12-08 16:12:53 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-12-08 16:16:43 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2022-12-08 16:18:46 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2022-12-08 16:19:41 +0100 | jpds2 | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2022-12-08 16:21:36 +0100 | shapr | (~user@68.54.166.125) |
| 2022-12-08 16:22:46 +0100 | raehik | (~raehik@213.86.197.10) |
| 2022-12-08 16:22:54 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2022-12-08 16:24:16 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2022-12-08 16:25:22 +0100 | jpds2 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-12-08 16:26:14 +0100 | <dolio> | What is "pretty fast"? |
| 2022-12-08 16:26:39 +0100 | <dolio> | Have you checked that SBCL's integers aren't two orders of magnitude slower than unboxed Int64? |
| 2022-12-08 16:27:47 +0100 | raehik | (~raehik@213.86.197.10) (Ping timeout: 264 seconds) |
| 2022-12-08 16:30:17 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2022-12-08 16:30:37 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2022-12-08 16:32:52 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-12-08 16:33:09 +0100 | <dminuoso> | Here is a cute take on query generation with postgresql-simple and nanolenses: https://gist.github.com/dminuoso/2f30d91630cb5dbf168765ce3bac8a74 |
| 2022-12-08 16:35:32 +0100 | gwern | (~gwern@user/gwern) |
| 2022-12-08 16:35:39 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-12-08 16:38:02 +0100 | <gwern> | so I have a (sigh) stdin question. for a cli utility, I want to read any stdin contents if there are any, and otherwise continue processing CLI arguments as normal. even using strict IO.getContents, not unsurprisingly, winds up blocking indefinitely. what do? |
| 2022-12-08 16:38:25 +0100 | <dminuoso> | In some of my uses I have to massage queries into CTEs first, so I can have a singular uniform where clause at the end. :) |
| 2022-12-08 16:39:26 +0100 | <dminuoso> | gwern: hGetBufNonBlocking perhaps? |
| 2022-12-08 16:39:36 +0100 | <merijn> | gwern: You want System.IO |
| 2022-12-08 16:39:46 +0100 | <merijn> | gwern: and/or the ByteString/Text versions |
| 2022-12-08 16:40:02 +0100 | <merijn> | gwern: Which have all the standard read/write operations on files you are used to in other languages |
| 2022-12-08 16:40:23 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-12-08 16:40:38 +0100 | <dminuoso> | Indeed, bytestring has hGetNonBlocking directly, which is a bit more comfortable to use than hGetBufNonBlocking (which you likely have to massage into a bytestring anyway) |
| 2022-12-08 16:40:54 +0100 | <gwern> | 'hGetBufNonBlocking is identical to hGetBuf, except that it will never block waiting for data to become available, instead it returns only whatever data is available. To wait for data to arrive before calling hGetBufNonBlocking, use hWaitForInput.' https://hackage.haskell.org/package/base-4.17.0.0/docs/System-IO.html#v:hGetBufNonBlocking hm... |
| 2022-12-08 16:40:59 +0100 | <merijn> | https://hackage.haskell.org/package/base-4.17.0.0/docs/System-IO.html#g:2 |
| 2022-12-08 16:41:01 +0100 | <merijn> | https://hackage.haskell.org/package/bytestring-0.11.3.1/docs/Data-ByteString.html#g:27 |
| 2022-12-08 16:41:09 +0100 | <merijn> | https://hackage.haskell.org/package/text-2.0.1/docs/Data-Text-IO.html |
| 2022-12-08 16:41:21 +0100 | <dminuoso> | https://hackage.haskell.org/package/bytestring-0.11.3.1/docs/Data-ByteString.html#v:hGetNonBlocking |
| 2022-12-08 16:41:24 +0100 | <dminuoso> | In particular for bytestring |
| 2022-12-08 16:41:37 +0100 | <dminuoso> | merijn: I dont think text has a non-blocking interface for this |
| 2022-12-08 16:42:00 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-12-08 16:42:07 +0100 | <merijn> | dminuoso: Sure, but you can test for data availability |
| 2022-12-08 16:42:28 +0100 | <dminuoso> | How do you do that? |
| 2022-12-08 16:42:48 +0100 | <dminuoso> | Oh you mean with hGetContents? |
| 2022-12-08 16:42:56 +0100 | <geekosaur> | hWaitForInput? |
| 2022-12-08 16:43:13 +0100 | <geekosaur> | no, that blocksa |
| 2022-12-08 16:43:20 +0100 | <merijn> | handroll something application specific using STM :p |
| 2022-12-08 16:43:25 +0100 | <dminuoso> | Im really not sure how you can do any of this without hGetBufNonBlocking |
| 2022-12-08 16:43:28 +0100 | <dminuoso> | (directly or indirectly) |
| 2022-12-08 16:43:42 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-12-08 16:43:43 +0100 | <dminuoso> | The bytestring wrapper is what you would end up buildign anyway, so I would just use that |
| 2022-12-08 16:44:39 +0100 | <merijn> | https://hackage.haskell.org/package/base-4.17.0.0/docs/System-IO.html#v:hReady |
| 2022-12-08 16:45:01 +0100 | <dminuoso> | Ah! That would work yes. |
| 2022-12-08 16:45:40 +0100 | <merijn> | gwern: At any rate, as you can see, plenty of tools besides getContents :) |
| 2022-12-08 16:46:06 +0100 | <gwern> | er, I suppose. I'm still staring at all the constructors a Handle apparently requires |
| 2022-12-08 16:46:27 +0100 | <gwern> | ('NoBuffering ReadMode nativeNewline' ok... but wtf is a 'dev') |
| 2022-12-08 16:47:12 +0100 | <merijn> | gwern: I mean, there is a pre-defined stdin Handle ;) |
| 2022-12-08 16:47:30 +0100 | <merijn> | And you're not really supposed to hand make them |
| 2022-12-08 16:47:42 +0100 | <gwern> | oh, of course it'd be in an entirely diferent module... https://hackage.haskell.org/package/base-4.14.1.0/docs/GHC-IO-Handle-FD.html#v:stdin -_- |
| 2022-12-08 16:47:47 +0100 | <merijn> | % :t System.IO.stdin |
| 2022-12-08 16:47:47 +0100 | <yahb2> | System.IO.stdin :: GHC.IO.Handle.Types.Handle |
| 2022-12-08 16:48:06 +0100 | <merijn> | gwern: stdin is just in/exported from System.IO |
| 2022-12-08 16:48:07 +0100 | <Guest75> | Hello. In my code, I seldom randomly access a list (!!), mostly iterate over it, and also need pattern match (x:xs). At the same time I intercat a lot with Aeson. Should I still prefer List over Vector for my data? |
| 2022-12-08 16:48:10 +0100 | <merijn> | together with stdout/stderr |
| 2022-12-08 16:48:11 +0100 | <dminuoso> | "Merijn's Amazing Handle Manufactory" |
| 2022-12-08 16:49:36 +0100 | <dminuoso> | Guest75: You can stick to vector, and if you want to pattern match on it regularly, you could make yourself a pattern synonym |
| 2022-12-08 16:50:01 +0100 | <gwern> | merijn: yes, but I'm not reading System.IO because that's not where 'hGetBufNonBlocking' is documented. and where 'hGetBufNonBlocking' is documented, 'Handle' hyperlinks you to https://hackage.haskell.org/package/base-4.14.1.0/docs/GHC-IO-Handle.html#t:Handle and inside GHC.IO.Handle there is no indication of a predefined 'stdin' (I did C-f but the only mention of 'stdin' didn't seem to have... |
| 2022-12-08 16:50:07 +0100 | <gwern> | ...anything to do with a predefined stdin Handle) |
| 2022-12-08 16:50:07 +0100 | <dminuoso> | Guest75: Its hard to say in general, though |
| 2022-12-08 16:50:13 +0100 | <byorgey> | Guest75: are you saying that your code currently uses lists? |
| 2022-12-08 16:50:41 +0100 | <Guest75> | yes. I have written it using lists. and doing (V.toList a) a lot |
| 2022-12-08 16:50:53 +0100 | <byorgey> | Guest75: is it too slow? Or is the performance acceptable? |
| 2022-12-08 16:51:11 +0100 | <Guest75> | I think acceptable. I didn't measure |
| 2022-12-08 16:51:24 +0100 | <byorgey> | ok, then if I were you I wouldn't bother updating to use Vector |
| 2022-12-08 16:51:35 +0100 | <Guest75> | aha. thanks |
| 2022-12-08 16:51:56 +0100 | <Guest75> | OTOH I should always prefer Text over String right? :-) |
| 2022-12-08 16:52:09 +0100 | <byorgey> | It depends =) |
| 2022-12-08 16:52:28 +0100 | <Guest75> | Does string support unicode? :/ |
| 2022-12-08 16:52:29 +0100 | <dminuoso> | gwern: though keep in mind, that hReady could result in a TOCTOU race |
| 2022-12-08 16:52:36 +0100 | <byorgey> | But in general, yes, Text is a better default |
| 2022-12-08 16:52:42 +0100 | <byorgey> | yes, String supports unicode |
| 2022-12-08 16:52:45 +0100 | <byorgey> | because Char does |
| 2022-12-08 16:52:49 +0100 | <Guest75> | aha |
| 2022-12-08 16:52:58 +0100 | <dminuoso> | Guest75: which if you end up using blocking hGetContents will leave you unhappy |
| 2022-12-08 16:53:05 +0100 | <dminuoso> | gwern: sorry. |
| 2022-12-08 16:54:00 +0100 | <Guest75> | dminuoso: that's for sterams, or something.... Like stdin/stdout I believe |
| 2022-12-08 16:54:14 +0100 | <dminuoso> | Guest75: I meant another person, sorry. |
| 2022-12-08 16:54:25 +0100 | <Guest75> | ah np |
| 2022-12-08 16:54:25 +0100 | ubert1 | (~Thunderbi@2a02:8109:abc0:6434:ca01:21c9:7b00:2bcf) |
| 2022-12-08 16:54:36 +0100 | <dminuoso> | 16:52:36 byorgey | But in general, yes, Text is a better default |
| 2022-12-08 16:54:41 +0100 | <dminuoso> | I wish I could say that with your confidence. |
| 2022-12-08 16:55:05 +0100 | <dminuoso> | While I *want* it to be a better default, the frequency by which you have to pack your text back to satisfy other folks interfaces.. |
| 2022-12-08 16:55:15 +0100 | <dminuoso> | Or unpack rather, I suppose. |
| 2022-12-08 16:57:24 +0100 | Guest75 | is still trying to remember the order of TL.decodeUtf8 TL.pack |
| 2022-12-08 16:58:19 +0100 | gwern | certainly spends a ridiuculous amount of time, code, and computer time packing and unpacking strings into various types |
| 2022-12-08 16:58:31 +0100 | <gwern> | for example, right now... |
| 2022-12-08 16:58:42 +0100 | <gwern> | '• Couldn't match type ‘GHC.Word.Word8’ with ‘Char’ Expected: String' hello darkness my old friend |
| 2022-12-08 17:00:18 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:9ec2:49f5:ac35:545a) (Quit: WeeChat 2.8) |
| 2022-12-08 17:01:45 +0100 | <shapr> | ghci 8.10.7 on termux on Android doesn't want to load .so files. I can't tell if it's user error or a limitation of ghci on Android. Any hints where I could learn more? |
| 2022-12-08 17:04:12 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) (Quit: opticblast) |
| 2022-12-08 17:04:23 +0100 | <shapr> | That is, on x86 this works: ghci -L. -lchallenge_ristretto_ffi |
| 2022-12-08 17:04:26 +0100 | <maerwald> | uhm, d_type returns trash on armv7 |
| 2022-12-08 17:04:27 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) |
| 2022-12-08 17:05:23 +0100 | <shapr> | maerwald: meaning, I shouldn't expect this to work on aarch64? |
| 2022-12-08 17:05:41 +0100 | <maerwald> | no, totally unrelated |
| 2022-12-08 17:05:48 +0100 | raehik | (~raehik@213.86.197.10) |
| 2022-12-08 17:05:55 +0100 | <geekosaur> | shapr, I make no promises but termux abuses interfaces everywhere to work at all and ghci using its own loader instead of dlopen and friends probably breaks it |
| 2022-12-08 17:06:07 +0100 | <maerwald> | ghcup is broken on armv7 because d_type values are absolute nonsense |
| 2022-12-08 17:06:15 +0100 | <maerwald> | but it doesn't look like memory corruption either |
| 2022-12-08 17:06:39 +0100 | <maerwald> | the dirent struct has d_type clearly defined |
| 2022-12-08 17:07:54 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 255 seconds) |
| 2022-12-08 17:08:03 +0100 | <shapr> | Hm, I'll see if GHC will do the right thing compiling source with FFI calls. |
| 2022-12-08 17:13:10 +0100 | festive_kurbus | (~festive_k@user/kurbus) |
| 2022-12-08 17:13:45 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-12-08 17:16:14 +0100 | <gwern> | looks like `stdin <- fmap E.decodeUtf8 $ Data.ByteString.hGetNonBlocking System.IO.stdin 999999` using 'import System.IO (stdin) / import qualified Data.ByteString (hGetNonBlocking) / import Data.Text.Encoding as E (decodeUtf8)' works |
| 2022-12-08 17:17:24 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 248 seconds) |
| 2022-12-08 17:18:11 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 260 seconds) |
| 2022-12-08 17:18:46 +0100 | <gwern> | dminuoso: yeah, the race condition is fine here because my usecase is something like "$ echo 'https://en.wikipedia.org/wiki/Subvocalization' | changeTag.hs psychology/inner-monologue" - given how long it takes ghci to boot up, all stdin inputs should be available eons before ghci ever gets around to hGetNonBlocking, and since it's intended for my interactive use, in the unusual case where the... |
| 2022-12-08 17:18:52 +0100 | <gwern> | ...race condition drops inputs and bypasses other checks like '>=2 arguments total', I will notice either by the logging output omitting a particular URL or eventually because that URL didn't get tagged right |
| 2022-12-08 17:21:19 +0100 | <dminuoso> | gwern: I was thinking of things like fork rather. |
| 2022-12-08 17:23:11 +0100 | <gwern> | (oh. hm, there's some recursion here but no OS-level fork() or anything so I shouldn't have to worry about anything like that) |
| 2022-12-08 17:24:32 +0100 | Kaiepi | (~Kaiepi@108.175.84.104) (Ping timeout: 246 seconds) |
| 2022-12-08 17:26:14 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.7.1) |
| 2022-12-08 17:28:01 +0100 | raehik | (~raehik@213.86.197.10) (Ping timeout: 252 seconds) |
| 2022-12-08 17:29:05 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2022-12-08 17:29:06 +0100 | jpds2 | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2022-12-08 17:31:24 +0100 | danza | (~francesco@93.176.139.150) (Ping timeout: 268 seconds) |
| 2022-12-08 17:31:30 +0100 | Kaiepi | (~Kaiepi@108.175.84.104) |
| 2022-12-08 17:31:52 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) |
| 2022-12-08 17:32:17 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-12-08 17:32:29 +0100 | jpds2 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-12-08 17:34:19 +0100 | nschoe | (~q@141.101.51.197) (Ping timeout: 248 seconds) |
| 2022-12-08 17:35:35 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 264 seconds) |
| 2022-12-08 17:44:16 +0100 | <sm> | making that a stack script would speed it up (recompiles as needed) |
| 2022-12-08 17:44:29 +0100 | danza | (~francesco@93.176.139.150) |
| 2022-12-08 17:46:39 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) |
| 2022-12-08 17:55:25 +0100 | <carbolymer> | is there a dark version of hackage? my floaters are pissing me off |
| 2022-12-08 17:56:05 +0100 | <shapr> | does that help? |
| 2022-12-08 17:56:52 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-12-08 18:03:27 +0100 | shapr | (~user@68.54.166.125) (Remote host closed the connection) |
| 2022-12-08 18:06:43 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2022-12-08 18:07:42 +0100 | <maerwald[m]> | dminuoso: https://github.com/haskell/ghcup-hs/issues/415#issuecomment-1343005271 |
| 2022-12-08 18:07:51 +0100 | <maerwald[m]> | Any ideas? |
| 2022-12-08 18:09:17 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-12-08 18:09:56 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-12-08 18:10:08 +0100 | <maerwald[m]> | Maybe some endiannes bug |
| 2022-12-08 18:10:22 +0100 | <maerwald[m]> | But doesn't happen on aarch64 |
| 2022-12-08 18:10:54 +0100 | festive_kurbus | (~festive_k@user/kurbus) (Quit: Client closed) |
| 2022-12-08 18:15:34 +0100 | festive_kurbus | (~festive_k@user/kurbus) |
| 2022-12-08 18:15:37 +0100 | mbuf | (~Shakthi@49.205.85.230) (Remote host closed the connection) |
| 2022-12-08 18:16:48 +0100 | pagnol | (~user@213-205-209-87.ftth.glasoperator.nl) |
| 2022-12-08 18:18:47 +0100 | Guest141 | (~Guest14@76.136.124.61) |
| 2022-12-08 18:19:07 +0100 | Guest141 | (~Guest14@76.136.124.61) (Client Quit) |
| 2022-12-08 18:22:29 +0100 | MajorBiscuit | (~MajorBisc@145.94.137.174) (Ping timeout: 260 seconds) |
| 2022-12-08 18:22:47 +0100 | <pagnol> | what is this called? for all x, f (g x) = x |
| 2022-12-08 18:24:28 +0100 | <monochrom> | f is the left inverse of g, g is the right inverse of f. I may have "left" and "right" missplaced. |
| 2022-12-08 18:26:56 +0100 | ubert1 | (~Thunderbi@2a02:8109:abc0:6434:ca01:21c9:7b00:2bcf) (Quit: ubert1) |
| 2022-12-08 18:29:29 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-12-08 18:31:39 +0100 | <c_wraith> | there are lots of other names for more specialized cases, but I'm not sure that matters. |
| 2022-12-08 18:36:05 +0100 | AlexZenon | (~alzenon@178.34.151.8) (Ping timeout: 255 seconds) |
| 2022-12-08 18:36:24 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-12-08 18:36:37 +0100 | festive_kurbus | (~festive_k@user/kurbus) (Quit: Client closed) |
| 2022-12-08 18:36:46 +0100 | Alex_test | (~al_test@178.34.151.8) (Ping timeout: 268 seconds) |
| 2022-12-08 18:37:39 +0100 | bazoo | (~bazoo@93.51.40.51) |
| 2022-12-08 18:40:42 +0100 | AlexZenon | (~alzenon@178.34.151.8) |
| 2022-12-08 18:41:29 +0100 | Alex_test | (~al_test@178.34.151.8) |
| 2022-12-08 18:42:41 +0100 | <bazoo> | Is it possible in Haskell to declare an integer type parametrized over its min and max values so that it's checked at compile time? |
| 2022-12-08 18:44:00 +0100 | <mauke> | no |
| 2022-12-08 18:45:50 +0100 | <bazoo> | Not even with almost-dependent-types extensions? |
| 2022-12-08 18:45:52 +0100 | <geekosaur> | checking such at compile time requires that you carry around compile-time proofs that it is within the value limits, else it requires runtime checking |
| 2022-12-08 18:46:12 +0100 | <geekosaur> | as yet dependent types aren't even remotely supported enough to do this |
| 2022-12-08 18:46:23 +0100 | <c_wraith> | You can fake it if you're fine with only having literals |
| 2022-12-08 18:46:41 +0100 | <c_wraith> | If you ever need a non-literal, you need runtime checking |
| 2022-12-08 18:46:56 +0100 | <bazoo> | I guess it would require both compile time and runtime checks, am I right? I guess it's what happens when you have a fixed vector and you apply fromList, for instance, right? |
| 2022-12-08 18:47:15 +0100 | <c_wraith> | though if you want to go a different direction, you can get a lot of that sort of checking at compile time from liquid haskell |
| 2022-12-08 18:48:46 +0100 | <bazoo> | LiquidHaskell seems interesting but I would love to keep inside GHC |
| 2022-12-08 18:49:28 +0100 | <geekosaur> | you're looking at the wrong language, really. this is idris stuff, not ghc |
| 2022-12-08 18:51:31 +0100 | festive_kurbus | (~festive_k@user/kurbus) |
| 2022-12-08 18:51:50 +0100 | thyriaen | (~thyriaen@2a01:aea0:dd4:4bae:6245:cbff:fe9f:48b1) |
| 2022-12-08 18:53:45 +0100 | beteigeuze | (~Thunderbi@85.247.81.220) |
| 2022-12-08 18:54:43 +0100 | <mauke> | if you could declare such a type, you couldn't use the usual Num operators with it |
| 2022-12-08 18:55:22 +0100 | <mauke> | like, imagine a + b where a, b :: BoundedInt 1 10 |
| 2022-12-08 18:55:27 +0100 | <mauke> | the result type would be wrong |
| 2022-12-08 18:57:07 +0100 | danza | (~francesco@93.176.139.150) (Ping timeout: 268 seconds) |
| 2022-12-08 19:02:11 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 19:03:19 +0100 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2022-12-08 19:03:34 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-12-08 19:04:51 +0100 | econo | (uid147250@user/econo) |
| 2022-12-08 19:05:04 +0100 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 260 seconds) |
| 2022-12-08 19:08:16 +0100 | CiaoSen | (~Jura@p200300c95747e0002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-12-08 19:09:08 +0100 | <bazoo> | mauke it kinda makes sense actually |
| 2022-12-08 19:16:57 +0100 | <dminuoso> | maerwald[m]: I cant make heads or tails of it. It cant be an endianness bug, because d_type is an `unsigned char` in glibc. |
| 2022-12-08 19:19:00 +0100 | <dminuoso> | It seems that all the dir types are just rubbish. Im feeling a memory corruption here. |
| 2022-12-08 19:19:06 +0100 | <dminuoso> | Or a general memory bug. |
| 2022-12-08 19:19:07 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 19:19:56 +0100 | razetime | (~quassel@49.207.203.213) (Ping timeout: 268 seconds) |
| 2022-12-08 19:20:40 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) (Remote host closed the connection) |
| 2022-12-08 19:20:53 +0100 | <dminuoso> | If you restart ghci, do you consistently get the same dir types? |
| 2022-12-08 19:24:17 +0100 | <dminuoso> | My gut feeling says there's a severe bug in GHC code generation here. |
| 2022-12-08 19:24:35 +0100 | <dminuoso> | maerwald[m]: try removing `c_freeDirEnt` as an experiment. |
| 2022-12-08 19:25:34 +0100 | <dminuoso> | Though not even that makes sense. Mmm |
| 2022-12-08 19:31:05 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2022-12-08 19:31:38 +0100 | danza | (~francesco@4.red-79-153-154.dynamicip.rima-tde.net) |
| 2022-12-08 19:34:10 +0100 | <geekosaur> | what version of ghc? could this be related to the ARM types thing in 9.2? |
| 2022-12-08 19:34:31 +0100 | califax | (~califax@user/califx) |
| 2022-12-08 19:35:12 +0100 | <dminuoso> | Wrong ARM version though |
| 2022-12-08 19:35:24 +0100 | <geekosaur> | true |
| 2022-12-08 19:35:24 +0100 | <dminuoso> | 9.2.1 received ARMv8 native code, but this is an ARMv7 problem |
| 2022-12-08 19:36:10 +0100 | <dminuoso> | Given that the dir entry names are read off correctly, either the offset of the dir_type is wrong, or there's some severe code generation bug. |
| 2022-12-08 19:36:30 +0100 | <dminuoso> | (Heh, or both) |
| 2022-12-08 19:36:45 +0100 | <dminuoso> | I would probably look into the generated assembly here |
| 2022-12-08 19:38:10 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) |
| 2022-12-08 19:38:28 +0100 | ft | (~ft@p508dbd59.dip0.t-ipconnect.de) |
| 2022-12-08 19:46:20 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-12-08 19:46:20 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-12-08 19:46:20 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-12-08 19:51:02 +0100 | <EvanR> | bazoo, if you try to do what you said in haskell, you will learn a lot xD |
| 2022-12-08 19:51:21 +0100 | <EvanR> | probably worth it |
| 2022-12-08 19:51:59 +0100 | <EvanR> | haskells type system can technically express a lot but it won't necessarily be ergonomic |
| 2022-12-08 19:52:21 +0100 | hochata | (~user@2806:104e:1b:16dd:2b68:28db:d39:1f54) |
| 2022-12-08 19:52:53 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a16f8a8efad5ebd7081.dip0.t-ipconnect.de) |
| 2022-12-08 19:53:22 +0100 | <geekosaur> | it still won'[t work with anything but constants. and forget about negative numbers |
| 2022-12-08 19:53:39 +0100 | <geekosaur> | (unless you want to represent them as a positive number plus a type level Bool) |
| 2022-12-08 19:54:12 +0100 | bobbingbob | (~dfadsva@2604:3d09:207f:f650::7b3a) |
| 2022-12-08 19:54:37 +0100 | hochata | (~user@2806:104e:1b:16dd:2b68:28db:d39:1f54) (Client Quit) |
| 2022-12-08 19:55:15 +0100 | hochata | (~user@2806:104e:1b:16dd:2b68:28db:d39:1f54) |
| 2022-12-08 19:55:23 +0100 | thegeekinside | (~thegeekin@189.217.82.244) |
| 2022-12-08 19:56:57 +0100 | thegeekinside | (~thegeekin@189.217.82.244) (Remote host closed the connection) |
| 2022-12-08 19:59:13 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) (Remote host closed the connection) |
| 2022-12-08 20:01:14 +0100 | <EvanR> | constant type level numbers is an example of where there is special support for egonomics |
| 2022-12-08 20:01:15 +0100 | jle`` | (~jusle@user/jle/x-3894663) |
| 2022-12-08 20:01:26 +0100 | codaraxis__ | (~codaraxis@user/codaraxis) |
| 2022-12-08 20:01:31 +0100 | <jle``> | i forgot the name of the thing that does 'traverse' but in reverse, and you get it for free from a Representable instance |
| 2022-12-08 20:02:06 +0100 | <EvanR> | but you can technically construct a whole system of arithmetic to express concepts like intervals and what happens when intervals collide |
| 2022-12-08 20:02:18 +0100 | <jle``> | ah yeah it's Distributive |
| 2022-12-08 20:03:08 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) |
| 2022-12-08 20:03:25 +0100 | gmg | (~user@user/gehmehgeh) |
| 2022-12-08 20:03:56 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-12-08 20:04:33 +0100 | akegalj | (~akegalj@141-136-183-112.dsl.iskon.hr) (Quit: leaving) |
| 2022-12-08 20:05:15 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2022-12-08 20:05:30 +0100 | codaraxis | (~codaraxis@user/codaraxis) (Ping timeout: 260 seconds) |
| 2022-12-08 20:07:11 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-12-08 20:07:27 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-12-08 20:10:07 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-12-08 20:14:31 +0100 | <monochrom> | I'm an egomaniac. I love egonomics. >:) |
| 2022-12-08 20:16:24 +0100 | <dolio> | Study of Egon Spengler? |
| 2022-12-08 20:16:28 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 20:16:37 +0100 | <EvanR> | and this is why IRC lack of message editing is a feature |
| 2022-12-08 20:20:35 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 264 seconds) |
| 2022-12-08 20:22:09 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 20:29:44 +0100 | <Guillaum[m]> | I would like to do something like: "acquireResource >> doSomething >> async (doATask `finally` releaseResource) >> doSomethingElse". Said otherwise, I want to aquire a resource, start a thread, and do a computation which releases the resource at the end of the computation. However I want to be sure the resource is released. In the current implementation, if something happen before `finally` is setup (so any exception INSIDE the async but |
| 2022-12-08 20:29:44 +0100 | <Guillaum[m]> | before the finally, or outside the async (before it is even started), I will lose my resource. |
| 2022-12-08 20:33:01 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-12-08 20:34:49 +0100 | nschoe | (~q@2a01:e0a:8e:a190:c70e:2102:82d3:a45a) |
| 2022-12-08 20:34:49 +0100 | nschoe | (~q@2a01:e0a:8e:a190:c70e:2102:82d3:a45a) (Client Quit) |
| 2022-12-08 20:37:24 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-12-08 20:38:28 +0100 | festive_kurbus | (~festive_k@user/kurbus) (Quit: Client closed) |
| 2022-12-08 20:39:15 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-12-08 20:40:23 +0100 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2022-12-08 20:42:46 +0100 | <EvanR> | the point of async is so you can trust the spawn and unspawn part of the process, instead of second guessing your forkIO code |
| 2022-12-08 20:43:53 +0100 | festive_kurbus | (~festive_k@user/kurbus) |
| 2022-12-08 20:44:13 +0100 | <EvanR> | something happening "between" async and finally is the async libraries responsibility |
| 2022-12-08 20:45:19 +0100 | <EvanR> | nevermind I see this is a large "should be a bracket" thing |
| 2022-12-08 20:45:25 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 20:45:57 +0100 | <EvanR> | you don't even release the resource on problem with the first doSomething |
| 2022-12-08 20:47:23 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 260 seconds) |
| 2022-12-08 20:47:36 +0100 | <EvanR> | If I read into this you want to release a resource early if possible, instead of putting a bracket around the entire thing. You can do that by building idempotence into your cleanup action. Make it ok to call twice |
| 2022-12-08 20:49:04 +0100 | emad | (~emad@102.40.212.34) |
| 2022-12-08 20:49:09 +0100 | codaraxis___ | (~codaraxis@user/codaraxis) |
| 2022-12-08 20:49:14 +0100 | emad | (~emad@102.40.212.34) (Remote host closed the connection) |
| 2022-12-08 20:52:42 +0100 | codaraxis__ | (~codaraxis@user/codaraxis) (Ping timeout: 256 seconds) |
| 2022-12-08 20:53:25 +0100 | <bazoo> | EvanR thanks, but I wonder at this point if it's possible at all. geekosaur anything but constants means that values for such a type must be known at compile time? |
| 2022-12-08 20:53:45 +0100 | <geekosaur> | yes |
| 2022-12-08 20:54:07 +0100 | <geekosaur> | you need runtime witnnesses of some kind for non-constant values |
| 2022-12-08 20:54:34 +0100 | Xeroine | (~Xeroine@user/xeroine) (Remote host closed the connection) |
| 2022-12-08 20:54:41 +0100 | <EvanR> | bazoo, possible and reasonably possible might be very far apart here |
| 2022-12-08 20:55:09 +0100 | <EvanR> | if you remove reasonable, you can imagine some really out there logic for what you want to happen |
| 2022-12-08 20:55:26 +0100 | <EvanR> | at compile time, maybe you don't know things like future user input, but you can still check the logic of working with what you eventually read |
| 2022-12-08 20:55:54 +0100 | Xeroine | (~Xeroine@user/xeroine) |
| 2022-12-08 20:56:02 +0100 | <EvanR> | e.g. x + (y + z) still equal (x + y) + z even if you don't know what they are yet. |
| 2022-12-08 20:56:22 +0100 | <EvanR> | every such step of logic can be encoded as a type class |
| 2022-12-08 20:56:51 +0100 | <zzz> | what's a more canonical way of doing `[(a -> a)] -> a -> a` than `foldr1 (.) [...]`? |
| 2022-12-08 20:57:18 +0100 | <EvanR> | foldr (.) id |
| 2022-12-08 20:58:19 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 21:00:15 +0100 | <EvanR> | if you want to get gratuitous, appEndo . foldMap Endo |
| 2022-12-08 21:02:39 +0100 | mixfix41 | (~sdenynine@user/mixfix41) (Ping timeout: 260 seconds) |
| 2022-12-08 21:02:56 +0100 | <dsal> | appendo sounds like one of the elf characters from Disenchantment |
| 2022-12-08 21:03:14 +0100 | <zzz> | i remember doing something elegant for this but maybe it's a false memory |
| 2022-12-08 21:03:15 +0100 | shapr | (~user@68.54.166.125) |
| 2022-12-08 21:05:13 +0100 | <zzz> | what about `f <$> [...] ? a`? |
| 2022-12-08 21:05:23 +0100 | <zzz> | where i want a -> a |
| 2022-12-08 21:05:32 +0100 | <EvanR> | what is ? |
| 2022-12-08 21:05:48 +0100 | <zzz> | something |
| 2022-12-08 21:05:51 +0100 | <zzz> | i dont know |
| 2022-12-08 21:06:38 +0100 | <EvanR> | also might be silly to ask... which order do you want to apply the functions in |
| 2022-12-08 21:06:51 +0100 | <zzz> | i was just signaling that f is constant |
| 2022-12-08 21:07:03 +0100 | <zzz> | dont care about order |
| 2022-12-08 21:07:33 +0100 | <dsal> | :t fix . fold |
| 2022-12-08 21:07:34 +0100 | <lambdabot> | (Foldable t, Monoid c) => t (c -> c) -> c |
| 2022-12-08 21:07:46 +0100 | <EvanR> | oh nice |
| 2022-12-08 21:07:47 +0100 | <dsal> | :t foldMap fix |
| 2022-12-08 21:07:48 +0100 | <lambdabot> | (Foldable t, Monoid m) => t (m -> m) -> m |
| 2022-12-08 21:08:07 +0100 | <dsal> | I assume those functions do the same thing. |
| 2022-12-08 21:09:17 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 21:09:26 +0100 | <zzz> | oh i think that was it! |
| 2022-12-08 21:09:41 +0100 | <dsal> | Really? I'm just in "throw out a bad idea" mode. |
| 2022-12-08 21:09:52 +0100 | <zzz> | ahah i love bad ideas |
| 2022-12-08 21:09:59 +0100 | <dsal> | We should hang out. |
| 2022-12-08 21:10:22 +0100 | <zzz> | that sounds like a bad idea |
| 2022-12-08 21:10:27 +0100 | <dsal> | Yeah, love it. |
| 2022-12-08 21:10:28 +0100 | <zzz> | i'm in |
| 2022-12-08 21:12:06 +0100 | <zzz> | than again maybe that asn'tit |
| 2022-12-08 21:12:09 +0100 | <monochrom> | You never know whether a bad idea becomes a good idea. I'm in. |
| 2022-12-08 21:12:12 +0100 | <zzz> | *wasn't it |
| 2022-12-08 21:12:33 +0100 | <EvanR> | buy bad idea coin today |
| 2022-12-08 21:12:55 +0100 | CiaoSen | (~Jura@p200300c95747e0002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-12-08 21:12:56 +0100 | hochata | (~user@2806:104e:1b:16dd:2b68:28db:d39:1f54) (Remote host closed the connection) |
| 2022-12-08 21:13:27 +0100 | <dsal> | I missed the initial `a` |
| 2022-12-08 21:13:29 +0100 | <dsal> | :t foldMap iterate |
| 2022-12-08 21:13:30 +0100 | <lambdabot> | Foldable t => t (a -> a) -> a -> [a] |
| 2022-12-08 21:13:49 +0100 | <dsal> | But then you want a single entry. Which entry? |
| 2022-12-08 21:13:53 +0100 | <dsal> | :t fold . foldMap iterate |
| 2022-12-08 21:13:56 +0100 | <lambdabot> | (Foldable t, Foldable ((->) a)) => t (a -> a) -> [a] |
| 2022-12-08 21:14:13 +0100 | <monochrom> | foldMap fix [f, g, h] = fix f <> fix g <> fix h = probably not what you want |
| 2022-12-08 21:14:18 +0100 | <dsal> | :t (fold .) . foldMap iterate |
| 2022-12-08 21:14:19 +0100 | <lambdabot> | (Monoid c, Foldable t) => t (c -> c) -> c -> c |
| 2022-12-08 21:15:03 +0100 | <EvanR> | I missed the part where `a' was a monoid to be monoided |
| 2022-12-08 21:15:14 +0100 | <zzz> | i regret having started this |
| 2022-12-08 21:15:34 +0100 | <monochrom> | Yeah, if fix f = foo :: X, we require X to be a Monoid instance. |
| 2022-12-08 21:16:06 +0100 | <monochrom> | At any rate, first of all we require "fix f" to make sense at all. (Usually it doesn't.) |
| 2022-12-08 21:24:30 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) (Remote host closed the connection) |
| 2022-12-08 21:27:05 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 21:27:36 +0100 | festive_kurbus | (~festive_k@user/kurbus) (Quit: Client closed) |
| 2022-12-08 21:28:05 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2022-12-08 21:29:06 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-12-08 21:29:31 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-12-08 21:34:10 +0100 | money | (money@user/polo) |
| 2022-12-08 21:37:09 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 21:41:38 +0100 | bazoo | (~bazoo@93.51.40.51) (Ping timeout: 260 seconds) |
| 2022-12-08 21:42:01 +0100 | <EvanR> | it makes sense if and only if f is broken |
| 2022-12-08 21:42:38 +0100 | <EvanR> | such as error |
| 2022-12-08 21:43:00 +0100 | hueso | (~root@user/hueso) (Ping timeout: 268 seconds) |
| 2022-12-08 21:44:06 +0100 | <Guillaum[m]> | EvanR: Thank you for your answer. I'll try to come with a more detailled version of my problem because that's not something that a "huge" bracket can solve right now. |
| 2022-12-08 21:45:40 +0100 | <EvanR> | for some reason I had the vague idea that a resource acquired by some thread or process should be ultimately responsible for releasing it, even if it crashes (or a child uncontrolled crashes) |
| 2022-12-08 21:45:48 +0100 | pavonia | (~user@user/siracusa) |
| 2022-12-08 21:46:11 +0100 | <dminuoso> | EvanR: who should be responsbile for releasing it? the resource? |
| 2022-12-08 21:46:23 +0100 | <dminuoso> | (that's what it says grammatically) |
| 2022-12-08 21:46:24 +0100 | <EvanR> | the same thread or process |
| 2022-12-08 21:46:42 +0100 | <EvanR> | Agreed I made no literal sense |
| 2022-12-08 21:46:57 +0100 | stef204 | (~stef204@user/stef204) |
| 2022-12-08 21:47:02 +0100 | <dminuoso> | Not entirely sure what "the thread is responsible" even means |
| 2022-12-08 21:47:40 +0100 | <EvanR> | all actions are executed by some thread |
| 2022-12-08 21:47:46 +0100 | <dminuoso> | Are you suggesting every resource acquired should be registered as a finalizer to the thread? |
| 2022-12-08 21:47:50 +0100 | mmhat | (~mmh@p200300f1c73b51dfee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-12-08 21:47:56 +0100 | <dminuoso> | (to the thread responsible for acquisition I mean) |
| 2022-12-08 21:48:07 +0100 | <EvanR> | no |
| 2022-12-08 21:48:36 +0100 | <EvanR> | not specifically talking about a mechanism to do it, or a blanket global policy everything has to do |
| 2022-12-08 21:48:46 +0100 | <dminuoso> | In the sense of ResourceT? |
| 2022-12-08 21:48:59 +0100 | <dminuoso> | Or how would it differ from ResourceT? |
| 2022-12-08 21:49:08 +0100 | <EvanR> | but guillaum is acquiring a resource in thread 1, then attempting to release it in, at least, a child thread |
| 2022-12-08 21:49:40 +0100 | <EvanR> | sounds it just sounds complicated |
| 2022-12-08 21:49:45 +0100 | <EvanR> | so it just sounds complicated |
| 2022-12-08 21:51:03 +0100 | <dminuoso> | It will be brittle because you would need a lot of code regions masked |
| 2022-12-08 21:51:32 +0100 | <dminuoso> | Guillaum[m]: But what you *can* do is use message passing to signal that you're done with the resource |
| 2022-12-08 21:51:49 +0100 | <EvanR> | looks like ResourceT has a way to share a resource among many threads and use reference counting to finally release it |
| 2022-12-08 21:52:00 +0100 | <dminuoso> | So one thread creates and finally destroys it, and in between it waits on say an MVar |
| 2022-12-08 21:52:15 +0100 | <dminuoso> | And the consumer thread puts into the MVar if its done |
| 2022-12-08 21:52:27 +0100 | avicenzi | (~avicenzi@2a00:ca8:a1f:b004::c32) (Ping timeout: 252 seconds) |
| 2022-12-08 21:52:28 +0100 | <dminuoso> | Yeah |
| 2022-12-08 21:52:37 +0100 | <dminuoso> | resourcet seems like the saner approach |
| 2022-12-08 21:52:44 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 21:53:19 +0100 | <Guillaum[m]> | More details if you want. I'm creating a job scheduling mechanism. I have a "main" thread which schedules jobs. It is a loop which checks redis, and if there is something on redis, starts an async to execute a task, and restart checking redis. I have a number of available tokens, so I won't schedule more tasks than available tokens. However, a task can "suspend" itself (i.e. wait), hence can release a token, so another task is scheduled. |
| 2022-12-08 21:53:19 +0100 | <Guillaum[m]> | Eventually, the task will end its wait (so use another token), and at the end of the process, the task should release the final token. |
| 2022-12-08 21:54:43 +0100 | <EvanR> | sounds like a job for an MVar or TVar with number of free tokens in it |
| 2022-12-08 21:55:10 +0100 | pagnol | (~user@213-205-209-87.ftth.glasoperator.nl) (Ping timeout: 260 seconds) |
| 2022-12-08 21:55:26 +0100 | <EvanR> | on crash thread puts the token back |
| 2022-12-08 21:55:38 +0100 | Cale | (~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com) (Read error: Connection reset by peer) |
| 2022-12-08 21:56:22 +0100 | bobbingbob | (~dfadsva@2604:3d09:207f:f650::7b3a) (Quit: Leaving) |
| 2022-12-08 21:56:37 +0100 | <Guillaum[m]> | EvanR: actually that's a TVar with the number of free tokens. And the code is as such: forever $ do { takeToken; task <- getATaskFromRedis; async (runTask task `finally` releaseToken) } |
| 2022-12-08 21:57:13 +0100 | <EvanR> | getATaskFromRedis could crash |
| 2022-12-08 21:57:24 +0100 | <Guillaum[m]> | Yes, that's the problem here |
| 2022-12-08 21:57:44 +0100 | <EvanR> | the task of getting and doing a task... is it's own task xD |
| 2022-12-08 21:58:58 +0100 | <dsal> | So, I'm looking at recursion schemes and am somewhat confused by this: hylo :: Functor f => (f b -> b) -> (a -> f a) -> a -> b |
| 2022-12-08 21:59:13 +0100 | <dsal> | How does this work when not a~b ? |
| 2022-12-08 21:59:19 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-12-08 21:59:20 +0100 | <EvanR> | a dedicated worker thread that continually gets tasks and makes them (reliably) available to the rest of the program might simplify that |
| 2022-12-08 21:59:33 +0100 | <dsal> | This `b` seems to come out of nowhere. |
| 2022-12-08 22:00:00 +0100 | <EvanR> | with a mechanism to log problems and attempt to restore the worker if it fails |
| 2022-12-08 22:00:37 +0100 | <EvanR> | as a self contained subpiece of the whole application |
| 2022-12-08 22:01:18 +0100 | <EvanR> | if you had that, then just getting the next available task "can't fail" |
| 2022-12-08 22:01:32 +0100 | <EvanR> | from the perspective of your code there |
| 2022-12-08 22:02:08 +0100 | <dsal> | If edwardk were around, he could probably explain it to someone who could explain it to me. |
| 2022-12-08 22:02:30 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2022-12-08 22:02:48 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2022-12-08 22:04:09 +0100 | <EvanR> | note having an f b to pass into that function doesn't mean you had a `b' to begin with |
| 2022-12-08 22:04:43 +0100 | <dsal> | Yeah, but my understanding is that the result of the second thing is given to the first thing. |
| 2022-12-08 22:04:48 +0100 | <EvanR> | and to get an f b from an f a, you can use fmap |
| 2022-12-08 22:05:08 +0100 | <dsal> | Oh. Right. |
| 2022-12-08 22:05:25 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 22:05:44 +0100 | <monochrom> | Oh! That does it. |
| 2022-12-08 22:06:24 +0100 | <dsal> | I'm still a bit confused. I guess I just need to make something work around. |
| 2022-12-08 22:06:55 +0100 | <dsal> | I'd expect that first thing to be `f a -> a` since it's ostensibly the result of the other thing, but it's magicaller than that. |
| 2022-12-08 22:06:58 +0100 | <monochrom> | The source code goes "hylo f g = h where h = f . fmap h . g", if it helps. |
| 2022-12-08 22:07:35 +0100 | <monochrom> | I feel like there is some Löb going on there. |
| 2022-12-08 22:07:54 +0100 | <monochrom> | But type-wise, yeah fmap bridges the gap from f a to f b. |
| 2022-12-08 22:08:17 +0100 | <EvanR> | yeah, "but to use fmap, I need an function a -> b". Which is what hylo is |
| 2022-12-08 22:08:48 +0100 | <monochrom> | I guess hence h needs itself :) |
| 2022-12-08 22:09:19 +0100 | <EvanR> | thanks to types I can answer the question an have no idea what's going on |
| 2022-12-08 22:09:33 +0100 | <Guillaum[m]> | EvanR: I've started to think about a refactor actually, but I was wondering if there was an easy solution for the problem as it is currently designed without too much rewrite. |
| 2022-12-08 22:09:57 +0100 | <iqubic> | dsal: You need to get from (f a -> f b) and you have hylo :: (f b -> b) -> (a -> f a) -> a -> b. Notice that if you run hylo, you get (a -> b), which lets you fmap properly. |
| 2022-12-08 22:10:42 +0100 | <dsal> | So it's just like hylo (fmap a2b) (a2somef) a ? |
| 2022-12-08 22:10:59 +0100 | dsal | should really be asking ghci |
| 2022-12-08 22:11:45 +0100 | <iqubic> | Well, hylo is the fuction you are trying to create, so you'd have to do it recursively |
| 2022-12-08 22:12:05 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 22:12:19 +0100 | <dsal> | No, hylo is the function I'm trying to use. |
| 2022-12-08 22:12:43 +0100 | <EvanR> | to do what exactly |
| 2022-12-08 22:13:54 +0100 | <dsal> | For example, I've got some code that takes an (Int, Int), expands it to an [(Int, Int)] and then collapses that to some monoid. |
| 2022-12-08 22:14:37 +0100 | <dsal> | So ignoring the signature, something like hylo length expansionThing (3,3) |
| 2022-12-08 22:14:48 +0100 | <EvanR> | what's a and b |
| 2022-12-08 22:15:01 +0100 | <dsal> | a is (Int, Int) and b is Int |
| 2022-12-08 22:15:28 +0100 | <EvanR> | cool |
| 2022-12-08 22:15:49 +0100 | <EvanR> | so yeah fmap a2b doesn't sound necessary or correct there |
| 2022-12-08 22:16:08 +0100 | <dsal> | No, I realized that when I got to ghci. |
| 2022-12-08 22:16:19 +0100 | <dsal> | It's the wrong direction. |
| 2022-12-08 22:17:08 +0100 | <EvanR> | f b -> b is like... takes the list of tree heights and returns how cells you can go before hitting a too high tree? |
| 2022-12-08 22:17:15 +0100 | <EvanR> | how many* |
| 2022-12-08 22:17:24 +0100 | <dsal> | Yeah. |
| 2022-12-08 22:18:09 +0100 | <EvanR> | well there's that |
| 2022-12-08 22:18:12 +0100 | <dsal> | I wrote a thing that feels like a hylomorphism, except it's just monoids. At least part of it seems like it should work with hylo except the type signature isn't what I'd expect. |
| 2022-12-08 22:18:17 +0100 | stef204 | (~stef204@user/stef204) (Quit: WeeChat 3.7.1) |
| 2022-12-08 22:18:25 +0100 | <EvanR> | use that as the first argument |
| 2022-12-08 22:18:26 +0100 | Cale | (~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com) |
| 2022-12-08 22:18:46 +0100 | <dsal> | For a simple case, I'm trying `sum` |
| 2022-12-08 22:19:28 +0100 | <dsal> | hylo sum :: (Functor f, Foldable f, Num b) => (a -> f a) -> a -> b |
| 2022-12-08 22:19:37 +0100 | huskle | (~huskle@250.79-105-213.static.virginmediabusiness.co.uk) |
| 2022-12-08 22:21:24 +0100 | <huskle> | here, i have more code |
| 2022-12-08 22:21:25 +0100 | <huskle> | https://paste.tomsmeding.com/zWqd6p7J |
| 2022-12-08 22:21:30 +0100 | <EvanR> | hylo sum rayNorthFrom (2,4) |
| 2022-12-08 22:21:44 +0100 | <huskle> | look at my code! look at my code!! |
| 2022-12-08 22:22:04 +0100 | <dsal> | hylo sum (\x -> [1 .. x]) 2 -- this stack overflows. |
| 2022-12-08 22:22:20 +0100 | gdd | (~gdd@129.199.146.230) (Ping timeout: 246 seconds) |
| 2022-12-08 22:22:30 +0100 | <huskle> | its the best code ever! |
| 2022-12-08 22:22:45 +0100 | <EvanR> | given how we implemented hylo I'm not that surprised xD |
| 2022-12-08 22:22:46 +0100 | <dsal> | hylo sum Identity 5 -- this just never terminates |
| 2022-12-08 22:23:03 +0100 | <EvanR> | maybe if you used lazy naturals |
| 2022-12-08 22:23:40 +0100 | <dsal> | hylo sum (const [1, 2, 3]) 5 -- still blows up. I clearly have no idea what I'm doing. |
| 2022-12-08 22:24:03 +0100 | <dsal> | Maybe I should understand the anamorphism first. |
| 2022-12-08 22:24:18 +0100 | <EvanR> | hylo f g = h where h = f . fmap h . g |
| 2022-12-08 22:24:37 +0100 | <dolio> | You're asking for the sum of an infinite tree. |
| 2022-12-08 22:24:54 +0100 | <dsal> | Yeah, I'm not sure how finite emerges here. |
| 2022-12-08 22:25:00 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) |
| 2022-12-08 22:25:02 +0100 | <dolio> | 2 ==> [1,2] ==> [[1],[1,2]] ==> ... |
| 2022-12-08 22:25:09 +0100 | <dsal> | ooooh |
| 2022-12-08 22:25:32 +0100 | <dsal> | OK, this makes a bit more sense now. |
| 2022-12-08 22:25:36 +0100 | <huskle> | https://paste.pics/KAJNC |
| 2022-12-08 22:25:42 +0100 | <huskle> | this is the graph of the output |
| 2022-12-08 22:27:09 +0100 | <huskle> | its a amplitude modulated parametric sin wave, where the amplitude modulation is parametric noise which is smoothly differentiable in its parameters |
| 2022-12-08 22:27:27 +0100 | <huskle> | you can smoothly shift the frequency, phase, or any of the noise shifts! |
| 2022-12-08 22:27:34 +0100 | <EvanR> | sum [sum [sum [sum [... |
| 2022-12-08 22:27:40 +0100 | <huskle> | so you can do gradient descent on them as basis elements! |
| 2022-12-08 22:28:19 +0100 | mmhat | (~mmh@p200300f1c73b51dfee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-12-08 22:28:29 +0100 | <huskle> | and they are trivially initialisable from fft, as the noises average to unity |
| 2022-12-08 22:28:38 +0100 | <huskle> | then you can do k-hard thresholding |
| 2022-12-08 22:28:54 +0100 | <huskle> | its the best thing EVER |
| 2022-12-08 22:30:09 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 22:30:33 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:30d2:fcaf:3b1c:ad43) (Ping timeout: 256 seconds) |
| 2022-12-08 22:31:51 +0100 | <huskle> | it even has a song! https://www.youtube.com/watch?v=2oe2sxBZ6nY |
| 2022-12-08 22:32:23 +0100 | <EvanR> | Busta Rhymes DANGEROUS |
| 2022-12-08 22:34:14 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 255 seconds) |
| 2022-12-08 22:34:45 +0100 | euandreh | (~Thunderbi@179.214.113.107) |
| 2022-12-08 22:35:13 +0100 | <dsal> | I guess recursion-schemes fails me again because my problem isn't quite recursive in the way this helps. |
| 2022-12-08 22:35:18 +0100 | <jean-paul[m]> | is https://medium.com/@zw3rk/the-haskell-cabal-and-cross-compilation-e9885fd5e2f pretty much the story for Cabal and cross-compilation? |
| 2022-12-08 22:36:18 +0100 | <huskle> | EvanR: my whole entire Unit is dangerous... |
| 2022-12-08 22:36:19 +0100 | gmg | (~user@user/gehmehgeh) |
| 2022-12-08 22:36:46 +0100 | <EvanR> | there may be a way to rephrase the problem to be recursive? |
| 2022-12-08 22:36:59 +0100 | <EvanR> | but it feels like stretching at this point |
| 2022-12-08 22:37:07 +0100 | huskle | (~huskle@250.79-105-213.static.virginmediabusiness.co.uk) (Quit: Connection closed) |
| 2022-12-08 22:37:11 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 22:37:18 +0100 | <dsal> | Yeah, that's kind of the problem I run into each time I try to use recursion-schemes. |
| 2022-12-08 22:38:30 +0100 | <dsal> | My current solution is fine. It's just got `(Semigroup s1, Semigroup s2) => (Word8 -> [Word8] -> s1) -> (s1 -> s2) -> Grid -> s2` and I was hoping there were something fancier I could use than foldMapping a foldMap, but the turtles stop there. |
| 2022-12-08 22:38:57 +0100 | <geekosaur> | jean-paul[m], the real problem is ghc doesn't really support cross-compilation that well, so neither cabal nor stack can support it very well either |
| 2022-12-08 22:39:18 +0100 | <dsal> | At each point, we expand the points of view and then collapse that down to the appropriate semigroup, which kind of feels like it matches, but that only happens once. |
| 2022-12-08 22:39:41 +0100 | <jean-paul[m]> | What does it mean that it does not support it "that well"? It has _some_ support... |
| 2022-12-08 22:40:58 +0100 | gmg | (~user@user/gehmehgeh) (Client Quit) |
| 2022-12-08 22:41:04 +0100 | <jean-paul[m]> | reflex-platform does some stuff for aarch64 and the Haskell parts seem to work okay (at least at some simple level). But if I try to add, say, pkgconfig-depends to a .cabal file then cabal runs the wrong pkg-config to try to resolve it. |
| 2022-12-08 22:41:11 +0100 | <EvanR> | notHylo :: (f b -> b) -> (a -> f a) -> (a -> b) -> a -> b |
| 2022-12-08 22:41:39 +0100 | <EvanR> | notHylo h g f = h . fmap f . g |
| 2022-12-08 22:42:08 +0100 | mmhat | (~mmh@p200300f1c73b51d2ee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-12-08 22:42:41 +0100 | <EvanR> | Functor f => |
| 2022-12-08 22:44:10 +0100 | <EvanR> | since the tree height is already what you need... it's more like h . g xD |
| 2022-12-08 22:44:12 +0100 | <geekosaur> | jean-paul[m], probably best asked in #hackage (which for some reason is the cabal channel) |
| 2022-12-08 22:44:49 +0100 | <dsal> | EvanR: Yeah, that's kind of it. But I'm doing folds, so it's really just… foldMap |
| 2022-12-08 22:44:58 +0100 | <geekosaur> | but I think those simple cases are the limit of what ghc can handle and it would mishandle the pkg-config output |
| 2022-12-08 22:45:01 +0100 | gdd | (~gdd@2001:470:1f13:187:e8a5:fbff:fe29:42f5) |
| 2022-12-08 22:45:26 +0100 | <jean-paul[m]> | geekosaur: Ok, thanks |
| 2022-12-08 22:46:07 +0100 | <dsal> | I could try it on day 7, but my day7 is also foldMap. |
| 2022-12-08 22:46:39 +0100 | phma | (~phma@host-67-44-208-200.hnremote.net) (Read error: Connection reset by peer) |
| 2022-12-08 22:47:01 +0100 | Topsi | (~Topsi@dyndsl-095-033-225-177.ewe-ip-backbone.de) |
| 2022-12-08 22:47:17 +0100 | phma | (phma@2001:5b0:215d:cc28:414c:6f3a:6804:56b7) |
| 2022-12-08 22:48:33 +0100 | hueso | (~root@user/hueso) |
| 2022-12-08 22:48:37 +0100 | EvanR_ | (~EvanR@user/evanr) |
| 2022-12-08 22:50:20 +0100 | EvanR | (~EvanR@user/evanr) (Ping timeout: 246 seconds) |
| 2022-12-08 22:51:49 +0100 | EvanR_ | EvanR |
| 2022-12-08 22:52:09 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Quit: euandreh) |
| 2022-12-08 22:54:25 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 23:01:27 +0100 | <EvanR> | downloading the dwarf fortress binary, and it not loading due to binary incompatibilities, or on OSX, loading but showing no graphics and not responding to input or signals |
| 2022-12-08 23:01:56 +0100 | <EvanR> | makes me wonder about viability for haskell static everything in games xD |
| 2022-12-08 23:02:00 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-12-08 23:02:55 +0100 | <EvanR> | is it just a given any program for PC must be continually recompiled and rereleased by a human |
| 2022-12-08 23:03:11 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 23:03:26 +0100 | <Rembane> | This is so that computers cannot take over the world. |
| 2022-12-08 23:03:34 +0100 | <EvanR> | built in self destruct |
| 2022-12-08 23:03:52 +0100 | <Rembane> | Indeed. Like cells killing themselves when things go weird. |
| 2022-12-08 23:05:01 +0100 | <dsal> | I don't mind computers taking over the world. I've got other stuff to do. |
| 2022-12-08 23:05:41 +0100 | <Rembane> | If they take over the world the only thing you're allowed to do is to update Javascript dependencies. |
| 2022-12-08 23:06:30 +0100 | <dsal> | What if I just stop feeding them? |
| 2022-12-08 23:06:45 +0100 | <Rembane> | I think that's the background story to the Matrix |
| 2022-12-08 23:07:09 +0100 | <Rembane> | So I guess that if you get yourself really sweet sunglasses and black shiny clothes you should be good. |
| 2022-12-08 23:07:19 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-12-08 23:07:36 +0100 | EvanR | climbs up and updates "days since the matrix reference" to 0 |
| 2022-12-08 23:07:50 +0100 | <c_wraith> | EvanR: did the Haskell game have the same installation problems for you? |
| 2022-12-08 23:08:03 +0100 | <c_wraith> | Defect Process. that's the one. |
| 2022-12-08 23:08:08 +0100 | <EvanR> | oh never played it |
| 2022-12-08 23:09:57 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 268 seconds) |
| 2022-12-08 23:10:07 +0100 | <c_wraith> | 'cause if the author hadn't posted on r/haskell, I'd never have known it was written in Haskell. It's just a game, from an outside POV |
| 2022-12-08 23:11:11 +0100 | <EvanR> | yeah the concern I have is not about a program working at a point in time, but working in a wide range of times before and after, ok not before but after, it's built |
| 2022-12-08 23:11:30 +0100 | <EvanR> | so it's hard to test |
| 2022-12-08 23:12:34 +0100 | <EvanR> | I don't know if there's any difference with haskell really vs C++ |
| 2022-12-08 23:14:48 +0100 | <c_wraith> | I've got a friend working on a game in C++ and fennel (a lua-based lisp), and she has reported the majority of her problems come from getting various C++ builds to work, especially as she goes between windows and linux. It's not easy. |
| 2022-12-08 23:16:05 +0100 | <monochrom> | It is still nice to know that some games actually sold on Steam are written in Haskell. Or even written in something other than C++ at all. |
| 2022-12-08 23:16:14 +0100 | <monochrom> | Helps break stereotypes. |
| 2022-12-08 23:16:48 +0100 | <EvanR> | that's actually mindblowing kind of |
| 2022-12-08 23:17:17 +0100 | <dminuoso> | `is_block_mergeable >>= \case True -> ... False -> ...` |
| 2022-12-08 23:17:22 +0100 | <c_wraith> | https://incoherentsoftware.com/defect-process/docs/ there's a high-level design doc, if you're interested |
| 2022-12-08 23:17:22 +0100 | <dminuoso> | Would you consider this an acceptable style? |
| 2022-12-08 23:17:37 +0100 | <monochrom> | Yes. |
| 2022-12-08 23:17:44 +0100 | <c_wraith> | dminuoso: I do that sometimes. linters hate me, but I think it's better than if, inside a do block. |
| 2022-12-08 23:17:53 +0100 | <monochrom> | One of 10 acceptable styles. :) |
| 2022-12-08 23:18:20 +0100 | <dminuoso> | heh |
| 2022-12-08 23:18:20 +0100 | <monochrom> | I also accept "x <- is_block_mergeable; if x then ... else ..." |
| 2022-12-08 23:18:25 +0100 | <mauke> | >>= ([..., ...] !!) . fromEnum |
| 2022-12-08 23:18:45 +0100 | <monochrom> | haha now that's cute but not on my accept list :) |
| 2022-12-08 23:18:46 +0100 | <dminuoso> | I dislike the then/else parts of the if-then-else construct. Case-of has always read more natural to me mmm |
| 2022-12-08 23:18:51 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-12-08 23:18:55 +0100 | <c_wraith> | I agree |
| 2022-12-08 23:19:24 +0100 | <monochrom> | Customers who dislike then-else may like: MultiwayIf >:) |
| 2022-12-08 23:19:41 +0100 | <c_wraith> | of course, these days there's also >>= bool (...) (...) |
| 2022-12-08 23:19:46 +0100 | dminuoso | prefers `case () of _ | -> ... ` over MultiwayIf |
| 2022-12-08 23:19:49 +0100 | <dminuoso> | Maybe Im strange |
| 2022-12-08 23:20:04 +0100 | <EvanR> | LambdaCase is cool, should be in vanilla |
| 2022-12-08 23:20:16 +0100 | <dminuoso> | Isnt it part of GHC202whenever? |
| 2022-12-08 23:20:18 +0100 | <mauke> | @pl if_ c t f = (f : t : []) !! fromEnum c |
| 2022-12-08 23:20:18 +0100 | <lambdabot> | if_ = flip (flip . ((!!) .) . flip (:) . return) . fromEnum |
| 2022-12-08 23:20:41 +0100 | <monochrom> | GHC2021 is vanillin >:) |
| 2022-12-08 23:21:07 +0100 | <c_wraith> | :t bool -- this has been in base for quite a while now. |
| 2022-12-08 23:21:08 +0100 | <lambdabot> | a -> a -> Bool -> a |
| 2022-12-08 23:21:20 +0100 | <dminuoso> | monochrom: So only one thing out of the hundred extensions we desire? |
| 2022-12-08 23:21:44 +0100 | <mauke> | @pl if_ t f c = (f : t : []) !! fromEnum c |
| 2022-12-08 23:21:44 +0100 | <lambdabot> | if_ = flip flip fromEnum . (((.) . (!!)) .) . flip (:) . return |
| 2022-12-08 23:21:46 +0100 | <EvanR> | boolM :: m a -> m a -> m Bool -> m a |
| 2022-12-08 23:21:50 +0100 | <EvanR> | I hate this |
| 2022-12-08 23:22:03 +0100 | <EvanR> | Monad m => |
| 2022-12-08 23:22:49 +0100 | <c_wraith> | EvanR: that one seems below the Fairbairn threshold |
| 2022-12-08 23:23:02 +0100 | <monochrom> | Oh, just sparking another controversy similar to "natural" vs "synthetic". |
| 2022-12-08 23:23:09 +0100 | <c_wraith> | of course. |
| 2022-12-08 23:25:18 +0100 | tomokojun | (~tomokojun@37.19.221.173) |
| 2022-12-08 23:25:42 +0100 | <mauke> | https://www.okmij.org/ftp/Haskell/bothTrue.txt if Oleg does it, it can't be bad |
| 2022-12-08 23:27:12 +0100 | <monochrom> | w00t comp.lang.functional |
| 2022-12-08 23:27:19 +0100 | <c_wraith> | hah. "without pattern matching" is sure a funny target. |
| 2022-12-08 23:27:23 +0100 | <monochrom> | Life was simpler back then. |
| 2022-12-08 23:28:14 +0100 | <monochrom> | unsafePtrToInt -_- hahaha |
| 2022-12-08 23:29:08 +0100 | <EvanR> | it says unsafe. Which by one account means you need to guarantee something to use it safely. But what xD |
| 2022-12-08 23:29:15 +0100 | <monochrom> | In GHC it would be reallyUnsafePtrEquality |
| 2022-12-08 23:29:37 +0100 | <c_wraith> | I think reallyUnsafePtrEquality would probably work correctly for that. Usually. |
| 2022-12-08 23:29:43 +0100 | michalz | (~michalz@185.246.204.93) (Remote host closed the connection) |
| 2022-12-08 23:30:13 +0100 | <monochrom> | I.e., "evaluate/seq to WHNF, but this is Bool so we know it's pointer to the True singleton or pointer to the False singleton, so just compare pointer equality..." |
| 2022-12-08 23:30:44 +0100 | <monochrom> | Excluded middle at its finest. |
| 2022-12-08 23:31:17 +0100 | <Lears> | That code requires hugs, and after reading it, so do I. |
| 2022-12-08 23:31:28 +0100 | monochrom | hugs Lears |
| 2022-12-08 23:31:29 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-12-08 23:31:38 +0100 | monochrom | hugs hugs, too. |
| 2022-12-08 23:31:58 +0100 | <monochrom> | Did you know: Hugs still has the monopoly over OOHaskell >:) |
| 2022-12-08 23:32:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-12-08 23:32:20 +0100 | <EvanR> | dminuoso, I just upgraded my ghc to 9.2.5. LambdaCase still doesn't work (in ghci) without enabling it somehow xD |
| 2022-12-08 23:32:30 +0100 | <monochrom> | OK you may hate OO but it has a subset Extensible Records which you have always wanted >:) |
| 2022-12-08 23:32:41 +0100 | fserucas | (~fserucas@laubervilliers-657-1-66-228.w90-63.abo.wanadoo.fr) |
| 2022-12-08 23:33:06 +0100 | fserucas | (~fserucas@laubervilliers-657-1-66-228.w90-63.abo.wanadoo.fr) (Client Quit) |
| 2022-12-08 23:33:15 +0100 | <EvanR> | OO would have really simplified by solution to today's advent of code. My Grid is passed to literally everything in the file, cluttering everything. No I doubt a monad would help |
| 2022-12-08 23:34:17 +0100 | <monochrom> | Ah, LambdaCase is not in GHC2021 yet. |
| 2022-12-08 23:34:18 +0100 | <mauke> | inb4 configuration pearl |
| 2022-12-08 23:34:27 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-12-08 23:34:29 +0100 | <monochrom> | This is why GHC2022 or even GHC2023 is a good idea. |
| 2022-12-08 23:34:47 +0100 | <mauke> | "just teleport values through the type system, bro" |
| 2022-12-08 23:34:56 +0100 | <EvanR> | is configuration pearl = reflection |
| 2022-12-08 23:35:13 +0100 | <c_wraith> | it is a less disturbing version of reflection |
| 2022-12-08 23:35:13 +0100 | <monochrom> | I think configuration pearl = Reader |
| 2022-12-08 23:35:17 +0100 | <c_wraith> | but reflection is a lot faster |
| 2022-12-08 23:35:51 +0100 | <mauke> | https://okmij.org/ftp/Haskell/tr-15-04.pdf |
| 2022-12-08 23:36:08 +0100 | <EvanR> | implicit configurations |
| 2022-12-08 23:36:13 +0100 | <EvanR> | is the AOL keyword |
| 2022-12-08 23:36:15 +0100 | <monochrom> | Oh, that one. |
| 2022-12-08 23:36:19 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-12-08 23:36:42 +0100 | <monochrom> | 500 milliolegs :) |
| 2022-12-08 23:36:53 +0100 | <c_wraith> | the reflection library does the same thing in interface, but with an incredibly dirty internal implementation |
| 2022-12-08 23:36:56 +0100 | <mauke> | yeah, the one with type-level representations of foreign pointers |
| 2022-12-08 23:37:24 +0100 | causal | (~user@50.35.85.7) |
| 2022-12-08 23:37:26 +0100 | <EvanR> | yeah I have a pretty good idea of how that would work for my use case. I have no idea how Object Oriented Programming In Haskell would work so I like it more xD |
| 2022-12-08 23:37:32 +0100 | <c_wraith> | Just unsafeCoerce the => to a -> ! |
| 2022-12-08 23:38:37 +0100 | <mauke> | https://hackage.haskell.org/package/reflection-2.1.6/docs/src/Data.Reflection.html#Reifies |
| 2022-12-08 23:39:46 +0100 | <geekosaur> | you might look at OOHaskell like monochrom suggested |
| 2022-12-08 23:39:58 +0100 | <geekosaur> | sadly it's been decades since it worked with ghc |
| 2022-12-08 23:40:05 +0100 | <mauke> | @where oohaskell |
| 2022-12-08 23:40:06 +0100 | <lambdabot> | http://arxiv.org/abs/cs/0509027 |
| 2022-12-08 23:40:08 +0100 | <geekosaur> | I think 6.8 broke it |
| 2022-12-08 23:40:29 +0100 | <EvanR> | I remember this paper |
| 2022-12-08 23:42:09 +0100 | <monochrom> | Hrm, just needs HList? Then I misremembered. |
| 2022-12-08 23:42:37 +0100 | <monochrom> | In that case, actually should be a walk in the park in today's GHC, what with DataKinds and TypeInType etc. |
| 2022-12-08 23:42:47 +0100 | <monochrom> | and type families etc. |
| 2022-12-08 23:43:41 +0100 | <monochrom> | I mean Oleg's original code would not compile, but why stick to that, you can do a modernized encoding using the same idea, and it even has a chance to be more elegant. |
| 2022-12-08 23:44:15 +0100 | <EvanR> | of the myriad OO features developed in this paper, "my class file lets me pretend I have globals it's great" isn't one of them xD |
| 2022-12-08 23:44:44 +0100 | <EvanR> | which is an actual "point" of OOP I was once told, which was at the time news to me |
| 2022-12-08 23:45:21 +0100 | <monochrom> | I am OK with pretended global. |
| 2022-12-08 23:45:25 +0100 | <c_wraith> | Oh, if all you want is globals, just unsafePerformIO a ref into a top-level binding. :P |
| 2022-12-08 23:45:34 +0100 | <c_wraith> | "just" |
| 2022-12-08 23:45:47 +0100 | <EvanR> | a top level IVar would actually work |
| 2022-12-08 23:45:51 +0100 | <monochrom> | I am already OK with pretended state, so why not. |
| 2022-12-08 23:46:00 +0100 | <geekosaur> | once told by whom? someone who can't untangle OOP-the-current-popular-paradigm from 1960s bad practices? |
| 2022-12-08 23:46:01 +0100 | <EvanR> | it's a read only Grid |
| 2022-12-08 23:46:21 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-12-08 23:46:29 +0100 | <EvanR> | by my boss. Who's a pretty cool dude! |
| 2022-12-08 23:46:46 +0100 | <c_wraith> | (this messages sponsored by "not getting fired") |
| 2022-12-08 23:46:51 +0100 | <EvanR> | lol |
| 2022-12-08 23:47:53 +0100 | <EvanR> | this is stupid but I'm going to try the top level IVar thing |
| 2022-12-08 23:47:55 +0100 | <monochrom> | You know what, I think it's ambiguous whether it is "the point is to have globals" or it is "the point is not to have globals". |
| 2022-12-08 23:48:11 +0100 | zant1 | (~zant@62.214.20.26) (Ping timeout: 268 seconds) |
| 2022-12-08 23:51:44 +0100 | <c_wraith> | EvanR: don't forget to NOINLINE it |
| 2022-12-08 23:52:32 +0100 | <EvanR> | right... |
| 2022-12-08 23:52:55 +0100 | <glguy> | You can always foreign import a C global |
| 2022-12-08 23:53:48 +0100 | <monochrom> | haha |
| 2022-12-08 23:54:39 +0100 | <glguy> | and StablePoiners are storable, so you can use that to have global boxed haskell values |
| 2022-12-08 23:54:57 +0100 | <monochrom> | And ironically the C global is a void* so the Haskell side treats it as a StablePtr so it stores a Haskell value that C doesn't understand? :) |
| 2022-12-08 23:55:03 +0100 | <monochrom> | haha |
| 2022-12-08 23:56:16 +0100 | <dminuoso> | EvanR: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html |
| 2022-12-08 23:56:22 +0100 | <dminuoso> | I guess LambdaCase is not part of GHC2021 |