search for: r_processeveents

Hi, I'm working on a frontend for R. I have R running in a separate thread in my application using Rf_initEmbeddedR, and I'm using R_tryEval to run commands in R (i.e. I don't run the mainloop). Everything works fine, except the x11-device: I can open x11-windows and paint to them alright from R. However, the x11-window does not respond to any events. E.g. clicking the

Thank you for the feedback and confirmations. Interesting to see that it's also reproducible on macOS expect for Spencer; that might indicate a difference in builds. BTW, my original post suggested that timeout error was for sure detected while running Sys.sleep(10). However, it could of course also be that it is only detected after it finishes. For troubleshooting, the

On unix, unless event polling is enabled Sys.sleep just waits in a select() call (with a SIGINT handler in place) so the elapsed time isn't checked until after the select call is complete. Rstudio uses event polling, and in particular sets R_wait_usec to 10000, which means event and interrupt checks happen during a Sys.seep call. The R GUI on macOS doesn't seem to do this (but my lldb

On Feb 10, 2005, at 7:38 PM, George W. Gilchrist wrote: > Today I was running a graduate level stats lab using R and we > encountered a > major problem while using the current build of the Cocoa GUI: > >> From the GUI: >> system.time(pbinom(80, 1e5, 806/1e6)) > [1] 14.37 4.94 30.29 0.00 0.00 >> > >> From the command line on the same machine: >>

Hi, there are two problems in devX11.c. The one is an undocumented nuisance and the other isn't a bug until you try to embed an X11 device in another window (think tktoplevel() in tcltk package...). Let's take a look at locator() first: Assuming you call locator() with a current X11 device, this call is handled in X11_Locator (src/unix/X11/devX11.c). When you have one window open and

Spencer also had tools and rsconnect loaded (via a namespace) but it doesn't seem to make a difference for me if I load them. It also doesn't seem to matter for me whether it is CRAN R, locally built R, Terminal, R.app. However, RStudio differs > setTimeLimit(elapsed=1) Error: reached elapsed time limit > setTimeLimit(elapsed=1) Error: reached elapsed time limit >

Hi All, I tried my best to figure out how to deal with the freezing R console but with no luck. I followed the instructions of calling R_ProcessEvents() regularly but still couldn't work it out (the callings were removed from the below C code). I am using R-2.8.1 on Windows XP service pack 3. The Rtools is version 2.9. I have the following C code: void rx(int *n, int *m, int *rxmax,int

Hi there, I am trying to interface c++ code in R and make a package. With R CMD SHLIB the dll was created, but when I try R CMD check, I am getting 'undefined reference to..' linkage error messages. The relevant c++ source from conf-infomap.cpp: #include "conf-infomap.h" #include "R.h" // R functions #include "Rinternals.h" #include "Rmath.h" //

Hi there, I'm sorry if I a send it for second time, I've just subscribed for the list. I am trying to interface c++ code in R and make a package. With R CMD SHLIB the dll was created, but when I try R CMD check, I am getting 'undefined reference to..' linkage error messages. The relevant c++ source from conf-infomap.cpp: #include "conf-infomap.h" #include

Thanks Professor Dalgard. If you have a different way to fix the bug then I'd be happy to test it. Or whatever. I understand that maybe some data was being referenced before it had been initialized. I could also support moving the R_ProcessEvents call in another place, but it seems one would also like to generate some kind of warning message, at the location of the bad reference, rather than

On Mon, 31 Oct 2016, Henrik Bengtsson wrote: > Thank you for looking into this Luke. > > On Thu, Oct 27, 2016 at 9:26 AM, <luke-tierney at uiowa.edu> wrote: >> On unix, unless event polling is enabled Sys.sleep just waits in a >> select() call (with a SIGINT handler in place) so the elapsed time >> isn't checked until after the select call is complete.

Hi there, I am trying to interface c++ code in R and make a package. With R CMD SHLIB the dll was created, but when I try R CMD check, I am getting 'undefined reference to..' linkage error messages. The relevant c++ source from conf-infomap.cpp: #include "conf-infomap.h" #include "R.h" // R functions #include "Rinternals.h" #include "Rmath.h" //

Hi Peter Yes, that looks roughly right to me. I would be in favour of your option (b), partly because it is probably easiest and partly because that retains the basic graphics device startup logic pattern that is replicated across all(?) graphics devices. Paul On 28/04/19 11:39 AM, peter dalgaard wrote: > I had a look at the current code, and AFAICT it has essentially the same structure

Thank you for looking into this Luke. On Thu, Oct 27, 2016 at 9:26 AM, <luke-tierney at uiowa.edu> wrote: > On unix, unless event polling is enabled Sys.sleep just waits in a > select() call (with a SIGINT handler in place) so the elapsed time > isn't checked until after the select call is complete. Rstudio uses > event polling, and in particular sets R_wait_usec to 10000,

Hey all. Setting a time limit with setTimeLimit(), and then using getGraphicsEvent(), will cause graphics event handling for the current device to break on timeout, until the device is destroyed and recreated. The problem lies in do_getGraphicsEvent() checking the value of dd->gettingEvent and concluding it's being called recursively (ironically this same test fails to detect actual

The real problem is that pbeta can take forever. That's bug #7153 and a fix is within reach. Morten

I tested it. It fixes the bug and didn't seem to produce any errors. Thank you Professor Dalgaard! I'm so glad this has finally been addressed. I will update the bug report. (https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702) On Thu, May 02, 2019 at 04:48:51PM +0200, peter dalgaard wrote: >OK, this is now in R-devel, but only superficially tested (b/c this is a Mac). Please

I had a look at the current code, and AFAICT it has essentially the same structure as it did back then. I think it may have finally dawned upon me what the issue really is: The logic is that in Rf_addX11Device, we have if (!X11DeviceDriver(dev, display, width, height, ps, gamma, colormodel, maxcubesize, bgcolor, canvascolor,

I don't recall exactly what I did 18 years ago eiher and I likely don't have the time to dig into the archives and reconstruct. I can imagine that the issue had to do with the protocol around creating and mapping windows. Presumably the segfault comes from looking for events on a window that hasn't been created yet, or has already been destroyed, leading to a NULL reference somewhere.

OK, this is now in R-devel, but only superficially tested (b/c this is a Mac). Please check it out. -pd > On 30 Apr 2019, at 23:09 , Paul Murrell <paul at stat.auckland.ac.nz> wrote: > > Hi Peter > > Yes, that looks roughly right to me. I would be in favour of your option (b), partly because it is probably easiest and partly because that retains the basic graphics device