Andrew,
> You may like to give CXXR a try
> (http://www.cs.kent.ac.uk/projects/cxxr/). In CXXR the R interpreter is
> written in C++, and a user interrupt is handled by throwing a C++
> exception, so the stack is unwound in an orderly fashion, destructors
> are invoked, etc.
Thank you for thi
Peter,
On 25/04/11 10:22, schattenpfla...@arcor.de wrote:
1. Calling R_CheckUserInterrupt() interrupts immediately, so I have no
possibility to exit my code gracefully. In particular, I suppose that
objects created on the heap (e.g., STL containers) are not destructed
properly.
Sorry not to ha
Hi,
I've been thinking about how to handle c++ threads that were started via
Rcpp calls to some of my c++ libraries from R. My main obstacle is trying to
make sure that users don't try to process files that are being generated by
a thread before the thread finishes. One thing I am considering is ha
On Apr 26, 2011, at 7:30 AM, schattenpfla...@arcor.de wrote:
> I have tested the solutions suggested by Simon and Thomas on a Linux machine.
> These are my findings:
>
>> On Windows you can look at the variable "UserBreak", available from
>> Rembedded.h. Outside of Windows, you can look at R_in
I have tested the solutions suggested by Simon and Thomas on a Linux
machine. These are my findings:
On Windows you can look at the variable "UserBreak", available from
Rembedded.h. Outside of Windows, you can look at R_interrupts_pending,
available from R_ext/GraphicsDevice.h. R_ext/GraphicsDe
Dear Simon,
thanks again for your explanations. Your previous e-mail clarified
several points for me.
Actually, it just came to me that there is a hack you could use. [...]
That actually looks quite nice. At least when compared to my currently
only alternative of not interrupting at all. I w
Thank you for your response, Simon.
1. Calling R_CheckUserInterrupt() interrupts immediately, so I have
no possibility to exit my code gracefully. In particular, I suppose
that objects created on the heap (e.g., STL containers) are not
destructed properly.
In general, you're responsible for the
On Monday 25 April 2011, Simon Urbanek wrote:
> Actually, it just came to me that there is a hack you could use. The
> problem with it is that it will eat all errors, even if they were not
> yours (e.g. those resulting from events triggered the event loop), so I
> would not recommend it for general
Actually, it just came to me that there is a hack you could use. The problem
with it is that it will eat all errors, even if they were not yours (e.g. those
resulting from events triggered the event loop), so I would not recommend it
for general use. But here we go:
static void chkIntFn(void *d
On Apr 25, 2011, at 11:09 AM, schattenpfla...@arcor.de wrote:
> Thank you for your response, Simon.
>
>>> 1. Calling R_CheckUserInterrupt() interrupts immediately, so I have
>>> no possibility to exit my code gracefully. In particular, I suppose
>>> that objects created on the heap (e.g., STL co
On Apr 25, 2011, at 5:22 AM, schattenpfla...@arcor.de wrote:
> Hello,
>
> I am writing an R interface for one of my C++ programs. The computations in
> C++ are very time consuming (several hours), so the user needs to be able to
> interrupt them. Currently, the only way I found to do so is cal
Hello,
I am writing an R interface for one of my C++ programs. The computations
in C++ are very time consuming (several hours), so the user needs to be
able to interrupt them. Currently, the only way I found to do so is
calling R_CheckUserInterrupt() frequently. Unfortunately, there are
sever
12 matches
Mail list logo
