| 2022-11-14 00:00:57 +0100 | lechner | (~lechner@debian/lechner) (Remote host closed the connection) |
| 2022-11-14 00:02:17 +0100 | lechner | (~lechner@debian/lechner) |
| 2022-11-14 00:05:36 +0100 | lagash | (lagash@lagash.shelltalk.net) |
| 2022-11-14 00:11:05 +0100 | michalz | (~michalz@185.246.207.221) (Remote host closed the connection) |
| 2022-11-14 00:12:09 +0100 | <EvanR> | this bitstring type in elixir is pretty snazzy, I guess the idiomatic way to get a bit string in haskell is list of Bit |
| 2022-11-14 00:12:27 +0100 | ropwareJB | (~ropwareJB@180-150-36-243.b49624.bne.nbn.aussiebb.net) |
| 2022-11-14 00:13:47 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 00:15:03 +0100 | machinedgod | (~machinedg@clnet-b05-118.ikbnet.co.at) (Ping timeout: 256 seconds) |
| 2022-11-14 00:18:21 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:c87d:35ff:3ab7:8a28) |
| 2022-11-14 00:18:38 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 2022-11-14 00:21:05 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-11-14 00:22:08 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-11-14 00:24:39 +0100 | kaskal | (~kaskal@089144207012.atnat0016.highway.bob.at) (Ping timeout: 260 seconds) |
| 2022-11-14 00:24:53 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2022-11-14 00:25:07 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-14 00:25:17 +0100 | kaskal | (~kaskal@89.144.223.95) |
| 2022-11-14 00:28:17 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-11-14 00:30:06 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 00:34:24 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-11-14 00:47:31 +0100 | causal | (~user@50.35.83.177) |
| 2022-11-14 00:48:05 +0100 | TonyStone31 | (~TonyStone@cpe-74-76-57-186.nycap.res.rr.com) (Quit: Leaving) |
| 2022-11-14 00:48:39 +0100 | mikoto-chan | (~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) |
| 2022-11-14 00:48:51 +0100 | bobbingbob | (~bobbingbo@2604:3d09:207f:f650::b469) |
| 2022-11-14 00:49:03 +0100 | Kaipei | (~Kaiepi@108.175.84.104) (Ping timeout: 256 seconds) |
| 2022-11-14 00:51:45 +0100 | <Axman6> | EvanR: I'm guessing that's just a layer on top of Erlang's amazing bitstring support. I wish we had a similar thing in Haskell |
| 2022-11-14 00:51:56 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 268 seconds) |
| 2022-11-14 00:51:57 +0100 | <EvanR> | yeah |
| 2022-11-14 00:52:35 +0100 | <Rembane> | Are there ways to add more pattern matching to Haskell? |
| 2022-11-14 00:52:52 +0100 | <johnw> | You mean, like with pattern synonyms? |
| 2022-11-14 00:53:26 +0100 | <Rembane> | Yeah, or... I don't know, I'm just asking stupid questions and hoping for the best. :) |
| 2022-11-14 00:55:52 +0100 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Quit: Leaving) |
| 2022-11-14 00:57:17 +0100 | j4cc3b | (~j4cc3b@pool-74-105-2-138.nwrknj.fios.verizon.net) |
| 2022-11-14 00:59:57 +0100 | <bobbingbob> | Rembane: I find that's the best approach |
| 2022-11-14 01:00:03 +0100 | <Rembane> | bobbingbob: ^^ |
| 2022-11-14 01:00:45 +0100 | <bobbingbob> | what do folks think of this? https://pastebin.com/LzJBKBVa |
| 2022-11-14 01:03:19 +0100 | <EvanR> | well it's been a while since I had to ask wtf homoiconicity even is, but that's probably not it because it's not a lisp |
| 2022-11-14 01:04:00 +0100 | <geekosaur> | code and data have the same shape. haskell doesn't fit it |
| 2022-11-14 01:04:30 +0100 | zmt01 | (~zmt00@user/zmt00) |
| 2022-11-14 01:04:39 +0100 | <EvanR> | we do have Show and Read which by default make data print out equal to code that creates the data |
| 2022-11-14 01:04:47 +0100 | acidjnk | (~acidjnk@p200300d6e7137a015d19df638f338baf.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-11-14 01:05:27 +0100 | <EvanR> | but there's always a reason anything but lisp can't satisfy it |
| 2022-11-14 01:05:40 +0100 | <geekosaur> | you could say homoiconicity is when those are both id |
| 2022-11-14 01:06:01 +0100 | forell | (~forell@user/forell) (Ping timeout: 268 seconds) |
| 2022-11-14 01:06:06 +0100 | <bobbingbob> | EvanR: alright lets forget that part. its not important. more important is im going to manipulate haskell from inside haskell by making a representation of haskell and then writing in the representation |
| 2022-11-14 01:06:18 +0100 | <geekosaur> | lisp isn't necessarily the only thing that can theoretically satisfy it, it's just the only thing that practically satisfies it |
| 2022-11-14 01:06:46 +0100 | <bobbingbob> | so basically i've started a very simplified haskell |
| 2022-11-14 01:06:50 +0100 | <geekosaur> | in part because anything else that can satisfy it gets defined as a lisp 🙂 |
| 2022-11-14 01:06:57 +0100 | <Axman6> | MAthematica IIRC is also an example... but it's just lisp with weird syntax |
| 2022-11-14 01:07:07 +0100 | <bobbingbob> | no parsing because i'm using haskell types |
| 2022-11-14 01:07:19 +0100 | <EvanR> | mathematica has a lot of syntactic sugar too |
| 2022-11-14 01:07:30 +0100 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 240 seconds) |
| 2022-11-14 01:07:33 +0100 | <geekosaur> | you never used interlisp, did you? |
| 2022-11-14 01:07:55 +0100 | <bobbingbob> | when i'm satisfied with my abstract program i can then use it to generate the source representation |
| 2022-11-14 01:08:24 +0100 | forell | (~forell@user/forell) |
| 2022-11-14 01:08:55 +0100 | <EvanR> | I never HEARD of interlisp |
| 2022-11-14 01:09:27 +0100 | <EvanR> | bobbingbob, there is at least one library for working with haskell source as a data type |
| 2022-11-14 01:09:43 +0100 | <EvanR> | other than GHC |
| 2022-11-14 01:09:55 +0100 | <bobbingbob> | yes i know. but its been awhile since ive coded and ive always had trouble with focus |
| 2022-11-14 01:10:03 +0100 | <bobbingbob> | so this is programming practice for me |
| 2022-11-14 01:10:19 +0100 | <bobbingbob> | so im bootstrapping basically |
| 2022-11-14 01:10:46 +0100 | <EvanR> | your Expression type probably needs at least Variables |
| 2022-11-14 01:10:51 +0100 | <bobbingbob> | i don't know how to assimilate so much information so ive realized what i need to do is create a source code browser |
| 2022-11-14 01:11:09 +0100 | chomwitt | (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) (Ping timeout: 256 seconds) |
| 2022-11-14 01:11:22 +0100 | <EvanR> | a browser? Like, a GUI? |
| 2022-11-14 01:11:28 +0100 | <bobbingbob> | i realise it is very hard to visualise graphs of programs as big as gcc and ghc but i want to |
| 2022-11-14 01:11:40 +0100 | geekosaur | wonders if it's worth pointing at manatee, or if that's too bitrotted now |
| 2022-11-14 01:12:07 +0100 | <geekosaur> | I think it's like a decade old at this point |
| 2022-11-14 01:12:48 +0100 | <EvanR> | as far as I'm concerned manatee was dark magic |
| 2022-11-14 01:13:56 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:c87d:35ff:3ab7:8a28) (Remote host closed the connection) |
| 2022-11-14 01:16:25 +0100 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) |
| 2022-11-14 01:17:00 +0100 | <bobbingbob> | it looks cool. i will look at it. reading practise |
| 2022-11-14 01:17:22 +0100 | xcmw | (~textual@50.93.222.82) |
| 2022-11-14 01:17:23 +0100 | <bobbingbob> | using other people code practise. im always trying to start from square one |
| 2022-11-14 01:17:29 +0100 | Igloo | (~ian@matrix.chaos.earth.li) (Ping timeout: 255 seconds) |
| 2022-11-14 01:18:08 +0100 | <geekosaur> | huh |
| 2022-11-14 01:19:51 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-11-14 01:21:45 +0100 | <bobbingbob> | geekosaur: i mean i don't like any of the guis so i'm always trying to make one. i want to create an visual editor for haskell |
| 2022-11-14 01:22:16 +0100 | <geekosaur> | sorry, the "huh" was unrelated |
| 2022-11-14 01:22:49 +0100 | <EvanR> | bobbingbob, what GUI technology would you use |
| 2022-11-14 01:23:04 +0100 | <EvanR> | manatee was using GTK |
| 2022-11-14 01:23:18 +0100 | Igloo | (~ian@matrix.chaos.earth.li) |
| 2022-11-14 01:23:44 +0100 | <geekosaur> | specifically gtk2hs. there's also gi these days |
| 2022-11-14 01:24:02 +0100 | <geekosaur> | there was a quasi-functional thing based on Qt at some point |
| 2022-11-14 01:24:14 +0100 | <geekosaur> | if you really want to get daring, there's reflex-platform |
| 2022-11-14 01:25:17 +0100 | <bobbingbob> | i tried to install obleisk but got install errors i don't understand so im going to use sdl for the time being, then opengl/vulkan or something in a long while |
| 2022-11-14 01:26:28 +0100 | <bobbingbob> | i will do another paste of the gui i have at the moment but it too is a work in progress |
| 2022-11-14 01:26:56 +0100 | <bobbingbob> | both the gui and the debugger are meant to be really simple and basic |
| 2022-11-14 01:27:19 +0100 | bilegeek | (~bilegeek@2600:1008:b064:c747:f92e:461d:82e7:f3a1) |
| 2022-11-14 01:27:44 +0100 | <bobbingbob> | i do plan to use other peoples work but i need to work out how to get a handle on the complexity of all the source i want to read/know something about |
| 2022-11-14 01:28:25 +0100 | <EvanR> | you're basically lt barclay in "The Nth Degree" when he says, I need a better interface |
| 2022-11-14 01:28:45 +0100 | <EvanR> | unfortunately there's no holodeck... |
| 2022-11-14 01:29:19 +0100 | <bobbingbob> | like i want to have a good grasp of ghc compile process, good grasp of how things work at the linking level, good grasp of git/emacs |
| 2022-11-14 01:29:21 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-14 01:29:21 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-14 01:29:21 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-14 01:29:42 +0100 | <bobbingbob> | i could keep going on and on and i just don't know how to take it in |
| 2022-11-14 01:30:02 +0100 | <EvanR> | there are a lot of existing tools that print out the intermediate / final forms of all that stuff in a way that can be actually read |
| 2022-11-14 01:30:27 +0100 | <bobbingbob> | concurrency/parallelism, optimizing, big O, so much math and on forever ... |
| 2022-11-14 01:32:10 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 240 seconds) |
| 2022-11-14 01:32:18 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 01:34:09 +0100 | <monochrom> | This is why a university CS program takes 3-4 years. |
| 2022-11-14 01:34:40 +0100 | <monochrom> | And yet that's already near-optimal because the order of the courses are carefully laid out. |
| 2022-11-14 01:35:06 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 2022-11-14 01:35:27 +0100 | <monochrom> | Someone did the dependency chasing for you and presents a build plan, and it's time-proved. |
| 2022-11-14 01:36:02 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-11-14 01:36:31 +0100 | <monochrom> | That's the value of university structured education, compared to "I learn everything from the internet". |
| 2022-11-14 01:36:37 +0100 | <monochrom> | At least for most people. |
| 2022-11-14 01:43:05 +0100 | adium | (adium@user/adium) |
| 2022-11-14 01:43:20 +0100 | <hpc> | "someone did the dependency chasing for you" is a good way to put it |
| 2022-11-14 01:43:40 +0100 | <bobbingbob> | monochrom: yeah problem is focus. dry material just turns my brain off. im learning to treat it the way i was taught to do meditate. when you lose focus put it back in place |
| 2022-11-14 01:45:46 +0100 | <monochrom> | And then there is brilliant.org, which is the opposite of dry. |
| 2022-11-14 01:46:18 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-11-14 01:46:18 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 01:47:18 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-11-14 01:50:49 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 2022-11-14 01:54:13 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-11-14 01:54:48 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 01:58:36 +0100 | <bobbingbob> | monochrom: oh cool! thanks for sharing that |
| 2022-11-14 01:59:46 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 2022-11-14 02:02:10 +0100 | xff0x | (~xff0x@2405:6580:b080:900:dd4a:69df:2709:8d37) (Ping timeout: 240 seconds) |
| 2022-11-14 02:02:56 +0100 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Ping timeout: 246 seconds) |
| 2022-11-14 02:06:15 +0100 | <SrPx> | quick question: why aren't you hyping this? https://twitter.com/VictorTaelin/status/1591959427363573767 |
| 2022-11-14 02:06:18 +0100 | <SrPx> | you should! |
| 2022-11-14 02:08:21 +0100 | <Axman6> | Probably because most of us have no idea how it relates to real programs |
| 2022-11-14 02:08:47 +0100 | <Axman6> | it sounds interesting, but it's definitely not going to speed things up in the real world by 9x |
| 2022-11-14 02:09:34 +0100 | <Axman6> | it's also unclear how it plays with others - how much Haskell is supported? can I do FFI calls? how does memory management work? |
| 2022-11-14 02:11:07 +0100 | <SrPx> | Axman6: what would convince you it applies to the real world? |
| 2022-11-14 02:11:19 +0100 | <SrPx> | that's a sorting algorithm |
| 2022-11-14 02:11:20 +0100 | czuberion[m] | (~czuberion@2001:470:69fc:105::2:bc47) |
| 2022-11-14 02:11:29 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2022-11-14 02:11:31 +0100 | <Axman6> | automatic parallelisation is something that's been tried plenty of times, and rarely actually performs well, you need to know more about what your program does than the compiler can usually infer |
| 2022-11-14 02:11:36 +0100 | <Axman6> | SrPx: can it run GHC? |
| 2022-11-14 02:12:19 +0100 | <SrPx> | not until we have a Core->GHC compiler, and that'll only happen if the community shows enough interest to fund the tech. chicken and egg |
| 2022-11-14 02:12:40 +0100 | <Axman6> | that might be irrelevant if I can call code for HVM from Haskell cheaply, then I can run the things that it does well using it, and everything else with a normal GHC compiled program |
| 2022-11-14 02:13:32 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-11-14 02:13:35 +0100 | <SrPx> | Axman6: yep that is very achievable. it is already possible on Rust, with a little effort. we could add a rich interop with Haskell in little time, but we'd need someone to maintain it |
| 2022-11-14 02:14:27 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:c87d:35ff:3ab7:8a28) |
| 2022-11-14 02:14:47 +0100 | <SrPx> | the criticism used to be that inets had no real-world application because λ-encodings are niche, so I went all the way to build HVM and benchmark on real-world algorithms. the next version parallelizes basically any sorting algorithm, precisely to make a point that it does generalize to basically anything you write |
| 2022-11-14 02:15:04 +0100 | <SrPx> | here is a draft of that: https://github.com/Kindelia/HVM/blob/master/guide/PARALLELISM.md |
| 2022-11-14 02:16:13 +0100 | poscat | (~poscat@2408:8206:4823:fd6f:98ab:5c38:136c:5932) (Quit: Bye) |
| 2022-11-14 02:16:27 +0100 | poscat | (~poscat@114.245.106.84) |
| 2022-11-14 02:16:36 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-14 02:16:41 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 02:17:31 +0100 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 2022-11-14 02:17:59 +0100 | <Axman6> | I wish we'd stop calling the functional quicksort quicksort, it uses some similar ideas but kinda misses one of the fundamental properties, that it's in place and requires no allocation ("we" = the whole FP community) |
| 2022-11-14 02:18:30 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:c87d:35ff:3ab7:8a28) (Ping timeout: 240 seconds) |
| 2022-11-14 02:21:07 +0100 | <monochrom> | Unpopular opinion: I wish we'd stop emphasizing that as a difference. |
| 2022-11-14 02:21:53 +0100 | <dolio> | So, what's you're alternate name for, "use the exact same algorithmic strategy as quicksort, but it needs to be called something else anyway"? |
| 2022-11-14 02:21:58 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-11-14 02:21:59 +0100 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 256 seconds) |
| 2022-11-14 02:22:43 +0100 | ygsjg | (~quassel@189.124.224.160) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-14 02:22:49 +0100 | <Axman6> | imma call it partitionsort |
| 2022-11-14 02:23:10 +0100 | <maerwald[m]> | Algorithms are hard in FP |
| 2022-11-14 02:23:26 +0100 | <SrPx> | Axman6: I kind of agree, kind of disagree. why requiring allocation should be a relevant factor to be worth pointing? yes, it is slow, but it doesn't need to be. I believe HVM will brute-force its way into making pure functional algorithms (with a lot of allocation) faster than mutable algorithms, given enough cores |
| 2022-11-14 02:24:01 +0100 | <SrPx> | I mean once we have CPUs with 65536 cores, I find it hard to believe single-threaded procedural algorithms will stand a chance against what HVM is doing |
| 2022-11-14 02:24:36 +0100 | <maerwald[m]> | Speculation |
| 2022-11-14 02:24:41 +0100 | ygsjg | (~quassel@189.124.224.160) |
| 2022-11-14 02:25:16 +0100 | <SrPx> | yes. I could be wrong, who knows? yet it is so clearly worth a shot. I wish we could compile GHC-Core to HVM, optimize it and take Haskell to a new level |
| 2022-11-14 02:26:13 +0100 | <maerwald[m]> | SrPx: performance doesn't seem like a primary priority for GHC |
| 2022-11-14 02:27:11 +0100 | <maerwald[m]> | Look at Go. The reason they rejected so many language features is not that they don't like them, but that they don't know how to implement them without additional cost |
| 2022-11-14 02:27:26 +0100 | <Axman6> | " This made the runtime 50x (!) faster" I want to know why the previous implementation was so bad! |
| 2022-11-14 02:27:53 +0100 | <Axman6> | s/bad/slow |
| 2022-11-14 02:29:51 +0100 | <SrPx> | Axman6: what do you mean? |
| 2022-11-14 02:29:54 +0100 | <SrPx> | 50x faster? |
| 2022-11-14 02:30:01 +0100 | <Axman6> | I'm reeading https://github.com/Kindelia/HVM/blob/master/guide/HOW.md |
| 2022-11-14 02:30:06 +0100 | <dolio> | So, my question is: how have you solved the pitfalls of previous attempts to automatically parallelize functional code? |
| 2022-11-14 02:31:00 +0100 | <SrPx> | Axman6: ah, before HVM people implemented interaction nets in really inefficient ways (including myself) |
| 2022-11-14 02:31:27 +0100 | <SrPx> | it took a while to realize how to represent nodes in a memory efficient way, and that impacts all the rest |
| 2022-11-14 02:32:44 +0100 | <Axman6> | there's no support for floating point in the language? that seems surprisingly limiting, particularly when one of the main types of code people want to parallelise is numeric node - is that a feature that's planned? |
| 2022-11-14 02:32:49 +0100 | <SrPx> | there is! |
| 2022-11-14 02:32:54 +0100 | <SrPx> | just merged on master, 2 days ago :) |
| 2022-11-14 02:33:09 +0100 | <Axman6> | great - that doc above needs updating then :P |
| 2022-11-14 02:33:53 +0100 | <SrPx> | there aren't many people working on it, so things move at a single-man pace. there is SO MUCH to improve. so many low hanging fruits. I really think you should appreciate how this thing is even competitive with a GHC at all, the amount of time and investment it received is 2 orders of magnitude larger |
| 2022-11-14 02:34:00 +0100 | <SrPx> | Axman6: yep lol |
| 2022-11-14 02:34:57 +0100 | <SrPx> | dolio: the HOW.md doc that Axman6 linked answers that question, and it is kinda sad that previous attempt made people skeptical of the idea, but trust me, it is different now ™ |
| 2022-11-14 02:35:15 +0100 | <SrPx> | dolio: the short answer is that HVM replaces references entirely by a lazy duplication primitive |
| 2022-11-14 02:35:46 +0100 | <SrPx> | so, that's right, there are no references in the language. like, at all. everything is linear and only exists in one place at once |
| 2022-11-14 02:36:26 +0100 | <Axman6> | I wish there were types in the code examples, particularly since the function/rule syntax is the same as constructor syntax, it's hard for me to understand what any of the code is actually doing |
| 2022-11-14 02:37:07 +0100 | <SrPx> | that makes parallelism extremely simpler, because communication and synchronization is minimized |
| 2022-11-14 02:37:32 +0100 | <SrPx> | Axman6: let me know what code was hard to understand and why, I'll work on improving it |
| 2022-11-14 02:37:37 +0100 | <dolio> | I've read that before, and it doesn't address my question at all, from what I recall, especially since the section on parallelism is "[TODO]". |
| 2022-11-14 02:38:02 +0100 | <SrPx> | dolio: there is a TODO there? I should probably redirect it to https://github.com/Kindelia/HVM/blob/master/guide/PARALLELISM.md which I'm currently writing |
| 2022-11-14 02:38:40 +0100 | <SrPx> | this is more a guide on how to develop parallel algorithms than an explanation on why it is supposed to work, though. yes I definitely should add that kind of info on HOW.md |
| 2022-11-14 02:39:11 +0100 | <Axman6> | "as been widely regarded as the hardest problem of the 21st century" seems a bit hyperbolic - or possibly the most hyperbolic thing ever said! :P |
| 2022-11-14 02:39:19 +0100 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) |
| 2022-11-14 02:39:54 +0100 | <SrPx> | Axman6: ah that was meant to be a joke, but I don't like the tone of this doc either. I plan to completely tone it down when I have the time, make it more serious |
| 2022-11-14 02:40:06 +0100 | <SrPx> | there is just so much to do and I'm so little |
| 2022-11-14 02:40:12 +0100 | <Axman6> | :thumbsup: |
| 2022-11-14 02:40:51 +0100 | <SrPx> | btw is the functional bitonic sort algorithm on the PARALLELISM.md link above known? |
| 2022-11-14 02:41:22 +0100 | <SrPx> | I couldn't find anything on google, and then realized it can be implemented in such a simple elegant way |
| 2022-11-14 02:41:40 +0100 | <Axman6> | not sure I agree with the example that talks about laziness, since is basically all implementations of laziness, when something is given a name, it will usually only be evaluated once, and the expression 2*2 has the name x inside foo |
| 2022-11-14 02:41:54 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-14 02:42:08 +0100 | <Axman6> | SrPx: I struggled to understand how it worked, so I couldn't tell you |
| 2022-11-14 02:42:10 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 240 seconds) |
| 2022-11-14 02:42:11 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2022-11-14 02:42:23 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-11-14 02:42:48 +0100 | Guest75 | (~Guest75@178.141.177.81) (Ping timeout: 260 seconds) |
| 2022-11-14 02:43:00 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-14 02:43:16 +0100 | <dolio> | And benchmarks of a few algorithms aren't the same as citing previous work, why it didn't work out in practice, and proving that those problems have been solved. Like, I have no reason to believe that quicksort wouldn't have also been really good with whatever people tried 20 years ago. |
| 2022-11-14 02:43:17 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-11-14 02:43:19 +0100 | <SrPx> | Axman6: the point is that if you do not optimize it that way, you'll have wasted work, so that you then realize that the optimization doesn't cover all cases (i.e., it fails to share work under lambdas). thus, we need other way to avoid that, which is what lazy dups do, and it covers all cases |
| 2022-11-14 02:43:46 +0100 | <SrPx> | dolio: I see what you mean. |
| 2022-11-14 02:43:50 +0100 | califax | (~califax@user/califx) |
| 2022-11-14 02:43:59 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds) |
| 2022-11-14 02:45:28 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 02:51:10 +0100 | bobbingbob | (~bobbingbo@2604:3d09:207f:f650::b469) (Ping timeout: 240 seconds) |
| 2022-11-14 02:52:17 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 2022-11-14 02:52:47 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-11-14 02:53:59 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 260 seconds) |
| 2022-11-14 02:55:14 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-11-14 02:55:37 +0100 | <sm> | SrPx: as always it sounds super exciting, thanks for your work. Most of us have learned to be cautious of (in your words) "hype", and to wait for some kind of concrete practical-in-the-real-world result |
| 2022-11-14 02:56:10 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-14 02:56:14 +0100 | <sm> | I mean in general, not your work specifically |
| 2022-11-14 02:56:36 +0100 | <sm> | sounds like it's getting closer.. ? 🚀 |
| 2022-11-14 02:58:00 +0100 | <maerwald[m]> | sm: Haskellers are not hype driven? 😂 |
| 2022-11-14 02:58:08 +0100 | <maerwald[m]> | Come on |
| 2022-11-14 02:58:21 +0100 | <sm> | heck no, we know how long good things take by now |
| 2022-11-14 02:59:50 +0100 | <maerwald[m]> | I think Haskellers are just used to awful performance, that's why |
| 2022-11-14 03:00:26 +0100 | number11 | (~number11@cpe-75-80-181-36.san.res.rr.com) |
| 2022-11-14 03:01:25 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-194.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-11-14 03:02:03 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2022-11-14 03:06:19 +0100 | <SrPx> | sm: but the hype is needed to fund the idea :p if I fail to raise any dime I'll have to stop, which will be a little sad, since I truly believe this has a huge potential to make many things better, specially for the FP community |
| 2022-11-14 03:07:51 +0100 | <SrPx> | I'll be talking with some VCs next week. I hope someone shares my vision |
| 2022-11-14 03:16:16 +0100 | <Axman6> | I'nm reading through the explanation of constructor duplication - why is the end result a pair? There were no pairs in the original expression |
| 2022-11-14 03:17:33 +0100 | <Axman6> | I also can't see how something that copies the irst element of an n element list n times could be optimal - is there heaps of memory being used here? |
| 2022-11-14 03:19:01 +0100 | <Axman6> | "That was a lot of info. Hopefully, by now, you have an intuition about how the lazy duplication primitive works." Sadly no, I'm actually more confused now I've read it, maybe I just don't understand the syntax that's being used to explain evaluation? |
| 2022-11-14 03:19:13 +0100 | <maerwald[m]> | SrPx: did you talk to HF? |
| 2022-11-14 03:19:20 +0100 | <SrPx> | HF? |
| 2022-11-14 03:19:39 +0100 | <maerwald[m]> | Haskell Foundation |
| 2022-11-14 03:20:01 +0100 | <SrPx> | Axman6: ah, I'm sorry, I guess then I didn't do a great job at explaining it :( I did my best but being pedagogical is hard |
| 2022-11-14 03:20:22 +0100 | <SrPx> | maerwald[m]: ah, no. should I? |
| 2022-11-14 03:20:33 +0100 | <SrPx> | I didn't talk to anyone yet really, I'll be starting this week |
| 2022-11-14 03:20:39 +0100 | <maerwald[m]> | SrPx: if you think this is relevant to Haskell, then yes |
| 2022-11-14 03:20:54 +0100 | <maerwald[m]> | Contact David the CEO directly |
| 2022-11-14 03:21:35 +0100 | <SrPx> | I think it is the most important thing that could ever happen to Haskell :p |
| 2022-11-14 03:21:41 +0100 | <SrPx> | maerwald[m]: I'll give it a shot |
| 2022-11-14 03:23:21 +0100 | <Axman6> | one problem I'm having understanding all this is I have absolutely no idea what's happening on either the CPU nor in memory, let alone how it solves the problems the others have run into over the years |
| 2022-11-14 03:23:40 +0100 | <Axman6> | if you're tlaking to VCs who have any CS background, you'll need to have answers to those questions |
| 2022-11-14 03:23:40 +0100 | <maerwald[m]> | SrPx: the CEO is technical enough that he might have an opinion about it even |
| 2022-11-14 03:24:18 +0100 | youziqi | (~youziqi@103.37.140.19) |
| 2022-11-14 03:24:47 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 260 seconds) |
| 2022-11-14 03:24:56 +0100 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-11-14 03:25:33 +0100 | <SrPx> | Axman6: I have all the answers to all these questions, I'm absolutely confident that the HVM has the potential to completely disrupt the entire tech industry. convincing people of that is the hardest part. understanding people is even harder. some people want in deep tech explanations. other want simpler ELI5s. other just want to know how I'm supposed to turn a compiler-ish thing into a business. other don't care and just want a crypto to pump |
| 2022-11-14 03:25:38 +0100 | <SrPx> | in depth* |
| 2022-11-14 03:26:07 +0100 | <SrPx> | maerwald[m]: I assume that if they liked the idea they'd have approached me though, but I'll try. costs nothing |
| 2022-11-14 03:27:42 +0100 | <davean> | bitonic sort is a sorting network and hence inherently functional. It is well know but generally performs horribly. |
| 2022-11-14 03:28:10 +0100 | <davean> | SrPx: Its real purpose is usually really wide systems, like GPUs where communication is expensive |
| 2022-11-14 03:29:08 +0100 | <SrPx> | davean: is the functional algorithm that I wrote known though? i.e., this one: https://github.com/Kindelia/HVM/blob/master/examples/sort/bitonic/main.hs |
| 2022-11-14 03:29:29 +0100 | <SrPx> | I wasn't aware since it doesn't use any kind of immutable map or indexing, just a tree that it swaps over and over |
| 2022-11-14 03:29:39 +0100 | <SrPx> | it parallelizes really well on HVM, near linear speedup |
| 2022-11-14 03:30:13 +0100 | <SrPx> | but yes, it is a little bit on the heavy side compared to radix sort |
| 2022-11-14 03:33:43 +0100 | <davean> | SrPx: well, it would take me a bit to be sure it maps exactly 1-to-1 to a standard one |
| 2022-11-14 03:34:06 +0100 | <davean> | It sure looks like it though? This sort of thing is usually only used on GPUs though (or massive distributed systems - see penny sort) |
| 2022-11-14 03:34:30 +0100 | number11 | (~number11@cpe-75-80-181-36.san.res.rr.com) () |
| 2022-11-14 03:34:34 +0100 | <SrPx> | yep I know, it is really good on the GPU since it is just distant swaps that can be performed in parallel |
| 2022-11-14 03:34:40 +0100 | <davean> | Sorting is REALLY well studied, so i'm not sure "uknown" is a very interesting question though |
| 2022-11-14 03:35:33 +0100 | <SrPx> | davean: yes I know, just wondering if someone ever had the motivation to write a pure functional version of it like that |
| 2022-11-14 03:35:49 +0100 | <SrPx> | since other than HVM it would be kinda pointless |
| 2022-11-14 03:36:12 +0100 | TonyStone | (~TonyStone@cpe-74-76-57-186.nycap.res.rr.com) |
| 2022-11-14 03:38:00 +0100 | <davean> | well like http://svenssonjoel.github.io/writing/lic.pdf has bitonic and Odd-Even merge. Is that close enough for you? Thats a personal decision |
| 2022-11-14 03:38:30 +0100 | <Axman6> | SrPx: there are several links to runtime.c, that all 404, btw |
| 2022-11-14 03:38:34 +0100 | <SrPx> | davean: no, because it uses array and array indexing |
| 2022-11-14 03:38:46 +0100 | <SrPx> | Axman6: oh thank you. well runtime.c doesn't exist anymore |
| 2022-11-14 03:38:52 +0100 | <SrPx> | I'll fix these |
| 2022-11-14 03:39:14 +0100 | <davean> | SrPx: Ok, why does that matter for you? |
| 2022-11-14 03:39:21 +0100 | <davean> | This is what makes it hard to answer |
| 2022-11-14 03:42:18 +0100 | <SrPx> | davean: that matters a lot because arrays and mutability don't mix very well with pure functional languages. For example, there are no arrays on the λ-calculus, and if you're trying to minimize the number of beta-reductions, emulating arrays will give you a 100x-200x penalty upfront, and adding arrays natively will make parallelism impossible (HVM doesn't have mutable arrays) |
| 2022-11-14 03:42:24 +0100 | <SrPx> | not impossible, harder* |
| 2022-11-14 03:42:41 +0100 | <davean> | SrPx: Arrays mix great. Did you see mutation in there? |
| 2022-11-14 03:43:02 +0100 | <davean> | The naive λ-calculus is not the core of what is |
| 2022-11-14 03:43:51 +0100 | <sm> | SrPx: I hear you. But oh boy VCs.. well that's another approach |
| 2022-11-14 03:43:53 +0100 | <davean> | A lot of functional things build new arrays to do sorts |
| 2022-11-14 03:44:36 +0100 | <SrPx> | okay the point I'm making is, suppose you implement array in a pure functional style (i.e., no mutability) |
| 2022-11-14 03:44:51 +0100 | <davean> | Ok, completely normal |
| 2022-11-14 03:44:56 +0100 | <davean> | Normal haskell there |
| 2022-11-14 03:45:08 +0100 | <davean> | We're in the absolute normal case now |
| 2022-11-14 03:45:11 +0100 | <SrPx> | every time you index it, you'll need to make a bunch of pattern-matches, right? for example, if it is a populated binary tree with depth 32, you'll need at least 32 pattern-matches to access a number |
| 2022-11-14 03:45:26 +0100 | <davean> | No, you don't |
| 2022-11-14 03:45:34 +0100 | <davean> | You can still have an actual array |
| 2022-11-14 03:45:49 +0100 | <davean> | https://www.haskell.org/onlinereport/haskell2010/haskellch14.html#x22-20100014 |
| 2022-11-14 03:46:15 +0100 | <davean> | Its part of the Haskell Report |
| 2022-11-14 03:46:31 +0100 | <davean> | You can still have contiguous memory of thunks |
| 2022-11-14 03:46:59 +0100 | <davean> | and if you look at the "c" generated by the paper I linked you you'll see it has input* and output* |
| 2022-11-14 03:47:04 +0100 | <davean> | it reads from input and writes to output |
| 2022-11-14 03:47:17 +0100 | <davean> | It feels like your base assumptions are off here |
| 2022-11-14 03:47:39 +0100 | <SrPx> | yes I know, the point is that Array can't be expressed with algebraic datatypes alone, it must be a primitive that does memory indexing. Haskell provides such primitive, but not everything does. raw type theory doesn't have such a thing, the lambda calculus neither, etc. etc. -- I'm not saying arrays are bad (they're great!), just that there are some environments where you don't have them |
| 2022-11-14 03:49:05 +0100 | <davean> | Ok, sure, I suppose. You have to be in a pretty esoteric enviroment to not have them though. |
| 2022-11-14 03:50:00 +0100 | <SrPx> | I mean, you can call it that, but disabling array enables other things, for similar reasons people promote immutability in Haskell :) |
| 2022-11-14 03:50:21 +0100 | <davean> | What do you think it enables specificly? |
| 2022-11-14 03:50:40 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-11-14 03:51:25 +0100 | <SrPx> | beta-optimality, parallelism! someone asked how HVM is able to parallelize automatically when other attempts failed, and that's the answer: it sacrifices things. mutable arrays are one of these things. not having mutable arrays mean two threads can't communicate directly, which lets you make strong assumptions on the compiler/runtime side, which is ultimately what makes automatic parallelism possible |
| 2022-11-14 03:52:13 +0100 | <SrPx> | (it was dan I believe) |
| 2022-11-14 03:52:22 +0100 | <davean> | Ok, but we never talked about *mutable* arrays here |
| 2022-11-14 03:52:30 +0100 | <davean> | we only talked about *pure* arrays |
| 2022-11-14 03:53:03 +0100 | <davean> | and arrays are the classic basis of automatic parallelization |
| 2022-11-14 03:53:27 +0100 | <davean> | Even C can do automated parallelism on array |
| 2022-11-14 03:53:40 +0100 | <davean> | even *with* mutation |
| 2022-11-14 03:54:46 +0100 | <SrPx> | hm I'm afraid you can't automatically parallelize a thread that is mutating a shared array in parallel |
| 2022-11-14 03:55:29 +0100 | <davean> | The standard C compilers take a single thread that is mutating an array and parallelize it usually |
| 2022-11-14 03:55:32 +0100 | <SrPx> | without introducing unnecessary sequentialism, I mean |
| 2022-11-14 03:55:44 +0100 | <davean> | but, again, nothing above talked about a mutable array other than you |
| 2022-11-14 03:55:55 +0100 | <SrPx> | yep I guess I misunderstood your point |
| 2022-11-14 03:55:57 +0100 | <davean> | The paper was about non-mutable arrays |
| 2022-11-14 03:56:09 +0100 | <davean> | and the Haskell Report Data.Array is non-mutable |
| 2022-11-14 03:56:36 +0100 | <davean> | So, what do you get from giving up non-mutable arrays and paying an extra log? |
| 2022-11-14 03:57:11 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 256 seconds) |
| 2022-11-14 03:58:41 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2022-11-14 03:59:23 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 03:59:54 +0100 | <davean> | seperate in and out arrays are completely standard in GPU programming. |
| 2022-11-14 04:00:14 +0100 | <davean> | and in GPU like haskell |
| 2022-11-14 04:00:17 +0100 | <davean> | more stuff at http://www.cse.chalmers.se/edu/year/2017/course/DAT280_Parallel_Functional_Programming/Material/GP… |
| 2022-11-14 04:02:06 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-14 04:02:33 +0100 | <SrPx> | davean: yep but the point I was making is, for the Bitonic Sort in particular, you do *not* need to pay an extra log. that's what the algorithm I sent is doing :) it does all the correct swaps without indexing (i.e., get/set). it just coordinates swaps in such a manner that the end result is equivalent to the swaps you'd to in a mutable array |
| 2022-11-14 04:02:44 +0100 | <SrPx> | i just found that kinda cool |
| 2022-11-14 04:04:08 +0100 | <davean> | Sure you could say the same about merge sort too I think |
| 2022-11-14 04:04:51 +0100 | <davean> | Thats a property of many fast sorts. |
| 2022-11-14 04:05:39 +0100 | <davean> | Some you need to step up to finger trees for |
| 2022-11-14 04:05:57 +0100 | <SrPx> | exactly, merge sort, quick sort, all the common sorts don't need array indexing, they have clean/direct functional algorithms that do the thing |
| 2022-11-14 04:06:07 +0100 | <SrPx> | I just wasn't aware the bitonic sort was there too |
| 2022-11-14 04:06:25 +0100 | <SrPx> | specially because it involves swaps in distant parts of the array in manners that looked like it couldn't be done without array indexing |
| 2022-11-14 04:06:31 +0100 | <SrPx> | but it can! fairly cool |
| 2022-11-14 04:06:41 +0100 | <davean> | well, any sort maps to a sorting network that is inherently static |
| 2022-11-14 04:06:57 +0100 | <davean> | thats one of the fundimental properties of sorting |
| 2022-11-14 04:07:00 +0100 | <SrPx> | but that's not the point |
| 2022-11-14 04:07:01 +0100 | <davean> | sorry any COMPARISON sort |
| 2022-11-14 04:07:20 +0100 | <davean> | But isn't that litterly a restatement of your observation? |
| 2022-11-14 04:07:23 +0100 | <SrPx> | noo! |
| 2022-11-14 04:07:25 +0100 | <SrPx> | for example |
| 2022-11-14 04:07:32 +0100 | <SrPx> | suppose your ultra clever sorting algorithm does this: |
| 2022-11-14 04:07:45 +0100 | <SrPx> | swap(array[7], array[91]) |
| 2022-11-14 04:07:51 +0100 | <SrPx> | swap(array[5], array[65]) |
| 2022-11-14 04:07:57 +0100 | <davean> | except it gets those from somewhere. |
| 2022-11-14 04:08:02 +0100 | <davean> | Thats the sorting network |
| 2022-11-14 04:08:06 +0100 | <davean> | those can be setup fixed. |
| 2022-11-14 04:08:21 +0100 | <davean> | https://en.wikipedia.org/wiki/Sorting_network |
| 2022-11-14 04:08:21 +0100 | <SrPx> | the indices that you swap must follow a specific rule, right? and after all the swaps you'll get a sorted array |
| 2022-11-14 04:08:53 +0100 | <SrPx> | the thing is, there is no guarantee that the indices you swap will be in such a way that you can do the same swaps without indexing, by just rotating trees efficiently |
| 2022-11-14 04:09:08 +0100 | <SrPx> | I know what a sorting network is aaa |
| 2022-11-14 04:09:25 +0100 | <davean> | A sorting network is your guarrentee |
| 2022-11-14 04:09:32 +0100 | <SrPx> | no it isn't!!! |
| 2022-11-14 04:09:41 +0100 | <SrPx> | you don't get what I'm trying to say and I guess I can't explain |
| 2022-11-14 04:09:46 +0100 | <SrPx> | this is fine, never mind all that |
| 2022-11-14 04:09:53 +0100 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:3d51:c8c8:3b5:2cac) (Quit: caryhartline) |
| 2022-11-14 04:10:09 +0100 | <SrPx> | I'm just bad at explaining, sorry |
| 2022-11-14 04:10:15 +0100 | <SrPx> | need to go now |
| 2022-11-14 04:10:24 +0100 | <davean> | A sorting network is a statement that it is knowable what has to feed into what. Since that exists, you can do each stage in constant time without an array. |
| 2022-11-14 04:10:51 +0100 | <davean> | Ok |
| 2022-11-14 04:10:54 +0100 | <davean> | well its been interesting |
| 2022-11-14 04:12:23 +0100 | td_ | (~td@83.135.9.56) (Ping timeout: 260 seconds) |
| 2022-11-14 04:14:06 +0100 | td_ | (~td@83.135.9.3) |
| 2022-11-14 04:17:34 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-11-14 04:18:58 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-14 04:20:07 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-14 04:21:28 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-14 04:22:03 +0100 | <SrPx> | davean: oh - I was just thinking about a counter-example and I believe you're right. no matter what the initial arrangement is, as long as you know the starting and ending indices statically, you can always rotate sub trees to perform the desired permutation. sorry, I get it now and stand corrected |
| 2022-11-14 04:22:18 +0100 | <SrPx> | really need to go run though |
| 2022-11-14 04:25:27 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 2022-11-14 04:28:05 +0100 | abrantesasf | (~abrantesa@187.64.158.2) |
| 2022-11-14 04:34:03 +0100 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2022-11-14 04:35:43 +0100 | mikoto-chan | (~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) (Ping timeout: 256 seconds) |
| 2022-11-14 04:56:02 +0100 | abrantesasf | (~abrantesa@187.64.158.2) (Remote host closed the connection) |
| 2022-11-14 05:00:00 +0100 | Taneb0 | (~Taneb@2001:41c8:51:10d:aaaa:0:aaaa:0) (Quit: I seem to have stopped.) |
| 2022-11-14 05:01:09 +0100 | Taneb | (~Taneb@runciman.hacksoc.org) |
| 2022-11-14 05:08:00 +0100 | manwithluck | (~manwithlu@194.177.28.176) (Read error: Connection reset by peer) |
| 2022-11-14 05:08:51 +0100 | ddellacosta | (~ddellacos@89.45.224.59) (Ping timeout: 260 seconds) |
| 2022-11-14 05:10:37 +0100 | <davean> | SrPx: To some degree thats the why and how of sorting being recursive! |
| 2022-11-14 05:12:45 +0100 | srk | (~sorki@user/srk) (Quit: ZNC 1.8.1 - https://znc.in) |
| 2022-11-14 05:13:04 +0100 | manwithluck | (~manwithlu@194.177.28.176) |
| 2022-11-14 05:14:02 +0100 | <SrPx> | davean: yep sorry for not getting it earlier |
| 2022-11-14 05:17:05 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 256 seconds) |
| 2022-11-14 05:18:20 +0100 | shriekingnoise | (~shrieking@186.137.167.202) (Ping timeout: 268 seconds) |
| 2022-11-14 05:18:26 +0100 | jargon | (~jargon@184.101.188.35) (Remote host closed the connection) |
| 2022-11-14 05:18:53 +0100 | jargon | (~jargon@184.101.188.35) |
| 2022-11-14 05:19:06 +0100 | jargon | (~jargon@184.101.188.35) (Remote host closed the connection) |
| 2022-11-14 05:31:52 +0100 | srk | (~sorki@user/srk) |
| 2022-11-14 05:33:35 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-14 05:33:45 +0100 | Techcable | (~Techcable@user/Techcable) (Ping timeout: 268 seconds) |
| 2022-11-14 05:35:04 +0100 | srk| | (~sorki@user/srk) |
| 2022-11-14 05:35:54 +0100 | mbuf | (~Shakthi@49.204.121.98) |
| 2022-11-14 05:38:41 +0100 | srk | (~sorki@user/srk) (Ping timeout: 268 seconds) |
| 2022-11-14 05:38:42 +0100 | srk| | srk |
| 2022-11-14 05:40:39 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 05:45:17 +0100 | jlgw | (~jw@83-233-104-81.cust.bredband2.com) (Remote host closed the connection) |
| 2022-11-14 05:46:43 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Read error: Connection reset by peer) |
| 2022-11-14 05:51:19 +0100 | bilegeek | (~bilegeek@2600:1008:b064:c747:f92e:461d:82e7:f3a1) (Quit: Leaving) |
| 2022-11-14 05:51:38 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2022-11-14 05:53:29 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-11-14 05:54:12 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-14 06:05:08 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 06:07:23 +0100 | shriekingnoise | (~shrieking@186.137.167.202) |
| 2022-11-14 06:08:17 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 268 seconds) |
| 2022-11-14 06:12:16 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-14 06:12:16 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-14 06:12:16 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-14 06:16:18 +0100 | <davean> | No problem, its sorta a deep implication of sorting networks |
| 2022-11-14 06:16:29 +0100 | <davean> | most CS people never get it :-p |
| 2022-11-14 06:16:40 +0100 | polo | (~polo@pool-100-11-18-203.phlapa.fios.verizon.net) |
| 2022-11-14 06:18:04 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-14 06:20:33 +0100 | mvk | (~mvk@2607:fea8:5ce3:8500::4b68) (Ping timeout: 256 seconds) |
| 2022-11-14 06:21:12 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-11-14 06:24:12 +0100 | <SrPx> | I love how that's both mind-blowing and absolutely reasonable |
| 2022-11-14 06:25:39 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 256 seconds) |
| 2022-11-14 06:25:39 +0100 | polo | (~polo@pool-100-11-18-203.phlapa.fios.verizon.net) (Ping timeout: 256 seconds) |
| 2022-11-14 06:29:15 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds) |
| 2022-11-14 06:29:53 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2022-11-14 06:34:42 +0100 | razetime | (~quassel@117.254.35.246) |
| 2022-11-14 06:34:58 +0100 | j4cc3b | (~j4cc3b@pool-74-105-2-138.nwrknj.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2022-11-14 06:43:47 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
| 2022-11-14 06:45:34 +0100 | Techcable | (~Techcable@user/Techcable) |
| 2022-11-14 06:54:47 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 2022-11-14 06:55:37 +0100 | freeside_ | (~mengwong@103.252.202.193) |
| 2022-11-14 06:57:37 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 2022-11-14 07:01:56 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-11-14 07:07:08 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2022-11-14 07:15:47 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 260 seconds) |
| 2022-11-14 07:16:59 +0100 | Batzy_ | (~quassel@user/batzy) |
| 2022-11-14 07:17:27 +0100 | Batzy | (~quassel@user/batzy) (Read error: Connection reset by peer) |
| 2022-11-14 07:17:47 +0100 | DDR | (~DDR@2604:3d08:4c7f:8250:ab47:a2f3:7012:8f4a) (Ping timeout: 256 seconds) |
| 2022-11-14 07:19:43 +0100 | chomwitt | (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) |
| 2022-11-14 07:20:37 +0100 | manwithluck | (~manwithlu@194.177.28.176) (Read error: Connection reset by peer) |
| 2022-11-14 07:21:03 +0100 | shriekingnoise | (~shrieking@186.137.167.202) (Ping timeout: 268 seconds) |
| 2022-11-14 07:21:21 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-11-14 07:22:55 +0100 | aliosablack | (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) |
| 2022-11-14 07:23:27 +0100 | chomwitt | (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) (Read error: Connection reset by peer) |
| 2022-11-14 07:23:33 +0100 | manwithluck | (~manwithlu@194.177.28.176) |
| 2022-11-14 07:32:02 +0100 | Batzy_ | (~quassel@user/batzy) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-11-14 07:33:21 +0100 | Batzy | (~quassel@user/batzy) |
| 2022-11-14 07:35:33 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-11-14 07:39:46 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-14 07:42:10 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-14 07:44:36 +0100 | mikoto-chan | (~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) |
| 2022-11-14 07:45:21 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-14 07:47:24 +0100 | dfee | (~dfee@162-227-164-101.lightspeed.sntcca.sbcglobal.net) |
| 2022-11-14 07:48:38 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2022-11-14 07:50:04 +0100 | clu | (~clu@user/varjax) |
| 2022-11-14 07:57:15 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-14 07:58:57 +0100 | Kaipei | (~Kaiepi@108.175.84.104) |
| 2022-11-14 08:06:17 +0100 | iqubic | (~iqubic@2601:602:9502:c70:76bd:8eff:1f39:3cbe) |
| 2022-11-14 08:06:55 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Read error: Connection reset by peer) |
| 2022-11-14 08:08:02 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 08:08:07 +0100 | causal | (~user@50.35.83.177) (Quit: WeeChat 3.7.1) |
| 2022-11-14 08:11:05 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-11-14 08:12:55 +0100 | random-jellyfish | (~random-je@user/random-jellyfish) |
| 2022-11-14 08:15:59 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2022-11-14 08:20:42 +0100 | kenran | (~user@user/kenran) |
| 2022-11-14 08:20:47 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-14 08:23:55 +0100 | youziqi | (~youziqi@103.37.140.19) (Ping timeout: 260 seconds) |
| 2022-11-14 08:24:01 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-11-14 08:25:11 +0100 | hsw_ | (~hsw@112-104-87-192.adsl.dynamic.seed.net.tw) |
| 2022-11-14 08:26:35 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Ping timeout: 248 seconds) |
| 2022-11-14 08:30:25 +0100 | youziqi | (~youziqi@103.37.140.121) |
| 2022-11-14 08:32:14 +0100 | michalz | (~michalz@185.246.207.203) |
| 2022-11-14 08:35:03 +0100 | razetime | (~quassel@117.254.35.246) (Ping timeout: 268 seconds) |
| 2022-11-14 08:35:23 +0100 | razetime | (~quassel@117.254.35.246) |
| 2022-11-14 08:37:13 +0100 | random-jellyfish | (~random-je@user/random-jellyfish) (Quit: Client closed) |
| 2022-11-14 08:37:34 +0100 | <Unhammer> | https://hackage.haskell.org/package/base-4.17.0.0/docs/Foreign-C-String.html is there one of these for bytestrings? uses "current locale" ew |
| 2022-11-14 08:42:07 +0100 | <[exa]> | Unhammer: ByteString has useAsCString, and you can manage the coding issues yourself using the standard bytestring utils |
| 2022-11-14 08:42:31 +0100 | <[exa]> | see around here https://hackage.haskell.org/package/bytestring-0.11.3.1/docs/Data-ByteString.html#g:25 |
| 2022-11-14 08:44:27 +0100 | <Unhammer> | ooh thanks [exa] |
| 2022-11-14 08:44:50 +0100 | <Unhammer> | hoogle for once was not elpful https://hoogle.haskell.org/?hoogle=ByteString%20-%3E%20CString |
| 2022-11-14 08:45:21 +0100 | <Unhammer> | oogle was not elpful, as they said in 'allo 'allo |
| 2022-11-14 08:46:55 +0100 | [exa] | hesitantly looks out of the window at the French borders |
| 2022-11-14 08:48:06 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Remote host closed the connection) |
| 2022-11-14 08:49:20 +0100 | <Unhammer> | =D |
| 2022-11-14 08:49:24 +0100 | wrengr | (~wrengr@201.59.83.34.bc.googleusercontent.com) (Remote host closed the connection) |
| 2022-11-14 08:49:29 +0100 | freeside_ | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-14 08:49:35 +0100 | <[exa]> | anyway yeah the surprise IO there doesn't elp it much |
| 2022-11-14 08:51:25 +0100 | merijn | (~merijn@86.86.29.250) |
| 2022-11-14 09:00:19 +0100 | mikoto-chan | (~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) (Ping timeout: 260 seconds) |
| 2022-11-14 09:01:54 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:9b29:5558:d4cc:17cc) |
| 2022-11-14 09:03:09 +0100 | <tomsmeding> | Is it compatible with the semantics of Haskell to have an interpreter that takes a haskell-src-exts AST, say, and single-steps the program, each time producing an AST again, slightly modified |
| 2022-11-14 09:03:32 +0100 | <tomsmeding> | or are there instances of laziness where you can't express the intermediate form at some point of execution as a Haskell AST |
| 2022-11-14 09:04:02 +0100 | razetime | (~quassel@117.254.35.246) (Ping timeout: 268 seconds) |
| 2022-11-14 09:04:08 +0100 | <tomsmeding> | (This in response to a suggestion in -offtopic but also something I've wondered myself, and it was not -offtopic hence here) |
| 2022-11-14 09:06:06 +0100 | kuribas | (~user@ptr-17d51emijpptyt1h7er.18120a2.ip6.access.telenet.be) |
| 2022-11-14 09:07:26 +0100 | odnes | (~odnes@5-203-237-249.pat.nym.cosmote.net) |
| 2022-11-14 09:07:29 +0100 | odnes | (~odnes@5-203-237-249.pat.nym.cosmote.net) (Remote host closed the connection) |
| 2022-11-14 09:08:19 +0100 | <opqdonut> | interesting question |
| 2022-11-14 09:09:37 +0100 | <opqdonut> | and a tool like that would be nice for teaching. I've written out step-by-step evaluations like that for things like `first . filter f . map g` |
| 2022-11-14 09:09:51 +0100 | <tomsmeding> | yeah the intended application would be teaching and debugging :p |
| 2022-11-14 09:10:41 +0100 | clu | (~clu@user/varjax) (Quit: WeeChat 3.7.1) |
| 2022-11-14 09:11:11 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-14 09:12:11 +0100 | <tomsmeding> | I feel that one should be able to do this, if you put all thunks you're currently evaluating in a 'let' |
| 2022-11-14 09:12:43 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-14 09:14:02 +0100 | <opqdonut> | yeah |
| 2022-11-14 09:14:10 +0100 | <opqdonut> | definitely for a suitably limited subset of haskell |
| 2022-11-14 09:14:20 +0100 | <tomsmeding> | right |
| 2022-11-14 09:14:21 +0100 | mmhat | (~mmh@p50857d40.dip0.t-ipconnect.de) |
| 2022-11-14 09:14:50 +0100 | <tomsmeding> | yeah not sure if this will play well with some of the type system extensions, for GADTs and TypeFamilies you're going to need lots of annoying type annotations |
| 2022-11-14 09:15:08 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-14 09:15:14 +0100 | <tomsmeding> | but for the teaching purpose we can safely skip those since if the students are there already, they're supposed to already understand the basic evaluation model :D |
| 2022-11-14 09:15:21 +0100 | kenran` | (~user@user/kenran) |
| 2022-11-14 09:15:42 +0100 | <opqdonut> | I think for even Haskell98 type classes, you're going to need stuff like `f (1::Int) (show :: Int -> String)` |
| 2022-11-14 09:15:57 +0100 | <tomsmeding> | hm that's right |
| 2022-11-14 09:15:59 +0100 | <opqdonut> | yeah but this can be glossed over |
| 2022-11-14 09:16:37 +0100 | <tomsmeding> | bonus points for writing functionality to detect when the type annotations are necessary for correct semantics, and only displaying them then |
| 2022-11-14 09:16:50 +0100 | kenran | (~user@user/kenran) (Ping timeout: 240 seconds) |
| 2022-11-14 09:17:59 +0100 | ropwareJB | (~ropwareJB@180-150-36-243.b49624.bne.nbn.aussiebb.net) (Quit: Client closed) |
| 2022-11-14 09:20:24 +0100 | <dminuoso> | That moment when concatenating with newlines suddenly is not associative... |
| 2022-11-14 09:20:38 +0100 | dminuoso | stares at his screen in disbelief |
| 2022-11-14 09:20:41 +0100 | <tomsmeding> | O.o |
| 2022-11-14 09:20:45 +0100 | evanvarvell | (~evanvarve@097-088-181-216.res.spectrum.com) |
| 2022-11-14 09:21:28 +0100 | razetime | (~quassel@117.254.35.246) |
| 2022-11-14 09:22:55 +0100 | <dminuoso> | Yeah, so on one hand I use `vsep` from pretty printer to the effect of `pprMod = vsep ["A", "B"]`, and then traverse over a thing using `traverse_ (yieldDoc . pprMod) mods` with `yieldDoc = yield . render . (<> hardline)` |
| 2022-11-14 09:23:16 +0100 | <dminuoso> | And the conduit produces lines in the shape of ["A", "A", "A", "B", "B", "B"] |
| 2022-11-14 09:23:24 +0100 | <dminuoso> | This is stunning |
| 2022-11-14 09:23:36 +0100 | <InstX1> | is it heresy to say that Haskell is terrible for learning software engineering, but good for learning computer science? |
| 2022-11-14 09:23:47 +0100 | <InstX1> | as a rank beginner |
| 2022-11-14 09:23:50 +0100 | cafkafk | (~cafkafk@fsf/member/cafkafk) |
| 2022-11-14 09:23:51 +0100 | <dminuoso> | I would say its nonsense *shrugs* |
| 2022-11-14 09:24:06 +0100 | <InstX1> | i can't get into the projects stage with Haskell |
| 2022-11-14 09:24:22 +0100 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) |
| 2022-11-14 09:25:04 +0100 | <InstX1> | also, what happened to Until? |
| 2022-11-14 09:25:06 +0100 | <InstX1> | until? |
| 2022-11-14 09:25:21 +0100 | <InstX1> | I did some benchmarking, accumulating parameter version of sum seems to outperform the foldl' based implementation |
| 2022-11-14 09:25:30 +0100 | merijn | (~merijn@86.86.29.250) (Ping timeout: 240 seconds) |
| 2022-11-14 09:25:32 +0100 | <InstX1> | until, however, is a disaster |
| 2022-11-14 09:26:00 +0100 | <tomsmeding> | InstX1: what's that oine |
| 2022-11-14 09:26:02 +0100 | <tomsmeding> | *one |
| 2022-11-14 09:26:12 +0100 | <InstX1> | until is a built in reverse while loop in base |
| 2022-11-14 09:26:14 +0100 | <iqubic> | @hoogle until |
| 2022-11-14 09:26:15 +0100 | <lambdabot> | Prelude until :: (a -> Bool) -> (a -> a) -> a -> a |
| 2022-11-14 09:26:15 +0100 | <lambdabot> | GHC.Base until :: (a -> Bool) -> (a -> a) -> a -> a |
| 2022-11-14 09:26:15 +0100 | <lambdabot> | Test.Hspec.Discover until :: () => (a -> Bool) -> (a -> a) -> a -> a |
| 2022-11-14 09:26:34 +0100 | <iqubic> | @src until |
| 2022-11-14 09:26:34 +0100 | <lambdabot> | until p f x | p x = x |
| 2022-11-14 09:26:34 +0100 | <lambdabot> | | otherwise = until p f (f x) |
| 2022-11-14 09:26:49 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-11-14 09:27:43 +0100 | <InstX1> | oh, looks like something was probably wrong with my benchmarks |
| 2022-11-14 09:28:24 +0100 | <InstX1> | still until is a disaster |
| 2022-11-14 09:29:02 +0100 | <iqubic> | It doesn't seem to bad to me |
| 2022-11-14 09:31:42 +0100 | <InstX1> | could have been an implementation thing |
| 2022-11-14 09:31:43 +0100 | Batzy | (~quassel@user/batzy) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-11-14 09:31:47 +0100 | <InstX1> | as in, i ended up doing it as a tuple |
| 2022-11-14 09:32:06 +0100 | Batzy | (~quassel@user/batzy) |
| 2022-11-14 09:32:12 +0100 | <tomsmeding> | InstX1: what's your implementation |
| 2022-11-14 09:32:30 +0100 | <InstX1> | i deleted it, it's just something i remember from benchmarks |
| 2022-11-14 09:32:36 +0100 | <InstX1> | but it involved creating a tuple for a control variable |
| 2022-11-14 09:33:16 +0100 | <tomsmeding> | there is the possibility that you "should" have seq'd the tuple elements, because tuples are lazy |
| 2022-11-14 09:33:20 +0100 | <tomsmeding> | but we can't know now :) |
| 2022-11-14 09:34:45 +0100 | <InstX1> | yeah, too tired to benchmark it again |
| 2022-11-14 09:35:51 +0100 | chele | (~chele@user/chele) |
| 2022-11-14 09:37:18 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-14 09:42:33 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-11-14 09:47:32 +0100 | acidjnk | (~acidjnk@p200300d6e7137a015d19df638f338baf.dip0.t-ipconnect.de) |
| 2022-11-14 09:48:36 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 2022-11-14 09:49:36 +0100 | machinedgod | (~machinedg@clnet-p10-126.ikbnet.co.at) |
| 2022-11-14 09:52:50 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 240 seconds) |
| 2022-11-14 09:52:51 +0100 | nschoe | (~q@141.101.51.197) |
| 2022-11-14 09:56:05 +0100 | Batzy | (~quassel@user/batzy) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-11-14 09:56:55 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) |
| 2022-11-14 09:57:19 +0100 | Batzy | (~quassel@user/batzy) |
| 2022-11-14 09:59:49 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-14 10:02:56 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-14 10:10:03 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2022-11-14 10:22:01 +0100 | ub | (~Thunderbi@77.119.171.26.wireless.dyn.drei.com) |
| 2022-11-14 10:22:03 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-11-14 10:23:03 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-11-14 10:23:46 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-14 10:24:37 +0100 | Guest7325 | (~coco@85.195.206.136) |
| 2022-11-14 10:25:28 +0100 | ubert1 | (~Thunderbi@77.119.222.7.wireless.dyn.drei.com) |
| 2022-11-14 10:25:38 +0100 | ub1 | (~Thunderbi@77.119.222.7.wireless.dyn.drei.com) |
| 2022-11-14 10:26:01 +0100 | Guest7325 | hahahhuhuu |
| 2022-11-14 10:26:09 +0100 | hahahhuhuu | c0c0 |
| 2022-11-14 10:26:21 +0100 | finsternis | (~X@23.226.237.192) (Read error: Connection reset by peer) |
| 2022-11-14 10:26:37 +0100 | ensyde | (~psy@104-62-224-96.lightspeed.chrlnc.sbcglobal.net) (Quit: WeeChat 2.8) |
| 2022-11-14 10:26:40 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-14 10:26:40 +0100 | ubert | (~Thunderbi@77.119.171.26.wireless.dyn.drei.com) (Ping timeout: 268 seconds) |
| 2022-11-14 10:26:41 +0100 | ub1 | ubert |
| 2022-11-14 10:26:54 +0100 | ub | (~Thunderbi@77.119.171.26.wireless.dyn.drei.com) (Ping timeout: 260 seconds) |
| 2022-11-14 10:31:01 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-11-14 10:44:10 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-14 10:51:08 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2022-11-14 10:54:48 +0100 | Heyting | (~Heyting@193.198.16.217) |
| 2022-11-14 10:54:49 +0100 | Heyting | (~Heyting@193.198.16.217) (Remote host closed the connection) |
| 2022-11-14 10:55:39 +0100 | CiaoSen | (~Jura@p200300c9571247002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-11-14 11:06:49 +0100 | <kuribas> | InstX1: I'd say haskell is great for learning software engineering, but only decent for learning computer science. |
| 2022-11-14 11:07:02 +0100 | <kuribas> | InstX1: besides, computer science is mostly math. |
| 2022-11-14 11:07:22 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 268 seconds) |
| 2022-11-14 11:07:27 +0100 | <InstX1> | i'm stalled because I can't get from the "I can do hundreds of exercises in a few months on Codewars" phase to the productive programming phase |
| 2022-11-14 11:07:42 +0100 | <InstX1> | hurts that I'm working on Windows, meaning it's hard to get GUI |
| 2022-11-14 11:08:11 +0100 | <kuribas> | yeah, nobody bothered to make good UI libraries for haskell |
| 2022-11-14 11:08:41 +0100 | <InstX1> | actual projects are probably more about Servant than any GUI apps |
| 2022-11-14 11:09:05 +0100 | <kuribas> | ooh, SICP comes with javascript now :-O https://www.bol.com/nl/nl/p/structure-and-interpretation-of-computer-programs/9300000039441478/?s2… |
| 2022-11-14 11:09:27 +0100 | <kuribas> | InstX1: I think most haskell in industry is backend programs. |
| 2022-11-14 11:09:56 +0100 | <kuribas> | IMO these days idris is a better language for teaching than haskell. |
| 2022-11-14 11:10:03 +0100 | <InstX1> | i'm wondering, what's the better Javascript book, Eloquent Javascript or SICP? |
| 2022-11-14 11:11:50 +0100 | <kuribas> | SICP isn't a javascript book |
| 2022-11-14 11:11:51 +0100 | <InstX1> | well, MIT already switched off to Python, so SICP is probably obsolete in that context |
| 2022-11-14 11:11:59 +0100 | <kuribas> | it's not a scheme book either |
| 2022-11-14 11:12:00 +0100 | <InstX1> | SICP is a principles book, no? |
| 2022-11-14 11:12:03 +0100 | <kuribas> | yes |
| 2022-11-14 11:13:14 +0100 | kenaryn | (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) |
| 2022-11-14 11:13:37 +0100 | <kuribas> | true, it's probably better to have SICP in JS than no SICP at all. |
| 2022-11-14 11:16:05 +0100 | mastarija | (~mastarija@2a05:4f46:e03:6000:9658:d7fb:b925:5ab5) |
| 2022-11-14 11:17:56 +0100 | <JensPetersen[m]> | Is there a good reason why <$!> is only defined for Monad (eg not Functor)? |
| 2022-11-14 11:17:59 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 260 seconds) |
| 2022-11-14 11:18:05 +0100 | <mastarija> | when using lenses, is there a combinator to modify only a value with a specific index? |
| 2022-11-14 11:19:34 +0100 | zer0bitz_ | (~zer0bitz@196.244.192.54) () |
| 2022-11-14 11:20:43 +0100 | <InstX1> | I have the old Second Edition / lisp version |
| 2022-11-14 11:20:44 +0100 | <InstX1> | scheme |
| 2022-11-14 11:21:26 +0100 | <c0c0> | I'm on NixOS and don't manage to get vscode working with the HLS (haskell.haskell extension). Can someone point me to up-to-date instructions for how to set it up? |
| 2022-11-14 11:21:33 +0100 | <kuribas> | :t at |
| 2022-11-14 11:21:34 +0100 | <lambdabot> | (At m, Functor f) => Index m -> (Maybe (IxValue m) -> f (Maybe (IxValue m))) -> m -> f m |
| 2022-11-14 11:21:55 +0100 | <kuribas> | -- mastarija |
| 2022-11-14 11:22:12 +0100 | <mastarija> | Hm.. |
| 2022-11-14 11:23:12 +0100 | <mastarija> | So I need to provide a function that takes "maybe" value and gives back "maybe" wrapped in f? |
| 2022-11-14 11:23:43 +0100 | ephemient | (uid407513@id-407513.lymington.irccloud.com) |
| 2022-11-14 11:23:59 +0100 | <mastarija> | Isn't there something like a simple setter that justs sets the value if old one exist, and returns unmodified container otherwise? |
| 2022-11-14 11:24:05 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-11-14 11:24:44 +0100 | <mastarija> | Like `myRecord & seti myIndex myVal` |
| 2022-11-14 11:25:19 +0100 | zer0bitz | (~zer0bitz@196.244.192.54) |
| 2022-11-14 11:27:42 +0100 | <dminuoso> | mastarija: fmap or <$> |
| 2022-11-14 11:28:06 +0100 | <dminuoso> | Or do you mean using lenses? |
| 2022-11-14 11:28:10 +0100 | <mastarija> | Lenses |
| 2022-11-14 11:28:16 +0100 | <dminuoso> | You just use `over` |
| 2022-11-14 11:28:37 +0100 | <dminuoso> | Or `set`, or any of their operator variants |
| 2022-11-14 11:28:48 +0100 | <mastarija> | Like, I want to modify a value of a particular key in a map, in a record |
| 2022-11-14 11:29:03 +0100 | <dminuoso> | like (.~) or (%~) |
| 2022-11-14 11:29:17 +0100 | <mastarija> | myRecord .~ _myMap key newValue |
| 2022-11-14 11:29:21 +0100 | <mastarija> | SOmething like this |
| 2022-11-14 11:29:33 +0100 | <dminuoso> | myRecord & at "key" .~ newValue |
| 2022-11-14 11:29:43 +0100 | <mastarija> | Aha |
| 2022-11-14 11:29:45 +0100 | <mastarija> | Cool |
| 2022-11-14 11:29:58 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-11-14 11:30:00 +0100 | <mastarija> | Does it work for arrays as well? |
| 2022-11-14 11:30:06 +0100 | <dminuoso> | What do you mean? |
| 2022-11-14 11:30:21 +0100 | <mastarija> | Wait... |
| 2022-11-14 11:30:26 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-14 11:30:26 +0100 | <mastarija> | That example is wrong |
| 2022-11-14 11:30:33 +0100 | <dminuoso> | Do note however, that to satisfy your request you must compose it with _Just probably |
| 2022-11-14 11:30:33 +0100 | <mastarija> | I have a record that has a Map within it |
| 2022-11-14 11:30:55 +0100 | <dminuoso> | To do that, and include your record, you would have to do: |
| 2022-11-14 11:30:55 +0100 | <mastarija> | MyRecord { myMap :: Map Key Val } |
| 2022-11-14 11:31:23 +0100 | <dminuoso> | myRecord & field.at "key"._Just .~ 10 |
| 2022-11-14 11:31:55 +0100 | <dminuoso> | (Since you only want to to update an existing entry in the map, but not set one if none previous exists, if I understood that right) |
| 2022-11-14 11:32:10 +0100 | <mastarija> | so myRecord & myMap . at someKey . _Just .~ 10 |
| 2022-11-14 11:32:12 +0100 | <mastarija> | yes |
| 2022-11-14 11:32:16 +0100 | <mastarija> | That's correct |
| 2022-11-14 11:32:24 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-11-14 11:32:29 +0100 | <mastarija> | Is there any lens tutorial that deals with such topics? |
| 2022-11-14 11:33:02 +0100 | <mastarija> | I've only found ones that explain what lenses are, but not what usefull combinators there are, and some interesting usecases. |
| 2022-11-14 11:34:10 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 240 seconds) |
| 2022-11-14 11:34:53 +0100 | <dminuoso> | Well, it is sort of expected you explore the library yourself. |
| 2022-11-14 11:35:22 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2022-11-14 11:35:42 +0100 | <dminuoso> | I personally prefer `optics`, but even if you want to use `lens`, what you could do is use the `optics` documentation as its much better organized and documented, and then just find the corresponding combinators in `lens` |
| 2022-11-14 11:36:09 +0100 | <mastarija> | Didn't know about that. I'll check it out. |
| 2022-11-14 11:37:05 +0100 | <dminuoso> | One of the benefits of `optics` is that they are much better typed, which makes the types easier to read. But anyway, dont misunderstand this as an attempt to sway you to `optics`. |
| 2022-11-14 11:37:37 +0100 | <dminuoso> | While we mostly use `optics`, when I do use `lens` I still use the `optics` documentation because for the most part the combinators are named the same wayu |
| 2022-11-14 11:38:00 +0100 | <mastarija> | So, if I have IndexedTraversal' then I can't use the at, right? |
| 2022-11-14 11:38:12 +0100 | <dminuoso> | What do you mean `I can't use the at`? |
| 2022-11-14 11:38:32 +0100 | <[Leary]> | JensPetersen[m]: Functor can't do it---at least, not in a way that means the same thing. `(<$!>) f = fmap \x -> let z = f x in z `seq` z` is pointless because `z `seq` z` is the same as `z`. If what you want is `(<$!>) f = fmap \x -> x `seq` f x`, then that does something, but you can already do that with: `(f $!) <$> ...`. |
| 2022-11-14 11:38:40 +0100 | <mastarija> | myRecord & _myMapIndexedTraversal . at "key" ... |
| 2022-11-14 11:38:46 +0100 | <mastarija> | dminuoso: |
| 2022-11-14 11:38:55 +0100 | <dminuoso> | What is the type of `_myMapIndexedTraversal`? |
| 2022-11-14 11:39:11 +0100 | <dminuoso> | mastarija: at any rate, yes you can do that. |
| 2022-11-14 11:39:21 +0100 | <dminuoso> | being able to do just that, is what makes lens so crazy. :) |
| 2022-11-14 11:39:28 +0100 | <JensPetersen[m]> | [Leary]: aha, thanks |
| 2022-11-14 11:39:42 +0100 | <mastarija> | dminuoso: IndexedTraversal' MyKey MyRecord MyValue |
| 2022-11-14 11:39:52 +0100 | <dminuoso> | mastarija: No this will work just fine, then. |
| 2022-11-14 11:39:58 +0100 | <mastarija> | Cool |
| 2022-11-14 11:40:07 +0100 | <dminuoso> | You might have to do some bit of shifting if you want to preserve the original index |
| 2022-11-14 11:40:15 +0100 | <dminuoso> | Or you can just degrade to non-indexed |
| 2022-11-14 11:40:45 +0100 | <dminuoso> | See (<.), (<.>) and (.>) |
| 2022-11-14 11:41:05 +0100 | <dminuoso> | In principle (.) acts the same as (.>) which means "preserve the index to the right" |
| 2022-11-14 11:41:10 +0100 | kuribas | (~user@ptr-17d51emijpptyt1h7er.18120a2.ip6.access.telenet.be) (Ping timeout: 240 seconds) |
| 2022-11-14 11:41:24 +0100 | <dminuoso> | So you might have to do something like |
| 2022-11-14 11:41:47 +0100 | <dminuoso> | `_myMapIndexedTraversal <. at "key" <. _Just` if you intend to use say `iover` or `iset` |
| 2022-11-14 11:42:20 +0100 | <dminuoso> | Uh, actually the second (<.) is probably erreneous and redundant |
| 2022-11-14 11:42:43 +0100 | <mastarija> | Wait, what? I thought we were just replacing the value at the specified index, no? |
| 2022-11-14 11:42:59 +0100 | <mastarija> | Index being a key in Map, or position in array? |
| 2022-11-14 11:43:02 +0100 | <dminuoso> | mastarija: There's two uses of the word `index` here |
| 2022-11-14 11:43:24 +0100 | <dminuoso> | And maybe there's additional confusion |
| 2022-11-14 11:43:28 +0100 | <dminuoso> | Can you share the code and relevant type signatures? |
| 2022-11-14 11:43:45 +0100 | <dminuoso> | Is `MyValue ~ Map K V`? If yes, what is `K`? |
| 2022-11-14 11:44:14 +0100 | random-jellyfish | (~random-je@user/random-jellyfish) |
| 2022-11-14 11:49:50 +0100 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Ping timeout: 255 seconds) |
| 2022-11-14 11:52:16 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-14 11:55:47 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-14 12:01:32 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2022-11-14 12:11:16 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-14 12:12:02 +0100 | xff0x | (~xff0x@2405:6580:b080:900:fc69:8fe6:1c5d:8fdb) |
| 2022-11-14 12:12:34 +0100 | luseerr | (~luseerr@145.224.100.107) |
| 2022-11-14 12:14:32 +0100 | <luseerr> | Hi! Is there any go-to library in haskell for parsing phone numbers? I found this lib https://hackage.haskell.org/package/phone-numbers which does exactly what I need but for some reason when trying to install it through stack I get an error "Missing (or bad) C libraries: phonenumber, protobuf" which as a newb I don't really follow. I could install |
| 2022-11-14 12:14:32 +0100 | <luseerr> | them locally somehow outside of stack I suppose, but then what happens in the build/release process? Any pointers appreciated! |
| 2022-11-14 12:20:27 +0100 | __monty__ | (~toonn@user/toonn) |
| 2022-11-14 12:21:35 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2022-11-14 12:24:35 +0100 | <[exa]> | I'm slightly surprised by the fact that even phone numbers have to be parsed nowadays |
| 2022-11-14 12:25:21 +0100 | Guest96 | (~Guest96@2401:4900:1cb9:ca12:255d:d66f:31b:83bb) |
| 2022-11-14 12:26:05 +0100 | <[exa]> | anyway there's apparently `libphonenumber`, you might have luck simply calling it using FFI |
| 2022-11-14 12:27:05 +0100 | <[exa]> | regarding the error, you might need to install the system library dependencies -- I'd expect something like libphonenumber-dev and libprotobuf-dev packages (assuming you're on unix) |
| 2022-11-14 12:27:08 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-11-14 12:31:00 +0100 | kenaryn | (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) (Quit: leaving) |
| 2022-11-14 12:31:59 +0100 | Guest96 | (~Guest96@2401:4900:1cb9:ca12:255d:d66f:31b:83bb) (Quit: Client closed) |
| 2022-11-14 12:32:17 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-11-14 12:32:26 +0100 | <dminuoso> | [exa]: phone-numbers is an ffi binding for libphonenumber |
| 2022-11-14 12:33:15 +0100 | <dminuoso> | [exa]: And of coure they have to be parsed. There's so many different phone number formats.. |
| 2022-11-14 12:35:34 +0100 | <fendor[m]> | since some recent ghc versions, the order of implicit forall's type variables has changed, what is the order now? Something deterministic? |
| 2022-11-14 12:35:36 +0100 | <dminuoso> | So sometimes a phone number might have non-digits in them, e.g. `0800 mycompany`, conflicts with country codes and area codes (Germany is a snowflake here, as 049* is a valid area code prefix, unlike virtually all other countries, which leads to ambiguity in some shorter conventions) |
| 2022-11-14 12:35:56 +0100 | <dminuoso> | fendor[m]: in order of appearance in the type signature as far as I remember |
| 2022-11-14 12:36:18 +0100 | <dminuoso> | but its not defined api either |
| 2022-11-14 12:36:42 +0100 | <dminuoso> | Which is part of why TypeApplications is such a poor utility, there is no guarantee the order wont change again |
| 2022-11-14 12:36:49 +0100 | <fendor[m]> | ah, that makes sense, thanks! |
| 2022-11-14 12:37:25 +0100 | <dminuoso> | fendor[m]: Note that there is some subtle annoying implications, as the constraint is considered to. |
| 2022-11-14 12:37:47 +0100 | <dminuoso> | Which means something turning `a -> b -> c` into `C b => a -> b -> c` will suddenly alter the type variable order |
| 2022-11-14 12:37:56 +0100 | <fendor[m]> | of course, using explicit forall's the solution |
| 2022-11-14 12:38:03 +0100 | <fendor[m]> | *is the solution |
| 2022-11-14 12:38:10 +0100 | <dminuoso> | I rather consider explicit Proxy a better solution |
| 2022-11-14 12:38:42 +0100 | <dminuoso> | There's a bunch of subtle problems otherwise, because once the type is back inferred, you cannot apply type variables anymore |
| 2022-11-14 12:38:59 +0100 | <fendor[m]> | I was just wondering, since I change my type signatures quite considerably, delete the previous sig, then let HLS infer the type, but since that includes implicit kind variables as well, I delete foralls, since otherwise the type sig is like 5 lines long |
| 2022-11-14 12:39:14 +0100 | <dminuoso> | so if you do something like |
| 2022-11-14 12:39:17 +0100 | <dminuoso> | % :set -XTypeApplication |
| 2022-11-14 12:39:17 +0100 | <yahb2> | Some flags have not been recognized: -XTypeApplication |
| 2022-11-14 12:39:20 +0100 | <dminuoso> | % :set -XTypeApplications |
| 2022-11-14 12:39:20 +0100 | <yahb2> | <no output> |
| 2022-11-14 12:39:24 +0100 | <dminuoso> | % f a = a |
| 2022-11-14 12:39:24 +0100 | <yahb2> | <no output> |
| 2022-11-14 12:39:30 +0100 | <dminuoso> | % f @Int 1 |
| 2022-11-14 12:39:30 +0100 | <yahb2> | <interactive>:16:1: error: ; • Cannot apply expression of type ‘p0 -> p0’ ; to a visible type argument ‘Int’ ; • In the expression: f @Int 1 ; In an equation for ‘it’: it = f @I... |
| 2022-11-14 12:39:49 +0100 | <dminuoso> | TypeApplications is not very polished. Proxy is *much* better |
| 2022-11-14 12:40:37 +0100 | <dminuoso> | fendor[m]: https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/type_applications.html#ordering… |
| 2022-11-14 12:40:49 +0100 | <dminuoso> | By the way, so the rules are actually way more complicated than "order of appearance" |
| 2022-11-14 12:40:53 +0100 | <fendor[m]> | huh, why does that fail? I preferred TypeApplications so far, since it feels quicker to specify what you need |
| 2022-11-14 12:41:30 +0100 | <dminuoso> | Because the type is inferred. |
| 2022-11-14 12:41:40 +0100 | <dminuoso> | Now you might say "just add a type signature", consider the following example: |
| 2022-11-14 12:41:46 +0100 | <dminuoso> | % f x a = a |
| 2022-11-14 12:41:46 +0100 | <yahb2> | <no output> |
| 2022-11-14 12:41:57 +0100 | <dminuoso> | % f :: a -> b -> b; f x a = a |
| 2022-11-14 12:41:57 +0100 | <yahb2> | <no output> |
| 2022-11-14 12:42:07 +0100 | <dminuoso> | % let g = f 'c' in g @Int 1 |
| 2022-11-14 12:42:08 +0100 | <yahb2> | <interactive>:22:18: error: ; • Cannot apply expression of type ‘b0 -> b0’ ; to a visible type argument ‘Int’ ; • In the expression: g @Int 1 ; In the expression: let g = f 'c' ... |
| 2022-11-14 12:42:12 +0100 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) |
| 2022-11-14 12:42:13 +0100 | <dminuoso> | It strikes again. |
| 2022-11-14 12:42:26 +0100 | <dminuoso> | fendor[m]: Proxy is really better. :) |
| 2022-11-14 12:42:35 +0100 | <dminuoso> | Oder better yet `proxy` |
| 2022-11-14 12:43:00 +0100 | <dminuoso> | Add the fact that the ordering of specified variables is really utterly complex, and not guaranteed to be stable either... |
| 2022-11-14 12:43:21 +0100 | mikoto-chan | (~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) |
| 2022-11-14 12:43:26 +0100 | kuribas | (~user@188.188.8.143) |
| 2022-11-14 12:44:03 +0100 | <fendor[m]> | proxy the library? |
| 2022-11-14 12:44:22 +0100 | <dminuoso> | No, as in `proxy p` rather than `Proxy p` |
| 2022-11-14 12:44:42 +0100 | <dminuoso> | It even allows for cute shenanigans like passying a `Maybe Int` if so desired |
| 2022-11-14 12:46:43 +0100 | vglfr | (~vglfr@145.224.100.100) (Remote host closed the connection) |
| 2022-11-14 12:46:50 +0100 | <fendor[m]> | ah, ok so instead of `send @Int 5`, you recommend a signature `send :: proxy p -> p -> m ()`, and then invoking it via `send (Just (5 :: Int))`? I am using Just 5 now only to check that I have understood correctly |
| 2022-11-14 12:47:09 +0100 | <dminuoso> | Well you would usually still invoke it with `Proxy :: Proxy Int` |
| 2022-11-14 12:47:10 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2022-11-14 12:47:31 +0100 | <dminuoso> | But you're not constraining the caller to `Proxy`, they could also pass some argument they have lying around |
| 2022-11-14 12:47:48 +0100 | <dminuoso> | i.e.: `send f ...` where `f` already is in scope. |
| 2022-11-14 12:47:54 +0100 | vglfr | (~vglfr@145.224.100.100) |
| 2022-11-14 12:47:59 +0100 | <dminuoso> | It can be more convenient than somehow matching the type out of `f` |
| 2022-11-14 12:48:18 +0100 | <fendor[m]> | yeah makes sense |
| 2022-11-14 12:48:19 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-11-14 12:48:24 +0100 | santiagopim | (~user@90.167.66.131) |
| 2022-11-14 12:48:41 +0100 | <dminuoso> | Note, actually Proxy is where TypeApplications is fine! |
| 2022-11-14 12:48:55 +0100 | <dminuoso> | `send (Proxy @Int)` tends to be a bit more terse |
| 2022-11-14 12:49:10 +0100 | <dminuoso> | And we have the sort of guarantee that Proxy will never add more type variables anyway, so its relatively reliable |
| 2022-11-14 12:50:54 +0100 | <dminuoso> | fendor[m]: that being said, your example of `send :: proxy p -> p -> m ()` is obviously contrived, since there's really no need to pass a `proxy p` when you already have a `p` argument |
| 2022-11-14 12:51:07 +0100 | <dminuoso> | Just making that note in case this type signature is what you're actually having in mind |
| 2022-11-14 12:52:51 +0100 | <fendor[m]> | while I am not entirely sure I really need TypeApplications in my example, I think it is still helpful to disambiguate literals, that's why I have it. |
| 2022-11-14 12:53:29 +0100 | <dminuoso> | You mean string (in the presence of OverloadedStrings) or numeric literals? |
| 2022-11-14 12:53:38 +0100 | <dminuoso> | For them, yeah TypeApplications is perfectly fine. |
| 2022-11-14 12:53:59 +0100 | <dminuoso> | Though `::` is just one character more |
| 2022-11-14 12:54:17 +0100 | <fendor[m]> | both, but also just to help the type inference out in this complex situation |
| 2022-11-14 12:54:33 +0100 | <dminuoso> | Not sure what @ helps you that (::) would not |
| 2022-11-14 12:54:57 +0100 | kuribas | (~user@188.188.8.143) (Ping timeout: 256 seconds) |
| 2022-11-14 12:54:58 +0100 | <fendor[m]> | true, but `send @Int 5` fells much cleaner to me than `send (5 :: Int)`. Also easier to type, but maybe I just need to change my typing habits |
| 2022-11-14 12:55:19 +0100 | <fendor[m]> | nothing, so far I felt like it is nicer to use |
| 2022-11-14 12:55:30 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2022-11-14 12:55:37 +0100 | <dminuoso> | You can also create surrogate bindings `sendInt = ...` |
| 2022-11-14 12:55:56 +0100 | <dminuoso> | Which is what I tend to favour |
| 2022-11-14 12:56:03 +0100 | <fendor[m]> | and since we have features that I think are aesthetically slightly nicer, I was going to use them, but you made me reconsider to switch to a more reliable way |
| 2022-11-14 12:56:51 +0100 | <dminuoso> | I think there's a case to be made for monomorphic bindings, actually. It becomes searchable for refactoring, and potentially lets you document behavioral differences |
| 2022-11-14 12:56:59 +0100 | <fendor[m]> | yeah I can but `send @Int` *feels* more general and doesnt require you to type a surrogate binding and a type signature |
| 2022-11-14 12:57:32 +0100 | <dminuoso> | Is it? As a reader, I might stop and think `what does @Int` even mean here? |
| 2022-11-14 12:57:38 +0100 | <dminuoso> | Something gets set to `Int`, but what? |
| 2022-11-14 12:57:47 +0100 | <dminuoso> | is it the input? output? something in logging? |
| 2022-11-14 12:58:15 +0100 | <dminuoso> | ANd worse, they have to potentially consult the GHC manual to figure out what the first type variable even is |
| 2022-11-14 12:58:27 +0100 | <c_wraith> | I think the real problem is ad-hoc polymorphism on type variables that appear only in a negative position |
| 2022-11-14 12:58:58 +0100 | <fendor[m]> | I can see that this makes sense, but at the same time, having 20 monomorphic send functions doesn't sound like that much better |
| 2022-11-14 12:59:18 +0100 | <dminuoso> | `send (5 :: Int)` makes it clear what is happening |
| 2022-11-14 12:59:23 +0100 | <dminuoso> | `send @Int 5` does not |
| 2022-11-14 12:59:47 +0100 | <dminuoso> | Because you really have to consult both the GHC manual and the definition site of `send` to understand what your invocation means |
| 2022-11-14 13:00:48 +0100 | <dminuoso> | Perhaps the biggest annoyance is that Haskell chose a double colon for type signatures and not a single colon like the rest of ML :( |
| 2022-11-14 13:00:57 +0100 | <dminuoso> | `send (5 : Int)` reads much less noisy |
| 2022-11-14 13:01:01 +0100 | <fendor[m]> | well, IF I have an explicit type signature for send, I only need to consult the documentation |
| 2022-11-14 13:01:18 +0100 | <dminuoso> | fendor[m]: If you do not have an explicit type signature for send, you cannot use TypeApplications anyway |
| 2022-11-14 13:02:02 +0100 | <[exa]> | dminuoso: syntactically I'd welcome something that allows you to also omit the parentheses there |
| 2022-11-14 13:02:26 +0100 | <fendor[m]> | well, yes you can, right? It might just not be what you intended 😛 |
| 2022-11-14 13:02:35 +0100 | <[exa]> | dminuoso: like, `send 5::Int` would be okay but that currently means something different |
| 2022-11-14 13:02:53 +0100 | <dminuoso> | Maybe I should conjure up a SingleColons extension. |
| 2022-11-14 13:03:00 +0100 | <dminuoso> | Surely cant be much work to do |
| 2022-11-14 13:04:27 +0100 | <fendor[m]> | +1 to Singlecolons extensions |
| 2022-11-14 13:04:31 +0100 | <fendor[m]> | that'd be great |
| 2022-11-14 13:05:16 +0100 | <dminuoso> | I can already see the controvery in the discussions on the PR. |
| 2022-11-14 13:07:50 +0100 | money | polo |
| 2022-11-14 13:08:50 +0100 | <yushyin> | https://github.com/ghc-proposals/ghc-proposals/pull/118 |
| 2022-11-14 13:08:57 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-11-14 13:10:59 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-11-14 13:16:32 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-14 13:16:52 +0100 | TonyStone | (~TonyStone@cpe-74-76-57-186.nycap.res.rr.com) (Ping timeout: 268 seconds) |
| 2022-11-14 13:17:01 +0100 | <fendor[m]> | I remember ndmitchell proposed that language extension in one of their blogposts |
| 2022-11-14 13:18:30 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-11-14 13:19:19 +0100 | xff0x | (~xff0x@2405:6580:b080:900:fc69:8fe6:1c5d:8fdb) (Ping timeout: 260 seconds) |
| 2022-11-14 13:19:35 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) |
| 2022-11-14 13:21:15 +0100 | xff0x | (~xff0x@2405:6580:b080:900:fc69:8fe6:1c5d:8fdb) |
| 2022-11-14 13:23:39 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 2022-11-14 13:28:34 +0100 | evanvarvell | (~evanvarve@097-088-181-216.res.spectrum.com) (Quit: Leaving) |
| 2022-11-14 13:29:49 +0100 | TonyStone | (~TonyStone@cpe-74-76-57-186.nycap.res.rr.com) |
| 2022-11-14 13:30:59 +0100 | CiaoSen | (~Jura@p200300c9571247002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-11-14 13:33:55 +0100 | coot | (~coot@213.134.171.3) |
| 2022-11-14 13:45:05 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-14 13:46:12 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 13:46:31 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-11-14 13:48:03 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-14 13:49:15 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2022-11-14 13:52:14 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 2022-11-14 13:52:41 +0100 | MajorBiscuit | (~MajorBisc@145.94.173.65) |
| 2022-11-14 13:56:30 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 240 seconds) |
| 2022-11-14 14:07:01 +0100 | <luseerr> | dminuoso thanks a lot, appreciate! |
| 2022-11-14 14:07:03 +0100 | CiaoSen | (~Jura@p200300c9571247002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-11-14 14:11:59 +0100 | jco | (~jco@90-228-194-139-no542.tbcn.telia.com) |
| 2022-11-14 14:14:20 +0100 | lyle | (~lyle@104.246.145.85) |
| 2022-11-14 14:16:13 +0100 | ft | (~ft@p508dbd59.dip0.t-ipconnect.de) (Quit: leaving) |
| 2022-11-14 14:16:50 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
| 2022-11-14 14:18:35 +0100 | hsw_ | (~hsw@112-104-87-192.adsl.dynamic.seed.net.tw) (Ping timeout: 260 seconds) |
| 2022-11-14 14:21:10 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-11-14 14:27:51 +0100 | <dminuoso> | Why does Data.ByteString use a ForeignPtr over just say a Ptr? |
| 2022-11-14 14:28:30 +0100 | stackdroid18 | (14094@user/stackdroid) |
| 2022-11-14 14:31:00 +0100 | <dminuoso> | Is it presumably just to be able to have a ByteString with finalizers attached? Because as far as I can tell, `bytestring` itself does not rely on it |
| 2022-11-14 14:33:43 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-11-14 14:41:42 +0100 | <merijn> | dminuoso: So you can easily create bytestrings out of external objects |
| 2022-11-14 14:41:54 +0100 | <merijn> | dminuoso: Some examples that come to mind: C malloced strings, SQLite results, etc. |
| 2022-11-14 14:42:11 +0100 | <merijn> | dminuoso: And also, it kinda does |
| 2022-11-14 14:42:48 +0100 | <merijn> | dminuoso: Because you can create substrings that use the same backing ForeignPtr, so it uses the ForeignPtr machinery to detect when all references are dead and things can get dealloced |
| 2022-11-14 14:43:18 +0100 | <dminuoso> | Okay, but conversely it is not assumed one can actually attach finalizers to an arbitrary ByteString right? |
| 2022-11-14 14:43:33 +0100 | <merijn> | I mean, why not? |
| 2022-11-14 14:43:45 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-14 14:43:48 +0100 | <dminuoso> | Well, for one bytestring internally has a bunch of `mallocPlainForeignPtrBytes` uses |
| 2022-11-14 14:44:33 +0100 | <merijn> | dminuoso: It's not part of the public API |
| 2022-11-14 14:44:33 +0100 | <dminuoso> | Which creates a ForeignPtr that you cannot attach finalizers to (it's a little beyond me why that is useful at all) |
| 2022-11-14 14:44:46 +0100 | <merijn> | So the only way you can get a ForeignPtr is if you do dirty stuff |
| 2022-11-14 14:44:56 +0100 | <merijn> | So "You're On Your Own (TM)" |
| 2022-11-14 14:45:03 +0100 | <dminuoso> | :) |
| 2022-11-14 14:45:11 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 14:45:12 +0100 | <dminuoso> | Related question: |
| 2022-11-14 14:45:22 +0100 | <merijn> | I don't think the API intends for you to attach finalizer to random bytestrings, no |
| 2022-11-14 14:45:38 +0100 | <merijn> | But the ability to (sensibly) create bytestrings out of pointers with finalizers is useful for obvious reasons |
| 2022-11-14 14:46:17 +0100 | <dminuoso> | If I `mallocForeignPtrBytes`, under the hood this will use newPinnedByteArray I |
| 2022-11-14 14:46:40 +0100 | <dminuoso> | However, what happens if I `plusForeignPtr` and lose the original foreign ptr |
| 2022-11-14 14:47:18 +0100 | <merijn> | plusForeignPtr creates a foreign ptr with a finalizer that remembers the original alloc, that's the point of it existing :p |
| 2022-11-14 14:47:19 +0100 | <dminuoso> | How does the GC keep the pinned bytearray alive? Does it consider whether a pointer exists that points anywhere in the bytearray? |
| 2022-11-14 14:47:35 +0100 | <dminuoso> | merijn: no, it does not! |
| 2022-11-14 14:47:39 +0100 | <dminuoso> | plusForeignPtr (ForeignPtr addr c) (I# d) = ForeignPtr (plusAddr# addr d) c |
| 2022-11-14 14:47:44 +0100 | <dminuoso> | No finalizer is being attached |
| 2022-11-14 14:47:49 +0100 | <dminuoso> | THat's why Im a bit surprised. |
| 2022-11-14 14:47:54 +0100 | <merijn> | dminuoso: Did you, perchance, consider reading the docs of plusForeignPtr |
| 2022-11-14 14:47:57 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-11-14 14:48:10 +0100 | <dminuoso> | Err yes? |
| 2022-11-14 14:48:19 +0100 | <merijn> | dminuoso: I think the original address is already stored in the finalizer |
| 2022-11-14 14:48:29 +0100 | <merijn> | dminuoso: "the finalizer will be called with the same address that it would have had this call not happened, *not* the new address." |
| 2022-11-14 14:48:42 +0100 | <merijn> | That's pretty explicitly clarified in the plusForeignPtr docs |
| 2022-11-14 14:48:50 +0100 | <dminuoso> | That's not really what I asked about though |
| 2022-11-14 14:49:10 +0100 | <dminuoso> | That doesnt state whether the newly created foreign ptr will keep the old one alive |
| 2022-11-14 14:49:22 +0100 | <dminuoso> | Merely that finalizers are invoked with the original address, nothing further |
| 2022-11-14 14:49:25 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 256 seconds) |
| 2022-11-14 14:49:40 +0100 | Guest30 | (~Guest30@ext-1-087.eduroam.chalmers.se) |
| 2022-11-14 14:49:50 +0100 | <Guest30> | Does anyone have recent experience of using Hugs? |
| 2022-11-14 14:49:59 +0100 | <merijn> | I mean, the answer seems to be an obvious yes, putting things together |
| 2022-11-14 14:50:05 +0100 | <merijn> | Guest30: No |
| 2022-11-14 14:50:09 +0100 | <Guest30> | RIP |
| 2022-11-14 14:50:18 +0100 | <merijn> | Guest30: I mean, I think someone got it running recently on some machine for shits and giggles |
| 2022-11-14 14:50:18 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 14:50:29 +0100 | <merijn> | Guest30: But it has not been seriously used by anyone in over 15 years |
| 2022-11-14 14:50:35 +0100 | <Guest30> | I got it running alright, took some work but no more than an hour or two |
| 2022-11-14 14:50:45 +0100 | <merijn> | So I would not recommend trying to use it, except for software archeaology reasons |
| 2022-11-14 14:51:15 +0100 | <Guest30> | I want to use a more modern package with it, but I am not sure how this is done with Hugs. I saw that Cabal doesn't support Hugs anymore |
| 2022-11-14 14:51:21 +0100 | <Guest30> | E.g I want to use bytestring |
| 2022-11-14 14:51:32 +0100 | <Guest30> | This seems to depend on GHC.Prim though, so maybe this is completely fruitless? |
| 2022-11-14 14:51:33 +0100 | <merijn> | dminuoso: ForeignPtrs are pinned and not moved. Now you could hypothesise the runtime *might* free up the few prefix bytes after plusForeignPtr |
| 2022-11-14 14:51:44 +0100 | <merijn> | dminuoso: But that seems *really* hard for absolutely *tiny* gains |
| 2022-11-14 14:52:06 +0100 | <dminuoso> | merijn: Who knows! Im making a fixed bytestring builder that works from the end, so I will always have left-overs at the beginning! :P |
| 2022-11-14 14:52:07 +0100 | <merijn> | So the most logical conclusions is that "no, nothing happens it's an opaque pinned foreign blob and nothing happens until the finalizer frees it" |
| 2022-11-14 14:52:21 +0100 | <dminuoso> | well, its not the finalizer that freers |
| 2022-11-14 14:52:23 +0100 | <dminuoso> | thats the point |
| 2022-11-14 14:52:25 +0100 | <merijn> | dminuoso: That is my understanding of things and nothing has contradicted it so far |
| 2022-11-14 14:52:44 +0100 | <merijn> | dminuoso: ask in #ghc? |
| 2022-11-14 14:52:46 +0100 | <dminuoso> | Mmm, fair |
| 2022-11-14 14:52:54 +0100 | <dminuoso> | thanks for your input |
| 2022-11-14 14:52:56 +0100 | <merijn> | Guest30: Why are you truing to use Hugs in the first place, tbh? |
| 2022-11-14 14:53:04 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds) |
| 2022-11-14 14:53:07 +0100 | <Guest30> | Smaller codebase |
| 2022-11-14 14:53:17 +0100 | <Guest30> | GHC has a lot of stuff I don't need |
| 2022-11-14 14:53:36 +0100 | <merijn> | Guest30: Well, as I said, no one has used it for anything remotely serious in well over 15 years (and even then almost no one used it), so no one who writes code cares about Hugs |
| 2022-11-14 14:53:41 +0100 | <Guest30> | I am doing research, so this is just a means to an end. I don't care that much about performance etc |
| 2022-11-14 14:53:41 +0100 | <kuribas> | Guest30: then don't use it? |
| 2022-11-14 14:53:43 +0100 | random-jellyfish | (~random-je@user/random-jellyfish) (Ping timeout: 260 seconds) |
| 2022-11-14 14:53:56 +0100 | <kuribas> | Guest30: the stuff that you don't need I mean. |
| 2022-11-14 14:54:11 +0100 | <merijn> | Guest30: Presumably you do care about "not wasting weeks/months of your research time" on trying to use Hugs? :p |
| 2022-11-14 14:54:17 +0100 | <dminuoso> | Guest30: That being said, you're probably better off asking on the haskell mailing lists about Hugs. The number of hugs users is really small, and its only there that I ever hear about Hugs. |
| 2022-11-14 14:54:23 +0100 | <Guest30> | It's is not a matter of just not using it, I wouldn't want it to _be_ in the codebase |
| 2022-11-14 14:54:28 +0100 | jco | (~jco@90-228-194-139-no542.tbcn.telia.com) (Quit: leaving) |
| 2022-11-14 14:54:34 +0100 | <merijn> | dminuoso: Well, he seems to want use modern libaries, so Hugs is just right out |
| 2022-11-14 14:54:35 +0100 | <dminuoso> | Hugs is only ever mentioned in this channel as part of archaic jokes and references. |
| 2022-11-14 14:54:42 +0100 | <Guest30> | So far I only sunk one morning into this, so I won't give up yet ;) |
| 2022-11-14 14:54:59 +0100 | <merijn> | Guest30: Please do come back in a month so I can say "I told you so" ;) |
| 2022-11-14 14:55:30 +0100 | <Guest30> | My supervisor is a huge hugs fan, he will be sad by this sentiment of hugs being a joke :( |
| 2022-11-14 14:55:32 +0100 | <merijn> | Guest30: Doing research on GHC has the added benefit of having a non-zero chance of it maybe being used :p |
| 2022-11-14 14:55:49 +0100 | <merijn> | Guest30: I don't think Hugs is a joke. I do think using Hugs in 2022 is a joke :p |
| 2022-11-14 14:56:01 +0100 | <merijn> | Hugs was amazing...2-2.5 decades ago :) |
| 2022-11-14 14:56:08 +0100 | <merijn> | Time marches on |
| 2022-11-14 14:56:23 +0100 | mastarija | (~mastarija@2a05:4f46:e03:6000:9658:d7fb:b925:5ab5) (Ping timeout: 260 seconds) |
| 2022-11-14 14:56:28 +0100 | <Guest30> | Heh, I guess |
| 2022-11-14 14:56:39 +0100 | <Guest30> | Doing what I want to do with GHC might take longer though |
| 2022-11-14 14:56:58 +0100 | <merijn> | Guest30: What kinda research you trying to do? Honestly, the intersection of "I need bytestring" and "I need to play with an implementation" seems...small |
| 2022-11-14 14:57:21 +0100 | <merijn> | Guest30: Could consider UHC? That's smaller than GHC (afaik) and at least that was (until fairly recently) still actively worked on |
| 2022-11-14 14:57:29 +0100 | <merijn> | But doesn't have all the extension baggage GHC does |
| 2022-11-14 14:57:52 +0100 | <Guest30> | Bytestring was just an example |
| 2022-11-14 14:58:04 +0100 | <Guest30> | I am looking at running haskell in SGX |
| 2022-11-14 14:58:19 +0100 | <merijn> | hmm, looks like UHC kinda died about 5 years ago |
| 2022-11-14 14:58:26 +0100 | <merijn> | but that's still more recent than Hugs :p |
| 2022-11-14 14:58:53 +0100 | <dminuoso> | Guest30: I think GHC will be faster still, due to the fact of being well documented and having loads of people to potentially assist. |
| 2022-11-14 14:59:10 +0100 | <Guest30> | We already sunk two weeks into that, and sortoff hit a dead end |
| 2022-11-14 14:59:37 +0100 | marinelli | (~marinelli@gateway/tor-sasl/marinelli) |
| 2022-11-14 15:00:40 +0100 | moonsheep | (~user@user/moonsheep) |
| 2022-11-14 15:07:13 +0100 | Guest30 | (~Guest30@ext-1-087.eduroam.chalmers.se) (Quit: Connection closed) |
| 2022-11-14 15:12:39 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 256 seconds) |
| 2022-11-14 15:16:00 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 15:18:19 +0100 | eddiejessup_ | (uid575763@id-575763.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-14 15:18:19 +0100 | eddiejessup | (uid575763@id-575763.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-14 15:18:26 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-14 15:21:45 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2022-11-14 15:23:13 +0100 | slack1256 | (~slack1256@191.125.99.74) |
| 2022-11-14 15:23:17 +0100 | Kaipei | (~Kaiepi@108.175.84.104) (Ping timeout: 268 seconds) |
| 2022-11-14 15:25:36 +0100 | shriekingnoise | (~shrieking@186.137.167.202) |
| 2022-11-14 15:30:45 +0100 | ft | (~ft@p508dbd59.dip0.t-ipconnect.de) |
| 2022-11-14 15:31:11 +0100 | mikoto-chan | (~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) (Quit: WeeChat 3.6) |
| 2022-11-14 15:32:10 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 252 seconds) |
| 2022-11-14 15:32:18 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 15:35:50 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Client Quit) |
| 2022-11-14 15:36:57 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 15:42:19 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-11-14 15:43:17 +0100 | Kaipei | (~Kaiepi@108.175.84.104) |
| 2022-11-14 15:47:09 +0100 | vglfr | (~vglfr@145.224.100.100) (Ping timeout: 260 seconds) |
| 2022-11-14 15:48:28 +0100 | vglfr | (~vglfr@145.224.100.100) |
| 2022-11-14 15:52:01 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-14 15:52:01 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-14 15:52:01 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-14 15:54:56 +0100 | irrgit_ | (~irrgit@89.47.234.26) |
| 2022-11-14 15:55:56 +0100 | xacktm | (~xacktm@user/xacktm) (Ping timeout: 246 seconds) |
| 2022-11-14 15:57:12 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-11-14 16:07:28 +0100 | aliosablack | reclaim |
| 2022-11-14 16:07:39 +0100 | reclaim | chomwitt |
| 2022-11-14 16:08:26 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
| 2022-11-14 16:09:08 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) |
| 2022-11-14 16:10:15 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-14 16:14:04 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) (Read error: Connection reset by peer) |
| 2022-11-14 16:14:17 +0100 | dolio | (~dolio@130.44.134.54) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-14 16:15:00 +0100 | Inoperable | (~PLAYER_1@fancydata.science) (Ping timeout: 248 seconds) |
| 2022-11-14 16:17:47 +0100 | dolio | (~dolio@130.44.134.54) |
| 2022-11-14 16:18:03 +0100 | dolio | (~dolio@130.44.134.54) (Client Quit) |
| 2022-11-14 16:21:33 +0100 | Inoperable | (~PLAYER_1@fancydata.science) |
| 2022-11-14 16:21:50 +0100 | dolio | (~dolio@130.44.134.54) |
| 2022-11-14 16:21:55 +0100 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) |
| 2022-11-14 16:23:15 +0100 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2022-11-14 16:23:59 +0100 | moonsheep | (~user@user/moonsheep) (Remote host closed the connection) |
| 2022-11-14 16:25:07 +0100 | stackdroid18 | (14094@user/stackdroid) (Quit: hasta la vista... tchau!) |
| 2022-11-14 16:26:49 +0100 | luseerr | (~luseerr@145.224.100.107) (Quit: Client closed) |
| 2022-11-14 16:31:25 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 256 seconds) |
| 2022-11-14 16:33:05 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 16:39:46 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-11-14 16:40:05 +0100 | xacktm | (~xacktm@user/xacktm) |
| 2022-11-14 16:43:10 +0100 | azimut_ | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-14 16:43:47 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Quit: WeeChat 3.7.1) |
| 2022-11-14 16:44:45 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-11-14 16:45:29 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-11-14 16:49:38 +0100 | freeside | (~mengwong@122.11.214.147) |
| 2022-11-14 16:50:22 +0100 | coot | (~coot@213.134.171.3) |
| 2022-11-14 16:50:49 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-194.elisa-laajakaista.fi) |
| 2022-11-14 16:52:21 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-11-14 16:53:59 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 260 seconds) |
| 2022-11-14 16:54:23 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 2022-11-14 16:55:27 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 16:58:30 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 240 seconds) |
| 2022-11-14 17:00:12 +0100 | july541[m] | (~july541ma@2001:470:69fc:105::1:e416) (Quit: You have been kicked for being idle) |
| 2022-11-14 17:01:47 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-14 17:02:10 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 240 seconds) |
| 2022-11-14 17:02:52 +0100 | cafkafk | (~cafkafk@fsf/member/cafkafk) |
| 2022-11-14 17:03:05 +0100 | ubert | (~Thunderbi@77.119.222.7.wireless.dyn.drei.com) (Quit: ubert) |
| 2022-11-14 17:03:05 +0100 | ubert1 | ubert |
| 2022-11-14 17:04:37 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 17:10:11 +0100 | <xilo> | hi, could someone take a look at this trivial error massage? I guess a simple import should solve it https://paste.tomsmeding.com/MSOSJmEI |
| 2022-11-14 17:11:05 +0100 | <geekosaur> | an import won't help here |
| 2022-11-14 17:11:18 +0100 | <Rembane> | xilo: You have redefined `Nothing` in your module `Tree.hs` at line 3. If you don't want to use Maybe you can go `import Prelude hiding (Nothing)` |
| 2022-11-14 17:11:26 +0100 | ystael | (~ystael@user/ystael) (Quit: Lost terminal) |
| 2022-11-14 17:11:47 +0100 | <geekosaur> | but better would be to use some other name |
| 2022-11-14 17:12:32 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-11-14 17:12:37 +0100 | <xilo> | ok cool, ty geekosaur |
| 2022-11-14 17:13:42 +0100 | kenran` | (~user@user/kenran) (Remote host closed the connection) |
| 2022-11-14 17:21:04 +0100 | machinedgod | (~machinedg@clnet-p10-126.ikbnet.co.at) (Ping timeout: 268 seconds) |
| 2022-11-14 17:23:32 +0100 | sh1n | (~sh1n@186.152.126.112) |
| 2022-11-14 17:23:59 +0100 | freeside | (~mengwong@122.11.214.147) (Ping timeout: 260 seconds) |
| 2022-11-14 17:27:08 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 260 seconds) |
| 2022-11-14 17:28:41 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:9b29:5558:d4cc:17cc) (Quit: WeeChat 2.8) |
| 2022-11-14 17:32:47 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 268 seconds) |
| 2022-11-14 17:36:24 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-14 17:36:27 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 260 seconds) |
| 2022-11-14 17:37:21 +0100 | janus | (janus@anubis.0x90.dk) |
| 2022-11-14 17:37:24 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2022-11-14 17:38:44 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Remote host closed the connection) |
| 2022-11-14 17:39:25 +0100 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2022-11-14 17:39:46 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 17:39:57 +0100 | califax | (~califax@user/califx) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-14 17:39:59 +0100 | ystael | (~ystael@user/ystael) |
| 2022-11-14 17:41:15 +0100 | califax | (~califax@user/califx) |
| 2022-11-14 17:45:42 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2022-11-14 17:55:41 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2022-11-14 17:55:52 +0100 | califax_ | (~califax@user/califx) |
| 2022-11-14 17:57:05 +0100 | califax_ | califax |
| 2022-11-14 17:58:11 +0100 | razetime | (~quassel@117.254.35.246) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-11-14 18:09:50 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 240 seconds) |
| 2022-11-14 18:10:17 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-14 18:10:45 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 18:14:43 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 268 seconds) |
| 2022-11-14 18:15:21 +0100 | MajorBiscuit | (~MajorBisc@145.94.173.65) (Ping timeout: 268 seconds) |
| 2022-11-14 18:15:56 +0100 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Ping timeout: 255 seconds) |
| 2022-11-14 18:17:45 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2022-11-14 18:18:25 +0100 | cafkafk | (~cafkafk@fsf/member/cafkafk) |
| 2022-11-14 18:20:41 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-14 18:21:47 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-11-14 18:21:49 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-14 18:21:56 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-14 18:23:19 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) (Quit: Konversation terminated!) |
| 2022-11-14 18:27:19 +0100 | CiaoSen | (~Jura@p200300c9571247002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-11-14 18:30:51 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-14 18:35:09 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-11-14 18:36:36 +0100 | iqubic | (~iqubic@2601:602:9502:c70:76bd:8eff:1f39:3cbe) (Quit: Client closed) |
| 2022-11-14 18:36:51 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 18:38:11 +0100 | mbuf | (~Shakthi@49.204.121.98) (Quit: Leaving) |
| 2022-11-14 18:40:42 +0100 | euandreh | (~Thunderbi@179.214.113.107) |
| 2022-11-14 18:40:58 +0100 | zmt01 | (~zmt00@user/zmt00) (Quit: Leaving) |
| 2022-11-14 18:42:44 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-14 18:43:10 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Remote host closed the connection) |
| 2022-11-14 18:43:57 +0100 | euandreh | (~Thunderbi@179.214.113.107) |
| 2022-11-14 18:46:23 +0100 | jinsun | (~jinsun@user/jinsun) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-14 18:46:25 +0100 | zmt00 | (~zmt00@user/zmt00) |
| 2022-11-14 18:48:49 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-11-14 18:54:12 +0100 | econo | (uid147250@user/econo) |
| 2022-11-14 18:57:03 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2022-11-14 19:00:40 +0100 | <EvanR> | well if I thought I knew vaguely what a random variable is supposed to be, now there's this analogy |
| 2022-11-14 19:00:44 +0100 | <EvanR> | https://i.imgur.com/OKc9PHq.png |
| 2022-11-14 19:01:16 +0100 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq) |
| 2022-11-14 19:01:23 +0100 | <EvanR> | and to explain what Reader is to a mathematician apparently you tell them it's basically a random variable |
| 2022-11-14 19:01:35 +0100 | nschoe | (~q@141.101.51.197) (Ping timeout: 268 seconds) |
| 2022-11-14 19:02:16 +0100 | <geekosaur> | mathematician, or statistician? |
| 2022-11-14 19:03:06 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-11-14 19:03:52 +0100 | <dolio> | What article is that from? |
| 2022-11-14 19:05:01 +0100 | <EvanR> | https://ncatlab.org/nlab/show/random+variable |
| 2022-11-14 19:05:32 +0100 | <dolio> | Well, then, it hardly seems fair to say that you need to explain reader as random variables because the article specifically on random variables only mentions that connection. |
| 2022-11-14 19:06:29 +0100 | <EvanR> | well, you don't need to |
| 2022-11-14 19:07:06 +0100 | <EvanR> | unrelated, how the hell is a random variable a reader monad |
| 2022-11-14 19:08:19 +0100 | <sclv> | yeah that's unfortunate. there's a much better mathematical way to explain the reader monad |
| 2022-11-14 19:08:36 +0100 | <sclv> | first we assume familiarity with fibered topoi |
| 2022-11-14 19:08:54 +0100 | <EvanR> | lol |
| 2022-11-14 19:09:23 +0100 | <dolio> | The obvious category thing to talk about is 'generalized elements', which you might talk of in all kinds of contexts. |
| 2022-11-14 19:10:01 +0100 | <dolio> | It's slightly different, I suppose, because it's an internal hom, but otherwise very similar. |
| 2022-11-14 19:10:01 +0100 | <EvanR> | a random variable is a generalized element? or |
| 2022-11-14 19:11:02 +0100 | <ozkutuk[m]> | Is there a way to express that two benchmarks are alternative implementations of the concept in Criterion? I am looking to compare the two approaches |
| 2022-11-14 19:11:06 +0100 | <davean> | EvanR: Its a random variable, because the users of your library are the average programmer, and the average programmer is a monkey at a type writer, so random typing on a keyboard sets the reader's content - there is your random variable! |
| 2022-11-14 19:11:49 +0100 | <dolio> | A generalized element of `B` is a map `A -> B`. The reader monad is like a monad for generalized elements with a specific domain. |
| 2022-11-14 19:12:08 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-11-14 19:13:14 +0100 | <dolio> | Turning a global element into a generalized element is the unit, and turning a generalized element of generalized elements into a generalized element is the multiplication. |
| 2022-11-14 19:15:27 +0100 | <EvanR> | does that multiplication have anything to do with randomness |
| 2022-11-14 19:17:07 +0100 | <dolio> | If you have a random variable of random variables, you can get a random variable from it. |
| 2022-11-14 19:17:46 +0100 | <ozkutuk[m]> | Okay I have found this issue, so apparently not https://github.com/haskell/criterion/issues/151 |
| 2022-11-14 19:19:28 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 19:19:39 +0100 | <EvanR> | composition of random variables, makes sense. Maybe this is really talking about a generalization of reader |
| 2022-11-14 19:19:55 +0100 | <dolio> | It's not super clear that reader is the right thing. |
| 2022-11-14 19:20:13 +0100 | <dolio> | But I don't know random variables that well. |
| 2022-11-14 19:22:29 +0100 | <dolio> | Like, if you're using `2 ->`, and you have one random variable that picks between red and green, and another that picks from blue and orange, then using reader to join the variable that randomly picks one of those variables is going to lack some colors. |
| 2022-11-14 19:22:41 +0100 | <dolio> | I guess it's still a random variable, though. Just maybe not the one you want. |
| 2022-11-14 19:22:42 +0100 | <sclv> | i mean there's a good probability monad with a sound basis but its... just not the reader monad |
| 2022-11-14 19:22:51 +0100 | Cale | (~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com) (Remote host closed the connection) |
| 2022-11-14 19:24:30 +0100 | <dolio> | There's another, related monad, which is `Σ[ A ∈ Type ] (A -> B)`. The unit uses A = (), and the join takes the product of the domains. That might be more along the lines of what you want. |
| 2022-11-14 19:27:18 +0100 | <EvanR> | rather than red green, blue orange, if you had X1 and X2 on the same domain, then Y = 50% X1, 50% X2... you could smush Y to get Z without wondering where any colors went |
| 2022-11-14 19:27:57 +0100 | <EvanR> | but yeah that's not what I though Reader was about |
| 2022-11-14 19:28:43 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 2022-11-14 19:31:06 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 19:31:48 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 268 seconds) |
| 2022-11-14 19:35:55 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-14 19:39:12 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2022-11-14 19:41:56 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-14 19:42:34 +0100 | <dminuoso> | Is there a memcpy variant that does not use FFI in base? |
| 2022-11-14 19:43:25 +0100 | <davean> | In *base*? That seems a very strict requirement |
| 2022-11-14 19:43:31 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 256 seconds) |
| 2022-11-14 19:43:43 +0100 | <dminuoso> | Well, or anything that GHC comes with is fine too |
| 2022-11-14 19:44:14 +0100 | <davean> | There are things like copyArray# which aren't QUITE what you want probably. |
| 2022-11-14 19:44:26 +0100 | <dminuoso> | Yeah Ive seen that too |
| 2022-11-14 19:44:36 +0100 | <davean> | I prefer to use packages |
| 2022-11-14 19:44:54 +0100 | <davean> | it wouldn't be appropriate for base to have memcpy really. |
| 2022-11-14 19:44:54 +0100 | <dminuoso> | Well, Im not going to depend on a package for the sole purpose of copying a small byte buffer. That's a bit extreme |
| 2022-11-14 19:45:01 +0100 | <dminuoso> | It does |
| 2022-11-14 19:45:09 +0100 | <dminuoso> | https://hackage.haskell.org/package/base-4.17.0.0/docs/Foreign-Marshal-Utils.html#v:copyBytes |
| 2022-11-14 19:45:18 +0100 | <dminuoso> | Which is just a memcpy binding |
| 2022-11-14 19:45:19 +0100 | <davean> | yes, for that purpose |
| 2022-11-14 19:45:33 +0100 | <davean> | I meant a more generalized haskell-ish oen |
| 2022-11-14 19:46:16 +0100 | <dminuoso> | I mean I can just cook up my own small writeWord64OffAddr# + writeWord8OffAddr# look |
| 2022-11-14 19:46:22 +0100 | <dminuoso> | s/look/loop\ |
| 2022-11-14 19:46:54 +0100 | <dminuoso> | In my use case, it will never exceed 255 bytes, and in most cases will likely be around 10-20 bytes |
| 2022-11-14 19:47:03 +0100 | <dminuoso> | memcpy is a bit over the top for that |
| 2022-11-14 19:47:03 +0100 | <EvanR> | copyArray in Foreign.Marshall.Array doesn't seen to use FFI directly, but primitives |
| 2022-11-14 19:47:15 +0100 | <dminuoso> | EvanR: Of course it does. |
| 2022-11-14 19:47:21 +0100 | <dminuoso> | copyBytes dest src size = do _ <- memcpy dest src (fromIntegral size) return () |
| 2022-11-14 19:47:25 +0100 | <dminuoso> | foreign import ccall unsafe "string.h" memcpy :: Ptr a -> Ptr a -> CSize -> IO (Ptr a) |
| 2022-11-14 19:47:42 +0100 | <dminuoso> | Oh wait, there'sd another copyArray? |
| 2022-11-14 19:47:45 +0100 | <EvanR> | copy... Array in Foreign.Marshall.Array? |
| 2022-11-14 19:47:59 +0100 | <dminuoso> | copyArray dest src size = copyBytes dest src (size * sizeOf (undefined :: a)) |
| 2022-11-14 19:48:06 +0100 | <dminuoso> | So that's just a copyBytes wrapper |
| 2022-11-14 19:48:12 +0100 | <dminuoso> | Which in turn uses memcpy |
| 2022-11-14 19:48:33 +0100 | <EvanR> | so what was I just looking at, ffs |
| 2022-11-14 19:48:33 +0100 | <davean> | primitive's copyPtr also binds copyBytes |
| 2022-11-14 19:48:36 +0100 | <dminuoso> | It's somewhat annoying that ghc-prim doesnt provide IO primop wrappers. :( |
| 2022-11-14 19:48:38 +0100 | <EvanR> | nevermind me |
| 2022-11-14 19:48:59 +0100 | <dminuoso> | I guess Ill just cook up the loop by hand then |
| 2022-11-14 19:49:11 +0100 | srz | (~srz@devil.dm.uba.ar) |
| 2022-11-14 19:49:13 +0100 | <davean> | dminuoso: why do you not mish to use copyBytes? |
| 2022-11-14 19:49:20 +0100 | <davean> | Your requirements seem very unclear |
| 2022-11-14 19:49:28 +0100 | <davean> | well, the reasons for them |
| 2022-11-14 19:49:42 +0100 | <dminuoso> | davean: because for 10-20 bytes on average the ffi overhead is going to be more costly |
| 2022-11-14 19:49:51 +0100 | <EvanR> | when the memory is not foreign it's seems a bit annoying to have to use ffi |
| 2022-11-14 19:49:53 +0100 | <dminuoso> | even if its unsafe, there's still a priceq to pay |
| 2022-11-14 19:50:16 +0100 | <geekosaur> | ffi overhead should be ~0 for unsafe |
| 2022-11-14 19:50:25 +0100 | nek0 | (~nek0@2a01:4f8:222:2b41::12) (Quit: The Lounge - https://thelounge.chat) |
| 2022-11-14 19:50:32 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-11-14 19:50:51 +0100 | <dminuoso> | Mmm, I was sure I was told otherwise |
| 2022-11-14 19:50:52 +0100 | <davean> | Interestingly FFI can sometimes be faster than primops |
| 2022-11-14 19:51:39 +0100 | <geekosaur> | last I checked an unsafe ffi just compiled as a direct call from the code, with the only overhead being the call itself |
| 2022-11-14 19:51:55 +0100 | <geekosaur> | primops still make calls since they call into cmm |
| 2022-11-14 19:52:24 +0100 | <geekosaur> | so you'd only win if it were a compiler primitive that generated the copy code in place |
| 2022-11-14 19:52:44 +0100 | <davean> | dminuoso: Honestly, most Haskellers don't understand GHC performance |
| 2022-11-14 19:52:54 +0100 | <davean> | test what you read. |
| 2022-11-14 19:52:57 +0100 | <EvanR> | that's actually a pretty helpful explanation of unsafe, if that's what it does |
| 2022-11-14 19:54:17 +0100 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Ping timeout: 256 seconds) |
| 2022-11-14 19:55:02 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-14 19:55:13 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 19:55:47 +0100 | LemanR | (~LemanR@pool-74-109-28-147.phlapa.fios.verizon.net) |
| 2022-11-14 19:57:03 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-14 19:58:19 +0100 | youziqi | (~youziqi@103.37.140.121) (Ping timeout: 268 seconds) |
| 2022-11-14 19:58:20 +0100 | califax | (~califax@user/califx) |
| 2022-11-14 19:59:21 +0100 | lyle | (~lyle@104.246.145.85) (Quit: WeeChat 3.7.1) |
| 2022-11-14 19:59:52 +0100 | youziqi | (~youziqi@103.37.140.125) |
| 2022-11-14 20:01:05 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 2022-11-14 20:02:09 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 2022-11-14 20:03:47 +0100 | nek0 | (~nek0@2a01:4f8:222:2b41::12) |
| 2022-11-14 20:04:53 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-14 20:06:30 +0100 | lechner | (~lechner@debian/lechner) (Remote host closed the connection) |
| 2022-11-14 20:06:30 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) (Read error: Connection reset by peer) |
| 2022-11-14 20:07:02 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-11-14 20:07:54 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 2022-11-14 20:10:32 +0100 | <EvanR> | T minus half 15 days ish until advent of code |
| 2022-11-14 20:10:41 +0100 | <EvanR> | half a month |
| 2022-11-14 20:11:07 +0100 | <EvanR> | get your editor macros and DSLs ready |
| 2022-11-14 20:11:11 +0100 | Cale | (~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com) |
| 2022-11-14 20:12:35 +0100 | lechner | (~lechner@debian/lechner) |
| 2022-11-14 20:13:43 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2022-11-14 20:14:41 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-14 20:19:34 +0100 | <LemanR> | (I asked on xmonad but figured this fits haskell question as well) can someone suggest o resource about reading haskell documentation? atm trying to read https://hackage.haskell.org/package/xmonad-contrib-0.17.1/docs/XMonad-Actions-TagWindows.html but am new to haskell. |
| 2022-11-14 20:20:50 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 20:28:32 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 2022-11-14 20:28:36 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-14 20:29:31 +0100 | motherfsck | (~motherfsc@user/motherfsck) |
| 2022-11-14 20:34:29 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-11-14 20:36:20 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Remote host closed the connection) |
| 2022-11-14 20:37:45 +0100 | LemanR | (~LemanR@pool-74-109-28-147.phlapa.fios.verizon.net) (Quit: Client closed) |
| 2022-11-14 20:37:59 +0100 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:1d0b:eb23:aba0:7ca3) |
| 2022-11-14 20:39:01 +0100 | <sm> | oh god AoC already |
| 2022-11-14 20:40:32 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-11-14 20:41:03 +0100 | <sm> | LemanR: a doc for reading haskell docs ? That kind of doc you're reading is generated by haddock - which has its own in depth user guide - but what's giving trouble ? |
| 2022-11-14 20:41:33 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) |
| 2022-11-14 20:43:58 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 2022-11-14 20:44:38 +0100 | LemanR | (~LemanR@pool-74-109-28-147.phlapa.fios.verizon.net) |
| 2022-11-14 20:45:56 +0100 | wrengr | (~wrengr@201.59.83.34.bc.googleusercontent.com) |
| 2022-11-14 20:47:50 +0100 | mcglk | (~mcglk@131.191.49.120) (Read error: Connection reset by peer) |
| 2022-11-14 20:48:02 +0100 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Ping timeout: 255 seconds) |
| 2022-11-14 20:49:37 +0100 | coot | (~coot@213.134.171.3) |
| 2022-11-14 20:50:07 +0100 | mmhat | (~mmh@p50857d40.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-11-14 20:53:13 +0100 | marinelli | (~marinelli@gateway/tor-sasl/marinelli) (Quit: marinelli) |
| 2022-11-14 20:59:16 +0100 | <LemanR> | I found https://hackage.haskell.org/package/xmonad-contrib-0.17.1/docs/XMonad-Doc-Developing.html so I should be in good hands |
| 2022-11-14 20:59:54 +0100 | <LemanR> | will need time to do a long format video on haskell. |
| 2022-11-14 21:00:27 +0100 | <geekosaur> | if you run across things you think should be mentioned in there, feel free to file an issue; we're currently reworking the docs, some of which haven't been touched in 15 years |
| 2022-11-14 21:01:17 +0100 | DDR | (~DDR@2604:3d08:4c7f:8250:7335:db3e:c155:4272) |
| 2022-11-14 21:01:45 +0100 | <geekosaur> | I have sensory processing issues that keep me from doing much with videos in particular, so I can't help much there |
| 2022-11-14 21:03:19 +0100 | mmhat | (~mmh@p200300f1c71c15a1ee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-11-14 21:05:03 +0100 | <EvanR> | haddocks contain too much information, we need videos to dilute the information in space and time |
| 2022-11-14 21:07:34 +0100 | gmg | (~user@user/gehmehgeh) |
| 2022-11-14 21:09:14 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-11-14 21:10:22 +0100 | LemanR | (~LemanR@pool-74-109-28-147.phlapa.fios.verizon.net) (Quit: Client closed) |
| 2022-11-14 21:18:40 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-14 21:20:47 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) |
| 2022-11-14 21:20:48 +0100 | <sm> | tooling that helps produce more complete docs could help a lot. Assistance/guidance/best practices for api docs, readme, cabal synopses, changelogs & release notes, hackage presentation, hoogle, errors database, announcements.. all simplified and under one roof |
| 2022-11-14 21:21:28 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-14 21:21:59 +0100 | merijn | (~merijn@86.86.29.250) |
| 2022-11-14 21:22:47 +0100 | mmhat | (~mmh@p200300f1c71c15a1ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-11-14 21:25:29 +0100 | CiaoSen | (~Jura@p200300c9571247002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-11-14 21:26:30 +0100 | merijn | (~merijn@86.86.29.250) (Ping timeout: 240 seconds) |
| 2022-11-14 21:29:45 +0100 | nschoe | (~q@2a01:e0a:8e:a190:ed71:b953:4bd7:bd1) |
| 2022-11-14 21:32:30 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 240 seconds) |
| 2022-11-14 21:36:05 +0100 | mmhat | (~mmh@p200300f1c71c150dee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-11-14 21:38:24 +0100 | pavonia | (~user@user/siracusa) |
| 2022-11-14 21:44:45 +0100 | Guest75 | (~Guest75@178.141.177.81) |
| 2022-11-14 21:46:43 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-11-14 21:47:56 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-11-14 21:49:24 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-11-14 21:49:31 +0100 | kenaryn | (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) |
| 2022-11-14 21:52:43 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-11-14 21:55:25 +0100 | c0c0 | (~coco@85.195.206.136) (Quit: WeeChat 3.5) |
| 2022-11-14 21:58:25 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Remote host closed the connection) |
| 2022-11-14 22:00:36 +0100 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2022-11-14 22:03:14 +0100 | James24 | (~James27@pop.92-184-124-93.mobile.abo.orange.fr) |
| 2022-11-14 22:03:43 +0100 | aliosablack | (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) |
| 2022-11-14 22:03:50 +0100 | chomwitt | (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) (Read error: Connection reset by peer) |
| 2022-11-14 22:04:47 +0100 | nschoe | (~q@2a01:e0a:8e:a190:ed71:b953:4bd7:bd1) (Ping timeout: 260 seconds) |
| 2022-11-14 22:05:26 +0100 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-11-14 22:05:54 +0100 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) |
| 2022-11-14 22:16:27 +0100 | gqplox | (~textual@97e5fa6a.skybroadband.com) |
| 2022-11-14 22:22:41 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-11-14 22:31:06 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Read error: Connection reset by peer) |
| 2022-11-14 22:31:18 +0100 | euandreh2 | (~Thunderbi@179.214.113.107) |
| 2022-11-14 22:31:45 +0100 | James24 | (~James27@pop.92-184-124-93.mobile.abo.orange.fr) (Quit: Leaving) |
| 2022-11-14 22:33:39 +0100 | euandreh2 | euandreh |
| 2022-11-14 22:35:23 +0100 | gqplox | (~textual@97e5fa6a.skybroadband.com) (Quit: Textual IRC Client: www.textualapp.com) |
| 2022-11-14 22:47:07 +0100 | srz | (~srz@devil.dm.uba.ar) (Ping timeout: 256 seconds) |
| 2022-11-14 22:49:45 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-14 22:55:18 +0100 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-11-14 22:55:30 +0100 | nibelungen | (~asturias@2001:19f0:7001:638:5400:3ff:fef3:8725) (Ping timeout: 240 seconds) |
| 2022-11-14 22:56:34 +0100 | nibelungen | (~asturias@2001:19f0:7001:638:5400:3ff:fef3:8725) |
| 2022-11-14 22:57:02 +0100 | machinedgod | (~machinedg@clnet-b05-118.ikbnet.co.at) |
| 2022-11-14 22:57:07 +0100 | slac13810 | (~slack1256@191.125.227.75) |
| 2022-11-14 22:58:54 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 2022-11-14 22:59:35 +0100 | slack1256 | (~slack1256@191.125.99.74) (Ping timeout: 256 seconds) |
| 2022-11-14 23:03:10 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 240 seconds) |
| 2022-11-14 23:04:43 +0100 | TonyStone31 | (~TonyStone@cpe-74-76-57-186.nycap.res.rr.com) |
| 2022-11-14 23:05:37 +0100 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) |
| 2022-11-14 23:05:49 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 260 seconds) |
| 2022-11-14 23:07:47 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-11-14 23:11:46 +0100 | slack1256 | (~slack1256@191.126.227.73) |
| 2022-11-14 23:13:59 +0100 | slac13810 | (~slack1256@191.125.227.75) (Ping timeout: 260 seconds) |
| 2022-11-14 23:14:47 +0100 | <johnw> | if there are aeson experts here, I have strinfied json within json objects. Reading it out is causing `jstring` from aeson to blow out my profiles. Are there any known ways to improve this situation? |
| 2022-11-14 23:17:50 +0100 | <dminuoso> | What does "blow out" mean? |
| 2022-11-14 23:18:03 +0100 | <dminuoso> | And what is a 'jstring'? |
| 2022-11-14 23:18:21 +0100 | <dminuoso> | Oh, `jstring :: Parser Text` I see. |
| 2022-11-14 23:22:40 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 23:22:44 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-14 23:23:31 +0100 | <dminuoso> | johnw: Curious though, what do you mean by blowing out profiles? |
| 2022-11-14 23:24:54 +0100 | <johnw> | like, very simple examples moving >1 GB through the allocator (not heap, though), where jstring is at the top of my profile results |
| 2022-11-14 23:25:14 +0100 | <johnw> | I'm expecting memory use to be ~19 MB tops |
| 2022-11-14 23:25:27 +0100 | slac26443 | (~slack1256@191.126.99.192) |
| 2022-11-14 23:25:33 +0100 | machinedgod | (~machinedg@clnet-b05-118.ikbnet.co.at) (Read error: Connection reset by peer) |
| 2022-11-14 23:25:40 +0100 | machined1od | (~machinedg@clnet-b05-118.ikbnet.co.at) |
| 2022-11-14 23:26:32 +0100 | <geekosaur> | there's a big difference between allocator and actual heap usage |
| 2022-11-14 23:26:46 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-14 23:26:46 +0100 | <johnw> | oh I know |
| 2022-11-14 23:26:58 +0100 | <johnw> | but in general, high allocator activity usually means lots of wasted CPU time |
| 2022-11-14 23:26:59 +0100 | <geekosaur> | if it's not actually using that much heap then I wouldn't worry: the nursery is very fast at both allocation and GC |
| 2022-11-14 23:27:19 +0100 | <Guest75> | Having a type: data T1 = V1 | V2 Integer | V3 String | V4 String T1 can one easily get sth equivalent to {"T1": [{"constructor": "V1"}, {"constructor": "V2", "params": ["Integer"]}, {"constructor": "V3", "params": ["String"]}, {"constructor": "V4", "params": ["T1", "String"]}}? Will DeriveGeneric solve the trick? |
| 2022-11-14 23:27:19 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Read error: Connection reset by peer) |
| 2022-11-14 23:27:21 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 2022-11-14 23:27:28 +0100 | <geekosaur> | well, it means for example there's no streaming optimization |
| 2022-11-14 23:27:37 +0100 | <geekosaur> | sometimes you just can't get that |
| 2022-11-14 23:27:42 +0100 | <dminuoso> | Guest75: Just write out the instance by hand. |
| 2022-11-14 23:27:59 +0100 | slack1256 | (~slack1256@191.126.227.73) (Ping timeout: 268 seconds) |
| 2022-11-14 23:28:09 +0100 | <johnw> | well, it's not just high in the profile by allocation, but also by CPU |
| 2022-11-14 23:28:22 +0100 | <dminuoso> | johnw: Mmm, can you share the simplified core output? |
| 2022-11-14 23:28:33 +0100 | <geekosaur> | aeson is not known to be the most optimal JSON parser |
| 2022-11-14 23:28:41 +0100 | <johnw> | for which part? this is happening under several layers of aeson |
| 2022-11-14 23:28:42 +0100 | <Guest75> | dminuoso: well, my actual "desired" type is bigger:-) https://github.com/andrewboltachev/pyparts/blob/master/src/Lib.hs#L68 |
| 2022-11-14 23:28:43 +0100 | <geekosaur> | in fact iirc it's pretty slow and wasteful |
| 2022-11-14 23:28:53 +0100 | <geekosaur> | you might also play with e.g. waargonaut |
| 2022-11-14 23:29:10 +0100 | dminuoso | would rather just handroll a flatparse-based JSON parser |
| 2022-11-14 23:29:16 +0100 | <Guest75> | geekosaur: is Aeson the most fancy one? |
| 2022-11-14 23:29:24 +0100 | <dminuoso> | aeson has the fanciest dependency tree. |
| 2022-11-14 23:29:38 +0100 | <dminuoso> | once you have aeson, every second package on hackage is a transitive dependency. |
| 2022-11-14 23:29:49 +0100 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |
| 2022-11-14 23:30:04 +0100 | <johnw> | do I need the +cffi flag for aeson in my library cabal files, as well as my application cabal file? |
| 2022-11-14 23:30:14 +0100 | <geekosaur> | speaking of, Guest75, since that looked like JSON to me it's possible that aeson-schema has something for you? |
| 2022-11-14 23:30:54 +0100 | <Guest75> | geekosaur: yeah. as I beginner I missed a lot of existing stuff |
| 2022-11-14 23:31:36 +0100 | <Guest75> | most desired feature for me, 'cause of what I've built this is https://github.com/andrewboltachev/pyparts/blob/master/src/Lib.hs#L77 "funnel" feature |
| 2022-11-14 23:31:37 +0100 | <dminuoso> | johnw: You need it in your cabal.project only. |
| 2022-11-14 23:32:00 +0100 | <dminuoso> | johnw: cabal flags are not communicatable via dependencies, they are project-levels configurations |
| 2022-11-14 23:32:14 +0100 | <Guest75> | which allows to build schema: https://github.com/andrewboltachev/pyparts/blob/master/src/Lib.hs#L317 in short increments |
| 2022-11-14 23:32:18 +0100 | michalz | (~michalz@185.246.207.203) |
| 2022-11-14 23:32:56 +0100 | <dminuoso> | https://hackage.haskell.org/package/aeson-2.1.1.0/docs/src/Data.Aeson.Parser.UnescapePure.html#une… |
| 2022-11-14 23:32:59 +0100 | <dminuoso> | Wow that looks disgusting. :( |
| 2022-11-14 23:33:13 +0100 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |
| 2022-11-14 23:33:25 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2022-11-14 23:33:25 +0100 | <johnw> | thanks |
| 2022-11-14 23:33:27 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-11-14 23:33:30 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-14 23:33:40 +0100 | <Guest75> | is that code so complex because it's optimized somehow? |
| 2022-11-14 23:33:44 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) |
| 2022-11-14 23:34:16 +0100 | <dminuoso> | Nah, that's mostly just the price for UTF8 encoding. |
| 2022-11-14 23:34:41 +0100 | <Guest75> | ah yes... OverloadedStrings, T.pack, TL.unpack, BLU.fromString etc |
| 2022-11-14 23:36:21 +0100 | <Guest75> | that's like a state machine there... |
| 2022-11-14 23:36:58 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-11-14 23:36:59 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-11-14 23:37:51 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 268 seconds) |
| 2022-11-14 23:38:07 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 2022-11-14 23:53:53 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 255 seconds) |
| 2022-11-14 23:55:51 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-11-14 23:59:08 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 260 seconds) |
