Re: [Rd] GUI's and R background processes
(Sorry, originally sent to wrong list.) Anne, you can accomplish your goal by using my Rdsm package, which adds a threads-like capability to R. You can download it from CRAN. Look in particular in the examples/ directory. The file WebProbe.R is pretty much exactly the same usage that you want. Look at Auction.R too. You may also find my UseR! presentation on Rdsm to be helpful, user2010.org/slides/Matloff.pdf You could do the same thing, though less directly and I believe less conveniently, using some of the packages Louis mentioned, as well as bigmemory. Norm Matloff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] GUI's and R background processes
Hello, I am new to R and have created an application using R 2.10, with a graphical UI using TclTk 8.5, running on windows 7, quad core machine. The intention of the application is to launch calculations and display results on a graphical dashboard. I've reached a roadblock, and I need to confirm that the following CANNOT be done. I've been trying to find a mechanism for doing the following: 1. From the dashboard, start a huge calculation (i.e. call a function) that take at least 30 seconds to run, but without tying up the other dashboard features 2. Dashboard can detect when the calculation is finished 3. Dashboard can display incremental results as the calculation runs (i.e. status/progress) The requirement is to kickoff 4 calculations (#1), but I don't want the user to wait for the others to finish. The calculations are not dependent. I just need to display results. I've been reading that threading in R is not an option. I tried using the multicore package, but that is still synchronous. I looked at multicore, fork(), addTaskCallback(), and TclTk threading, and none of these seem like an option. Is there a way to launch multiple R scripts from controller that can communicate back and forth? I believe this means that the separate processes are able to communicate. I certainly appreciate any direction you can provide. I really want to find some good news to tell the boss, though, since we went down this path before realizing the limitations. Thanks very much, Anne [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] GUI's and R background processes
Anne George wrote: Hello, I am new to R and have created an application using R 2.10, with a graphical UI using TclTk 8.5, running on windows 7, quad core machine. The intention of the application is to launch calculations and display results on a graphical dashboard. I've reached a roadblock, and I need to confirm that the following CANNOT be done. I've been trying to find a mechanism for doing the following: 1. From the dashboard, start a huge calculation (i.e. call a function) that take at least 30 seconds to run, but without tying up the other dashboard features 2. Dashboard can detect when the calculation is finished 3. Dashboard can display incremental results as the calculation runs (i.e. status/progress) The requirement is to kickoff 4 calculations (#1), but I don't want the user to wait for the others to finish. The calculations are not dependent. I just need to display results. I've been reading that threading in R is not an option. I tried using the multicore package, but that is still synchronous. I looked at multicore, fork(), addTaskCallback(), and TclTk threading, and none of these seem like an option. Is there a way to launch multiple R scripts from controller that can communicate back and forth? I believe this means that the separate processes are able to communicate. I certainly appreciate any direction you can provide. I really want to find some good news to tell the boss, though, since we went down this path before realizing the limitations. This is possible, but not easy. You need to work at the C level. The key is that the long running processes need to periodically tell R to check for user events by calling R_ProcessEvents(); R_CheckUserInterrupt(); at the C level. This works in Windows in current versions, and I believe on all platforms in R-devel. The code should be prepared for R to call it again during R_ProcessEvents, so if it is not re-entrant, it should arrange to signal an error. It should be prepared for the R_CheckUserInterrupt call to never return if the user happened to interrupt the calculation. You probably only want one processor to do this, and let it check on the other cores to see if there are any results ready. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
