| 2023-08-21 00:04:39 +0200 | jero98772 | (~jero98772@2800:484:1d84:300::2) |
| 2023-08-21 00:05:42 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 246 seconds) |
| 2023-08-21 00:07:30 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-08-21 00:07:47 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-21 00:08:15 +0200 | dibblego | (~dibblego@116-255-1-151.ip4.superloop.au) |
| 2023-08-21 00:08:15 +0200 | dibblego | (~dibblego@116-255-1-151.ip4.superloop.au) (Changing host) |
| 2023-08-21 00:08:15 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-08-21 00:08:20 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2023-08-21 00:09:11 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-21 00:09:11 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2023-08-21 00:11:37 +0200 | jero98772 | (~jero98772@2800:484:1d84:300::2) (Ping timeout: 260 seconds) |
| 2023-08-21 00:12:47 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 260 seconds) |
| 2023-08-21 00:14:53 +0200 | caryhartline | (~caryhartl@168.182.58.169) |
| 2023-08-21 00:19:10 +0200 | mikoto-chan | (~mikoto-ch@85-76-46-81-nat.elisa-mobile.fi) |
| 2023-08-21 00:25:35 +0200 | mvk | (~mvk@2607:fea8:5c9a:a600::1c6d) |
| 2023-08-21 00:26:26 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-08-21 00:29:08 +0200 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2023-08-21 00:32:47 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-08-21 00:46:20 +0200 | mikoto-chan | (~mikoto-ch@85-76-46-81-nat.elisa-mobile.fi) (Ping timeout: 245 seconds) |
| 2023-08-21 00:49:20 +0200 | <wroathe> | Hey guys, so I've got a memory profile of my program that shows that lots of Text and ARR_WORDS are being allocated by my program. I think I know where this is happening, but what tools can I use to very clearly see the new allocation being made with my own two eyes? |
| 2023-08-21 00:49:47 +0200 | <wroathe> | I'm calling `drop` from Data.Text, and from what I can see in the text library code it looks like it creates a new Text object |
| 2023-08-21 00:50:05 +0200 | <wroathe> | What I'm wondering is if this strict annotation here: https://github.com/haskell/text/blob/master/src/Data/Text/Internal.hs#L66 means that it copies the inner array each time it does so? |
| 2023-08-21 00:50:24 +0200 | hsxtrt | (~hsxtrt@14-200-253-168.static.tpgi.com.au) |
| 2023-08-21 00:50:32 +0200 | <wroathe> | Here's where a new Text is created: https://github.com/haskell/text/blob/master/src/Data/Text.hs#L1450 |
| 2023-08-21 00:51:16 +0200 | <wroathe> | Is there a compilation stage I can look at that would show me that calling drop is copying this array? |
| 2023-08-21 00:51:21 +0200 | anselmschueler | (~anselmsch@user/schuelermine) (Quit: WeeChat 4.0.3) |
| 2023-08-21 00:51:52 +0200 | <mauke> | to me that looks like it creates a new wrapper object (of type Text), but does not copy the underlying array |
| 2023-08-21 00:52:16 +0200 | <wroathe> | Ah. I was wondering if the ! would change that behavior |
| 2023-08-21 00:52:28 +0200 | <geekosaur> | nope, it requires more than that |
| 2023-08-21 00:53:54 +0200 | <wroathe> | Hmm, this is the section of code I'm trying to figure out the problem with: https://gist.github.com/JustinChristensen/1a260e17984f0daae853fc5d56ab08f5 |
| 2023-08-21 00:54:13 +0200 | <wroathe> | From earlier this morning. The profile says that this advanceTo routine is responsible for 33% of my program's allocations |
| 2023-08-21 00:54:46 +0200 | <wroathe> | The idea there is with megaparsec I'm trying to advance the input and offset to a TSV field boundary (and hoping to do that without any extra allocations) |
| 2023-08-21 00:55:17 +0200 | <wroathe> | Sorry, 37% |
| 2023-08-21 00:56:55 +0200 | jargon | (~jargon@174-22-213-62.phnx.qwest.net) |
| 2023-08-21 00:57:28 +0200 | <EvanR> | so how does findIndex work |
| 2023-08-21 00:58:35 +0200 | <EvanR> | i'll be interested to see how you do that without allocations |
| 2023-08-21 00:59:20 +0200 | <wroathe> | https://github.com/haskell/text/blob/9fc523cef77f02c465afe00a2f4ac67c388f9945/src/Data/Text.hs#L19… |
| 2023-08-21 00:59:37 +0200 | <EvanR> | ah it's from Data.Text |
| 2023-08-21 01:00:19 +0200 | <wroathe> | EvanR: Yeah, I don't truly mean zero allocation. I'm just trying to approximate how easy it woudl be to do something like this with an array in C to this context |
| 2023-08-21 01:00:23 +0200 | hsxtrt | (~hsxtrt@14-200-253-168.static.tpgi.com.au) (Quit: This computer has gone to sleep) |
| 2023-08-21 01:00:55 +0200 | <wroathe> | The -hd profile I just ran shows Text and ARR_WORDS is the largest portion of allocation occuring |
| 2023-08-21 01:01:33 +0200 | <EvanR> | the Data.Text implementation code uses a stream framework which is subject to optimizations, like fusion |
| 2023-08-21 01:01:59 +0200 | Guest|7 | (~Guest|7@cpe-184-54-115-255.swo.res.rr.com) |
| 2023-08-21 01:02:08 +0200 | <EvanR> | you said you were reading 8MB file, so there's that |
| 2023-08-21 01:02:47 +0200 | <wroathe> | Yup |
| 2023-08-21 01:03:02 +0200 | <wroathe> | I'm trying to figure out how to get a screenshot of this report. One sec. |
| 2023-08-21 01:03:25 +0200 | <EvanR> | is it lazy I/O or fully loaded before parsing |
| 2023-08-21 01:03:34 +0200 | <Guest|7> | Hello! I'm trying to install GHCi on Artix linux. I saw the section about setting a platform-override for ghcup, but I can't find what the config overrides would be for Arch. Would anyone be able to tell me what command I should use? |
| 2023-08-21 01:04:08 +0200 | <wroathe> | EvanR: I'm just using Data.Text.IO readFile |
| 2023-08-21 01:04:09 +0200 | <EvanR> | if it's lazy I/O it's not surprising to see alot of allocating in the process of seeking forward |
| 2023-08-21 01:05:05 +0200 | <shapr> | there's a lot to learn in the world |
| 2023-08-21 01:05:39 +0200 | <shapr> | Guest|7: What's different about artix linux? What's a platform override? |
| 2023-08-21 01:07:18 +0200 | <Guest|7> | The issue is that when running `ghcup install ghci`, ghcup throws an error about 'undetected distro'. Arch and Artix are pretty similar, Artix just has more options for init systems. I got the platform override from here: https://www.haskell.org/ghcup/guide/#overriding-distro-detection |
| 2023-08-21 01:07:44 +0200 | <Guest|7> | But it only lists an example for Void and Ubuntu |
| 2023-08-21 01:09:35 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-08-21 01:10:10 +0200 | <EvanR> | wroathe, according to readFile (hGetContents) for Data.Text.IO, it will read chunks until none are left to read, concat them all and return them. So that's a lot of allocating, but should happen upfront at the beginning |
| 2023-08-21 01:11:07 +0200 | <sclv> | Guest|7: you can find a list of the platforms in the ghcup distro metadata yaml i think https://github.com/haskell/ghcup-metadata/blob/c88802ea8cf25a4e16227679dd89e8843ad7f759/ghcup-0.0.… |
| 2023-08-21 01:11:55 +0200 | <Guest|7> | Oh I see, thanks. I was just looking in the wrong place |
| 2023-08-21 01:12:05 +0200 | <wroathe> | EvanR: https://i.imgur.com/aETjZ8g.png |
| 2023-08-21 01:12:22 +0200 | <wroathe> | The amount of technical difficulty I had getting that screenshot on desktop linux makes me feel old :D |
| 2023-08-21 01:12:41 +0200 | <EvanR> | print screen works on default ubuntu right now |
| 2023-08-21 01:12:50 +0200 | <wroathe> | Yeah I'm on Fedora, and relatively new to it |
| 2023-08-21 01:12:54 +0200 | <shapr> | ( flameshot is a really good screenshot tool on Linux, according to my recent research ) |
| 2023-08-21 01:12:55 +0200 | <wroathe> | I'm just getting used to grim/slurp |
| 2023-08-21 01:13:00 +0200 | <wroathe> | Using sway as my window manager |
| 2023-08-21 01:13:23 +0200 | <wroathe> | Yeah I just installed/used grimshot and it did what I needed |
| 2023-08-21 01:13:38 +0200 | <wroathe> | This is the result of running with -hd for my program: https://i.imgur.com/aETjZ8g.png |
| 2023-08-21 01:13:53 +0200 | <EvanR> | if you're expecting your program to be able to process everything in a fixed amount of memory, then your picture shows a space leak |
| 2023-08-21 01:14:17 +0200 | <wroathe> | Yeah, I gathered that much already |
| 2023-08-21 01:14:55 +0200 | <wroathe> | I don't think "fixed", but at the very least my goal is for something like advanceTo to not cost me 37% of my memory usage |
| 2023-08-21 01:14:57 +0200 | <EvanR> | I still wasn't sure if you were chasing something worth chasing xD |
| 2023-08-21 01:15:07 +0200 | <shapr> | Guest|7: did it work? |
| 2023-08-21 01:15:16 +0200 | <Guest|7> | not yet |
| 2023-08-21 01:15:45 +0200 | <wroathe> | Because again mentally I'm trying to implement "advance the pointer, subtract the difference to get the offset added, commit those to the parser state" |
| 2023-08-21 01:15:56 +0200 | <probie> | wroathe: do you get different results for memory usage when there's no lazy IO going on? |
| 2023-08-21 01:16:00 +0200 | <wroathe> | Which might not be possible with megaparsec, but I'm just seeing what options I've got |
| 2023-08-21 01:16:16 +0200 | <wroathe> | probie: How would I disable that? Which Data.Text routine are you thinking? |
| 2023-08-21 01:16:31 +0200 | <EvanR> | megaparsec does backtracking, so it might not be able to drop context it needs to possibly backtrack if there's a parse error some time before the end of the processing |
| 2023-08-21 01:17:03 +0200 | <wroathe> | EvanR: Well that's fine. In this mental model I'm describing there could be many parser states. As long as we're talking about pointers and not entirely new arrays the amount of overhead should be minimal |
| 2023-08-21 01:17:23 +0200 | <wroathe> | (sorry I know I'm trying to apply C understanding to an entirely different beast. try to bear with me) |
| 2023-08-21 01:17:41 +0200 | <EvanR> | your picture, it shows a fixed amount of ARR_WORDS |
| 2023-08-21 01:17:49 +0200 | <EvanR> | which is good |
| 2023-08-21 01:18:25 +0200 | <EvanR> | Text and the thing under ARR_WORDS is growing |
| 2023-08-21 01:18:35 +0200 | <EvanR> | along with a lot of other stuff |
| 2023-08-21 01:18:58 +0200 | <EvanR> | it looks like the ARR_WORDS grows to its max in the first 0.1 seconds, probably loading the file |
| 2023-08-21 01:19:30 +0200 | <probie> | wroathe: ignore me, for some reason I thought `Data.Text.readFile` was lazy, but it's not |
| 2023-08-21 01:19:39 +0200 | dolio | (~dolio@130.44.134.54) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-08-21 01:19:46 +0200 | <EvanR> | yeah |
| 2023-08-21 01:19:51 +0200 | <wroathe> | Here's the full program: https://gist.github.com/JustinChristensen/72e4eae8a8e6e4e4f9be09078770c504 |
| 2023-08-21 01:21:00 +0200 | dolio | (~dolio@130.44.134.54) |
| 2023-08-21 01:21:15 +0200 | jero98772 | (~jero98772@2800:484:1d84:300::2) |
| 2023-08-21 01:23:07 +0200 | shapr | (~user@2600:1700:c640:3100:5507:bbc0:d0c9:b395) (Remote host closed the connection) |
| 2023-08-21 01:23:21 +0200 | shapr | (~user@2600:1700:c640:3100:6898:ed8d:7f5e:e726) |
| 2023-08-21 01:23:41 +0200 | <EvanR> | on line 278 and 279 you're holding some strings (Text) while you recurse deeper into the parsing |
| 2023-08-21 01:23:52 +0200 | <EvanR> | finally it will all be linked into a list and returned |
| 2023-08-21 01:24:04 +0200 | mikoto-chan | (~mikoto-ch@85-76-46-81-nat.elisa-mobile.fi) |
| 2023-08-21 01:24:06 +0200 | <EvanR> | so it makes sense your Text constructors will steadily increase |
| 2023-08-21 01:24:20 +0200 | <wroathe> | Yeah I was wondering about that |
| 2023-08-21 01:24:31 +0200 | <wroathe> | But the confusing thing is that profiling is telling me that advanceTo is the problem |
| 2023-08-21 01:24:59 +0200 | <EvanR> | still not sure there is a problem yet |
| 2023-08-21 01:25:19 +0200 | Guest|7 | (~Guest|7@cpe-184-54-115-255.swo.res.rr.com) (Quit: Connection closed) |
| 2023-08-21 01:25:40 +0200 | <wroathe> | I just added the full profile |
| 2023-08-21 01:25:41 +0200 | <wroathe> | To that gist |
| 2023-08-21 01:25:48 +0200 | <wroathe> | If you refresh |
| 2023-08-21 01:25:54 +0200 | <EvanR> | other than the obvious, you will wait until the end of parsing to return a giant linked list of strings |
| 2023-08-21 01:26:10 +0200 | <wroathe> | yeah, I expect that much |
| 2023-08-21 01:26:23 +0200 | <EvanR> | but since we don't know if parsing failed until we finish, we can't start process that list lazily with this plan |
| 2023-08-21 01:26:24 +0200 | <wroathe> | I'm just not expecting advanceTo to be responsible for 37% of allocations |
| 2023-08-21 01:27:07 +0200 | <EvanR> | well the code for findIndex does a bunch of stuff |
| 2023-08-21 01:27:22 +0200 | <wroathe> | So maybe that's the cost... |
| 2023-08-21 01:27:28 +0200 | <wroathe> | Hmm, I guessed it would've been drop |
| 2023-08-21 01:27:32 +0200 | <EvanR> | if it produces temporary constructors, they will be collected soon |
| 2023-08-21 01:27:48 +0200 | dolio | (~dolio@130.44.134.54) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-08-21 01:28:58 +0200 | <EvanR> | can you write a faster processor for this data, probably xD |
| 2023-08-21 01:29:31 +0200 | <EvanR> | maybe using pipes or conduit |
| 2023-08-21 01:29:48 +0200 | <wroathe> | faster in what sense? |
| 2023-08-21 01:30:00 +0200 | xff0x | (~xff0x@138.64.86.45) (Quit: xff0x) |
| 2023-08-21 01:30:01 +0200 | <wroathe> | I'm fine with it buffering up my objects for the parse in memory |
| 2023-08-21 01:30:33 +0200 | <wroathe> | The way I've written it it should only examine each line of the file twice |
| 2023-08-21 01:30:35 +0200 | <EvanR> | fast runtime, less memory usage |
| 2023-08-21 01:31:28 +0200 | <wroathe> | Well, what's slow about this? (I'm just trying to understand what you see as costly here) |
| 2023-08-21 01:31:28 +0200 | caryhartline | (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 2023-08-21 01:31:36 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9c64:3e23:a36:74a0) |
| 2023-08-21 01:31:58 +0200 | <EvanR> | depends on what the goal is. To produce a giant list of strings in memory and then end the program? |
| 2023-08-21 01:32:27 +0200 | <wroathe> | EvanR: Haha, to insert into a database. I just haven't gotten that far yet. |
| 2023-08-21 01:32:43 +0200 | <wroathe> | I'm trying to get the parser perfect first, and then I'll write the "insert into my database" co de |
| 2023-08-21 01:32:46 +0200 | <wroathe> | code* |
| 2023-08-21 01:33:16 +0200 | <EvanR> | if you change it slightly to "insert every valid line (record) into the database" you could go much faster |
| 2023-08-21 01:33:54 +0200 | <wroathe> | That typically runs contradictory to everything I know about program speed :P I/O is expensive. It's much cheaper to buffer all of this up and then do large inserts |
| 2023-08-21 01:34:05 +0200 | <wroathe> | s/cheaper/faster/ |
| 2023-08-21 01:34:51 +0200 | <wroathe> | I'm just trying to get rid of unnecessary allocations. I'm pretty happy with what's there so far besides strange results I'm seeing |
| 2023-08-21 01:35:53 +0200 | <EvanR> | when you read a file incrementally, it's buffered for you |
| 2023-08-21 01:36:18 +0200 | <wroathe> | I mean buffer the objects up that I'm then serializing into INSERT statements |
| 2023-08-21 01:36:44 +0200 | <wroathe> | Incremental I/O wouldn't help here. I think we might be saying the same thing |
| 2023-08-21 01:36:51 +0200 | razetime | (~quassel@117.254.37.152) |
| 2023-08-21 01:37:08 +0200 | <EvanR> | yeah, you can have a pipeline stage that chunks valid records if you want to put them all in one sql call |
| 2023-08-21 01:37:30 +0200 | <wroathe> | How is that different than what I'm doing here? It seems to me that the difference there is just the API |
| 2023-08-21 01:37:43 +0200 | <EvanR> | I just see a profile that grows to 100M before doing anything as possibly going faster, since having large heap footprint slows haskell down |
| 2023-08-21 01:38:13 +0200 | <wroathe> | I'm 1. Reading the entire file into memory, 2. Parsing its contents into records in memory, and then I'll be 3. Serializing those objects into large INSERT statements |
| 2023-08-21 01:38:46 +0200 | dolio | (~dolio@130.44.134.54) |
| 2023-08-21 01:38:50 +0200 | <EvanR> | yeah, that's chunk size = everything |
| 2023-08-21 01:39:21 +0200 | <wroathe> | It just seems strange that an 8MB file would result in 100MB of resident heap size for this |
| 2023-08-21 01:39:36 +0200 | <wroathe> | For a comparable C program I'd be surprised if I went over 20MB in total |
| 2023-08-21 01:39:44 +0200 | <EvanR> | depends on how large your string slices into the file are |
| 2023-08-21 01:39:46 +0200 | <wroathe> | For both the file in memory and my allocated structs |
| 2023-08-21 01:40:02 +0200 | <EvanR> | if each string is 1 character, 8 -> 100 would be lucky xD |
| 2023-08-21 01:40:11 +0200 | hsxtrt | (~hsxtrt@14-200-253-168.static.tpgi.com.au) |
| 2023-08-21 01:40:19 +0200 | <wroathe> | Yeah I think that's the rub |
| 2023-08-21 01:40:20 +0200 | <EvanR> | a Text has non trivial overhead |
| 2023-08-21 01:40:32 +0200 | <EvanR> | at least it's not 1 character |
| 2023-08-21 01:40:59 +0200 | <EvanR> | this is another reason you'd like to not load it all into memory at once |
| 2023-08-21 01:41:07 +0200 | <wroathe> | Hmm, I wonder if Bytestring or String would lead to better memory usage |
| 2023-08-21 01:41:20 +0200 | <monochrom> | Did you know that a list of length n takes 3*w*n bytes where w=4 or 8, and this is just for the (:) nodes, not even counting the elements? |
| 2023-08-21 01:41:21 +0200 | <geekosaur> | String will be much worse |
| 2023-08-21 01:41:21 +0200 | <EvanR> | not String, no which has that overhead for every single Char |
| 2023-08-21 01:41:39 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2023-08-21 01:42:03 +0200 | <monochrom> | And the heap size is going to be 2*3*w*n because copying GC = double buffering like in computer graphics. |
| 2023-08-21 01:42:29 +0200 | <wroathe> | monochrom: where are you getting the 3 from? |
| 2023-08-21 01:42:44 +0200 | <monochrom> | How GHC does algebraic data types. |
| 2023-08-21 01:43:05 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9c64:3e23:a36:74a0) (Quit: xff0x) |
| 2023-08-21 01:43:13 +0200 | <wroathe> | Hmm, let me get the final list counts |
| 2023-08-21 01:43:38 +0200 | <monochrom> | A white-lie model that gives the correct answer but white-lie reason: each data constructor takes w bytes, each field is a pointer that also takes w bytes. |
| 2023-08-21 01:43:49 +0200 | <wroathe> | Oh shoot I'm about to be kicked out of this coffee shop. I'll be back on in a bit |
| 2023-08-21 01:43:50 +0200 | <EvanR> | the list nodes don't even show up in your profile because that's at the last moment before the program ends (without using the list) |
| 2023-08-21 01:43:51 +0200 | <monochrom> | (:) has 2 fields therefore (1+2)*w bytes. |
| 2023-08-21 01:43:54 +0200 | caryhartline | (~caryhartl@168.182.58.169) |
| 2023-08-21 01:44:17 +0200 | <EvanR> | profile after you print out the number of list nodes xD |
| 2023-08-21 01:44:33 +0200 | <wroathe> | EvanR: Yeah that adds even more. I've tested that. |
| 2023-08-21 01:45:00 +0200 | <monochrom> | The white lie is in "data constructor takes w bytes". In truth, it is a pointer to a chunk of code and info that represents the data constructor. |
| 2023-08-21 01:45:03 +0200 | <EvanR> | list is better used as a vehicle for lazy evaluation than a large data structure :tm: |
| 2023-08-21 01:46:03 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2023-08-21 01:47:04 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-21 01:47:32 +0200 | <hpc> | it's perhaps better to call it a control structure than a data structure |
| 2023-08-21 01:47:54 +0200 | <EvanR> | Control.List |
| 2023-08-21 01:47:56 +0200 | <hpc> | it's a loop in disguise, kind of like how a tree is a search in disguise |
| 2023-08-21 01:47:57 +0200 | <EvanR> | Data.Monad |
| 2023-08-21 01:48:17 +0200 | <mauke> | Data.Function |
| 2023-08-21 01:48:24 +0200 | <EvanR> | Function.Data |
| 2023-08-21 01:48:52 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 250 seconds) |
| 2023-08-21 01:48:56 +0200 | <hpc> | in other languages they still talk about say, alpha-beta search as a "search tree" rather than "this funny sort of recursive function call" |
| 2023-08-21 01:49:07 +0200 | <monochrom> | Basically people who are short on RAM know about the life hack that you can reduce space consumption by 50% just by switching back to 32-bit GHC. |
| 2023-08-21 01:49:08 +0200 | <int-e> | wroathe: Hmm, can you try making `i` strict in this line? https://gist.github.com/JustinChristensen/72e4eae8a8e6e4e4f9be09078770c504#file-parse-hs-L161 (so either with a bang pattern, (!i, "") or with i `seq` on the RHS) |
| 2023-08-21 01:49:35 +0200 | <EvanR> | they left |
| 2023-08-21 01:49:35 +0200 | <hpc> | the tree never materializes, unless you consider those function definitions a hard-coded version of it |
| 2023-08-21 01:49:42 +0200 | <int-e> | https://hackage.haskell.org/package/text-2.0.2/docs/src/Data.Text.Read.html#decimal looks like it'll leave an unevaluated `foldl'` around |
| 2023-08-21 01:49:45 +0200 | <int-e> | EvanR: oh, unlucky |
| 2023-08-21 01:50:18 +0200 | <geekosaur> | "I'll be back on in a bit" |
| 2023-08-21 01:50:28 +0200 | <geekosaur> | think they're looking for another open coffeeshop 🙂 |
| 2023-08-21 01:50:33 +0200 | <EvanR> | ^ |
| 2023-08-21 01:50:35 +0200 | <hpc> | monochrom: from a certain perspective, they're reducing space consumption by a factor of 4 billion :D |
| 2023-08-21 01:50:43 +0200 | <int-e> | Which maybe explains the odd Data.Text.Read.sat_s1Vc6 allocations *and* will also hang onto a bunch of `Text` data. (looking at https://i.imgur.com/aETjZ8g.png ) |
| 2023-08-21 01:51:02 +0200 | <int-e> | (I'd probably forget if I didn't finish that thought.) |
| 2023-08-21 01:51:15 +0200 | mvk | (~mvk@2607:fea8:5c9a:a600::1c6d) (Ping timeout: 246 seconds) |
| 2023-08-21 01:51:22 +0200 | <hpc> | (actually more than that, exponentials are ridiculous) |
| 2023-08-21 01:51:28 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 2023-08-21 01:51:40 +0200 | falafel | (~falafel@51.6.68.216) (Ping timeout: 248 seconds) |
| 2023-08-21 01:52:10 +0200 | <monochrom> | Sunday evening anything open late is going to be tough. |
| 2023-08-21 01:52:33 +0200 | <int-e> | EvanR: "unlucky" - I used tab-completion to write that nick |
| 2023-08-21 01:52:52 +0200 | <int-e> | but didn't check again when I had finished typing the message |
| 2023-08-21 01:53:32 +0200 | <EvanR> | libera haskell IRC perpetual blinking neon sign that says OPEN |
| 2023-08-21 01:53:58 +0200 | <EvanR> | ok maybe not blinking that would drive me nuts |
| 2023-08-21 01:54:55 +0200 | <monochrom> | Some neon signs blink because of malfunction and old age. We're in good hands. >:) |
| 2023-08-21 01:55:43 +0200 | <EvanR> | yeah not blinking VCR 12:00, but stochastic |
| 2023-08-21 01:57:46 +0200 | <monochrom> | I feel that we are just confronting the well-understood "parsing with `many foo` takes linear space and the constant multiplier is huge too". |
| 2023-08-21 01:58:55 +0200 | <int-e> | monochrom: I mostly agree. I just didn't understand that one particular allocation. |
| 2023-08-21 02:00:51 +0200 | <monochrom> | This year I didn't teach Functor-Applicative-Monad. But I thought up a good exam question a while ago before I made that decision. |
| 2023-08-21 02:01:24 +0200 | <monochrom> | One can prove from the Applicative laws that `liftA2 (&&)` must not do short-circuiting. |
| 2023-08-21 02:02:00 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-08-21 02:02:00 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-08-21 02:02:00 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-08-21 02:02:06 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-08-21 02:02:14 +0200 | <wroathe> | Back. Sorry. Damn public places and their so-called "hours of operation" |
| 2023-08-21 02:03:27 +0200 | <EvanR> | you missed some stuff https://ircbrowse.tomsmeding.com/browse/lchaskell?id=1055666#trid1055666 |
| 2023-08-21 02:03:28 +0200 | <int-e> | wroathe: http://paste.debian.net/1289541/ |
| 2023-08-21 02:03:41 +0200 | <int-e> | hah, redundant again |
| 2023-08-21 02:04:34 +0200 | <wroathe> | int-e: EvanR: thanks |
| 2023-08-21 02:04:34 +0200 | califax | (~califax@user/califx) |
| 2023-08-21 02:04:39 +0200 | <monochrom> | Actually more essentially and easily, `fmap (False &&) foo` cannot short-ciruit to pure False. |
| 2023-08-21 02:05:20 +0200 | <int-e> | > liftA2 (&&) (pure False) (pure undefined) |
| 2023-08-21 02:05:21 +0200 | <lambdabot> | error: |
| 2023-08-21 02:05:21 +0200 | <lambdabot> | • Ambiguous type variable ‘f0’ arising from a use of ‘show_M661397343980... |
| 2023-08-21 02:05:21 +0200 | <lambdabot> | prevents the constraint ‘(Show (f0 Bool))’ from being solved. |
| 2023-08-21 02:05:28 +0200 | <int-e> | > liftA2 (&&) (pure False) (pure undefined) :: [Bool] |
| 2023-08-21 02:05:29 +0200 | <lambdabot> | [False] |
| 2023-08-21 02:05:53 +0200 | <monochrom> | pure undefined /= undefined |
| 2023-08-21 02:06:15 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9c64:3e23:a36:74a0) |
| 2023-08-21 02:06:15 +0200 | <int-e> | monochrom: sure, I know what you're after, but I couldn't help pointing out that the short-cutting of && is still there |
| 2023-08-21 02:06:57 +0200 | <wroathe> | Haha, I wasn't looking for another coffee shop. I decided to head home. They can't kick me out of my home (at least I don't think...) |
| 2023-08-21 02:07:32 +0200 | <int-e> | this is pretty much the dividing line between applicatives and monads... with moands, you *can* short-circuit on the monad action level. |
| 2023-08-21 02:08:05 +0200 | <wroathe> | int-e: EvanR: so what's the takeaway from that backscroll? int-e is that line you highlighted a major source of my allocation troublle? |
| 2023-08-21 02:08:06 +0200 | <int-e> | "Computations depending on wrapped values" if you will. Which is really the essence of bind. |
| 2023-08-21 02:08:45 +0200 | <int-e> | wroathe: I don't know... I didn't run any code. It /might/ be good for reducing allocations by 10-15%. |
| 2023-08-21 02:09:08 +0200 | <EvanR> | it was something to try |
| 2023-08-21 02:09:21 +0200 | <EvanR> | maybe a magic single ! that improves performance |
| 2023-08-21 02:10:14 +0200 | <int-e> | wroathe: TBH I'm mostly questioning your approach... why would you go through the file in one go instead of using smaller chunks. But I got curious about that one allocation item. |
| 2023-08-21 02:10:55 +0200 | <wroathe> | I'm gathering the haskell GC makes processing in smaller chunks advantageous, but conventional wisdom with other runtimes is that this is the better approach |
| 2023-08-21 02:11:24 +0200 | <wroathe> | In general I don't care if this takes memory. I just don't want it to be taking memory that it doesn't need to. |
| 2023-08-21 02:11:30 +0200 | <int-e> | sorry, not allocations |
| 2023-08-21 02:11:34 +0200 | <int-e> | I mean resident size |
| 2023-08-21 02:12:19 +0200 | hsxtrt | (~hsxtrt@14-200-253-168.static.tpgi.com.au) (Quit: This computer has gone to sleep) |
| 2023-08-21 02:12:57 +0200 | jero98772 | (~jero98772@2800:484:1d84:300::2) (Ping timeout: 260 seconds) |
| 2023-08-21 02:13:24 +0200 | <EvanR> | 2 seconds is a really long time for that size of file. It's great that it works, but if we really don't care about performance, why all the hacking of parser state |
| 2023-08-21 02:13:26 +0200 | <wroathe> | monochrom: So in total this results in 30209 "company" objects, 90627 "address" objects, and 30209 "submission" objects after parsing this file |
| 2023-08-21 02:14:30 +0200 | <wroathe> | EvanR: Because the hacking of parser state is supposed to be a performance improvement. The point there is that I'm trying to remember field positions to allow for random access to give myself the freedom to parse a given row into multiple objects in a random access pattern like parseSubmission does |
| 2023-08-21 02:14:43 +0200 | <EvanR> | I presumed you wanted high performance, like, does all this in like 2 milliseconds xD |
| 2023-08-21 02:14:56 +0200 | <wroathe> | I'm quite happy with that API for what I'm doing. The advancing of the parser from one field separation to the next should in theory be "free" |
| 2023-08-21 02:15:02 +0200 | <wroathe> | But this profile says it's 37% of my allocations |
| 2023-08-21 02:15:14 +0200 | <int-e> | Nobody has said "premature optimization" yet... this really feels like one. |
| 2023-08-21 02:15:16 +0200 | <wroathe> | EvanR: If I wanted that high of performance I'd just do this in C |
| 2023-08-21 02:15:17 +0200 | hsxtrt | (~hsxtrt@14-200-253-168.static.tpgi.com.au) |
| 2023-08-21 02:15:24 +0200 | <EvanR> | no. |
| 2023-08-21 02:15:26 +0200 | <wroathe> | int-e: It's a hobby program. If this were for work I'd agree with you |
| 2023-08-21 02:15:35 +0200 | <geekosaur> | flatparse |
| 2023-08-21 02:15:45 +0200 | <EvanR> | I think a point is being missed here about how haskell can be really fast, esp at simple stuff like this |
| 2023-08-21 02:15:51 +0200 | <wroathe> | But since I'm doing this for fun I'm free to quibble about memory use and performance all I want :D |
| 2023-08-21 02:15:55 +0200 | <EvanR> | but you're slow and complicated right now |
| 2023-08-21 02:16:41 +0200 | <wroathe> | So the key to a fast haskell program is to find out what the perfect max residency size is to manipulate the GC into being performant? |
| 2023-08-21 02:16:59 +0200 | <wroathe> | Or what's the fundamental difference here between my "slow and complicated" approach, and what I should be doing? |
| 2023-08-21 02:17:18 +0200 | <EvanR> | I'm just saying it would be slow and simple by using megaparsec normally |
| 2023-08-21 02:17:32 +0200 | <int-e> | geekosaur: argh, why is `char :: Char -> Q Exp` |
| 2023-08-21 02:17:34 +0200 | <EvanR> | less code I believ |
| 2023-08-21 02:18:55 +0200 | <wroathe> | EvanR: I'm not understanding how this isn't a normal use of megaparsec. There's nothing in the API documentation that says I'm not allowed to manipulate the parser state. In fact, he provides an API to do just that |
| 2023-08-21 02:18:56 +0200 | <EvanR> | (maybe it would actually improve performance not trying to preempt the parser and search the string yourself) |
| 2023-08-21 02:19:00 +0200 | <int-e> | It's mostly fine; I just didn't expect to see Template Haskell in the API. |
| 2023-08-21 02:19:02 +0200 | logothesia | (~logothesi@user/logothesia) (Ping timeout: 256 seconds) |
| 2023-08-21 02:19:32 +0200 | <EvanR> | well you search but also use combinators like manyTill |
| 2023-08-21 02:19:36 +0200 | <wroathe> | The reason I'm doing it this way is so I get nice parse errors as I'm trying to randomly access the current parsed row |
| 2023-08-21 02:20:09 +0200 | <EvanR> | fair enough |
| 2023-08-21 02:20:15 +0200 | <wroathe> | If I were to just read the current row into a [Text] I'd be able to do the random access thing, but the parse errors would suck |
| 2023-08-21 02:20:29 +0200 | <EvanR> | sure |
| 2023-08-21 02:20:52 +0200 | <wroathe> | And in that circumstance I'd be skeptical that I'm doing anything fundamentally different than what I'm doing now |
| 2023-08-21 02:21:19 +0200 | <wroathe> | Because ultimately `drop` and takeWhileP would end up resulting in a new Text being created |
| 2023-08-21 02:21:58 +0200 | <EvanR> | drop obviously creates a new Text, but it just points into the existing underlying array, which is great |
| 2023-08-21 02:22:35 +0200 | <wroathe> | Also another thing that's weird about this... |
| 2023-08-21 02:23:02 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 252 seconds) |
| 2023-08-21 02:23:04 +0200 | <wroathe> | Say what you will about the "random access" to a row's fields thing I'm trying to do, but advanceTo is only being called proportional to the number of fields in the underlying TSV file |
| 2023-08-21 02:23:11 +0200 | <geekosaur> | int-e, it looks like they generate parsers for literals at compile time for speed |
| 2023-08-21 02:23:14 +0200 | <wroathe> | That is, it should only be called once per \t or \n |
| 2023-08-21 02:23:25 +0200 | <EvanR> | you also need to be careful about attributing "allocations" to particular functions |
| 2023-08-21 02:23:40 +0200 | <geekosaur> | everything leads to https://hackage.haskell.org/package/flatparse-0.5.0.1/docs/src/FlatParse.Basic.Bytes.html#bytesUns… |
| 2023-08-21 02:23:43 +0200 | <wroathe> | Yeah I'm just going off of what that profile says. |
| 2023-08-21 02:23:45 +0200 | <EvanR> | I'm not sure how meaningful the profile is on that, since stuff happens at lazy times |
| 2023-08-21 02:24:07 +0200 | <wroathe> | geekosaur: Haha, is this how I make a fast haskell parser? :) |
| 2023-08-21 02:24:22 +0200 | <geekosaur> | yes |
| 2023-08-21 02:24:45 +0200 | <wroathe> | EvanR: well there I ahve it |
| 2023-08-21 02:24:47 +0200 | <int-e> | beautiful |
| 2023-08-21 02:24:47 +0200 | <wroathe> | have* it |
| 2023-08-21 02:25:04 +0200 | <wroathe> | Idk these parser combinator libraries are pretty heavily marketed in the haskell space |
| 2023-08-21 02:25:06 +0200 | <int-e> | (there's a blinking sarcasm tag after that) |
| 2023-08-21 02:25:16 +0200 | <EvanR> | code that is located within some function lexically could be evaluated as part of some other thing because laziness |
| 2023-08-21 02:25:26 +0200 | <wroathe> | It's as if Attoparsec, Parsec, and Megaparsec are the only way you're supposed to parse in a functional context |
| 2023-08-21 02:25:44 +0200 | <wroathe> | Nevermind a good old fashioned stack and switch iterative parser |
| 2023-08-21 02:26:03 +0200 | <EvanR> | those do represent the haskell version of recursive descent |
| 2023-08-21 02:26:03 +0200 | <geekosaur> | happy exists, it's just slower than megaparsec or attoparsec |
| 2023-08-21 02:26:14 +0200 | <probie> | Some people still use happy (the Haskell version of yacc/bison) |
| 2023-08-21 02:26:47 +0200 | <geekosaur> | flatparse is quite new so hasn't got a lot of market share yet, but it's been catching on |
| 2023-08-21 02:27:50 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) |
| 2023-08-21 02:28:16 +0200 | <wroathe> | Well thanks for the help guys (especially you, EvanR). I've got a lot to mull over here. |
| 2023-08-21 02:28:39 +0200 | <EvanR> | wroathe, another avenue you might be barking down inappropriately, is the act of allocating is not as expensive as in C with malloc. Since the allocator is very simple (the GC does all the work later) |
| 2023-08-21 02:29:32 +0200 | YuutaW | (~YuutaW@mail.yuuta.moe) (Ping timeout: 245 seconds) |
| 2023-08-21 02:29:35 +0200 | <EvanR> | so if some function really is doing 37% of the allocations, it might not be taking all the time |
| 2023-08-21 02:29:48 +0200 | <wroathe> | EvanR: Yeah, but as you said, 2s is quite a long time. I've already made one performance improvement to this by fixing a place where I was using T.unpack to create small String objects whenever a field of my TSV held a time value I wanted to parse using parseTimeM from the time library |
| 2023-08-21 02:29:58 +0200 | caryhartline | (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 2023-08-21 02:30:05 +0200 | <wroathe> | And it resulted in like a 30% reduction in allocations and an improvement of like 1.5 in running time |
| 2023-08-21 02:30:23 +0200 | <int-e> | "Megaparsec [...] tries to find a nice balance between speed, flexibility, and quality of parse errors." -- reducing allocations doesn't even make the list |
| 2023-08-21 02:30:26 +0200 | <wroathe> | So I figure if I can make one more big improvement like that I'll be cooking with fire |
| 2023-08-21 02:30:47 +0200 | razetime | (~quassel@117.254.37.152) (Ping timeout: 245 seconds) |
| 2023-08-21 02:30:48 +0200 | <EvanR> | another metric to look at is how much time is spent in GC |
| 2023-08-21 02:30:59 +0200 | <EvanR> | as a percent of runtime |
| 2023-08-21 02:31:17 +0200 | int-e | usually looks at residency and productivity |
| 2023-08-21 02:31:31 +0200 | razetime | (~quassel@117.254.36.54) |
| 2023-08-21 02:32:12 +0200 | <geekosaur> | don't even need to profile for that, +RTS -s |
| 2023-08-21 02:32:18 +0200 | YuutaW | (~YuutaW@mail.yuuta.moe) |
| 2023-08-21 02:32:23 +0200 | <int-e> | The amount of allocations matters, but temporary allocations are also the price of laziness. If I want full control over allocations I won't be using Haskell. |
| 2023-08-21 02:32:47 +0200 | <EvanR> | you would use zig? xD |
| 2023-08-21 02:33:09 +0200 | <EvanR> | comes with no less than 5 standard allocators |
| 2023-08-21 02:34:14 +0200 | <int-e> | Rust or C or C++ most likely, in some order. |
| 2023-08-21 02:34:48 +0200 | <geekosaur> | but if they're truly temporary allocations they cost ~nothing |
| 2023-08-21 02:35:47 +0200 | <wroathe> | In a C context I'd mmap the file into memory, and then allocate a region for my objects. The string values would just be pointers into the original mmapped TSV file along with a length, or structs to hold the date objects or int for everything else |
| 2023-08-21 02:35:51 +0200 | razetime | (~quassel@117.254.36.54) (Ping timeout: 245 seconds) |
| 2023-08-21 02:35:52 +0200 | <EvanR> | because they don't get traversed and then are lost all at once from the nursery |
| 2023-08-21 02:36:13 +0200 | razetime | (~quassel@117.254.37.27) |
| 2023-08-21 02:36:27 +0200 | <wroathe> | All told like I said I'd be surprised if I went over 20MB residency for the whole parsed file with the structs |
| 2023-08-21 02:36:33 +0200 | <int-e> | EvanR: yeah, it's cheap but it's not free (it comes at the cost of memory locality) |
| 2023-08-21 02:39:41 +0200 | <EvanR> | I'm still curious about the possibly foldl' thunks corresponding to the 3rd thing in the profile, that might be eliminated with a single !, but meh |
| 2023-08-21 02:40:16 +0200 | <wroathe> | I'll try int-e's suggestion in a bit here after I finish my dinner |
| 2023-08-21 02:40:44 +0200 | bratwurst | (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) (Ping timeout: 248 seconds) |
| 2023-08-21 02:43:04 +0200 | phma | (~phma@host-67-44-208-38.hnremote.net) (Read error: Connection reset by peer) |
| 2023-08-21 02:43:34 +0200 | phma | (~phma@2001:5b0:2143:fba8:9b6b:196:6798:af5d) |
| 2023-08-21 02:44:18 +0200 | mikoto-chan | (~mikoto-ch@85-76-46-81-nat.elisa-mobile.fi) (Ping timeout: 246 seconds) |
| 2023-08-21 02:45:24 +0200 | mvk | (~mvk@2607:fea8:5c9a:a600::1c6d) |
| 2023-08-21 02:45:54 +0200 | <int-e> | wroathe: Oh you also had that ghc-debug problem earlier... I think you have ghc < 9.4.2 but something in the build plan pulled in a later version of ghc-heap. (apparently ghc-heap-9.6.1 can be compiled on older ghc's, but does it actually work there?) |
| 2023-08-21 02:49:14 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Ping timeout: 244 seconds) |
| 2023-08-21 02:49:38 +0200 | <wroathe> | int-e: 9.2.5. Good eye. |
| 2023-08-21 02:49:42 +0200 | <wroathe> | I was wondering if that was the cause. |
| 2023-08-21 02:51:11 +0200 | <int-e> | (I rather suspect that using a mismatched version of ghc-heap isn't okay... there's stuff in there that has to correspond directly with RTS internals like https://hackage.haskell.org/package/ghc-heap-9.6.1/docs/src/GHC.Exts.Heap.ClosureTypes.html ) |
| 2023-08-21 02:51:49 +0200 | <wroathe> | GHC releases new versions so quickly it's hard to keep up :P |
| 2023-08-21 02:52:04 +0200 | <int-e> | and with the matching ghc-heap version you wouldn't run into this; compare https://gitlab.haskell.org/ghc/ghc-debug/-/blob/master/common/src/GHC/Debug/Decode/Convert.hs#L33-40 |
| 2023-08-21 02:52:14 +0200 | <wroathe> | And I only program in Haskell as a hobby, so it can be weeks or months at a time before I get back to little projects I'm working on |
| 2023-08-21 02:52:29 +0200 | <wroathe> | int-e: Yeah, I was convinced when you initially said it |
| 2023-08-21 02:52:38 +0200 | <wroathe> | I suspected that updating GHC would fix it when I posted the error earlier |
| 2023-08-21 02:52:47 +0200 | <wroathe> | Although I didn't go into the detail you're going into to prove my assertion |
| 2023-08-21 02:53:17 +0200 | <int-e> | wroathe: Yeah but I'm not saying that you should update GHC necessarily... at least at a glance, ghc-debug itself should be fine on older GHCs. |
| 2023-08-21 02:53:40 +0200 | <int-e> | So I believe something else is pulling in a newer ghc-heap. |
| 2023-08-21 02:55:15 +0200 | <int-e> | (And ideally, that package should have tighter dependencies so that this doesn't happen.) |
| 2023-08-21 02:56:12 +0200 | <wroathe> | Well ghc-debug is still not fully baked |
| 2023-08-21 02:56:23 +0200 | <wroathe> | It's only in version 0.5 at the moment |
| 2023-08-21 02:57:24 +0200 | razetime | (~quassel@117.254.37.27) (Ping timeout: 246 seconds) |
| 2023-08-21 02:57:28 +0200 | <int-e> | hmm. I guess something like cabal install --constraint "ghc-heap=installed" would help to pinpoint the real culprit here. Assuming the installed version is the one bundled with the compiler. |
| 2023-08-21 02:57:55 +0200 | razetime | (~quassel@117.254.36.220) |
| 2023-08-21 02:58:29 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-08-21 02:58:56 +0200 | <geekosaur> | I think it's 'ghc-heap installed', not sure if the = works there |
| 2023-08-21 02:59:06 +0200 | <geekosaur> | (double quotes also fine) |
| 2023-08-21 02:59:06 +0200 | <int-e> | geekosaur: oh yes |
| 2023-08-21 03:03:41 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-08-21 03:06:39 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-21 03:06:40 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2023-08-21 03:10:35 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-08-21 03:12:37 +0200 | <wroathe> | int-e: Only slightly better. 83,266,260 versus 89,793,936 |
| 2023-08-21 03:12:45 +0200 | <wroathe> | with that bang pattern |
| 2023-08-21 03:14:20 +0200 | <EvanR> | 17% less 🎉 |
| 2023-08-21 03:15:16 +0200 | <EvanR> | 7.2% less wow I can't use a calculator! |
| 2023-08-21 03:15:22 +0200 | <wroathe> | I was going to say |
| 2023-08-21 03:15:37 +0200 | <wroathe> | You had me in the middle of whipping out my own calculator :D |
| 2023-08-21 03:15:56 +0200 | <int-e> | better than nothing. does it change the https://i.imgur.com/aETjZ8g.png graph? (hmm is that allocations or residency...) |
| 2023-08-21 03:16:05 +0200 | <EvanR> | tada emoji somewhat rescinded |
| 2023-08-21 03:16:21 +0200 | <wroathe> | cabal run tallow -O2 --enable-profiling -- data/2023q2/sub.txt +RTS -pa -L120 -hd |
| 2023-08-21 03:16:33 +0200 | <wroathe> | int-e: it's the result of -hd, which I think is residency |
| 2023-08-21 03:16:43 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-08-21 03:16:54 +0200 | <wroathe> | https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#rts-flag--hd |
| 2023-08-21 03:17:32 +0200 | <int-e> | "live heap", yeah that's residency |
| 2023-08-21 03:17:54 +0200 | quidnunc | (~user@70.31.194.28) (Read error: Connection reset by peer) |
| 2023-08-21 03:19:04 +0200 | <wroathe> | int-e: https://i.imgur.com/3WYdFMs.png |
| 2023-08-21 03:20:15 +0200 | <int-e> | Cool, so the Data.Text.Read.sat* things are indeed gone. But it didn't reduce the Text numbers, hmm. Interesting. |
| 2023-08-21 03:21:40 +0200 | <int-e> | (so that part of my speculation didn't work out) |
| 2023-08-21 03:22:10 +0200 | <EvanR> | when you get individual text values in the recursive parser, I wonder if those are even evaluated fully before the list begins to materials |
| 2023-08-21 03:22:12 +0200 | <EvanR> | materialize |
| 2023-08-21 03:22:27 +0200 | <EvanR> | at the end of parsing |
| 2023-08-21 03:23:14 +0200 | <EvanR> | assuming that's not them in the profile |
| 2023-08-21 03:23:20 +0200 | <EvanR> | which I was assuming |
| 2023-08-21 03:23:54 +0200 | <int-e> | Oh and of course the results have to go somewhere... is that the IS thing? |
| 2023-08-21 03:25:14 +0200 | <int-e> | (Is that how I# is rendered in a profile?) |
| 2023-08-21 03:28:52 +0200 | hsxtrt | (~hsxtrt@14-200-253-168.static.tpgi.com.au) (Quit: This computer has gone to sleep) |
| 2023-08-21 03:30:08 +0200 | mikoto-chan | (~mikoto-ch@85-76-111-77-nat.elisa-mobile.fi) |
| 2023-08-21 03:35:19 +0200 | <int-e> | Anyway, I think ultimately the data may just be roughly this big. For example, each `Maybe Text` that isn't Nothing takes up 48 bytes on the heap, in addition to 8 bytes in the corresponding record. (Assuming a 64 bit system), assuming they all point to the same underlying byte array. |
| 2023-08-21 03:36:21 +0200 | <wroathe> | int-e: Could be, yeah. I'm just trying to beat this advanceTo thing to death |
| 2023-08-21 03:36:22 +0200 | <int-e> | corresponding to the Text and Just constructors in that profile. |
| 2023-08-21 03:36:36 +0200 | libertyprime | (~libertypr@203.96.203.44) |
| 2023-08-21 03:36:42 +0200 | <wroathe> | I'm about to run an experiment to isolate advanceTo here |
| 2023-08-21 03:36:58 +0200 | <int-e> | I mean, there are a lot of sat_ there indicating that things are lazy that could be strict. |
| 2023-08-21 03:37:45 +0200 | <wroathe> | ! all the things |
| 2023-08-21 03:37:50 +0200 | <int-e> | But it's starting to look like you won't get below 60M with those data types, no matter how you do the parsing. |
| 2023-08-21 03:38:27 +0200 | <wroathe> | int-e: Yup, I figured as much. |
| 2023-08-21 03:38:50 +0200 | <int-e> | ("with those data types": it would be significantly more compact if you replaced each Maybe Text by an index and a length into the original input) |
| 2023-08-21 03:38:52 +0200 | jle` | (~jle`@23.240.75.236) (Ping timeout: 248 seconds) |
| 2023-08-21 03:39:22 +0200 | <int-e> | If those are unpacked, that's 16 bytes instead of 48 + 8 bytes. |
| 2023-08-21 03:39:43 +0200 | <wroathe> | Do you have some reading I can do on the representation of haskell data in memory? |
| 2023-08-21 03:39:59 +0200 | <wroathe> | With C I can more or less add it all up in my head for my architecture, but for Haskell I've got no fucking clue |
| 2023-08-21 03:40:16 +0200 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
| 2023-08-21 03:42:11 +0200 | <int-e> | Well in the simplest case, it's one word for the constructor tag, and another word for each data item attached to it (a pointer). This is complicated when strict fields get unpacked... then rather than the pointer, you have the fields of the unpacked single-constructor type. And then you have primitive types which are usually a word, some sometimes more. |
| 2023-08-21 03:43:50 +0200 | <int-e> | So Just x is 2 words, and Text happens to contain a ByteArray (which is a pointer to a heap object containing the actual byte array), and two unpacked Ints. So that's 4 words. |
| 2023-08-21 03:44:15 +0200 | <int-e> | and 6 words = 48 bytes. |
| 2023-08-21 03:46:16 +0200 | <EvanR> | why do you think there's a ton of Just hanging around |
| 2023-08-21 03:46:18 +0200 | ddellacosta | (~ddellacos@143.244.47.100) (Ping timeout: 256 seconds) |
| 2023-08-21 03:46:46 +0200 | <int-e> | The details... there are papers on GHC's RTS, starting with the STG paper and many tweaks; not sure what the best one is. They talk about stuff like info tables (the tags are pointers to info tables), entry points (actually the tags are pointers to entry points and the info tables are put in front of those entry points)... lots of icky details. |
| 2023-08-21 03:47:00 +0200 | <wroathe> | So I just ran an interesting experiment by just executing parseRowState in a loop |
| 2023-08-21 03:47:11 +0200 | <int-e> | EvanR: Because basically every single text field is a Maybe Text. |
| 2023-08-21 03:47:31 +0200 | <int-e> | EvanR: unless that was a rhetorical question; I can't tell. |
| 2023-08-21 03:47:32 +0200 | <EvanR> | oh the Maybe is part of the output data |
| 2023-08-21 03:47:55 +0200 | <int-e> | EvanR: https://gist.github.com/JustinChristensen/72e4eae8a8e6e4e4f9be09078770c504#file-parse-hs-L53-L58 |
| 2023-08-21 03:47:56 +0200 | <EvanR> | not a control structure |
| 2023-08-21 03:48:09 +0200 | <EvanR> | ok then |
| 2023-08-21 03:48:16 +0200 | ddellacosta | (~ddellacos@146.70.168.217) |
| 2023-08-21 03:48:48 +0200 | <wroathe> | int-e: EvanR: https://i.imgur.com/84es3Qe.png |
| 2023-08-21 03:49:19 +0200 | <EvanR> | that's the same amount of ARR_WORDS as before, just not elevated on top of other stuff |
| 2023-08-21 03:49:25 +0200 | <EvanR> | 8M of ARR_WORDS |
| 2023-08-21 03:49:50 +0200 | <wroathe> | https://gist.github.com/JustinChristensen/72e4eae8a8e6e4e4f9be09078770c504#file-rowstate-hs |
| 2023-08-21 03:49:50 +0200 | <int-e> | wroathe: expected... I mean if I understand correctly, you read the file and while all the stuff you have seen before gets allocated, it also gets collected quickly so it's lost in the noise |
| 2023-08-21 03:49:51 +0200 | <EvanR> | basically the whole file |
| 2023-08-21 03:49:58 +0200 | <int-e> | assuming you actually force the parse result |
| 2023-08-21 03:50:10 +0200 | finsternis | (~X@23.226.237.192) (Read error: Connection reset by peer) |
| 2023-08-21 03:50:37 +0200 | <int-e> | the 3.5MB number looks like you're, maybe, not forcing the parse |
| 2023-08-21 03:50:42 +0200 | hsxtrt | (~hsxtrt@14.200.253.168) |
| 2023-08-21 03:50:56 +0200 | <wroathe> | I linked the updated program there |
| 2023-08-21 03:51:30 +0200 | <EvanR> | I change my earlier speculation about evaluating those individual Text to evaluating the Just text |
| 2023-08-21 03:51:46 +0200 | <EvanR> | as soon as possible |
| 2023-08-21 03:51:59 +0200 | <wroathe> | And here is the profile for that updated program: https://gist.github.com/JustinChristensen/72e4eae8a8e6e4e4f9be09078770c504#file-rowstate-prof |
| 2023-08-21 03:52:12 +0200 | <wroathe> | So based on this what I think I'm getting is... |
| 2023-08-21 03:52:20 +0200 | <wroathe> | Yeah, resident here there's only the 8MB worth of data from the file |
| 2023-08-21 03:52:37 +0200 | <wroathe> | But during the course of execution advanceTo seems to be allocating lots of objects that get GCed immediately? |
| 2023-08-21 03:53:36 +0200 | <wroathe> | I think it must be misreporting |
| 2023-08-21 03:53:49 +0200 | <int-e> | It has to allocate a new Text object. And an updated internal state record for the parser. |
| 2023-08-21 03:53:51 +0200 | <wroathe> | Because I look at the profile it says that 2 GB of allocations can be attributed to advanceTo |
| 2023-08-21 03:54:03 +0200 | <wroathe> | Which sounds very wrong |
| 2023-08-21 03:54:06 +0200 | <int-e> | There are no in-place updates. |
| 2023-08-21 03:54:29 +0200 | <int-e> | It's all recreate-and-discard-old-version. |
| 2023-08-21 03:55:15 +0200 | <EvanR> | normally a haskell program will allocate an insane amount of bytes per second |
| 2023-08-21 03:55:15 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) (Quit: Leaving) |
| 2023-08-21 03:55:31 +0200 | <EvanR> | of course it doesn't stay because you'd run out of memory |
| 2023-08-21 03:55:35 +0200 | <wroathe> | Right |
| 2023-08-21 03:56:05 +0200 | <wroathe> | Yeah, resident here is only the original 8 MB, which is good... although even that looks suspicious |
| 2023-08-21 03:56:18 +0200 | <wroathe> | Because even with this new version of the program I'd expect to see some Text resident |
| 2023-08-21 03:56:56 +0200 | <int-e> | `Text` is just those 32 bytes that point into the big blob that holds the entire input file. |
| 2023-08-21 03:57:12 +0200 | <int-e> | you can have hundreds of those and it won't be visible in the graph |
| 2023-08-21 03:57:50 +0200 | <wroathe> | int-e: Yeah, but according to the profile advanceTo is allocating 2 GB worth of something over the entire ~0.5s of runtime |
| 2023-08-21 03:57:56 +0200 | <int-e> | it's when you get to half a million or more that they become visible like in the other version of the program |
| 2023-08-21 03:58:17 +0200 | <wroathe> | This is what I'm referring to: https://gist.github.com/JustinChristensen/72e4eae8a8e6e4e4f9be09078770c504#file-rowstate-prof-L10 |
| 2023-08-21 03:59:01 +0200 | <int-e> | wroathe: There may be some allocation there that can be avoided, but if so I have no clue what that is. As I said earlier, I usually don't worry about allocations all that much. |
| 2023-08-21 03:59:02 +0200 | <EvanR> | how many loop iterations is that in 0.5s and how many bytes per iteration does it allocate |
| 2023-08-21 03:59:18 +0200 | <EvanR> | could easily add up to 2G |
| 2023-08-21 04:00:13 +0200 | <wroathe> | What I'm wondering is if the runtime is allocating a region or something and that profile is mis-attributing that region allocation to this one routine |
| 2023-08-21 04:04:30 +0200 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 250 seconds) |
| 2023-08-21 04:05:21 +0200 | <int-e> | hmm... it's quite possible that findIndex actually unpacks the text into a stream |
| 2023-08-21 04:07:07 +0200 | <wroathe> | I was actually just about to test if findIndex was the culprit |
| 2023-08-21 04:07:10 +0200 | <int-e> | Follow https://hackage.haskell.org/package/text-2.0.2/docs/src/Data.Text.html#findIndex and notice the absence of an implementation that *doesn't* use a stream. |
| 2023-08-21 04:07:45 +0200 | <EvanR> | is something wrong with using a stream |
| 2023-08-21 04:11:48 +0200 | td_ | (~td@i53870934.versanet.de) (Ping timeout: 256 seconds) |
| 2023-08-21 04:13:35 +0200 | td_ | (~td@i53870925.versanet.de) |
| 2023-08-21 04:14:15 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9c64:3e23:a36:74a0) (Ping timeout: 245 seconds) |
| 2023-08-21 04:16:31 +0200 | gastus | (~gastus@185.6.123.186) |
| 2023-08-21 04:16:34 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-21 04:17:52 +0200 | <dsal> | I replaced that code that was using unsafeIOToSTM by making a pure "forgetful" map and just wrapping it in STM. |
| 2023-08-21 04:18:00 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 245 seconds) |
| 2023-08-21 04:18:27 +0200 | <dsal> | It's not *exactly* the same because that other thing was overly precise with its clock updates and stuff. We just don't want to remember everything forever, so mine's a lot more chill. |
| 2023-08-21 04:19:39 +0200 | gastus_ | (~gastus@185.6.123.193) (Ping timeout: 244 seconds) |
| 2023-08-21 04:20:14 +0200 | <dsal> | The original code was using Map.filter in a loop to drop old entries, so it wasn't exactly precise anyway (though I made all the entrypoints also check before I started making larger changes). |
| 2023-08-21 04:20:49 +0200 | <int-e> | EvanR: Hmm it's more subtle than that. If `text` was compiled with optimizations, the Stream should all disappear. However, the resulting `findIndex` is too big to be inlined. Which means that the chars that are passed to the predicate all have to be boxed... though that doesn't begin to explain 2GB worth of allocations for at most 8M skipped bytes. |
| 2023-08-21 04:21:03 +0200 | <dsal> | Now I just do a Map.splitLookup on a synthetic time thing which gives me all the keys that need to be deleted. |
| 2023-08-21 04:22:42 +0200 | jargon | (~jargon@174-22-213-62.phnx.qwest.net) (Remote host closed the connection) |
| 2023-08-21 04:22:50 +0200 | <int-e> | anyway, let me get out of this rabbit hole |
| 2023-08-21 04:23:00 +0200 | razetime | (~quassel@117.254.36.220) (Ping timeout: 245 seconds) |
| 2023-08-21 04:23:31 +0200 | <EvanR> | you can checkout anytime but never leave |
| 2023-08-21 04:23:37 +0200 | razetime | (~quassel@117.254.37.117) |
| 2023-08-21 04:23:40 +0200 | ddellacosta | (~ddellacos@146.70.168.217) (Ping timeout: 248 seconds) |
| 2023-08-21 04:25:21 +0200 | <monochrom> | The singularity is in your future. >:) |
| 2023-08-21 04:27:25 +0200 | <int-e> | EvanR: (More subtlety: there's also a boxed Bool in that picture... but the two values are statically allocated.) |
| 2023-08-21 04:28:03 +0200 | <EvanR> | .oO(are the first few Char statically allocated too) |
| 2023-08-21 04:28:17 +0200 | <EvanR> | (or the first few Int for that matter) |
| 2023-08-21 04:28:32 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-08-21 04:28:35 +0200 | <int-e> | EvanR: yes but I believe only the unpackCString (spelling?) stuff actually uses that |
| 2023-08-21 04:28:54 +0200 | hugo | (znc@2001:6b0:17:f0a0::17) |
| 2023-08-21 04:28:57 +0200 | <int-e> | And in particular, the C# constructor of Char doesn't. |
| 2023-08-21 04:29:25 +0200 | <int-e> | emphasis on *believe* |
| 2023-08-21 04:31:06 +0200 | ddellacosta | (~ddellacos@146.70.171.136) |
| 2023-08-21 04:35:50 +0200 | <wroathe> | int-e: So this version of advanceTo has no appreciable difference on the 2GB of allocations: https://gist.github.com/JustinChristensen/72e4eae8a8e6e4e4f9be09078770c504#file-sigh-hs |
| 2023-08-21 04:36:03 +0200 | <wroathe> | so findIndex doesn't appear to be the problem |
| 2023-08-21 04:36:26 +0200 | <wroathe> | The stateOffset is only used to compute error output, so for the purposes of testing it can be elided |
| 2023-08-21 04:36:53 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::85eb) |
| 2023-08-21 04:44:17 +0200 | <int-e> | as you suggested earlier, it is possible that there's some misattribution there. |
| 2023-08-21 04:44:57 +0200 | <int-e> | or maybe the function gets used way more often than you think due to backtracking |
| 2023-08-21 04:46:14 +0200 | hsxtrt | (~hsxtrt@14.200.253.168) (Quit: Leaving) |
| 2023-08-21 04:46:40 +0200 | <wroathe> | Well, I just looked at the input file and there are 1,087,560 tabs and newlines in it |
| 2023-08-21 04:46:48 +0200 | <wroathe> | So that should be the number of times advanceTo is called |
| 2023-08-21 04:47:53 +0200 | <int-e> | EvanR: fwiw, using C# definitely results in heap allocations |
| 2023-08-21 04:48:09 +0200 | <EvanR> | :t C# |
| 2023-08-21 04:48:10 +0200 | <lambdabot> | error: Data constructor not in scope: C# |
| 2023-08-21 04:48:22 +0200 | <int-e> | % :info Char |
| 2023-08-21 04:48:22 +0200 | <yahb2> | type Char :: * ; data Char = GHC.Types.C# GHC.Prim.Char# ; -- Defined in ‘GHC.Types’ ; instance Eq Char -- Defined in ‘GHC.Classes’ ; instance Ord Char -- Defined in ‘GHC.Classes’ ; instance Enu... |
| 2023-08-21 04:48:57 +0200 | <int-e> | :t GHC.Types.C# |
| 2023-08-21 04:48:57 +0200 | <EvanR> | when you type 'c' is that "using C#" or a statically allocated 'c' |
| 2023-08-21 04:48:58 +0200 | <lambdabot> | GHC.Prim.Char# -> Char |
| 2023-08-21 04:49:16 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 260 seconds) |
| 2023-08-21 04:49:36 +0200 | mikoto-chan | (~mikoto-ch@85-76-111-77-nat.elisa-mobile.fi) (Ping timeout: 245 seconds) |
| 2023-08-21 04:50:04 +0200 | <int-e> | That's a compile time constant, so it'll be *a* statically allocated 'c'. I'm not sure that those are shared across modules. |
| 2023-08-21 04:50:34 +0200 | <EvanR> | I would never presume to suggest they were! |
| 2023-08-21 04:50:52 +0200 | justsomeguy | (justsomegu@user/justsomeguy) |
| 2023-08-21 04:50:59 +0200 | <int-e> | But I meant actually using C# as a function with unknown argument. |
| 2023-08-21 04:51:07 +0200 | <EvanR> | sure |
| 2023-08-21 04:51:44 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-08-21 04:51:44 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-08-21 04:51:44 +0200 | finn_elija | FinnElija |
| 2023-08-21 04:54:48 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 246 seconds) |
| 2023-08-21 04:55:09 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2023-08-21 04:57:10 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-21 05:00:50 +0200 | jargon | (~jargon@174-22-213-62.phnx.qwest.net) |
| 2023-08-21 05:01:40 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 256 seconds) |
| 2023-08-21 05:02:28 +0200 | jmcantrell | (~weechat@user/jmcantrell) |
| 2023-08-21 05:03:26 +0200 | <wroathe> | int-e: using lazy text instead of strict text resulted in 27% fewer allocations in that dropWhile implementation |
| 2023-08-21 05:04:11 +0200 | <wroathe> | From 2,717,358,616 bytes down to 1,969,361,672 |
| 2023-08-21 05:04:56 +0200 | aforemny | (~aforemny@i59F516C9.versanet.de) (Ping timeout: 246 seconds) |
| 2023-08-21 05:05:12 +0200 | <EvanR> | lazy readFile will do lazy I/O (like I originally suggested) |
| 2023-08-21 05:05:33 +0200 | <EvanR> | though the parsing still kind defeats some of the benefit |
| 2023-08-21 05:05:52 +0200 | aforemny | (~aforemny@2001:9e8:6cd8:3100:c980:385d:6185:8dda) |
| 2023-08-21 05:07:27 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Quit: Leaving) |
| 2023-08-21 05:10:52 +0200 | <int-e> | EvanR: on the other hand, String literals (unpackCString#) and IO (like getContents) share the same table of "low" characters. |
| 2023-08-21 05:12:52 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 244 seconds) |
| 2023-08-21 05:16:20 +0200 | shapr | (~user@2600:1700:c640:3100:6898:ed8d:7f5e:e726) (Remote host closed the connection) |
| 2023-08-21 05:16:55 +0200 | shapr | (~user@2600:1700:c640:3100:2ac6:30d3:17d6:81ff) |
| 2023-08-21 05:18:33 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 244 seconds) |
| 2023-08-21 05:23:56 +0200 | libertyprime | (~libertypr@203.96.203.44) (Ping timeout: 248 seconds) |
| 2023-08-21 05:27:07 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-21 05:27:07 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2023-08-21 05:32:22 +0200 | libertyprime | (~libertypr@203.96.203.44) |
| 2023-08-21 05:34:32 +0200 | justsomeguy | (justsomegu@user/justsomeguy) (Ping timeout: 245 seconds) |
| 2023-08-21 05:40:12 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2023-08-21 05:47:31 +0200 | ddellacosta | (~ddellacos@146.70.171.136) (Ping timeout: 245 seconds) |
| 2023-08-21 05:49:33 +0200 | ddellacosta | (~ddellacos@146.70.168.136) |
| 2023-08-21 05:50:12 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::85eb) (Remote host closed the connection) |
| 2023-08-21 05:50:58 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::a0f6) |
| 2023-08-21 05:54:59 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2023-08-21 06:00:32 +0200 | actioninja | (~actioninj@user/actioninja) (Quit: see ya mane) |
| 2023-08-21 06:00:57 +0200 | actioninja | (~actioninj@user/actioninja) |
| 2023-08-21 06:05:37 +0200 | g | (~glguy@libera/staff-emeritus/glguy) (Remote host closed the connection) |
| 2023-08-21 06:05:44 +0200 | g | (~glguy@libera/staff-emeritus/glguy) |
| 2023-08-21 06:06:40 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-08-21 06:07:29 +0200 | g | (~glguy@libera/staff-emeritus/glguy) (Remote host closed the connection) |
| 2023-08-21 06:07:37 +0200 | g | (g@libera/staff-emeritus/glguy) |
| 2023-08-21 06:23:29 +0200 | jargon | (~jargon@174-22-213-62.phnx.qwest.net) (Remote host closed the connection) |
| 2023-08-21 06:23:46 +0200 | razetime | (~quassel@117.254.37.117) (Ping timeout: 245 seconds) |
| 2023-08-21 06:24:48 +0200 | mvk | (~mvk@2607:fea8:5c9a:a600::1c6d) (Ping timeout: 246 seconds) |
| 2023-08-21 06:26:12 +0200 | jmcantrell | (~weechat@user/jmcantrell) (Quit: WeeChat 4.0.3) |
| 2023-08-21 06:53:09 +0200 | libertyprime | (~libertypr@203.96.203.44) (Ping timeout: 246 seconds) |
| 2023-08-21 06:56:18 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-21 07:00:30 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 2023-08-21 07:01:47 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::a0f6) (Remote host closed the connection) |
| 2023-08-21 07:02:05 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::85eb) |
| 2023-08-21 07:11:12 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) (Quit: Leaving) |
| 2023-08-21 07:11:26 +0200 | bjin | (~bjin@user/bjin) |
| 2023-08-21 07:15:59 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-21 07:20:22 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 2023-08-21 07:28:23 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-21 07:32:32 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 240 seconds) |
| 2023-08-21 07:34:28 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:bc38:61d8:7af5:2488) (Remote host closed the connection) |
| 2023-08-21 07:35:37 +0200 | jonathan__ | (~jonathan@193.203.13.94) |
| 2023-08-21 07:36:01 +0200 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
| 2023-08-21 07:37:12 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-08-21 07:41:13 +0200 | chele | (~chele@user/chele) |
| 2023-08-21 07:48:55 +0200 | michalz | (~michalz@185.246.207.222) |
| 2023-08-21 07:53:30 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 246 seconds) |
| 2023-08-21 07:55:04 +0200 | NewtonTrendy | (uid282092@user/bopqod) (Quit: Connection closed for inactivity) |
| 2023-08-21 08:08:29 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-08-21 08:08:42 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::85eb) (Ping timeout: 258 seconds) |
| 2023-08-21 08:09:48 +0200 | mikoto-chan | (~mikoto-ch@85-76-50-50-nat.elisa-mobile.fi) |
| 2023-08-21 08:13:19 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Remote host closed the connection) |
| 2023-08-21 08:13:59 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2023-08-21 08:15:12 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-21 08:15:49 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Read error: Connection reset by peer) |
| 2023-08-21 08:16:30 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2023-08-21 08:16:44 +0200 | shapr | (~user@2600:1700:c640:3100:2ac6:30d3:17d6:81ff) (Ping timeout: 248 seconds) |
| 2023-08-21 08:16:59 +0200 | acidjnk | (~acidjnk@p200300d6e7072f62514217c34acbe695.dip0.t-ipconnect.de) |
| 2023-08-21 08:19:32 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 2023-08-21 08:21:42 +0200 | YuutaW | (~YuutaW@mail.yuuta.moe) (Ping timeout: 256 seconds) |
| 2023-08-21 08:24:17 +0200 | razetime | (~quassel@117.254.37.117) |
| 2023-08-21 08:25:20 +0200 | YuutaW | (~YuutaW@mail.yuuta.moe) |
| 2023-08-21 08:35:30 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-21 08:35:38 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-08-21 08:37:44 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 246 seconds) |
| 2023-08-21 08:38:26 +0200 | paddymahoney | (~paddymaho@cpe883d24bcf597-cmbc4dfb741f80.cpe.net.cable.rogers.com) (Ping timeout: 246 seconds) |
| 2023-08-21 08:40:06 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 250 seconds) |
| 2023-08-21 08:40:39 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Quit: Leaving) |
| 2023-08-21 08:43:56 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:cc65:1a3b:6ab3:49f4) |
| 2023-08-21 08:47:49 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-21 08:48:15 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-08-21 08:52:10 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Ping timeout: 246 seconds) |
| 2023-08-21 08:52:31 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 246 seconds) |
| 2023-08-21 08:52:34 +0200 | fendor | (~fendor@2a02:8388:1640:be00:b586:6c06:a58:19a3) |
| 2023-08-21 08:58:35 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-08-21 09:03:02 +0200 | ensyde | (ensyde@2600:3c02::f03c:93ff:fe9e:b831) |
| 2023-08-21 09:06:41 +0200 | mikoto-chan | (~mikoto-ch@85-76-50-50-nat.elisa-mobile.fi) (Ping timeout: 245 seconds) |
| 2023-08-21 09:07:37 +0200 | bliminse | (~bliminse@user/bliminse) (Quit: leaving) |
| 2023-08-21 09:10:21 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 246 seconds) |
| 2023-08-21 09:10:28 +0200 | rune__ | (sid21167@ilkley.irccloud.com) |
| 2023-08-21 09:11:13 +0200 | rune__ | (sid21167@ilkley.irccloud.com) (Client Quit) |
| 2023-08-21 09:14:57 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-08-21 09:17:00 +0200 | dibblego | (~dibblego@116-255-1-151.ip4.superloop.au) |
| 2023-08-21 09:17:00 +0200 | dibblego | (~dibblego@116-255-1-151.ip4.superloop.au) (Changing host) |
| 2023-08-21 09:17:00 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-08-21 09:19:11 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-209-157.dsl.scarlet.be) |
| 2023-08-21 09:19:23 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2023-08-21 09:21:54 +0200 | gastus | (~gastus@185.6.123.186) (Ping timeout: 244 seconds) |
| 2023-08-21 09:22:34 +0200 | Pickchea | (~private@user/pickchea) |
| 2023-08-21 09:26:11 +0200 | CiaoSen | (~Jura@2a05:5800:2d6:1600:664b:f0ff:fe37:9ef) |
| 2023-08-21 09:37:06 +0200 | ft | (~ft@p4fc2ad78.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2023-08-21 09:37:32 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-209-157.dsl.scarlet.be) (Ping timeout: 252 seconds) |
| 2023-08-21 09:41:02 +0200 | misterfish | (~misterfis@87.215.131.102) |
| 2023-08-21 09:43:10 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-21 09:43:26 +0200 | bliminse | (~bliminse@user/bliminse) |
| 2023-08-21 09:44:52 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 240 seconds) |
| 2023-08-21 09:46:46 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.2) |
| 2023-08-21 09:47:52 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 245 seconds) |
| 2023-08-21 09:48:56 +0200 | ft | (~ft@p4fc2ad78.dip0.t-ipconnect.de) |
| 2023-08-21 09:49:16 +0200 | wrengr | (~wrengr@201.59.83.34.bc.googleusercontent.com) (Remote host closed the connection) |
| 2023-08-21 09:49:43 +0200 | gensyst | (~gensyst@user/gensyst) |
| 2023-08-21 09:49:47 +0200 | <gensyst> | I have tons of these: "newtype Lol = Lol Float", "newtype Rofl = Rofl Float". |
| 2023-08-21 09:49:47 +0200 | <gensyst> | When extracting, I'm always doing "(let Lol x = lol in x)", "(let Rofl x = rofl in x)", etc. |
| 2023-08-21 09:49:47 +0200 | <gensyst> | Is it possible to have one general extraction function that works for all newtypes? |
| 2023-08-21 09:50:02 +0200 | dibblego | (~dibblego@116-255-1-151.ip4.superloop.au) |
| 2023-08-21 09:50:02 +0200 | dibblego | (~dibblego@116-255-1-151.ip4.superloop.au) (Changing host) |
| 2023-08-21 09:50:02 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-08-21 09:52:30 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-209-157.dsl.scarlet.be) |
| 2023-08-21 09:52:43 +0200 | <opqdonut> | gensyst: you can define your own class, or use one of the solutions on hackage like https://hackage.haskell.org/package/newtype |
| 2023-08-21 09:53:01 +0200 | mima | (~mmh@aftr-62-216-211-33.dynamic.mnet-online.de) |
| 2023-08-21 09:54:03 +0200 | <probie> | gensyst: `Data.Coerce.coerce`? |
| 2023-08-21 09:54:59 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Remote host closed the connection) |
| 2023-08-21 09:55:37 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 2023-08-21 09:58:22 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-08-21 09:59:30 +0200 | <dminuoso> | gensyst: Also, newtypes can have field accessors. So you can also write something like `newtype Lol = Lol { unLol :: Float }`, that can help some as well. |
| 2023-08-21 10:00:22 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-08-21 10:02:10 +0200 | <dminuoso> | If you're using Lens, Control.Lens.Wrapped might be interesting to look at as well. You could also consider Generics (Control.Lens.Wrapped.Wrapped has a default implementation to look at) |
| 2023-08-21 10:04:23 +0200 | notzmv | (~zmv@user/notzmv) |
| 2023-08-21 10:11:18 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2023-08-21 10:11:44 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-08-21 10:12:23 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-08-21 10:12:46 +0200 | califax | (~califax@user/califx) |
| 2023-08-21 10:15:22 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 245 seconds) |
| 2023-08-21 10:15:56 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-21 10:20:49 +0200 | dibblego | (~dibblego@116-255-1-151.ip4.superloop.au) |
| 2023-08-21 10:20:49 +0200 | dibblego | (~dibblego@116-255-1-151.ip4.superloop.au) (Changing host) |
| 2023-08-21 10:20:49 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-08-21 10:20:59 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-21 10:21:55 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 2023-08-21 10:24:00 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:cc65:1a3b:6ab3:49f4) (Ping timeout: 246 seconds) |
| 2023-08-21 10:30:42 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:a6c1:e36f:a7ec:e7e5) |
| 2023-08-21 10:35:41 +0200 | razetime | (~quassel@117.254.37.117) (Ping timeout: 246 seconds) |
| 2023-08-21 10:35:50 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Ping timeout: 252 seconds) |
| 2023-08-21 10:38:02 +0200 | turlando | (~turlando@user/turlando) |
| 2023-08-21 10:40:48 +0200 | cyphase_eviltwin | (~cyphase@user/cyphase) |
| 2023-08-21 10:40:57 +0200 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 244 seconds) |
| 2023-08-21 10:44:31 +0200 | <fendor> | I am working through https://blog.sumtypeofway.com/posts/introduction-to-recursion-schemes.html. the advantage of `newtype Term f = In (f (Term f))` is that I can derive, foldable, etc... |
| 2023-08-21 10:44:38 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 252 seconds) |
| 2023-08-21 10:45:25 +0200 | <fendor> | but I seem to be loosing the ability to derive Show for types Expr where `type Expr = Term ExprF`. Can I still derive Show somehow? |
| 2023-08-21 10:47:32 +0200 | <[Leary]> | fendor: `deriving instance Show (f (Term f)) => Show (Term f)`, with StandaloneDeriving and perhaps UndecidableInstances. |
| 2023-08-21 10:49:51 +0200 | <fendor> | I am a bit weary of UndecidableInstances in my code... but I suppose, it is fine in this particular instance |
| 2023-08-21 10:51:02 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::85eb) |
| 2023-08-21 10:51:57 +0200 | <probie> | You probably want to define `Show1` (from `Data.Functor.Classes` https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-Functor-Classes.html) |
| 2023-08-21 10:53:18 +0200 | <c_wraith> | UndecidableInstances is harmless. If it ends up in a loop trying to figure something out, it gives an error message instead of compiling incorrectly or something |
| 2023-08-21 10:56:31 +0200 | razetime | (~quassel@117.254.37.117) |
| 2023-08-21 10:59:08 +0200 | gensyst | (~gensyst@user/gensyst) (Ping timeout: 246 seconds) |
| 2023-08-21 11:03:08 +0200 | danse-nr3 | (~francesco@151.47.152.232) |
| 2023-08-21 11:03:38 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-21 11:07:11 +0200 | <fendor> | it might be harmless, but unless you understand why you need it, you might run into issues later |
| 2023-08-21 11:11:57 +0200 | <fendor> | probie, thanks! |
| 2023-08-21 11:14:14 +0200 | Square | (~Square4@user/square) |
| 2023-08-21 11:14:26 +0200 | <c_wraith> | You have to try really hard to run into problems with it. You basically need to be writing fundep prolog to get UndecidableInstances to loop indefinitely |
| 2023-08-21 11:16:03 +0200 | <fendor> | iirc, I encountered issues that I couldn't actually write the instances I wanted, even though it fixed my initial type error |
| 2023-08-21 11:16:36 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Quit: Leaving) |
| 2023-08-21 11:17:14 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-21 11:19:30 +0200 | <[Leary]> | fendor: In order to ensure instance resolution finishes within a finite number of steps, Haskell imposes the (overly strong) restriction that constraints on an instance must be smaller (in some precise sense) than the instance head. UndecidableInstances just lifts that restriction. |
| 2023-08-21 11:20:10 +0200 | <c_wraith> | ah, well. There certainly are instances that don't work even with it on. |
| 2023-08-21 11:21:00 +0200 | <c_wraith> | Even though GHC tells you enabling it will help - it only helps with one specific thing, and several might apply at the same time. |
| 2023-08-21 11:22:07 +0200 | <fendor> | exactly |
| 2023-08-21 11:22:28 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 256 seconds) |
| 2023-08-21 11:30:19 +0200 | ft | (~ft@p4fc2ad78.dip0.t-ipconnect.de) (Quit: leaving) |
| 2023-08-21 11:35:41 +0200 | danse-nr3 | (~francesco@151.47.152.232) (Ping timeout: 248 seconds) |
| 2023-08-21 11:37:54 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:d4d1:1f75:43b9:b6be) |
| 2023-08-21 11:42:03 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:d4d1:1f75:43b9:b6be) (Ping timeout: 246 seconds) |
| 2023-08-21 11:45:10 +0200 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-08-21 11:46:45 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 246 seconds) |
| 2023-08-21 11:47:32 +0200 | Pickchea | (~private@user/pickchea) |
| 2023-08-21 11:52:03 +0200 | danse-nr3 | (~francesco@151.47.152.232) |
| 2023-08-21 11:55:05 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2023-08-21 11:55:32 +0200 | td_ | (~td@i53870925.versanet.de) (Ping timeout: 250 seconds) |
| 2023-08-21 12:03:09 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-08-21 12:05:34 +0200 | ensyde | (ensyde@2600:3c02::f03c:93ff:fe9e:b831) (Quit: WeeChat 4.0.3) |
| 2023-08-21 12:07:36 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 246 seconds) |
| 2023-08-21 12:10:44 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::85eb) (Remote host closed the connection) |
| 2023-08-21 12:11:03 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::c972) |
| 2023-08-21 12:11:13 +0200 | bjin | (~bjin@user/bjin) (Leaving) |
| 2023-08-21 12:17:20 +0200 | td_ | (~td@i5387092A.versanet.de) |
| 2023-08-21 12:23:51 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-08-21 12:24:32 +0200 | CiaoSen | (~Jura@2a05:5800:2d6:1600:664b:f0ff:fe37:9ef) (Ping timeout: 246 seconds) |
| 2023-08-21 12:27:16 +0200 | lottaquestions | (~nick@2607:fa49:503d:b200:5a77:1161:fea9:1c25) |
| 2023-08-21 12:28:49 +0200 | td_ | (~td@i5387092A.versanet.de) (Ping timeout: 246 seconds) |
| 2023-08-21 12:35:15 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::c972) (Remote host closed the connection) |
| 2023-08-21 12:35:32 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::2cf5) |
| 2023-08-21 12:36:18 +0200 | ripspin | (~chatzilla@1.145.138.142) |
| 2023-08-21 12:39:23 +0200 | shriekingnoise | (~shrieking@186.137.175.87) (Quit: Quit) |
| 2023-08-21 12:51:38 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-08-21 12:58:48 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 250 seconds) |
| 2023-08-21 12:59:37 +0200 | xff0x | (~xff0x@2405:6580:b080:900:519f:cf85:d2f3:6c08) |
| 2023-08-21 13:01:42 +0200 | acidjnk | (~acidjnk@p200300d6e7072f62514217c34acbe695.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2023-08-21 13:04:42 +0200 | acidjnk | (~acidjnk@p200300d6e7072f62bd26c55050e04c1c.dip0.t-ipconnect.de) |
| 2023-08-21 13:09:00 +0200 | vglfr | (~vglfr@cli-188-239-201-89.bbn.slav.dn.ua) (Ping timeout: 256 seconds) |
| 2023-08-21 13:09:45 +0200 | acidjnk | (~acidjnk@p200300d6e7072f62bd26c55050e04c1c.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2023-08-21 13:10:52 +0200 | td_ | (~td@i5387093F.versanet.de) |
| 2023-08-21 13:17:16 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-209-157.dsl.scarlet.be) (Quit: WeeChat 3.8) |
| 2023-08-21 13:20:44 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-08-21 13:22:02 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 260 seconds) |
| 2023-08-21 13:25:08 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-21 13:32:30 +0200 | td_ | (~td@i5387093F.versanet.de) (Ping timeout: 246 seconds) |
| 2023-08-21 13:36:07 +0200 | Guest12 | (~Guest44@176.122.87.241) |
| 2023-08-21 13:39:21 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:d4d1:1f75:43b9:b6be) |
| 2023-08-21 13:39:22 +0200 | td_ | (~td@i5387092D.versanet.de) |
| 2023-08-21 13:43:42 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:d4d1:1f75:43b9:b6be) (Ping timeout: 245 seconds) |
| 2023-08-21 13:45:23 +0200 | <Guest12> | hello |
| 2023-08-21 13:46:09 +0200 | danse-nr3 | (~francesco@151.47.152.232) (Ping timeout: 246 seconds) |
| 2023-08-21 13:46:35 +0200 | <Guest12> | https://paste.tomsmeding.com/orqoheRZ |
| 2023-08-21 13:48:06 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) (Ping timeout: 256 seconds) |
| 2023-08-21 13:49:59 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2023-08-21 13:50:12 +0200 | <Guest12> | is it possible to specify a "specific" SomeType for Message content? or just don't use SomeType? https://paste.tomsmeding.com/MvCm3vC8 |
| 2023-08-21 13:51:11 +0200 | Guest12 | (~Guest44@176.122.87.241) (Quit: Client closed) |
| 2023-08-21 13:51:29 +0200 | Guest92 | (~Guest44@176.122.87.241) |
| 2023-08-21 13:52:57 +0200 | razetime | (~quassel@117.254.37.117) (Ping timeout: 260 seconds) |
| 2023-08-21 13:54:07 +0200 | danse-nr3 | (~francesco@151.47.152.232) |
| 2023-08-21 13:54:32 +0200 | td_ | (~td@i5387092D.versanet.de) (Ping timeout: 240 seconds) |
| 2023-08-21 13:56:03 +0200 | kuribas | (~user@2a02:1808:87:3737:23f8:531e:6ce4:5065) |
| 2023-08-21 13:56:42 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-21 13:56:42 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2023-08-21 14:03:34 +0200 | SegmentationFaul | (~Segmentat@185.151.84.54) |
| 2023-08-21 14:04:02 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds) |
| 2023-08-21 14:07:07 +0200 | td_ | (~td@83.135.9.23) |
| 2023-08-21 14:08:29 +0200 | Inst | (~liamzy@2601:6c4:4085:6d50::2cf5) (Ping timeout: 246 seconds) |
| 2023-08-21 14:15:26 +0200 | <exarkun> | I tried to write a unit-y test for custom TLS settings for use with http-client-tls (by submitting the configuration and then asking http-client's "manager" to make a connection to a server the tests run, and asserting something about the result of the connection attempt) but I have now run into the issue that the http-client's Connection type is internal (but exposed ... so ... fine I guess) and |
| 2023-08-21 14:15:28 +0200 | <exarkun> | also missing basic functionality, like a Show instance. Am I barking up the wrong tree? |
| 2023-08-21 14:15:42 +0200 | danse-nr3 | (~francesco@151.47.152.232) (Ping timeout: 246 seconds) |
| 2023-08-21 14:16:44 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-08-21 14:17:30 +0200 | kitzman | (~kitzman@user/dekenevs) (Quit: C-x C-c) |
| 2023-08-21 14:18:11 +0200 | Guest92 | (~Guest44@176.122.87.241) (Quit: Client closed) |
| 2023-08-21 14:18:15 +0200 | danse-nr3 | (~francesco@151.47.152.232) |
| 2023-08-21 14:19:29 +0200 | kitzman | (~kitzman@user/dekenevs) |
| 2023-08-21 14:19:31 +0200 | razetime | (~quassel@117.254.37.117) |
| 2023-08-21 14:24:18 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 246 seconds) |
| 2023-08-21 14:26:42 +0200 | dibblego | (~dibblego@116.255.1.151) |
| 2023-08-21 14:26:42 +0200 | dibblego | (~dibblego@116.255.1.151) (Changing host) |
| 2023-08-21 14:26:42 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-08-21 14:31:28 +0200 | ripspin | (~chatzilla@1.145.138.142) (Remote host closed the connection) |
| 2023-08-21 14:34:48 +0200 | SegmentationFaul | (~Segmentat@185.151.84.54) (Quit: Client closed) |
| 2023-08-21 14:40:36 +0200 | falafel | (~falafel@216.68.6.51.dyn.plus.net) |
| 2023-08-21 14:47:13 +0200 | ph88 | (~ph88@ip5b403cd4.dynamic.kabel-deutschland.de) |
| 2023-08-21 14:47:32 +0200 | <ph88> | how can i run Control.Monad.Fail ? either with Either or with exception |
| 2023-08-21 14:48:16 +0200 | <ph88> | oh nvm i guess i can turn it into Maybe |
| 2023-08-21 14:49:32 +0200 | razetime | (~quassel@117.254.37.117) (Ping timeout: 245 seconds) |
| 2023-08-21 14:54:20 +0200 | <ncf> | > fail "boo" :: Either String () |
| 2023-08-21 14:54:21 +0200 | <lambdabot> | error: |
| 2023-08-21 14:54:21 +0200 | <lambdabot> | • No instance for (MonadFail (Either String)) |
| 2023-08-21 14:54:21 +0200 | <lambdabot> | arising from a use of ‘fail’ |
| 2023-08-21 14:54:50 +0200 | <ncf> | rip |
| 2023-08-21 14:57:00 +0200 | <ncf> | https://gitlab.haskell.org/ghc/ghc/-/issues/12160 |
| 2023-08-21 15:01:24 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-08-21 15:02:16 +0200 | danse-nr3 | (~francesco@151.47.152.232) (Read error: Connection reset by peer) |
| 2023-08-21 15:02:46 +0200 | danse-nr3 | (~francesco@151.37.126.103) |
| 2023-08-21 15:09:46 +0200 | <albet70> | how to construct an IO String reading element from a list one by one? |
| 2023-08-21 15:11:27 +0200 | <ncf> | IORef? |
| 2023-08-21 15:15:30 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 245 seconds) |
| 2023-08-21 15:19:00 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-21 15:23:15 +0200 | kuribas` | (~user@2a02:1808:1:281d:be13:5348:8276:dbb0) |
| 2023-08-21 15:23:50 +0200 | ystael | (~ystael@user/ystael) |
| 2023-08-21 15:24:24 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 2023-08-21 15:25:06 +0200 | kuribas | (~user@2a02:1808:87:3737:23f8:531e:6ce4:5065) (Ping timeout: 260 seconds) |
| 2023-08-21 15:27:54 +0200 | ccapndave | (~ccapndave@xcpe-62-167-165-47.cgn.res.adslplus.ch) |
| 2023-08-21 15:28:57 +0200 | hgolden | (~hgolden@2603-8000-9d00-3ed1-fc05-5499-f77c-fbe5.res6.spectrum.com) (Remote host closed the connection) |
| 2023-08-21 15:31:16 +0200 | SegmentationFaul | (~Segmentat@185.151.84.54) |
| 2023-08-21 15:32:06 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 252 seconds) |
| 2023-08-21 15:35:17 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-21 15:36:20 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-21 15:36:54 +0200 | falafel | (~falafel@216.68.6.51.dyn.plus.net) (Ping timeout: 246 seconds) |
| 2023-08-21 15:38:55 +0200 | <xerox> | elements being? |
| 2023-08-21 15:40:11 +0200 | ccapndave | (~ccapndave@xcpe-62-167-165-47.cgn.res.adslplus.ch) (Quit: Textual IRC Client: www.textualapp.com) |
| 2023-08-21 15:40:32 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-08-21 15:40:32 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-08-21 15:40:32 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-08-21 15:40:36 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 2023-08-21 15:43:58 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2023-08-21 15:44:21 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-08-21 15:45:05 +0200 | danse-nr3 | (~francesco@151.37.126.103) (Ping timeout: 245 seconds) |
| 2023-08-21 15:49:38 +0200 | danse-nr3 | (~francesco@151.37.126.103) |
| 2023-08-21 15:52:20 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-08-21 15:55:55 +0200 | ripspin | (~chatzilla@1.145.177.194) |
| 2023-08-21 15:56:21 +0200 | kuribas` | (~user@2a02:1808:1:281d:be13:5348:8276:dbb0) (Ping timeout: 246 seconds) |
| 2023-08-21 15:59:04 +0200 | ddellacosta | (~ddellacos@146.70.168.136) (Ping timeout: 250 seconds) |
| 2023-08-21 16:01:52 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2023-08-21 16:05:11 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-08-21 16:08:34 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-08-21 16:10:07 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-21 16:11:53 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Client Quit) |
| 2023-08-21 16:14:12 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-21 16:23:14 +0200 | Ram-Z | (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) (Ping timeout: 246 seconds) |
| 2023-08-21 16:23:15 +0200 | jonathan | (~jonathan@193.203.13.94) |
| 2023-08-21 16:23:41 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-21 16:23:41 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2023-08-21 16:29:03 +0200 | Ram-Z | (~Ram-Z@li1814-254.members.linode.com) |
| 2023-08-21 16:31:12 +0200 | m21it | (~m21it@2800:ac:c020:f24b:2278:812f:509e:9a2f) |
| 2023-08-21 16:34:52 +0200 | <m21it> | Hello! I'm writing some instances for the Data.Data.Data class and I can not understand how `toConstr` and `dataTypeOf` could actually work, because they do seem recursively depend on each other through the `DataRep`. |
| 2023-08-21 16:35:06 +0200 | <m21it> | https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.Data.html#DataType |
| 2023-08-21 16:36:37 +0200 | <m21it> | I did some tests `x `shouldBe` Data.fromConstr (Data.toConstr x)` but it seems to be non-terminating due to infinite recursion |
| 2023-08-21 16:39:37 +0200 | Ram-Z | (~Ram-Z@li1814-254.members.linode.com) (Quit: ZNC - http://znc.in) |
| 2023-08-21 16:41:24 +0200 | <m21it> | It seems to be Constr does depend on DataType does depend on DataRep does depend of Constr.. |
| 2023-08-21 16:41:28 +0200 | Ram-Z | (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) |
| 2023-08-21 16:42:03 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Quit: Leaving) |
| 2023-08-21 16:42:24 +0200 | acidjnk | (~acidjnk@p200300d6e7072f62b0c5e6199a92dfb8.dip0.t-ipconnect.de) |
| 2023-08-21 16:46:31 +0200 | thegeekinside | (~thegeekin@189.180.79.225) |
| 2023-08-21 16:50:52 +0200 | jonathan | (~jonathan@193.203.13.94) (Quit: Leaving) |
| 2023-08-21 16:51:04 +0200 | srk- | (~sorki@user/srk) |
| 2023-08-21 16:54:58 +0200 | srk | (~sorki@user/srk) (Ping timeout: 252 seconds) |
| 2023-08-21 16:54:58 +0200 | srk- | srk |
| 2023-08-21 16:55:06 +0200 | misterfish | (~misterfis@87.215.131.102) (Ping timeout: 256 seconds) |
| 2023-08-21 16:55:48 +0200 | random-jellyfish | (~random-je@user/random-jellyfish) |
| 2023-08-21 17:02:16 +0200 | <random-jellyfish> | is there a way to convert an imperative algorithm with if statements, while/for loops, break statements, case statements etc. into finite state machine algorithm? |
| 2023-08-21 17:02:32 +0200 | <random-jellyfish> | is there like a standard way that I can read about and reuse? |
| 2023-08-21 17:04:19 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-08-21 17:04:56 +0200 | ripspin | (~chatzilla@1.145.177.194) (Ping timeout: 250 seconds) |
| 2023-08-21 17:05:42 +0200 | dsfsdfsdf | (~dsfsdfsdf@ip4d148080.dynamic.kabel-deutschland.de) |
| 2023-08-21 17:06:11 +0200 | <m21it> | random-jellyfish: yes, StateT monad transformer |
| 2023-08-21 17:07:19 +0200 | <m21it> | random-jellyfish: and if you need more imperative features than just state, you could use other transformers like for example ExceptT for early return/brake |
| 2023-08-21 17:07:42 +0200 | <random-jellyfish> | can it be implemented in other languages? e.g. CommonLisp? |
| 2023-08-21 17:07:54 +0200 | dsfsdfsdf | (~dsfsdfsdf@ip4d148080.dynamic.kabel-deutschland.de) (Client Quit) |
| 2023-08-21 17:08:41 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-08-21 17:09:21 +0200 | gatekempt | (~gatekempt@user/gatekempt) |
| 2023-08-21 17:10:12 +0200 | <m21it> | It depends, I don't know. Monads and monad transformers do depend on ad-hoc polymorphism (type classes) and higher-order types. In other languages there will be other instruments |
| 2023-08-21 17:10:31 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-08-21 17:14:36 +0200 | <[Leary]> | m21it: Mutual recursion (whether of values or data types) is not inherently problematic. The docs for the class show what a GHC generated instance looks like, and you can see it ties a knot with `con_C1`, `con_C2` and `ty_T`---this is fine, so long as `mkConstr` and `mkDataType` are not strict in these arguments. |
| 2023-08-21 17:14:44 +0200 | <[Leary]> | > (fromConstr . toConstr :: Data a => a -> a) <$> [Nothing, Just ()] |
| 2023-08-21 17:14:46 +0200 | <lambdabot> | [Nothing,Just *Exception: Data.Data.fromConstr |
| 2023-08-21 17:16:37 +0200 | <ph88> | is there some auto fixer program that can do things like remove unused imports. replace unused variables by underscore etc ? |
| 2023-08-21 17:17:24 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-21 17:17:25 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2023-08-21 17:19:01 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:a6c1:e36f:a7ec:e7e5) (Quit: WeeChat 2.8) |
| 2023-08-21 17:21:24 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:75c0:69c6:c6bf:d46c) |
| 2023-08-21 17:21:27 +0200 | <m21it> | ph88: hlint and fourmolu are good to remove redundant stuff and do simple auto-refactorings |
| 2023-08-21 17:21:41 +0200 | ripspin | (~chatzilla@1.145.251.200) |
| 2023-08-21 17:22:17 +0200 | <ph88> | thx |
| 2023-08-21 17:30:07 +0200 | <EvanR> | express an imperative algorithm with an actual finite state machine is a more narrow objective though, not just can you write it in haskell |
| 2023-08-21 17:30:25 +0200 | <geekosaur> | https://hackage.haskell.org/package/HaRe seems a bit out of date |
| 2023-08-21 17:30:52 +0200 | <geekosaur> | but I think most of its goals have been integrated into HLS, not that that has a batch mode |
| 2023-08-21 17:32:01 +0200 | <geekosaur> | also, PSA: I just got the buggy Linux kernel on my Ubuntu 22.04.2 system, look out for more "mmap 4096 bytes" complaints |
| 2023-08-21 17:32:22 +0200 | <m21it> | geekosaur: oh, hi! You are in this chat as well :) |
| 2023-08-21 17:32:32 +0200 | <geekosaur> | (luckily I already upgraded to a GHC that works compatibly with the new kernel) |
| 2023-08-21 17:32:42 +0200 | <geekosaur> | this is actually my main chat |
| 2023-08-21 17:33:32 +0200 | Square | (~Square4@user/square) (Ping timeout: 248 seconds) |
| 2023-08-21 17:38:44 +0200 | NewtonTrendy | (uid282092@user/bopqod) |
| 2023-08-21 17:38:51 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 246 seconds) |
| 2023-08-21 17:41:00 +0200 | <[Leary]> | random-jellyfish: Seems like FSM aren't Turing complete, so an imperative language with while loops is probably too powerful to be translated. |
| 2023-08-21 17:42:02 +0200 | <EvanR> | yeah, the loops are the fundamental issue. But also imperative code often has int variables, which starts to stretch the definition of Finite State |
| 2023-08-21 17:42:09 +0200 | rembo10 | (~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-08-21 17:42:20 +0200 | <EvanR> | 4 ints is 2^(4*64) states |
| 2023-08-21 17:42:28 +0200 | rembo10 | (~rembo10@main.remulis.com) |
| 2023-08-21 17:43:04 +0200 | sefidel | (~sefidel@user/sefidel) (Ping timeout: 244 seconds) |
| 2023-08-21 17:43:11 +0200 | <random-jellyfish> | yeah it's true some cases might not be translatable |
| 2023-08-21 17:43:20 +0200 | sefidel | (~sefidel@user/sefidel) |
| 2023-08-21 17:47:58 +0200 | random-jellyfish | (~random-je@user/random-jellyfish) (Quit: Client closed) |
| 2023-08-21 17:52:40 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2023-08-21 17:53:33 +0200 | ripspin | (~chatzilla@1.145.251.200) (Remote host closed the connection) |
| 2023-08-21 17:56:05 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2023-08-21 17:56:59 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2023-08-21 17:57:23 +0200 | Ram-Z | (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) (Quit: ZNC - http://znc.in) |
| 2023-08-21 17:59:26 +0200 | Ram-Z | (~Ram-Z@li1814-254.members.linode.com) |
| 2023-08-21 18:00:08 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2023-08-21 18:01:04 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2023-08-21 18:02:19 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 2023-08-21 18:05:01 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2023-08-21 18:05:36 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-08-21 18:05:52 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 2023-08-21 18:06:31 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Client Quit) |
| 2023-08-21 18:06:51 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-08-21 18:11:28 +0200 | gmg | (~user@user/gehmehgeh) |
| 2023-08-21 18:16:56 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2023-08-21 18:16:58 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-21 18:17:33 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2023-08-21 18:19:34 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Client Quit) |
| 2023-08-21 18:22:13 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-08-21 18:22:41 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-08-21 18:22:58 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2023-08-21 18:23:36 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2023-08-21 18:24:23 +0200 | razetime | (~quassel@117.254.37.154) |
| 2023-08-21 18:24:36 +0200 | thegeekinside | (~thegeekin@189.180.79.225) (Ping timeout: 245 seconds) |
| 2023-08-21 18:25:21 +0200 | thegeekinside | (~thegeekin@189.180.79.225) |
| 2023-08-21 18:25:30 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 245 seconds) |
| 2023-08-21 18:25:55 +0200 | woffs | (3cd46299b2@woffs.de) |
| 2023-08-21 18:37:02 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 245 seconds) |
| 2023-08-21 18:39:32 +0200 | m21it | (~m21it@2800:ac:c020:f24b:2278:812f:509e:9a2f) (Remote host closed the connection) |
| 2023-08-21 18:40:02 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-21 18:40:03 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2023-08-21 18:42:39 +0200 | vglfr | (~vglfr@145.224.100.231) |
| 2023-08-21 18:43:06 +0200 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) |
| 2023-08-21 18:43:55 +0200 | SegmentationFaul | (~Segmentat@185.151.84.54) (Quit: Client closed) |
| 2023-08-21 18:44:25 +0200 | vglfr | (~vglfr@145.224.100.231) (Read error: Connection reset by peer) |
| 2023-08-21 18:44:35 +0200 | vglfr | (~vglfr@145.224.100.231) |
| 2023-08-21 18:46:42 +0200 | vglfr | (~vglfr@145.224.100.231) (Read error: Connection reset by peer) |
| 2023-08-21 18:50:53 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-21 18:51:40 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-08-21 18:52:07 +0200 | woffs | (3cd46299b2@woffs.de) () |
| 2023-08-21 18:52:14 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-08-21 18:53:41 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-08-21 19:02:38 +0200 | danse-nr3 | (~francesco@151.37.126.103) (Read error: Connection reset by peer) |
| 2023-08-21 19:03:07 +0200 | danse-nr3 | (~francesco@151.47.168.22) |
| 2023-08-21 19:04:16 +0200 | myyo | (~myyo@75-166-145-203.hlrn.qwest.net) |
| 2023-08-21 19:08:00 +0200 | razetime | (~quassel@117.254.37.154) (Ping timeout: 245 seconds) |
| 2023-08-21 19:09:44 +0200 | shapr | (~user@2600:1700:c640:3100:4414:113a:dbea:a6ec) |
| 2023-08-21 19:10:04 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) |
| 2023-08-21 19:14:30 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Ping timeout: 250 seconds) |
| 2023-08-21 19:14:30 +0200 | jmcantrell | (~weechat@user/jmcantrell) |
| 2023-08-21 19:15:31 +0200 | ars23 | (~ars23@92.81.96.66) |
| 2023-08-21 19:15:44 +0200 | ars23 | (~ars23@92.81.96.66) (Changing host) |
| 2023-08-21 19:15:44 +0200 | ars23 | (~ars23@user/ars23) |
| 2023-08-21 19:15:55 +0200 | ars23 | (~ars23@user/ars23) (Remote host closed the connection) |
| 2023-08-21 19:17:04 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2023-08-21 19:17:21 +0200 | myyo | (~myyo@75-166-145-203.hlrn.qwest.net) () |
| 2023-08-21 19:18:17 +0200 | <dminuoso> | EvanR: 2^(4*64) is quite... finite? |
| 2023-08-21 19:18:24 +0200 | <dminuoso> | It's not less finite than 10. |
| 2023-08-21 19:18:35 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) (Read error: Connection reset by peer) |
| 2023-08-21 19:18:36 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2023-08-21 19:18:48 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-21 19:20:05 +0200 | <EvanR> | and ram is finite so every algorithm is O(1) |
| 2023-08-21 19:20:26 +0200 | <dminuoso> | Well RAM is usually not part of the definition of most languages. |
| 2023-08-21 19:20:40 +0200 | <dminuoso> | So if we consider something like Integer its a different story, because its unbounded in principle. |
| 2023-08-21 19:20:44 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-21 19:20:46 +0200 | <dminuoso> | But Int is very finite. |
| 2023-08-21 19:22:15 +0200 | <mauke> | fortunately C isn't turing complete, so it is always O(1) |
| 2023-08-21 19:22:19 +0200 | <mauke> | which explains its speed |
| 2023-08-21 19:22:22 +0200 | <EvanR> | having spent time in the godot discord you have this idea that a finite state machine is a particular way of writing an imperative algorithm with if statements and for loops, which is what that discussion immediately sounded like because no one was actually talking about finite state machines |
| 2023-08-21 19:23:47 +0200 | <EvanR> | finite or not 2^256 sets of rules isn't practical |
| 2023-08-21 19:25:12 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2023-08-21 19:27:17 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2023-08-21 19:28:59 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-21 19:29:40 +0200 | <Athas> | Why is the dynamically linked binary I build with 'cabal build' 120MiB (86MiB after stripping), while the statically linked binary I build with Nix only 43MiB? |
| 2023-08-21 19:29:51 +0200 | <Athas> | Same version of GHC and almost same Hackage dependencies. |
| 2023-08-21 19:30:14 +0200 | <Athas> | Also same GHC options, unless Nix sets something unusual. |
| 2023-08-21 19:37:52 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Ping timeout: 240 seconds) |
| 2023-08-21 19:38:32 +0200 | kimiamania600 | (~65804703@user/kimiamania) |
| 2023-08-21 19:38:48 +0200 | kimiamania60 | (~65804703@user/kimiamania) (Ping timeout: 244 seconds) |
| 2023-08-21 19:38:48 +0200 | kimiamania600 | kimiamania60 |
| 2023-08-21 19:40:38 +0200 | shapr | (~user@2600:1700:c640:3100:4414:113a:dbea:a6ec) (Ping timeout: 246 seconds) |
| 2023-08-21 19:44:09 +0200 | danse-nr3 | (~francesco@151.47.168.22) (Remote host closed the connection) |
| 2023-08-21 19:44:31 +0200 | danse-nr3 | (~francesco@151.47.168.22) |
| 2023-08-21 19:47:20 +0200 | danza | (~francesco@151.47.168.22) |
| 2023-08-21 19:48:21 +0200 | ddellacosta | (~ddellacos@146.70.168.100) |
| 2023-08-21 19:50:18 +0200 | danse-nr3 | (~francesco@151.47.168.22) (Ping timeout: 246 seconds) |
| 2023-08-21 19:58:52 +0200 | <tomsmeding> | Athas: any striking differences when running this? objdump -h $EXECNAME | awk '{print $3 " " $2}' | grep '^[0-9a-f]\+ ' | sort |
| 2023-08-21 20:00:25 +0200 | teddyc | (theodorc@cassarossa.samfundet.no) (Quit: WeeChat 3.0) |
| 2023-08-21 20:01:16 +0200 | kimiamania60 | (~65804703@user/kimiamania) (Ping timeout: 245 seconds) |
| 2023-08-21 20:02:00 +0200 | <Athas> | The .text and .data sections are only half the size in the Nix-built one. |
| 2023-08-21 20:02:17 +0200 | <geekosaur> | sounds like it uses -split-sections? |
| 2023-08-21 20:02:22 +0200 | <Athas> | Which of them? |
| 2023-08-21 20:02:49 +0200 | <geekosaur> | what? |
| 2023-08-21 20:03:20 +0200 | <geekosaur> | oh. I mean nix does |
| 2023-08-21 20:03:21 +0200 | <Athas> | Is it the Nix or the cabal one that you think uses -split-sections? |
| 2023-08-21 20:03:42 +0200 | <Athas> | Is there a reason not to use -split-sections, if it makes such a large difference? |
| 2023-08-21 20:03:43 +0200 | <geekosaur> | it means the linker can do more pruning of unusede code/data |
| 2023-08-21 20:03:51 +0200 | <geekosaur> | portability, mostly |
| 2023-08-21 20:04:31 +0200 | <geekosaur> | also it's somewhat slower to build and in particuloar link |
| 2023-08-21 20:04:48 +0200 | <geekosaur> | (granted, not as horrendously slow as the old -split-objs) |
| 2023-08-21 20:05:03 +0200 | <tomsmeding> | portability across linkers or portability across loaders (running platforms)? |
| 2023-08-21 20:05:25 +0200 | <geekosaur> | neither os x nor windows supports -split-sections |
| 2023-08-21 20:05:27 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-08-21 20:06:53 +0200 | <Athas> | Presumably GHC knows which operating system it is running on. |
| 2023-08-21 20:07:48 +0200 | <geekosaur> | yes, it just whines if you use it on the wrong platform, but some people don't like that |
| 2023-08-21 20:08:18 +0200 | kimiamania600 | (~65804703@user/kimiamania) |
| 2023-08-21 20:10:47 +0200 | <geekosaur> | also it puts a lot of load on the linker, meaning you should prefer `ld.gold`, but you should anyway as there's a bug iirc in the old bfd linker that ghc tickles |
| 2023-08-21 20:16:24 +0200 | <geekosaur> | (or a non-GNU linker if you are on an ELF platform that has one) |
| 2023-08-21 20:19:11 +0200 | ph88 | (~ph88@ip5b403cd4.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2023-08-21 20:25:41 +0200 | m1dnight | (~christoph@78-22-4-67.access.telenet.be) (Read error: Connection reset by peer) |
| 2023-08-21 20:26:42 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2023-08-21 20:26:59 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 2023-08-21 20:27:24 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-08-21 20:29:19 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:75c0:69c6:c6bf:d46c) (Remote host closed the connection) |
| 2023-08-21 20:29:59 +0200 | mima | (~mmh@aftr-62-216-211-33.dynamic.mnet-online.de) (Ping timeout: 246 seconds) |
| 2023-08-21 20:31:38 +0200 | m1dnight | (~christoph@78-22-4-67.access.telenet.be) |
| 2023-08-21 20:36:31 +0200 | fendor | (~fendor@2a02:8388:1640:be00:b586:6c06:a58:19a3) (Remote host closed the connection) |
| 2023-08-21 20:38:44 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2023-08-21 20:38:59 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-08-21 20:47:34 +0200 | Pickchea | (~private@user/pickchea) |
| 2023-08-21 21:00:20 +0200 | Simikando | (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Quit: Leaving) |
| 2023-08-21 21:02:02 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2023-08-21 21:03:34 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-08-21 21:03:34 +0200 | ulysses4ever | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2023-08-21 21:04:24 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2023-08-21 21:08:33 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) |
| 2023-08-21 21:15:07 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-08-21 21:19:30 +0200 | shapr | (~user@2600:1700:c640:3100:65f2:5dc9:6ef9:713) |
| 2023-08-21 21:29:09 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-08-21 21:29:49 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-08-21 21:34:11 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 245 seconds) |
| 2023-08-21 21:49:48 +0200 | bramhaag7 | (~bramhaag@134.195.121.39) |
| 2023-08-21 21:50:55 +0200 | bramhaag | (~bramhaag@134.195.121.39) (Ping timeout: 246 seconds) |
| 2023-08-21 21:51:45 +0200 | ft | (~ft@p4fc2ad78.dip0.t-ipconnect.de) |
| 2023-08-21 21:54:12 +0200 | bramhaag7 | (~bramhaag@134.195.121.39) (Ping timeout: 260 seconds) |
| 2023-08-21 21:55:25 +0200 | bramhaag | (~bramhaag@134.195.121.39) |
| 2023-08-21 22:01:27 +0200 | jonathan__ | (~jonathan@193.203.13.94) (Remote host closed the connection) |
| 2023-08-21 22:01:52 +0200 | jonathan__ | (~jonathan@193.203.13.94) |
| 2023-08-21 22:01:58 +0200 | bramhaag | (~bramhaag@134.195.121.39) (Quit: The Lounge - https://thelounge.chat) |
| 2023-08-21 22:03:08 +0200 | bramhaag7 | (~bramhaag@198.8.58.39) |
| 2023-08-21 22:03:30 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 250 seconds) |
| 2023-08-21 22:06:13 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.2) |
| 2023-08-21 22:06:37 +0200 | econo_ | (uid147250@2a03:5180:f::2:3f32) |
| 2023-08-21 22:15:01 +0200 | Square2 | (~Square4@user/square) |
| 2023-08-21 22:15:20 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-08-21 22:17:19 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-08-21 22:25:28 +0200 | fendor | (~fendor@2a02:8388:1640:be00:b586:6c06:a58:19a3) |
| 2023-08-21 22:25:28 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 256 seconds) |
| 2023-08-21 22:26:29 +0200 | son0p | (~ff@191.104.6.44) |
| 2023-08-21 22:29:54 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 246 seconds) |
| 2023-08-21 22:30:50 +0200 | ulysses4ever | (~artem@73.145.241.240) |
| 2023-08-21 22:32:54 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Ping timeout: 246 seconds) |
| 2023-08-21 22:39:47 +0200 | artem | (~artem@73.145.241.240) |
| 2023-08-21 22:39:47 +0200 | ulysses4ever | (~artem@73.145.241.240) (Read error: Connection reset by peer) |
| 2023-08-21 22:40:10 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-08-21 22:47:41 +0200 | ulysses4ever | (~artem@73.145.241.240) |
| 2023-08-21 22:47:41 +0200 | artem | (~artem@73.145.241.240) (Read error: Connection reset by peer) |
| 2023-08-21 22:48:03 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-08-21 22:51:32 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-08-21 22:55:05 +0200 | NewtonTrendy | (uid282092@user/bopqod) (Quit: Connection closed for inactivity) |
| 2023-08-21 22:59:51 +0200 | jonathan__ | (~jonathan@193.203.13.94) (Ping timeout: 246 seconds) |
| 2023-08-21 23:03:11 +0200 | danza_ | (~francesco@151.47.175.249) |
| 2023-08-21 23:03:19 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-08-21 23:04:46 +0200 | ulysses4ever | (~artem@73.145.241.240) (Ping timeout: 260 seconds) |
| 2023-08-21 23:05:18 +0200 | danza | (~francesco@151.47.168.22) (Ping timeout: 252 seconds) |
| 2023-08-21 23:06:31 +0200 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2023-08-21 23:17:22 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-08-21 23:19:36 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-08-21 23:20:14 +0200 | Guest|16 | (~Guest|16@174.27.143.6) |
| 2023-08-21 23:22:55 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-08-21 23:28:00 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 2023-08-21 23:28:01 +0200 | falafel | (~falafel@216.68.6.51.dyn.plus.net) |
| 2023-08-21 23:35:47 +0200 | michalz | (~michalz@185.246.207.222) (Remote host closed the connection) |
| 2023-08-21 23:42:50 +0200 | jargon | (~jargon@174-22-213-62.phnx.qwest.net) |
| 2023-08-21 23:44:02 +0200 | fendor | (~fendor@2a02:8388:1640:be00:b586:6c06:a58:19a3) (Remote host closed the connection) |
| 2023-08-21 23:45:39 +0200 | ulysses4ever | (~artem@73.145.240.4) |
| 2023-08-21 23:50:34 +0200 | NewtonTrendy | (uid282092@user/bopqod) |
| 2023-08-21 23:52:08 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 2023-08-21 23:52:37 +0200 | ulysses4ever | (~artem@73.145.240.4) (Ping timeout: 260 seconds) |
| 2023-08-21 23:54:09 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine) |
| 2023-08-21 23:55:31 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2023-08-21 23:59:09 +0200 | arahael | (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 2023-08-21 23:59:26 +0200 | mjt128 | (~user@2604:3d09:3e79:f200:7249:9780:ed33:b6f3) |
