Newest at the top
| 2025-01-09 00:55:16 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 00:49:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-09 00:47:29 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-09 00:45:25 +0100 | <hololeap> | gn |
| 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:44:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 00:44:23 +0100 | sabathan | (~sabathan@acaen-652-1-335-197.w83-115.abo.wanadoo.fr) |
| 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: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:42:45 +0100 | <haskellbridge> | <magic_rb> which is essentially what c_wraith solution does |
| 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: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:41:44 +0100 | <hololeap> | lol |
| 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: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: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:39:33 +0100 | dysthesis | (~dysthesis@user/dysthesis) dysthesis |
| 2025-01-09 00:38:47 +0100 | <c_wraith> | hololeap: single-wakeup is not "all waiting threads receive the value" |
| 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: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: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:34:53 +0100 | <lambdabot> | <hint>:1:56: error: parse error on input ‘type’ |
| 2025-01-09 00:34:51 +0100 | <hololeap> | > Haskell Functional Reactive Programming framework with type-level clocks |
| 2025-01-09 00:34:18 +0100 | <hololeap> | speaking of, this looks interesting: https://github.com/turion/rhine |
| 2025-01-09 00:34:17 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-09 00:33:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 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: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: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:30:32 +0100 | <haskellbridge> | <magic_rb> i need to get something functional-ish quite quickly |
| 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:29:31 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) hgolden |
| 2025-01-09 00:29:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-09 00:28:22 +0100 | <hololeap> | sorry, I suck at explaining technical things |
| 2025-01-09 00:28:09 +0100 | <hololeap> | which might be what you're looking for? |
| 2025-01-09 00:27:53 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
| 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:25:14 +0100 | sabathan | (~sabathan@acaen-652-1-335-197.w83-115.abo.wanadoo.fr) (Ping timeout: 272 seconds) |
| 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: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: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:23:10 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f68a1608a41cd6a32b2.dip0.t-ipconnect.de) acidjnk |
| 2025-01-09 00:22:53 +0100 | esph | (~weechat@user/esph) esph |
| 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:20:15 +0100 | <haskellbridge> | <magic_rb> dont feel like throwing kafka immediately into this mess |
| 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:19:31 +0100 | <hololeap> | yeah I wasn't suggesting that just thinking about it |
| 2025-01-09 00:19:28 +0100 | <geekosaur> | you're better off using an existing cross-machine messaging system |
| 2025-01-09 00:19:03 +0100 | <geekosaur> | or, what c_wraith said |
| 2025-01-09 00:18:51 +0100 | <geekosaur> | then I wouldn't even start with any of ghc's channels |