Re: [Bioc-devel] error from biocLite on OSX with R-devel / Bioc-devel

[Levi Waldron]

On Wed, Feb 1, 2017 at 12:51 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> Levi triggered the problem with install.packages("lazyeval",
> repos=biocinstallRepos(), which is an R-only command. Also, there have not
> been any changes to the logic of biocLite() in this regard, so the problem
> is likely to be in R (devel) per se. I'll try to get access to a Mac and
> investigate.


Yes, in fact, now I notice that it also happens with just
install.packages("lazyeval"), on the second invocation with the same repo
argument (although exiting and starting R again creates a new tmp directory
so gives another free invocation. Sorry for blaming it on biocLite().

-- 
Levi Waldron
http://www.waldronlab.org
Assistant Professor of Biostatistics CUNY School of Public Health
US: +1 646-364-9616   Skype:
levi.waldron

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] error from biocLite on OSX with R-devel / Bioc-devel

[Martin Morgan]

On 01/31/2017 11:41 AM, Vincent Carey wrote:



On Mon, Jan 30, 2017 at 11:14 PM, Martin Morgan
>
wrote:

On 01/30/2017 09:52 AM, Levi Waldron wrote:

On Mon, Jan 30, 2017 at 12:23 AM, Martin Morgan
> wrote:

It seems like this is a local cache of the rstudio file that
describes the
mac repository. Maybe your vanilla execution of
install.packages() does not
use the repository that BiocInstaller does. So maybe

install.packages("lazyeval", repos=biocinstallRepos())

fails (maybe if repeated a second time)?


Yes, you're right, it fails.


so it seems like you can make this fail with pure R commands,
repos="https://cran.r-project.org " or
maybe a vector of two repositories?

artin

This would sound like an RStudio
problem. Is a work-around possible with

  options(repos=c(CRAN="https://cran.r-project.org
"))
  biocinstallRepos()   # should pick up new
repository
  biocLite("lazyeval")


This works for one install, then subsequently produces the same
error:

Browse[1]> file

[1]

"/var/folders/6n/cj15_ryn3ls0jtvfhtxztq08gn/T//RtmpYdXlSZ/repos_https%3A%2F%2Fcran.r-project.org

%2Fbin%2Fmacosx%2Fmavericks%2Fcontrib%2F3.4.rds"


we triggered the problem on a new Rstudio under Sierra ... the offending
RDS file from cran.rstudio.org  is still present.

we wanted to install ldblock in the devel branch, and succeeded with

install.packages("ldblock", repos="https://bioconductor.org/3.5/bioc;)

and this succeeded repetitively

there is something wrong with the process in biocLite that creates the file

/var/folders/6n/cj15_ryn3ls0jtvfhtxztq08gn/T//Rtmpvc0v9g/repos_https%3A%2F%2Fcran.rstudio.com
%2Fbin%2Fmacosx%2Fmavericks%2Fcontrib%2F3.4.rds

can't track any further at this time


Levi triggered the problem with install.packages("lazyeval", 
repos=biocinstallRepos(), which is an R-only command. Also, there have 
not been any changes to the logic of biocLite() in this regard, so the 
problem is likely to be in R (devel) per se. I'll try to get access to a 
Mac and investigate.


Martin






This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org  mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel






This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Unexpected EOF in R-patched_2017-01-30

[Avraham Adler]

On Tue, Jan 31, 2017 at 3:30 PM, peter dalgaard  wrote:
>
>> On 31 Jan 2017, at 18:56 , Avraham Adler  wrote:
>>
>> Hello.
>>
>> When trying to unpack today's version of R-patched,
>
> From which source? The files from cran.r-project.org seems OK, both those in 
> src/base-prerelease and those from ETHZ. Also, is it not "tar -xfz" when 
> reading a compressed file?
>
> -pd

>From 

Also, while passing z is not in the instructions given in Installation
and Administration [1], I tried passing -xzf and it did not work. I
believe f has to be last if the file name follows immediately.

[1]  


Thanks,

Avi

>> I get the following error:
>>
>> C:\R>tar -xf R-patched_2017-01-30.tar.gz
>>
>> gzip: stdin: unexpected end of file
>> tar: Unexpected EOF in archive
>> tar: Unexpected EOF in archive
>> tar: Error is not recoverable: exiting now
>>
>> I got the same error for R-patched_2017-01-30.tar.gz but not for 
>> R-3.3.2.tar.gz.
>>
>> Thank you,
>>
>> Avi
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
>

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

Re: [Rd] Unexpected EOF in R-patched_2017-01-30

[peter dalgaard]

> On 31 Jan 2017, at 18:56 , Avraham Adler  wrote:
> 
> Hello.
> 
> When trying to unpack today's version of R-patched,

>From which source? The files from cran.r-project.org seems OK, both those in 
>src/base-prerelease and those from ETHZ. Also, is it not "tar -xfz" when 
>reading a compressed file?

-pd 

> I get the following error:
> 
> C:\R>tar -xf R-patched_2017-01-30.tar.gz
> 
> gzip: stdin: unexpected end of file
> tar: Unexpected EOF in archive
> tar: Unexpected EOF in archive
> tar: Error is not recoverable: exiting now
> 
> I got the same error for R-patched_2017-01-30.tar.gz but not for 
> R-3.3.2.tar.gz.
> 
> Thank you,
> 
> Avi
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

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

[Rd] Unexpected EOF in R-patched_2017-01-30

[Avraham Adler]

Hello.

When trying to unpack today's version of R-patched, I get the following error:

C:\R>tar -xf R-patched_2017-01-30.tar.gz

gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

I got the same error for R-patched_2017-01-30.tar.gz but not for R-3.3.2.tar.gz.

Thank you,

Avi

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

Re: [Rd] rnbinom Returns Error that says optional argument is missing

[Joris Meys]

Hi Thomas,

This seems fully expected behaviour. Obviously unspecified arguments are
evaluated as missing regardless of a default value. So if you set mu as a
default, the function will call C_rnbinom with n, size and prob. As prob is
not specified you get the error one would expect. Specifying a default
value for prob also makes rnbinom call C_rnbinom, but in this case there is
a prob value so it works.

I don't know what you consider "unintentional", but everything works as
expected and imho as intended as well. Changing formals to a function comes
with no guarantees, and setting a default value for an argument that
previously had none, comes with the risk of breaking things (like you
noticed)

If you want to use a default value for mu, you have to change the body of
the function as well, eg:

> formals(rnbinom)[c('size','mu')] <- c(1,1)
> body(rnbinom) <- quote(.Call(C_rnbinom_mu, n, size, mu))
> rnbinom(10)
 [1] 0 4 2 0 3 0 4 0 0 2

That's really hacking away and something I would never suggest to people,
but it works.

Hope this explains
Cheers
Joris


On Tue, Jan 31, 2017 at 5:39 PM, Thomas Roh  wrote:

> I am trying to reset the default arguments in the rnbinom function with the
> following example code:
>
> params <- c("size" = 1, "mu" = 1)
> formals(rnbinom)[names(params)] <- params
> rnbinom(n = 10)
>
> It returns the following:
>
> Error in rnbinom(n = 10) : argument "prob" is missing, with no default
>
> If I set the defaults with this code:
>
> params <- c("size" = 1, "prob" = .5)
> formals(rnbinom)[names(params)] <- params
> rnbinom(n = 10)
>
> The function works correctly. The documentation specifies that you can set
> mu or prob with size. I understand that the problem lies in default
> arguments are evaluated as missing, but it seems unintentional that setting
> "prob" and "size" defaults will actually evaluate.
>
> Here is the function call:
>
> function (n, size, prob, mu)
>
> {
>
> if (!missing(mu)) {
>
> if (!missing(prob))
>
> stop("'prob' and 'mu' both specified")
>
> .Call(C_rnbinom_mu, n, size, mu)
>
> }
>
> else .Call(C_rnbinom, n, size, prob)
>
> }
>
>
>
>
>
> --
> Thomas Roh
> thms...@gmail.com
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Joris Meys
Statistical consultant

Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics

tel :  +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

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

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

[Martin Maechler]

> Suharto Anggono Suharto Anggono via R-devel 
> on Tue, 31 Jan 2017 15:43:53 + writes:

> Function 'aggregate.data.frame' in R has taken a different route. With 
drop=FALSE, the function is also applied to subset corresponding to combination 
of grouping variables that doesn't appear in the data (example 2 in 
https://stat.ethz.ch/pipermail/r-devel/2017-January/073678.html).

Interesting point (I couldn't easily find 'the example 2' though).
However, aggregate.data.frame() is a considerably more
sophisticated function and one goal was to change tapply() as
little as possible for compatibility (and maintenance!) reasons .

> Because 'default' is used only when simplification happens, putting 'default' 
> after 'simplify' in the argument list may be more logical. 

Yes, from this point of view, you are right; I had thought about
that too; on the other hand, it belongs "closely" to the 'FUN'
and I think that's why I had decided not to change the proposal..

> Anyway, it doesn't affect call to 'tapply' because the argument 'default' 
> must be specified by name.

Exactly.. so we keep the order as is.

> With the code using
>if(missing(default)) ,
> I consider the stated default value of 'default',
>default = NA ,
> misleading because the code doesn't use it. 

I know and I also had thought about it and decided to keep it 
in the spirit of "self documentation" because  "in spirit", the
default still *is* NA.

> Also,
>  tapply(1:3, 1:3, as.raw)
> is not the same as
>  tapply(1:3, 1:3, as.raw, default = NA) .
> The accurate statement is the code in
> if(missing(default)) ,
> but it involves the local variable 'ans'.

exactly.  But putting that whole expression in there would look
confusing to those using  str(tapply), args(tapply) or similar
inspection to quickly get a glimpse of the function user "interface".
That's why we typically don't do that and rather slightly cheat
with the formal default, for the above "didactical" purposes.

If you are puristic about this, then missing() should almost never
be used when the function argument has a formal default.

I don't have a too strong opinion here, and we do have quite a
few other cases, where the formal default argument is not always
used because of   if(missing(.))  clauses.

I think I could be convinced to drop the '= NA' from the formal
argument list..


> As far as I know, the result of function 'array' in is not a classed 
object and the default method of  `[<-` will be used in the 'tapply' code 
portion.

> As far as I know, the result of 'lapply' is a list without class. So, 
'unlist' applied to it uses the default method and the 'unlist' result is a 
vector or a factor.

You may be right here
  ((or not:  If a package author makes array() into an S3 generic and defines
S3method(array, *) and she or another make tapply() into a
generic with methods,  are we really sure that this code
would not be used ??))

still, the as.raw example did not easily work without a warning
when using as.vector() .. or similar.

> With the change, the result of

> tapply(1:3, 1:3, factor, levels=3:1)

> is of mode "character". The value is from the internal code, not from the 
factor levels. It is worse than before the change, where it is really the 
internal code, integer.

I agree that this change is not desirable.
One could argue that it was quite a "lucky coincidence" that the previous
code returned the internal integer codes though..


> In the documentation, the description of argument 'simplify' says: "If 
'TRUE' (the default), then if 'FUN' always returns a scalar, 'tapply' returns 
an array with the mode of the scalar."


> To initialize array, a zero-length vector can also be used.

yes, of course; but my  ans[0L][1L]  had the purpose to get the
correct mode specific version of NA .. which works for raw (by
getting '00' because "raw" has *no* NA!).

So it seems I need an additional   !is.factor(ans)  there ...
a bit ugly.


-

> For 'xtabs', I think that it is better if the result has storage mode 
> "integer" if 'sum' results are of storage mode "integer", as in R 3.3.2. 

you are right, that *is* preferable

>  As 'default' argument for 'tapply', 'xtabs' can use 0L, or use 0L or 0 
> depending on storage mode of the summed quantity.

indeed, that will be an improvement there!

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

Re: [Bioc-devel] error from biocLite on OSX with R-devel / Bioc-devel

[Vincent Carey]

On Mon, Jan 30, 2017 at 11:14 PM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:

> On 01/30/2017 09:52 AM, Levi Waldron wrote:
>
>> On Mon, Jan 30, 2017 at 12:23 AM, Martin Morgan
>>  wrote:
>>
>>> It seems like this is a local cache of the rstudio file that describes
>>> the
>>> mac repository. Maybe your vanilla execution of install.packages() does
>>> not
>>> use the repository that BiocInstaller does. So maybe
>>>
>>> install.packages("lazyeval", repos=biocinstallRepos())
>>>
>>> fails (maybe if repeated a second time)?
>>>
>>
>> Yes, you're right, it fails.
>>
>>
> so it seems like you can make this fail with pure R commands, repos="
> https://cran.r-project.org; or maybe a vector of two repositories?
>
> artin
>
> This would sound like an RStudio
>>> problem. Is a work-around possible with
>>>
>>>   options(repos=c(CRAN="https://cran.r-project.org;))
>>>   biocinstallRepos()   # should pick up new repository
>>>   biocLite("lazyeval")
>>>
>>
>> This works for one install, then subsequently produces the same error:
>>
>> Browse[1]> file
>>
>> [1] "/var/folders/6n/cj15_ryn3ls0jtvfhtxztq08gn/T//RtmpYdXlS
>> Z/repos_https%3A%2F%2Fcran.r-project.org%2Fbin%2Fmacosx%
>> 2Fmavericks%2Fcontrib%2F3.4.rds"
>>
>
we triggered the problem on a new Rstudio under Sierra ... the offending
RDS file from cran.rstudio.org is still present.

we wanted to install ldblock in the devel branch, and succeeded with

install.packages("ldblock", repos="https://bioconductor.org/3.5/bioc;)

and this succeeded repetitively

there is something wrong with the process in biocLite that creates the file

/var/folders/6n/cj15_ryn3ls0jtvfhtxztq08gn/T//Rtmpvc0v9g
/repos_https%3A%2F%2Fcran.rstudio.com 
%2Fbin%2Fmacosx%2Fmavericks%2Fcontrib%2F3.4.rds

can't track any further at this time


>
>
> This email message may contain legally privileged and/or...{{dropped:2}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

[Suharto Anggono Suharto Anggono via R-devel]

Function 'aggregate.data.frame' in R has taken a different route. With 
drop=FALSE, the function is also applied to subset corresponding to combination 
of grouping variables that doesn't appear in the data (example 2 in 
https://stat.ethz.ch/pipermail/r-devel/2017-January/073678.html).

Because 'default' is used only when simplification happens, putting 'default' 
after 'simplify' in the argument list may be more logical. Anyway, it doesn't 
affect call to 'tapply' because the argument 'default' must be specified by 
name.

With the code using
if(missing(default)) ,
I consider the stated default value of 'default',
default = NA ,
misleading because the code doesn't use it. Also,
tapply(1:3, 1:3, as.raw)
is not the same as
tapply(1:3, 1:3, as.raw, default = NA) .
The accurate statement is the code in
if(missing(default)) ,
but it involves the local variable 'ans'.

As far as I know, the result of function 'array' in is not a classed object and 
the default method of  `[<-` will be used in the 'tapply' code portion.

As far as I know, the result of 'lapply' is a list without class. So, 'unlist' 
applied to it uses the default method and the 'unlist' result is a vector or a 
factor.

With the change, the result of
tapply(1:3, 1:3, factor, levels=3:1)
is of mode "character". The value is from the internal code, not from the 
factor levels. It is worse than before the change, where it is really the 
internal code, integer.
In the documentation, the description of argument 'simplify' says: "If 'TRUE' 
(the default), then if 'FUN' always returns a scalar, 'tapply' returns an array 
with the mode of the scalar."

To initialize array, a zero-length vector can also be used.

For 'xtabs', I think that it is better if the result has storage mode "integer" 
if 'sum' results are of storage mode "integer", as in R 3.3.2. As 'default' 
argument for 'tapply', 'xtabs' can use 0L, or use 0L or 0 depending on storage 
mode of the summed quantity.


> Henrik Bengtsson 
> on Fri, 27 Jan 2017 09:46:15 -0800 writes:

> On Fri, Jan 27, 2017 at 12:34 AM, Martin Maechler
>  wrote:
>> 
>> > On Jan 26, 2017 07:50, "William Dunlap via R-devel"
>>  > wrote:
>> 
>> > It would be cool if the default for tapply's init.value
>> could be > FUN(X[0]), so it would be 0 for FUN=sum or
>> FUN=length, TRUE for > FUN=all, -Inf for FUN=max, etc.
>> But that would take time and would > break code for which
>> FUN did not work on length-0 objects.
>> 
>> > Bill Dunlap > TIBCO Software > wdunlap tibco.com
>> 
>> I had the same idea (after my first post), so I agree
>> that would be nice. One could argue it would take time
>> only if the user is too lazy to specify the value, and we
>> could use tryCatch(FUN(X[0]), error = NA) to safeguard
>> against those functions that fail for 0 length arg.
>> 
>> But I think the main reason for _not_ setting such a
>> default is back-compatibility.  In my proposal, the new
>> argument would not be any change by default and so all
>> current uses of tapply() would remain unchanged.
>> 
>>> Henrik Bengtsson  on
>>> Thu, 26 Jan 2017 07:57:08 -0800 writes:
>> 
>> > On a related note, the storage mode should try to match
>> ans[[1]] (or > unlist:ed and) when allocating 'ansmat' to
>> avoid coercion and hence a full > copy.
>> 
>> Yes, related indeed; and would fall "in line" with Bill's
>> idea.  OTOH, it could be implemented independently, by
>> something like
>> 
>> if(missing(init.value)) init.value <- if(length(ans))
>> as.vector(NA, mode=storage.mode(ans[[1]])) else NA

> I would probably do something like:

>   ans <- unlist(ans, recursive = FALSE, use.names = FALSE)
>   if (length(ans)) storage.mode(init.value) <- storage.mode(ans[[1]])
>   ansmat <- array(init.value, dim = extent, dimnames = namelist)

> instead.  That completely avoids having to use missing() and the value
> of 'init.value' will be coerced later if not done upfront.  use.names
> = FALSE speeds up unlist().

Thank you, Henrik.
That's a good idea to do the unlist() first, and with 'use.names=FALSE'.
I'll copy that.

On the other hand, "brutally" modifying  'init.value' (now called 'default')
even when the user has specified it is not acceptable I think.
You are right that it would be coerced anyway subsequently, but
the coercion will happen in whatever method of  `[<-` will be
appropriate.
Good S3 and S4 programmers will write such methods for their classes.

For that reason, I'm even more conservative now, only fiddle in
case of an atomic 'ans' and make use of the corresponding '['
method rather than as.vector(.) ... because that will fulfill
the following new regression test {not fulfilled in current R}:

identical(tapply(1:3, 1:3, as.raw),
  array(as.raw(1:3), 3L, dimnames=list(1:3)))

Also, I've done a few more things -- treating if(.) 

Re: [Bioc-devel] GenomeInfoDb::fetchExtendedChromInfoFromUCSC broken again?

[Martin Morgan]

See https://stat.ethz.ch/pipermail/bioc-devel/2017-January/010396.html

On 01/31/2017 07:57 AM, Christian Arnold wrote:


Hi,

it appears that in the newest devel version,
fetchExtendedChromInfoFromUCSC is broken (again). I found an earlier
post here:
https://www.mail-archive.com/bioc-devel@r-project.org/msg06193.html,
which however states that this has been fixed already in the previous
version 1.11.2 of the package:


library(GenomeInfoDb)

fetchExtendedChromInfoFromUCSC("mm9")


("mm9")

Error in file(file, "rt") : cannot open connection
In addition: Warning messages:
1: In FUN(genome = names(SUPPORTED_UCSC_GENOMES)[idx], circ_seqs =
supported_genome$circ_seqs,  :
  NCBI seqlevel was set to NA for mm9 UCSC seqlevel(s) not in the NCBI
assembly: chr1_random, chr3_random, chr4_random, chr5_random, chr7_random,
  chr8_random, chr9_random, chr13_random, chr16_random, chr17_random,
chrX_random, chrY_random, chrUn_random
2: In file(file, "rt") :
  URL
'https://ftp.ncbi.nlm.nih.gov/genomes/ASSEMBLY_REPORTS/All/GCF_01635.18.assembly.txt':
status was '404 Not Found'



sessionInfo()
R Under development (unstable) (2016-06-30 r70858)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.1 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C LC_TIME=de_DE.UTF-8
LC_COLLATE=en_US.UTF-8 LC_MONETARY=de_DE.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=de_DE.UTF-8   LC_NAME=C LC_ADDRESS=C
LC_TELEPHONE=C LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats4parallel  stats graphics  grDevices utils datasets
methods   base

other attached packages:
[1] GenomeInfoDb_1.11.6 IRanges_2.9.16  S4Vectors_0.13.11
BiocGenerics_0.21.3

loaded via a namespace (and not attached):
[1] tools_3.4.0

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] GenomeInfoDb::fetchExtendedChromInfoFromUCSC broken again?

[Christian Arnold]

Hi,

it appears that in the newest devel version, 
fetchExtendedChromInfoFromUCSC is broken (again). I found an earlier 
post here: 
https://www.mail-archive.com/bioc-devel@r-project.org/msg06193.html, 
which however states that this has been fixed already in the previous 
version 1.11.2 of the package:



library(GenomeInfoDb)

fetchExtendedChromInfoFromUCSC("mm9")

> ("mm9")
Error in file(file, "rt") : cannot open connection
In addition: Warning messages:
1: In FUN(genome = names(SUPPORTED_UCSC_GENOMES)[idx], circ_seqs = 
supported_genome$circ_seqs,  :
  NCBI seqlevel was set to NA for mm9 UCSC seqlevel(s) not in the NCBI 
assembly: chr1_random, chr3_random, chr4_random, chr5_random, chr7_random,
  chr8_random, chr9_random, chr13_random, chr16_random, chr17_random, 
chrX_random, chrY_random, chrUn_random

2: In file(file, "rt") :
  URL 
'https://ftp.ncbi.nlm.nih.gov/genomes/ASSEMBLY_REPORTS/All/GCF_01635.18.assembly.txt': 
status was '404 Not Found'




sessionInfo()
R Under development (unstable) (2016-06-30 r70858)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.1 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C LC_TIME=de_DE.UTF-8
LC_COLLATE=en_US.UTF-8 LC_MONETARY=de_DE.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=de_DE.UTF-8   LC_NAME=C LC_ADDRESS=C   
LC_TELEPHONE=C LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=C


attached base packages:
[1] stats4parallel  stats graphics  grDevices utils datasets  
methods   base


other attached packages:
[1] GenomeInfoDb_1.11.6 IRanges_2.9.16  S4Vectors_0.13.11 
BiocGenerics_0.21.3


loaded via a namespace (and not attached):
[1] tools_3.4.0

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] no visible global function definition for ‘par’

[Cathy Lee Gierke]

Thank you.  Makes sense.  It is *very* helpful to have R CMD check provide
that.

Cathy Lee Gierke


*“Darkness cannot drive out darkness: only light can do that. Hate cannot
drive out hate: only love can do that.” *
*“The arc of the moral universe is long, but it bends towards justice.”*
*“Nothing in the world is more dangerous than sincere ignorance and
conscientious stupidity.” *
*“Never forget that everything Hitler did in Germany was legal.”   *
*“Forgiveness is not an occasional act, it is a constant attitude.” *
*“Injustice anywhere is a threat to justice everywhere.”  *

― Martin Luther King Jr.



On Tue, Jan 31, 2017 at 2:17 AM, Martin Maechler  wrote:

> > Dirk Eddelbuettel 
> > on Mon, 30 Jan 2017 20:50:19 -0600 writes:
>
> > On 30 January 2017 at 09:58, Kevin Ushey wrote:
> > | The correct thing to do is indeed import any functions from any R
> packages
> > | you use, base or otherwise. The simplest fix, if you don't want to
> > | selectively import such a large range of functions, is to simply
> add e.g.
> > |
> > | import(utils)
> > | import(stats)
> > | ... etc ...
> > |
> > | to your NAMESPACE file.
>
> > Or do what R CMD check suggested and import the ones used, rather
> than all.
>
> > Which is what I had quoted earlier:
>
> > | Consider adding
> > |
> > |   importFrom("grDevices", "as.raster", "dev.cur", "dev.off",
> "gray",
> > |  "heat.colors", "jpeg", "palette", "pdf", "png",
> "rainbow",
> > |  "terrain.colors", "tiff")
> > |   importFrom("graphics", "abline", "axis", "barplot", "box",
> "boxplot",
> > |  "image", "layout", "legend", "lines", "mtext", "par",
> > |  "plot", "plot.new", "points", "rasterImage",
> "strwidth",
> > |  "text", "title")
> > |   importFrom("stats", "TukeyHSD", "acf", "aov", "ccf",
> "coefficients",
> > |  "drop1", "end", "fft", "median", "model.tables",
> > |  "na.action", "na.omit", "pf", "ts", "var")
> > |   importFrom("utils", "read.table", "str", "tail", "write.table")
> > |
> > | to your NAMESPACE file.
>
> > I find this preferable and quite appreciate that R CMD check
> provides it.
> > Dirk
>
> yes, and that is not only Dirk :
>
> It *is* highly preferable and recommended, also in *the*
> reference manual ("Writing R Extensions", aka WRE) for reasons
> of
>   - efficiency,
>   - modularity and "self-documentation"
>   - much better control against accidental name clashes,
>
> There are very few exceptions where importing a whole namespace
> makes sense and the above base packages are typically never part
> of these exceptions.
>
> Martin Maechler
> ETH Zurich and R Core
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] no visible global function definition for ‘par’

[Martin Maechler]

> Dirk Eddelbuettel 
> on Mon, 30 Jan 2017 20:50:19 -0600 writes:

> On 30 January 2017 at 09:58, Kevin Ushey wrote:
> | The correct thing to do is indeed import any functions from any R 
packages
> | you use, base or otherwise. The simplest fix, if you don't want to
> | selectively import such a large range of functions, is to simply add 
e.g.
> | 
> | import(utils)
> | import(stats)
> | ... etc ...
> | 
> | to your NAMESPACE file.

> Or do what R CMD check suggested and import the ones used, rather than 
all.

> Which is what I had quoted earlier:

> | Consider adding
> | 
> |   importFrom("grDevices", "as.raster", "dev.cur", "dev.off", "gray",
> |  "heat.colors", "jpeg", "palette", "pdf", "png", "rainbow",
> |  "terrain.colors", "tiff")
> |   importFrom("graphics", "abline", "axis", "barplot", "box", "boxplot",
> |  "image", "layout", "legend", "lines", "mtext", "par",
> |  "plot", "plot.new", "points", "rasterImage", "strwidth",
> |  "text", "title")
> |   importFrom("stats", "TukeyHSD", "acf", "aov", "ccf", "coefficients",
> |  "drop1", "end", "fft", "median", "model.tables",
> |  "na.action", "na.omit", "pf", "ts", "var")
> |   importFrom("utils", "read.table", "str", "tail", "write.table")
> | 
> | to your NAMESPACE file.

> I find this preferable and quite appreciate that R CMD check provides it.
> Dirk

yes, and that is not only Dirk :

It *is* highly preferable and recommended, also in *the*
reference manual ("Writing R Extensions", aka WRE) for reasons
of
  - efficiency,
  - modularity and "self-documentation"
  - much better control against accidental name clashes,

There are very few exceptions where importing a whole namespace
makes sense and the above base packages are typically never part
of these exceptions.

Martin Maechler
ETH Zurich and R Core

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