Skip to content
Prev 51904 / 63421 Next

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
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: