Took a while to find enough time to have a good look at this, but I
have this working now. I am using the for-loop calling the handlers.
Using only R_CheckUserInterrupt() did not work. It was a bit of work
to track down all of the function declarations in R's source.
Thanks!
Regards,
Jan
On Thu, Jul 22, 2010 at 4:06 PM, Simon Urbanek
<simon.urba...@r-project.org> wrote:
>
> On Jul 22, 2010, at 3:31 AM, Jan van der Laan wrote:
>
>> Thomas, Simon,
>>
>> Thank you for your answers. I will have a look at the code Thomas gave
>> me and probably also have another look at src/unix/sys-std.c. I'll get
>> back when I have this working, or, more likely, when I can't get this
>> to work.
>>
>> As for the example code. I know it is very fragile. I tried to make a
>> minimal complete example that showed the problem without having to
>> attach hundreds of lines of code that nobody will read. However, what
>> parts are unix specific? Is it the int Rf_initialize_R and
>> R_running_as_main_program? What non os specific options do I have?
>>
>
> I was talking about the snippet Thomas sent - not your code - yours was
> nicely minimalistic. The issue with running the handlers by hand is that it's
> unix-only. But as I corrected in my second e-mail - it is the way to go right
> now since there is no alternative at the moment (again, you may get away with
> simply calling R_CheckUserInterrupt() but some devices may be using input
> handlers in which case it is not sufficient). The fact that you can check
> handlers manually is a good thing but it may be worth considering providing
> an API call like R_idle(int timeoutMillis) that does the job across all
> platforms.
>
> Cheers,
> Simon
>
>
>
>> Again thank you for your answers.
>>
>> Regards,
>>
>> Jan
>>
>> On Wed, Jul 21, 2010 at 10:52 PM, Simon Urbanek
>> <simon.urba...@r-project.org> wrote:
>>>
>>> On Jul 21, 2010, at 4:28 PM, Simon Urbanek wrote:
>>>
>>>> Use
>>>> R_CheckUserInterrupt()
>>>>
>>>
>>> Actually, the above is true but assumes that you're running R's REPL and
>>> not your own R_ReadConsole (it will work even in your ReadConsole but unix
>>> handlers are not run in that case so only some events will work).
>>>
>>>
>>>> The code below is very fragile and unix-specific.
>>>>
>>>
>>> That is true, too, but even after R_ProcessEvenrts refactorization the
>>> handlers are still-unix specific so I stand corrected and you still have to
>>> run handlers manually (note that you don't need PolledEvents anymore since
>>> they are part of the handlers).
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>>>>>
>>>>> On Wednesday 21 July 2010, Jan van der Laan wrote:
>>>>>> How do I ensure that the windows keep being updated?
>>>>>
>>>>> in RKWard we run the following periodically during idle phases:
>>>>>
>>>>>
>>>>> // this basically copied from R's unix/sys-std.c (Rstd_ReadConsole)
>>>>> #ifndef Q_WS_WIN
>>>>> for (;;) {
>>>>> fd_set *what;
>>>>> what = R_checkActivityEx(R_wait_usec > 0 ? R_wait_usec : 50,
>>>>> 1,
>>>>> Rf_onintr);
>>>>> R_runHandlers(R_InputHandlers, what);
>>>>> if (what == NULL) break;
>>>>> }
>>>>> /* This seems to be needed to make Rcmdr react to events. Has this
>>>>> always
>>>>> been the case? It was commented out for a long time, without anybody
>>>>> noticing.
>>>>> */
>>>>> R_PolledEvents ();
>>>>> #else
>>>>> R_ProcessEvents();
>>>>> #endif
>>>>>
>>>>>
>>>>> Regards
>>>>> Thomas
>>>>> ______________________________________________
>>>>> R-devel@r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>> ______________________________________________
>>>> R-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>>
>>>
>>> ______________________________________________
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
