Logs: liberachat/#haskell
| 2021-08-17 18:47:34 | <monochrom> | I think it's 2 counters because it's 2 lists. The usual pure functional "queue is 2 lists, front and back" trick. |
| 2021-08-17 18:48:12 | <aegon> | i'm having a rough time deciphering this error message. I think i need to use some form of lift, but maybe i'm instancing MonadHttp in an incorrect place? |
| 2021-08-17 18:48:17 | <aegon> | https://paste.tomsmeding.com/lG8UF1es |
| 2021-08-17 18:48:36 | <jay-invariant> | One way to get a constant-factor speedup would be to feed the queue fixed-sized chunks of many Int32's. You could make a sink like `MSF IO Int32 ()` that internally fills a vector, then pushes it to the queue when it's reached a certain size |
| 2021-08-17 18:49:23 | fendor_ | is now known as fendor |
| 2021-08-17 18:49:42 | × | kuribas quits (~user@ptr-25vy0iacpr2aovgi62v.18120a2.ip6.access.telenet.be) (Ping timeout: 258 seconds) |
| 2021-08-17 18:50:20 | × | koolazer quits (~koo@user/koolazer) (*.net *.split) |
| 2021-08-17 18:50:20 | × | synthmeat quits (~synthmeat@user/synthmeat) (*.net *.split) |
| 2021-08-17 18:50:20 | × | Hafydd quits (~Hafydd@user/hafydd) (*.net *.split) |
| 2021-08-17 18:50:20 | × | vjoki quits (~vjoki@2a00:d880:3:1::fea1:9ae) (*.net *.split) |
| 2021-08-17 18:50:20 | × | phaazon quits (~phaazon@2001:41d0:a:fe76::1) (*.net *.split) |
| 2021-08-17 18:50:20 | × | monochrom quits (trebla@216.138.220.146) (*.net *.split) |
| 2021-08-17 18:50:25 | → | Erutuon joins (~Erutuon@user/erutuon) |
| 2021-08-17 18:50:30 | → | synthmeat joins (~synthmeat@user/synthmeat) |
| 2021-08-17 18:50:30 | → | Hafydd joins (~Hafydd@user/hafydd) |
| 2021-08-17 18:50:30 | → | vjoki joins (~vjoki@2a00:d880:3:1::fea1:9ae) |
| 2021-08-17 18:50:30 | → | phaazon joins (~phaazon@2001:41d0:a:fe76::1) |
| 2021-08-17 18:50:30 | → | monochrom joins (trebla@216.138.220.146) |
| 2021-08-17 18:50:41 | → | koolazer joins (~koo@user/koolazer) |
| 2021-08-17 18:51:59 | <chisui> | Well I have a large `IOVector` I write audio samples to. In another thread I generate these samples. Currently this causes an error since the buffer fills up too quickly. My current solution is that I set a limit and in the `arrM` function I spin wait until the buffer is empty enough to fill it again. |
| 2021-08-17 18:54:02 | <monochrom> | If that case you can easily replace the spin-lock by a real-lock. MVar as a size-1 queue is equiv to a lock, too. |
| 2021-08-17 18:54:34 | <monochrom> | You can define "acquire" to be one of putMVar or takeMVar, "release" to be the other. |
| 2021-08-17 18:54:35 | <jay-invariant> | aegon: I think you need to `lift $ R.deleteAnchor c auuid`, since `ScottyT` does not forward the underlying monad's `MonadHTTP` |
| 2021-08-17 18:55:13 | <aegon> | jay-invariant: i found a lift from ActionT e m a's instance of MonadTrans that i think would do the job but I can't find out where to import it from |
| 2021-08-17 18:55:17 | <monochrom> | Or s/acqure/green light/, s/release/red light/. Or whatever convention you feel like. |
| 2021-08-17 18:55:55 | <jay-invariant> | aegon: I think just `Control.Monad.Trans` |
| 2021-08-17 18:56:04 | <jay-invariant> | in mtl |
| 2021-08-17 18:56:42 | <aegon> | jay-invariant: aand, works. thanks :) |
| 2021-08-17 18:58:28 | <jay-invariant> | aegon: I would create the IOVector and fill it in the sending thread, then send it via TBQueue (or MVar, if you only want to buffer one chunk) to the callback thread. Then the callback thread just passes the vector along |
| 2021-08-17 18:58:42 | <aegon> | chisui: ^ |
| 2021-08-17 18:58:55 | <jay-invariant> | oh yeah whoops chisui |
| 2021-08-17 18:59:25 | × | eight quits (~eight@user/eight) (Quit: leaving) |
| 2021-08-17 18:59:34 | <monochrom> | MVar is very cheap. |
| 2021-08-17 19:00:08 | <monochrom> | STM is where yes you can begin worrying about overhead. One single MVar? No. |
| 2021-08-17 19:00:22 | <chisui> | Unfortunately I don't know how big the read chunk will be before it is requested |
| 2021-08-17 19:00:53 | <chisui> | I would have 50000 write actions on the MVar right? |
| 2021-08-17 19:01:34 | <jay-invariant> | chisui: no, I'm suggesting you make a large vector, and write the MVar once, when the vector is full |
| 2021-08-17 19:01:51 | <jay-invariant> | that way you never have to worry about a vector being accessed by two threads at once |
| 2021-08-17 19:01:56 | <monochrom> | The MVar contains (). |
| 2021-08-17 19:02:44 | <monochrom> | You use it as a green light red light. Not for storing data. |
| 2021-08-17 19:02:58 | <chisui> | Ahhh, I have never seen the `MVar ()` as mutex pattern before. |
| 2021-08-17 19:03:00 | <monochrom> | "message" does not always mean data either. |
| 2021-08-17 19:03:25 | <monochrom> | (ever heard of "control messages"?) |
| 2021-08-17 19:03:26 | <jay-invariant> | oh, well that's not how I would do it. I'm more of a fan of go's "share memory by communicating, don't communicate by sharing memory" |
| 2021-08-17 19:03:46 | <chisui> | monochrom: no I haven't heard of control messages |
| 2021-08-17 19:04:45 | <monochrom> | I guess I have more lower-level background than average. But network protocols are full of control messages. |
| 2021-08-17 19:04:54 | <monochrom> | especially for flow control |
| 2021-08-17 19:05:57 | ← | jakalx parts (~jakalx@base.jakalx.net) (Error from remote client) |
| 2021-08-17 19:06:19 | <monochrom> | And my supervisor's enlightening comment that "synchonization" is a special case of messaging. Think about it. |
| 2021-08-17 19:07:18 | → | idf joins (~idf@198.23.223.146) |
| 2021-08-17 19:07:22 | <jay-invariant> | Something like a `TBQueue (Vector Int)`, where each Vector has some large fixed size, should be reasonably efficient without much risk of concurrency bugs |
| 2021-08-17 19:07:24 | <monochrom> | If you and I are synchronizing, perhaps I'm waiting for you and you tell me "now it's time" when the time comes. Well that's a message right there. |
| 2021-08-17 19:07:34 | <chisui> | well, what if the callback requests 40k samples and the next time 50k samples? How to I know when to provide compute more values? |
| 2021-08-17 19:08:40 | <jay-invariant> | The size of the chunks you send might not be exactly the size the callback asks for, in which case the callback thread will have to handle re-arranging the vectors |
| 2021-08-17 19:08:44 | <aegon> | chisui: I'm probably derailing things here, but what about using a chunked consumer type patternwhere if you want to process 50 at a time, consume till 50, then had those 50 off to the audio proc |
| 2021-08-17 19:08:54 | <aegon> | is there any reason you can't chunk audio processing in the middle? |
| 2021-08-17 19:09:49 | <chisui> | aegon: the audio library I'm using determines the chunk size on demand |
| 2021-08-17 19:11:01 | → | lavaman joins (~lavaman@98.38.249.169) |
| 2021-08-17 19:11:03 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-08-17 19:11:24 | <jay-invariant> | The reason I'm suggesting `TBQueue (Vector Int)` over just `TBQueue Int` is just for efficiency, but conceptually it's the same idea: the callback will read some number of Ints from the queue and copy them into the buffer until its full |
| 2021-08-17 19:12:58 | → | Pickchea joins (~private@user/pickchea) |
| 2021-08-17 19:13:00 | → | aarvar joins (~aaron@2601:602:a080:fa0:c9d0:9f94:946c:b2f0) |
| 2021-08-17 19:13:08 | <jay-invariant> | I think some amount of copying and re-arranging is unavoidable, since you want to start processing before the callback has handed you the destination buffer |
| 2021-08-17 19:14:54 | → | Axma97927 joins (~Axman6@user/axman6) |
| 2021-08-17 19:16:18 | × | dhouthoo quits (~dhouthoo@178-117-36-167.access.telenet.be) (Quit: WeeChat 3.2) |
| 2021-08-17 19:17:25 | <jay-invariant> | It might be more readable to split it into a pure `chunk :: MSF m Int (Maybe (Vector Int))` that builds up immutable chunks using the ST monad or something under the hood, and then pass that to a sink that enqueues it |
| 2021-08-17 19:18:05 | × | Axman6 quits (~Axman6@user/axman6) (Ping timeout: 256 seconds) |
| 2021-08-17 19:19:24 | × | aegon quits (~mike@174.127.249.180) (Remote host closed the connection) |
| 2021-08-17 19:19:56 | → | pompez joins (~martin@user/pompez) |
| 2021-08-17 19:20:10 | → | gehmehgeh joins (~user@user/gehmehgeh) |
| 2021-08-17 19:20:16 | × | pompez quits (~martin@user/pompez) (Client Quit) |
| 2021-08-17 19:33:09 | → | Axman6 joins (~Axman6@user/axman6) |
| 2021-08-17 19:35:27 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 245 seconds) |
| 2021-08-17 19:35:39 | × | Axma97927 quits (~Axman6@user/axman6) (Ping timeout: 256 seconds) |
| 2021-08-17 19:40:06 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-08-17 19:42:30 | × | chisui quits (~chisui@200116b864e3ed008dc027ad9120a9d2.dip.versatel-1u1.de) (Quit: Client closed) |
| 2021-08-17 19:45:13 | → | chisui joins (~chisui@200116b864e3ed0070d95a3d3da0f298.dip.versatel-1u1.de) |
| 2021-08-17 19:46:20 | → | aegon joins (~mike@174.127.249.180) |
| 2021-08-17 19:46:28 | <aegon> | ws ge |
| 2021-08-17 19:46:33 | <aegon> | whoops |
| 2021-08-17 19:59:05 | bryan[m] | is now known as chreekat[m] |
| 2021-08-17 20:00:06 | → | jakalx joins (~jakalx@base.jakalx.net) |
| 2021-08-17 20:00:29 | → | jgeerds joins (~jgeerds@55d45555.access.ecotel.net) |
| 2021-08-17 20:00:37 | → | fernand joins (~fernand@179.156.35.4) |
| 2021-08-17 20:00:38 | × | stiell quits (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2021-08-17 20:01:06 | → | stiell joins (~stiell@gateway/tor-sasl/stiell) |
| 2021-08-17 20:04:16 | → | Cajun joins (~Cajun@user/cajun) |
| 2021-08-17 20:05:45 | × | juhp quits (~juhp@128.106.188.220) (Ping timeout: 268 seconds) |
| 2021-08-17 20:06:49 | → | juhp joins (~juhp@128.106.188.220) |
| 2021-08-17 20:07:29 | × | _ht quits (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
| 2021-08-17 20:08:02 | × | fernand quits (~fernand@179.156.35.4) (Quit: Connection closed) |
| 2021-08-17 20:14:10 | × | lavaman quits (~lavaman@98.38.249.169) (Ping timeout: 240 seconds) |
| 2021-08-17 20:14:31 | × | chisui quits (~chisui@200116b864e3ed0070d95a3d3da0f298.dip.versatel-1u1.de) (Ping timeout: 246 seconds) |
| 2021-08-17 20:17:37 | × | mei quits (~mei@user/mei) (Ping timeout: 248 seconds) |
| 2021-08-17 20:22:47 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-08-17 20:27:30 | → | acidjnk_new3 joins (~acidjnk@p200300d0c72b955208843bbbc6b733a4.dip0.t-ipconnect.de) |
| 2021-08-17 20:27:31 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-08-17 20:30:44 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2021-08-17 20:31:25 | → | retroid_ joins (~retro@5ec19a54.skybroadband.com) |
| 2021-08-17 20:35:40 | × | MQ-17J quits (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Read error: Connection reset by peer) |
All times are in UTC.