similar to: top level condition handlers

Hello, (This is follow up from this thread: http://www.nabble.com/execution-time-of-.packages-td22304833.html but with a different focus) I am often confused by the result of the profiler, when a loop is involved. Consider these two scripts: script1: Rprof( ) x <- numeric( ) for( i in 1:10000){ x <- c( x, rnorm(10) ) } Rprof( NULL ) print( summaryRprof( ) ) script2:

Hello, I?m trying to leverage R_ToplevelExec to implement C level try/catch. The way it is implemented allows for running a function in a top level context. This context gets an empty handler stack, so either the function runs correctly or it jumps. When it jumps, it does not find a handler, so it jumps to the top level context. R does not allow me to call begin context and end context

Along with getting pqR to work on Windows, I've also been testing it in the context of embedded R, and in the process have found some problems with the examples given of embedded R use. One problem can be seen in R_ReplDLLinit, in src/main/main.c: void R_ReplDLLinit(void) { SETJMP(R_Toplevel.cjmpbuf); R_GlobalContext = R_ToplevelContext = R_SessionContext = &R_Toplevel;

Hello, When using R_tryEval (from JRI in my case), is there a way to setup error recovery strategy and more generally calling handlers. From my reading of context.c, R_tryEval calls R_ToplevelExec which creates a context like this: begincontext(&thiscontext, CTXT_TOPLEVEL, R_NilValue, R_GlobalEnv, R_BaseEnv, R_NilValue, R_NilValue); so I guess what I am trying to do is add

I am compiling the Embedding examples in the tests directory and get an undefined reference. I include the make output as well as grep'd output of nm on libR.so and compiler and arch information. Do I have an improperly built R shared library or is there a problem with the Embedding tests or something else I am not seeing? Thanks for any help! George ost at

Hi Emil, First, thanks for the response. As you mentioned, a lot of times tryCatch does the work, as you can return a value. However, sometimes it is useful to assign several variables when an error occurs. You could do it with <<-, but I prefer to reduce it's usage unless completely necessary. I guess that the attachment was missed in the moderation. Here it is the function:

Hi all, I'm working on a GUI frontend for R, and I'm looking for a good way to catch all warning- and error-output. The reason for this is mostly, that I would like to know, which sections of the output are "normal" output, warnings, and errors. This would allow for some nice features, such as highlighting warnings and errors in a different color, or popping up a message

This is probably best viewed in the context of other issue with displaying calls, such as issues arising from calls constructed in non-standard evaluation contexts. Might be good to move to a wishlist item in bugzilla. Best, luke On Sat, 13 Jul 2019, brodie gaslam via R-devel wrote: > When large calls cause errors R may stall for extended periods.? This > is particularly likely to happen

Better to add this to the wishlist item. This all needs to be looked at together, and nothing is likely to happen until after vacation/conference season. It will disappear from everyone's radar if it is just in R_devel. Best, luke On Sun, 14 Jul 2019, brodie gaslam wrote: > Luke, thanks for considering the issue.? I would like to > try to separate the problem into two parts, as I

When large calls cause errors R may stall for extended periods.? This is particularly likely to happen with `do.call`, as in this example with a 24 second stall: ??? x <- runif(1e7) ??? system.time(do.call(paste0, list(abs, x)))? # intentional error ??? ## Error in (function (..., collapse = NULL)? : ??? ##?? cannot coerce type 'builtin' to vector of type 'character' ??? ##

We also have a few other suggestions and wishes about backtrace storage and display on the one hand, and display of constructed calls on the other hand. Perhaps it would be better to open a different wishlist item for traceback() to keep the discussions focused? FWIW I think deparsing backtraces lazily is a great idea. Displaying 1 line per call by default in interactive sessions, while being

Luke, thanks for considering the issue.? I would like to try to separate the problem into two parts, as I _think_ your comments address primarily part 2 below: 1. How can we avoid significant and possibly crippling ?? stalls on error with these non-standard calls. 2. What is the best way to view these non-standard calls. I agree that issue 2. requires further thought and discussion under a

A non-text attachment was scrubbed... Name: not available Type: text Size: 1287 bytes Desc: not available Url : https://stat.ethz.ch/pipermail/r-help/attachments/19980406/39dc7891/attachment.pl

Hi everyone, When dealing with errors, sometimes I want to run a bunch of code when an error occurs. For now I usually use a structure such as: res <- tryCatch(expr, error = function(cond) cond) # or try(expr) if (inherits(res, ?error?)) # or inherits(res, ?try-error?) # a bunch of code I though it would be useful to have a function that does this naturally, so I came up with the attached

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: custom_errors-v0.1.zip Type: application/zip Size: 4247 bytes Desc: not available Url : http://wrath.rubyonrails.org/pipermail/rails/attachments/20060517/360db211/custom_errors-v0.1-0001.zip

Hi, I'm looking for a way to generate a "full stop" that will not be caught by signal handlers, cf. .Internal(.dfltStop(msg, call)). RATIONALE: In the R.oo package I have throw() which (leaving out some details) basically does what stop() does but appends a stack trace string to the error message that shows up at the R prompt. Example: bar <- function() throw("A foo

I'm confused by the page documenting tryCatch and friends. I think it describes 3 separate mechanisms: tryCatch (in which control returns to the invoking tryCatch), withCallHandlers (in which control goes up to the calling handler/s but then continues from the point at which signalCondition() was invoked), and withRestarts (I can't tell where control ends up). For tryCatch the docs say

Does signalCondition() only work within try-catch blocks? I expected: testSignal <- function() { error <- simpleError("An error!") signalCondition(error) } to do the same thing as testStop <- function() { error <- simpleError("An error!") stop(error) } but testSignal returns NULL without throwing an error. Have I misunderstood something?

The internal code does more or less signalCondition(e) ## allows for (another) handler cat("\n") ## cleans up console invokeRestart("abort") ## jump to 'abort' restart if not handled [for back compatibility it also runs the error option code if that is set, but that may go away eventually]. A version of your example: > { +

Hi, I would like to bring up and old suggestion [http://tolstoy.newcastle.edu.au/R/devel/06/03/4512.html] of adding an exit condition, so that for instance it is possible to silently exit from scripts and Rd examples similar to return() for functions, e.g. \examples{ require("foo") || exit("Example will not run without the 'foo' package.") ... } I know this can be