On 2024-12-11 6:22 p.m., Simon Urbanek wrote:
On Dec 12, 2024, at 10:00 AM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:
On 2024-12-11 3:43 p.m., Michael Hall wrote:
Message: 1
Date: Wed, 11 Dec 2024 12:25:42 -0500
From: Duncan Murdoch <murdoch.dun...@gmail.com>
To: R-SIG-Mac <R-SIG-Mac@r-project.org>
Subject: [R-SIG-Mac] R.app not handling events
Message-ID: <bdf048f1-b010-4845-a67a-f24edf634...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Every now and then R.app stops responding to various events while a
long-running command is executing. I can't scroll the console to look
at earlier results, and I don't see partial results until the whole
computation is complete. If I ask MacOS to switch to that window, it
won't come to the top (though clicking on it does bring it up, but I
need to be able to see part of it to do that).
Once it finishes it returns to the console prompt and things look fine,
but the same thing happens during the next long-running command.
This happens every now and then, but I haven't spotted the cause. The
only solution I've found is to quit the session and restart it.
Does anyone know what might be causing this, or a way to fix it without
ending the session?
Duncan Murdoch
You could maybe look at what the app shows on Activity Monitor. Is it doing
anything? CPU, IO?
You can spin dump from there but I’ve never found that particularly revealing.
It's definitely still working. The typical situation where I've seen this
lately is when doing some web scraping with RSelenium. Sometimes it takes 10
minutes to visit all the pages and find the info I'm after (not because it's a
lot of downloading, it's because the site is very slow).
Normally my code prints status reports as it goes so I can tell what's
happening in the console. When things are in the broken state, those don't
show up until everything is done. But I can still see the controlled copy of
Chrome visiting pages, so I know it hasn't crashed. It doesn't seem any slower,
it's just that there are no updates in the console or responses to user
interaction while the command is running.
The GUI only gets to update things if the user code allows it to process
events. If the package you are using doesn't let R process the event loop or if
it uses code that explicitly disallows it (e.g. for re-entrance reasons) then
there is nothing the GUI can since both R and the GUI run on the main thread
(macOS doesn't allow it otherwise) so the GUI only gets to respond if R
relinquishes control.
Note that some actions in the GUI require R code evaluations so those will all
bock until your code finishes, effectively freezing the GUI.
It would be nice to see what are the exact conditions - i.e., what is it that
blocks the event loop, ideally some reproducible example to see if there is
anything we can do about it in R itself.
I don't think it's RSelenium or another package keeping control for too
long without allowing a return to R. Most of the calls to it only take
a few seconds to execute; it's just that my R code has a lot of them, so
the R function takes 10 minutes to finish. There are lots of R
statements being executed.
However, it could be a package that is telling R to stop the GUI from
processing events, and then forgetting to restore things when done.
Lately it has only happened while RSelenium was executing, so that
suggests it may be the culprit, but I don't know how to trigger it so I
can't put together a reproducible example.
It was happening about once in 100 sessions using RSelenium and hasn't
happened again since I tried John Fox's app nap advice, but I haven't
had 100 sessions since then.
I've just discovered one thing that might be related. Normally if I
execute a long running command in the console, the cursor moves to the
next line as soon as it starts, and stays there until it's done.
However, if I run `Sys.sleep(10)` I get the same symptoms as I described
for the 10 seconds it executes. The cursor never advances, and Esc
doesn't interrupt it. Things go back to normal at the end, so that's
different from the broken state.
Duncan
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
