| 2025-01-09 00:00:34 +0100 | biberao | (~m@user/biberao) (Quit: WeeChat 3.8) |
| 2025-01-09 00:00:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2025-01-09 00:04:16 +0100 | Square2 | (~Square@user/square) (Remote host closed the connection) |
| 2025-01-09 00:05:16 +0100 | esph | (~weechat@user/esph) (Quit: WeeChat 4.5.1) |
| 2025-01-09 00:05:32 +0100 | esph | (~weechat@user/esph) esph |
| 2025-01-09 00:05:52 +0100 | omegatron | (~some@user/omegatron) omegatron |
| 2025-01-09 00:06:49 +0100 | Square | (~Square@user/square) Square |
| 2025-01-09 00:07:56 +0100 | esph | (~weechat@user/esph) (Client Quit) |
| 2025-01-09 00:07:57 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds) |
| 2025-01-09 00:08:01 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f68a1608a41cd6a32b2.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-01-09 00:08:17 +0100 | esph | (~weechat@user/esph) esph |
| 2025-01-09 00:09:12 +0100 | <geekosaur> | https://downloads.haskell.org/ghc/latest/docs/libraries/stm-2.5.3.1-9996/Control-Concurrent-STM-TC… ? |
| 2025-01-09 00:09:43 +0100 | <geekosaur> | don't think it supports #2 though |
| 2025-01-09 00:09:57 +0100 | <geekosaur> | I'm not aware of a channel type that supports both of those |
| 2025-01-09 00:11:14 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 00:11:21 +0100 | <EvanR> | attach a timestamp to each event and use this to filter out events "in the past" you want to ignore |
| 2025-01-09 00:11:56 +0100 | esph | (~weechat@user/esph) (Client Quit) |
| 2025-01-09 00:12:07 +0100 | <geekosaur> | that'd pretty much be it, otherwise the writer would need to know what threads were blocked so it could deliver the event only to them |
| 2025-01-09 00:12:23 +0100 | <EvanR> | where timestamp is like, the applications globally agreed incrementing counter defining time |
| 2025-01-09 00:12:38 +0100 | <haskellbridge> | <magic_rb> i dont know if i even need 2 to be honest |
| 2025-01-09 00:12:56 +0100 | <haskellbridge> | <magic_rb> the only issue i can see is if "TChan" is never read from, then it'll pile up |
| 2025-01-09 00:13:01 +0100 | <c_wraith> | Honestly, this seems like something easy enough to do yourself |
| 2025-01-09 00:13:16 +0100 | <haskellbridge> | <geekosaur> I don't think TBChan has a broadcast variant |
| 2025-01-09 00:13:23 +0100 | <c_wraith> | You'd want to be a little careful with finalizers so that things don't leak, though |
| 2025-01-09 00:13:31 +0100 | <haskellbridge> | <magic_rb> I'm also kind of having issues with "the channels are per _what_" |
| 2025-01-09 00:13:33 +0100 | <EvanR> | if no one is reading from a broadcast tchan then the event goes into the ether |
| 2025-01-09 00:13:34 +0100 | <haskellbridge> | <geekosaur> er, TBQueue |
| 2025-01-09 00:13:49 +0100 | <haskellbridge> | <magic_rb> EvanR: i mean from one of the dupchans |
| 2025-01-09 00:15:31 +0100 | <haskellbridge> | <magic_rb> the only real reason why i have to bother with "channels are per what" is because they have buffers. If 2. was satisfied i wouldn't have to bother with "per what" |
| 2025-01-09 00:16:04 +0100 | <haskellbridge> | <magic_rb> ie whenever a thread tries to read from the channel, it throws its hat in the ring and waits for an event, simple |
| 2025-01-09 00:17:38 +0100 | <geekosaur> | sadly I think the only way you can accomplish that without the event sender knowing is for only one reader to be awakened |
| 2025-01-09 00:17:55 +0100 | <haskellbridge> | <magic_rb> the event sender can know, i think |
| 2025-01-09 00:18:03 +0100 | <geekosaur> | (where the choice of which depends on the implementation and may e.g. be thundering herd) |
| 2025-01-09 00:18:06 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-01-09 00:18:11 +0100 | <hololeap> | it sounds a lot like ghc's sparks system to me |
| 2025-01-09 00:18:17 +0100 | <haskellbridge> | <magic_rb> i want this to be eventually extendable across multiple machines, think kafka |
| 2025-01-09 00:18:21 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-09 00:18:35 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-09 00:18:48 +0100 | <c_wraith> | well then you're just entering a world of different complications and should use an existing complicated product |
| 2025-01-09 00:18:51 +0100 | <geekosaur> | then I wouldn't even start with any of ghc's channels |
| 2025-01-09 00:19:03 +0100 | <geekosaur> | or, what c_wraith said |
| 2025-01-09 00:19:28 +0100 | <geekosaur> | you're better off using an existing cross-machine messaging system |
| 2025-01-09 00:19:31 +0100 | <hololeap> | yeah I wasn't suggesting that just thinking about it |
| 2025-01-09 00:20:06 +0100 | <haskellbridge> | <magic_rb> im not going to implement kafka myself, but for the single machine situation which is what im focusing on, i need something with the same semantics |
| 2025-01-09 00:20:15 +0100 | <haskellbridge> | <magic_rb> dont feel like throwing kafka immediately into this mess |
| 2025-01-09 00:21:09 +0100 | <haskellbridge> | <magic_rb> so i need something which behaves like a "whatever kafka is" (the term eludes me right now) but on a single machine |
| 2025-01-09 00:22:53 +0100 | esph | (~weechat@user/esph) esph |
| 2025-01-09 00:23:10 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f68a1608a41cd6a32b2.dip0.t-ipconnect.de) acidjnk |
| 2025-01-09 00:24:26 +0100 | <hololeap> | I think EvanR's idea along with TChan could work even if it's a bit of a kludge |
| 2025-01-09 00:24:28 +0100 | <c_wraith> | I mean, if you're dropping the "receive past events" part, you don't have most of the complexities of a channel |
| 2025-01-09 00:24:38 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) (Remote host closed the connection) |
| 2025-01-09 00:25:14 +0100 | sabathan | (~sabathan@acaen-652-1-335-197.w83-115.abo.wanadoo.fr) (Ping timeout: 272 seconds) |
| 2025-01-09 00:27:51 +0100 | <hololeap> | there's also FRP, where events affect every defined behavior as they happen in real time, and new behaviors that are brought online can attach to existing events without affecting other existing behaviors |
| 2025-01-09 00:27:53 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
| 2025-01-09 00:28:09 +0100 | <hololeap> | which might be what you're looking for? |
| 2025-01-09 00:28:22 +0100 | <hololeap> | sorry, I suck at explaining technical things |
| 2025-01-09 00:29:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 00:29:31 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) hgolden |
| 2025-01-09 00:30:20 +0100 | <haskellbridge> | <magic_rb> im familiar with the concept of FRP, though im not sure that it applies here nor do i want to open that can of worms |
| 2025-01-09 00:30:32 +0100 | <haskellbridge> | <magic_rb> i need to get something functional-ish quite quickly |
| 2025-01-09 00:30:53 +0100 | <haskellbridge> | <magic_rb> so ill do the minimum of a event sourcing architecture and see where that takes me |
| 2025-01-09 00:32:27 +0100 | <haskellbridge> | <magic_rb> hololeap: seeing past events doesnt matter, its just wholly unnecessary, since the channel might get duped right after the event youre interested in happened and so you need to first check the database anyway |
| 2025-01-09 00:33:21 +0100 | <haskellbridge> | <magic_rb> right, what i want is a lastEvent MVar and some kind of thundering herd inducing semaphore |
| 2025-01-09 00:33:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-09 00:34:17 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-09 00:34:18 +0100 | <hololeap> | speaking of, this looks interesting: https://github.com/turion/rhine |
| 2025-01-09 00:34:51 +0100 | <hololeap> | > Haskell Functional Reactive Programming framework with type-level clocks |
| 2025-01-09 00:34:53 +0100 | <lambdabot> | <hint>:1:56: error: parse error on input ‘type’ |
| 2025-01-09 00:37:35 +0100 | <c_wraith> | magic_rb: like, https://paste.tomsmeding.com/ov7bxeMa seems like it meets your requirements. It's a *lot* easier when you don't need the channel semantics. |
| 2025-01-09 00:37:41 +0100 | <haskellbridge> | <magic_rb> what i could do, which is kinda cursed is have two semaphores when a thread goes to emit an event it swaps them and awakes everyone on the "active" one, which then becomes the inactive |
| 2025-01-09 00:38:12 +0100 | <hololeap> | magic_rb, just found this. not sure if it fits the bill: https://hackage.haskell.org/package/broadcast-chan |
| 2025-01-09 00:38:47 +0100 | <c_wraith> | hololeap: single-wakeup is not "all waiting threads receive the value" |
| 2025-01-09 00:39:33 +0100 | dysthesis | (~dysthesis@user/dysthesis) dysthesis |
| 2025-01-09 00:41:24 +0100 | <haskellbridge> | <magic_rb> c_wraith: the docs suggest that all readers will read any one written value, so im not sure what that package does actually |
| 2025-01-09 00:41:38 +0100 | <hololeap> | in the docs it says: BroadcastChan In: Will receive all messages written to the channel after this read end is created. |
| 2025-01-09 00:41:38 +0100 | <haskellbridge> | <magic_rb> BroadcastChan In: Will receive all messages written to the channel after this read end is created. |
| 2025-01-09 00:41:44 +0100 | <hololeap> | lol |
| 2025-01-09 00:42:25 +0100 | <haskellbridge> | <magic_rb> so thats quite close it'll still accumulate messages in the read ends if no one reads them, so the solution there is to create a read end and then immediately discard it after you no longer are actively reading |
| 2025-01-09 00:42:35 +0100 | <c_wraith> | magic_rb: anyway, take a look at my suggestion. If you think of it more like a live broadcast than a message queue, it becomes a lot simpler. Also a lot less useful - there's never a guarantee someone will receive the message. |
| 2025-01-09 00:42:45 +0100 | <haskellbridge> | <magic_rb> which is essentially what c_wraith solution does |
| 2025-01-09 00:43:33 +0100 | <haskellbridge> | <magic_rb> yeah i might go with your implementation, its neatly simple and ill need the "check the state, await state change" implementation anyway, so i dont care about lost events |
| 2025-01-09 00:44:16 +0100 | <haskellbridge> | <magic_rb> i appreciate the help from everyone, i gotta go hit the hay |
| 2025-01-09 00:44:23 +0100 | sabathan | (~sabathan@acaen-652-1-335-197.w83-115.abo.wanadoo.fr) |
| 2025-01-09 00:44:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 00:45:19 +0100 | <haskellbridge> | <magic_rb> if anyone's curious about the current state of things: https://git.redalder.org/magic_rb/haci |
| 2025-01-09 00:45:25 +0100 | <hololeap> | gn |
| 2025-01-09 00:47:29 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-09 00:49:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-09 00:55:16 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 00:57:39 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2025-01-09 00:58:10 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 272 seconds) |
| 2025-01-09 00:59:53 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-09 01:00:02 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-09 01:00:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-09 01:00:37 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-09 01:00:42 +0100 | lol_ | (~lol@2603:3016:1e01:b9c0:794b:ce9f:2a3d:41ae) |
| 2025-01-09 01:00:47 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-09 01:01:19 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-09 01:01:20 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-09 01:03:48 +0100 | <haskellbridge> | <magic_rb> Oh i made the repo private, damn |
| 2025-01-09 01:03:49 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-01-09 01:04:26 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-01-09 01:04:55 +0100 | jcarpenter2 | (~lol@2603:3016:1e01:b9c0:480:d3aa:2a9:c319) (Ping timeout: 264 seconds) |
| 2025-01-09 01:10:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 01:18:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-09 01:29:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 01:30:50 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-09 01:32:50 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) (Ping timeout: 260 seconds) |
| 2025-01-09 01:34:01 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-09 01:37:19 +0100 | homo | (~homo@user/homo) (Quit: Leaving) |
| 2025-01-09 01:40:41 +0100 | agent314 | (~quassel@37.19.210.25) agent314 |
| 2025-01-09 01:41:03 +0100 | alist | (~alist@108-224-153-186.lightspeed.cicril.sbcglobal.net) (Remote host closed the connection) |
| 2025-01-09 01:43:17 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
| 2025-01-09 01:45:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 01:46:56 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f68a1608a41cd6a32b2.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2025-01-09 01:47:05 +0100 | xff0x | (~xff0x@2405:6580:b080:900:6d94:dd0b:4250:b8b3) (Ping timeout: 252 seconds) |
| 2025-01-09 01:47:58 +0100 | sprotte24 | (~sprotte24@p200300d16f1e660091235e642331973a.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-01-09 01:51:48 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-09 01:59:36 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-09 02:01:42 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-09 02:01:44 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-09 02:02:19 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-09 02:02:20 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-09 02:02:54 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-09 02:02:54 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-09 02:03:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 02:07:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-09 02:12:12 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 264 seconds) |
| 2025-01-09 02:18:28 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 02:20:36 +0100 | dysthesis | (~dysthesis@user/dysthesis) (Ping timeout: 264 seconds) |
| 2025-01-09 02:22:42 +0100 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 265 seconds) |
| 2025-01-09 02:22:48 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-09 02:24:10 +0100 | m5zs7k | (aquares@web10.mydevil.net) m5zs7k |
| 2025-01-09 02:25:24 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2025-01-09 02:26:51 +0100 | agent314 | (~quassel@37.19.210.25) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2025-01-09 02:33:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 02:35:00 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
| 2025-01-09 02:36:05 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-01-09 02:37:52 +0100 | califax | (~califax@user/califx) califx |
| 2025-01-09 02:38:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-09 02:38:40 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-01-09 02:39:51 +0100 | otto_s | (~user@p4ff2701d.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2025-01-09 02:41:18 +0100 | lbseale | (~quassel@user/ep1ctetus) ep1ctetus |
| 2025-01-09 02:41:32 +0100 | otto_s | (~user@p4ff270f4.dip0.t-ipconnect.de) |
| 2025-01-09 02:48:40 +0100 | gabriel_sevecek | (~gabriel@188-167-229-200.dynamic.chello.sk) (Ping timeout: 260 seconds) |
| 2025-01-09 02:48:52 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-01-09 02:49:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 02:51:07 +0100 | emmanuelux_ | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-01-09 02:51:07 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-01-09 02:51:35 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Ping timeout: 260 seconds) |
| 2025-01-09 02:51:45 +0100 | gabriel_sevecek | (~gabriel@188-167-229-200.dynamic.chello.sk) gabriel_sevecek |
| 2025-01-09 02:52:52 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection) |
| 2025-01-09 02:53:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-09 02:54:28 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |