From simon.urbanek at r-project.org  Sat Dec 15 21:41:23 2012
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Sat, 15 Dec 2012 15:41:23 -0500
Subject: [Rd] Could Rstd_Busy do something (src/unix/sys-std.c)?
In-Reply-To: <CAGBu4CPT_wK5xjdFxX0WrF=TxiS8-7zYENZ6FP=XkYVo41yyRg@mail.gmail.com>
References: <CAGBu4CNTtEcBEA6yB5tM8JkEDdVyTAr2xC+75Ay+dFM30=BTMg@mail.gmail.com>
	<CDB0FA0A-94E8-4BFA-961F-4ADA4ED04A2F@r-project.org>
	<CAGBu4CPT_wK5xjdFxX0WrF=TxiS8-7zYENZ6FP=XkYVo41yyRg@mail.gmail.com>
Message-ID: <77436EA2-B617-4267-9694-B1CCB35FF4B2@r-project.org>


On Dec 15, 2012, at 2:20 PM, Jakson Alves de Aquino wrote:

> On Sat, Dec 15, 2012 at 1:09 PM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>> On Dec 15, 2012, at 6:36 AM, Jakson Alves de Aquino wrote:
>>> I could avoid the crash if I knew that R is busy at the moment that
>>> it receives the SIGWINCH. Thus my question is: Could Rstd_Busy()
>>> set the value of a variable so packages like setwidth could know
>>> that R is busy?
>> 
>> You're looking at the wrong spot - the Busy callback is meant for UI
>> signaling that R may enter a longer time of processing, it is not
>> really an indicator that R is busy - R can be busy even without the
>> busy state being signaled.
> 
> Thanks for your suggestions!
> 
> Although the comment above Rstd_Busy() (at src/unix/sys-std.c) says
> "actions during (long) computations", the function is called whenever
> any command is entered in R Console.
> 
>> But back to your original question - there are a few spots where you
>> can process you request : the most obvious one is in the ReadConsole
>> callback - that callback doesn't return until the user has entered a
>> line - this would be a way to a GUI to handle this.
> 
> Both ptr_R_Busy and ptr_R_ReadConsole are declared on Rinterface.h,
> but I can't use them because setwidth doesn't provide front-end to R
> and Rinterface.h has the following statements:
> 
>    This header file is to provide hooks for alternative front-ends,
>    e.g. GUIs such as GNOME and Cocoa.  [...] It should not be
>    included by package sources unless they are providing such a
>    front-end.
> 
>> The other way is to register an input handler and signal your FD
>> when you get SIGWINCH, that guarantees that your handler will be
>> called as soon as possible after the signal has arrived - that is
>> probably what you want (see CarbonEL for a simple example how this
>> is used).
> 
> Based on CarbolEL, I added the following to setwidth_Start() function:
> 
>    int fds[2];
>    if(pipe(fds))
>        Rprintf("pipe > 0\n");
>    else
>        Rprintf("pipe = 0\n");
>    ifd = fds[0];
>    ofd = fds[1];
>    addInputHandler(R_InputHandlers, ifd, &uih, 32);
> 
> And, also based on CarbolEL, I created the following uih() function:
> 
>    static void uih(void *data) {
>      char buf[16];
> 
>      if(read(ifd, buf, 16) == 0){
>          Rprintf("read = 0 :: %s\n", buf);
>          Rprintf("%d written\n", write(ofd, buf, 16));
>      } else {
>          Rprintf("read != 0\n");
>      }
>    }
> 
> However, the uih() function never gets called.
> 

You didn't provide the signal yet - you have the initialization and receiving end ready - now you need to write the piece that triggers the input.

Cheers,
S


> Best,
> 
> -- 
> Jakson Alves de Aquino
> Federal University of Cear?
> Social Sciences Department
> www.lepem.ufc.br/aquino.php
> 
> 



[Rd] Could Rstd_Busy do something (src/unix/sys-std.c)?
Simon Urbanek