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 r
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(formul
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 objec
*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();
CollectedHe
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 packa
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 getti
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?
>
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
