search for: myerrors

Hi, at the R prompt, is it possible to retrieve the last error (as in condition object of class "error")? I'm not asking for geterrmessage(), which only returns the error message (as a character string). I'm basically looking for a .Last.error or .Last.condition, analogously to .Last.value for values, which can be used when it is "too late" (not possible) to go back

Dear all, I try to understand why on my computer I do not clear all data with this code: #include <R.h> static int count = 0; class A { public: A(){ printf("c %d\n", count); count++; } ~A(){count--; printf("d %d\n", count); } }; extern "C" { void testAL(){ A a; { A b; } error("does not write [d 0]"); } }

I am trying to plot the mean and standard error of three separate conditions. For various reasons, I do not have access to the raw data from which the mean and error were derived and would like to make error bar plots utilizing only the actual mean and standard error values. Is there a way to do this in R? Thanks for any help in advance. james [[alternative HTML version deleted]]

On Sat, Sep 5, 2015 at 11:50 AM, Greg Stark <stark at mit.edu> wrote: > On Sat, Sep 5, 2015 at 6:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > This is more like a limitation of asan, not libFuzzer. > > By design, asan does not recover from the first crash. > > This feature has been criticized quite a lot, but I am still convinced > this >

Hi Mehdi, > If you subclass a diagnostic right now, isn’t the RTTI information available to the handler, which can then achieve the same dispatching / custom handling per type of diagnostic? > (I’m not advocating the diagnostic system, which I found less convenient to use than what you are proposing) I have to confess I haven't looked at the diagnostic classes closely. I'll take a

Hi All, Now that this thread has accumulated some feedback, I thought I'd try to summarize my thoughts on error handling in LLVM, and why I think this proposal is worth adopting: (1) Failure to check an error *is* a programmatic error, and our error system should reflect this. This makes it easy to spot mistakes in our error handling and correct them. (2) Error returns should describe all

Le lun. 9 d?c. 2019 ? 09:57, Tomas Kalibera <tomas.kalibera at gmail.com> a ?crit : > On 12/9/19 2:54 PM, Laurent Gautier wrote: > > > > Le lun. 9 d?c. 2019 ? 05:43, Tomas Kalibera <tomas.kalibera at gmail.com> a > ?crit : > >> On 12/7/19 10:32 PM, Laurent Gautier wrote: >> >> Thanks for the quick response Tomas. >> >> The same error

Thanks for the quick response Tomas. The same error is indeed happening when trying to have a zero-length variable name in an environment. The surprising bit is then "why is this happening during parsing" (that is why are variables assigned to an environment) ? We are otherwise aware that the error is not occurring in the R console, but can be traced to a call to R_ParseVector() in

Le lun. 9 d?c. 2019 ? 05:43, Tomas Kalibera <tomas.kalibera at gmail.com> a ?crit : > On 12/7/19 10:32 PM, Laurent Gautier wrote: > > Thanks for the quick response Tomas. > > The same error is indeed happening when trying to have a zero-length > variable name in an environment. The surprising bit is then "why is this > happening during parsing" (that is why

On 12/7/19 10:32 PM, Laurent Gautier wrote: > Thanks for the quick response Tomas. > > The same error is indeed happening when trying to have a zero-length > variable name in an environment. The surprising bit is then "why is > this happening during parsing" (that is why are variables assigned to > an environment) ? The emitted R error (in the R console) is not a

Hi Mehdi, > For a generic error class it is not an option indeed, but I was looking at it in the context of LLVM internal use, so just like our RTTI is not an option for “generic RTTI” but fits our need, we could (not should) do the same with ErrorHandling. Definitely. If this was LLVM only there'd be a strong case for using the existing RTTI system. The reason for the new RTTI system is

Hi Mehdi, > Side question on the related work because I’m curious: did you look for similar generic scheme for error handling offered by other C++ libraries? Maybe the common scheme is to use C++ exceptions but since many folks disable them (hello Google ;-) ) there has been probably many other attempts to address this. I did look around, but not very hard. Among the people I asked, everyone

Hi Rafael, > What prevents you from using a diag handler in the jit server that > sends errors/warnings over the RPCChannel? What would you do with errors that can't reasonable be serialized when they reach the diagnostic handler? And what would you do with the serialized bytes on the client end? - Lang. Sent from my iPhone On Feb 10, 2016, at 10:31 AM, Rafael Espíndola

Hi Simon, Widespread errors would have caught my earlier as the way that code is using only one initialization of the embedded R, is used quite a bit, and is covered by quite a few unit tests. This is the only situation I am aware of in which an error occurs. What is a "correct context", or initial context, the code should from ? Searching for "context" in the R-exts manual

On 12/9/19 2:54 PM, Laurent Gautier wrote: > > > Le?lun. 9 d?c. 2019 ??05:43, Tomas Kalibera <tomas.kalibera at gmail.com > <mailto:tomas.kalibera at gmail.com>> a ?crit?: > > On 12/7/19 10:32 PM, Laurent Gautier wrote: >> Thanks for the quick response Tomas. >> >> The same error is indeed happening when trying to have a >>

Laurent, the main point here is that ParseVector() just like any other R API has to be called in a correct context since it can raise errors so the issue was that your C code has a bug of not setting R correctly (my guess would be your'e not creating the initial context necessary in embedded R). There are many different errors, your is just one of many that can occur - any R API call that

Hi Mehdi, > I’m not sure to understand this claim? You are supposed to be able to extend and subclass the type of diagnostics? (I remember doing it for an out-of-tree LLVM-based project). You can subclass diagnostics, but subclassing (on its own) only lets you change the behaviour of the diagnostic/error itself. What we need, and what this patch supplies, is a way to choose a particular