search for: have_aqua

Hello, Up to R 2.6.2, I used to start Tcl *without Tk* (I need only Tcl for some part of my work, like a socket server written in Tcl only, for instance) with this code under Mac OS X (particularly on this system, because I don't want to start X11 just to use Tcl code, which is required for Tk!): > Sys.unsetenv("DISPLAY") > library(tcltk) I got then the message

It turns out that the behavior of starting just Tcl was actually a bug. Apparently the intention was to attempt to start Tk regardless of the DISPLAY variable, because some TclTk implementation such as Aqua Tcl/Tk don't require DISPLAY and thus would not be loaded. Due to a bug (HAVE_AQUA was not included in Rconfig.h before R 2.7.0), though, this was not the case. I'll leave it to tcltk users/maintainers to decide the right way forward. Essentially I see two options: 1) status quo: tcltk always attempts to load Tk and fails on an error 2) allow some (possibly cross-platfor...

.../blob/trunk/src/unix/sys-unix.c#L421-L453) * src/gnuwin32/system.c (https://github.com/wch/r-source/blob/trunk/src/gnuwin32/system.c#L110-L140) So, they're clearly different implementations on Windows and Unix. Also, for the Unix implementation, the code differ based on preprocessing directive HAVE_AQUA, which could explain why Spencer observes a different behavior than Peter and Berend (all on macOS). Whenever the R_CheckUserInterrupt() function is called it in turn always calls R_ProcessEvents(). At the end, there is a code snippet - if (R_interrupts_pending) onintr(); - which is Windows spec...

...src/gnuwin32/system.c >> (https://github.com/wch/r-source/blob/trunk/src/gnuwin32/system.c#L110-L140) >> >> So, they're clearly different implementations on Windows and Unix. >> Also, for the Unix implementation, the code differ based on >> preprocessing directive HAVE_AQUA, which could explain why Spencer >> observes a different behavior than Peter and Berend (all on macOS). >> >> >> Whenever the R_CheckUserInterrupt() function is called it in turn >> always calls R_ProcessEvents(). At the end, there is a code snippet - >> if (R_i...

...c#L421-L453) > * src/gnuwin32/system.c > (https://github.com/wch/r-source/blob/trunk/src/gnuwin32/system.c#L110-L140) > > So, they're clearly different implementations on Windows and Unix. > Also, for the Unix implementation, the code differ based on > preprocessing directive HAVE_AQUA, which could explain why Spencer > observes a different behavior than Peter and Berend (all on macOS). > > > Whenever the R_CheckUserInterrupt() function is called it in turn > always calls R_ProcessEvents(). At the end, there is a code snippet - > if (R_interrupts_pending) oni...

...(https://github.com/wch/r-source/blob/trunk/src/gnuwin32/system.c#L110-L140) >>>> >>>> So, they're clearly different implementations on Windows and Unix. >>>> Also, for the Unix implementation, the code differ based on >>>> preprocessing directive HAVE_AQUA, which could explain why Spencer >>>> observes a different behavior than Peter and Berend (all on macOS). >>>> >>>> >>>> Whenever the R_CheckUserInterrupt() function is called it in turn >>>> always calls R_ProcessEvents(). At the end, th...

...t; >>> (https://github.com/wch/r-source/blob/trunk/src/gnuwin32/system.c#L110-L140) >>> >>> So, they're clearly different implementations on Windows and Unix. >>> Also, for the Unix implementation, the code differ based on >>> preprocessing directive HAVE_AQUA, which could explain why Spencer >>> observes a different behavior than Peter and Berend (all on macOS). >>> >>> >>> Whenever the R_CheckUserInterrupt() function is called it in turn >>> always calls R_ProcessEvents(). At the end, there is a code snippe...

setTimeLimit(elapsed=1) causes a timeout error whenever a call takes more than one second. For instance, this is how it works on Windows (R 3.3.1): > setTimeLimit(elapsed=1) > Sys.sleep(10); message("done") Error in Sys.sleep(10) : reached elapsed time limit Also, the error propagates immediately and causes an interrupt after ~1 second; > system.time({ Sys.sleep(10);