search for: r_processevents

...ws and paint to them alright from R. However, the x11-window does not respond to any events. E.g. clicking the close-button simply does not close the window and the contents in the window do not get refreshed when it was hidden by other windows. I figured that the reason for this might be, that R_ProcessEvents () and handleEvent () in devX11.c do not get called (of course I might be completely wrong?). So I tried calling R_ProcessEvents () manually, but I can't get that to link (unresolved symbol R_ProcessEvents). Any hints on how I can get this to work? Thanks Thomas

...user interrupt could occur. This will happen frequently in R code and during Sys.sleep, but only at points in compiled C and Fortran code identified by the code author." The example here uses Sys.sleep(), which supports and detects user interrupts. The timeout error message is thrown by the R_ProcessEvents(void) function as defined in: * src/unix/sys-unix.c (https://github.com/wch/r-source/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...

...ntly in R code and during Sys.sleep, but only at >> points in compiled C and Fortran code identified by the code author." >> >> The example here uses Sys.sleep(), which supports and detects user interrupts. >> >> >> The timeout error message is thrown by the R_ProcessEvents(void) >> function as defined in: >> >> * src/unix/sys-unix.c >> (https://github.com/wch/r-source/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) >> >>...

...this only occurs > for > certain arguments, but we saw this on ~15 different machines today. > And it > seems to only be when running the Cocoa GUI. No problems at all with > this > under Windoze. Any ideas? The cause is pbeta_raw calling (indirectly via R_CheckUserInterrupt) R_ProcessEvents for every iteration - and for small p the number of iterations goes really high (e.g. for the case above n=99919). R_ProcessEvents is not a cheap operation, because it enters system event loop and processes any pending events. A quick fix could be the following patch, which checks for break onl...

...) && ! (event.xclient.message_type == _XA_WM_PROTOCOLS)) ! if (!inclose && event.xclient.data.l[0] == protocol) { ! XFindContext(display, event.xclient.window, devPtrContext, &temp); dd = (DevDesc *) temp; ! KillDevice(dd); } } static void R_ProcessEvents(void *data) --- 619,652 ---- xd->windowHeight = event.xconfigure.height; xd->resize = 1; } + else if (event.type == DestroyNotify) { + /* The window is being destroyed, kill the device, too. */ + XFindContext(display, event.xdestroywindow.window, +...

...t; will happen frequently in R code and during Sys.sleep, but only at > points in compiled C and Fortran code identified by the code author." > > The example here uses Sys.sleep(), which supports and detects user interrupts. > > > The timeout error message is thrown by the R_ProcessEvents(void) > function as defined in: > > * src/unix/sys-unix.c > (https://github.com/wch/r-source/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 diffe...

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 *rxdate, int *refills,int *rxs) { int i,j,k, total;...

...[...] extern "C" { void RosvallDynamicSkeleton(int *seed,char** file, int *attempts, int *resamples, double *conf) { int ret = confInfomap(seed[0],file,attempts[0],resamples[0],conf[0]); if(ret == 0) Rprintf("cluster map has been written to %s\n", file[0]); R_FlushConsole(); R_ProcessEvents(); return; // Return Nothing. } } extern "C" { void findConfCoreWrapper(SEXP gdiag, SEXP bootClusters, SEXP membership, SEXP conf) { multimap<double,treeNode,greater<double> > treeMap; multimap<double,treeNode,greater<double> >::iterator it_tM; int l =LENGTH(...

...[...] extern "C" { void RosvallDynamicSkeleton(int *seed,char** file, int *attempts, int *resamples, double *conf) { int ret = confInfomap(seed[0],file,attempts[0],resamples[0],conf[0]); if(ret == 0) Rprintf("cluster map has been written to %s\n", file[0]); R_FlushConsole(); R_ProcessEvents(); return; // Return Nothing. } } extern "C" { void findConfCoreWrapper(SEXP gdiag, SEXP bootClusters, SEXP membership, SEXP conf) { multimap<double,treeNode,greater<double> > treeMap; multimap<double,treeNode,greater<double> >::iterator it_tM; int l =LENGTH(...

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 segfaulting. Was it not possible to identify this location? I'm guessing that Valgrind is a bit more mature now than it was in 2001...? Frederick...

...points in compiled C and Fortran code identified by the code author." >>>> >>>> The example here uses Sys.sleep(), which supports and detects user >>>> interrupts. >>>> >>>> >>>> The timeout error message is thrown by the R_ProcessEvents(void) >>>> function as defined in: >>>> >>>> * src/unix/sys-unix.c >>>> >>>> (https://github.com/wch/r-source/blob/trunk/src/unix/sys-unix.c#L421-L453) >>>> * src/gnuwin32/system.c >>>> >>>> (https://git...

...[...] extern "C" { void RosvallDynamicSkeleton(int *seed,char** file, int *attempts, int *resamples, double *conf) { int ret = confInfomap(seed[0],file,attempts[0],resamples[0],conf[0]); if(ret == 0) Rprintf("cluster map has been written to %s\n", file[0]); R_FlushConsole(); R_ProcessEvents(); return; // Return Nothing. } } extern "C" { void findConfCoreWrapper(SEXP gdiag, SEXP bootClusters, SEXP membership, SEXP conf) { multimap<double,treeNode,greater<double> > treeMap; multimap<double,treeNode,greater<double> >::iterator it_tM; int l =LENGTH(...

...; 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 segfaulting. Was it not possible to >> identify this location? I'm guessing that Valgrind is a bit more >> mature now...

...but only at >>> points in compiled C and Fortran code identified by the code author." >>> >>> The example here uses Sys.sleep(), which supports and detects user >>> interrupts. >>> >>> >>> The timeout error message is thrown by the R_ProcessEvents(void) >>> function as defined in: >>> >>> * src/unix/sys-unix.c >>> >>> (https://github.com/wch/r-source/blob/trunk/src/unix/sys-unix.c#L421-L453) >>> * src/gnuwin32/system.c >>> >>> (https://github.com/wch/r-source/blob/trunk/...

...39;s being called recursively (ironically this same test fails to detect actual recursion). The gettingEvent value is not reset on error conditions, so the device becomes unusable for the remainder of its life. As far as I've been able to tell, the values set with setTimeLimit() are checked in R_ProcessEvents(), which is defined separately in gnuwin32/system.c and unix/sys-unix.c. If a time limit is exceeded, it error()s out. That in turn percolates up and through jump_to_top_ex(), as defined in main/errors.c, which eventually calls GEonExit() in main/engine.c, a function meant to reset some state on gr...

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

...;> 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 segfaulting. Was it not possible to >>>> identify this location? I'm guessing that Valgrind is a bit...

...t ofb.net wrote: > > 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 segfaulting. Was it not possible to > identify this location? I'm guessing that Valgrind is a bit more > mature now than it was in...

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.

...t;>> >>> 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 segfaulting. Was it not possible to >>> identify this location? I'm guessing that Valgrind is a bit more >&gt...