[R-SIG-Mac] R-SIG-Mac Digest, Vol 261, Issue 2

[Simon Urbanek]

> On Dec 12, 2024, at 10:00 AM, Duncan Murdoch <murdoch.duncan using 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.duncan using gmail.com>
>>> To: R-SIG-Mac <R-SIG-Mac using r-project.org>
>>> Subject: [R-SIG-Mac] R.app not handling events
>>> Message-ID: <bdf048f1-b010-4845-a67a-f24edf6345be using 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.

Cheers,
Simon