Logs: freenode/#haskell
| 2020-11-02 20:57:34 | <monochrom> | This is why I'm better off as a computer scientist or programmer or the like. |
| 2020-11-02 20:57:50 | <tomsmeding> | apparently unicode has symbols for them 𝆑 𝆏 |
| 2020-11-02 20:58:10 | <monochrom> | If the code says "x = 1" then it is 1, what do you mean musicality allows you to change it to 2. |
| 2020-11-02 20:58:37 | <tomsmeding> | something with physicists and pi? |
| 2020-11-02 20:58:46 | <bqv> | termbin.com doesn't like recieving this many lines... |
| 2020-11-02 20:58:51 | <tomsmeding> | 149? |
| 2020-11-02 20:58:58 | <bqv> | oh no i was gonna send the full thing |
| 2020-11-02 20:58:59 | <tomsmeding> | sounds like a crappy pastebin, try mine |
| 2020-11-02 20:59:05 | <dsal> | bqv: I think you're just supposed to dump them into irc if you have too many lines. |
| 2020-11-02 20:59:05 | <tomsmeding> | oh lol |
| 2020-11-02 20:59:13 | <bqv> | it's only 1.9mb |
| 2020-11-02 20:59:27 | → | ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) |
| 2020-11-02 20:59:40 | <tomsmeding> | tar cz * | curl --data-binary @/dev/stdin https://tomsmeding.com/gooi/things.tar.gz |
| 2020-11-02 21:00:02 | × | mmalecki quits (~mmalecki@154.13.1.56) () |
| 2020-11-02 21:00:21 | → | geowiesnot joins (~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) |
| 2020-11-02 21:00:28 | <bqv> | i can't tell if that succeeded or not |
| 2020-11-02 21:00:33 | <tomsmeding> | did it print a URL |
| 2020-11-02 21:00:44 | <bqv> | oh, yes |
| 2020-11-02 21:00:52 | <bqv> | https://tomsmeding.com/vang/IZn8dA/things.tar.gz |
| 2020-11-02 21:00:58 | <bqv> | also https://tomsmeding.com/vang/9OW8PN/things.tar.gz |
| 2020-11-02 21:01:59 | <tomsmeding> | identical? |
| 2020-11-02 21:02:06 | <bqv> | yeah lol |
| 2020-11-02 21:02:11 | <bqv> | i did it twice by mistake |
| 2020-11-02 21:02:35 | <tomsmeding> | (link is valid for 24 hours btw) |
| 2020-11-02 21:02:54 | <tomsmeding> | cabal > stack I approve |
| 2020-11-02 21:03:01 | <bqv> | :D |
| 2020-11-02 21:04:25 | × | ensyde quits (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) (Ping timeout: 264 seconds) |
| 2020-11-02 21:04:29 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2020-11-02 21:04:36 | × | ahmr88 quits (~ahmr88@cpc85006-haye22-2-0-cust131.17-4.cable.virginm.net) (Remote host closed the connection) |
| 2020-11-02 21:05:37 | <tomsmeding> | why does process 1691973 write out "wl_display_create() = 0x00007f4770000c80" c h a r a c t e r b y c h a r a c t e r |
| 2020-11-02 21:05:49 | <bqv> | that's coming from haskell, tbf |
| 2020-11-02 21:06:12 | <bqv> | i think it might be because i build that string using a monoid |
| 2020-11-02 21:06:14 | × | p-core quits (~Thunderbi@2001:718:1e03:5128:2ab7:7f35:48a1:8515) (Ping timeout: 268 seconds) |
| 2020-11-02 21:06:21 | <bqv> | (execWriter) |
| 2020-11-02 21:06:30 | <tomsmeding> | ah no it's just String being String I think |
| 2020-11-02 21:06:36 | <bqv> | heh |
| 2020-11-02 21:06:43 | <tomsmeding> | but that's your haskell, apparently? |
| 2020-11-02 21:07:02 | <bqv> | yes |
| 2020-11-02 21:07:13 | <bqv> | (that's a hilarious sideeffect, btw) |
| 2020-11-02 21:07:31 | <tomsmeding> | (line 1427 in your log) |
| 2020-11-02 21:07:40 | <bqv> | yeah i found it |
| 2020-11-02 21:09:02 | × | Kaivo quits (~Kaivo@104-200-86-99.mc.derytele.com) (Ping timeout: 264 seconds) |
| 2020-11-02 21:09:14 | × | bitmapper quits (uid464869@gateway/web/irccloud.com/x-kktozexnvkkmtbir) (Quit: Connection closed for inactivity) |
| 2020-11-02 21:09:25 | → | britva joins (~britva@31-10-157-156.cgn.dynamic.upc.ch) |
| 2020-11-02 21:11:22 | → | Kaivo joins (~Kaivo@ec2-15-222-231-32.ca-central-1.compute.amazonaws.com) |
| 2020-11-02 21:11:36 | → | ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) |
| 2020-11-02 21:11:56 | <bqv> | so the launcher sets handlers using sigaction on USR1 |
| 2020-11-02 21:11:57 | <tomsmeding> | merijn: apparently the haskell runtime uses signalfd4(2) and immediately after masks the signal |
| 2020-11-02 21:12:03 | <bqv> | it's using that x11 mechanism |
| 2020-11-02 21:12:06 | <tomsmeding> | (TIL sigalfd4) |
| 2020-11-02 21:12:18 | <bqv> | perhaps the haskell runtime is clearing something it shouldn't? |
| 2020-11-02 21:13:01 | <tomsmeding> | what process are you starting directly after you attach a handler to SIGUSR1 in haskell code? |
| 2020-11-02 21:13:14 | × | chaosmasttter quits (~chaosmast@p200300c4a72dee01a86cafb086ba766e.dip0.t-ipconnect.de) (Quit: WeeChat 2.9) |
| 2020-11-02 21:13:14 | <tomsmeding> | (process 1692017) |
| 2020-11-02 21:13:57 | <bqv> | i don't see anything fork-like happening around there |
| 2020-11-02 21:14:15 | <bqv> | the immediate next line is basically a call to wl_display_create() |
| 2020-11-02 21:14:24 | <bqv> | then a load of c marshalling |
| 2020-11-02 21:14:53 | <bqv> | (actually, none of my code specifically creates any processes, but the launcher does, and the library might) |
| 2020-11-02 21:15:11 | <tomsmeding> | ah |
| 2020-11-02 21:15:35 | × | refried_ quits (~textual@pool-108-20-26-90.bstnma.fios.verizon.net) (Quit: My MacBook Air has gone to sleep. ZZZzzz…) |
| 2020-11-02 21:15:54 | <bqv> | oh |
| 2020-11-02 21:16:05 | × | ensyde quits (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2020-11-02 21:16:15 | <bqv> | would it matter if the handler was within a forkOS bound thread that's blocked indefinitely? |
| 2020-11-02 21:16:23 | <bqv> | i thought because it's haskell code, it wouldn't be bound |
| 2020-11-02 21:16:29 | <bqv> | but maybe it's blocked for that reason? |
| 2020-11-02 21:16:42 | <tomsmeding> | ¯\_(ツ)_/¯ |
| 2020-11-02 21:17:07 | <tomsmeding> | I'm actually not all that familiar with the intricacies of forkOS, defer to the other people that contributed earlier :p |
| 2020-11-02 21:17:22 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2020-11-02 21:17:45 | → | refried_ joins (~textual@pool-108-20-26-90.bstnma.fios.verizon.net) |
| 2020-11-02 21:17:49 | <tomsmeding> | AH |
| 2020-11-02 21:18:17 | × | cole-h quits (~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) (Quit: Goodbye) |
| 2020-11-02 21:18:30 | <tomsmeding> | okay I was wrong, that signalfd4 is not the haskell rts, that's whatever library you're using |
| 2020-11-02 21:18:41 | <bqv> | oh, that's interesting |
| 2020-11-02 21:18:52 | → | loprakoa[m] joins (loprakoama@gateway/shell/matrix.org/x-xavaolgsmkbljkqt) |
| 2020-11-02 21:19:01 | <tomsmeding> | early on there is an rt_sigaction that binds a handler to USR1; that'll be your code, because quickly after there is that c h a r a c t e r call to wl_display_create() |
| 2020-11-02 21:19:49 | <tomsmeding> | later, though, at :13587-13588, your own haskell process (but I think the library, really) makes a signal FD and then SIG_BLOCK's USR1 in your process |
| 2020-11-02 21:20:00 | <tomsmeding> | hence your handler doesn't fire |
| 2020-11-02 21:20:28 | <bqv> | what on earth |
| 2020-11-02 21:20:37 | <geekosaur67> | that's documented |
| 2020-11-02 21:20:44 | <geekosaur67> | go read the signalfd4 manpage |
| 2020-11-02 21:21:10 | <tomsmeding> | geekosaur67: I think bqv is not reacting to the syscalls' behaviour, but the behaviour of the library he's using |
| 2020-11-02 21:21:18 | <bqv> | yeah |
| 2020-11-02 21:21:38 | <bqv> | oh interesting, i think i know what call's doing that |
| 2020-11-02 21:21:41 | → | p-core joins (~Thunderbi@2001:718:1e03:5128:2ab7:7f35:48a1:8515) |
| 2020-11-02 21:21:46 | <bqv> | maybe if i put the handler after that then |
| 2020-11-02 21:21:49 | × | tms_ quits (thomaav@cassarossa.samfundet.no) (Ping timeout: 264 seconds) |
| 2020-11-02 21:22:01 | <geekosaur67> | I expect it just lists out all the non-SIG_DFL signals and does the signalfd4() thing on them |
| 2020-11-02 21:22:08 | <geekosaur67> | so it's just not expecting your handler |
| 2020-11-02 21:22:25 | <bqv> | well actually, to be honest that's perfectly reasonable behaviour, i was just confused as to how it was occuring |
| 2020-11-02 21:22:37 | <bqv> | but as long as nothing's broken, i can live with just setting an ignore handler |
| 2020-11-02 21:22:38 | <tomsmeding> | geekosaur67: it specifically only does it for CHLD and USR1 |
| 2020-11-02 21:23:08 | × | u0_a298` quits (~user@47.206.148.226) (Ping timeout: 256 seconds) |
| 2020-11-02 21:23:15 | <tomsmeding> | probably that's the best approach bqv |
| 2020-11-02 21:23:53 | → | ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) |
| 2020-11-02 21:24:05 | <tomsmeding> | note that process 1691972 also puts a SIG_BLOCK on USR1 at line 3922, but that's for a different process (not sure which) |
| 2020-11-02 21:24:26 | → | cole-h joins (~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) |
| 2020-11-02 21:24:29 | <bqv> | yes, by my guess, one is for my process, one is for Xwayland |
| 2020-11-02 21:25:39 | <tomsmeding> | ah at some point your haskell process (but really the library probably) forks to 1692017, puts a SIG_IGN handler on USR1, and then exec's Xwayland |
| 2020-11-02 21:25:56 | <tomsmeding> | so it's not the block that's the culprit, it's that overwrite |
| 2020-11-02 21:25:59 | <tomsmeding> | I think |
All times are in UTC.