| 2022-10-29 00:00:13 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-10-29 00:00:13 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-10-29 00:00:13 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-29 00:03:44 +0200 | michalz | (~michalz@185.246.207.200) (Remote host closed the connection) |
| 2022-10-29 00:03:48 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds) |
| 2022-10-29 00:04:24 +0200 | fjmorazan | (~quassel@user/fjmorazan) () |
| 2022-10-29 00:05:08 +0200 | fjmorazan | (~quassel@user/fjmorazan) |
| 2022-10-29 00:06:25 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 246 seconds) |
| 2022-10-29 00:06:26 +0200 | talismanick | (~talismani@76.133.152.122) |
| 2022-10-29 00:07:30 +0200 | axeman | (~quassel@ip-037-201-153-145.um10.pools.vodafone-ip.de) |
| 2022-10-29 00:08:24 +0200 | acidjnk_new3 | (~acidjnk@p200300d6e7137a26d59898e5c9870d6b.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2022-10-29 00:09:44 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-10-29 00:11:20 +0200 | pavonia | (~user@user/siracusa) |
| 2022-10-29 00:11:39 +0200 | polo | (~polo@user/polo) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-10-29 00:12:07 +0200 | polo | (~polo@user/polo) |
| 2022-10-29 00:13:15 +0200 | <cpli> | is there some `TChan A -> TChan A -> TChan A` which fuses two channels? |
| 2022-10-29 00:13:28 +0200 | <cpli> | i.e. for writing purposes only |
| 2022-10-29 00:14:16 +0200 | <cpli> | dup and clone exist, would fusing require doing so on a seperate thread? |
| 2022-10-29 00:14:33 +0200 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:41f8:4e00:54f7:b844) |
| 2022-10-29 00:15:41 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 00:15:42 +0200 | <EvanR> | what does fusing for writing purpose mean |
| 2022-10-29 00:15:53 +0200 | <dminuoso> | Or for reading purposes. |
| 2022-10-29 00:16:06 +0200 | <EvanR> | or append purpose |
| 2022-10-29 00:16:10 +0200 | <dminuoso> | That is, if both channels have multiple things, in what order should they read? |
| 2022-10-29 00:16:40 +0200 | <dminuoso> | Looking at the internals, I think you can construct an interleaving TChan without a thread |
| 2022-10-29 00:16:54 +0200 | <DigitalKiwi> | no append only prepend |
| 2022-10-29 00:17:08 +0200 | <EvanR> | this is haskell we can only prepend |
| 2022-10-29 00:17:17 +0200 | <DigitalKiwi> | :D |
| 2022-10-29 00:17:58 +0200 | <EvanR> | haskellOS |
| 2022-10-29 00:18:09 +0200 | <EvanR> | all the files are stored backwards |
| 2022-10-29 00:18:35 +0200 | <dminuoso> | Well anyway, an interleaving TChan could be constructed if the internals were exposed in Control.Concurrent.STM.TChan |
| 2022-10-29 00:18:44 +0200 | <dminuoso> | But they are not, so I guess you're out of luck either way |
| 2022-10-29 00:18:53 +0200 | <dminuoso> | I dont see a way without a separate thread doing what you want |
| 2022-10-29 00:19:08 +0200 | <DigitalKiwi> | https://mostlyabsurd.com/files/2022-10-28-171849_964x357_scrot.png |
| 2022-10-29 00:19:08 +0200 | polo | (~polo@user/polo) (Ping timeout: 276 seconds) |
| 2022-10-29 00:20:16 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds) |
| 2022-10-29 00:20:53 +0200 | <cpli> | re:dminuoso "..., in what order should they read?"; in order they were written |
| 2022-10-29 00:21:07 +0200 | <dminuoso> | cpli: What does that even mean in STM? |
| 2022-10-29 00:22:27 +0200 | <cpli> | i have a `[Backend]` where `data Backend = B1 B1State | B2 B2State | B3...` |
| 2022-10-29 00:22:50 +0200 | <cpli> | each `Backend` broadcasts its event to all other backends |
| 2022-10-29 00:23:16 +0200 | <dsal> | "order" over distinct things (e.g., two threads with two channels) is a coincidence when you observe it. |
| 2022-10-29 00:23:22 +0200 | <cpli> | in some wrapper `data Event = E1 FromB1 | E2 FromB2` |
| 2022-10-29 00:23:48 +0200 | <cpli> | all backends are concurrently executed |
| 2022-10-29 00:23:59 +0200 | <dminuoso> | cpli: STM works differently |
| 2022-10-29 00:24:07 +0200 | <dminuoso> | It's not just barriers. |
| 2022-10-29 00:25:01 +0200 | <cpli> | is there any <10min read on how to impl async broadcasting? |
| 2022-10-29 00:25:51 +0200 | <dsal> | The stm docs are pretty clear. You just dup a chan and write to it. |
| 2022-10-29 00:26:05 +0200 | <monochrom> | There is no need to "merge" two TChans. Instead, to read from both TChans with "whichever one has a message first, read it", use atomically (fmap Left readTChan c1 <|> fmap Right readTChan c2) or equivalent. |
| 2022-10-29 00:26:08 +0200 | <int-e> | DigitalKiwi: 4 centuries earlier: REPENT! REPENT! |
| 2022-10-29 00:26:11 +0200 | <cpli> | if i write to a chan and immediately read, do i read my own message? |
| 2022-10-29 00:26:26 +0200 | <dsal> | https://hackage.haskell.org/package/stm-2.5.1.0/docs/Control-Concurrent-STM-TChan.html#v:dupTChan |
| 2022-10-29 00:26:45 +0200 | <dminuoso> | monochrom: Im not sure "first" really applies. |
| 2022-10-29 00:26:49 +0200 | <DigitalKiwi> | https://twitter.com/ArchKiwi/status/1586120762544398336 |
| 2022-10-29 00:27:05 +0200 | <monochrom> | Sure, s/first/"first" |
| 2022-10-29 00:27:14 +0200 | <dminuoso> | monochrom: Consider the case where first `c2` has a message, the stm transaction proceeds, but gets retried. |
| 2022-10-29 00:27:43 +0200 | <dminuoso> | Is there any guarantee c2 will be picked again, even if after retrying c1 has a message? |
| 2022-10-29 00:28:00 +0200 | <dsal> | cpli: maybe? You've not shown enough code to say for sure. |
| 2022-10-29 00:28:56 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Remote host closed the connection) |
| 2022-10-29 00:29:29 +0200 | <dsal> | dminuoso: I'm pretty sure that code won't read from c2 until c1 is empty. To make that fairer, you could put the channels in a queue of some sort and make sure each time a channel is read from it goes to the end of the list. |
| 2022-10-29 00:29:41 +0200 | <dsal> | Doing the go thing of "randomly pick a ready channel" might be a little harder. |
| 2022-10-29 00:29:52 +0200 | <dminuoso> | dsal: well, if c1 is empty at the time the transaction is started |
| 2022-10-29 00:30:00 +0200 | <dminuoso> | but has data when its retried. |
| 2022-10-29 00:30:23 +0200 | <dminuoso> | The only way I can see fairness is if you put them into a single list with a tag |
| 2022-10-29 00:30:28 +0200 | <dminuoso> | Then you can preserve the original order. |
| 2022-10-29 00:30:50 +0200 | <monochrom> | Oh the beauty is that every observation can be explained away by a fictional sequence, and you have no way to refute it, right? |
| 2022-10-29 00:31:00 +0200 | <monochrom> | or fictional history. |
| 2022-10-29 00:32:48 +0200 | thyriaen_ | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) |
| 2022-10-29 00:32:49 +0200 | buffet | (~buffet@buffet.sh) |
| 2022-10-29 00:32:52 +0200 | <dminuoso> | cpli: So yeah I guess thats the real answer. Keep a single TChan and have all write into that, and then each backend would have a dupTChan'ed or newBroadcastTChan'ed reader. |
| 2022-10-29 00:33:00 +0200 | <dsal> | I've never had to care about a particular ordering of channel ops, so I've not thought too much about avoiding having one get behind. One approach might be to atomically read from multiple and make a decision as to which one you want based on data inside. |
| 2022-10-29 00:33:23 +0200 | <dminuoso> | cpli: (so the merging happens by fact of just writing into a single TChan) |
| 2022-10-29 00:33:37 +0200 | <dsal> | Yeah, that's a lot easier. :) |
| 2022-10-29 00:33:41 +0200 | <monochrom> | Right? "Is c2 really ready earlier?" is just philosophy. The computer science question is "if empirically you get Right, can we restrospectively make up a story that says c2 is ready earlier?" and the answer is yes. |
| 2022-10-29 00:33:57 +0200 | polo | (~polo@user/polo) |
| 2022-10-29 00:34:42 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 00:34:52 +0200 | <dsal> | I've got into a lot of arguments with people who just want to overwrite the state with "whatever happened last" and it's really hard to explain to people how that doesn't work. |
| 2022-10-29 00:34:59 +0200 | <dminuoso> | cpli: more to the point, set up that `TChan Event` with newBroadcastTChan (instead of newTChan) and then dupChan it for every backend. :) |
| 2022-10-29 00:35:25 +0200 | <dminuoso> | dsal: You can just fling an IORef around! |
| 2022-10-29 00:35:53 +0200 | <dminuoso> | And to silence any arguments, unsafeIOtoSTM all evil operations and do this in STM for maximum confusion. |
| 2022-10-29 00:36:01 +0200 | <dsal> | A guy on my team once made a model of our system that let someone single step through every decision with business folks nodding that it was doing what they want and then get to the last bit and it all falls apart and they just assume it's a bug that needs to be fixed. |
| 2022-10-29 00:37:01 +0200 | <dsal> | You could always have a PNRG in your STM state and change the ordering along the way. |
| 2022-10-29 00:37:24 +0200 | pyrex | (~pyrex@user/pyrex) |
| 2022-10-29 00:39:17 +0200 | <dminuoso> | Why settle for a PRNG? |
| 2022-10-29 00:39:31 +0200 | <dminuoso> | unsafeIOtoSTM that quantum RNG :) |
| 2022-10-29 00:39:38 +0200 | <monochrom> | Haha |
| 2022-10-29 00:39:48 +0200 | <cpli> | dsal: not enough code |
| 2022-10-29 00:39:49 +0200 | <cpli> | run :: [Backend] → IO () |
| 2022-10-29 00:39:50 +0200 | <cpli> | run bs = let |
| 2022-10-29 00:39:50 +0200 | <cpli> | withChannel :: [(Chan Event, Backend)] |
| 2022-10-29 00:39:50 +0200 | <cpli> | withChannel = (newChan,) <$> bs |
| 2022-10-29 00:39:50 +0200 | <cpli> | -- what would i do here, such that |
| 2022-10-29 00:39:50 +0200 | <cpli> | -- bn <- bm where N /= M |
| 2022-10-29 00:39:50 +0200 | <cpli> | in mapConcurrently_ (uncurry runBackend) withChannel |
| 2022-10-29 00:39:51 +0200 | <cpli> | runBackend :: Chan Event → Backend → IO () |
| 2022-10-29 00:39:51 +0200 | <cpli> | runBackend ch (B1 b) = runB1 ch b |
| 2022-10-29 00:39:52 +0200 | <cpli> | runBackend ch (B2 b) = runB2 ch b |
| 2022-10-29 00:39:52 +0200 | <cpli> | -- ... |
| 2022-10-29 00:40:48 +0200 | <cpli> | dminuoso: if i simply `dupChan` then every backend needs to take `N-1` reading channels from all the other backends |
| 2022-10-29 00:41:00 +0200 | <dminuoso> | cpli: No, you seem to misunderstand. |
| 2022-10-29 00:41:01 +0200 | <monochrom> | That may break the Copenhagen interpretation >:) |
| 2022-10-29 00:41:04 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) |
| 2022-10-29 00:41:33 +0200 | <dminuoso> | cpli: First you start with one writer TChan, set it up with newBroadcastTChan (this is important!), this will get passed along to every backend. |
| 2022-10-29 00:41:47 +0200 | <cpli> | understood. |
| 2022-10-29 00:41:54 +0200 | <dminuoso> | cpli: Then, for every backend, you provide a dupTChan of that original chan, which will - for each backend - be a reader. |
| 2022-10-29 00:42:23 +0200 | <dminuoso> | s/for each backend/for each respective backend/ |
| 2022-10-29 00:43:04 +0200 | <dminuoso> | So if you want to broadcast, you write to that first writer tchan, and to listen to events you just read from that local reader tchan |
| 2022-10-29 00:43:52 +0200 | <dminuoso> | so each backend has exactly one writer and one reader channel |
| 2022-10-29 00:48:35 +0200 | <cpli> | and if i `runBackend1 :: Chan Event → Backend1 → IO () |
| 2022-10-29 00:48:35 +0200 | <cpli> | runBackend1 ch b = race (async (readChan ch)) awaitBackendEvent |
| 2022-10-29 00:48:49 +0200 | <cpli> | sorry for formatting |
| 2022-10-29 00:49:07 +0200 | <cpli> | that code isn't really done |
| 2022-10-29 00:49:23 +0200 | <cpli> | the idea is that events from the backend are then written into the channel again |
| 2022-10-29 00:50:27 +0200 | <cpli> | more akin to: |
| 2022-10-29 00:50:27 +0200 | <cpli> | runBackend1 :: Chan Event → Backend1 → IO () |
| 2022-10-29 00:50:27 +0200 | <cpli> | runBackend1 ch b = forever $ race (readChan ch) |
| 2022-10-29 00:50:27 +0200 | <cpli> | (writeChan ch =<< awaitBackendEvent) |
| 2022-10-29 00:51:31 +0200 | <cpli> | or in your case dminuoso: |
| 2022-10-29 00:51:33 +0200 | <cpli> | runBackend1 :: Chan Event → Chan Event → Backend1 → IO () |
| 2022-10-29 00:51:33 +0200 | <cpli> | runBackend1 wch rch b = forever $ race (readChan rch) |
| 2022-10-29 00:51:33 +0200 | <cpli> | (writeChan wch =<< awaitBackendEvent) |
| 2022-10-29 00:52:04 +0200 | <dminuoso> | That looks a bit strange |
| 2022-10-29 00:52:17 +0200 | <dminuoso> | Is the `rch` another channel? |
| 2022-10-29 00:52:21 +0200 | <cpli> | don't `Event`s from `wch` don't simply end up back in `rch`? |
| 2022-10-29 00:52:35 +0200 | <dminuoso> | Sure, you need to filter them out. |
| 2022-10-29 00:52:42 +0200 | <cpli> | and `unGet` them? |
| 2022-10-29 00:53:19 +0200 | <dminuoso> | No, you just read them again. |
| 2022-10-29 00:53:36 +0200 | <cpli> | oh true |
| 2022-10-29 00:53:41 +0200 | <cpli> | sure |
| 2022-10-29 00:53:55 +0200 | <cpli> | kind of a hassle to have to |
| 2022-10-29 00:54:17 +0200 | <cpli> | but the events are sure to arrive at the other threads nonetheless |
| 2022-10-29 00:54:31 +0200 | <dminuoso> | Of course, that's what dupTChan is for |
| 2022-10-29 00:54:43 +0200 | <dminuoso> | It lets you set up broadcast semantics exactly like that |
| 2022-10-29 00:54:53 +0200 | polo | (~polo@user/polo) (Ping timeout: 276 seconds) |
| 2022-10-29 00:56:32 +0200 | <cpli> | the entire idea with "fuse" would've been to do what you meant, i.e. to `newBroadcastTChan` then `dupTChan` until you'd have a list of "RChan"s from all *other backends* and fuse those together to create a `Chan` for `bn` which would only recieve all events from `bm` where `n /= m` |
| 2022-10-29 00:56:54 +0200 | <cpli> | but i guess just filtering out your own events is simpler |
| 2022-10-29 00:57:12 +0200 | <dminuoso> | Yup, it doesnt need a n helper threads to set up |
| 2022-10-29 00:57:36 +0200 | <dminuoso> | or I guess just a singular dispatcher thread |
| 2022-10-29 00:57:38 +0200 | <cpli> | probably possible to solve in data, no? |
| 2022-10-29 00:58:15 +0200 | <dminuoso> | I would only pursue the dispatcher model if you had more unicast semantics |
| 2022-10-29 00:58:20 +0200 | <dminuoso> | but if everything is broadcast, this is the simpler way |
| 2022-10-29 00:58:37 +0200 | <dminuoso> | cpli: Also, this model preserves event order properly |
| 2022-10-29 00:58:47 +0200 | <dminuoso> | your other approach does not |
| 2022-10-29 00:59:03 +0200 | <cpli> | *would* not, since it doesn't seem to exist |
| 2022-10-29 00:59:14 +0200 | <dminuoso> | of course it does. |
| 2022-10-29 00:59:24 +0200 | nek0 | (~nek0@2a01:4f8:222:2b41::12) |
| 2022-10-29 00:59:25 +0200 | <dminuoso> | its preserved in the order of which elements are read out |
| 2022-10-29 01:00:05 +0200 | <dminuoso> | I mean yeah, ultimately you could still have write problems if there's any coordination/communication between the backends with retries going on |
| 2022-10-29 01:00:11 +0200 | <cpli> | would an optimization be to include the read in the write case? i.e. immediately read after writing to the `Chan- i don't have guarantees about my event being next ever.. |
| 2022-10-29 01:00:30 +0200 | <dminuoso> | What do you mean "to include the read in the write case"? |
| 2022-10-29 01:00:46 +0200 | <dsal> | No, if you want to ignore particular messages, you have to ignore the particular messages. You can't rely on timing. |
| 2022-10-29 01:01:34 +0200 | <dminuoso> | Oh you mean as a means to consume the element you have just written? |
| 2022-10-29 01:02:37 +0200 | <cpli> | `bn` writes to `wch` and read from `rch`, `bm` will recieve the event, but `bn` also *will* recieve its own message, `bn` wouldn't need to read its message in its "read thread" if it could immediately could remove the message from `rch` |
| 2022-10-29 01:02:42 +0200 | <cpli> | but there's no guarantee |
| 2022-10-29 01:03:00 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:f81b:3b92:bbe7:93b6) (Remote host closed the connection) |
| 2022-10-29 01:03:33 +0200 | <cpli> | also `rch` could be clogged up anyway, with 15 events "in queue" in which case the event pushed to `wch` wouldn't be the next in line anyways |
| 2022-10-29 01:03:41 +0200 | <dminuoso> | cpli: https://gist.github.com/dminuoso/f42f92a27457088ce0d927175d7a21fc |
| 2022-10-29 01:03:43 +0200 | <dminuoso> | Something along these lines |
| 2022-10-29 01:03:55 +0200 | danza | (~francesco@151.68.150.173) (Ping timeout: 272 seconds) |
| 2022-10-29 01:04:34 +0200 | <dminuoso> | cpli: oh hold on by the way, we dont even need two separate TChans! |
| 2022-10-29 01:04:43 +0200 | <dminuoso> | Just the dupTChan'ed channel will serve both! |
| 2022-10-29 01:04:48 +0200 | <dminuoso> | simplifying things even further. |
| 2022-10-29 01:05:50 +0200 | <cpli> | `atomically` such that no events may be written to the channels whilst initializing them? |
| 2022-10-29 01:06:58 +0200 | <dminuoso> | cpli: No, its just that newBroadcastTChan must occur inside STM. |
| 2022-10-29 01:07:00 +0200 | <dminuoso> | And dupTChan |
| 2022-10-29 01:07:38 +0200 | <cpli> | what stops this from being non-STM, multithreading? |
| 2022-10-29 01:08:02 +0200 | <dminuoso> | cpli: Ive updated the gist, feel free to reload |
| 2022-10-29 01:08:35 +0200 | <dminuoso> | cpli: TChan is an STM data structure. |
| 2022-10-29 01:08:56 +0200 | <dminuoso> | You dont have to use STM everywhere, just in the few parts where you interact with it. |
| 2022-10-29 01:08:59 +0200 | redmp | (~redmp@eduroam-169-233-187-108.ucsc.edu) (Ping timeout: 272 seconds) |
| 2022-10-29 01:10:33 +0200 | j4cc3b | (~j4cc3b@pool-74-105-2-138.nwrknj.fios.verizon.net) |
| 2022-10-29 01:10:49 +0200 | <cpli> | "TChan", "STM.TChan". yes, and multithreading requires STM, I assume |
| 2022-10-29 01:11:00 +0200 | <dminuoso> | No, we have threads without STM just fine. |
| 2022-10-29 01:11:11 +0200 | <dminuoso> | STM is just the basis for most our synchronization tools. |
| 2022-10-29 01:11:23 +0200 | <dminuoso> | Think of STM as setting up transactions around critical sections. |
| 2022-10-29 01:11:55 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-10-29 01:12:00 +0200 | <dminuoso> | or well, avoiding the need for critical sections, even. |
| 2022-10-29 01:12:32 +0200 | <dminuoso> | cpli: Basically we have two things at our disposal: We have MVar and STM |
| 2022-10-29 01:12:34 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-10-29 01:13:46 +0200 | <dminuoso> | Both can help with synchronizing multiple threads. MVar is a really low level primitive that you can build higher primitives around (say like a semaphore), whereas STM is a potent high level framework (its not based on MVar, though) |
| 2022-10-29 01:13:54 +0200 | <cpli> | oh this is actually way cooler than i expected |
| 2022-10-29 01:14:18 +0200 | <cpli> | i require awaitEvent :: _ -> IO Event |
| 2022-10-29 01:14:29 +0200 | <cpli> | actually no |
| 2022-10-29 01:14:49 +0200 | <dminuoso> | Sure, just wrap the body in `atomically` then you can make it `IO Event` |
| 2022-10-29 01:14:57 +0200 | <cpli> | this may await an event from `b1` indefinitely |
| 2022-10-29 01:15:12 +0200 | <dminuoso> | Either would |
| 2022-10-29 01:15:12 +0200 | <cpli> | whilst `b2` is broadcasting |
| 2022-10-29 01:15:33 +0200 | <dminuoso> | Why would it?> |
| 2022-10-29 01:16:10 +0200 | <cpli> | if `b1` recieves an event `FromB1` it creates another `B1Event` |
| 2022-10-29 01:16:36 +0200 | <cpli> | otherwise `awaitEvent` return the event from `bn` |
| 2022-10-29 01:16:41 +0200 | Sgeo_ | (~Sgeo@user/sgeo) |
| 2022-10-29 01:16:41 +0200 | <dminuoso> | Well, each backend will likely have to run two separate threads, yes. |
| 2022-10-29 01:16:42 +0200 | danza | (~francesco@151.35.98.197) |
| 2022-10-29 01:16:58 +0200 | <cpli> | and `race` with Control.Concurrent |
| 2022-10-29 01:17:03 +0200 | <dminuoso> | Or you have some kind of event loop and use tryReadTChan instead |
| 2022-10-29 01:17:49 +0200 | <cpli> | i think for each backend to either be: |
| 2022-10-29 01:17:55 +0200 | <cpli> | 1. broadcasting its own event |
| 2022-10-29 01:18:07 +0200 | <cpli> | 2. processing an event it recieved |
| 2022-10-29 01:18:11 +0200 | <cpli> | is relatively elgant |
| 2022-10-29 01:18:39 +0200 | cpli | thinks their typos probably aren't exactly elegant |
| 2022-10-29 01:19:27 +0200 | jmorris | (uid537181@id-537181.uxbridge.irccloud.com) |
| 2022-10-29 01:19:53 +0200 | <dminuoso> | cpli: Updated gist |
| 2022-10-29 01:20:04 +0200 | Sgeo | (~Sgeo@user/sgeo) (Ping timeout: 250 seconds) |
| 2022-10-29 01:20:34 +0200 | <dminuoso> | Whether a simple `runBackend b = forever $ do r <- tryAwaitEvent ...` or STM variant instead makes more sense, depends on what you want to do exactly |
| 2022-10-29 01:20:49 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03) |
| 2022-10-29 01:21:09 +0200 | <dminuoso> | Also think ahead about things like termination |
| 2022-10-29 01:21:19 +0200 | <dminuoso> | Might want to include some kind of signaling layer in the event stream |
| 2022-10-29 01:21:38 +0200 | <dminuoso> | Such that the worker can just stop gracefully, perhaps release resources |
| 2022-10-29 01:21:59 +0200 | <cpli> | doesn't `TMChan` solve such a scenario? |
| 2022-10-29 01:22:35 +0200 | <dminuoso> | Sure, if you fancy that. |
| 2022-10-29 01:22:39 +0200 | <dminuoso> | I would probably just roll my own |
| 2022-10-29 01:23:01 +0200 | <cpli> | i have to admit i don't know why you're checking if eventTag e == backendTag (bwcBackend b) |
| 2022-10-29 01:23:11 +0200 | <dminuoso> | Writing such thing on the spot takes little effort and it helps keep dependency footprints small. And it lets you model your combinators the way you need to. |
| 2022-10-29 01:23:24 +0200 | <cpli> | if it recieves a message from itself it tries agai- |
| 2022-10-29 01:23:27 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-29 01:23:28 +0200 | <cpli> | makes sense. |
| 2022-10-29 01:24:29 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 258 seconds) |
| 2022-10-29 01:24:43 +0200 | <dminuoso> | cpli: For elaborate things, you may have to spawn two thread for each backend, potentially with TQueues or things between them for coordinations. |
| 2022-10-29 01:25:00 +0200 | <dminuoso> | This is all just different options, without knowing what these backends really do its hard to tell |
| 2022-10-29 01:25:01 +0200 | <cpli> | dminuoso the backends both come from relatively large dependencies, i've come this far only by scouting stackage for package versions that don't clash on their version of `ByteString` and downgrading from ghc 9.4.2 to 9.0.2 |
| 2022-10-29 01:25:15 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2022-10-29 01:25:42 +0200 | <cpli> | they're xmpp and irc |
| 2022-10-29 01:25:47 +0200 | <cpli> | i'm writing a bridge. |
| 2022-10-29 01:25:53 +0200 | <cpli> | cat's out the bag |
| 2022-10-29 01:26:04 +0200 | <dminuoso> | So there's just two backends then? |
| 2022-10-29 01:26:11 +0200 | <cpli> | well, extensibility |
| 2022-10-29 01:26:21 +0200 | <dminuoso> | As a kind of star bridge? |
| 2022-10-29 01:26:36 +0200 | <cpli> | currently my dhall config only lets you specify bots for either backend, but yes, a star bridge |
| 2022-10-29 01:26:44 +0200 | <cpli> | plans for discord etc |
| 2022-10-29 01:27:11 +0200 | <cpli> | the thing i want to implement really is proper puppeteering for irc |
| 2022-10-29 01:27:13 +0200 | <dminuoso> | cpli: I think I would just spawn two threads for each backend. |
| 2022-10-29 01:27:20 +0200 | <cpli> | exaclty |
| 2022-10-29 01:27:27 +0200 | <cpli> | s/cl/lc/ |
| 2022-10-29 01:27:28 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-10-29 01:27:38 +0200 | <dminuoso> | Haskell threads are really cheap, so go wild with them. |
| 2022-10-29 01:27:45 +0200 | <cpli> | they are? |
| 2022-10-29 01:27:53 +0200 | <dminuoso> | Yes, they are green threads. |
| 2022-10-29 01:28:32 +0200 | <cpli> | haskell knew of that color before go's implementation? |
| 2022-10-29 01:28:37 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 272 seconds) |
| 2022-10-29 01:29:01 +0200 | <dminuoso> | Honestly I dont know of the ethymology. :) |
| 2022-10-29 01:29:18 +0200 | <dminuoso> | Sorry I should refine. *GHC threads cheap |
| 2022-10-29 01:29:46 +0200 | <cpli> | it has something to do with async, where threads are coloured red or blue, and state needs to stay in one color |
| 2022-10-29 01:29:55 +0200 | <cpli> | but green sits on top ignoring all of that |
| 2022-10-29 01:30:07 +0200 | <dminuoso> | Im almost confident that the name is older than go. |
| 2022-10-29 01:30:46 +0200 | <cpli> | yup 1997: "Green threads refers to the name of the original thread library for the programming language Java (that was released in version 1.1 and then Green threads were abandoned in version 1.3 to native threads). It was designed by The Green Team at Sun Microsystems." |
| 2022-10-29 01:30:56 +0200 | <cpli> | from wikipedia the *free* encyclopedia |
| 2022-10-29 01:31:00 +0200 | <dminuoso> | https://web.archive.org/web/20080530073139/http://java.sun.com/features/1998/05/birthday.html |
| 2022-10-29 01:31:06 +0200 | <dminuoso> | Well I prefer citing the primary source. :) |
| 2022-10-29 01:31:20 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::f30b) (Ping timeout: 250 seconds) |
| 2022-10-29 01:31:48 +0200 | <cpli> | find on page: "green threads" 0/0 results |
| 2022-10-29 01:31:52 +0200 | <dminuoso> | Heh its funny, isnt it. |
| 2022-10-29 01:32:01 +0200 | <dminuoso> | Quality control at its finest |
| 2022-10-29 01:32:37 +0200 | <dminuoso> | cpli: the cool thing about the way things are implemented in haskell, is that you get the best of all worlds combined. |
| 2022-10-29 01:32:59 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection) |
| 2022-10-29 01:32:59 +0200 | thyriaen_ | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection) |
| 2022-10-29 01:33:29 +0200 | <dminuoso> | You can just use blocking IO in threads, and the RTS will be aware of that, use non-blockin IO behind the scenes, schedule threads when data is available again |
| 2022-10-29 01:33:44 +0200 | <dminuoso> | And you still get parallelism since GHC can use multiple capabilities |
| 2022-10-29 01:33:53 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 276 seconds) |
| 2022-10-29 01:33:55 +0200 | <jbggs[m]> | I thought red/blue functions was a different thing from green threads |
| 2022-10-29 01:34:16 +0200 | <dminuoso> | And when I say Haskell, I really mean GHC Haskell. |
| 2022-10-29 01:34:34 +0200 | <cpli> | systemFω here to save the day |
| 2022-10-29 01:35:03 +0200 | <jbggs[m]> | i.e. red functions are async functions, which in many languages are run on green threads |
| 2022-10-29 01:35:21 +0200 | <cpli> | jbggs[m]: i apologise, i relay uncited information. |
| 2022-10-29 01:35:35 +0200 | <jbggs[m]> | or at least can be |
| 2022-10-29 01:35:59 +0200 | <monochrom> | amd functions, intel functions, and nvidia threads? >:) |
| 2022-10-29 01:36:04 +0200 | <cpli> | dminuoso: this is the haskell irc, before i denounce things without thought |
| 2022-10-29 01:36:13 +0200 | <cpli> | do people here use compilers other than ghc? |
| 2022-10-29 01:36:21 +0200 | <dminuoso> | monochrom: If you want crazy terminology, look at ARINC 653. |
| 2022-10-29 01:36:55 +0200 | <jbggs[m]> | I think it's interesting that people are prone to thinking of these things with colors |
| 2022-10-29 01:36:56 +0200 | <jbggs[m]> | cpli: no harm no foul :D |
| 2022-10-29 01:37:11 +0200 | <dminuoso> | They contort established terminology to the point where they will sell you a "list" as an "OS process" (slightly exaggerating, but not by much) |
| 2022-10-29 01:37:25 +0200 | <monochrom> | Oh there are people who listen to music and see colours, too. |
| 2022-10-29 01:37:26 +0200 | mixfix41 | (~sdeny9ee@user/mixfix41) (Ping timeout: 260 seconds) |
| 2022-10-29 01:37:40 +0200 | <jbggs[m]> | I mean they're both functors right :V |
| 2022-10-29 01:37:50 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds) |
| 2022-10-29 01:38:08 +0200 | <jbggs[m]> | lists and OS processes i mean |
| 2022-10-29 01:38:12 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2022-10-29 01:38:18 +0200 | <cpli> | jbggs[m]: smells like 2-cats |
| 2022-10-29 01:38:45 +0200 | <cpli> | sorry, i meant 2d operads |
| 2022-10-29 01:38:49 +0200 | <jbggs[m]> | 2-cats? |
| 2022-10-29 01:39:11 +0200 | <EvanR> | cpli, within the atomically, it's like there are no other threads or they don't do anything that matters. So you read what you just wrote. If anything would have happened to change that, the atomically doesn't happen (retry) |
| 2022-10-29 01:39:54 +0200 | <dminuoso> | *semantically |
| 2022-10-29 01:39:56 +0200 | <jbggs[m]> | That's a new word for me, operad |
| 2022-10-29 01:39:58 +0200 | <cpli> | EvanR, if i remember anything correctly STM basically locks for any other thread trying to access the same memory region |
| 2022-10-29 01:40:05 +0200 | <dminuoso> | cpli: No. |
| 2022-10-29 01:40:08 +0200 | <cpli> | q-q |
| 2022-10-29 01:40:08 +0200 | <dminuoso> | cpli: its lock-free. |
| 2022-10-29 01:40:11 +0200 | <cpli> | q-q |
| 2022-10-29 01:40:16 +0200 | cpli | in awe |
| 2022-10-29 01:40:26 +0200 | <EvanR> | locking sounds like an implementation thing, which it doesn't use but really shouldn't matter to this story |
| 2022-10-29 01:40:29 +0200 | <cpli> | wait-free too? |
| 2022-10-29 01:40:38 +0200 | <monochrom> | Well, I'm fine with a suitable definition of "basically". |
| 2022-10-29 01:41:21 +0200 | <EvanR> | one slow implementation strategy is to run all STM actions sequentially, perhaps using a shared global lock |
| 2022-10-29 01:42:03 +0200 | <monochrom> | Basically, if you only notice final answers and don't notice speed, STM gives the same answer as locking. |
| 2022-10-29 01:42:18 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-29 01:42:28 +0200 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) |
| 2022-10-29 01:42:39 +0200 | <monochrom> | If you pay attention to speed, STM is sometimes faster than locking, sometimes slower. |
| 2022-10-29 01:42:42 +0200 | <cpli> | jbggs[m]: "cats" or categories, 2-cats are cats with 0-cells (your normal objects) 1-cells (arrows between your objects) and arrows between your objects etc. operads are a way to represent cells, which is another matter |
| 2022-10-29 01:43:22 +0200 | <EvanR> | do operads have anything to do with monads |
| 2022-10-29 01:43:38 +0200 | <monochrom> | Although, the sad thing is that the very word "transactional" in the very name has already told you how it does it, but people have never learned transactions, they have only learned locking. |
| 2022-10-29 01:43:53 +0200 | <cpli> | not necessarily, but also yes, unless they don't EvanR |
| 2022-10-29 01:44:18 +0200 | <EvanR> | that's the worst bit of category theory ever |
| 2022-10-29 01:45:16 +0200 | <cpli> | operads are just shapes that give you some way of "glueing" them together to get new shapes |
| 2022-10-29 01:45:31 +0200 | <cpli> | i.e. composition if you think of the edges of your shapes as arrows |
| 2022-10-29 01:45:52 +0200 | <cpli> | i.e. glueing from topology if you get really weird |
| 2022-10-29 01:46:00 +0200 | polo | (~polo@user/polo) |
| 2022-10-29 01:46:06 +0200 | <cpli> | i.e. homotopies if you haven't slept for 2 weeks |
| 2022-10-29 01:46:45 +0200 | <talismanick> | monochrom: "If you want to write CS research today, look at what the database people were doing 2 decades ago" |
| 2022-10-29 01:46:56 +0200 | <cpli> | monochrom, what does transactional entail? |
| 2022-10-29 01:47:00 +0200 | <talismanick> | I forget who said that, but the more I read, the more it rings true... |
| 2022-10-29 01:47:12 +0200 | <EvanR> | what database people other than mysql was doing 2 decades ago |
| 2022-10-29 01:47:13 +0200 | <cpli> | i.e. "ownership" in rust terms is always handed along? |
| 2022-10-29 01:47:22 +0200 | <talismanick> | cpli: ACIDity |
| 2022-10-29 01:47:41 +0200 | <EvanR> | the I in ACID corresponds to transactional |
| 2022-10-29 01:47:50 +0200 | <cpli> | of course it does |
| 2022-10-29 01:47:56 +0200 | <monochrom> | Learn "database transactions". If you don't see "roll back" you aren't learning transactions. |
| 2022-10-29 01:48:01 +0200 | polo | (~polo@user/polo) (Client Quit) |
| 2022-10-29 01:48:02 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-11.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-10-29 01:48:16 +0200 | <dminuoso> | Gosh, did Microsoft really remove SPJs papers website? :( |
| 2022-10-29 01:48:18 +0200 | <talismanick> | Or, at least, the A and I parts - C is up to the programmer, and D is outside the scope of STM |
| 2022-10-29 01:48:28 +0200 | <dminuoso> | I wish hyperlinks would just stay alive... |
| 2022-10-29 01:48:38 +0200 | <EvanR> | i was downloading spj papers from microsoft a couple weeks ago |
| 2022-10-29 01:48:56 +0200 | <cpli> | oh |
| 2022-10-29 01:49:22 +0200 | <monochrom> | I think https://simon.peytonjones.org/publications/ helps. |
| 2022-10-29 01:49:41 +0200 | <cpli> | start doing x, do x in y, if x fails, restore y |
| 2022-10-29 01:50:02 +0200 | <EvanR> | begin transaction; do whatever, do whatever, do whatever, commit |
| 2022-10-29 01:50:31 +0200 | <cpli> | or record y, do f, if f fails, restore y and override g's operation on y |
| 2022-10-29 01:50:32 +0200 | <EvanR> | let the database figure out how to interleave it all |
| 2022-10-29 01:50:55 +0200 | <EvanR> | while maintaining the invariants |
| 2022-10-29 01:51:24 +0200 | <cpli> | i guess `I` ruins my joke |
| 2022-10-29 01:51:44 +0200 | <dminuoso> | cpli: Anyway, the way GHC implements STM, is by just running the transactional code without any lock, along the way it records a transaction log of what it has does, and if at the end the log is consistent it will commit that to memory. |
| 2022-10-29 01:51:49 +0200 | <cpli> | how do you guarantee `I` on non-hardware-atomics? |
| 2022-10-29 01:51:55 +0200 | <cpli> | i.e. entire memory regions? |
| 2022-10-29 01:52:30 +0200 | <dminuoso> | And if it doesnt, it can retry that block. Given that it has a transactional log, it can then block until it *knows* that a dependent variable has changed (no need to retry if none of the read variables havent changed) |
| 2022-10-29 01:53:03 +0200 | <cpli> | dminuoso, oh, it's the weird "transform any algorithm into a wait-free algorithm vm" |
| 2022-10-29 01:53:21 +0200 | <dminuoso> | I do not know that transformation |
| 2022-10-29 01:53:30 +0200 | <cpli> | no? |
| 2022-10-29 01:53:34 +0200 | <cpli> | one-moment |
| 2022-10-29 01:53:48 +0200 | <EvanR> | what would wait free mean in this context |
| 2022-10-29 01:54:06 +0200 | <monochrom> | I know lock-free, I don't know wait-free. |
| 2022-10-29 01:54:08 +0200 | <cpli> | http://cs.technion.ac.il/~erez/Papers/wf-simulation-full.pdf |
| 2022-10-29 01:54:16 +0200 | <cpli> | wait, this turns lock-free into wait-free |
| 2022-10-29 01:54:22 +0200 | <cpli> | dammit |
| 2022-10-29 01:54:25 +0200 | <monochrom> | Wouldn't it be nice if vaccination clinics were wait-free >:) |
| 2022-10-29 01:54:41 +0200 | chomwitt | (~chomwitt@2a02:587:dc10:8200:1ac0:4dff:fedb:a3f1) (Ping timeout: 276 seconds) |
| 2022-10-29 01:55:14 +0200 | <dminuoso> | monochrom: They can be, just start coughing enough and ask loudly-but-not-too-loudly for the vaccination against your hot COVID infection. |
| 2022-10-29 01:55:22 +0200 | <talismanick> | cpli: so, wait-free means no live locks... ? |
| 2022-10-29 01:56:15 +0200 | <cpli> | wait-free is pseudo termination-guarantees |
| 2022-10-29 01:56:32 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-29 01:56:32 +0200 | <monochrom> | I think they would immediately send you home instead. But hey, "abort early, abort often" is more wait-free than "wait then abort anyway". |
| 2022-10-29 01:56:32 +0200 | <dminuoso> | cpli: Im not sure this really compares. One of the crucial things is that if the view of memory is not consistent (which it might be), it will retry. |
| 2022-10-29 01:57:09 +0200 | <cpli> | talismanick: `push` **will succeed** in n cpu-cycles |
| 2022-10-29 01:57:50 +0200 | <cpli> | dminuoso: how do you ensure termination? i.e. stop the vm from retrying indefinitely? |
| 2022-10-29 01:58:05 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 01:58:29 +0200 | <dminuoso> | cpli: two things: a) since a transaction log is kept, you can only retry when there's a possibility of obtaining a different result |
| 2022-10-29 01:58:42 +0200 | <monochrom> | In usage of STM we just ask for fairness, I think. |
| 2022-10-29 01:58:50 +0200 | <cpli> | dminuoso: interesting. |
| 2022-10-29 01:58:52 +0200 | <dminuoso> | b) just some optimism that concurrency is not crazy wild I suppose? |
| 2022-10-29 01:59:00 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-29 01:59:05 +0200 | <cpli> | B) |
| 2022-10-29 01:59:13 +0200 | <talismanick> | aaaaah, so it's the opposite of what I said - no deadlocks , but can have livelocks (each part succeeds in allotted time without being starved externally, but end up ping-pong'ing each other and cause the system to make no progress) |
| 2022-10-29 01:59:13 +0200 | <dminuoso> | I mean yeah, if you keep extremely large transactions, retrying will get more expensive |
| 2022-10-29 01:59:22 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds) |
| 2022-10-29 01:59:46 +0200 | <talismanick> | interesting |
| 2022-10-29 02:00:27 +0200 | <cpli> | talismanick, the guarantee applies to entire algorithms, i.e. only using wait-free makes you wait-free |
| 2022-10-29 02:00:37 +0200 | <EvanR> | cpli, nothing stops you from writing STM code that retries forever. Actually that's a handy way to get a dummy thread that does nothing |
| 2022-10-29 02:00:43 +0200 | <EvanR> | without busy looping |
| 2022-10-29 02:01:09 +0200 | <cpli> | EvanR do you have a simple example? that does sound fun |
| 2022-10-29 02:01:11 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-29 02:01:18 +0200 | <EvanR> | forever retry |
| 2022-10-29 02:01:24 +0200 | <dminuoso> | And unlike the naïve MVar variant, GHC wont "help you catch a bug" :p |
| 2022-10-29 02:01:29 +0200 | <cpli> | (mainly because a thread doing nothing is kind of useful in places- |
| 2022-10-29 02:01:40 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-10-29 02:01:41 +0200 | <cpli> | EvanR i.e. a haskell example |
| 2022-10-29 02:01:46 +0200 | <EvanR> | that's... haskell xD |
| 2022-10-29 02:01:49 +0200 | <cpli> | oh |
| 2022-10-29 02:01:50 +0200 | <dminuoso> | cpli: that was a haskell example. :) |
| 2022-10-29 02:01:57 +0200 | <talismanick> | EvanR: That reminds me a bit of a technique in a paper on OOP (the Actor Model back then, really) in Concurrent Prolog |
| 2022-10-29 02:02:06 +0200 | <cpli> | Control.Concurrent.retry? |
| 2022-10-29 02:02:09 +0200 | <dminuoso> | Isnt it lovely, how you can express a thought so vividly like `forever retry` |
| 2022-10-29 02:02:12 +0200 | <EvanR> | :t retry |
| 2022-10-29 02:02:14 +0200 | <lambdabot> | error: Variable not in scope: retry |
| 2022-10-29 02:02:23 +0200 | <geekosaur> | % :t retry |
| 2022-10-29 02:02:23 +0200 | <yahb2> | <interactive>:1:1: error: Variable not in scope: retry |
| 2022-10-29 02:02:24 +0200 | <dminuoso> | % import Control.Monad |
| 2022-10-29 02:02:24 +0200 | <yahb2> | <no output> |
| 2022-10-29 02:02:29 +0200 | <dminuoso> | % import GHC.Conc |
| 2022-10-29 02:02:30 +0200 | <yahb2> | <no output> |
| 2022-10-29 02:02:32 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds) |
| 2022-10-29 02:02:35 +0200 | <dminuoso> | % :t forever retry |
| 2022-10-29 02:02:35 +0200 | <yahb2> | forever retry :: STM b |
| 2022-10-29 02:02:51 +0200 | <cpli> | beautiful |
| 2022-10-29 02:02:58 +0200 | <dminuoso> | Is the `forever` even needed? |
| 2022-10-29 02:03:16 +0200 | ubert1 | (~Thunderbi@91.141.46.203.wireless.dyn.drei.com) |
| 2022-10-29 02:03:17 +0200 | <talismanick> | https://dl.acm.org/doi/10.1007/BF03037020 |
| 2022-10-29 02:03:19 +0200 | <monochrom> | Only one way to find out. Try. :) |
| 2022-10-29 02:03:21 +0200 | <cpli> | talismanick: concurrent prolog sounds wild. |
| 2022-10-29 02:03:22 +0200 | <dminuoso> | % print =<< (atomically retry :: STM ()) |
| 2022-10-29 02:03:23 +0200 | <yahb2> | <interactive>:20:12: error: ; • Couldn't match expected type: STM () ; with actual type: IO a0 ; • In the second argument of ‘(=<<)’, namely ; ‘(atomically retry :... |
| 2022-10-29 02:03:28 +0200 | <dminuoso> | % print =<< atomically (retry :: STM ()) |
| 2022-10-29 02:03:30 +0200 | <yahb2> | <interactive>:4:32: error: ; Not in scope: type constructor or class ‘STM’ |
| 2022-10-29 02:03:41 +0200 | <dminuoso> | % print =<< atomically retry |
| 2022-10-29 02:03:42 +0200 | <yahb2> | <interactive>:6:11: error: ; Variable not in scope: atomically :: t0 -> IO a0 ; ; <interactive>:6:22: error: Variable not in scope: retry |
| 2022-10-29 02:03:52 +0200 | <dminuoso> | % :t retry |
| 2022-10-29 02:03:53 +0200 | <yahb2> | <interactive>:1:1: error: Variable not in scope: retry |
| 2022-10-29 02:03:57 +0200 | ubert | (~Thunderbi@178.165.186.249.wireless.dyn.drei.com) (Ping timeout: 240 seconds) |
| 2022-10-29 02:03:57 +0200 | ubert1 | ubert |
| 2022-10-29 02:03:58 +0200 | <dminuoso> | % import Control.Monad |
| 2022-10-29 02:03:58 +0200 | <yahb2> | <no output> |
| 2022-10-29 02:04:00 +0200 | <dminuoso> | % import GHC.COnc |
| 2022-10-29 02:04:00 +0200 | <yahb2> | <no location info>: error: ; Could not find module ‘GHC.COnc’ ; Perhaps you meant GHC.Conc (from base-4.16.3.0) |
| 2022-10-29 02:04:02 +0200 | <dminuoso> | % import GHC.Conc |
| 2022-10-29 02:04:03 +0200 | <yahb2> | <no output> |
| 2022-10-29 02:04:16 +0200 | crns | (~netcrns@user/crns) (Ping timeout: 250 seconds) |
| 2022-10-29 02:04:17 +0200 | <dminuoso> | % print =<< atomically (retry :: STM ()) |
| 2022-10-29 02:04:19 +0200 | <yahb2> | <interactive>:4:32: error: ; Not in scope: type constructor or class ‘STM’ |
| 2022-10-29 02:04:28 +0200 | <dminuoso> | I do not know whats going on here. |
| 2022-10-29 02:04:29 +0200 | califax | (~califax@user/califx) |
| 2022-10-29 02:04:49 +0200 | <jbggs[m]> | Is this conversational AI |
| 2022-10-29 02:04:50 +0200 | <dminuoso> | *** Exception: thread blocked indefinitely in an STM transaction |
| 2022-10-29 02:04:59 +0200 | <monochrom> | Retry with Control.Concurrent.STM? :) |
| 2022-10-29 02:04:59 +0200 | <dminuoso> | EvanR: So I do not think this will actually work. |
| 2022-10-29 02:05:28 +0200 | dolio | (~dolio@130.44.134.54) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-29 02:05:30 +0200 | <dminuoso> | A similar detection as with MVar seems to be existing here, except I do not think you can work around this. |
| 2022-10-29 02:05:37 +0200 | <[Leary]> | There's no memory it depends on, so the retry will never happen. |
| 2022-10-29 02:05:58 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 02:06:12 +0200 | <EvanR> | looks like STM is too smart for me |
| 2022-10-29 02:06:34 +0200 | <[Leary]> | So the way to make it go forever is to have it read something but ignore it, while another thread can potentially change that thing? |
| 2022-10-29 02:06:37 +0200 | <EvanR> | forever retry generated some good puns though |
| 2022-10-29 02:06:43 +0200 | <cpli> | i'll be back in a bit, this was fun, i'll implement my star breech when i'm back |
| 2022-10-29 02:07:03 +0200 | dolio | (~dolio@130.44.134.54) |
| 2022-10-29 02:07:05 +0200 | <dminuoso> | EvanR: Know what you can do, however? |
| 2022-10-29 02:07:11 +0200 | <dminuoso> | % import Control.Monad |
| 2022-10-29 02:07:11 +0200 | <yahb2> | <no output> |
| 2022-10-29 02:07:13 +0200 | <dminuoso> | % import Data.Function |
| 2022-10-29 02:07:14 +0200 | <yahb2> | <no output> |
| 2022-10-29 02:07:16 +0200 | <dminuoso> | % forever fix error |
| 2022-10-29 02:07:19 +0200 | <yahb2> | <interactive>:4:1: error: ; Variable not in scope: forever :: t0 -> ([Char] -> a0) -> t ; ; <interactive>:4:9: error: Variable not in scope: fix |
| 2022-10-29 02:07:22 +0200 | dolio | (~dolio@130.44.134.54) (Client Quit) |
| 2022-10-29 02:07:33 +0200 | <monochrom> | Yeah, one transaction reads a TVar then goes "if it's 0, retry". Another thread runs "write 0 to that TVar" every once in a while. |
| 2022-10-29 02:07:36 +0200 | <dminuoso> | Okay, this would normally loop. Something is up with yahb here |
| 2022-10-29 02:08:22 +0200 | dolio | (~dolio@130.44.134.54) |
| 2022-10-29 02:08:28 +0200 | <dminuoso> | monochrom: I think doing the inverse is better. If its 0, retry, and have a signal handler write 1 to that tvar on sigterm. |
| 2022-10-29 02:08:35 +0200 | <monochrom> | Well, import Control.Monad and then can't find forever, that's an issue, yeah. |
| 2022-10-29 02:09:07 +0200 | <dminuoso> | monochrom: the delay suggests to me there's something killing the yahb instance (due to timeout, presumably), and perhaps re-inputing the last command. |
| 2022-10-29 02:09:17 +0200 | <monochrom> | I'm going to issue % :quit to see if it helps to, "have you turned it off and on again?" |
| 2022-10-29 02:09:21 +0200 | <monochrom> | % :quit |
| 2022-10-29 02:09:21 +0200 | <yahb2> | <no output> |
| 2022-10-29 02:09:33 +0200 | <EvanR> | % 1 `div` 0 |
| 2022-10-29 02:09:33 +0200 | <yahb2> | *** Exception: divide by zero |
| 2022-10-29 02:09:47 +0200 | <dminuoso> | Hold on. |
| 2022-10-29 02:09:51 +0200 | <dminuoso> | I thought you couldnt divide by zero? |
| 2022-10-29 02:09:53 +0200 | <EvanR> | yahb is more resilient than the idris bot |
| 2022-10-29 02:10:02 +0200 | <dminuoso> | I finally have the answer. Haskell shows me you can! |
| 2022-10-29 02:10:20 +0200 | <EvanR> | you can divide by zero on graphical linear algebra .net blog xD |
| 2022-10-29 02:10:48 +0200 | <monochrom> | I can divide by zero in Double. In fact I can do it two ways. :) |
| 2022-10-29 02:10:51 +0200 | <dminuoso> | If you divide by negative zero, do you get a negative bottom? |
| 2022-10-29 02:11:09 +0200 | crns | (~netcrns@p4ff5e2ab.dip0.t-ipconnect.de) |
| 2022-10-29 02:11:09 +0200 | crns | (~netcrns@p4ff5e2ab.dip0.t-ipconnect.de) (Changing host) |
| 2022-10-29 02:11:09 +0200 | crns | (~netcrns@user/crns) |
| 2022-10-29 02:11:14 +0200 | <dminuoso> | (and does a negative bottom converge?) |
| 2022-10-29 02:11:28 +0200 | <EvanR> | % 1 `div` (negate 0) < 0 |
| 2022-10-29 02:11:29 +0200 | <yahb2> | *** Exception: divide by zero |
| 2022-10-29 02:12:04 +0200 | <EvanR> | % 1 `div` negate 0 < 0 |
| 2022-10-29 02:12:05 +0200 | <yahb2> | *** Exception: divide by zero |
| 2022-10-29 02:12:44 +0200 | <EvanR> | not lazy enough |
| 2022-10-29 02:12:47 +0200 | <monochrom> | > sqrt (-0) |
| 2022-10-29 02:12:48 +0200 | <lambdabot> | -0.0 |
| 2022-10-29 02:12:49 +0200 | <dminuoso> | EvanR: So here comes the difficult thing. We may not see the real negative bottom. Imprecise exceptions means we can never know whether the error came from your division or not! |
| 2022-10-29 02:12:50 +0200 | <monochrom> | \∩/ |
| 2022-10-29 02:13:53 +0200 | <monochrom> | Blame theory says that it always came from someone else's division! |
| 2022-10-29 02:14:45 +0200 | <dminuoso> | Does that mean if my Haskell program bottoms out, I can never be liable for damages or injuries? |
| 2022-10-29 02:14:57 +0200 | <dminuoso> | (Provably) |
| 2022-10-29 02:15:35 +0200 | <geekosaur> | only if the bottom's exceptional |
| 2022-10-29 02:15:58 +0200 | <monochrom> | That's under the jurisdiction of legal theory, not blame theory. :) |
| 2022-10-29 02:17:26 +0200 | <EvanR> | there better not be any bottoms in the avionics software on my plane |
| 2022-10-29 02:17:32 +0200 | <EvanR> | of course, there probably are |
| 2022-10-29 02:18:25 +0200 | <EvanR> | dminuoso, aiui imprecise exceptions means when evaluating something that could bottom in several ways |
| 2022-10-29 02:19:12 +0200 | <EvanR> | one way is selected and that's what you get. But you might be able to know which is which |
| 2022-10-29 02:19:25 +0200 | <monochrom> | It's an abstraction. If an expression have several sources of exceptions, imprecise exception says one of them is nondeterministically chosen. |
| 2022-10-29 02:19:53 +0200 | <monochrom> | But clearly it is not very nondeterministic. If you find out the evaluation order, that settles it. |
| 2022-10-29 02:20:22 +0200 | <EvanR> | I mean you might get one of several different error messages (if any) |
| 2022-10-29 02:20:34 +0200 | <monochrom> | This is an abstraction façade to entitle the optimizer to do reordering. |
| 2022-10-29 02:20:59 +0200 | <dminuoso> | monochrom: It'll be easy to argue "this is an implementation detail", "lets just worry about language semantics" |
| 2022-10-29 02:21:00 +0200 | <EvanR> | it says it's non deterministic? |
| 2022-10-29 02:21:13 +0200 | <EvanR> | in some fancy technical sense? |
| 2022-10-29 02:21:14 +0200 | <dminuoso> | Otherwise I will just shift the blame (and damages) to the GHC team as being responsible for the implementation. |
| 2022-10-29 02:21:19 +0200 | <monochrom> | The same way we say "the OS nondeterministically chooses the next thread to run" but clearly it's deterministic once you know the actual scheduler and all the other 1 million factors. |
| 2022-10-29 02:21:22 +0200 | <dminuoso> | I will win this argument in court. |
| 2022-10-29 02:21:50 +0200 | <dminuoso> | monochrom: Okay, that means I must really buy a quantum RNG PCI card. |
| 2022-10-29 02:22:06 +0200 | <monochrom> | Oh, hiding an implementation detail is a case of abstraction, too. |
| 2022-10-29 02:22:06 +0200 | <dminuoso> | If evaluation order is chosen truly randomly, I have a way out. |
| 2022-10-29 02:24:21 +0200 | <monochrom> | Yes, to date, short of quantum computing, nondeterminism has always been a hide-implementation-details abstraction, in the very same sense as throwing a die is regarded nondeterministic just because no one bothers measuring all factors involved. |
| 2022-10-29 02:24:29 +0200 | <alexfmpe[m]> | as long as any evaluation order results in damages, you're liable according to a non-deterministic finite judge machine |
| 2022-10-29 02:25:51 +0200 | boxscape_ | (~boxscape@81.191.27.107) (Remote host closed the connection) |
| 2022-10-29 02:26:24 +0200 | <monochrom> | Although, beautifully, this abstraction inspires the beautiful theory of nondeterminisitc computing, which is pivotal in helping us frame very important questions on complexity. |
| 2022-10-29 02:29:05 +0200 | <monochrom> | It is also possible that the multiple-world interpretation of quantum computing still makes your quantum nondeterminism a hide-details abstraction, i.e., you are just ignorant of all the entanglements out there that affect you. |
| 2022-10-29 02:29:22 +0200 | <dolio> | That's not the only one. |
| 2022-10-29 02:29:55 +0200 | j4cc3b | (~j4cc3b@pool-74-105-2-138.nwrknj.fios.verizon.net) (Quit: Client closed) |
| 2022-10-29 02:36:05 +0200 | nate3 | (~nate@98.45.169.16) |
| 2022-10-29 02:36:08 +0200 | slack1256 | (~slack1256@181.42.52.169) |
| 2022-10-29 02:40:29 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-10-29 02:40:29 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-10-29 02:40:29 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-29 02:40:58 +0200 | nate3 | (~nate@98.45.169.16) (Ping timeout: 255 seconds) |
| 2022-10-29 02:48:09 +0200 | Kaiepi | (~Kaiepi@108.175.84.104) (Ping timeout: 255 seconds) |
| 2022-10-29 02:52:57 +0200 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 240 seconds) |
| 2022-10-29 03:03:11 +0200 | redmp | (~redmp@mobile-166-170-43-64.mycingular.net) |
| 2022-10-29 03:04:38 +0200 | nate3 | (~nate@98.45.169.16) |
| 2022-10-29 03:06:14 +0200 | xff0x | (~xff0x@2405:6580:b080:900:2e5f:ef77:7c98:ca52) (Ping timeout: 250 seconds) |
| 2022-10-29 03:08:47 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 276 seconds) |
| 2022-10-29 03:09:29 +0200 | money | (sid532813@user/polo) () |
| 2022-10-29 03:09:57 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 272 seconds) |
| 2022-10-29 03:10:39 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-10-29 03:16:45 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-10-29 03:18:54 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 03:18:54 +0200 | xff0x | (~xff0x@2405:6580:b080:900:2e5f:ef77:7c98:ca52) |
| 2022-10-29 03:23:34 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds) |
| 2022-10-29 03:24:03 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-29 03:24:28 +0200 | money | (sid532813@user/polo) |
| 2022-10-29 03:25:42 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 03:33:23 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-10-29 03:33:44 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-29 03:42:09 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2022-10-29 03:42:43 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2022-10-29 03:43:50 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2022-10-29 03:45:25 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 272 seconds) |
| 2022-10-29 03:53:02 +0200 | axeman | (~quassel@ip-037-201-153-145.um10.pools.vodafone-ip.de) (Ping timeout: 250 seconds) |
| 2022-10-29 03:58:05 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 272 seconds) |
| 2022-10-29 04:03:52 +0200 | nate3 | (~nate@98.45.169.16) (Ping timeout: 250 seconds) |
| 2022-10-29 04:07:26 +0200 | money | polo |
| 2022-10-29 04:08:22 +0200 | td_ | (~td@83.135.9.42) (Ping timeout: 252 seconds) |
| 2022-10-29 04:10:05 +0200 | td_ | (~td@83.135.9.7) |
| 2022-10-29 04:10:26 +0200 | causal | (~user@50.35.83.177) (Quit: WeeChat 3.6) |
| 2022-10-29 04:12:39 +0200 | slack1256 | (~slack1256@181.42.52.169) (Ping timeout: 272 seconds) |
| 2022-10-29 04:17:43 +0200 | crns | (~netcrns@user/crns) (Ping timeout: 272 seconds) |
| 2022-10-29 04:19:23 +0200 | crns | (~netcrns@p5dc33ed0.dip0.t-ipconnect.de) |
| 2022-10-29 04:19:23 +0200 | crns | (~netcrns@p5dc33ed0.dip0.t-ipconnect.de) (Changing host) |
| 2022-10-29 04:19:23 +0200 | crns | (~netcrns@user/crns) |
| 2022-10-29 04:22:56 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds) |
| 2022-10-29 04:26:37 +0200 | frost75 | (~frost@user/frost) |
| 2022-10-29 04:30:02 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 04:32:17 +0200 | Kaiepi | (~Kaiepi@108.175.84.104) |
| 2022-10-29 04:34:38 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds) |
| 2022-10-29 04:37:18 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 04:43:24 +0200 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat) |
| 2022-10-29 04:44:44 +0200 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 2022-10-29 04:45:14 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-10-29 04:45:14 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-29 04:57:21 +0200 | constxd | (~brad@47.55.121.233) (Quit: WeeChat 2.8) |
| 2022-10-29 05:01:09 +0200 | danza | (~francesco@151.35.98.197) (Read error: Connection reset by peer) |
| 2022-10-29 05:03:25 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-10-29 05:05:45 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-29 05:06:16 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 250 seconds) |
| 2022-10-29 05:16:11 +0200 | tiziodcaio | (~tiziodcai@2001:470:69fc:105::1:2bf8) |
| 2022-10-29 05:16:12 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-10-29 05:16:41 +0200 | danza | (~francesco@bo-18-136-28.service.infuturo.it) |
| 2022-10-29 05:17:59 +0200 | king_gs | (~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) |
| 2022-10-29 05:18:10 +0200 | jargon | (~jargon@184.101.90.242) |
| 2022-10-29 05:21:01 +0200 | bilegeek | (~bilegeek@2600:1008:b027:7f32:a99b:c297:feda:8531) (Quit: Leaving) |
| 2022-10-29 05:30:31 +0200 | td_ | (~td@83.135.9.7) (Ping timeout: 246 seconds) |
| 2022-10-29 05:32:33 +0200 | td_ | (~td@83.135.9.8) |
| 2022-10-29 05:36:10 +0200 | Kaiepi | (~Kaiepi@108.175.84.104) (Ping timeout: 250 seconds) |
| 2022-10-29 05:45:16 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds) |
| 2022-10-29 05:46:32 +0200 | johnw | (~johnw@2600:1700:cf00:db0:24dd:7cba:243c:c819) (Quit: ZNC - http://znc.in) |
| 2022-10-29 05:46:34 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-10-29 05:46:34 +0200 | litharge | (litharge@libera/bot/litharge) (*.net *.split) |
| 2022-10-29 05:52:34 +0200 | litharge | (litharge@libera/bot/litharge) |
| 2022-10-29 05:54:24 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-29 05:55:37 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-29 05:55:37 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-10-29 05:55:37 +0200 | finn_elija | FinnElija |
| 2022-10-29 05:58:26 +0200 | king_gs | (~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) (Ping timeout: 276 seconds) |
| 2022-10-29 06:05:56 +0200 | frost75 | (~frost@user/frost) (Quit: Client closed) |
| 2022-10-29 06:10:46 +0200 | king_gs | (~Thunderbi@187.201.83.115) |
| 2022-10-29 06:12:38 +0200 | flukiluke | (~m-7humut@2603:c023:c000:6c7e:8945:ad24:9113:a962) (Remote host closed the connection) |
| 2022-10-29 06:12:59 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2022-10-29 06:13:41 +0200 | flukiluke | (~m-7humut@2603:c023:c000:6c7e:8945:ad24:9113:a962) |
| 2022-10-29 06:14:08 +0200 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-29 06:17:25 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 272 seconds) |
| 2022-10-29 06:28:36 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 250 seconds) |
| 2022-10-29 06:30:01 +0200 | Vajb | (~Vajb@85-76-71-213-nat.elisa-mobile.fi) (Read error: Connection reset by peer) |
| 2022-10-29 06:30:14 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-10-29 06:35:03 +0200 | Kaiepi | (~Kaiepi@108.175.84.104) |
| 2022-10-29 06:51:27 +0200 | src36 | (~src@176.53.146.40) |
| 2022-10-29 06:52:27 +0200 | src36 | (~src@176.53.146.40) (Client Quit) |
| 2022-10-29 06:58:00 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2022-10-29 07:08:39 +0200 | <dsal> | I'm using sqlite-simple in an app and would really like to add postgres support. All the options seem pretty invasive. What do people like these days? |
| 2022-10-29 07:09:21 +0200 | redmp | (~redmp@mobile-166-170-43-64.mycingular.net) (Ping timeout: 272 seconds) |
| 2022-10-29 07:12:01 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-10-29 07:12:12 +0200 | Vajb | (~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) |
| 2022-10-29 07:15:51 +0200 | monochrom | (trebla@216.138.220.146) (Quit: NO CARRIER) |
| 2022-10-29 07:23:50 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-10-29 07:24:49 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds) |
| 2022-10-29 07:24:49 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-29 07:24:54 +0200 | <kronicmage> | @pf \(a, b) (c, d) -> (a+c, b+d) |
| 2022-10-29 07:24:54 +0200 | <lambdabot> | Maybe you meant: pl bf |
| 2022-10-29 07:25:00 +0200 | <kronicmage> | @pl \(a, b) (c, d) -> (a+c, b+d) |
| 2022-10-29 07:25:01 +0200 | <lambdabot> | uncurry (flip flip snd . (ap .) . flip flip fst . ((.) .) . (. (+)) . flip . (((.) . (,)) .) . (+)) |
| 2022-10-29 07:25:16 +0200 | <kronicmage> | ouch |
| 2022-10-29 07:28:04 +0200 | monochrom | (trebla@216.138.220.146) |
| 2022-10-29 07:28:16 +0200 | <dsal> | :t bimap (+) (+) |
| 2022-10-29 07:28:18 +0200 | <lambdabot> | (Bifunctor p, Num a1, Num a2) => p a1 a2 -> p (a1 -> a1) (a2 -> a2) |
| 2022-10-29 07:39:14 +0200 | jmorris | (uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-29 07:52:45 +0200 | nate3 | (~nate@98.45.169.16) |
| 2022-10-29 08:03:09 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-10-29 08:04:49 +0200 | king_gs | (~Thunderbi@187.201.83.115) (Read error: Connection reset by peer) |
| 2022-10-29 08:05:28 +0200 | king_gs | (~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) |
| 2022-10-29 08:15:57 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-10-29 08:25:07 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-29 08:30:25 +0200 | nate3 | (~nate@98.45.169.16) (Ping timeout: 272 seconds) |
| 2022-10-29 08:35:49 +0200 | birdgoose | (~jesse@2406:e003:1d87:6601:e725:b6b4:ace8:4ebe) (Quit: Konversation terminated!) |
| 2022-10-29 08:36:07 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 258 seconds) |
| 2022-10-29 08:38:01 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-29 08:57:35 +0200 | king_gs | (~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) (Quit: king_gs) |
| 2022-10-29 08:58:30 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 255 seconds) |
| 2022-10-29 08:59:22 +0200 | rembo10 | (~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-29 09:01:55 +0200 | rembo10 | (~rembo10@main.remulis.com) |
| 2022-10-29 09:03:44 +0200 | danza | (~francesco@bo-18-136-28.service.infuturo.it) (Ping timeout: 250 seconds) |
| 2022-10-29 09:05:00 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-10-29 09:09:03 +0200 | Kaiepi | (~Kaiepi@108.175.84.104) (Ping timeout: 272 seconds) |
| 2022-10-29 09:16:59 +0200 | danza | (~francesco@151.57.22.153) |
| 2022-10-29 09:19:31 +0200 | jtomas | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) |
| 2022-10-29 09:20:42 +0200 | Kaiepi | (~Kaiepi@108.175.84.104) |
| 2022-10-29 09:21:43 +0200 | danza | (~francesco@151.57.22.153) (Read error: Connection reset by peer) |
| 2022-10-29 09:31:47 +0200 | mixfix41 | (~sdeny9ee@user/mixfix41) |
| 2022-10-29 09:37:23 +0200 | acidjnk_new3 | (~acidjnk@p200300d6e7137a26b5cba7005e8744f0.dip0.t-ipconnect.de) |
| 2022-10-29 09:38:38 +0200 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-10-29 09:39:57 +0200 | zaquest | (~notzaques@5.130.79.72) |
| 2022-10-29 09:42:57 +0200 | jargon | (~jargon@184.101.90.242) (Remote host closed the connection) |
| 2022-10-29 09:43:11 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-10-29 09:49:12 +0200 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) |
| 2022-10-29 10:02:01 +0200 | acidjnk_new3 | (~acidjnk@p200300d6e7137a26b5cba7005e8744f0.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-10-29 10:08:24 +0200 | vglfr | (~vglfr@145.224.100.22) |
| 2022-10-29 10:09:10 +0200 | titibandit | (~titibandi@xdsl-87-79-250-160.nc.de) |
| 2022-10-29 10:09:28 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2022-10-29 10:11:50 +0200 | polo | Gambino |
| 2022-10-29 10:15:14 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2022-10-29 10:19:51 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03) (Remote host closed the connection) |
| 2022-10-29 10:21:52 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-29 10:34:03 +0200 | Sgeo_ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-10-29 10:36:13 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-11.elisa-laajakaista.fi) |
| 2022-10-29 10:43:24 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2022-10-29 10:54:31 +0200 | Unhammer | (~Unhammer@user/unhammer) (Ping timeout: 260 seconds) |
| 2022-10-29 10:55:20 +0200 | Batzy | (~quassel@user/batzy) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-29 10:55:43 +0200 | Batzy | (~quassel@user/batzy) |
| 2022-10-29 10:57:17 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) |
| 2022-10-29 10:57:18 +0200 | Batzy | (~quassel@user/batzy) (Client Quit) |
| 2022-10-29 10:57:43 +0200 | Batzy | (~quassel@user/batzy) |
| 2022-10-29 10:59:11 +0200 | vglfr | (~vglfr@145.224.100.22) (Remote host closed the connection) |
| 2022-10-29 10:59:46 +0200 | vglfr | (~vglfr@145.224.100.22) |
| 2022-10-29 11:04:54 +0200 | freeside | (~mengwong@122.11.214.174) |
| 2022-10-29 11:08:29 +0200 | Unhammer | (~Unhammer@user/unhammer) |
| 2022-10-29 11:09:08 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2022-10-29 11:11:44 +0200 | tcard_ | (~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9) (Read error: Connection reset by peer) |
| 2022-10-29 11:11:44 +0200 | tcard__ | (~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9) |
| 2022-10-29 11:15:27 +0200 | AkechiShiro | (~licht@user/akechishiro) |
| 2022-10-29 11:17:32 +0200 | zeenk | (~zeenk@2a02:2f04:a105:5d00:c862:f190:2ea:d494) |
| 2022-10-29 11:18:13 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-10-29 11:20:19 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03) |
| 2022-10-29 11:24:15 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Quit: Leaving) |
| 2022-10-29 11:24:42 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03) (Ping timeout: 252 seconds) |
| 2022-10-29 11:25:46 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds) |
| 2022-10-29 11:26:00 +0200 | titibandit | (~titibandi@xdsl-87-79-250-160.nc.de) (Remote host closed the connection) |
| 2022-10-29 11:27:00 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) |
| 2022-10-29 11:27:12 +0200 | CiaoSen | (~Jura@p200300c95724d3002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-10-29 11:27:17 +0200 | titibandit | (~titibandi@xdsl-87-79-250-160.nc.de) |
| 2022-10-29 11:28:44 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-10-29 11:30:10 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection) |
| 2022-10-29 11:31:15 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) |
| 2022-10-29 11:44:11 +0200 | titibandit | (~titibandi@xdsl-87-79-250-160.nc.de) (Quit: Leaving.) |
| 2022-10-29 11:45:58 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection) |
| 2022-10-29 11:46:16 +0200 | <dminuoso> | dsal: You can also just additionally load hasql, implement queries for both backends, and just keep a database independent layer in between. |
| 2022-10-29 11:46:32 +0200 | <dminuoso> | Just dont succumb to postgresql-simple. |
| 2022-10-29 11:46:41 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) |
| 2022-10-29 11:48:49 +0200 | <dminuoso> | With a bit of discipline you can probably reuse most queries across them |
| 2022-10-29 11:49:10 +0200 | biberu | (~biberu@user/biberu) (Read error: Connection reset by peer) |
| 2022-10-29 11:49:55 +0200 | <dminuoso> | Otherwise hdbc is a thing, its not overly terrible |
| 2022-10-29 11:50:33 +0200 | jtomas | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 272 seconds) |
| 2022-10-29 11:57:02 +0200 | titibandit | (~titibandi@xdsl-87-79-250-160.nc.de) |
| 2022-10-29 11:59:30 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-10-29 12:02:05 +0200 | biberu | (~biberu@user/biberu) |
| 2022-10-29 12:02:57 +0200 | ubert | (~Thunderbi@91.141.46.203.wireless.dyn.drei.com) (Ping timeout: 240 seconds) |
| 2022-10-29 12:05:02 +0200 | <fendor[m]> | Can I have something akin to rewrite rules for type family application? E.g., I have type level functions Append and RemoveLast, and I want `forall p . RemoveLast (Append p 'Z) ~ p` to hold |
| 2022-10-29 12:05:46 +0200 | <fendor[m]> | or do I need a type-plugin that fixes that adds this simplification for me? |
| 2022-10-29 12:07:39 +0200 | freeside | (~mengwong@122.11.214.174) (Ping timeout: 272 seconds) |
| 2022-10-29 12:14:01 +0200 | <[Leary]> | fendor[m]: I'm not sure if there are better ways, but if you use defunctionalised type families you can write these rules into the definitions of `RemoveLast` and `Append`. |
| 2022-10-29 12:14:43 +0200 | <probie> | As a hack, I've often added those sort of things as assertions at the use site (I remember at one point needing `Reverse (Reverse xs) ~ xs`), which works well enough if their use is internal and not exposed to a user of one's library |
| 2022-10-29 12:15:41 +0200 | <fendor[m]> | [Leary]: Any resources on how to defunctionalise type families? |
| 2022-10-29 12:15:53 +0200 | <fendor[m]> | probie: that sounds curious, I am fine with terrible UX for now |
| 2022-10-29 12:16:16 +0200 | zer0bitz | (~zer0bitz@2001:2003:f748:2000:99dc:7f1f:c53d:641d) (Read error: Connection reset by peer) |
| 2022-10-29 12:18:35 +0200 | <[Leary]> | fendor[m]: It's been a while since I read about it, I forget where. But this looks alright: https://free.cofree.io/2019/01/08/defunctionalization/ |
| 2022-10-29 12:18:51 +0200 | <fendor[m]> | thank you! |
| 2022-10-29 12:19:14 +0200 | zer0bitz | (~zer0bitz@2001:2003:f748:2000:5894:8e10:5893:ce6f) |
| 2022-10-29 12:20:48 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 252 seconds) |
| 2022-10-29 12:29:12 +0200 | burakcank | Guest283 |
| 2022-10-29 12:30:35 +0200 | frost14 | (~frost@user/frost) |
| 2022-10-29 12:31:35 +0200 | tcard__ | (~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9) (Quit: Leaving) |
| 2022-10-29 12:32:32 +0200 | CiaoSen | (~Jura@p200300c95724d3002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-10-29 12:32:36 +0200 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2022-10-29 12:36:32 +0200 | tcard | (~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9) |
| 2022-10-29 12:39:29 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-10-29 12:40:04 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-10-29 12:40:04 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Remote host closed the connection) |
| 2022-10-29 12:41:28 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-29 12:45:54 +0200 | jtomas | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) |
| 2022-10-29 12:46:11 +0200 | __monty__ | (~toonn@user/toonn) |
| 2022-10-29 12:53:21 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-29 13:09:00 +0200 | danza | (~francesco@151.35.235.74) |
| 2022-10-29 13:12:43 +0200 | janlely | (~janlely@122.231.201.44) |
| 2022-10-29 13:16:00 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 264 seconds) |
| 2022-10-29 13:16:48 +0200 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 250 seconds) |
| 2022-10-29 13:17:55 +0200 | beteigeuze | (~Thunderbi@89.187.168.47) |
| 2022-10-29 13:21:09 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2022-10-29 13:25:50 +0200 | acidjnk | (~acidjnk@p200300d6e7137a2658873e742925ddf0.dip0.t-ipconnect.de) |
| 2022-10-29 13:36:10 +0200 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) (Quit: .) |
| 2022-10-29 13:37:55 +0200 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) |
| 2022-10-29 13:43:15 +0200 | <dminuoso> | fendor[m]: The only equivalent of rewrite rules I know of is typechecker plugins. |
| 2022-10-29 13:44:58 +0200 | CiaoSen | (~Jura@p200300c95724d3002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-10-29 13:49:37 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-10-29 13:57:52 +0200 | titibandit | (~titibandi@xdsl-87-79-250-160.nc.de) (Quit: Leaving.) |
| 2022-10-29 13:59:16 +0200 | <fendor[m]> | typechecker plugin it is! |
| 2022-10-29 13:59:16 +0200 | <fendor[m]> | will make it actually easier |
| 2022-10-29 13:59:17 +0200 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 240 seconds) |
| 2022-10-29 14:05:42 +0200 | frost14 | (~frost@user/frost) (Ping timeout: 244 seconds) |
| 2022-10-29 14:05:59 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-29 14:11:08 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 276 seconds) |
| 2022-10-29 14:19:09 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2022-10-29 14:19:09 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-10-29 14:20:39 +0200 | vglfr | (~vglfr@145.224.100.22) (Ping timeout: 272 seconds) |
| 2022-10-29 14:21:37 +0200 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 240 seconds) |
| 2022-10-29 14:22:19 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-10-29 14:22:38 +0200 | califax | (~califax@user/califx) |
| 2022-10-29 14:24:10 +0200 | titibandit | (~titibandi@xdsl-87-79-250-160.nc.de) |
| 2022-10-29 14:26:41 +0200 | cyphase | (~cyphase@user/cyphase) |
| 2022-10-29 14:30:02 +0200 | jlgw | (~jw@83-233-104-81.cust.bredband2.com) |
| 2022-10-29 14:37:44 +0200 | <jlgw> | Hi, I'm trying to remap ctrl-j in ghci, but any time I enter a remap of ctrl-j (e.g. adding `bind: ctrl-j down` in ~/.haskeline) the return key is also remapped. I don't get this issue for other remaps (e.g. `bind: ctrl-k up`) and it's not an issue I've encountered in GNU readline. I've skimmed through the haskeline docs and the open issues but I haven't found anything relevant. Any tips on a solution or further reading? |
| 2022-10-29 14:39:11 +0200 | vglfr | (~vglfr@145.224.100.22) |
| 2022-10-29 14:42:27 +0200 | <fendor[m]> | huh, the defunctionatalisation approach looks very promising, too |
| 2022-10-29 14:45:49 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-10-29 14:56:03 +0200 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) (Quit: Stop) |
| 2022-10-29 14:57:46 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2022-10-29 15:02:23 +0200 | shapr | (~user@144.163.4.141) |
| 2022-10-29 15:03:17 +0200 | <MangoIV[m]> | <fendor[m]> "Any resources on how to defuncti..." <- there's a library, `first-class-families`, you can have a look at. It's probably faster than reading 10 blogposts. |
| 2022-10-29 15:03:20 +0200 | <MangoIV[m]> | * there's a (imho really good) library, `first-class-families`, |
| 2022-10-29 15:03:38 +0200 | <fendor[m]> | ooh, nice! |
| 2022-10-29 15:03:39 +0200 | <MangoIV[m]> | https://flora.pm/packages/@hackage/first-class-families |
| 2022-10-29 15:03:50 +0200 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 250 seconds) |
| 2022-10-29 15:03:52 +0200 | <fendor[m]> | haha, nice, flora 🙂 |
| 2022-10-29 15:04:12 +0200 | <MangoIV[m]> | yes, I am a flora power user. |
| 2022-10-29 15:05:01 +0200 | fendor[m] | uploaded an image: (174KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/IpizUwRetSGlZXTMURjQtqkm/image.png > |
| 2022-10-29 15:05:01 +0200 | <fendor[m]> | I remember reading that on discord 😄 I am immediately filing a layout bug report |
| 2022-10-29 15:05:48 +0200 | MangoIV[m] | uploaded an image: (427KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/hEogonwbNYLOUdvCDHRzMPwW/image.png > |
| 2022-10-29 15:05:48 +0200 | <MangoIV[m]> | might as well just ping Hecate, they will probably be able to help you, for me it doesn't look like that: |
| 2022-10-29 15:06:27 +0200 | <fendor[m]> | will do, thank you very much! |
| 2022-10-29 15:06:47 +0200 | <MangoIV[m]> | you're very welcome :) |
| 2022-10-29 15:07:33 +0200 | phma | (~phma@2001:5b0:212a:cc58:94b0:45f6:bc48:ff7d) (Read error: Connection reset by peer) |
| 2022-10-29 15:08:08 +0200 | phma | (~phma@host-67-44-208-99.hnremote.net) |
| 2022-10-29 15:15:22 +0200 | acidjnk | (~acidjnk@p200300d6e7137a2658873e742925ddf0.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2022-10-29 15:16:56 +0200 | infinity0 | (~infinity0@pwned.gg) |
| 2022-10-29 15:23:52 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 15:31:33 +0200 | phma_ | (~phma@2001:5b0:211f:2dc8:ca7e:3ef3:1458:a7b3) |
| 2022-10-29 15:36:01 +0200 | phma | (~phma@host-67-44-208-99.hnremote.net) (Ping timeout: 272 seconds) |
| 2022-10-29 15:36:23 +0200 | zeenk | (~zeenk@2a02:2f04:a105:5d00:c862:f190:2ea:d494) (Quit: Konversation terminated!) |
| 2022-10-29 15:50:29 +0200 | causal | (~user@50.35.83.177) |
| 2022-10-29 15:54:18 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Remote host closed the connection) |
| 2022-10-29 15:58:52 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-10-29 15:59:26 +0200 | jonathanx | (~jonathan@host-78-78-169-236.mobileonline.telia.com) |
| 2022-10-29 16:07:21 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-29 16:10:10 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-10-29 16:15:20 +0200 | jonathanx | (~jonathan@host-78-78-169-236.mobileonline.telia.com) (Ping timeout: 250 seconds) |
| 2022-10-29 16:22:51 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2022-10-29 16:24:46 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03) |
| 2022-10-29 16:29:21 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03) (Ping timeout: 260 seconds) |
| 2022-10-29 16:32:13 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-10-29 16:40:54 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 250 seconds) |
| 2022-10-29 16:41:01 +0200 | beteigeuze1 | (~Thunderbi@89.187.168.50) |
| 2022-10-29 16:43:47 +0200 | beteigeuze | (~Thunderbi@89.187.168.47) (Ping timeout: 272 seconds) |
| 2022-10-29 16:44:32 +0200 | titibandit | (~titibandi@xdsl-87-79-250-160.nc.de) (Remote host closed the connection) |
| 2022-10-29 16:45:40 +0200 | beteigeuze1 | (~Thunderbi@89.187.168.50) (Ping timeout: 250 seconds) |
| 2022-10-29 16:50:39 +0200 | tiziodcaio | (~tiziodcai@2001:470:69fc:105::1:2bf8) (Quit: Reconnecting) |
| 2022-10-29 16:51:09 +0200 | gqplox | (~textual@2a02:c7c:941d:fd00:40a0:1c9d:7a12:f334) |
| 2022-10-29 16:59:02 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-10-29 17:00:02 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-10-29 17:00:36 +0200 | danza | (~francesco@151.35.235.74) (Read error: Connection reset by peer) |
| 2022-10-29 17:06:24 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) |
| 2022-10-29 17:06:49 +0200 | <zzz> | weird. it looks fine to me on linux firefox but not on chromium |
| 2022-10-29 17:06:51 +0200 | tiziodcaio | (~tiziodcai@2001:470:69fc:105::1:2bf8) |
| 2022-10-29 17:08:53 +0200 | <zzz> | Hecate: there's also an extra space at the beginning of each code block: https://shot.jrvieira.com/1667056109.png |
| 2022-10-29 17:11:45 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-29 17:16:41 +0200 | danza | (~francesco@151.68.163.113) |
| 2022-10-29 17:17:40 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-10-29 17:28:20 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-10-29 17:30:57 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-29 17:31:44 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::f30b) |
| 2022-10-29 17:32:10 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-29 17:32:36 +0200 | img | (~img@user/img) |
| 2022-10-29 17:33:30 +0200 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2022-10-29 17:34:58 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-10-29 17:38:20 +0200 | CiaoSen | (~Jura@p200300c95724d3002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-10-29 17:39:06 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-10-29 17:43:15 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-29 17:43:21 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-29 17:44:17 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds) |
| 2022-10-29 17:56:10 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-10-29 17:57:10 +0200 | acidjnk | (~acidjnk@p200300d6e7137a24c5c90248eaa00c2d.dip0.t-ipconnect.de) |
| 2022-10-29 17:57:11 +0200 | danza | (~francesco@151.68.163.113) (Read error: Connection reset by peer) |
| 2022-10-29 17:59:20 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 250 seconds) |
| 2022-10-29 18:00:06 +0200 | Las[m] | (~lasmatrix@2001:470:69fc:105::74e) |
| 2022-10-29 18:03:00 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-10-29 18:03:44 +0200 | califax | (~califax@user/califx) |
| 2022-10-29 18:04:36 +0200 | michalz | (~michalz@185.246.207.221) |
| 2022-10-29 18:11:09 +0200 | chomwitt | (~chomwitt@athe730-c-multi-217.home.otenet.gr) |
| 2022-10-29 18:11:57 +0200 | acidjnk | (~acidjnk@p200300d6e7137a24c5c90248eaa00c2d.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-10-29 18:18:08 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 276 seconds) |
| 2022-10-29 18:19:24 +0200 | econo | (uid147250@user/econo) |
| 2022-10-29 18:29:26 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-10-29 18:29:26 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-10-29 18:29:26 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-29 18:32:42 +0200 | shapr | (~user@144.163.4.141) (Ping timeout: 250 seconds) |
| 2022-10-29 18:47:54 +0200 | danza | (~francesco@151.68.168.242) |
| 2022-10-29 18:55:20 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03) |
| 2022-10-29 18:57:50 +0200 | mixfix41 | (~sdeny9ee@user/mixfix41) (Ping timeout: 250 seconds) |
| 2022-10-29 19:00:49 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-10-29 19:02:11 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-29 19:02:15 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-29 19:03:56 +0200 | glguy | (~glguy@libera/staff-emeritus/glguy) (Ping timeout: 260 seconds) |
| 2022-10-29 19:06:55 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 272 seconds) |
| 2022-10-29 19:09:26 +0200 | nate3 | (~nate@98.45.169.16) |
| 2022-10-29 19:10:08 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 276 seconds) |
| 2022-10-29 19:11:03 +0200 | glguy | (~glguy@libera/staff-emeritus/glguy) |
| 2022-10-29 19:15:11 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-10-29 19:17:46 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 250 seconds) |
| 2022-10-29 19:18:30 +0200 | Buliarous | (~gypsydang@46.232.210.139) |
| 2022-10-29 19:20:51 +0200 | glguy | (~glguy@libera/staff-emeritus/glguy) (Ping timeout: 260 seconds) |
| 2022-10-29 19:20:58 +0200 | Buliarous | (~gypsydang@46.232.210.139) (Client Quit) |
| 2022-10-29 19:21:41 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-10-29 19:21:41 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-10-29 19:21:41 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-29 19:23:16 +0200 | dimsuz | (~dima@185.17.131.16) |
| 2022-10-29 19:24:11 +0200 | <EvanR> | dminuoso, whats wrong with postgresql-simple |
| 2022-10-29 19:24:53 +0200 | glguy | (~glguy@libera/staff-emeritus/glguy) |
| 2022-10-29 19:25:58 +0200 | <dimsuz> | hi! learing to parse with megaparsec. Struggling to turn this: ""@@header@@\nline\nline\line\n@@header@@\nline\nline"" into [Hunk{header,[lines]}]. I have working parser for "header" and then I'm trying to sepBy header, but also need to not consume it while sepBy-ing... Need advice/direction. |
| 2022-10-29 19:27:07 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2022-10-29 19:30:40 +0200 | <EvanR> | hmm I would not start with sepBy for that |
| 2022-10-29 19:31:11 +0200 | <EvanR> | if you have a parser for header body optional newlines/whitespace, then you can use many on that to get a list |
| 2022-10-29 19:33:44 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-10-29 19:33:45 +0200 | <dimsuz> | oh, that gives me an idea that I should write a separate parser for body. not sure though if I should make it know that it should stop if it sees 'header'. megaparsec has "notFollowedBy", maybe I should use it |
| 2022-10-29 19:34:36 +0200 | danza | (~francesco@151.68.168.242) (Ping timeout: 264 seconds) |
| 2022-10-29 19:34:46 +0200 | <EvanR> | if it that lines can't start with @@? or @@header@@ |
| 2022-10-29 19:34:50 +0200 | <EvanR> | or something else |
| 2022-10-29 19:36:15 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-10-29 19:36:36 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2022-10-29 19:36:50 +0200 | <EvanR> | you could make a line parser that fails if the first two characters is @@ |
| 2022-10-29 19:38:17 +0200 | moonsheep | (~user@user/moonsheep) |
| 2022-10-29 19:39:10 +0200 | <dimsuz> | yes, it's a diff hunk parser, so headers are stuff like "@@ +3,44 -8,55 @@", then go the lines separated by '\n', then goes another hunk (header+lines) |
| 2022-10-29 19:39:12 +0200 | <EvanR> | thunk hunk parser would be, header followed by many lines |
| 2022-10-29 19:39:24 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-10-29 19:39:32 +0200 | <EvanR> | then hunk parser would be, header followed by many lines |
| 2022-10-29 19:39:45 +0200 | <EvanR> | the word hunk is throwing me off heavily |
| 2022-10-29 19:39:52 +0200 | <dimsuz> | oh, and line parser failing wouldn't fail whole parsing? |
| 2022-10-29 19:39:59 +0200 | <moonsheep> | for some procedure that may fail (i.e. a protocol of some sort) what is the best way to back out in case of an unrecoverable failure? there seems to be so many options and I never know which to pick: Alternative, MonadFail, MonadError, etc. |
| 2022-10-29 19:40:19 +0200 | <dimsuz> | "hunk" is diff speak :) not sure why they're called taht |
| 2022-10-29 19:40:21 +0200 | <EvanR> | that's how many works, it tries the parser repeatedly until it fails |
| 2022-10-29 19:40:27 +0200 | acidjnk | (~acidjnk@p200300d6e7137a24f4d49bb670ebec41.dip0.t-ipconnect.de) |
| 2022-10-29 19:40:40 +0200 | <dimsuz> | EvanR: thanks, going off to try this |
| 2022-10-29 19:40:45 +0200 | <EvanR> | when you use the basic combinator p1 <|> p2, p1 is tried, if it fails p2 is tried, if that fails p1 <|> p2 fails |
| 2022-10-29 19:41:05 +0200 | <EvanR> | something like that is going on within many |
| 2022-10-29 19:41:09 +0200 | <dimsuz> | yep, I understand it for <|> but somehow didn't intuitively undrstood it for many |
| 2022-10-29 19:41:18 +0200 | <moonsheep> | on a related note, that seems like the main advantage of Alternative, but I'm not sure if it plays nice with IO |
| 2022-10-29 19:41:47 +0200 | <EvanR> | moonsheep, if you're in IO, you could throw an IO exception xD |
| 2022-10-29 19:42:08 +0200 | <EvanR> | if you're in pure code, something like Except or ExceptT |
| 2022-10-29 19:42:15 +0200 | <moonsheep> | I am in a MonadUnliftIO |
| 2022-10-29 19:42:22 +0200 | <EvanR> | if you're in a sophisticated monad transformer... |
| 2022-10-29 19:42:30 +0200 | <moonsheep> | pretty much |
| 2022-10-29 19:42:45 +0200 | <EvanR> | consult your sophisticated monad transformer manual / service representative |
| 2022-10-29 19:42:52 +0200 | <moonsheep> | hmm right |
| 2022-10-29 19:43:15 +0200 | <moonsheep> | well, MonadError "feels" like it was built exactly for this kind of scenario |
| 2022-10-29 19:43:20 +0200 | <int-e> | don't get yourself into a bind |
| 2022-10-29 19:45:02 +0200 | <[Leary]> | moonsheep: The unliftio paradigm already has its own opinions about how exceptions should be produced and recovered from, as I recall. If you're in that world already, it's probably worth heeding. |
| 2022-10-29 19:45:16 +0200 | <moonsheep> | so I should use IO exceptions? |
| 2022-10-29 19:46:07 +0200 | <moonsheep> | I have some finallys that always have to fire at the end of all things, no matter what, and I was scared that they would interact weirdly with other things |
| 2022-10-29 19:46:14 +0200 | <EvanR> | wait that's not what we were saying at all |
| 2022-10-29 19:46:35 +0200 | <moonsheep> | well what are those "opinions on how exceptions should be produced"? |
| 2022-10-29 19:46:37 +0200 | <EvanR> | I haven't used MonadUnliftIO but there's probably some more appropriate exception mechanism |
| 2022-10-29 19:46:46 +0200 | <EvanR> | for that |
| 2022-10-29 19:47:33 +0200 | ddellacosta | (~ddellacos@89.45.224.247) |
| 2022-10-29 19:47:37 +0200 | <moonsheep> | unliftio does have a handy "throwString", should I just use that for one-off errors? |
| 2022-10-29 19:49:45 +0200 | <EvanR> | it looks like throwIO is recommended if you have your own exception type, else if you can't be arsed use throwString |
| 2022-10-29 19:50:13 +0200 | <moonsheep> | right |
| 2022-10-29 19:50:21 +0200 | <moonsheep> | sounds like a decent plan |
| 2022-10-29 19:50:29 +0200 | <EvanR> | has the same effect as fromEither if you are converting an Either into an exception |
| 2022-10-29 19:52:54 +0200 | ddellacosta | (~ddellacos@89.45.224.247) (Ping timeout: 252 seconds) |
| 2022-10-29 19:54:23 +0200 | <EvanR> | looks like they reference and depend on the package safe-exceptions |
| 2022-10-29 19:56:24 +0200 | <EvanR> | which claims that by default exception handling is scary |
| 2022-10-29 19:57:10 +0200 | <EvanR> | which kind of sounds like bootstrapping its own purpose |
| 2022-10-29 19:58:46 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Remote host closed the connection) |
| 2022-10-29 20:00:33 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) |
| 2022-10-29 20:00:49 +0200 | <geekosaur> | exception handling by default is scary |
| 2022-10-29 20:00:50 +0200 | <moonsheep> | yeah that's kind of the point of unliftioo |
| 2022-10-29 20:01:23 +0200 | <geekosaur> | and bracket, which issupposed to hide some of that scariness, propitiates it instead |
| 2022-10-29 20:02:10 +0200 | <sm> | g'day all |
| 2022-10-29 20:02:26 +0200 | wroathe | (~wroathe@50.205.197.50) |
| 2022-10-29 20:02:26 +0200 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2022-10-29 20:02:26 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-29 20:03:11 +0200 | <sm> | is there an easy way to get a human-friendly hash of a haskell value, eg of a Data instance ? |
| 2022-10-29 20:04:25 +0200 | <moonsheep> | does it have to be cryptographically secure? |
| 2022-10-29 20:04:38 +0200 | <sm> | not really |
| 2022-10-29 20:04:39 +0200 | <sm> | no, not at all |
| 2022-10-29 20:04:45 +0200 | <moonsheep> | what about Hashable then? |
| 2022-10-29 20:04:49 +0200 | talismanick | (~talismani@76.133.152.122) (Ping timeout: 246 seconds) |
| 2022-10-29 20:04:57 +0200 | <sm> | it's more important that it be fairly reliably unique |
| 2022-10-29 20:05:27 +0200 | <sm> | I found that, but I think it produces an integer ? I'm wanting something more alphanumeric |
| 2022-10-29 20:05:36 +0200 | <moonsheep> | well Hashable doesn't do any guarantees on the algorithm used |
| 2022-10-29 20:05:53 +0200 | <EvanR> | render the Integer in hex xD |
| 2022-10-29 20:06:17 +0200 | <EvanR> | I guess that doesn't guarantee there will be letters |
| 2022-10-29 20:06:32 +0200 | <moonsheep> | I mean, the representation you use is largely irrelevant |
| 2022-10-29 20:06:48 +0200 | <moonsheep> | if your issue is that integers are too small you could use a bytestring I guess |
| 2022-10-29 20:07:36 +0200 | <sm> | this is something users will see, I want it to look like familiar, like an md5 hash |
| 2022-10-29 20:08:13 +0200 | <sm> | would md5 be wrong for this ? |
| 2022-10-29 20:08:25 +0200 | <moonsheep> | so then are you asking for a way to represent integers as strings in some base (like base16)? |
| 2022-10-29 20:08:42 +0200 | <moonsheep> | sm: md5 is vulnerable to collision attacks, but if those aren't a problem then it's fine |
| 2022-10-29 20:08:50 +0200 | <sm> | concretely, people want to see a unique content-based hash for each of their hledger transactions |
| 2022-10-29 20:08:50 +0200 | <[Leary]> | I would just render the integer in base64. |
| 2022-10-29 20:09:31 +0200 | <moonsheep> | yeah base64 is pretty nice |
| 2022-10-29 20:09:33 +0200 | <sm> | hashable + base64, that sounds like an option |
| 2022-10-29 20:09:38 +0200 | <moonsheep> | I wonder why hashes aren't more often represented like that |
| 2022-10-29 20:09:53 +0200 | <moonsheep> | it's always base16 for some reason |
| 2022-10-29 20:10:38 +0200 | <moonsheep> | well I guess padding =s sure |
| 2022-10-29 20:11:30 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-10-29 20:12:49 +0200 | <sm> | https://hackage.haskell.org/package/pureMD5 might be plan B |
| 2022-10-29 20:13:12 +0200 | <sm> | (with custom haskell value -> hash generator, which I expect I'll need anyway) |
| 2022-10-29 20:13:16 +0200 | <sm> | thanks all |
| 2022-10-29 20:13:26 +0200 | <darkling> | If we're generating IDs that are going to be turned into base64 strings for human consumption, we always make sure they're a multiple of 3 bytes, so there's no trailing = symbols. |
| 2022-10-29 20:15:16 +0200 | <EvanR> | moonsheep, bespoke ways to display hashes or IDs abound in web land, perhaps you would be interested in applying for a job at amazon to learn more. Don't think call now |
| 2022-10-29 20:16:24 +0200 | <moonsheep> | darkling: if you know the length in advance you don't really need the trailing = |
| 2022-10-29 20:17:18 +0200 | <moonsheep> | EvanR: one day |
| 2022-10-29 20:18:29 +0200 | nate3 | (~nate@98.45.169.16) (Ping timeout: 272 seconds) |
| 2022-10-29 20:18:50 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-10-29 20:25:30 +0200 | AlexNoo_ | (~AlexNoo@178.34.163.109) |
| 2022-10-29 20:27:11 +0200 | Alex_test | (~al_test@178.34.162.124) (Ping timeout: 244 seconds) |
| 2022-10-29 20:27:44 +0200 | danza | (~francesco@151.68.168.242) |
| 2022-10-29 20:28:48 +0200 | AlexNoo | (~AlexNoo@178.34.162.124) (Ping timeout: 255 seconds) |
| 2022-10-29 20:28:58 +0200 | AlexZenon | (~alzenon@178.34.162.124) (Ping timeout: 246 seconds) |
| 2022-10-29 20:30:45 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-10-29 20:31:33 +0200 | Alex_test | (~al_test@178.34.163.109) |
| 2022-10-29 20:32:26 +0200 | cowboy8625 | (~cowboy@rrcs-173-198-134-163.west.biz.rr.com) |
| 2022-10-29 20:36:47 +0200 | AlexZenon | (~alzenon@178.34.163.109) |
| 2022-10-29 20:38:09 +0200 | <dimsuz> | EvanR: thanks for the help with parser combinators, it all worked out beautifully. Feeling good, going for a walk. Cheers! |
| 2022-10-29 20:38:34 +0200 | dimsuz | (~dima@185.17.131.16) (Quit: leaving) |
| 2022-10-29 20:41:45 +0200 | son0p | (~ff@181.136.122.143) (Remote host closed the connection) |
| 2022-10-29 20:44:23 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::f30b) (Ping timeout: 276 seconds) |
| 2022-10-29 20:45:34 +0200 | nate3 | (~nate@98.45.169.16) |
| 2022-10-29 20:47:25 +0200 | danza | (~francesco@151.68.168.242) (Read error: Connection reset by peer) |
| 2022-10-29 20:54:08 +0200 | acidjnk | (~acidjnk@p200300d6e7137a24f4d49bb670ebec41.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-10-29 20:54:35 +0200 | nate3 | (~nate@98.45.169.16) (Ping timeout: 272 seconds) |
| 2022-10-29 20:55:35 +0200 | AlexNoo_ | AlexNoo |
| 2022-10-29 20:56:14 +0200 | <APic> | Guad Nocht! |
| 2022-10-29 21:03:05 +0200 | <EvanR> | sometimes you see proposals to add something like monads, do notation, or something like just State monad to language X. If they could only steal one thing I would settle for Functor |
| 2022-10-29 21:03:37 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 240 seconds) |
| 2022-10-29 21:03:48 +0200 | <EvanR> | spread the news about Functor please because it's large scale missing too |
| 2022-10-29 21:03:52 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-10-29 21:04:12 +0200 | <EvanR> | and much more widely applicable |
| 2022-10-29 21:04:40 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-10-29 21:06:33 +0200 | <EvanR> | geekosaur, what's wrong with bracket? |
| 2022-10-29 21:06:48 +0200 | moonsheep | (~user@user/moonsheep) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.2)) |
| 2022-10-29 21:07:13 +0200 | moonsheep | (~user@185.154.9.186) |
| 2022-10-29 21:07:26 +0200 | moonsheep | (~user@185.154.9.186) () |
| 2022-10-29 21:07:34 +0200 | <geekosaur> | IIRC a missing `mask` in the recovery/after-close part means an exception there can leak resources |
| 2022-10-29 21:08:00 +0200 | <geekosaur> | and it won't be fixed because "someone might be relying on it running without `mask`" |
| 2022-10-29 21:08:43 +0200 | <EvanR> | that does sound a bit dubious |
| 2022-10-29 21:08:53 +0200 | <c_wraith> | I think you have to mask the whole bracket and strategically unmask to make it work right, too |
| 2022-10-29 21:09:09 +0200 | <c_wraith> | Like, you can't just mask in the release action, because that still leaves a gap |
| 2022-10-29 21:09:19 +0200 | <geekosaur> | https://stackoverflow.com/questions/64468126/how-to-make-bracket-safe-from-async-exception |
| 2022-10-29 21:09:25 +0200 | <geekosaur> | yeh |
| 2022-10-29 21:09:31 +0200 | <EvanR> | it is specific to async exceptions |
| 2022-10-29 21:09:32 +0200 | <geekosaur> | this is more or less why unliftio |
| 2022-10-29 21:09:51 +0200 | <c_wraith> | well yes. async exceptions are the only thing mask stops |
| 2022-10-29 21:10:46 +0200 | <geekosaur> | but async exceptions are also essentially the only thing that can lead to resource leaks (unless you're really careless) |
| 2022-10-29 21:10:47 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-10-29 21:11:04 +0200 | <c_wraith> | Oh, I've seen some careless code. :P |
| 2022-10-29 21:11:13 +0200 | <geekosaur> | so have I |
| 2022-10-29 21:11:35 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-10-29 21:11:36 +0200 | <geekosaur> | but more often in C or etc.; Haskell programmers usually make some attempt at safety |
| 2022-10-29 21:11:57 +0200 | <EvanR> | strive to write carelessness safe code |
| 2022-10-29 21:12:19 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 272 seconds) |
| 2022-10-29 21:12:36 +0200 | <Franciman> | geekosaur: laziness can also lead to strange behaviour making your machine fail |
| 2022-10-29 21:12:41 +0200 | <Franciman> | because it goes out of RAM |
| 2022-10-29 21:12:51 +0200 | <Franciman> | well, not laziness per se, while careless usage of laziness |
| 2022-10-29 21:13:14 +0200 | <EvanR> | careless evaluation |
| 2022-10-29 21:13:19 +0200 | <geekosaur> | Franciman, given that you hate Haskell so much,m could you please go peddle your wares elsewhere? |
| 2022-10-29 21:13:36 +0200 | cowboy8625 | (~cowboy@rrcs-173-198-134-163.west.biz.rr.com) (Quit: WeeChat 3.5) |
| 2022-10-29 21:14:05 +0200 | <Franciman> | wtf |
| 2022-10-29 21:14:11 +0200 | <Franciman> | ok |
| 2022-10-29 21:14:15 +0200 | <DigitalKiwi> | what's funny is the majority of programs that make my machine run out of ram are not haskell |
| 2022-10-29 21:14:34 +0200 | <c_wraith> | are they electron? |
| 2022-10-29 21:14:55 +0200 | acidjnk | (~acidjnk@p200300d6e7137a24f17133d2359444b2.dip0.t-ipconnect.de) |
| 2022-10-29 21:15:04 +0200 | <DigitalKiwi> | there are a few of those yeah lol |
| 2022-10-29 21:15:20 +0200 | wroathe | (~wroathe@50.205.197.50) |
| 2022-10-29 21:15:20 +0200 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2022-10-29 21:15:20 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-29 21:15:40 +0200 | <DigitalKiwi> | i'm actually really shocked that signal-desktop works as well as it does heh |
| 2022-10-29 21:15:41 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-10-29 21:15:56 +0200 | <DigitalKiwi> | but slack and discord == OOM |
| 2022-10-29 21:16:10 +0200 | <EvanR> | wasteful usage of ram grows to meet memory upgrades? |
| 2022-10-29 21:16:25 +0200 | <DigitalKiwi> | ram soldered in capped at 16GB :( |
| 2022-10-29 21:16:26 +0200 | <EvanR> | it's even built into haskell |
| 2022-10-29 21:16:33 +0200 | <geekosaur> | here you're pissing on laziness. last time it was "in ocaml. way better". in fact I'm hard put to see much positive in your contributions here, according to my logs |
| 2022-10-29 21:17:07 +0200 | <Franciman> | ... |
| 2022-10-29 21:17:10 +0200 | <Franciman> | are you serious? |
| 2022-10-29 21:17:16 +0200 | <Franciman> | it was a joke... |
| 2022-10-29 21:17:17 +0200 | <EvanR> | how's the laziness situation on ocaml |
| 2022-10-29 21:17:28 +0200 | <DigitalKiwi> | i'm too lazy to learn it |
| 2022-10-29 21:17:45 +0200 | <DigitalKiwi> | so it's going great i guess? |
| 2022-10-29 21:17:48 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 21:17:49 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-10-29 21:17:56 +0200 | <EvanR> | 🥁 |
| 2022-10-29 21:18:00 +0200 | <Franciman> | let's put it clear geekosaur |
| 2022-10-29 21:18:14 +0200 | <Franciman> | i have no interest in showing things |
| 2022-10-29 21:18:34 +0200 | <Franciman> | i wanted to participate in the conversation without saying haskell sucks |
| 2022-10-29 21:18:40 +0200 | <Franciman> | i even said «careless usage of laziness» |
| 2022-10-29 21:18:56 +0200 | <Franciman> | what's edgy about it? |
| 2022-10-29 21:19:34 +0200 | <EvanR> | SPJ: Haskell is useless. Franciman: Haskell sucks |
| 2022-10-29 21:19:44 +0200 | <Franciman> | i don't care whether haskell sucks or not |
| 2022-10-29 21:19:47 +0200 | <Franciman> | i was wrong in the past |
| 2022-10-29 21:20:09 +0200 | <Franciman> | i've done my share of errors |
| 2022-10-29 21:20:38 +0200 | <EvanR> | cunningham & cunningham: everything sucks |
| 2022-10-29 21:21:47 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-10-29 21:24:47 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-10-29 21:26:06 +0200 | <geekosaur> | sysadmin: all hardware sucks, all software sucks |
| 2022-10-29 21:26:44 +0200 | <Franciman> | bye bye |
| 2022-10-29 21:26:48 +0200 | Franciman | (~Franciman@mx1.fracta.dev) (WeeChat 3.0) |
| 2022-10-29 21:29:33 +0200 | SnoopDoll | (~SnoopDoll@host-95-251-162-186.retail.telecomitalia.it) |
| 2022-10-29 21:29:48 +0200 | buffet | (~buffet@buffet.sh) (WeeChat 3.5) |
| 2022-10-29 21:30:16 +0200 | SnoopDoll | (~SnoopDoll@host-95-251-162-186.retail.telecomitalia.it) () |
| 2022-10-29 21:31:09 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Quit: Lost terminal) |
| 2022-10-29 21:44:56 +0200 | <dsal> | dminuoso: I've not looked at hasql. But what's wrong with postgresql-simple? |
| 2022-10-29 21:46:47 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-10-29 21:46:54 +0200 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:41f8:4e00:54f7:b844) (Quit: caryhartline) |
| 2022-10-29 21:49:40 +0200 | son0p | (~ff@181.136.122.143) (Remote host closed the connection) |
| 2022-10-29 21:55:55 +0200 | polo | (~polo@user/polo) |
| 2022-10-29 22:00:47 +0200 | Cale_ | (~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com) |
| 2022-10-29 22:01:52 +0200 | Cale | (~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com) (Ping timeout: 260 seconds) |
| 2022-10-29 22:01:58 +0200 | nate3 | (~nate@98.45.169.16) |
| 2022-10-29 22:05:02 +0200 | Cale_ | (~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com) (Client Quit) |
| 2022-10-29 22:05:10 +0200 | Cale | (~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com) |
| 2022-10-29 22:08:05 +0200 | Guest|57 | (~Guest|57@128.172.245.79) |
| 2022-10-29 22:15:23 +0200 | polo | (~polo@user/polo) (Ping timeout: 276 seconds) |
| 2022-10-29 22:20:25 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 255 seconds) |
| 2022-10-29 22:24:05 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-10-29 22:25:58 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6) |
| 2022-10-29 22:26:41 +0200 | qhong | (~qhong@rescomp-21-400677.stanford.edu) (Remote host closed the connection) |
| 2022-10-29 22:26:50 +0200 | cyphase | (~cyphase@user/cyphase) |
| 2022-10-29 22:29:57 +0200 | nate3 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2022-10-29 22:29:58 +0200 | mrianbloom | (uid350277@id-350277.ilkley.irccloud.com) |
| 2022-10-29 22:30:54 +0200 | <mrianbloom> | Can you specify that you want some example code to be compiled in a package even if it is not an executable and has no main function? |
| 2022-10-29 22:31:34 +0200 | <mrianbloom> | Currently using stack but I guess this also applies to cabal. |
| 2022-10-29 22:37:26 +0200 | RevoGen | (~RevoGen@136.167.84.221) |
| 2022-10-29 22:40:34 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-10-29 22:42:34 +0200 | <sclv> | mrianbloom: if you have a library stanza, all modules in the library will be compiled |
| 2022-10-29 22:42:46 +0200 | buffet | (~buffet@buffet.sh) |
| 2022-10-29 22:42:54 +0200 | buffet | (~buffet@buffet.sh) (WeeChat 3.5) |
| 2022-10-29 22:43:11 +0200 | <mrianbloom> | I see. |
| 2022-10-29 22:44:01 +0200 | <mrianbloom> | Seems like I'm suggesting it can be used by library users. |
| 2022-10-29 22:44:56 +0200 | seriley | (~seriley@75.164.74.1) |
| 2022-10-29 22:45:17 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 22:45:31 +0200 | lechner- | (~lechner@2601:641:400:1e5::d35) |
| 2022-10-29 22:46:17 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2022-10-29 22:47:06 +0200 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-10-29 22:48:00 +0200 | <seriley> | When I do :info Enum in ghci, the first line gives me "type Enum :: * -> Constraint. What does that mean? |
| 2022-10-29 22:49:30 +0200 | <geekosaur> | Enum takes a Type and produces a Constraint. so something like `Enum Int` is legal as long as it occurs to the left of a `=>` |
| 2022-10-29 22:49:38 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 252 seconds) |
| 2022-10-29 22:49:47 +0200 | <[Leary]> | mrianbloom: If you don't want it to be exposed for use like a regular library module, you can keep it internal by putting it in `other modules`. Though in that case, I'm not certain it will be compiled without being a dependency; you may need to do an `import MyLibrary.Example()` somewhere. |
| 2022-10-29 22:49:51 +0200 | <geekosaur> | but `Enum Monad` would be ill-typed as its kind is not `*` but `* -> *` |
| 2022-10-29 22:50:16 +0200 | <seriley> | thanks |
| 2022-10-29 22:50:27 +0200 | <mrianbloom> | I see, thank you. |
| 2022-10-29 22:50:35 +0200 | <geekosaur> | nor can you say `foo :: Enum Int` because it's a Constraint instead of a Type |
| 2022-10-29 22:51:29 +0200 | <seriley> | ok. That makes sense |
| 2022-10-29 22:52:50 +0200 | <seriley> | Constraints only work on the left of => in a type declaration? |
| 2022-10-29 22:53:17 +0200 | RevoGen | (~RevoGen@136.167.84.221) (Remote host closed the connection) |
| 2022-10-29 22:54:36 +0200 | <geekosaur> | yes |
| 2022-10-29 22:54:45 +0200 | <monochrom> | For beginners it is simpler to ignore "type Enum :: * -> Constraint" and focus on "class Enum a where ..." and some of the instances. |
| 2022-10-29 22:54:50 +0200 | <geekosaur> | ^ |
| 2022-10-29 22:55:11 +0200 | <geekosaur> | that teells you what it can do., the rest is more or less typechecker gobbledygook |
| 2022-10-29 22:55:50 +0200 | <seriley> | I see. thanks again |
| 2022-10-29 22:55:55 +0200 | <monochrom> | Hell, in general, beginners better focus on Haskell 2010; hell, sometimes even that is too big. |
| 2022-10-29 22:57:47 +0200 | <monochrom> | After you understand the concept of type classes, then this Constraint business is a powerful generalization. But walk before run, low tech before high tech. |
| 2022-10-29 22:59:50 +0200 | <[Leary]> | Haskell is just big full-stop. If I were teaching it, I would start with plain LC and introduce one Haskell feature at a time. |
| 2022-10-29 23:01:20 +0200 | ddellacosta | (~ddellacos@143.244.47.100) |
| 2022-10-29 23:01:33 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-10-29 23:03:05 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-29 23:07:26 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Ping timeout: 250 seconds) |
| 2022-10-29 23:10:07 +0200 | Kaiepi | (~Kaiepi@108.175.84.104) (Ping timeout: 272 seconds) |
| 2022-10-29 23:10:40 +0200 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) |
| 2022-10-29 23:12:55 +0200 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-10-29 23:13:47 +0200 | nate3 | (~nate@98.45.169.16) |
| 2022-10-29 23:13:54 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2022-10-29 23:14:09 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-10-29 23:19:26 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt juan@acm.org) |
| 2022-10-29 23:19:37 +0200 | nate3 | (~nate@98.45.169.16) (Ping timeout: 272 seconds) |
| 2022-10-29 23:22:01 +0200 | polo | (~polo@user/polo) |
| 2022-10-29 23:24:46 +0200 | Clint | (~Clint@user/clint) (Quit: restarting) |
| 2022-10-29 23:30:11 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2022-10-29 23:30:28 +0200 | nate3 | (~nate@98.45.169.16) |
| 2022-10-29 23:33:46 +0200 | polo | (~polo@user/polo) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-10-29 23:34:05 +0200 | zzz | yin |
| 2022-10-29 23:34:41 +0200 | polo | (~polo@user/polo) |
| 2022-10-29 23:34:44 +0200 | <yin> | hi. i'm trying out hls with CoC on nvim. where can i get a list of all the commands i can use? |
| 2022-10-29 23:35:08 +0200 | <yin> | been searching the docs for about 15 mins and am lost |
| 2022-10-29 23:37:59 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 272 seconds) |
| 2022-10-29 23:38:42 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-10-29 23:42:55 +0200 | michalz | (~michalz@185.246.207.221) (Remote host closed the connection) |
| 2022-10-29 23:44:48 +0200 | Clint | (~Clint@user/clint) |
| 2022-10-29 23:48:17 +0200 | acidjnk | (~acidjnk@p200300d6e7137a24f17133d2359444b2.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-10-29 23:53:25 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-10-29 23:53:48 +0200 | jtomas | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 264 seconds) |
| 2022-10-29 23:56:15 +0200 | mmhat | (~mmh@p200300f1c7307602ee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-10-29 23:57:56 +0200 | polo | (~polo@user/polo) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-10-29 23:59:52 +0200 | zebrag | (~chris@user/zebrag) |
