Re: [Rd] Is it possible to retrieve the last error? (not error *message*)
I wondered the same thing a few days ago.
https://stackoverflow.com/questions/36966036/how-to-get-the-last-error
The here's the solution from that discussion:
get_last_error <- function()
{
tr <- .traceback()
if(length(tr) == 0)
{
return(NULL)
}
tryCatch(eval(parse(text = tr[[1]])), error = identity)
}
Note that it uses .traceback() from R 3.3.0; you'll have to use
baseenv()$.Traceback with earlier version of R.
On 4 May 2016 at 22:41, Henrik Bengtsson wrote:
> 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 an
> use try()/tryCatch().
>
> Thanks,
>
> Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Regards,
Richie
Learning R
4dpiecharts.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R process killed when allocating too large matrix (Mac OS X)
On 05.05.2016 04:25, Marius Hofert wrote: Hi Simon, ... all interesting (but quite a bit above my head). I only read 'Linux' and want to throw in that this problem does not appear on Linux (it seems). I talked about this with Martin Maechler and he reported that the same example (on one of his machines; with NA_real_ instead of '0's in the matrix) gave: Error: cannot allocate vector of size 70.8 Gb Timing stopped at: 144.79 41.619 202.019 ... but no killer around... Well, with n=1. ;-) Actually this also happens under Linux and I had my R processes killed more than once (and much worse also other processes so that we had to reboot a server, essentially). That's why we use job scheduling on servers for R nowadays ... Best, Uwe Cheers, Marius __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R process killed when allocating too large matrix (Mac OS X)
On 05/05/2016 10:11, Uwe Ligges wrote: On 05.05.2016 04:25, Marius Hofert wrote: Hi Simon, ... all interesting (but quite a bit above my head). I only read 'Linux' and want to throw in that this problem does not appear on Linux (it seems). I talked about this with Martin Maechler and he reported that the same example (on one of his machines; with NA_real_ instead of '0's in the matrix) gave: Error: cannot allocate vector of size 70.8 Gb Timing stopped at: 144.79 41.619 202.019 ... but no killer around... Well, with n=1. ;-) Actually this also happens under Linux and I had my R processes killed more than once (and much worse also other processes so that we had to reboot a server, essentially). That's why we use job scheduling on servers for R nowadays ... Yes, Linux does not deal safely with running out of memory, although it is better than it was. In my experience, only commercial Unices do that gracefully. Have you tried setting a (virtual) memory limit on the process using the shell it is launched from? I have found that to be effective on most OSes, at least in protecting other processes from being killed. However, some things do reserve excessive amounts of VM that they do not use and so cannot be run under a sensible limit. -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Max OSX 3.3.0 and lzma
I have lzma installed (in /usr/local) but R-3.3.0 configure doesn't like something about it: checking for lzma_version_number in -llzma... yes checking lzma.h usability... no checking lzma.h presence... no checking for lzma.h... no configure: error: "liblzma library and headers are required" bash-3.2$ ls /usr/local/lib/*lzma* ls /usr/local/lib/*lzma* /usr/local/lib/liblzma.5.dylib/usr/local/lib/liblzma.a /usr/local/lib/liblzma.dylib bash-3.2$ ls /usr/local/include/*lzma* ls /usr/local/include/*lzma* /usr/local/include/lzma.h /usr/local/include/lzma: base.hblock.hcontainer.hfilter.hindex.h lzma12.hversion.h bcj.hcheck.hdelta.hhardware.h index_hash.h stream_flags.hvli.h I'm no configure wizard so would appreciate a hint. Thanks Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Max OSX 3.3.0 and lzma
On 05/05/2016 19:40, Mick Jordan wrote: I have lzma installed (in /usr/local) but R-3.3.0 configure doesn't like something about it: checking for lzma_version_number in -llzma... yes checking lzma.h usability... no checking lzma.h presence... no checking for lzma.h... no configure: error: "liblzma library and headers are required" bash-3.2$ ls /usr/local/lib/*lzma* ls /usr/local/lib/*lzma* /usr/local/lib/liblzma.5.dylib/usr/local/lib/liblzma.a /usr/local/lib/liblzma.dylib bash-3.2$ ls /usr/local/include/*lzma* ls /usr/local/include/*lzma* /usr/local/include/lzma.h /usr/local/include/lzma: base.hblock.hcontainer.hfilter.hindex.h lzma12.hversion.h bcj.hcheck.hdelta.hhardware.h index_hash.h stream_flags.hvli.h I'm no configure wizard so would appreciate a hint. Look at config.log. And please follow the posting guide and give at least the OS, preferably full details of your setup. It looks like this is OS X (so this is not the right list and did you get liblzma from r.reseach.att.com?), and I've just scrubbed an explanation I wrote about an Oracle OS called Solaris Thanks Mick Jordan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] In R for Windows RGui, plain text help files open up at bottom of help file
Hello, When using the R for Windows installer, I typically choose a customized startup and specify "Plain text" (rather than "HTML help") as my preferred help style. In R-3.3.0, R-3.2.5, and (IIRC) R-3.2.4 (but not R-3.2.3), the plain text help files that open up when using `help()` or `?` do so with the text 'scrolled' down all the way to the bottom. It's a minor inconvenience, but probably worth mentioning. In case it helps, here's my sessionInfo: R version 3.3.0 (2016-05-03) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 7 x64 (build 7601) Service Pack 1 locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_3.3.0 Cheers, Josh O'Brien __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Storage of byte code-compiled functions in sysdata.rda
I can't reproduce the more complex version. But the package on CRAN
fails in the same way on 3.2.3 and 3.3.0.
The problem is that your sysdata.rda includes a function that is
generating this error. If you do
f <- getFromNamespace(".RMXE", ns ="RobAStRDA")[["GEVFamily"]][["fun.N"]][[1]]
g <- get("fct", environment(f))
and look at the byte code for g with compiler::disassemble or the
utility I'll paste in below you get
getbc(g)
list(8L, BCMISMATCH.OP)
The only way you can get a file like this is to byte compile and save
in a version of R with a newer byte code version (the 8L) and then
load and resave in an older version of R. If you load and run this
code in an older (or newer) version of R it will revert to the
standard interpeter using eval but will issue a warning once per
session. If you try to run it in an R with byte code version 8L you
get this error.
I can make a small change to that this becomes a once-per-session
warning, but even then you won't actually be running compiled code.
So I think your task is to figure out how you are ended up with a
sysdata.rda file created in this incompatible way. Something to look
for might be whether a call from within your R-devel somehow manages
to run an R process with an older R version.
Let me know what you find out.
luke
Here is the little utility, adapted from compiler::disassemble:
getbc <- function (code)
{
.CodeSym <- as.name(".Code")
disasm.const <- function(x) if (typeof(x) == "list" && length(x) >
0 && identical(x[[1]], .CodeSym))
disasm(x)
else x
disasm <- function(code) {
code[[2]] <- compiler:::bcDecode(code[[2]])
code[[3]] <- lapply(code[[3]], disasm.const)
code
}
if (typeof(code) == "closure") {
code <- .Internal(bodyCode(code))
if (typeof(code) != "bytecode")
stop("function is not compiled")
}
invisible(dput(disasm(.Internal(disassemble(code)))[[2]]))
}
On Sun, 1 May 2016, Peter Ruckdeschel wrote:
Thanks, Luke, for having a look to it.
Sure, I can give you some reproducible example -- even in two degrees of
completeness ;-): see below.
Thanks again, Peter
%---
(I) first example
%---
Just to reproduce the error, on r-devel, try:
install.packages("RobAStRDA")
require(RobAStRDA)
getFromNamespace(".RMXE", ns = "RobAStRDA")[["GEVFamily"]][["fun.N"]][[1]](1.3)
%---
(II) an example also giving the context
%---
For the "complete" story, not only the R-code needs to be given, but also the
preparation steps to produce the packages on the right R version;
so please follow steps (1)--(6) below; I am not 100% sure whether this already
gives
you all information needed for this, but if not so please let me know.
(1) create a minimal R-package "InterpolTry"
with byte-compilation on in the DESCRIPTION file
and with stats::approxfun imported in the NAMESPACE file
(2) in an R session on R-devel do
require(InterpolTry)
x <- 1:100
y <- 1:100
fun <- approxfun(x,y)
## revise the next line accordingly to your local settings
SrcRPathInterpolTry <-
RdaFile <- file.path(SrcRPathInterpolTry, "sysdata.rda")
save(fun, file = RdaFile)
tools::resaveRdaFiles(RdaFile)
(3) re-build package InterpolTry and re-install it
(4) create a minimal R package "UseInterpolTry", again
with byte-compilation on in the DESCRIPTION file
and with stats::approxfun and package "InterpolTry"
imported in the NAMESPACE file
(5) in the R folder of R package "UseInterpolTry" write a function
useInterpolFct() which goes like this
useInterpolFct <- function(x){
fun <- getFromNamespace("fun", ns = "InterpolTry")
fun(x)
}
export this function in the namespace and create an .Rd file to it
(6) (re-)build package "UseInterpolTry" and (re-)install it and try
require(UseInterpolTry)
useInterpolFct(5)
Steps (1)--(6) work with R-3.1.3, but no longer with R-devel.
Am 01.05.2016 um 14:12 schrieb Tierney, Luke:
Can you provide a complete reproducible example?
Sent from my iPhone
On May 1, 2016, at 6:51 AM, Peter Ruckdeschel wrote:
Hi r-devels,
we are seeing a new problem with our packages RobAStRDA (just new on CRAN,
thanks
to Uwe and Kurt!) and RobExtremes (to be submitted).
It must be something recent with the way you internally treat/store byte-code
compiled
functions, as we have no problems with R-3.1.3, but do see an "Error in fct(x)
: byte code
version mismatch" with R-devel SVNrev r70532.
Background:
Starting from several x-y grids, in the sysdata.rda file of RobAStRDA, we store
the results
of calls to approxfun/splinefun to these grids from within a session with pkg
RobAStRDA
require()d. From pkg RobExtremes we then call these interpolating functions by
means of
a call (essentially) as:
getFromNamespace(".RMXE", ns = "RobAStRDA")[["GEVFamily"]][["fun.N"]][[1
[Rd] ctrl-R in Rgui
When in the Rgui editor sometimes ctrl-R does not cause anything to be sent to the R console. It can be reproduced like this: - when in the Rgui console press ctrl-F N to get a new editor window - enter: pi + 3 followed by Enter - while still in the editor window press ctrl-A ctrl-R and pi + 3 gets entered into the console and runs as expected - while still in the editor window press ctrl-A ctrl-R again In the last case nothing happens whereas one would have expected it to be entered into the console again and run again. I am using [1] "R version 3.3.0 Patched (2016-05-03 r70575)" -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is it possible to retrieve the last error? (not error *message*)
Thanks.
As mentioned in that Stackoverflow thread, this requires re-evaluation
of the problematic code, which may or may not work (in addition to
taking time).
The closest I get to a solution, but which also requires being
proactive, is to use options(error=...) to record the condition
signaled by stop(). However, contrary to try()/tryCatch(), this is an
option that can be on all the time. It can be automatically enabled
by setting it in for instance .Rprofile.
## This can be placed in .Rprofile
local({
recordStop <- function(...) {
## Find the stop() frame
frames <- sys.frames()
args <- names(formals(base::stop))
isStop <- lapply(frames, FUN=function(f) all(args %in% names(f)))
idx <- which(unlist(isStop))[1]
frame <- frames[[idx]]
## Was stop() called with a condition or a message?
vars <- names(frame)
if ("cond" %in% vars) {
.Last.error <- frame$cond
} else {
msg <- eval(quote(.makeMessage(..., domain=domain)), envir=frame)
call <- if (frame$call.) sys.calls()[[1]] else NULL
.Last.error <- simpleError(msg, call=call)
}
assign(".Last.error", .Last.error, envir=.GlobalEnv)
} ## recordStop()
options(error=recordStop)
})
Then it can be used as:
## Requires options(error=recordStop)
## stop() at the prompt
stop("Hello")
## Error: Hello
print(.Last.error)
##
str(.Last.error)
# List of 3
# $ message: chr "woops"
# $ call : NULL
# $ value : num 2
# - attr(*, "class")= chr [1:4] "MyError" "simpleError" "error" "condition"
## stop() in a function
foo <- function() stop("woops")
ex <- tryCatch(foo(), error = function(ex) ex)
print(ex)
##
foo()
## Error in foo() : woops
print(.Last.error)
##
## Assert identical results
stopifnot(all.equal(.Last.error, ex))
## stop() in a nested call
bar <- function() foo()
ex <- tryCatch(bar(), error = function(ex) ex)
#
bar()
# Error in foo() : woops
print(.Last.error)
#
## Assert identical results
stopifnot(all.equal(.Last.error, ex))
## A custom error class
MyError <- function(..., value=0) {
ex <- simpleError(...)
ex$value <- value
class(ex) <- c("MyError", class(ex))
ex
}
## stop() from prompt
err <- MyError("woops", value=1L)
ex <- tryCatch(stop(err), error = function(ex) ex)
print(ex)
#
stop(err)
## Error: woops
print(.Last.error)
#
## Assert identical results
stopifnot(all.equal(.Last.error, ex))
## stop() in a function
yo <- function(value=1) stop(MyError("woops", value=value))
ex <- tryCatch(yo(), error = function(ex) ex)
print(ex)
#
yo()
# Error: woops
print(.Last.error)
#
## Assert identical results
stopifnot(all.equal(.Last.error, ex))
## stop() in a nested call
yeah <- function(value=2) yo(value=value)
ex <- tryCatch(yeah(), error = function(ex) ex)
print(ex)
#
yeah()
# Error: woops
print(.Last.error)
#
stopifnot(all.equal(.Last.error, ex))
str(.Last.error)
# List of 3
# $ message: chr "woops"
# $ call : NULL
# $ value : num 2
# - attr(*, "class")= chr [1:4] "MyError" "simpleError" "error" "condition"
/Henrik
On Wed, May 4, 2016 at 11:59 PM, Richard Cotton wrote:
> I wondered the same thing a few days ago.
>
> https://stackoverflow.com/questions/36966036/how-to-get-the-last-error
>
> The here's the solution from that discussion:
>
> get_last_error <- function()
> {
> tr <- .traceback()
> if(length(tr) == 0)
> {
> return(NULL)
> }
> tryCatch(eval(parse(text = tr[[1]])), error = identity)
> }
>
> Note that it uses .traceback() from R 3.3.0; you'll have to use
> baseenv()$.Traceback with earlier version of R.
>
> On 4 May 2016 at 22:41, Henrik Bengtsson wrote:
>> 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 an
>> use try()/tryCatch().
>>
>> Thanks,
>>
>> Henrik
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Regards,
> Richie
>
> Learning R
> 4dpiecharts.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
