Nick Sabbe nick.sa...@ugent.be
on Tue, 15 Jan 2013 21:34:52 +0100 writes:
I have exactly the same issue with a pair of my packages
on R-Forge. I've already notified Stefan, but I mentioned
it wasn't urgent for me :)
It must have something to do with the R check using a
Hi,
the same error was happen to me as well. it doesn't have problem with mac
and windows but there is package dependencies with Linux platform. this is
something i don't get a solution yet. so what I've done is, I simply check
on win-builder for machine dependencies and on my local machine as
Hi,
I am trying to integrate my Java program with R using rJava package. I want
to execute the whole Java program from R. The main() method in my Java code
calls all the other defined methods. So, I guess I have to call the main()
method in .jcall.
An example Java code:
*class A {
Hi,
1. I suggest adding the following piece of advice at the end of the section
describing R_getEmbeddingDllInfo() (currently 8.1.3) in R-exts.texi:
---
In order to call registered symbols of the embedding application from a
package, you have to specify @code{PACKAGE = (embedding)} in
Dear List,
I'm having considerable trouble setting up my environment (Linux, Fedora
16, Bash) to build and check packages under R Under Development
(r61660). I'm doing this to better get a handle on difference in the
output from running checks on examples in one of my packages. Note I
compiled R
On Jan 16, 2013, at 7:32 AM, Gaurav Dasgupta wrote:
Hi,
I am trying to integrate my Java program with R using rJava package. I want
to execute the whole Java program from R. The main() method in my Java code
calls all the other defined methods. So, I guess I have to call the main()
method
As a follow-up, shortly after I clicked send I decided to do something
silly and rename my ~/.Renviron (which set R_LIBS too). Silly because
the Writing R Extensions (WRE) manual says that these startup files are
not read as R is invoked with --vanilla.
Once I renamed ~/.Renviron so it was not
A new function in my heplots package wants to use a non-exported utility
function in the car package,
df.terms, but this depends on other non-exported functions.
From the Writing R extensions manual, I thought I could do this via (in
my NAMESPACE)
importFrom(car, car:::df.terms,
On 13-01-16 11:25 AM, Michael Friendly wrote:
A new function in my heplots package wants to use a non-exported utility
function in the car package,
df.terms, but this depends on other non-exported functions.
From the Writing R extensions manual, I thought I could do this via (in
my NAMESPACE)
On 1/16/2013 11:40 AM, Duncan Murdoch wrote:
\S 1.6.1 of the manual says regarding importFrom():
Using |foo:::f| instead of |foo::f| allows access to unexported objects.
This is generally not recommended, as the semantics of unexported
objects may be changed by the package author in routine
On Wed, Jan 16, 2013 at 7:25 AM, Gavin Simpson gavin.simp...@ucl.ac.uk wrote:
As a follow-up, shortly after I clicked send I decided to do something
silly and rename my ~/.Renviron (which set R_LIBS too). Silly because
the Writing R Extensions (WRE) manual says that these startup files are
not
On Wed, Jan 16, 2013 at 8:59 AM, Henrik Bengtsson h...@biostat.ucsf.edu wrote:
On Wed, Jan 16, 2013 at 7:25 AM, Gavin Simpson gavin.simp...@ucl.ac.uk
wrote:
As a follow-up, shortly after I clicked send I decided to do something
silly and rename my ~/.Renviron (which set R_LIBS too). Silly
On 1/16/2013 11:40 AM, Duncan Murdoch wrote:
2. Is my only alternative to copy these functions to my package, also
unexported?
Using car:::df.terms explicitly is another option.
Another possibility is for the car maintainer (John Fox) to export
that function from car.
Hmm. It turns out
Dear Duncan and Michael,
My initial reaction is that I'd rather not export these functions from the car
package since the package already has many exported functions and the functions
in question perform low-level operations that won't be of interest to end
users. I recognize, however, the
On 1/16/2013 12:26 PM, John Fox wrote:
Dear Duncan and Michael,
My initial reaction is that I'd rather not export these functions from the car
package since the package already has many exported functions and the functions
in question perform low-level operations that won't be of interest to
Dear List,
Further to my earlier email, I note that, for me at least, R CMD check
is *not* reading R_LIBS from ~/.R/check.Renviron on R 2.15.2 patched
(r61228) and R Under Development (r61660). The only way I can get R CMD
check to look for packages in a user-supplied library is by explicitly
To circumvent this, I check using:
R --no-init-file CMD check foo_1.0.tar.gz
In devtools, we take considerable care to match the R you're running
with the R you're checking in, so we also set the following
environmental variables:
env - c(
LC_ALL = C,
R_LIBS = paste(.libPaths(),
On Wed, 2013-01-16 at 14:39 -0600, Hadley Wickham wrote:
To circumvent this, I check using:
R --no-init-file CMD check foo_1.0.tar.gz
In devtools, we take considerable care to match the R you're running
with the R you're checking in, so we also set the following
environmental variables:
18 matches
Mail list logo
