Logs on 2023-08-21 (liberachat/#haskell)
| 00:00:51 | <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. |
| 00:01:24 | <monochrom> | One can prove from the Applicative laws that `liftA2 (&&)` must not do short-circuiting. |
| 00:02:00 | → | wroathe joins (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 00:02:00 | × | wroathe quits (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 00:02:00 | → | wroathe joins (~wroathe@user/wroathe) |
| 00:02:06 | × | califax quits (~califax@user/califx) (Remote host closed the connection) |
| 00:02:14 | <wroathe> | Back. Sorry. Damn public places and their so-called "hours of operation" |
| 00:03:27 | <EvanR> | you missed some stuff https://ircbrowse.tomsmeding.com/browse/lchaskell?id=1055666#trid1055666 |
| 00:03:28 | <int-e> | wroathe: http://paste.debian.net/1289541/ |
| 00:03:41 | <int-e> | hah, redundant again |
| 00:04:34 | <wroathe> | int-e: EvanR: thanks |
| 00:04:34 | → | califax joins (~califax@user/califx) |
| 00:04:39 | <monochrom> | Actually more essentially and easily, `fmap (False &&) foo` cannot short-ciruit to pure False. |
| 00:05:20 | <int-e> | > liftA2 (&&) (pure False) (pure undefined) |
| 00:05:21 | <lambdabot> | error: |
| 00:05:21 | <lambdabot> | • Ambiguous type variable ‘f0’ arising from a use of ‘show_M661397343980... |
| 00:05:21 | <lambdabot> | prevents the constraint ‘(Show (f0 Bool))’ from being solved. |
| 00:05:28 | <int-e> | > liftA2 (&&) (pure False) (pure undefined) :: [Bool] |
| 00:05:29 | <lambdabot> | [False] |
| 00:05:53 | <monochrom> | pure undefined /= undefined |
| 00:06:15 | → | xff0x joins (~xff0x@2405:6580:b080:900:9c64:3e23:a36:74a0) |
| 00:06:15 | <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 |
| 00:06:57 | <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...) |
| 00:07:32 | <int-e> | this is pretty much the dividing line between applicatives and monads... with moands, you *can* short-circuit on the monad action level. |
| 00:08:05 | <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? |
| 00:08:06 | <int-e> | "Computations depending on wrapped values" if you will. Which is really the essence of bind. |
| 00:08:45 | <int-e> | wroathe: I don't know... I didn't run any code. It /might/ be good for reducing allocations by 10-15%. |
| 00:09:08 | <EvanR> | it was something to try |
| 00:09:21 | <EvanR> | maybe a magic single ! that improves performance |
| 00:10:14 | <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. |
| 00:10:55 | <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 |
| 00:11:24 | <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. |
| 00:11:30 | <int-e> | sorry, not allocations |
| 00:11:34 | <int-e> | I mean resident size |
| 00:12:19 | × | hsxtrt quits (~hsxtrt@14-200-253-168.static.tpgi.com.au) (Quit: This computer has gone to sleep) |
| 00:12:57 | × | jero98772 quits (~jero98772@2800:484:1d84:300::2) (Ping timeout: 260 seconds) |
| 00:13:24 | <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 |
| 00:13:26 | <wroathe> | monochrom: So in total this results in 30209 "company" objects, 90627 "address" objects, and 30209 "submission" objects after parsing this file |
| 00:14:30 | <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 |
| 00:14:43 | <EvanR> | I presumed you wanted high performance, like, does all this in like 2 milliseconds xD |
| 00:14:56 | <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" |
| 00:15:02 | <wroathe> | But this profile says it's 37% of my allocations |
| 00:15:14 | <int-e> | Nobody has said "premature optimization" yet... this really feels like one. |
| 00:15:16 | <wroathe> | EvanR: If I wanted that high of performance I'd just do this in C |
| 00:15:17 | → | hsxtrt joins (~hsxtrt@14-200-253-168.static.tpgi.com.au) |
| 00:15:24 | <EvanR> | no. |
| 00:15:26 | <wroathe> | int-e: It's a hobby program. If this were for work I'd agree with you |
| 00:15:35 | <geekosaur> | flatparse |
| 00:15:45 | <EvanR> | I think a point is being missed here about how haskell can be really fast, esp at simple stuff like this |
| 00:15:51 | <wroathe> | But since I'm doing this for fun I'm free to quibble about memory use and performance all I want :D |
| 00:15:55 | <EvanR> | but you're slow and complicated right now |
| 00:16:41 | <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? |
| 00:16:59 | <wroathe> | Or what's the fundamental difference here between my "slow and complicated" approach, and what I should be doing? |
| 00:17:18 | <EvanR> | I'm just saying it would be slow and simple by using megaparsec normally |
| 00:17:32 | <int-e> | geekosaur: argh, why is `char :: Char -> Q Exp` |
| 00:17:34 | <EvanR> | less code I believ |
| 00:18:55 | <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 |
| 00:18:56 | <EvanR> | (maybe it would actually improve performance not trying to preempt the parser and search the string yourself) |
| 00:19:00 | <int-e> | It's mostly fine; I just didn't expect to see Template Haskell in the API. |
| 00:19:02 | × | logothesia quits (~logothesi@user/logothesia) (Ping timeout: 256 seconds) |
| 00:19:32 | <EvanR> | well you search but also use combinators like manyTill |
| 00:19:36 | <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 |
| 00:20:09 | <EvanR> | fair enough |
| 00:20:15 | <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 |
| 00:20:29 | <EvanR> | sure |
| 00:20:52 | <wroathe> | And in that circumstance I'd be skeptical that I'm doing anything fundamentally different than what I'm doing now |
| 00:21:19 | <wroathe> | Because ultimately `drop` and takeWhileP would end up resulting in a new Text being created |
| 00:21:58 | <EvanR> | drop obviously creates a new Text, but it just points into the existing underlying array, which is great |
| 00:22:35 | <wroathe> | Also another thing that's weird about this... |
| 00:23:02 | × | ystael quits (~ystael@user/ystael) (Ping timeout: 252 seconds) |
| 00:23:04 | <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 |
| 00:23:11 | <geekosaur> | int-e, it looks like they generate parsers for literals at compile time for speed |
| 00:23:14 | <wroathe> | That is, it should only be called once per \t or \n |
| 00:23:25 | <EvanR> | you also need to be careful about attributing "allocations" to particular functions |
| 00:23:40 | <geekosaur> | everything leads to https://hackage.haskell.org/package/flatparse-0.5.0.1/docs/src/FlatParse.Basic.Bytes.html#bytesUnsafe |
| 00:23:43 | <wroathe> | Yeah I'm just going off of what that profile says. |
| 00:23:45 | <EvanR> | I'm not sure how meaningful the profile is on that, since stuff happens at lazy times |
| 00:24:07 | <wroathe> | geekosaur: Haha, is this how I make a fast haskell parser? :) |
| 00:24:22 | <geekosaur> | yes |
| 00:24:45 | <wroathe> | EvanR: well there I ahve it |
| 00:24:47 | <int-e> | beautiful |
| 00:24:47 | <wroathe> | have* it |
| 00:25:04 | <wroathe> | Idk these parser combinator libraries are pretty heavily marketed in the haskell space |
| 00:25:06 | <int-e> | (there's a blinking sarcasm tag after that) |
| 00:25:16 | <EvanR> | code that is located within some function lexically could be evaluated as part of some other thing because laziness |
| 00:25:26 | <wroathe> | It's as if Attoparsec, Parsec, and Megaparsec are the only way you're supposed to parse in a functional context |
| 00:25:44 | <wroathe> | Nevermind a good old fashioned stack and switch iterative parser |
| 00:26:03 | <EvanR> | those do represent the haskell version of recursive descent |
| 00:26:03 | <geekosaur> | happy exists, it's just slower than megaparsec or attoparsec |
| 00:26:14 | <probie> | Some people still use happy (the Haskell version of yacc/bison) |
| 00:26:47 | <geekosaur> | flatparse is quite new so hasn't got a lot of market share yet, but it's been catching on |
| 00:27:50 | → | bratwurst joins (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) |
| 00:28:16 | <wroathe> | Well thanks for the help guys (especially you, EvanR). I've got a lot to mull over here. |
| 00:28:39 | <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) |
| 00:29:32 | × | YuutaW quits (~YuutaW@mail.yuuta.moe) (Ping timeout: 245 seconds) |
| 00:29:35 | <EvanR> | so if some function really is doing 37% of the allocations, it might not be taking all the time |
| 00:29:48 | <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 |
| 00:29:58 | × | caryhartline quits (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 00:30:05 | <wroathe> | And it resulted in like a 30% reduction in allocations and an improvement of like 1.5 in running time |
| 00:30:23 | <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 |
| 00:30:26 | <wroathe> | So I figure if I can make one more big improvement like that I'll be cooking with fire |
| 00:30:47 | × | razetime quits (~quassel@117.254.37.152) (Ping timeout: 245 seconds) |
| 00:30:48 | <EvanR> | another metric to look at is how much time is spent in GC |
| 00:30:59 | <EvanR> | as a percent of runtime |
| 00:31:17 | int-e | usually looks at residency and productivity |
| 00:31:31 | → | razetime joins (~quassel@117.254.36.54) |
| 00:32:12 | <geekosaur> | don't even need to profile for that, +RTS -s |
| 00:32:18 | → | YuutaW joins (~YuutaW@mail.yuuta.moe) |
| 00:32:23 | <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. |
| 00:32:47 | <EvanR> | you would use zig? xD |
| 00:33:09 | <EvanR> | comes with no less than 5 standard allocators |
| 00:34:14 | <int-e> | Rust or C or C++ most likely, in some order. |
| 00:34:48 | <geekosaur> | but if they're truly temporary allocations they cost ~nothing |
| 00:35:47 | <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 |
| 00:35:51 | × | razetime quits (~quassel@117.254.36.54) (Ping timeout: 245 seconds) |
| 00:35:52 | <EvanR> | because they don't get traversed and then are lost all at once from the nursery |
| 00:36:13 | → | razetime joins (~quassel@117.254.37.27) |
| 00:36:27 | <wroathe> | All told like I said I'd be surprised if I went over 20MB residency for the whole parsed file with the structs |
| 00:36:33 | <int-e> | EvanR: yeah, it's cheap but it's not free (it comes at the cost of memory locality) |
| 00:39:41 | <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 |
| 00:40:16 | <wroathe> | I'll try int-e's suggestion in a bit here after I finish my dinner |
| 00:40:44 | × | bratwurst quits (~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) (Ping timeout: 248 seconds) |
| 00:43:04 | × | phma quits (~phma@host-67-44-208-38.hnremote.net) (Read error: Connection reset by peer) |
| 00:43:34 | → | phma joins (~phma@2001:5b0:2143:fba8:9b6b:196:6798:af5d) |
| 00:44:18 | × | mikoto-chan quits (~mikoto-ch@85-76-46-81-nat.elisa-mobile.fi) (Ping timeout: 246 seconds) |
| 00:45:24 | → | mvk joins (~mvk@2607:fea8:5c9a:a600::1c6d) |
| 00:45:54 | <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?) |
| 00:49:14 | × | Tuplanolla quits (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Ping timeout: 244 seconds) |
| 00:49:38 | <wroathe> | int-e: 9.2.5. Good eye. |
| 00:49:42 | <wroathe> | I was wondering if that was the cause. |
| 00:51:11 | <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 ) |
| 00:51:49 | <wroathe> | GHC releases new versions so quickly it's hard to keep up :P |
| 00:52:04 | <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 |
| 00:52:14 | <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 |
| 00:52:29 | <wroathe> | int-e: Yeah, I was convinced when you initially said it |
| 00:52:38 | <wroathe> | I suspected that updating GHC would fix it when I posted the error earlier |
| 00:52:47 | <wroathe> | Although I didn't go into the detail you're going into to prove my assertion |
| 00:53:17 | <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. |
| 00:53:40 | <int-e> | So I believe something else is pulling in a newer ghc-heap. |
| 00:55:15 | <int-e> | (And ideally, that package should have tighter dependencies so that this doesn't happen.) |
| 00:56:12 | <wroathe> | Well ghc-debug is still not fully baked |
| 00:56:23 | <wroathe> | It's only in version 0.5 at the moment |
| 00:57:24 | × | razetime quits (~quassel@117.254.37.27) (Ping timeout: 246 seconds) |
| 00:57:28 | <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. |
| 00:57:55 | → | razetime joins (~quassel@117.254.36.220) |
| 00:58:29 | → | azimut joins (~azimut@gateway/tor-sasl/azimut) |
| 00:58:56 | <geekosaur> | I think it's 'ghc-heap installed', not sure if the = works there |
| 00:59:06 | <geekosaur> | (double quotes also fine) |
| 00:59:06 | <int-e> | geekosaur: oh yes |
| 01:03:41 | × | szkl quits (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 01:06:39 | → | artem joins (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 01:06:40 | × | ulysses4ever quits (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 01:10:35 | × | albet70 quits (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 01:12:37 | <wroathe> | int-e: Only slightly better. 83,266,260 versus 89,793,936 |
| 01:12:45 | <wroathe> | with that bang pattern |
| 01:14:20 | <EvanR> | 17% less 🎉 |
| 01:15:16 | <EvanR> | 7.2% less wow I can't use a calculator! |
| 01:15:22 | <wroathe> | I was going to say |
| 01:15:37 | <wroathe> | You had me in the middle of whipping out my own calculator :D |
| 01:15:56 | <int-e> | better than nothing. does it change the https://i.imgur.com/aETjZ8g.png graph? (hmm is that allocations or residency...) |
| 01:16:05 | <EvanR> | tada emoji somewhat rescinded |
| 01:16:21 | <wroathe> | cabal run tallow -O2 --enable-profiling -- data/2023q2/sub.txt +RTS -pa -L120 -hd |
| 01:16:33 | <wroathe> | int-e: it's the result of -hd, which I think is residency |
| 01:16:43 | → | albet70 joins (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 01:16:54 | <wroathe> | https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#rts-flag--hd |
| 01:17:32 | <int-e> | "live heap", yeah that's residency |
| 01:17:54 | × | quidnunc quits (~user@70.31.194.28) (Read error: Connection reset by peer) |
| 01:19:04 | <wroathe> | int-e: https://i.imgur.com/3WYdFMs.png |
| 01:20:15 | <int-e> | Cool, so the Data.Text.Read.sat* things are indeed gone. But it didn't reduce the Text numbers, hmm. Interesting. |
| 01:21:40 | <int-e> | (so that part of my speculation didn't work out) |
| 01:22:10 | <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 |
| 01:22:12 | <EvanR> | materialize |
| 01:22:27 | <EvanR> | at the end of parsing |
| 01:23:14 | <EvanR> | assuming that's not them in the profile |
| 01:23:20 | <EvanR> | which I was assuming |
| 01:23:54 | <int-e> | Oh and of course the results have to go somewhere... is that the IS thing? |
| 01:25:14 | <int-e> | (Is that how I# is rendered in a profile?) |
| 01:28:52 | × | hsxtrt quits (~hsxtrt@14-200-253-168.static.tpgi.com.au) (Quit: This computer has gone to sleep) |
| 01:30:08 | → | mikoto-chan joins (~mikoto-ch@85-76-111-77-nat.elisa-mobile.fi) |
| 01:35:19 | <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. |
| 01:36:21 | <wroathe> | int-e: Could be, yeah. I'm just trying to beat this advanceTo thing to death |
| 01:36:22 | <int-e> | corresponding to the Text and Just constructors in that profile. |
| 01:36:36 | → | libertyprime joins (~libertypr@203.96.203.44) |
| 01:36:42 | <wroathe> | I'm about to run an experiment to isolate advanceTo here |
| 01:36:58 | <int-e> | I mean, there are a lot of sat_ there indicating that things are lazy that could be strict. |
| 01:37:45 | <wroathe> | ! all the things |
| 01:37:50 | <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. |
| 01:38:27 | <wroathe> | int-e: Yup, I figured as much. |
| 01:38:50 | <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) |
| 01:38:52 | × | jle` quits (~jle`@23.240.75.236) (Ping timeout: 248 seconds) |
| 01:39:22 | <int-e> | If those are unpacked, that's 16 bytes instead of 48 + 8 bytes. |
| 01:39:43 | <wroathe> | Do you have some reading I can do on the representation of haskell data in memory? |
| 01:39:59 | <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 |
| 01:40:16 | → | jle` joins (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
| 01:42:11 | <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. |
| 01:43:50 | <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. |
| 01:44:15 | <int-e> | and 6 words = 48 bytes. |
| 01:46:16 | <EvanR> | why do you think there's a ton of Just hanging around |
| 01:46:18 | × | ddellacosta quits (~ddellacos@143.244.47.100) (Ping timeout: 256 seconds) |
| 01:46:46 | <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. |
| 01:47:00 | <wroathe> | So I just ran an interesting experiment by just executing parseRowState in a loop |
| 01:47:11 | <int-e> | EvanR: Because basically every single text field is a Maybe Text. |
| 01:47:31 | <int-e> | EvanR: unless that was a rhetorical question; I can't tell. |
| 01:47:32 | <EvanR> | oh the Maybe is part of the output data |
| 01:47:55 | <int-e> | EvanR: https://gist.github.com/JustinChristensen/72e4eae8a8e6e4e4f9be09078770c504#file-parse-hs-L53-L58 |
| 01:47:56 | <EvanR> | not a control structure |
| 01:48:09 | <EvanR> | ok then |
| 01:48:16 | → | ddellacosta joins (~ddellacos@146.70.168.217) |
| 01:48:48 | <wroathe> | int-e: EvanR: https://i.imgur.com/84es3Qe.png |
| 01:49:19 | <EvanR> | that's the same amount of ARR_WORDS as before, just not elevated on top of other stuff |
| 01:49:25 | <EvanR> | 8M of ARR_WORDS |
| 01:49:50 | <wroathe> | https://gist.github.com/JustinChristensen/72e4eae8a8e6e4e4f9be09078770c504#file-rowstate-hs |
| 01:49:50 | <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 |
| 01:49:51 | <EvanR> | basically the whole file |
| 01:49:58 | <int-e> | assuming you actually force the parse result |
| 01:50:10 | × | finsternis quits (~X@23.226.237.192) (Read error: Connection reset by peer) |
| 01:50:37 | <int-e> | the 3.5MB number looks like you're, maybe, not forcing the parse |
| 01:50:42 | → | hsxtrt joins (~hsxtrt@14.200.253.168) |
| 01:50:56 | <wroathe> | I linked the updated program there |
| 01:51:30 | <EvanR> | I change my earlier speculation about evaluating those individual Text to evaluating the Just text |
| 01:51:46 | <EvanR> | as soon as possible |
| 01:51:59 | <wroathe> | And here is the profile for that updated program: https://gist.github.com/JustinChristensen/72e4eae8a8e6e4e4f9be09078770c504#file-rowstate-prof |
| 01:52:12 | <wroathe> | So based on this what I think I'm getting is... |
| 01:52:20 | <wroathe> | Yeah, resident here there's only the 8MB worth of data from the file |
| 01:52:37 | <wroathe> | But during the course of execution advanceTo seems to be allocating lots of objects that get GCed immediately? |
| 01:53:36 | <wroathe> | I think it must be misreporting |
| 01:53:49 | <int-e> | It has to allocate a new Text object. And an updated internal state record for the parser. |
| 01:53:51 | <wroathe> | Because I look at the profile it says that 2 GB of allocations can be attributed to advanceTo |
| 01:54:03 | <wroathe> | Which sounds very wrong |
| 01:54:06 | <int-e> | There are no in-place updates. |
| 01:54:29 | <int-e> | It's all recreate-and-discard-old-version. |
| 01:55:15 | <EvanR> | normally a haskell program will allocate an insane amount of bytes per second |
| 01:55:15 | × | codaraxis__ quits (~codaraxis@user/codaraxis) (Quit: Leaving) |
| 01:55:31 | <EvanR> | of course it doesn't stay because you'd run out of memory |
| 01:55:35 | <wroathe> | Right |
| 01:56:05 | <wroathe> | Yeah, resident here is only the original 8 MB, which is good... although even that looks suspicious |
| 01:56:18 | <wroathe> | Because even with this new version of the program I'd expect to see some Text resident |
| 01:56:56 | <int-e> | `Text` is just those 32 bytes that point into the big blob that holds the entire input file. |
| 01:57:12 | <int-e> | you can have hundreds of those and it won't be visible in the graph |
| 01:57:50 | <wroathe> | int-e: Yeah, but according to the profile advanceTo is allocating 2 GB worth of something over the entire ~0.5s of runtime |
| 01:57:56 | <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 |
| 01:58:17 | <wroathe> | This is what I'm referring to: https://gist.github.com/JustinChristensen/72e4eae8a8e6e4e4f9be09078770c504#file-rowstate-prof-L10 |
| 01:59:01 | <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. |
| 01:59:02 | <EvanR> | how many loop iterations is that in 0.5s and how many bytes per iteration does it allocate |
| 01:59:18 | <EvanR> | could easily add up to 2G |
| 02:00:13 | <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 |
| 02:04:30 | × | waleee quits (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 250 seconds) |
| 02:05:21 | <int-e> | hmm... it's quite possible that findIndex actually unpacks the text into a stream |
| 02:07:07 | <wroathe> | I was actually just about to test if findIndex was the culprit |
| 02:07:10 | <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. |
| 02:07:45 | <EvanR> | is something wrong with using a stream |
| 02:11:48 | × | td_ quits (~td@i53870934.versanet.de) (Ping timeout: 256 seconds) |
| 02:13:35 | → | td_ joins (~td@i53870925.versanet.de) |
| 02:14:15 | × | xff0x quits (~xff0x@2405:6580:b080:900:9c64:3e23:a36:74a0) (Ping timeout: 245 seconds) |
| 02:16:31 | → | gastus joins (~gastus@185.6.123.186) |
| 02:16:34 | → | nate2 joins (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 02:17:52 | <dsal> | I replaced that code that was using unsafeIOToSTM by making a pure "forgetful" map and just wrapping it in STM. |
| 02:18:00 | × | hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 245 seconds) |
| 02:18:27 | <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. |
| 02:19:39 | × | gastus_ quits (~gastus@185.6.123.193) (Ping timeout: 244 seconds) |
| 02:20:14 | <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). |
| 02:20:49 | <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. |
| 02:21:03 | <dsal> | Now I just do a Map.splitLookup on a synthetic time thing which gives me all the keys that need to be deleted. |
| 02:22:42 | × | jargon quits (~jargon@174-22-213-62.phnx.qwest.net) (Remote host closed the connection) |
| 02:22:50 | <int-e> | anyway, let me get out of this rabbit hole |
| 02:23:00 | × | razetime quits (~quassel@117.254.36.220) (Ping timeout: 245 seconds) |
| 02:23:31 | <EvanR> | you can checkout anytime but never leave |
| 02:23:37 | → | razetime joins (~quassel@117.254.37.117) |
| 02:23:40 | × | ddellacosta quits (~ddellacos@146.70.168.217) (Ping timeout: 248 seconds) |
| 02:25:21 | <monochrom> | The singularity is in your future. >:) |
| 02:27:25 | <int-e> | EvanR: (More subtlety: there's also a boxed Bool in that picture... but the two values are statically allocated.) |
| 02:28:03 | <EvanR> | .oO(are the first few Char statically allocated too) |
| 02:28:17 | <EvanR> | (or the first few Int for that matter) |
| 02:28:32 | → | justsomeguy joins (~justsomeg@user/justsomeguy) |
| 02:28:35 | <int-e> | EvanR: yes but I believe only the unpackCString (spelling?) stuff actually uses that |
| 02:28:54 | → | hugo joins (znc@2001:6b0:17:f0a0::17) |
| 02:28:57 | <int-e> | And in particular, the C# constructor of Char doesn't. |
| 02:29:25 | <int-e> | emphasis on *believe* |
| 02:31:06 | → | ddellacosta joins (~ddellacos@146.70.171.136) |
| 02:35:50 | <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 |
| 02:36:03 | <wroathe> | so findIndex doesn't appear to be the problem |
| 02:36:26 | <wroathe> | The stateOffset is only used to compute error output, so for the purposes of testing it can be elided |
| 02:36:53 | → | Inst joins (~liamzy@2601:6c4:4085:6d50::85eb) |
| 02:44:17 | <int-e> | as you suggested earlier, it is possible that there's some misattribution there. |
| 02:44:57 | <int-e> | or maybe the function gets used way more often than you think due to backtracking |
| 02:46:14 | × | hsxtrt quits (~hsxtrt@14.200.253.168) (Quit: Leaving) |
| 02:46:40 | <wroathe> | Well, I just looked at the input file and there are 1,087,560 tabs and newlines in it |
| 02:46:48 | <wroathe> | So that should be the number of times advanceTo is called |
| 02:47:53 | <int-e> | EvanR: fwiw, using C# definitely results in heap allocations |
| 02:48:09 | <EvanR> | :t C# |
| 02:48:10 | <lambdabot> | error: Data constructor not in scope: C# |
| 02:48:22 | <int-e> | % :info Char |
| 02:48:22 | <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... |
| 02:48:57 | <int-e> | :t GHC.Types.C# |
| 02:48:57 | <EvanR> | when you type 'c' is that "using C#" or a statically allocated 'c' |
| 02:48:58 | <lambdabot> | GHC.Prim.Char# -> Char |
| 02:49:16 | × | justsomeguy quits (~justsomeg@user/justsomeguy) (Ping timeout: 260 seconds) |
| 02:49:36 | × | mikoto-chan quits (~mikoto-ch@85-76-111-77-nat.elisa-mobile.fi) (Ping timeout: 245 seconds) |
| 02:50:04 | <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. |
| 02:50:34 | <EvanR> | I would never presume to suggest they were! |
| 02:50:52 | → | justsomeguy joins (justsomegu@user/justsomeguy) |
| 02:50:59 | <int-e> | But I meant actually using C# as a function with unknown argument. |
| 02:51:07 | <EvanR> | sure |
| 02:51:44 | → | finn_elija joins (~finn_elij@user/finn-elija/x-0085643) |
| 02:51:44 | × | FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 02:51:44 | finn_elija | is now known as FinnElija |
| 02:54:48 | × | jpds quits (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 246 seconds) |
| 02:55:09 | → | xff0x joins (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 02:57:10 | → | arahael joins (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 03:00:50 | → | jargon joins (~jargon@174-22-213-62.phnx.qwest.net) |
| 03:01:40 | × | arahael quits (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 256 seconds) |
| 03:02:28 | → | jmcantrell joins (~weechat@user/jmcantrell) |
| 03:03:26 | <wroathe> | int-e: using lazy text instead of strict text resulted in 27% fewer allocations in that dropWhile implementation |
| 03:04:11 | <wroathe> | From 2,717,358,616 bytes down to 1,969,361,672 |
| 03:04:56 | × | aforemny quits (~aforemny@i59F516C9.versanet.de) (Ping timeout: 246 seconds) |
| 03:05:12 | <EvanR> | lazy readFile will do lazy I/O (like I originally suggested) |
| 03:05:33 | <EvanR> | though the parsing still kind defeats some of the benefit |
| 03:05:52 | → | aforemny joins (~aforemny@2001:9e8:6cd8:3100:c980:385d:6185:8dda) |
| 03:07:27 | × | hsw quits (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Quit: Leaving) |
| 03:10:52 | <int-e> | EvanR: on the other hand, String literals (unpackCString#) and IO (like getContents) share the same table of "low" characters. |
| 03:12:52 | × | wroathe quits (~wroathe@user/wroathe) (Ping timeout: 244 seconds) |
| 03:16:20 | × | shapr quits (~user@2600:1700:c640:3100:6898:ed8d:7f5e:e726) (Remote host closed the connection) |
| 03:16:55 | → | shapr joins (~user@2600:1700:c640:3100:2ac6:30d3:17d6:81ff) |
| 03:18:33 | × | nate2 quits (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 244 seconds) |
| 03:23:56 | × | libertyprime quits (~libertypr@203.96.203.44) (Ping timeout: 248 seconds) |
| 03:27:07 | → | ulysses4ever joins (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 03:27:07 | × | artem quits (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 03:32:22 | → | libertyprime joins (~libertypr@203.96.203.44) |
| 03:34:32 | × | justsomeguy quits (justsomegu@user/justsomeguy) (Ping timeout: 245 seconds) |
| 03:40:12 | × | Unicorn_Princess quits (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 03:47:31 | × | ddellacosta quits (~ddellacos@146.70.171.136) (Ping timeout: 245 seconds) |
| 03:49:33 | → | ddellacosta joins (~ddellacos@146.70.168.136) |
| 03:50:12 | × | Inst quits (~liamzy@2601:6c4:4085:6d50::85eb) (Remote host closed the connection) |
| 03:50:58 | → | Inst joins (~liamzy@2601:6c4:4085:6d50::a0f6) |
| 03:54:59 | × | [itchyjunk] quits (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 04:00:32 | × | actioninja quits (~actioninj@user/actioninja) (Quit: see ya mane) |
| 04:00:57 | → | actioninja joins (~actioninj@user/actioninja) |
| 04:05:37 | × | g quits (~glguy@libera/staff-emeritus/glguy) (Remote host closed the connection) |
| 04:05:44 | → | g joins (~glguy@libera/staff-emeritus/glguy) |
| 04:06:40 | → | _ht joins (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 04:07:29 | × | g quits (~glguy@libera/staff-emeritus/glguy) (Remote host closed the connection) |
| 04:07:37 | → | g joins (g@libera/staff-emeritus/glguy) |
| 04:23:29 | × | jargon quits (~jargon@174-22-213-62.phnx.qwest.net) (Remote host closed the connection) |
| 04:23:46 | × | razetime quits (~quassel@117.254.37.117) (Ping timeout: 245 seconds) |
| 04:24:48 | × | mvk quits (~mvk@2607:fea8:5c9a:a600::1c6d) (Ping timeout: 246 seconds) |
| 04:26:12 | × | jmcantrell quits (~weechat@user/jmcantrell) (Quit: WeeChat 4.0.3) |
| 04:53:09 | × | libertyprime quits (~libertypr@203.96.203.44) (Ping timeout: 246 seconds) |
| 04:56:18 | → | arahael joins (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 05:00:30 | × | arahael quits (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 05:01:47 | × | Inst quits (~liamzy@2601:6c4:4085:6d50::a0f6) (Remote host closed the connection) |
| 05:02:05 | → | Inst joins (~liamzy@2601:6c4:4085:6d50::85eb) |
| 05:11:12 | × | Feuermagier quits (~Feuermagi@user/feuermagier) (Quit: Leaving) |
| 05:11:26 | → | bjin joins (~bjin@user/bjin) |
| 05:15:59 | → | nate2 joins (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 05:20:22 | × | nate2 quits (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 05:28:23 | → | arahael joins (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 05:32:32 | × | arahael quits (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 240 seconds) |
| 05:34:28 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:bc38:61d8:7af5:2488) (Remote host closed the connection) |
| 05:35:37 | → | jonathan__ joins (~jonathan@193.203.13.94) |
| 05:36:01 | → | bgs joins (~bgs@212-85-160-171.dynamic.telemach.net) |
| 05:37:12 | × | _ht quits (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 05:41:13 | → | chele joins (~chele@user/chele) |
| 05:48:55 | → | michalz joins (~michalz@185.246.207.222) |
| 05:53:30 | × | notzmv quits (~zmv@user/notzmv) (Ping timeout: 246 seconds) |
| 05:55:04 | × | NewtonTrendy quits (uid282092@user/bopqod) (Quit: Connection closed for inactivity) |
| 06:08:29 | → | justsomeguy joins (~justsomeg@user/justsomeguy) |
| 06:08:42 | × | Inst quits (~liamzy@2601:6c4:4085:6d50::85eb) (Ping timeout: 258 seconds) |
| 06:09:48 | → | mikoto-chan joins (~mikoto-ch@85-76-50-50-nat.elisa-mobile.fi) |
| 06:13:19 | × | tcard quits (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Remote host closed the connection) |
| 06:13:59 | → | tcard joins (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 06:15:12 | → | arahael joins (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 06:15:49 | × | tcard quits (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Read error: Connection reset by peer) |
| 06:16:30 | → | tcard joins (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 06:16:44 | × | shapr quits (~user@2600:1700:c640:3100:2ac6:30d3:17d6:81ff) (Ping timeout: 248 seconds) |
| 06:16:59 | → | acidjnk joins (~acidjnk@p200300d6e7072f62514217c34acbe695.dip0.t-ipconnect.de) |
| 06:19:32 | × | arahael quits (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 06:21:42 | × | YuutaW quits (~YuutaW@mail.yuuta.moe) (Ping timeout: 256 seconds) |
| 06:24:17 | → | razetime joins (~quassel@117.254.37.117) |
| 06:25:20 | → | YuutaW joins (~YuutaW@mail.yuuta.moe) |
| 06:35:30 | → | Simikando joins (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 06:35:38 | → | eggplantade joins (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 06:37:44 | × | justsomeguy quits (~justsomeg@user/justsomeguy) (Ping timeout: 246 seconds) |
| 06:38:26 | × | paddymahoney quits (~paddymaho@cpe883d24bcf597-cmbc4dfb741f80.cpe.net.cable.rogers.com) (Ping timeout: 246 seconds) |
| 06:40:06 | × | eggplantade quits (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 250 seconds) |
| 06:40:39 | × | Simikando quits (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Quit: Leaving) |
| 06:43:56 | → | lortabac joins (~lortabac@2a01:e0a:541:b8f0:cc65:1a3b:6ab3:49f4) |
| 06:47:49 | → | Simikando joins (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 06:48:15 | → | justsomeguy joins (~justsomeg@user/justsomeguy) |
| 06:52:10 | × | Simikando quits (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Ping timeout: 246 seconds) |
| 06:52:31 | × | justsomeguy quits (~justsomeg@user/justsomeguy) (Ping timeout: 246 seconds) |
| 06:52:34 | → | fendor joins (~fendor@2a02:8388:1640:be00:b586:6c06:a58:19a3) |
| 06:58:35 | → | idgaen joins (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 07:03:02 | → | ensyde joins (ensyde@2600:3c02::f03c:93ff:fe9e:b831) |
| 07:06:41 | × | mikoto-chan quits (~mikoto-ch@85-76-50-50-nat.elisa-mobile.fi) (Ping timeout: 245 seconds) |
| 07:07:37 | × | bliminse quits (~bliminse@user/bliminse) (Quit: leaving) |
| 07:10:21 | × | dibblego quits (~dibblego@haskell/developer/dibblego) (Ping timeout: 246 seconds) |
| 07:10:28 | → | rune__ joins (sid21167@ilkley.irccloud.com) |
| 07:11:13 | × | rune__ quits (sid21167@ilkley.irccloud.com) (Client Quit) |
| 07:14:57 | → | coot joins (~coot@89-69-206-216.dynamic.chello.pl) |
| 07:17:00 | → | dibblego joins (~dibblego@116-255-1-151.ip4.superloop.au) |
| 07:17:00 | × | dibblego quits (~dibblego@116-255-1-151.ip4.superloop.au) (Changing host) |
| 07:17:00 | → | dibblego joins (~dibblego@haskell/developer/dibblego) |
| 07:19:11 | → | mikoto-chan joins (~mikoto-ch@ip-83-134-209-157.dsl.scarlet.be) |
| 07:19:23 | → | cfricke joins (~cfricke@user/cfricke) |
| 07:21:54 | × | gastus quits (~gastus@185.6.123.186) (Ping timeout: 244 seconds) |
| 07:22:34 | → | Pickchea joins (~private@user/pickchea) |
| 07:26:11 | → | CiaoSen joins (~Jura@2a05:5800:2d6:1600:664b:f0ff:fe37:9ef) |
| 07:37:06 | × | ft quits (~ft@p4fc2ad78.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 07:37:32 | × | mikoto-chan quits (~mikoto-ch@ip-83-134-209-157.dsl.scarlet.be) (Ping timeout: 252 seconds) |
| 07:41:02 | → | misterfish joins (~misterfis@87.215.131.102) |
| 07:43:10 | → | arahael joins (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 07:43:26 | → | bliminse joins (~bliminse@user/bliminse) |
| 07:44:52 | × | dibblego quits (~dibblego@haskell/developer/dibblego) (Ping timeout: 240 seconds) |
| 07:46:46 | × | idgaen quits (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.2) |
| 07:47:52 | × | arahael quits (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 245 seconds) |
| 07:48:56 | → | ft joins (~ft@p4fc2ad78.dip0.t-ipconnect.de) |
| 07:49:16 | × | wrengr quits (~wrengr@201.59.83.34.bc.googleusercontent.com) (Remote host closed the connection) |
| 07:49:43 | → | gensyst joins (~gensyst@user/gensyst) |
| 07:49:47 | <gensyst> | I have tons of these: "newtype Lol = Lol Float", "newtype Rofl = Rofl Float". |
| 07:49:47 | <gensyst> | When extracting, I'm always doing "(let Lol x = lol in x)", "(let Rofl x = rofl in x)", etc. |
| 07:49:47 | <gensyst> | Is it possible to have one general extraction function that works for all newtypes? |
| 07:50:02 | → | dibblego joins (~dibblego@116-255-1-151.ip4.superloop.au) |
| 07:50:02 | × | dibblego quits (~dibblego@116-255-1-151.ip4.superloop.au) (Changing host) |
| 07:50:02 | → | dibblego joins (~dibblego@haskell/developer/dibblego) |
| 07:52:30 | → | mikoto-chan joins (~mikoto-ch@ip-83-134-209-157.dsl.scarlet.be) |
| 07:52:43 | <opqdonut> | gensyst: you can define your own class, or use one of the solutions on hackage like https://hackage.haskell.org/package/newtype |
| 07:53:01 | → | mima joins (~mmh@aftr-62-216-211-33.dynamic.mnet-online.de) |
| 07:54:03 | <probie> | gensyst: `Data.Coerce.coerce`? |
| 07:54:59 | × | jespada quits (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Remote host closed the connection) |
| 07:55:37 | → | jespada joins (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 07:58:22 | × | econo_ quits (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 07:59:30 | <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. |
| 08:00:22 | × | Sgeo quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 08:02:10 | <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) |
| 08:04:23 | → | notzmv joins (~zmv@user/notzmv) |
| 08:11:18 | × | azimut quits (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 08:11:44 | → | azimut joins (~azimut@gateway/tor-sasl/azimut) |
| 08:12:23 | × | califax quits (~califax@user/califx) (Remote host closed the connection) |
| 08:12:46 | → | califax joins (~califax@user/califx) |
| 08:15:22 | × | dibblego quits (~dibblego@haskell/developer/dibblego) (Ping timeout: 245 seconds) |
| 08:15:56 | → | Simikando joins (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 08:20:49 | → | dibblego joins (~dibblego@116-255-1-151.ip4.superloop.au) |
| 08:20:49 | × | dibblego quits (~dibblego@116-255-1-151.ip4.superloop.au) (Changing host) |
| 08:20:49 | → | dibblego joins (~dibblego@haskell/developer/dibblego) |
| 08:20:59 | → | arahael joins (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 08:21:55 | → | dhil joins (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 08:24:00 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:cc65:1a3b:6ab3:49f4) (Ping timeout: 246 seconds) |
| 08:30:42 | → | lortabac joins (~lortabac@2a01:e0a:541:b8f0:a6c1:e36f:a7ec:e7e5) |
| 08:35:41 | × | razetime quits (~quassel@117.254.37.117) (Ping timeout: 246 seconds) |
| 08:35:50 | × | Simikando quits (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Ping timeout: 252 seconds) |
| 08:38:02 | → | turlando joins (~turlando@user/turlando) |
| 08:40:48 | → | cyphase_eviltwin joins (~cyphase@user/cyphase) |
| 08:40:57 | × | cyphase quits (~cyphase@user/cyphase) (Ping timeout: 244 seconds) |
| 08:44:31 | <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... |
| 08:44:38 | × | Pickchea quits (~private@user/pickchea) (Ping timeout: 252 seconds) |
| 08:45:25 | <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? |
| 08:47:32 | <[Leary]> | fendor: `deriving instance Show (f (Term f)) => Show (Term f)`, with StandaloneDeriving and perhaps UndecidableInstances. |
| 08:49:51 | <fendor> | I am a bit weary of UndecidableInstances in my code... but I suppose, it is fine in this particular instance |
| 08:51:02 | → | Inst joins (~liamzy@2601:6c4:4085:6d50::85eb) |
| 08:51:57 | <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) |
| 08:53:18 | <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 |
| 08:56:31 | → | razetime joins (~quassel@117.254.37.117) |
| 08:59:08 | × | gensyst quits (~gensyst@user/gensyst) (Ping timeout: 246 seconds) |
| 09:03:08 | → | danse-nr3 joins (~francesco@151.47.152.232) |
| 09:03:38 | → | Simikando joins (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 09:07:11 | <fendor> | it might be harmless, but unless you understand why you need it, you might run into issues later |
| 09:11:57 | <fendor> | probie, thanks! |
| 09:14:14 | → | Square joins (~Square4@user/square) |
| 09:14:26 | <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 |
| 09:16:03 | <fendor> | iirc, I encountered issues that I couldn't actually write the instances I wanted, even though it fixed my initial type error |
| 09:16:36 | × | Simikando quits (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Quit: Leaving) |
| 09:17:14 | → | nate2 joins (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 09:19:30 | <[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. |
| 09:20:10 | <c_wraith> | ah, well. There certainly are instances that don't work even with it on. |
| 09:21:00 | <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. |
| 09:22:07 | <fendor> | exactly |
| 09:22:28 | × | nate2 quits (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 256 seconds) |
| 09:30:19 | × | ft quits (~ft@p4fc2ad78.dip0.t-ipconnect.de) (Quit: leaving) |
| 09:35:41 | × | danse-nr3 quits (~francesco@151.47.152.232) (Ping timeout: 248 seconds) |
| 09:37:54 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:d4d1:1f75:43b9:b6be) |
| 09:42:03 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:d4d1:1f75:43b9:b6be) (Ping timeout: 246 seconds) |
| 09:45:10 | × | whatsupdoc quits (uid509081@id-509081.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 09:46:45 | × | azimut quits (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 246 seconds) |
| 09:47:32 | → | Pickchea joins (~private@user/pickchea) |
| 09:52:03 | → | danse-nr3 joins (~francesco@151.47.152.232) |
| 09:55:05 | × | tzh quits (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 09:55:32 | × | td_ quits (~td@i53870925.versanet.de) (Ping timeout: 250 seconds) |
| 10:03:09 | → | [itchyjunk] joins (~itchyjunk@user/itchyjunk/x-7353470) |
| 10:05:34 | × | ensyde quits (ensyde@2600:3c02::f03c:93ff:fe9e:b831) (Quit: WeeChat 4.0.3) |
| 10:07:36 | × | xff0x quits (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 246 seconds) |
| 10:10:44 | × | Inst quits (~liamzy@2601:6c4:4085:6d50::85eb) (Remote host closed the connection) |
| 10:11:03 | → | Inst joins (~liamzy@2601:6c4:4085:6d50::c972) |
| 10:11:13 | ← | bjin parts (~bjin@user/bjin) (Leaving) |
| 10:17:20 | → | td_ joins (~td@i5387092A.versanet.de) |
| 10:23:51 | → | mc47 joins (~mc47@xmonad/TheMC47) |
| 10:24:32 | × | CiaoSen quits (~Jura@2a05:5800:2d6:1600:664b:f0ff:fe37:9ef) (Ping timeout: 246 seconds) |
| 10:27:16 | → | lottaquestions joins (~nick@2607:fa49:503d:b200:5a77:1161:fea9:1c25) |
| 10:28:49 | × | td_ quits (~td@i5387092A.versanet.de) (Ping timeout: 246 seconds) |
| 10:35:15 | × | Inst quits (~liamzy@2601:6c4:4085:6d50::c972) (Remote host closed the connection) |
| 10:35:32 | → | Inst joins (~liamzy@2601:6c4:4085:6d50::2cf5) |
| 10:36:18 | → | ripspin joins (~chatzilla@1.145.138.142) |
| 10:39:23 | × | shriekingnoise quits (~shrieking@186.137.175.87) (Quit: Quit) |
| 10:51:38 | → | justsomeguy joins (~justsomeg@user/justsomeguy) |
| 10:58:48 | × | justsomeguy quits (~justsomeg@user/justsomeguy) (Ping timeout: 250 seconds) |
| 10:59:37 | → | xff0x joins (~xff0x@2405:6580:b080:900:519f:cf85:d2f3:6c08) |
| 11:01:42 | × | acidjnk quits (~acidjnk@p200300d6e7072f62514217c34acbe695.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 11:04:42 | → | acidjnk joins (~acidjnk@p200300d6e7072f62bd26c55050e04c1c.dip0.t-ipconnect.de) |
| 11:09:00 | × | vglfr quits (~vglfr@cli-188-239-201-89.bbn.slav.dn.ua) (Ping timeout: 256 seconds) |
| 11:09:45 | × | acidjnk quits (~acidjnk@p200300d6e7072f62bd26c55050e04c1c.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 11:10:52 | → | td_ joins (~td@i5387093F.versanet.de) |
| 11:17:16 | × | mikoto-chan quits (~mikoto-ch@ip-83-134-209-157.dsl.scarlet.be) (Quit: WeeChat 3.8) |
| 11:20:44 | × | Pickchea quits (~private@user/pickchea) (Quit: Leaving) |
| 11:22:02 | × | cfricke quits (~cfricke@user/cfricke) (Ping timeout: 260 seconds) |
| 11:25:08 | → | sm joins (~sm@plaintextaccounting/sm) |
| 11:32:30 | × | td_ quits (~td@i5387093F.versanet.de) (Ping timeout: 246 seconds) |
| 11:36:07 | → | Guest12 joins (~Guest44@176.122.87.241) |
| 11:39:21 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:d4d1:1f75:43b9:b6be) |
| 11:39:22 | → | td_ joins (~td@i5387092D.versanet.de) |
| 11:43:42 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:d4d1:1f75:43b9:b6be) (Ping timeout: 245 seconds) |
| 11:45:23 | <Guest12> | hello |
| 11:46:09 | × | danse-nr3 quits (~francesco@151.47.152.232) (Ping timeout: 246 seconds) |
| 11:46:35 | <Guest12> | https://paste.tomsmeding.com/orqoheRZ |
| 11:48:06 | × | pointlessslippe1 quits (~pointless@212.82.82.3) (Ping timeout: 256 seconds) |
| 11:49:59 | → | pointlessslippe1 joins (~pointless@212.82.82.3) |
| 11:50:12 | <Guest12> | is it possible to specify a "specific" SomeType for Message content? or just don't use SomeType? https://paste.tomsmeding.com/MvCm3vC8 |
| 11:51:11 | × | Guest12 quits (~Guest44@176.122.87.241) (Quit: Client closed) |
| 11:51:29 | → | Guest92 joins (~Guest44@176.122.87.241) |
| 11:52:57 | × | razetime quits (~quassel@117.254.37.117) (Ping timeout: 260 seconds) |
| 11:54:07 | → | danse-nr3 joins (~francesco@151.47.152.232) |
| 11:54:32 | × | td_ quits (~td@i5387092D.versanet.de) (Ping timeout: 240 seconds) |
| 11:56:03 | → | kuribas joins (~user@2a02:1808:87:3737:23f8:531e:6ce4:5065) |
| 11:56:42 | → | artem joins (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 11:56:42 | × | ulysses4ever quits (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 12:03:34 | → | SegmentationFaul joins (~Segmentat@185.151.84.54) |
| 12:04:02 | × | jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds) |
| 12:07:07 | → | td_ joins (~td@83.135.9.23) |
| 12:08:29 | × | Inst quits (~liamzy@2601:6c4:4085:6d50::2cf5) (Ping timeout: 246 seconds) |
| 12:15:26 | <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 |
| 12:15:28 | <exarkun> | also missing basic functionality, like a Show instance. Am I barking up the wrong tree? |
| 12:15:42 | × | danse-nr3 quits (~francesco@151.47.152.232) (Ping timeout: 246 seconds) |
| 12:16:44 | × | sm quits (~sm@plaintextaccounting/sm) (Quit: sm) |
| 12:17:30 | × | kitzman quits (~kitzman@user/dekenevs) (Quit: C-x C-c) |
| 12:18:11 | × | Guest92 quits (~Guest44@176.122.87.241) (Quit: Client closed) |
| 12:18:15 | → | danse-nr3 joins (~francesco@151.47.152.232) |
| 12:19:29 | → | kitzman joins (~kitzman@user/dekenevs) |
| 12:19:31 | → | razetime joins (~quassel@117.254.37.117) |
| 12:24:18 | × | dibblego quits (~dibblego@haskell/developer/dibblego) (Ping timeout: 246 seconds) |
| 12:26:42 | → | dibblego joins (~dibblego@116.255.1.151) |
| 12:26:42 | × | dibblego quits (~dibblego@116.255.1.151) (Changing host) |
| 12:26:42 | → | dibblego joins (~dibblego@haskell/developer/dibblego) |
| 12:31:28 | × | ripspin quits (~chatzilla@1.145.138.142) (Remote host closed the connection) |
| 12:34:48 | × | SegmentationFaul quits (~Segmentat@185.151.84.54) (Quit: Client closed) |
| 12:40:36 | → | falafel joins (~falafel@216.68.6.51.dyn.plus.net) |
| 12:47:13 | → | ph88 joins (~ph88@ip5b403cd4.dynamic.kabel-deutschland.de) |
| 12:47:32 | <ph88> | how can i run Control.Monad.Fail ? either with Either or with exception |
| 12:48:16 | <ph88> | oh nvm i guess i can turn it into Maybe |
| 12:49:32 | × | razetime quits (~quassel@117.254.37.117) (Ping timeout: 245 seconds) |
| 12:54:20 | <ncf> | > fail "boo" :: Either String () |
| 12:54:21 | <lambdabot> | error: |
| 12:54:21 | <lambdabot> | • No instance for (MonadFail (Either String)) |
| 12:54:21 | <lambdabot> | arising from a use of ‘fail’ |
| 12:54:50 | <ncf> | rip |
| 12:57:00 | <ncf> | https://gitlab.haskell.org/ghc/ghc/-/issues/12160 |
| 13:01:24 | × | mc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 13:02:16 | × | danse-nr3 quits (~francesco@151.47.152.232) (Read error: Connection reset by peer) |
| 13:02:46 | → | danse-nr3 joins (~francesco@151.37.126.103) |
| 13:09:46 | <albet70> | how to construct an IO String reading element from a list one by one? |
| 13:11:27 | <ncf> | IORef? |
| 13:15:30 | × | arahael quits (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 245 seconds) |
| 13:19:00 | → | nate2 joins (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 13:23:15 | → | kuribas` joins (~user@2a02:1808:1:281d:be13:5348:8276:dbb0) |
| 13:23:50 | → | ystael joins (~ystael@user/ystael) |
| 13:24:24 | × | nate2 quits (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 13:25:06 | × | kuribas quits (~user@2a02:1808:87:3737:23f8:531e:6ce4:5065) (Ping timeout: 260 seconds) |
| 13:27:54 | → | ccapndave joins (~ccapndave@xcpe-62-167-165-47.cgn.res.adslplus.ch) |
| 13:28:57 | × | hgolden quits (~hgolden@2603-8000-9d00-3ed1-fc05-5499-f77c-fbe5.res6.spectrum.com) (Remote host closed the connection) |
| 13:31:16 | → | SegmentationFaul joins (~Segmentat@185.151.84.54) |
| 13:32:06 | × | dhil quits (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 252 seconds) |
| 13:35:17 | → | sm joins (~sm@plaintextaccounting/sm) |
| 13:36:20 | → | arahael joins (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 13:36:54 | × | falafel quits (~falafel@216.68.6.51.dyn.plus.net) (Ping timeout: 246 seconds) |
| 13:38:55 | <xerox> | elements being? |
| 13:40:11 | × | ccapndave quits (~ccapndave@xcpe-62-167-165-47.cgn.res.adslplus.ch) (Quit: Textual IRC Client: www.textualapp.com) |
| 13:40:32 | → | wroathe joins (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 13:40:32 | × | wroathe quits (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 13:40:32 | → | wroathe joins (~wroathe@user/wroathe) |
| 13:40:36 | × | arahael quits (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 13:43:58 | × | ec quits (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 13:44:21 | → | ec joins (~ec@gateway/tor-sasl/ec) |
| 13:45:05 | × | danse-nr3 quits (~francesco@151.37.126.103) (Ping timeout: 245 seconds) |
| 13:49:38 | → | danse-nr3 joins (~francesco@151.37.126.103) |
| 13:52:20 | × | sm quits (~sm@plaintextaccounting/sm) (Quit: sm) |
| 13:55:55 | → | ripspin joins (~chatzilla@1.145.177.194) |
| 13:56:21 | × | kuribas` quits (~user@2a02:1808:1:281d:be13:5348:8276:dbb0) (Ping timeout: 246 seconds) |
| 13:59:04 | × | ddellacosta quits (~ddellacos@146.70.168.136) (Ping timeout: 250 seconds) |
| 14:01:52 | × | wroathe quits (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 14:05:11 | → | Sgeo joins (~Sgeo@user/sgeo) |
| 14:08:34 | → | mc47 joins (~mc47@xmonad/TheMC47) |
| 14:10:07 | → | Simikando joins (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 14:11:53 | × | Simikando quits (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Client Quit) |
| 14:14:12 | → | Simikando joins (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 14:23:14 | × | Ram-Z quits (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) (Ping timeout: 246 seconds) |
| 14:23:15 | → | jonathan joins (~jonathan@193.203.13.94) |
| 14:23:41 | → | ulysses4ever joins (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 14:23:41 | × | artem quits (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 14:29:03 | → | Ram-Z joins (~Ram-Z@li1814-254.members.linode.com) |
| 14:31:12 | → | m21it joins (~m21it@2800:ac:c020:f24b:2278:812f:509e:9a2f) |
| 14:34:52 | <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`. |
| 14:35:06 | <m21it> | https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.Data.html#DataType |
| 14:36:37 | <m21it> | I did some tests `x `shouldBe` Data.fromConstr (Data.toConstr x)` but it seems to be non-terminating due to infinite recursion |
| 14:39:37 | × | Ram-Z quits (~Ram-Z@li1814-254.members.linode.com) (Quit: ZNC - http://znc.in) |
| 14:41:24 | <m21it> | It seems to be Constr does depend on DataType does depend on DataRep does depend of Constr.. |
| 14:41:28 | → | Ram-Z joins (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) |
| 14:42:03 | × | Simikando quits (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Quit: Leaving) |
| 14:42:24 | → | acidjnk joins (~acidjnk@p200300d6e7072f62b0c5e6199a92dfb8.dip0.t-ipconnect.de) |
| 14:46:31 | → | thegeekinside joins (~thegeekin@189.180.79.225) |
| 14:50:52 | × | jonathan quits (~jonathan@193.203.13.94) (Quit: Leaving) |
| 14:51:04 | → | srk- joins (~sorki@user/srk) |
| 14:54:58 | × | srk quits (~sorki@user/srk) (Ping timeout: 252 seconds) |
| 14:54:58 | srk- | is now known as srk |
| 14:55:06 | × | misterfish quits (~misterfis@87.215.131.102) (Ping timeout: 256 seconds) |
| 14:55:48 | → | random-jellyfish joins (~random-je@user/random-jellyfish) |
| 15:02:16 | <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? |
| 15:02:32 | <random-jellyfish> | is there like a standard way that I can read about and reuse? |
| 15:04:19 | → | idgaen joins (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 15:04:56 | × | ripspin quits (~chatzilla@1.145.177.194) (Ping timeout: 250 seconds) |
| 15:05:42 | → | dsfsdfsdf joins (~dsfsdfsdf@ip4d148080.dynamic.kabel-deutschland.de) |
| 15:06:11 | <m21it> | random-jellyfish: yes, StateT monad transformer |
| 15:07:19 | <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 |
| 15:07:42 | <random-jellyfish> | can it be implemented in other languages? e.g. CommonLisp? |
| 15:07:54 | × | dsfsdfsdf quits (~dsfsdfsdf@ip4d148080.dynamic.kabel-deutschland.de) (Client Quit) |
| 15:08:41 | → | azimut joins (~azimut@gateway/tor-sasl/azimut) |
| 15:09:21 | → | gatekempt joins (~gatekempt@user/gatekempt) |
| 15:10:12 | <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 |
| 15:10:31 | → | Unicorn_Princess joins (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 15:14:36 | <[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. |
| 15:14:44 | <[Leary]> | > (fromConstr . toConstr :: Data a => a -> a) <$> [Nothing, Just ()] |
| 15:14:46 | <lambdabot> | [Nothing,Just *Exception: Data.Data.fromConstr |
| 15:16:37 | <ph88> | is there some auto fixer program that can do things like remove unused imports. replace unused variables by underscore etc ? |
| 15:17:24 | → | artem joins (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 15:17:25 | × | ulysses4ever quits (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 15:19:01 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:a6c1:e36f:a7ec:e7e5) (Quit: WeeChat 2.8) |
| 15:21:24 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:75c0:69c6:c6bf:d46c) |
| 15:21:27 | <m21it> | ph88: hlint and fourmolu are good to remove redundant stuff and do simple auto-refactorings |
| 15:21:41 | → | ripspin joins (~chatzilla@1.145.251.200) |
| 15:22:17 | <ph88> | thx |
| 15:30:07 | <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 |
| 15:30:25 | <geekosaur> | https://hackage.haskell.org/package/HaRe seems a bit out of date |
| 15:30:52 | <geekosaur> | but I think most of its goals have been integrated into HLS, not that that has a batch mode |
| 15:32:01 | <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 |
| 15:32:22 | <m21it> | geekosaur: oh, hi! You are in this chat as well :) |
| 15:32:32 | <geekosaur> | (luckily I already upgraded to a GHC that works compatibly with the new kernel) |
| 15:32:42 | <geekosaur> | this is actually my main chat |
| 15:33:32 | × | Square quits (~Square4@user/square) (Ping timeout: 248 seconds) |
| 15:38:44 | → | NewtonTrendy joins (uid282092@user/bopqod) |
| 15:38:51 | × | azimut quits (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 246 seconds) |
| 15:41:00 | <[Leary]> | random-jellyfish: Seems like FSM aren't Turing complete, so an imperative language with while loops is probably too powerful to be translated. |
| 15:42:02 | <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 |
| 15:42:09 | × | rembo10 quits (~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 15:42:20 | <EvanR> | 4 ints is 2^(4*64) states |
| 15:42:28 | → | rembo10 joins (~rembo10@main.remulis.com) |
| 15:43:04 | × | sefidel quits (~sefidel@user/sefidel) (Ping timeout: 244 seconds) |
| 15:43:11 | <random-jellyfish> | yeah it's true some cases might not be translatable |
| 15:43:20 | → | sefidel joins (~sefidel@user/sefidel) |
| 15:47:58 | × | random-jellyfish quits (~random-je@user/random-jellyfish) (Quit: Client closed) |
| 15:52:40 | × | chele quits (~chele@user/chele) (Remote host closed the connection) |
| 15:53:33 | × | ripspin quits (~chatzilla@1.145.251.200) (Remote host closed the connection) |
| 15:56:05 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 15:56:59 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 15:57:23 | × | Ram-Z quits (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) (Quit: ZNC - http://znc.in) |
| 15:59:26 | → | Ram-Z joins (~Ram-Z@li1814-254.members.linode.com) |
| 16:00:08 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 16:01:04 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 16:02:19 | → | Tuplanolla joins (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 16:05:01 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 16:05:36 | → | _ht joins (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 16:05:52 | → | dhil joins (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 16:06:31 | × | _ht quits (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Client Quit) |
| 16:06:51 | → | _ht joins (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 16:11:28 | → | gmg joins (~user@user/gehmehgeh) |
| 16:16:56 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 16:16:58 | → | arahael joins (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 16:17:33 | → | tzh joins (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 16:19:34 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Client Quit) |
| 16:22:13 | × | FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 16:22:41 | → | FinnElija joins (~finn_elij@user/finn-elija/x-0085643) |
| 16:22:58 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 16:23:36 | × | dcoutts quits (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 16:24:23 | → | razetime joins (~quassel@117.254.37.154) |
| 16:24:36 | × | thegeekinside quits (~thegeekin@189.180.79.225) (Ping timeout: 245 seconds) |
| 16:25:21 | → | thegeekinside joins (~thegeekin@189.180.79.225) |
| 16:25:30 | × | arahael quits (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 245 seconds) |
| 16:25:55 | → | woffs joins (3cd46299b2@woffs.de) |
| 16:37:02 | × | machinedgod quits (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 245 seconds) |
| 16:39:32 | × | m21it quits (~m21it@2800:ac:c020:f24b:2278:812f:509e:9a2f) (Remote host closed the connection) |
| 16:40:02 | → | ulysses4ever joins (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 16:40:03 | × | artem quits (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 16:42:39 | → | vglfr joins (~vglfr@145.224.100.231) |
| 16:43:06 | → | oo_miguel joins (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) |
| 16:43:55 | × | SegmentationFaul quits (~Segmentat@185.151.84.54) (Quit: Client closed) |
| 16:44:25 | × | vglfr quits (~vglfr@145.224.100.231) (Read error: Connection reset by peer) |
| 16:44:35 | → | vglfr joins (~vglfr@145.224.100.231) |
| 16:46:42 | × | vglfr quits (~vglfr@145.224.100.231) (Read error: Connection reset by peer) |
| 16:50:53 | → | Simikando joins (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 16:51:40 | × | FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 16:52:07 | ← | woffs parts (3cd46299b2@woffs.de) () |
| 16:52:14 | → | FinnElija joins (~finn_elij@user/finn-elija/x-0085643) |
| 16:53:41 | × | pavonia quits (~user@user/siracusa) (Quit: Bye!) |
| 17:02:38 | × | danse-nr3 quits (~francesco@151.37.126.103) (Read error: Connection reset by peer) |
| 17:03:07 | → | danse-nr3 joins (~francesco@151.47.168.22) |
| 17:04:16 | → | myyo joins (~myyo@75-166-145-203.hlrn.qwest.net) |
| 17:08:00 | × | razetime quits (~quassel@117.254.37.154) (Ping timeout: 245 seconds) |
| 17:09:44 | → | shapr joins (~user@2600:1700:c640:3100:4414:113a:dbea:a6ec) |
| 17:10:04 | → | zer0bitz joins (~zer0bitz@user/zer0bitz) |
| 17:14:30 | × | Simikando quits (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Ping timeout: 250 seconds) |
| 17:14:30 | → | jmcantrell joins (~weechat@user/jmcantrell) |
| 17:15:31 | → | ars23 joins (~ars23@92.81.96.66) |
| 17:15:44 | × | ars23 quits (~ars23@92.81.96.66) (Changing host) |
| 17:15:44 | → | ars23 joins (~ars23@user/ars23) |
| 17:15:55 | × | ars23 quits (~ars23@user/ars23) (Remote host closed the connection) |
| 17:17:04 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 17:17:21 | × | myyo quits (~myyo@75-166-145-203.hlrn.qwest.net) () |
| 17:18:17 | <dminuoso> | EvanR: 2^(4*64) is quite... finite? |
| 17:18:24 | <dminuoso> | It's not less finite than 10. |
| 17:18:35 | × | zer0bitz quits (~zer0bitz@user/zer0bitz) (Read error: Connection reset by peer) |
| 17:18:36 | × | ulysses4ever quits (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 17:18:48 | → | ulysses4ever joins (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 17:20:05 | <EvanR> | and ram is finite so every algorithm is O(1) |
| 17:20:26 | <dminuoso> | Well RAM is usually not part of the definition of most languages. |
| 17:20:40 | <dminuoso> | So if we consider something like Integer its a different story, because its unbounded in principle. |
| 17:20:44 | → | nate2 joins (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 17:20:46 | <dminuoso> | But Int is very finite. |
| 17:22:15 | <mauke> | fortunately C isn't turing complete, so it is always O(1) |
| 17:22:19 | <mauke> | which explains its speed |
| 17:22:22 | <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 |
| 17:23:47 | <EvanR> | finite or not 2^256 sets of rules isn't practical |
| 17:25:12 | × | nate2 quits (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 17:27:17 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 17:28:59 | → | Simikando joins (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 17:29:40 | <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? |
| 17:29:51 | <Athas> | Same version of GHC and almost same Hackage dependencies. |
| 17:30:14 | <Athas> | Also same GHC options, unless Nix sets something unusual. |
| 17:37:52 | × | Simikando quits (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Ping timeout: 240 seconds) |
| 17:38:32 | → | kimiamania600 joins (~65804703@user/kimiamania) |
| 17:38:48 | × | kimiamania60 quits (~65804703@user/kimiamania) (Ping timeout: 244 seconds) |
| 17:38:48 | kimiamania600 | is now known as kimiamania60 |
| 17:40:38 | × | shapr quits (~user@2600:1700:c640:3100:4414:113a:dbea:a6ec) (Ping timeout: 246 seconds) |
| 17:44:09 | × | danse-nr3 quits (~francesco@151.47.168.22) (Remote host closed the connection) |
| 17:44:31 | → | danse-nr3 joins (~francesco@151.47.168.22) |
| 17:47:20 | → | danza joins (~francesco@151.47.168.22) |
| 17:48:21 | → | ddellacosta joins (~ddellacos@146.70.168.100) |
| 17:50:18 | × | danse-nr3 quits (~francesco@151.47.168.22) (Ping timeout: 246 seconds) |
| 17:58:52 | <tomsmeding> | Athas: any striking differences when running this? objdump -h $EXECNAME | awk '{print $3 " " $2}' | grep '^[0-9a-f]\+ ' | sort |
| 18:00:25 | × | teddyc quits (theodorc@cassarossa.samfundet.no) (Quit: WeeChat 3.0) |
| 18:01:16 | × | kimiamania60 quits (~65804703@user/kimiamania) (Ping timeout: 245 seconds) |
| 18:02:00 | <Athas> | The .text and .data sections are only half the size in the Nix-built one. |
| 18:02:17 | <geekosaur> | sounds like it uses -split-sections? |
| 18:02:22 | <Athas> | Which of them? |
| 18:02:49 | <geekosaur> | what? |
| 18:03:20 | <geekosaur> | oh. I mean nix does |
| 18:03:21 | <Athas> | Is it the Nix or the cabal one that you think uses -split-sections? |
| 18:03:42 | <Athas> | Is there a reason not to use -split-sections, if it makes such a large difference? |
| 18:03:43 | <geekosaur> | it means the linker can do more pruning of unusede code/data |
| 18:03:51 | <geekosaur> | portability, mostly |
| 18:04:31 | <geekosaur> | also it's somewhat slower to build and in particuloar link |
| 18:04:48 | <geekosaur> | (granted, not as horrendously slow as the old -split-objs) |
| 18:05:03 | <tomsmeding> | portability across linkers or portability across loaders (running platforms)? |
| 18:05:25 | <geekosaur> | neither os x nor windows supports -split-sections |
| 18:05:27 | × | mc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 18:06:53 | <Athas> | Presumably GHC knows which operating system it is running on. |
| 18:07:48 | <geekosaur> | yes, it just whines if you use it on the wrong platform, but some people don't like that |
| 18:08:18 | → | kimiamania600 joins (~65804703@user/kimiamania) |
| 18:10:47 | <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 |
| 18:16:24 | <geekosaur> | (or a non-GNU linker if you are on an ELF platform that has one) |
| 18:19:11 | × | ph88 quits (~ph88@ip5b403cd4.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 18:25:41 | × | m1dnight quits (~christoph@78-22-4-67.access.telenet.be) (Read error: Connection reset by peer) |
| 18:26:42 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 18:26:59 | → | Simikando joins (~Simikando@adsl-dyn1.91-127-51.t-com.sk) |
| 18:27:24 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 18:29:19 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:75c0:69c6:c6bf:d46c) (Remote host closed the connection) |
| 18:29:59 | × | mima quits (~mmh@aftr-62-216-211-33.dynamic.mnet-online.de) (Ping timeout: 246 seconds) |
| 18:31:38 | → | m1dnight joins (~christoph@78-22-4-67.access.telenet.be) |
| 18:36:31 | × | fendor quits (~fendor@2a02:8388:1640:be00:b586:6c06:a58:19a3) (Remote host closed the connection) |
| 18:38:44 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 18:38:59 | → | waleee joins (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 18:47:34 | → | Pickchea joins (~private@user/pickchea) |
| 19:00:20 | × | Simikando quits (~Simikando@adsl-dyn1.91-127-51.t-com.sk) (Quit: Leaving) |
| 19:02:02 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 19:03:34 | → | artem joins (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 19:03:34 | × | ulysses4ever quits (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 19:04:24 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 19:08:33 | → | zer0bitz joins (~zer0bitz@user/zer0bitz) |
| 19:15:07 | → | misterfish joins (~misterfis@84-53-85-146.bbserv.nl) |
| 19:19:30 | → | shapr joins (~user@2600:1700:c640:3100:65f2:5dc9:6ef9:713) |
| 19:29:09 | → | jmdaemon joins (~jmdaemon@user/jmdaemon) |
| 19:29:49 | → | eggplantade joins (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 19:34:11 | × | eggplantade quits (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 245 seconds) |
| 19:49:48 | → | bramhaag7 joins (~bramhaag@134.195.121.39) |
| 19:50:55 | × | bramhaag quits (~bramhaag@134.195.121.39) (Ping timeout: 246 seconds) |
| 19:51:45 | → | ft joins (~ft@p4fc2ad78.dip0.t-ipconnect.de) |
| 19:54:12 | × | bramhaag7 quits (~bramhaag@134.195.121.39) (Ping timeout: 260 seconds) |
| 19:55:25 | → | bramhaag joins (~bramhaag@134.195.121.39) |
| 20:01:27 | × | jonathan__ quits (~jonathan@193.203.13.94) (Remote host closed the connection) |
| 20:01:52 | → | jonathan__ joins (~jonathan@193.203.13.94) |
| 20:01:58 | × | bramhaag quits (~bramhaag@134.195.121.39) (Quit: The Lounge - https://thelounge.chat) |
| 20:03:08 | → | bramhaag7 joins (~bramhaag@198.8.58.39) |
| 20:03:30 | × | misterfish quits (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 250 seconds) |
| 20:06:13 | × | idgaen quits (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.2) |
| 20:06:37 | → | econo_ joins (uid147250@2a03:5180:f::2:3f32) |
| 20:15:01 | → | Square2 joins (~Square4@user/square) |
| 20:15:20 | → | misterfish joins (~misterfis@84-53-85-146.bbserv.nl) |
| 20:17:19 | × | _ht quits (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 20:25:28 | → | fendor joins (~fendor@2a02:8388:1640:be00:b586:6c06:a58:19a3) |
| 20:25:28 | × | misterfish quits (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 256 seconds) |
| 20:26:29 | → | son0p joins (~ff@191.104.6.44) |
| 20:29:54 | × | dhil quits (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 246 seconds) |
| 20:30:50 | → | ulysses4ever joins (~artem@73.145.241.240) |
| 20:32:54 | × | artem quits (~artem@c-73-103-90-145.hsd1.in.comcast.net) (Ping timeout: 246 seconds) |
| 20:39:47 | → | artem joins (~artem@73.145.241.240) |
| 20:39:47 | × | ulysses4ever quits (~artem@73.145.241.240) (Read error: Connection reset by peer) |
| 20:40:10 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 20:47:41 | → | ulysses4ever joins (~artem@73.145.241.240) |
| 20:47:41 | × | artem quits (~artem@73.145.241.240) (Read error: Connection reset by peer) |
| 20:48:03 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 20:51:32 | × | coot quits (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 20:55:05 | × | NewtonTrendy quits (uid282092@user/bopqod) (Quit: Connection closed for inactivity) |
| 20:59:51 | × | jonathan__ quits (~jonathan@193.203.13.94) (Ping timeout: 246 seconds) |
| 21:03:11 | → | danza_ joins (~francesco@151.47.175.249) |
| 21:03:19 | → | sm joins (~sm@plaintextaccounting/sm) |
| 21:04:46 | × | ulysses4ever quits (~artem@73.145.241.240) (Ping timeout: 260 seconds) |
| 21:05:18 | × | danza quits (~francesco@151.47.168.22) (Ping timeout: 252 seconds) |
| 21:06:31 | × | bgs quits (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 21:17:22 | × | Pickchea quits (~private@user/pickchea) (Quit: Leaving) |
| 21:19:36 | × | sm quits (~sm@plaintextaccounting/sm) (Quit: sm) |
| 21:20:14 | → | Guest|16 joins (~Guest|16@174.27.143.6) |
| 21:22:55 | → | nate2 joins (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 21:28:00 | × | nate2 quits (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 21:28:01 | → | falafel joins (~falafel@216.68.6.51.dyn.plus.net) |
| 21:35:47 | × | michalz quits (~michalz@185.246.207.222) (Remote host closed the connection) |
| 21:42:50 | → | jargon joins (~jargon@174-22-213-62.phnx.qwest.net) |
| 21:44:02 | × | fendor quits (~fendor@2a02:8388:1640:be00:b586:6c06:a58:19a3) (Remote host closed the connection) |
| 21:45:39 | → | ulysses4ever joins (~artem@73.145.240.4) |
| 21:50:34 | → | NewtonTrendy joins (uid282092@user/bopqod) |
| 21:52:08 | → | arahael joins (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) |
| 21:52:37 | × | ulysses4ever quits (~artem@73.145.240.4) (Ping timeout: 260 seconds) |
| 21:54:09 | × | Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine) |
| 21:55:31 | → | Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915) |
| 21:59:09 | × | arahael quits (~arahael@119-18-1-27.771201.syd.nbn.aussiebb.net) (Ping timeout: 246 seconds) |
| 21:59:26 | → | mjt128 joins (~user@2604:3d09:3e79:f200:7249:9780:ed33:b6f3) |
| 22:03:06 | → | pavonia joins (~user@user/siracusa) |
| 22:05:38 | × | Guest|16 quits (~Guest|16@174.27.143.6) (Quit: Connection closed) |
| 22:06:47 | → | [_] joins (~itchyjunk@user/itchyjunk/x-7353470) |
| 22:07:02 | × | [itchyjunk] quits (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 245 seconds) |
| 22:19:43 | → | drewjose joins (~drewjose@2401:4900:1cc9:b527:b1a8:defb:8599:3a50) |
| 22:23:55 | × | gatekempt quits (~gatekempt@user/gatekempt) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:33:39 | → | ulysses4ever joins (~artem@2601:408:c405:52ad:f474:e3f8:9806:671) |
| 22:34:30 | → | Guest99 joins (~Guest99@apn-31-0-47-57.dynamic.gprs.plus.pl) |
| 22:38:05 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 22:38:22 | × | Guest99 quits (~Guest99@apn-31-0-47-57.dynamic.gprs.plus.pl) (Client Quit) |
| 22:39:36 | × | dibblego quits (~dibblego@haskell/developer/dibblego) (Ping timeout: 245 seconds) |
| 22:42:03 | × | ulysses4ever quits (~artem@2601:408:c405:52ad:f474:e3f8:9806:671) (Ping timeout: 246 seconds) |
| 22:43:39 | → | ulysses4ever joins (~artem@2601:408:c405:52ad:f474:e3f8:9806:671) |
| 22:43:55 | → | dibblego joins (~dibblego@116-255-1-151.ip4.superloop.au) |
| 22:43:55 | × | dibblego quits (~dibblego@116-255-1-151.ip4.superloop.au) (Changing host) |
| 22:43:55 | → | dibblego joins (~dibblego@haskell/developer/dibblego) |
| 22:44:53 | × | gmg quits (~user@user/gehmehgeh) (Quit: Leaving) |
| 22:49:49 | → | machinedgod joins (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 22:53:58 | → | artem joins (~artem@73.145.240.227) |
| 22:53:58 | × | ulysses4ever quits (~artem@2601:408:c405:52ad:f474:e3f8:9806:671) (Read error: Connection reset by peer) |
| 22:57:32 | → | mima joins (~mmh@62.216.211.35) |
| 22:59:55 | × | jle` quits (~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 246 seconds) |
| 23:01:59 | → | jle` joins (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
| 23:03:34 | × | acidjnk quits (~acidjnk@p200300d6e7072f62b0c5e6199a92dfb8.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 23:15:44 | × | jargon quits (~jargon@174-22-213-62.phnx.qwest.net) (Remote host closed the connection) |
| 23:17:28 | × | shapr quits (~user@2600:1700:c640:3100:65f2:5dc9:6ef9:713) (Remote host closed the connection) |
| 23:17:42 | → | shapr joins (~user@2600:1700:c640:3100:b3b0:6645:998e:257b) |
| 23:23:21 | × | ystael quits (~ystael@user/ystael) (Ping timeout: 245 seconds) |
| 23:23:46 | → | azimut joins (~azimut@gateway/tor-sasl/azimut) |
| 23:25:22 | × | machinedgod quits (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 23:31:55 | → | gatekempt joins (~gatekempt@user/gatekempt) |
| 23:33:26 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:75c0:69c6:c6bf:d46c) |
| 23:33:52 | → | myxos_ joins (~myxos@cpe-65-28-251-121.cinci.res.rr.com) |
| 23:33:56 | × | myxos_ quits (~myxos@cpe-65-28-251-121.cinci.res.rr.com) (Client Quit) |
| 23:34:50 | → | myxokephale joins (~myxos@cpe-65-28-251-121.cinci.res.rr.com) |
| 23:34:54 | × | juri_ quits (~juri@84-19-175-187.pool.ovpn.com) (Ping timeout: 246 seconds) |
| 23:35:01 | × | myxokephale quits (~myxos@cpe-65-28-251-121.cinci.res.rr.com) (Client Quit) |
| 23:37:43 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:75c0:69c6:c6bf:d46c) (Ping timeout: 246 seconds) |
| 23:41:50 | → | juri_ joins (~juri@79.140.117.208) |
| 23:44:02 | × | Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 23:44:24 | → | Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915) |
| 23:49:56 | × | Tuplanolla quits (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.) |
| 23:50:40 | → | mvk joins (~mvk@2607:fea8:5c9a:a600::1c6d) |
| 23:52:52 | × | juri_ quits (~juri@79.140.117.208) (Ping timeout: 244 seconds) |
| 23:54:54 | → | juri_ joins (~juri@84-19-175-187.pool.ovpn.com) |
All times are in UTC on 2023-08-21.