[Rd] rJava Java debugger API
Hi,
I use rJava and call Java code that uses JVMTI code like this
VM vm = VM.getVM();
Universe universe = vm.getUniverse();
CollectedHeap heap = universe.heap();
This code attaches to another JVM and to get its internals. This is legal
Java and it works. But when I use rJava to call this code, the call is
successfull and it throws an error. I believe there is Java native
Interface involved in the JVM and it seems to affect R. rJava is 0.9
> version
_
platform x86_64-apple-darwin10.8.0
arch x86_64
os darwin10.8.0
system x86_64, darwin10.8.0
status
major 3
minor 1.0
year 2014
month 04
day10
svn rev65387
language R
version.string R version 3.1.0 (2014-04-10)
nickname Spring Dance
Thanks,
Mohan
Error: C stack usage 140730070087404 is too close to the limit
Error: C stack usage 140730070156700 is too close to the limit
> Warning: stack imbalance in '.Call', 59 then -1
Warning: stack imbalance in '{', 56 then -4
*** caught bus error ***
address 0x100583fd8, cause 'non-existent physical address'
*** caught bus error ***
address 0x100583fd8, cause 'non-existent physical address'
>
Traceback:
1: run(timeoutMs)
2: service(timeout)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: run(10)
*** caught segfault ***
address 0x20057ea40, cause 'memory not mapped'
Traceback:
1: run(timeoutMs)
2: service(timeout)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
--
View this message in context:
http://r.789695.n4.nabble.com/rJava-Java-debugger-API-tp469.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] model.frame and parent environment
Duncan, You missed the point. (I sometimes write too tersely, so I take the blame.) Users are writing their own "myfun". I want model.frame to work for them, without forcing the user to learn environment trickery. The actual question from the user was a call to fit <- coxph(formula, data=nd) predict(fit, type='expected') Within the predict call it is model.frame that fails, in the same way that it does in my simplified example. Now within model.frame.coxph (and model.frame.lm) there is the line eval(fexpr, env, parent.frame()) where env = environment of the formula and fexpr is an unevaluated call to model.frame. My underneath question: why is the enclosure argment ignored in this particular case? Parent.frame includes "nd". I have to admit that I find the non-functional parts of scheme, which R inherited, continue to leave me with the emotional response of "why would you add such nastiness to a language"? This leaves me at a disadvantage, I suspect, when trying to trace these things out. I've not yet seen a situation where I would want a formula to reference non-local information. Aside: The horrible decision in S to have "data=" replace rather than augment the scope for variable matching caused a lot of grief when calling a model inside a function. The R paradym fixed that, for which I am grateful, but with serious consequences. Terry T. On 06/16/2014 06:26 PM, Duncan Murdoch wrote: On 16/06/2014, 6:09 PM, Therneau, Terry M., Ph.D. wrote: Copy/paste error in creating my message, should have been: myfun(y~x, test) The problem is still real. I believe you that there's a real problem, I just wasn't sure what it was. When I try your corrected code I get this: Error in is.data.frame(data) : object 'nd' not found which is presumably the problem you had. A simple fix is to add the line environment(formula) <- environment() at the start of myfun. This tells R functions to look in the local environment, where it will find nd. Duncan Murdoch On 06/16/2014 04:27 PM, Duncan Murdoch wrote: I think something went wrong in your example: myfun takes a formula as well as a dataframe, and you only passed the dataframe. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] model.frame question
Brian, So let me ask an r-core opinion. Should I change the default to model=TRUE? Survival is heavily used and there is something to be said for consistency within the central packages. Sometimes old habits die hard, and there is a "save memory" part of me that hates to save a large object that likely won't be used. Not nearly as relevant today as when I started my career. I agree that the biggest issue with model=FALSE is when someone asks for predictions from a saved fit, perhaps saved weeks ago, and the data has changed under our feet. I have a check in predict.coxph that the number of rows in the data hasn't changed, but there really is no defense. Aside: This would mean in theory that I could also change the default to y= FALSE. I discovered a few years ago that that won't fly, when I set the default for y to "not model"; why keep redundant copies? Several other packages that depend on survival failed. They assume fit$y is there, without checking. The iron chains of backwards compatability... >1. The key line, in both model.frame.coxph and model.frame.lm is > eval(fcall, env, parent.frame()) > >and it appear (at least to me) that the parent.frame() part of this is >effectively ignored when fcall is itself a reference to model.frame. >I'd like to understand this better. Way back (ca R 1.2.0) an advocate of lexical scoping changed model.frame.lm to refer to an environment not a data frame for 'env'. That pretty fundamental change means that your sort of example is not a recommended way to do this: you are mixing scoping models. This hasn't left me any wiser. Can you expand? As stated in another note the real issue was fit <- coxph(formula, data=nd) predict(fit, type="expected") within a user's function. They, not unreasonably, expected it to work without further trickery. It fails because the model.frame call within predict.coxph cannot find "nd". >2. The modeling functions coxph and survreg in the survival default to >model=FALSE, originally in mimicry of lm and glm; I don't know when R > changed the default to model=TRUE for lm and glm. One possible response I am not sure R ever did: model = TRUE was the default 16 years ago at the beginning of the CVS/SVN archive. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rJava Java debugger API
*Now* you tell us rJava is involved. Its lists are accessed via
http://www.rforge.net/rJava/
On 17/06/2014 07:43, rmohan wrote:
Hi,
I use rJava and call Java code that uses JVMTI code like this
VM vm = VM.getVM();
Universe universe = vm.getUniverse();
CollectedHeap heap = universe.heap();
This code attaches to another JVM and to get its internals. This is legal
Java and it works. But when I use rJava to call this code, the call is
successfull and it throws an error. I believe there is Java native
Interface involved in the JVM and it seems to affect R. rJava is 0.9
version
_
platform x86_64-apple-darwin10.8.0
arch x86_64
os darwin10.8.0
system x86_64, darwin10.8.0
status
major 3
minor 1.0
year 2014
month 04
day10
svn rev65387
language R
version.string R version 3.1.0 (2014-04-10)
nickname Spring Dance
Thanks,
Mohan
Error: C stack usage 140730070087404 is too close to the limit
Error: C stack usage 140730070156700 is too close to the limit
Warning: stack imbalance in '.Call', 59 then -1
Warning: stack imbalance in '{', 56 then -4
*** caught bus error ***
address 0x100583fd8, cause 'non-existent physical address'
*** caught bus error ***
address 0x100583fd8, cause 'non-existent physical address'
Traceback:
1: run(timeoutMs)
2: service(timeout)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: run(10)
*** caught segfault ***
address 0x20057ea40, cause 'memory not mapped'
Traceback:
1: run(timeoutMs)
2: service(timeout)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
--
View this message in context:
http://r.789695.n4.nabble.com/rJava-Java-debugger-API-tp469.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check warning with S3 method
I'm getting an R CMD check warning with a package (call it package A) that defines an S3 method but not the generic. The generic is defined in another package (package B). Package A imports the S3 generic from B. And there's one additional detail: the generic overrides a function in the stats package. I've created a minimal test package which reproduces the problem: https://github.com/wch/s3methodtest In this case: - the package imports dplyr, for the dplyr::filter S3 generic - the package defines a S3 method filter.test - it imports dplyr, which defines a filter S3 generic The warning doesn't occur when package dplyr is in Depends instead of Imports. It also doesn't occur if the method is for a generic that does not override an existing function like stats::filter. For example, if instead of filter.test, I define select.test (dplyr::select is also an S3 generic), then there's no warning. This warning seems incorrect. Is this a bug? I'm interested in submitting the package to CRAN soon, so any advice on what to do is appreciated. Thanks, -Winston __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning with S3 method
I forgot to add this - here's the warning: * checking S3 generic/method consistency ... WARNING Warning: declared S3 method 'filter.test' not found See section 'Generic functions and methods' of the 'Writing R Extensions' manual. On Tue, Jun 17, 2014 at 2:21 PM, Winston Chang wrote: > I'm getting an R CMD check warning with a package (call it package A) > that defines an S3 method but not the generic. The generic is defined > in another package (package B). Package A imports the S3 generic from > B. And there's one additional detail: the generic overrides a function > in the stats package. > > I've created a minimal test package which reproduces the problem: > https://github.com/wch/s3methodtest > > In this case: > - the package imports dplyr, for the dplyr::filter S3 generic > - the package defines a S3 method filter.test > - it imports dplyr, which defines a filter S3 generic > > The warning doesn't occur when package dplyr is in Depends instead of > Imports. It also doesn't occur if the method is for a generic that > does not override an existing function like stats::filter. For > example, if instead of filter.test, I define select.test > (dplyr::select is also an S3 generic), then there's no warning. > > This warning seems incorrect. Is this a bug? I'm interested in > submitting the package to CRAN soon, so any advice on what to do is > appreciated. > > Thanks, > -Winston __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] what is the current correct repos structure for mac osx binaries?
Please forgive another comment on this topic. The 'type' argument to tools::write_PACKAGES doesn't currently accept the 'mac.binary.mavericks' value. It seems like it should, to make it possible to pass the same 'type' argument to all of the package generation and manipulation functions? > tools::write_PACKAGES(type='mac.binary.mavericks') Error in match.arg(type) : 'arg' should be one of “source”, “mac.binary”, “win.binary” best, -skye On 06/16/2014 11:32 AM, Simon Urbanek wrote: On Jun 16, 2014, at 1:18 PM, Skye Bender-deMoll wrote: Dear R-devel, Apologies for the confusing typo in the reported paths my previous question, thanks to Simon for providing the answer that the default repository type on the mac is now "mac.binary.mavericks" not "mac.binary" as the docs for install.packages state. That is incorrect. The default varies by the distribution you use. For the "regular" binary based on 10.6+ it is "mac.binary". For the special Mavericks distribution it is "mac.binary.mavericks". __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] PATCH: Avoiding extra copies (NAMED bumped) with source(..., print.eval=FALSE) ...and with print.eval=TRUE?
OBJECTIVE:
To update source(..., print.eval=FALSE) to not use withVisible()
unless really needed. This avoids unnecessary increases of reference
counts/NAMED introduced by withVisible(), which in turn avoids
unnecessary memory allocations and garbage collection overhead. This
has an impact on all source():ed scripts, e.g. pre-allocation of large
matrices to save memory does *not always* help in such setups. It is
likely to also affect the evaluation of code chunks of various
vignette engines.
BACKGROUND:
If you run the following at the prompt, you get that the assignment of
the first element does *not* cause an extra copy of 'x':
> x <- 1:2
> tracemem(x)
[1] "<0x1c5a7b28>"
> x[1] <- 0L
> x
[1] 0 2
However, it you source() the same code (with print.eval=FALSE; the
default), you get:
> code <- "
x <- 1:2
tracemem(x)
x[1] <- 0L
"
> source(textConnection(code))
tracemem[0x10504e20 -> 0x10509cd0]: eval eval withVisible source
> x
[1] 0 2
Looking at how source() works, this is because it effectively does:
> invisible(withVisible(x <- 1:2))
> invisible(withVisible(tracemem(x)))
> invisible(withVisible(x[1] <- 0L))
tracemem[0x104b68a8 -> 0x104b6788]: withVisible
> x
[1] 0 2
WORKAROUND HACK:
I understand that wrapping up multiple expressions into one avoids this:
> code <- "{
x <- 1:2
tracemem(x)
x[1] <- 0L
}"
> source(textConnection(code))
which you in this case can narrow down to:
code <- "
{x <- 1:2; {}}
tracemem(x)
x[1] <- 0L
"
source(textConnection(code))
but that's not my point here. Instead, I believe R can handle this
better itself.
DISCUSSION / PATCH:
It's quite easy to patch base::source(..., print.eval=FALSE) to avoid
the extra copies, because source() uses withVisible() so that it:
(a) can show()/print() the value of each expression (when
print.eval=TRUE), as well as
(b) returning the value of the last expression evaluated.
Thus, with print.eval=FALSE, withVisible() is only needed for the very
last expression evaluated.
Here is a patch to source() that avoids calling withVisible() unless needed:
$ svn diff src/library/base/R/source.R
Index: src/library/base/R/source.R
===
--- src/library/base/R/source.R (revision 65900)
+++ src/library/base/R/source.R (working copy)
@@ -206,7 +206,10 @@
}
}
if (!tail) {
- yy <- withVisible(eval(ei, envir))
+if (print.eval || i == Ne+echo)
+yy <- withVisible(eval(ei, envir))
+else
+eval(ei, envir)
i.symbol <- mode(ei[[1L]]) == "name"
if (!i.symbol) {
## ei[[1L]] : the function "<-" or other
With this patch you get:
> source(textConnection(code), echo=TRUE, print.eval=FALSE)
> x <- 1:2
> tracemem(x)
> x[1] <- 0L
> source(textConnection(code), echo=TRUE, print.eval=TRUE)
> x <- 1:2
> tracemem(x)
[1] "<0x1c5675c0>"
> x[1] <- 0L
tracemem[0x1c5675c0 -> 0x1c564ad0]: eval eval withVisible source
FURTHER IMPROVEMENTS:
Looking at the internals of withVisible():
/* This is a special .Internal */
SEXP attribute_hidden do_withVisible(SEXP call, SEXP op, SEXP args, SEXP rho)
{
SEXP x, nm, ret;
checkArity(op, args);
x = CAR(args);
x = eval(x, rho);
PROTECT(x);
PROTECT(ret = allocVector(VECSXP, 2));
PROTECT(nm = allocVector(STRSXP, 2));
SET_STRING_ELT(nm, 0, mkChar("value"));
SET_STRING_ELT(nm, 1, mkChar("visible"));
SET_VECTOR_ELT(ret, 0, x);
SET_VECTOR_ELT(ret, 1, ScalarLogical(R_Visible));
setAttrib(ret, R_NamesSymbol, nm);
UNPROTECT(3);
return ret;
}
Not sure exactly where the reference count (NAMED is updated) is
bumped, but *if it is possible to evaluate the expression and inspect
if the value is "visible" or not before it happens*, then one could
imaging adding an option to withVisible() that tells it to only return
the value if the evaluated value is visible (otherwise NULL). That
way one could avoid extra copies in most cases also with
print.eval=TRUE, e.g.
> withVisible(x[1] <- 0L)
$value
[1] 0
$visible
[1] FALSE
In other words, whenever withVisible() returns visible=FALSE, the
return values is not used by source().
Comments?
/Henrik
> sessionInfo()
R Under development (unstable) (2014-06-12 r65926)
Platform: x86_64-w64-mingw32/x64 (64-bit)
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
