Re: [Rd] R CMD check: Uses the superseded package: ‘doSNOW’

[Martyn Plummer]

The CRAN package snow is superseded by the parallel package which is
distributed with R since version 2.14.0. Here are the release notes

 \item There is a new package \pkg{parallel}.

 It incorporates (slightly revised) copies of packages
 \CRANpkg{multicore} and \CRANpkg{snow} (excluding MPI, PVM and NWS
 clusters).  Code written to use the higher-level API functions in
 those packages should work unchanged (apart from changing any
 references to their namespaces to a reference to \pkg{parallel},
 and links explicitly to \CRANpkg{multicore} or \CRANpkg{snow} on help
 pages).

So you should replace your dependency on doSNOW with doParallel, which
is the equivalent foreach adapter for the parallel package.

Martyn

On Mon, 2015-02-09 at 23:08 +0100, Xavier Robin wrote:
> Dear list,
> 
> When I run an R CMD check --as-cran on my package (pROC) I get the
> following note:
> > Uses the superseded package: ‘doSNOW’
> The fact that it uses the doSNOW package is correct as I have the
> following example in an .Rd file:
> > #ifdef windows
> > if (require(doSNOW)) {
> > registerDoSNOW(cl <- makeCluster(2, type = "SOCK"))
> > ci(roc2, method="bootstrap", parallel=TRUE)
> > \dontrun{ci(roc2, method="bootstrap", parallel=TRUE)}
> > \dontshow{ci(roc2, method="bootstrap", parallel=TRUE, boot.n=20)}
> > stopCluster(cl)
> > }
> > #endif
> > #ifdef unix
> > if (require(doMC)) {
> > registerDoMC(2)
> > \dontrun{ci(roc2, method="bootstrap", parallel=TRUE)}
> > \dontshow{ci(roc2, method="bootstrap", parallel=TRUE, boot.n=20)}
> > }
> > #endif
> 
> The "superseded" part is more confusing to me, though. The doSNOW
> package seems to be still available on CRAN with no special notice,
> listed in the HighPerformanceComputing view likewise, and under active
> development (last change a couple of days ago on R-Forge). I could find
> no mention of what it has been superseded with. Surprisingly, Google was
> no help on this.
> 
> I could see the note is triggered in QC.R file of the tools package.
> However this finding is not much help and leaves me just as confused as
> before.
> 
> I recall spending quite some time to setup this example to run both
> under Windows and Unix. doSNOW was the only way I could get it to work
> there. doMC is apparently still available for Unix only. I couldn't get
> doRNG to work on either platforms.
> 
> So what is R CMD check noticing me about?
> Should I ignore the notice, or take an action? If so, which one?
> 
> Best wishes,
> Xavier
> 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check: Uses the superseded package: ‘doSNOW’

[Xavier Robin]

Oh, I completely missed that one.
It's very neat as it seems to work both on Windows and Unix.

Thanks!
Xavier


On 10/02/15 10:52, Martyn Plummer wrote:
> The CRAN package snow is superseded by the parallel package which is
> distributed with R since version 2.14.0. Here are the release notes
>
>  \item There is a new package \pkg{parallel}.
>
>  It incorporates (slightly revised) copies of packages
>  \CRANpkg{multicore} and \CRANpkg{snow} (excluding MPI, PVM and NWS
>  clusters).  Code written to use the higher-level API functions in
>  those packages should work unchanged (apart from changing any
>  references to their namespaces to a reference to \pkg{parallel},
>  and links explicitly to \CRANpkg{multicore} or \CRANpkg{snow} on help
>  pages).
>
> So you should replace your dependency on doSNOW with doParallel, which
> is the equivalent foreach adapter for the parallel package.
>
> Martyn
>
> On Mon, 2015-02-09 at 23:08 +0100, Xavier Robin wrote:
>> Dear list,
>>
>> When I run an R CMD check --as-cran on my package (pROC) I get the
>> following note:
>>> Uses the superseded package: ‘doSNOW’
>> The fact that it uses the doSNOW package is correct as I have the
>> following example in an .Rd file:
>>> #ifdef windows
>>> if (require(doSNOW)) {
>>> registerDoSNOW(cl <- makeCluster(2, type = "SOCK"))
>>> ci(roc2, method="bootstrap", parallel=TRUE)
>>> \dontrun{ci(roc2, method="bootstrap", parallel=TRUE)}
>>> \dontshow{ci(roc2, method="bootstrap", parallel=TRUE, boot.n=20)}
>>> stopCluster(cl)
>>> }
>>> #endif
>>> #ifdef unix
>>> if (require(doMC)) {
>>> registerDoMC(2)
>>> \dontrun{ci(roc2, method="bootstrap", parallel=TRUE)}
>>> \dontshow{ci(roc2, method="bootstrap", parallel=TRUE, boot.n=20)}
>>> }
>>> #endif
>> The "superseded" part is more confusing to me, though. The doSNOW
>> package seems to be still available on CRAN with no special notice,
>> listed in the HighPerformanceComputing view likewise, and under active
>> development (last change a couple of days ago on R-Forge). I could find
>> no mention of what it has been superseded with. Surprisingly, Google was
>> no help on this.
>>
>> I could see the note is triggered in QC.R file of the tools package.
>> However this finding is not much help and leaves me just as confused as
>> before.
>>
>> I recall spending quite some time to setup this example to run both
>> under Windows and Unix. doSNOW was the only way I could get it to work
>> there. doMC is apparently still available for Unix only. I couldn't get
>> doRNG to work on either platforms.
>>
>> So what is R CMD check noticing me about?
>> Should I ignore the notice, or take an action? If so, which one?
>>
>> Best wishes,
>> Xavier
>>


-- 
Xavier Robin, PhD
Cellular Signal Integration Group (C-SIG)  - Linding Lab
Biotech Research and Innovation Center (BRIC) - University of Copenhagen
Anker Engelundsvej, DTU Campus, Building 301, DK-2800 Lyngby, DENMARK
Mobile: +45 42 799 833
www.lindinglab.org - www.bric.ku.dk

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] How to deal with functions detected as apparent S3 methods

[Xavier Robin]

Dear list,

I am trying to clear the following note that is generated by an R CMD
check --as-cran on my package (pROC):
> * checking S3 generic/method consistency ... NOTE
> Found the following apparent S3 methods exported but not registered:
>   ci.auc ci.coords ci.se ci.sp ci.thresholds roc.test
> See section ‘Registering S3 methods’ in the ‘Writing R Extensions’
> manual.
However, these functions are (at least intended to be) actual functions,
not methods.
The reason these messages are generated is that I define two generic
functions ci and roc. Due to the S3 rules, these 6 functions are
accidentally recognized as methods of those generics. But it has never
been in my intention to do so.

I just fixed a bunch of these notes (see

for instance) that were pointing at actual errors, but these remaining 6
are definitely "correct", at least in the sense that registering them as
S3 method instead of exporting them would break quite some code
(including the doc and examples of the package).

(This is additionally made even more complex by the fact that 'ci.auc'
could actually be used as a method, although that usage is not
documented (it would then be a method that further delegate to other
methods). It is not the case of the other 5 functions.)

I guess the naming was a bit unfortunate... but it happened 5 years ago
and it is quite difficult to change now.

How can I fix this? I can see two ways to go here:

* Deprecate these functions and replace them with some underscore
version (ci_auc, etc.)
It might take some time for the usage to change but I'm sure I can
convince CRAN to accept the package if some transition action is taken...

* Just ignore the note: after all it is just an automated test, I never
had any issue with this, nor heard anyone complaining about this before.
I can't find anything specifically advising against this usage in the
docs, but maybe I just overlooked it?

Any advice on how to address this problem would be appreciated.

Best wishes,
Xavier

-- 
Xavier Robin, PhD
Cellular Signal Integration Group (C-SIG)  - Linding Lab
Biotech Research and Innovation Center (BRIC) - University of Copenhagen
Anker Engelundsvej, DTU Campus, Building 301, DK-2800 Lyngby, DENMARK
Mobile: +45 42 799 833
www.lindinglab.org - www.bric.ku.dk

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] WISH: eval() to preserve the "visibility" (now value is always visible)

[Henrik Bengtsson]

On Sun, Feb 8, 2015 at 8:44 PM, Suharto Anggono Suharto Anggono via
R-devel  wrote:
> Sorry to intervene.

No, I'm very happy you intervened.  You're comment is 100%
valid/correct making my wish moot.

Your explanation is very clear and nails it; one should use
eval(substitute(expr)) or evalq(expr) for what I'm trying to do.

It all came from me trying to prevent

> withOptions({x <- 1}, foo=1)

from printed the value, where (somewhat simplified):

withOptions <- function(expr, ..., envir=parent.frame()) {
  oopts <- options(...)
  on.exit(options(oopts))
  eval(expr, envir=envir)
}

I have a few of these withNnn() functions, but for this particular one
(*) I had forgotten an expr <- substitute(expr) in there, which caused
me to incorrectly blame eval().  This is very much
the same problem as you observed with my eval2() example.

Thank you very much

Henrik
(*) Actually withSeeds() which is to messy to use as an example.

>
> Argument passed to 'eval' is evaluated first.
> So,
> eval(x <- 2)
> is effectively like
> { x <- 2; eval(2) } ,
> which is effectively
> { x <- 2; 2 } .
> The result is visible.
>
> eval(expression(x <- 2))
> or
> eval(quote(x <- 2))
> or
> evalq(x <- 2)
> gives the same effect as
> x <- 2 .
> The result is invisible.
>
> In function 'eval2',
> res <- eval(withVisible(expr), envir=envir, ...)
> is effectively
> res <- withVisible(expr) .
>
> ---
>
> Would it be possible to have the value of eval() preserve the
> "visibility" of the value of the expression?
>
>
> "PROBLEM":
>
> # Invisible
>> x <- 1
>
> # Visible
>> eval(x <- 2)
> [1] 2
>
> "TROUBLESHOOTING":
>> withVisible(x <- 1)
> $value
> [1] 1
> $visible
> [1] FALSE
>
>> withVisible(eval(x <- 2))
> $value
> [1] 2
> $visible
> [1] TRUE
>
>
> WORKAROUND:
> eval2 <- function(expr, envir=parent.frame(), ...) {
>   res <- eval(withVisible(expr), envir=envir, ...)
>   value <- res$value
>   if (res$visible) value else invisible(value)
> }
>
>> x <- 1
>> eval(x <- 2)
> [1] 2
>> eval2(x <- 3)
>> x
> [1] 3
>
> /Henrik
>
> __
> 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

[Rd] CRAN check fails on Solaris, any hints why?

[Helske, Jouni]

Dear all,

I recently uploaded a new package Rlibeemd to CRAN 
(http://cran.r-project.org/web/packages/Rlibeemd/index.html, and in github: 
https://github.com/helske/Rlibeemd), and simple example in help files seems to 
throw an error on Solaris:

Version: 1.3.1
Check: examples
Result: ERROR
Running examples in �Rlibeemd-Ex.R� failed
The error most likely occurred in:

> ### Name: ceemdan
> ### Title: CEEMDAN decomposition
> ### Aliases: ceemdan
>
> ### ** Examples
>
> imfs <- ceemdan(UKgas, threads = 1)
gsl: tridiag.c:191: ERROR: matrix must be positive definite
Default GSL error handler invoked.

The package is structured in such way that the underlying C library uses GSL 
for performing complete ensemble empirical mode decomposition, and I have 
written Rcpp/R wrappers around those functions. In eemd.c there are lines

const int status = gsl_linalg_solve_tridiag(&diag_vec.vector,
&supdiag_vec.vector,
&subdiag_vec.vector,
&g_vec.vector,
&solution_vec.vector);
if (status) { // we never get to this point if above function fails!
REprintf("Error reported by gsl_linalg_solve_tridiag: %s\n",
gsl_strerror(status));
return EMD_GSL_ERROR;
}

So first I need to add gsl_set_error_handler_off() to some point of the code so 
the GSL does not abort R. But what I wonder is why does the error happen at 
all. The same example works fine wih Windows, Linux and OSX. After googling a 
bit I saw that there are other packages with problems related to Solaris and 
GSL (such as http://cran.r-project.org/web/checks/check_results_RcppGSL.html), 
so I wonder if the issue is related to incorrect Makevars and/or configure or 
something like that?

This is the first project where I needed configure script. This is my 
configure.ac which I copied from RcppGSL packages example:

AC_INIT([Rlibeemd], 1.3.0)
## Use gsl-config to find arguments for compiler and linker flags
##
## Check for non-standard programs: gsl-config(1)
AC_PATH_PROG([GSL_CONFIG], [gsl-config])
## If gsl-config was found, let's use it
if test "${GSL_CONFIG}" != ""; then
# Use gsl-config for header and linker arguments (without BLAS which we get 
from R)
GSL_CFLAGS=`${GSL_CONFIG} --cflags`
GSL_LIBS=`${GSL_CONFIG} --libs`
else
AC_MSG_ERROR([gsl-config not found, is GSL installed?])
fi
# Now substitute these variables in src/Makevars.in to create src/Makevars
AC_SUBST(GSL_CFLAGS)
AC_SUBST(GSL_LIBS)
AC_OUTPUT(src/Makevars)

And here is Makevars.in:

GSL_CFLAGS = @GSL_CFLAGS@
GSL_LIBS = @GSL_LIBS@
PKG_LIBS=$(GSL_LIBS) $(SHLIB_OPENMP_CFLAGS) $(SHLIB_OPENMP_CXXFLAGS)
PKG_CFLAGS=$(GSL_CFLAGS) $(SHLIB_OPENMP_CFLAGS)
PKG_CXXFLAGS=$(SHLIB_OPENMP_CXXFLAGS)

Any help would be greatly appreciated. I don't have access to Solaris which 
makes the debugging rather hard.

Best regards,

Jouni Helske


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel