Logs: liberachat/#haskell
| 2021-06-07 09:42:26 | <kuribas> | I mean ToField/FromField, sorry :) |
| 2021-06-07 09:44:18 | × | fizbin quits (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Ping timeout: 252 seconds) |
| 2021-06-07 09:45:53 | × | mpt quits (~tom@2a02:908:1862:49e0::5) (Ping timeout: 272 seconds) |
| 2021-06-07 09:47:58 | ← | bfrk parts (~Thunderbi@200116b8451fe900af67d936efb17ea9.dip.versatel-1u1.de) () |
| 2021-06-07 09:54:46 | → | nkpart joins (uid3844@id-3844.highgate.irccloud.com) |
| 2021-06-07 09:55:05 | × | dunkeln quits (~dunkeln@94.129.65.28) (Quit: leaving) |
| 2021-06-07 09:56:14 | → | boxscape joins (~boxscape@user/boxscape) |
| 2021-06-07 09:57:09 | × | azeem quits (~azeem@dynamic-adsl-94-34-34-125.clienti.tiscali.it) (Ping timeout: 245 seconds) |
| 2021-06-07 09:58:40 | × | boxscape quits (~boxscape@user/boxscape) (Client Quit) |
| 2021-06-07 09:59:08 | → | boxscape joins (~boxscape@user/boxscape) |
| 2021-06-07 10:01:33 | → | azeem joins (~azeem@176.200.235.0) |
| 2021-06-07 10:02:27 | → | ddellacosta joins (~ddellacos@86.106.143.74) |
| 2021-06-07 10:06:44 | × | ddellacosta quits (~ddellacos@86.106.143.74) (Ping timeout: 245 seconds) |
| 2021-06-07 10:09:30 | × | JimL quits (~quassel@ti0577q162-3381.bb.online.no) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2021-06-07 10:11:42 | → | michalz joins (~user@185.246.204.107) |
| 2021-06-07 10:12:24 | <boxscape> | % const 4 (undefined :: Constraint) |
| 2021-06-07 10:12:24 | <yahb> | boxscape: 4 |
| 2021-06-07 10:12:28 | <boxscape> | seems really strange that this works |
| 2021-06-07 10:12:36 | → | _ht joins (~quassel@82-169-194-8.biz.kpn.net) |
| 2021-06-07 10:12:40 | × | bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2021-06-07 10:12:41 | <boxscape> | I would neither expect undefined :: Constraint to be well-typed, nor const a b if b :: Constraint |
| 2021-06-07 10:13:24 | <boxscape> | oh but I guess it's because Constraint is a regular data type rather than just a kind |
| 2021-06-07 10:14:04 | × | Erutuon quits (~Erutuon@user/erutuon) (Ping timeout: 268 seconds) |
| 2021-06-07 10:14:30 | → | neceve joins (~quassel@2a02:c7f:607e:d600:a95a:ecd2:e57a:3130) |
| 2021-06-07 10:17:59 | <Taneb> | :k Constraint |
| 2021-06-07 10:18:00 | <lambdabot> | * |
| 2021-06-07 10:18:14 | <boxscape> | % :i Constraint |
| 2021-06-07 10:18:15 | <yahb> | boxscape: type Constraint :: *; data Constraint; -- Defined in `GHC.Types' |
| 2021-06-07 10:18:49 | <boxscape> | doesn't look any different from Void, really |
| 2021-06-07 10:20:12 | × | GIANTWORLDKEEPER quits (~pjetcetal@2.95.204.25) (Ping timeout: 265 seconds) |
| 2021-06-07 10:23:00 | → | larkfisherman joins (~larkfishe@217.75.204.126) |
| 2021-06-07 10:23:04 | → | pasko__ joins (~larkfishe@217.75.204.126) |
| 2021-06-07 10:23:38 | <vaibhavsagar[m]> | how are people implementing timeouts when using the `websocket` library? |
| 2021-06-07 10:23:52 | <vaibhavsagar[m]> | System.Timeout or something else? |
| 2021-06-07 10:24:59 | → | eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:90fb:e693:9986:91e0) |
| 2021-06-07 10:25:27 | <vaibhavsagar[m]> | I'm not seeing anything included by default and my first impulse was to use `race` from `async` but it seems like the `timeout` in `base` is simpler and better for my purposes |
| 2021-06-07 10:26:01 | → | yd502 joins (~yd502@180.168.212.6) |
| 2021-06-07 10:26:24 | × | oxide quits (~lambda@user/oxide) (Ping timeout: 268 seconds) |
| 2021-06-07 10:28:05 | → | oxide joins (~lambda@user/oxide) |
| 2021-06-07 10:29:14 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:90fb:e693:9986:91e0) (Ping timeout: 245 seconds) |
| 2021-06-07 10:29:25 | <dminuoso> | vaibhavsagar[m]: Hold on, what kind of timeouts are you talking about? |
| 2021-06-07 10:30:29 | <vaibhavsagar[m]> | when I am receiving a message over a websocket, and I want to wait no more than x seconds |
| 2021-06-07 10:31:08 | <dminuoso> | vaibhavsagar[m]: Keep in mind the subtle bound issue of `timeout` |
| 2021-06-07 10:31:15 | <vaibhavsagar[m]> | I think the library is pretty simple/barebones in that sense, since it doesn't seem to include any way of handling timeouts by default |
| 2021-06-07 10:31:38 | <vaibhavsagar[m]> | what issue? |
| 2021-06-07 10:31:41 | <dminuoso> | Int is only guaranteed to give you [-2^29..2^29-1] |
| 2021-06-07 10:31:45 | <dminuoso> | And timeout wants nanoseconds. |
| 2021-06-07 10:31:46 | → | shryke joins (~shryke@91.103.43.254) |
| 2021-06-07 10:31:57 | <vaibhavsagar[m]> | oh yeah, I know timeout wants microseconds |
| 2021-06-07 10:32:08 | <dminuoso> | % 2^29 - 1 |
| 2021-06-07 10:32:08 | <yahb> | dminuoso: 536870911 |
| 2021-06-07 10:32:30 | <vaibhavsagar[m]> | that's not a problem for my use case I think |
| 2021-06-07 10:32:52 | <vaibhavsagar[m]> | I'm planning to wait maybe 5 minutes at most |
| 2021-06-07 10:32:52 | <dminuoso> | Well you asked for "n seconds" |
| 2021-06-07 10:33:02 | <dminuoso> | Oh sorry, its in microseconds. |
| 2021-06-07 10:33:19 | <vaibhavsagar[m]> | yeah, which is the same as n*10^6 microseconds |
| 2021-06-07 10:33:24 | <vaibhavsagar[m]> | I read the docs |
| 2021-06-07 10:33:26 | <dminuoso> | So anything up to 536 seconds will work, anything more is going to be implementation dependent |
| 2021-06-07 10:33:28 | <dminuoso> | Right |
| 2021-06-07 10:33:47 | <vaibhavsagar[m]> | you're not actually answering my question at all |
| 2021-06-07 10:33:57 | <vaibhavsagar[m]> | so `timeout` is fine then it sounds like |
| 2021-06-07 10:34:07 | <dminuoso> | timeout could work, just remember to send pings manually with `websockets` |
| 2021-06-07 10:34:37 | <dminuoso> | STM is probably a more robust choice |
| 2021-06-07 10:35:04 | <dminuoso> | websockets does not handle pings *or* answering to pings for you |
| 2021-06-07 10:35:09 | <dminuoso> | You gotta do that yourself :) |
| 2021-06-07 10:35:12 | <vaibhavsagar[m]> | I'm communicating with an external application over websockets |
| 2021-06-07 10:35:18 | <vaibhavsagar[m]> | I don't see how STM is better |
| 2021-06-07 10:35:54 | <vaibhavsagar[m]> | the external application is developed by a third party in a non-Haskell language |
| 2021-06-07 10:36:03 | <dminuoso> | ah wait, websockets comes with withPingThread, actually |
| 2021-06-07 10:36:07 | → | ddellacosta joins (~ddellacos@89.46.62.115) |
| 2021-06-07 10:36:22 | <vaibhavsagar[m]> | yes, I did notice that |
| 2021-06-07 10:36:57 | <dminuoso> | vaibhavsagar[m]: depending on how you want to run things, you might have multiple threads, one of which responds to pings with pong |
| 2021-06-07 10:37:03 | <dminuoso> | so stm could be used to coordinate these threads |
| 2021-06-07 10:38:01 | × | chexum quits (~chexum@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2021-06-07 10:38:55 | → | ddellaco_ joins (~ddellacos@89.45.224.251) |
| 2021-06-07 10:41:19 | × | ddellacosta quits (~ddellacos@89.46.62.115) (Ping timeout: 245 seconds) |
| 2021-06-07 10:41:30 | × | xsperry quits (~as@user/xsperry) (Ping timeout: 252 seconds) |
| 2021-06-07 10:43:29 | × | ddellaco_ quits (~ddellacos@89.45.224.251) (Ping timeout: 244 seconds) |
| 2021-06-07 10:50:39 | → | themc47 joins (~yecinem@89.246.239.190) |
| 2021-06-07 10:51:52 | <vaibhavsagar[m]> | hmm, I need to look into this, thanks |
| 2021-06-07 10:52:59 | × | mc47 quits (~yecinem@89.246.239.190) (Ping timeout: 245 seconds) |
| 2021-06-07 10:53:02 | × | larkfisherman quits (~larkfishe@217.75.204.126) (Quit: Leaving) |
| 2021-06-07 10:53:07 | × | pasko__ quits (~larkfishe@217.75.204.126) (Quit: Leaving) |
| 2021-06-07 10:53:16 | <dminuoso> | vaibhavsagar[m]: The thing is, websockets gives you two asynchronous channels (much like stdin/stdout). If you have just one message and you want to respond to it, websockets is just un-needed overkill |
| 2021-06-07 10:53:29 | <dminuoso> | Might as well just go play HTTP with say JSON ontop then |
| 2021-06-07 10:53:58 | <vaibhavsagar[m]> | I don't get to choose the communication channel |
| 2021-06-07 10:54:09 | <vaibhavsagar[m]> | that decision has already been made for me |
| 2021-06-07 10:54:16 | <vaibhavsagar[m]> | and there are multiple messages |
| 2021-06-07 10:54:25 | <vaibhavsagar[m]> | so websockets are not the worst idea |
| 2021-06-07 10:54:48 | × | cfricke quits (~cfricke@user/cfricke) (Quit: WeeChat 3.1) |
| 2021-06-07 10:56:03 | <vaibhavsagar[m]> | I already have a proof-of-concept working, we're not about to change it now :) |
| 2021-06-07 10:56:27 | → | lavaman joins (~lavaman@98.38.249.169) |
| 2021-06-07 10:56:32 | <dminuoso> | websockets is really odd, it's almost as if people re-invented TCP.. |
| 2021-06-07 10:56:41 | <dminuoso> | Ontop of HTTP. |
| 2021-06-07 10:57:15 | <vaibhavsagar[m]> | ¯_(ツ)_/¯ |
| 2021-06-07 10:58:36 | × | themc47 quits (~yecinem@89.246.239.190) (Quit: Leaving) |
| 2021-06-07 10:58:52 | → | mc47 joins (~yecinem@89.246.239.190) |
| 2021-06-07 11:00:45 | × | lavaman quits (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-06-07 11:01:00 | <tdammers> | case in point, you do get the entire HTTP stack below those websockets, so in practice that means you won't have to worry about encryption and authentication specifically for websockets, you can just piggy-back on whatever you already have in place for your other HTTP stuff |
| 2021-06-07 11:01:11 | <tdammers> | so yeah, it's a bit odd, but also quite helpful that way |
All times are in UTC.