[Rd] update.packages with ask = FALSE will sometimes ask about updates

[Richard Cotton]

Today while running update.packages(ask = FALSE), R stopped to ask me
a question:

  There are binary versions available but the source versions are later:
binary  source needs_compilation
KernSmooth 2.23-13 2.23-14  TRUE
mixture1.2 1.3  TRUE

Do you want to install from sources the packages which need compilation?
y/n:


update.packages calls install.packages which calls getDependencies,
which was where there question originated.

It seems to me that if I've set ask = FALSE, stopping to ask questions
is a bug.  There are a few possible interpretations of the best
behaviour though, so I thought I'd put it up for discussion here
before (maybe) submitting as a bug.

1. The existing behaviour is correct: the case of out-of-date binaries
causes a special situation, and R is right to ask.

2. ask = FALSE means I want all updates, so don't ask me any
questions, just install all possible updates.

3. ask = FALSE means that I don't want any interactivity, but
out-of-date binaries is a special case, so R should just fail to
update these packages, with an error message stating that they need to
be manually updated.

4. There should be an extra argument that decides between the some or
all of the behaviours described in 1, 2 and 3.

Which of these options is best?  (Or have I missed an option?)

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

Re: [Rd] update.packages with ask = FALSE will sometimes ask about updates

[Rainer M Krug]

Richard Cotton  writes:

> Today while running update.packages(ask = FALSE), R stopped to ask me
> a question:
>
>   There are binary versions available but the source versions are later:
> binary  source needs_compilation
> KernSmooth 2.23-13 2.23-14  TRUE
> mixture1.2 1.3  TRUE
>
> Do you want to install from sources the packages which need compilation?
> y/n:
>
>
> update.packages calls install.packages which calls getDependencies,
> which was where there question originated.
>
> It seems to me that if I've set ask = FALSE, stopping to ask questions
> is a bug.  There are a few possible interpretations of the best
> behaviour though, so I thought I'd put it up for discussion here
> before (maybe) submitting as a bug.
>
> 1. The existing behaviour is correct: the case of out-of-date binaries
> causes a special situation, and R is right to ask.
>
> 2. ask = FALSE means I want all updates, so don't ask me any
> questions, just install all possible updates.
>
> 3. ask = FALSE means that I don't want any interactivity, but
> out-of-date binaries is a special case, so R should just fail to
> update these packages, with an error message stating that they need to
> be manually updated.
>
> 4. There should be an extra argument that decides between the some or
> all of the behaviours described in 1, 2 and 3.
>
> Which of these options is best?  (Or have I missed an option?)

I am with R (and youre first option). If I ask for binaries, I want
binaries (because I can not install from source, because I want them
fast, because I have locally different compilers, ...). So to silently
try to install sources instead of binaries could be completely
wrong. Although unlikely, the same applies the other way round, when I
ask for source.

THe other possible option would be 4, but instead of failing (the
binaries might still be newer then the installed versions) to give a
warning - as it is not more: For the settings asked for, these are, the
newest versions are installed - but be warned that there are newer
versions from source.

Thinking about it now, option 4 with warning should be the way to go.

Cheers,

Rainer
>

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
__
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’

[Joshua Ulrich]

On Tue, Feb 10, 2015 at 5:10 AM, Xavier Robin  wrote:
> Oh, I completely missed that one.
> It's very neat as it seems to work both on Windows and Unix.
>
It works on both Windows and *nix because it combines functionality
from snow (Windows) and multicore (*nix).

> 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



-- 
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com

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

Re: [Rd] Proper way to define cbind, rbind for s4 classes in package

[Mario Annau]

sorry - I just got irritated by my different R-versions.
The behaviour I described in the previous mail was discovered using R
3.1.2 without bind_activation(TRUE). In r67773 all calls are delegated
to r/cbind.matrix and not r/cbind2.
As a workaround I have now implemented an S3 method for my S4 class
which correctly dispatches for both versions (3.1.2 and r67699+) - see
also the commit for the h5 package on github:
https://github.com/mannau/h5/commit/20daea37ade1a317458c8a1d03928f579e457f93.
Any better ideas are welcome.
br,
mario


Am 09/02/15 um 23:38 schrieb Michael Lawrence:
> Are you able to create a reproducible example, somehow?
> 
> Thanks,
> Michael
> 
> On Mon, Feb 9, 2015 at 2:28 PM, Mario Annau  > wrote:
> 
> Hi Michael,
> I've tested your change in r67699 (using r67773) and the function now
> correctly dispatches to r/cbind2 within the R-session without
> bind_activation(TRUE). However, running unit tests using R CMD check I
> figured out that the same function call delegates to r/cbind.matrix
> (function uses S4 class as first- and matrix as second argument). Is
> this a bug and/or how can I get function dispatch right (to r/cbind2)
> for my test cases?
> best,
> mario
> 
> 
> Am 02/02/15 um 12:32 schrieb Martin Maechler:
> >> Michael Lawrence  >
> >> on Sun, 1 Feb 2015 19:23:06 -0800 writes:
> >
> > > I've implemented the proposed changes in
> > > R-devel. Minimally tested, so please try it. It should
> > > delegate to r/cbind2 when there is at least one S4
> > > argument and S3 dispatch fails (so you'll probably want to
> > > add an S3 method for your class to introduce a conflict,
> > > otherwise it will dispatch to cbind.data.frame if one of
> > > the args is a data.frame). There may no longer be a need
> > > for cBind() and rBind().
> >
> > > Michael
> >
> > This sounds great!   Thank you very much, Michael!
> > :-) :-)
> >
> > ... but  :-(  experiments with the Matrix package (and R
> > devel with your change), show a remaining buglet with treating of
> dimnames :
> >
> >> M1 <- Matrix(m1 <- matrix(1:12, 3,4))
> >> cbind(m1, MM = -1)
> >MM
> >[1,] 1 4 7 10 -1
> >[2,] 2 5 8 11 -1
> >[3,] 3 6 9 12 -1
> >> cbind(M1, MM = -1)   ##  notice the "..."
> >3 x 5 Matrix of class "dgeMatrix"
> >...
> >[1,] 1 4 7 10  -1
> >[2,] 2 5 8 11  -1
> >[3,] 3 6 9 12  -1
> >> rbind(R1 = 10:11, m1)
> >   [,1] [,2] [,3] [,4]
> >R1   10   11   10   11
> >147   10
> >258   11
> >369   12
> >> rbind(R1 = 10:11, M1) ## --- notice the 'deparse.level'
> >4 x 4 Matrix of class "dgeMatrix"
> >[,1] [,2] [,3] [,4]
> >deparse.level   10   11   10   11
> >   147   10
> >   258   11
> >   369   12
> >>
> >
> > Also, it seems you are not observing the 'deparse.level'
> > argument at all:
> > Looking at the last three lines of the example in  ?cbind,
> >
> >  rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 0) # middle
> 2 rownames
> >  rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 1) # 3
> rownames (default)
> >  rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 2) # 4 rownames
> >
> > but using a Matrix matrix 'dd', we see that (row)names
> > construction needs to amended:
> >
> >   > (dd <- Matrix(rbind(c(0:1,0,0
> >   1 x 4 sparse Matrix of class "dgCMatrix"
> >
> >   [1,] . 1 . .
> >
> >   > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 0) # middle
> 2 rownames
> >   4 x 4 sparse Matrix of class "dgCMatrix"
> >
> >   deparse.level  1  2  3  4
> >   c  2  2  2  2
> >   a++   10 10 10 10
> >.  1  .  .
> >   > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 1) # 3
> rownames (default)
> >   4 x 4 sparse Matrix of class "dgCMatrix"
> >
> >   deparse.level  1  2  3  4
> >   c  2  2  2  2
> >   a++   10 10 10 10
> >.  1  .  .
> >   > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 2) # 4 rownames
> >   4 x 4 sparse Matrix of class "dgCMatrix"
> >
> >   deparse.level  1  2  3  4
> >   c  2  2  2  2
> >   a++   10 10 10 10
> >.  1  .  .
> >   >
> >
> >
> >
> > > On Mon, Jan 26, 2015 at 3:55 AM, Martin Maechler <
> > > maech...@lynne.stat.math.ethz.ch
> > wrote:
> >
>