Richard Bodewits
2016-Sep-16 16:01 UTC
[Rd] getGraphicsEvent() questions, minor feature/tweak request, and patch(es).
Hey all, new R user and first timer here. I've been using getGraphicsEvent() on an X11-Xlib device in a kind of interactive loop, and would like to be able to stop it from printing newlines in the console when I don't actually want to print a prompt. Even an empty "" value still causes a newline right now. To not break any code that depends on this behavior, I figured getting C_getGraphicsEvent to accept an NA value would be the way to go. It strikes me as highly unlikely that there's any code out there built on expecting getGraphicsEvent() to error out when getting a 'prompt = NA' parameter, so this seems like a safe change to make. After rooting about in the R source for a bit I've found a way to implement this change myself in src/main/gevents.c, and I've included a patch as attachment. What I don't know is if there's a better or at least more conventional way to be checking for the NA value. Coercing with asChar() and only comparing against R_NaString causes NULL values, functions, expression objects and potentially others to become valid prompt values as well, so I'm using TYPEOF() to restrict accepted values further. I've found manually entered NA values are interpreted as being of LGLSXP, so that's the only type I'm accepting NA values for. Is there a better way? There's an isna() in library/utils/src/io.c, but that module doesn't seem to be available to the linker in the current build script for gevents.c's module, which would make it a more invasive patch to use. I'm also not certain it'd work the way I'd want it to, from looking at its internals. As far as I can tell, the prompt value is only used in two places; do_getGraphicsEvent() in src/main/gevents.c, and GA_eventHelper() in library/grDevices/src/devWindows.c. The latter has a sanity check for string-ness already, so making NA a possibility should be safe there, as well. That apparent lack of use elsewhere leads me to a question about the help file for getGraphicsEvent(). In it, the claim is made that 'prompt' is used to display a prompt text on the device. This might be true in MS Windows, but for X11 the prompt value seems to be solely used for Rprintf() to the console. Is this discrepency a bug or missing feature in the X11 implementation, an incorrect wording in the help, or an interpretation error on my side? Whatever it is, I've also included a minor patch for the help file to at least indicate support for 'prompt NA'. Apologies if I'm doing this all wrong, or if I'm missing obvious reasons why these patches are unacceptable. As I said, first timer here and new to R in general. ;-) - Richard Bodewits -------------- next part -------------- Index: src/main/gevents.c ==================================================================--- src/main/gevents.c (revision 71269) +++ src/main/gevents.c (working copy) @@ -135,7 +135,7 @@ checkArity(op, args); prompt = CAR(args); - if (!isString(prompt) || !length(prompt)) error(_("invalid prompt")); + if ((!isString(prompt) || !length(prompt)) && (TYPEOF(prompt) != LGLSXP || asChar(prompt) != R_NaString)) error(_("invalid prompt")); /* NB: cleanup of event handlers must be done by driver in onExit handler */ @@ -159,8 +159,10 @@ if (!count) error(_("no graphics event handlers set")); - Rprintf("%s\n", CHAR(asChar(prompt))); - R_FlushConsole(); + if (TYPEOF(prompt) != LGLSXP || asChar(prompt) != R_NaString) { + Rprintf("%s\n", CHAR(asChar(prompt))); + R_FlushConsole(); + } /* Poll them */ while (result == R_NilValue) { -------------- next part -------------- Index: src/library/grDevices/man/getGraphicsEvent.Rd ==================================================================--- src/library/grDevices/man/getGraphicsEvent.Rd (revision 71269) +++ src/library/grDevices/man/getGraphicsEvent.Rd (working copy) @@ -24,12 +24,12 @@ } \arguments{ - \item{prompt}{prompt to be displayed to the user in the graphics window} + \item{prompt}{prompt to be displayed to the user in the graphics window, or NA for no prompt} \item{onMouseDown}{a function to respond to mouse clicks} \item{onMouseMove}{a function to respond to mouse movement} \item{onMouseUp}{a function to respond to mouse button releases} \item{onKeybd}{a function to respond to key presses} - \item{consolePrompt}{prompt to be displayed to the user in the console} + \item{consolePrompt}{prompt to be displayed to the user in the console, or NA for no prompt} \item{which}{which graphics device does the call apply to?} \item{...}{items including handlers to be placed in the event environment} \item{env}{an environment to be used as the event environment}
Richard Bodewits
2016-Sep-18 12:12 UTC
[Rd] getGraphicsEvent() questions, minor feature/tweak request, and patch(es).
Attached a minor revision of the previous patch, to avoid NA_character_ prompt values from being printed as NA. - Richard Bodewits On 09/16/2016 06:01 PM, Richard Bodewits wrote:> Hey all, new R user and first timer here. > > I've been using getGraphicsEvent() on an X11-Xlib device in a kind of > interactive loop, and would like to be able to stop it from printing > newlines in the console when I don't actually want to print a prompt. > Even an empty "" value still causes a newline right now. > > To not break any code that depends on this behavior, I figured getting > C_getGraphicsEvent to accept an NA value would be the way to go. It > strikes me as highly unlikely that there's any code out there built on > expecting getGraphicsEvent() to error out when getting a 'prompt = NA' > parameter, so this seems like a safe change to make. > > After rooting about in the R source for a bit I've found a way to > implement this change myself in src/main/gevents.c, and I've included a > patch as attachment. What I don't know is if there's a better or at > least more conventional way to be checking for the NA value. > > Coercing with asChar() and only comparing against R_NaString causes NULL > values, functions, expression objects and potentially others to become > valid prompt values as well, so I'm using TYPEOF() to restrict accepted > values further. I've found manually entered NA values are interpreted as > being of LGLSXP, so that's the only type I'm accepting NA values for. Is > there a better way? There's an isna() in library/utils/src/io.c, but > that module doesn't seem to be available to the linker in the current > build script for gevents.c's module, which would make it a more invasive > patch to use. I'm also not certain it'd work the way I'd want it to, > from looking at its internals. > > As far as I can tell, the prompt value is only used in two places; > do_getGraphicsEvent() in src/main/gevents.c, and GA_eventHelper() in > library/grDevices/src/devWindows.c. The latter has a sanity check for > string-ness already, so making NA a possibility should be safe there, as > well. > > That apparent lack of use elsewhere leads me to a question about the > help file for getGraphicsEvent(). In it, the claim is made that 'prompt' > is used to display a prompt text on the device. This might be true in MS > Windows, but for X11 the prompt value seems to be solely used for > Rprintf() to the console. Is this discrepency a bug or missing feature > in the X11 implementation, an incorrect wording in the help, or an > interpretation error on my side? Whatever it is, I've also included a > minor patch for the help file to at least indicate support for 'prompt > NA'. > > Apologies if I'm doing this all wrong, or if I'm missing obvious reasons > why these patches are unacceptable. As I said, first timer here and new > to R in general. ;-) > > > - Richard Bodewits > > > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-------------- next part -------------- Index: src/main/gevents.c ==================================================================--- src/main/gevents.c (revision 71298) +++ src/main/gevents.c (working copy) @@ -135,7 +135,7 @@ checkArity(op, args); prompt = CAR(args); - if (!isString(prompt) || !length(prompt)) error(_("invalid prompt")); + if ((!isString(prompt) || !length(prompt)) && (TYPEOF(prompt) != LGLSXP || asChar(prompt) != R_NaString)) error(_("invalid prompt")); /* NB: cleanup of event handlers must be done by driver in onExit handler */ @@ -159,8 +159,10 @@ if (!count) error(_("no graphics event handlers set")); - Rprintf("%s\n", CHAR(asChar(prompt))); - R_FlushConsole(); + if (asChar(prompt) != R_NaString) { + Rprintf("%s\n", CHAR(asChar(prompt))); + R_FlushConsole(); + } /* Poll them */ while (result == R_NilValue) {
Seemingly Similar Threads
- Handlers in setGraphicsEventHandlers() can recursively call getGraphicsEvent(). Intended behavior?
- Handlers in setGraphicsEventHandlers() can recursively call getGraphicsEvent(). Intended behavior?
- Handlers in setGraphicsEventHandlers() can recursively call getGraphicsEvent(). Intended behavior?
- getGraphicsEvent on X11 and event queuing
- getGraphicsEvent on X11 and event queuing