Logs: liberachat/#haskell
| 2025-09-07 08:12:14 | × | nshepperd quits (nshepperd@2600:3c03::f03c:92ff:fe28:92c9) (Quit: quit) |
| 2025-09-07 08:15:52 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-09-07 08:16:38 | × | hakutaku quits (~textual@chen.yukari.eu.org) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2025-09-07 08:23:36 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-07 08:28:07 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-09-07 08:36:57 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 2025-09-07 08:38:57 | → | acidjnk joins (~acidjnk@p200300d6e7171913b85d875ab8253342.dip0.t-ipconnect.de) |
| 2025-09-07 08:38:59 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-07 08:40:55 | × | sroso quits (~sroso@user/SrOso) (Read error: Connection reset by peer) |
| 2025-09-07 08:41:33 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 252 seconds) |
| 2025-09-07 08:43:38 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-09-07 08:51:54 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-07 08:56:45 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 2025-09-07 08:58:29 | → | Tuplanolla joins (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2025-09-07 09:03:55 | trickard_ | is now known as trickard |
| 2025-09-07 09:04:48 | × | tzh quits (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-09-07 09:07:23 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-07 09:14:23 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 2025-09-07 09:14:36 | → | AlexNoo_ joins (~AlexNoo@178.34.162.29) |
| 2025-09-07 09:17:37 | × | AlexZenon quits (~alzenon@94.233.241.149) (Ping timeout: 256 seconds) |
| 2025-09-07 09:18:16 | × | AlexNoo quits (~AlexNoo@94.233.241.149) (Ping timeout: 248 seconds) |
| 2025-09-07 09:19:30 | × | trickard quits (~trickard@cpe-53-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-09-07 09:19:43 | → | trickard_ joins (~trickard@cpe-53-98-47-163.wireline.com.au) |
| 2025-09-07 09:20:57 | → | emmanuelux joins (~emmanuelu@user/emmanuelux) |
| 2025-09-07 09:22:00 | × | tomboy64 quits (~tomboy64@user/tomboy64) (Ping timeout: 245 seconds) |
| 2025-09-07 09:22:21 | → | AlexZenon joins (~alzenon@178.34.162.29) |
| 2025-09-07 09:23:03 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 2025-09-07 09:24:37 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-07 09:27:23 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2025-09-07 09:29:32 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-09-07 09:37:00 | × | nshepperd2 quits (~nshepperd@2a01:4f9:3b:4cc9::2) (Quit: The Lounge - https://thelounge.chat) |
| 2025-09-07 09:39:40 | → | nshepperd2 joins (~nshepperd@2a01:4f9:3b:4cc9::2) |
| 2025-09-07 09:40:00 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-07 09:41:00 | <arahael> | I'm attempting to check for data in a pty, however, the only routines available are to actually block until I'm reading from it. I'm using spawnWithPty from System.Process.Pty. Is my only option to spawn a separate thread and do blocking stuff in that thread? |
| 2025-09-07 09:42:25 | <arahael> | (And using forkOS at that) |
| 2025-09-07 09:43:18 | <tomsmeding> | should be no need for forkOS, the GHC runtime is asynchronous under the hood anyway |
| 2025-09-07 09:43:40 | <tomsmeding> | the ghc-haskell-ish way would indeed be to forkIO and block there |
| 2025-09-07 09:44:50 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-09-07 09:44:50 | <tomsmeding> | arahael: what would you do with the result of a check if data is currently available? Would you do polling? |
| 2025-09-07 09:45:10 | <arahael> | Well, if there was data available, I'd be reading it. |
| 2025-09-07 09:45:17 | <tomsmeding> | and if there wasn't? |
| 2025-09-07 09:45:23 | <arahael> | If there is no data availabl,e I'd be querying something else and THEN checking if there's data. |
| 2025-09-07 09:45:28 | <tomsmeding> | I see |
| 2025-09-07 09:45:36 | <tomsmeding> | so your own scheduler? |
| 2025-09-07 09:45:40 | <arahael> | Basically yes. |
| 2025-09-07 09:45:46 | <tomsmeding> | the GHC RTS has a good scheduler :) |
| 2025-09-07 09:45:53 | <arahael> | "If there's data on A, process A. Otherwise if there's data on B, process B. Repeat". |
| 2025-09-07 09:46:14 | <arahael> | Hmm, so I'm inferring from your response that the blocking routines for these reads is not blocking the OS thread? |
| 2025-09-07 09:46:19 | <tomsmeding> | yes |
| 2025-09-07 09:46:39 | <tomsmeding> | start two forkIO threads to wait for data on A and B, and send the results on a Chan (Either MsgA MsgB) that you consume in a third forkIO thread |
| 2025-09-07 09:46:57 | <arahael> | Awesome, that works then, how would I normally know, though, just from reading the code? I'm observing functions such as: threadWaitReadPty :: Pty -> IO () |
| 2025-09-07 09:46:59 | <tomsmeding> | if you don't need to handle the messages centrally in one place you can handle them in the A and B threads immediately, of course |
| 2025-09-07 09:47:14 | <tomsmeding> | arahael: in principle, _nothing_ in the GHC RTS blocks the OS thread |
| 2025-09-07 09:47:25 | <tomsmeding> | there are exceptions: foreign calls block |
| 2025-09-07 09:47:33 | <tomsmeding> | "unsafe" foreign calls, that is |
| 2025-09-07 09:47:35 | <arahael> | Ah, so if it were to block the OS thread, it should be very very strongly called out in the documentation, then? |
| 2025-09-07 09:47:40 | <tomsmeding> | yes |
| 2025-09-07 09:47:42 | <arahael> | Excellent. |
| 2025-09-07 09:47:49 | <tomsmeding> | if it isn't, file a bug :p |
| 2025-09-07 09:47:53 | <arahael> | :P |
| 2025-09-07 09:48:54 | <tomsmeding> | arahael: there is one pernicious thing that blocks an OS thread in GHC haskell: a tight loop that doesn't allocate |
| 2025-09-07 09:49:21 | <tomsmeding> | scheduler yields occur on allocation, so if you have a tight loop that doesn't allocate, it doesn't yield and it doesn't relinquish the OS thread |
| 2025-09-07 09:49:30 | <arahael> | I've heard about that. |
| 2025-09-07 09:49:33 | <tomsmeding> | (the runtime is kind of cooperatively scheduled) |
| 2025-09-07 09:49:38 | <arahael> | Yeah, makes sense. |
| 2025-09-07 09:49:50 | <tomsmeding> | iirc there's an option to GHC that makes it insert more yields |
| 2025-09-07 09:49:59 | <tomsmeding> | if you suspect that this is causing you pain |
| 2025-09-07 09:50:13 | <arahael> | I think I can cross that bridge if I ever get to it, I think what I needed now was to sort of learn the more typical conventions, so you've been very helpful. |
| 2025-09-07 09:50:20 | <tomsmeding> | yay :) |
| 2025-09-07 09:51:40 | <tomsmeding> | this one https://downloads.haskell.org/ghc/latest/docs/users_guide/using-optimisation.html#ghc-flag-fomit-yields |
| 2025-09-07 09:51:59 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 2025-09-07 09:52:08 | <arahael> | Ah, cool. |
| 2025-09-07 09:53:25 | → | ljdarj joins (~Thunderbi@user/ljdarj) |
| 2025-09-07 09:55:24 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-07 09:56:00 | <tomsmeding> | there are also some operations on the haskell level that are "non-interruptible" ( https://hackage.haskell.org/package/base-4.21.0.0/docs/Control-Exception.html#g:12 ), which can be important if you do tricky things with concurrency and exceptions (and MVars, mostly) |
| 2025-09-07 09:56:20 | <tomsmeding> | but they are non-interruptible _on the haskell level_, meaning that you need to reach for heavier-handed exception machinery to interrupt them |
| 2025-09-07 09:56:30 | <tomsmeding> | they still don't block the OS thread on the scheduler level |
| 2025-09-07 09:57:47 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 244 seconds) |
| 2025-09-07 09:57:50 | <arahael> | Nice, I'm not expecting to do anything 'tricky' at this stage. |
| 2025-09-07 09:57:59 | <tomsmeding> | cool, then you should forget about this particular bit :p |
| 2025-09-07 09:58:11 | <arahael> | And if I am, then I'll be re-asking here to figure out what I'm doing wrong. :P |
| 2025-09-07 09:58:16 | <tomsmeding> | please do |
| 2025-09-07 09:58:28 | trickard_ | is now known as trickard |
| 2025-09-07 09:58:44 | <arahael> | Been ages since I've been here, actually, been out of the haskell space for a while. I miss it. |
| 2025-09-07 09:59:09 | <tomsmeding> | I hope you enjoy being here :) |
| 2025-09-07 10:00:08 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-09-07 10:00:31 | <arahael> | I am. :) It's so refreshing. |
| 2025-09-07 10:00:37 | <arahael> | Nice having a real type system again. |
| 2025-09-07 10:01:35 | <tomsmeding> | just looked at that suspiciously named threadWaitRead function; I'm 99% sure the "thread" referred to there is the Haskell-level forkIO thread |
| 2025-09-07 10:02:09 | <tomsmeding> | a few functions deep you end up here https://hackage.haskell.org/package/base-4.14.0.0/docs/src/GHC.Event.Thread.html#threadWait |
| 2025-09-07 10:02:09 | <arahael> | Ah, good. |
| 2025-09-07 10:02:20 | <arahael> | I was confused why I couldn't get the handle from it, though. |
| 2025-09-07 10:02:26 | <arahael> | (getFd is not exported in that module) |
| 2025-09-07 10:02:31 | <tomsmeding> | which seems to implement the actual waiting by registering a callback on some kind of event; that callback does a putMVar, and the actual waiting is a takeMVar |
| 2025-09-07 10:03:22 | <tomsmeding> | yeah good question |
| 2025-09-07 10:04:07 | <tomsmeding> | maaybe to have future compatibility with platforms where a pty is not a file descriptor? |
| 2025-09-07 10:04:18 | <tomsmeding> | but then the "Portability" field at the top of the docs has value "haha"... :p |
| 2025-09-07 10:04:22 | <Franciman> | ski: can we have ontological modelling in haskell? |
| 2025-09-07 10:04:24 | <arahael> | I did notice that. :P |
| 2025-09-07 10:09:11 | <tomsmeding> | @tell merijn why did you make the Pty type in posix-pty abstract, i.e. why does the user have no ability to get the underlying Fd? (tell arahael your answer) |
All times are in UTC.