search for: myerror

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

...f("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]"); } } To run with R: I build gcc -shared -I/opt/R-202301/lib/R/include/ myError.cpp -o myError.so then in R: dyn.load("myError.so") .C("testAL") This writes c0, c1, d1 but not d0. If I comment line "error", I does write latest d0. How could I get all my objects destroy while sending en error message to R ? Regards, Antoine Lucas. [[alternat...

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 >

...w what is a failure of the handler and how is it handled? Sorry - that was a bad example to choose: That was actually showcasing failure, not success. Success looks like this: TypedError bar() { TypedError Err = foo; if (auto E2 = catchTypedErrors(std::move(Err), handleTypedError<MyError>([&](std::unique_ptr<MyError> M) { // Deal with 'M' somehow. return TypedError(); })) return E2; // Proceed with 'bar' if 'Err' is handled. } A key observation is that catchTypedErrors itself returns an error. It has to, because you...

...just the cost of constructing the pointee describing the error, plus the cost of handling the error (if that happens). The pointee must be a user-defined class that works with the typed-error RTTI system. We provide a utility class, TypedErrorInfo, to make it easy to construct such classes: class MyError : TypedErrorInfo<MyError> { ... }; User defined error classes must also implement a log method to render the error to a stream, however this can usually be done in a couple of lines. Since we expect the number of user-defined error classes to be small, this overhead should be minimal. For us...

...probably some error in how the external code is handling R >> errors (Fatal error: unable to initialize the JIT, stack smashing, etc) >> and possibly also how R is initialized before calling ParseVector. Probably >> you would get the same problem when running say "stop('myerror')". Please >> note R errors are implemented as long-jumps, so care has to be taken when >> calling into R, Writing R Extensions has more details (and section 8 >> specifically about embedding R). This is unlike parse (syntax) errors >> signaled via return value to P...

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

...e). There is probably some error in how the external code is handling R errors > (Fatal error: unable to initialize the JIT, stack smashing, etc) and > possibly also how R is initialized before calling ParseVector. Probably you > would get the same problem when running say "stop('myerror')". Please note > R errors are implemented as long-jumps, so care has to be taken when > calling into R, Writing R Extensions has more details (and section 8 > specifically about embedding R). This is unlike parse (syntax) errors > signaled via return value to ParseVector() &gt...

...ring parsing. There is probably some error in how the external code is handling R errors? (Fatal error: unable to initialize the JIT, stack smashing, etc) and possibly also how R is initialized before calling ParseVector. Probably you would get the same problem when running say "stop('myerror')". Please note R errors are implemented as long-jumps, so care has to be taken when calling into R, Writing R Extensions has more details (and section 8 specifically about embedding R). This is unlike parse (syntax) errors signaled via return value to ParseVector() Best, Tomas > &...

...is it handled? > > Sorry - that was a bad example to choose: That was actually showcasing > failure, not success. Success looks like this: > > TypedError bar() { > TypedError Err = foo; > if (auto E2 = > catchTypedErrors(std::move(Err), > handleTypedError<MyError>([&](std::unique_ptr<MyError> M) { > // Deal with 'M' somehow. > return TypedError(); > })) > return E2; > > // Proceed with 'bar' if 'Err' is handled. > } > > A key observation is that catchTypedErrors itse...

...ry - that was a bad example to choose: That was actually showcasing >> failure, not success. Success looks like this: >> >> TypedError bar() { >> TypedError Err = foo; >> if (auto E2 = >> catchTypedErrors(std::move(Err), >> handleTypedError<MyError>([&](std::unique_ptr<MyError> M) { >> // Deal with 'M' somehow. >> return TypedError(); >> })) >> return E2; >> >> // Proceed with 'bar' if 'Err' is handled. >> } >> >> A key obser...

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

...nal code is handling R > >>> errors (Fatal error: unable to initialize the JIT, stack smashing, > etc) > >>> and possibly also how R is initialized before calling ParseVector. > Probably > >>> you would get the same problem when running say "stop('myerror')". > Please > >>> note R errors are implemented as long-jumps, so care has to be taken > when > >>> calling into R, Writing R Extensions has more details (and section 8 > >>> specifically about embedding R). This is unlike parse (syntax) errors &g...

...some error in how the external code is handling > R errors? (Fatal error: unable to initialize the JIT, stack > smashing, etc) and possibly also how R is initialized before > calling ParseVector. Probably you would get the same problem when > running say "stop('myerror')". Please note R errors are > implemented as long-jumps, so care has to be taken when calling > into R, Writing R Extensions has more details (and section 8 > specifically about embedding R). This is unlike parse (syntax) > errors signaled via return value to P...

...me error in how the external code is handling R >>> errors (Fatal error: unable to initialize the JIT, stack smashing, etc) >>> and possibly also how R is initialized before calling ParseVector. Probably >>> you would get the same problem when running say "stop('myerror')". Please >>> note R errors are implemented as long-jumps, so care has to be taken when >>> calling into R, Writing R Extensions has more details (and section 8 >>> specifically about embedding R). This is unlike parse (syntax) errors >>> signaled via r...

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