date:20170731

Re: [Rd] force promises inside lapply

2017-07-31 Thread William Dunlap via R-devel

quote(expr) will make no changes in expr, it just returns its one argument,
unevaluated.
substitute could be used in your lapply(..., library) example to give
library a name instead
of a character string for an input (which might be necessary if the
character.only argument
were not available)
lapply(c("MASS", "splines"), function(pkg)
eval(substitute(library(pkg), list(pkg=as.name(pkg)
bquote() could be used as well
lapply(c("MASS", "splines"), function(pkg) eval(bquote(library(.(pkg)),
list(pkg=as.name(pkg)
But avoiding such things is much easier.


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Mon, Jul 31, 2017 at 2:41 PM, Benjamin Tyner  wrote:

> Thanks again Bill; I agree that substitute is overkill here.
>
> As an aside, for cases where someone may be tempted to use substitute(),
> it seems quote() might be a safer alternative; compare
>
>> lapply(list(1), function(y) c(quote(y), substitute(y)))
>[[1]]
>[[1]][[1]]
>y
>
>[[1]][[2]]
>X[[i]]
>
> versus in R < 3.2,
>
>> lapply(list(1), function(y) c(quote(y), substitute(y)))
>[[1]]
>[[1]][[1]]
>y
>
>[[1]][[2]]
>X[[1L]]
>
> in any case, the lesson seems to be that quote and substitute are not
> interchangeable, even though for example
>
>> (function() identical(quote({a}), substitute({a})))()
>[1] TRUE
>
>
> On 07/29/2017 09:39 AM, William Dunlap wrote:
>
>> Functions, like your loader(), that use substitute to let users confound
>> things and their names, should give the user a way to avoid the use of
>> substitute.  E.g., library() has the 'character.only' argument; if TRUE
>> then the package argument is treated as an ordinary argument and not passed
>> through substitute().
>>
>> myLoader <- function(package, quietly = TRUE) {
>>wrapper <- if (quietly) suppressPackageStartupMessages else `{`
>>wrapper(library(package = package, character.only=TRUE))
>>}
>>
>> > lapply(c("MASS","boot"), myLoader, quietly=FALSE)
>> [[1]]
>>  [1] "MASS"  "splines"   "pryr"  "stats" "graphics"  "grDevices"
>>  [7] "utils" "datasets"  "methods"   "base"
>>
>> [[2]]
>>  [1] "boot"  "MASS"  "splines"   "pryr"  "stats"
>>  "graphics"
>>  [7] "grDevices" "utils" "datasets"  "methods"   "base"
>>
>> "Non-standard" evaluation (using substitute(), formulas, promises, the
>> rlang or lazyeval packages, etc.) has it uses but I wouldn't use it for
>> such a function as your loader().
>>
>>
>> Bill Dunlap
>> TIBCO Software
>> wdunlap tibco.com 
>>
>>
>> On Fri, Jul 28, 2017 at 8:20 PM, Benjamin Tyner > > wrote:
>>
>> Thanks Bill. I think my confusion may have been in part due to my
>> conflating two distinct meanings of the term "evaluate"; the help
>> for force says it "forces the evaluation of a function argument"
>> whereas the help for eval says it "evaluates the ... argument ...
>> and returns the computed value". I found it helpful to compare:
>>
>>> lapply(list(a=1,b=2,c=3), function(x){ force(substitute(x)) })
>>$a
>>X[[i]]
>>
>>$b
>>X[[i]]
>>
>>$c
>>X[[i]]
>>
>> versus
>>
>>> lapply(list(a=1,b=2,c=3), function(x){ eval(substitute(x)) })
>>Error in eval(substitute(x)) : object 'X' not found
>>
>> Now for the context my question arose in: given a function
>>
>>loader <- function(package, quietly = TRUE) {
>>
>>wrapper <- if (quietly) suppressPackageStartupMessages else `{`
>>
>>expr <- substitute(wrapper(library(package = package)))
>>
>>eval(expr)
>>}
>>
>> prior to R version 3.2, one could do things like
>>
>> lapply(c("MASS", "boot"), loader)
>>
>> but not anymore (which is fine; I agree that one should not depend
>> on lapply's implementation details).
>>
>> Regards,
>> Ben
>>
>>
>> On 07/28/2017 06:53 PM, William Dunlap wrote:
>>
>> 1: substitute(), when given an argument to a function (which
>> will be a promise) gives you the unevaluated expression given
>> as the argument:
>>
>> >  L <- list(a=1, b=2, c=3)
>> > str(lapply(L, function(x) substitute(x)))
>> List of 3
>>  $ a: language X[[i]]
>>  $ b: language X[[i]]
>>  $ c: language X[[i]]
>>
>> The 'X' and 'i' are in a frame constructed by lapply and you
>> are not really supposed to depend on the precise form of those
>> expressions.
>>
>> 2: An evaluated promise is still a promise: it has the
>> 'evaled' field set to TRUE and the 'value' field set to the
>> result of evaluating 'code' in 'env'.
>>
>> > f <- function(x, force) {
>>  if (force) force(x)
>>  if (pryr::is_promise(x)) promise_info(x)
>>  else "not a promise"
>>  }
>> > str(f(log(-1), force=FALSE))
>>

[Rd] reproducible segmentation fault installing packages on FreeBSD 11.1

2017-07-31 Thread Joseph Mingrone

Hi,

This happens when attempting to install any package. There were no such
problems on 11.0.

Some other ways to trigger the problem:

curlGetHeaders("http://bugs.r-project.org;)
There are no problems with the first two calls, but then the crash
always happens on the third call.

tf <- tempfile()
download.file("http://cran.r-project.org/",tf,method="libcurl;)
This one is ok for the first five calls, but always crashes on the
sixth call.

download.file("http://cran.r-project.org/",tf,method="internal;)
does not trigger the issue.

Is there any further information I can provide or anything else I can
test?

Joseph

jrm@phe ~ % R --debugger=gdb
GNU gdb (GDB) 8.0 [GDB v8.0 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/lib/R/bin/exec/R...(no debugging symbols 
found)...done.
(gdb) r
Starting program: /usr/local/lib/R/bin/exec/R

R version 3.4.1 (2017-06-30) -- "Single Candle"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: amd64-portbld-freebsd11.1 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> install.packages("ggplot2")
Installing package into ‘/usr/home/jrm/.R/amd64-portbld-freebsd11.1-library/3.4’
(as ‘lib’ is unspecified)
--- Please select a CRAN mirror for use in this session ---
[New LWP 100239 of process 56011]
[LWP 100239 of process 56011 exited]

--- snip ---

Selection: 1
[New LWP 100265 of process 56011]
[LWP 100265 of process 56011 exited]
also installing the dependencies ‘stringi’, ‘magrittr’, ‘colorspace’, ‘Rcpp’, 
‘stringr’, ‘RColorBrewer’, ‘dichromat’, ‘munsell’, ‘labeling’, ‘rlang’, 
‘digest’, ‘gtable’, ‘plyr’, ‘reshape2’, ‘scales’, ‘tibble’, ‘lazyeval’

trying URL 'https://cloud.r-project.org/src/contrib/stringi_1.1.5.tar.gz'
[New LWP 100267 of process 56011]
[LWP 100267 of process 56011 exited]
Content type 'application/x-gzip' length 3645872 bytes (3.5 MB)
==
downloaded 3.5 MB

trying URL 'https://cloud.r-project.org/src/contrib/magrittr_1.5.tar.gz'
[New LWP 100844 of process 56011]
[LWP 100844 of process 56011 exited]
Content type 'application/x-gzip' length 200504 bytes (195 KB)
==
downloaded 195 KB

trying URL 'https://cloud.r-project.org/src/contrib/colorspace_1.3-2.tar.gz'
[New LWP 100161 of process 56011]
[LWP 100161 of process 56011 exited]
Content type 'application/x-gzip' length 293433 bytes (286 KB)
==
downloaded 286 KB

trying URL 'https://cloud.r-project.org/src/contrib/Rcpp_0.12.12.tar.gz'
[New LWP 100854 of process 56011]

Thread 7 received signal SIGSEGV, Segmentation fault.
[Switching to LWP 100854 of process 56011]
uw_frame_state_for (context=context@entry=0x7fffdfffde20, 
fs=fs@entry=0x7fffdfffdb70)
at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249
1249  return MD_FALLBACK_FRAME_STATE_FOR (context, fs);



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

Re: [Rd] force promises inside lapply

2017-07-31 Thread Benjamin Tyner

Thanks again Bill; I agree that substitute is overkill here.

As an aside, for cases where someone may be tempted to use substitute(), 
it seems quote() might be a safer alternative; compare

   > lapply(list(1), function(y) c(quote(y), substitute(y)))
   [[1]]
   [[1]][[1]]
   y

   [[1]][[2]]
   X[[i]]

versus in R < 3.2,

   > lapply(list(1), function(y) c(quote(y), substitute(y)))
   [[1]]
   [[1]][[1]]
   y

   [[1]][[2]]
   X[[1L]]

in any case, the lesson seems to be that quote and substitute are not 
interchangeable, even though for example

   > (function() identical(quote({a}), substitute({a})))()
   [1] TRUE

On 07/29/2017 09:39 AM, William Dunlap wrote:
Functions, like your loader(), that use substitute to let users 
confound things and their names, should give the user a way to avoid 
the use of substitute.  E.g., library() has the 'character.only' 
argument; if TRUE then the package argument is treated as an ordinary 
argument and not passed through substitute().

myLoader <- function(package, quietly = TRUE) {
   wrapper <- if (quietly) suppressPackageStartupMessages else `{`
   wrapper(library(package = package, character.only=TRUE))
   }

> lapply(c("MASS","boot"), myLoader, quietly=FALSE)
[[1]]
 [1] "MASS"  "splines"   "pryr"  "stats" "graphics"  "grDevices"
 [7] "utils" "datasets"  "methods"   "base"

[[2]]
 [1] "boot"  "MASS"  "splines"   "pryr"  "stats" 
"graphics"

 [7] "grDevices" "utils" "datasets"  "methods"   "base"

"Non-standard" evaluation (using substitute(), formulas, promises, the 
rlang or lazyeval packages, etc.) has it uses but I wouldn't use it 
for such a function as your loader().

Bill Dunlap
TIBCO Software
wdunlap tibco.com 

On Fri, Jul 28, 2017 at 8:20 PM, Benjamin Tyner > wrote:

Thanks Bill. I think my confusion may have been in part due to my
conflating two distinct meanings of the term "evaluate"; the help
for force says it "forces the evaluation of a function argument"
whereas the help for eval says it "evaluates the ... argument ...
and returns the computed value". I found it helpful to compare:

   > lapply(list(a=1,b=2,c=3), function(x){ force(substitute(x)) })
   $a
   X[[i]]

   $b
   X[[i]]

   $c
   X[[i]]

versus

   > lapply(list(a=1,b=2,c=3), function(x){ eval(substitute(x)) })
   Error in eval(substitute(x)) : object 'X' not found

Now for the context my question arose in: given a function

   loader <- function(package, quietly = TRUE) {

   wrapper <- if (quietly) suppressPackageStartupMessages else `{`

   expr <- substitute(wrapper(library(package = package)))

   eval(expr)
   }

prior to R version 3.2, one could do things like

lapply(c("MASS", "boot"), loader)

but not anymore (which is fine; I agree that one should not depend
on lapply's implementation details).

Regards,
Ben

On 07/28/2017 06:53 PM, William Dunlap wrote:

1: substitute(), when given an argument to a function (which
will be a promise) gives you the unevaluated expression given
as the argument:

>  L <- list(a=1, b=2, c=3)
> str(lapply(L, function(x) substitute(x)))
List of 3
 $ a: language X[[i]]
 $ b: language X[[i]]
 $ c: language X[[i]]

The 'X' and 'i' are in a frame constructed by lapply and you
are not really supposed to depend on the precise form of those
expressions.

2: An evaluated promise is still a promise: it has the
'evaled' field set to TRUE and the 'value' field set to the
result of evaluating 'code' in 'env'.

> f <- function(x, force) {
 if (force) force(x)
 if (pryr::is_promise(x)) promise_info(x)
 else "not a promise"
 }
> str(f(log(-1), force=FALSE))
List of 4
 $ code  : language log(-1)
 $ env   :
 $ evaled: logi FALSE
 $ value : NULL
> str(f(log(-1), force=TRUE))
List of 4
 $ code  : language log(-1)
 $ env   : NULL
 $ evaled: logi TRUE
 $ value : num NaN
Warning message:
In log(-1) : NaNs produced

Can you give a concrete example of what you are try to accomplish?

Bill Dunlap
TIBCO Software
wdunlap tibco.com  

On Fri, Jul 28, 2017 at 3:04 PM, Benjamin Tyner

>> wrote:

Hi,

I thought I understood the change to lapply semantics
resulting
from this,

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16093

Re: [Bioc-devel] Catching SVN up to Github

2017-07-31 Thread Matt Richards

Yes, that's correct; Martin helped us make that change a few weeks ago and
it appears the svn-remote* in the config file are also updated:

svn-remote.devel.url=https://hedgehog.fhcrc.org/bioconductor//trunk/madman/
Rpacks/trena

svn-remote.devel.fetch=:refs/remotes/git-svn-devel

On Fri, Jul 28, 2017 at 6:46 AM, Shepherd, Lori <
lori.sheph...@roswellpark.org> wrote:

> It seems like you renamed your package after it was submitted based on the
> current version in svn and the current ERROR occurring on the build report.
>
>
> Could you check your git config -l   and see if the svn-remote* in the
> config file are updated to reflect the naming change?
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
> --
> *From:* Bioc-devel  on behalf of Matt
> Richards 
> *Sent:* Thursday, July 27, 2017 4:36:47 PM
> *To:* bioc-devel@r-project.org
> *Subject:* [Bioc-devel] Catching SVN up to Github
>
> Hi all,
>
> Since our package, "trena", was accepted, we've made some pretty extensive
> changes to the package on Github. Our version has so far jumped from
> 0.99.10 to 0.99.135. These changes are all contained on a forked version of
> the Bioconductor mirror, as specified (https://www.bioconductor.org/
> developers/how-to/git-mirrors/). We haven't yet put these changes onto
> SVN.
>
> My question is regarding how to get the Github repo and the SVN on the same
> page. I've followed the procedure outlined on the linked page and also
> tried the cherry picking procedure, but any `git svn` command
> (info/rebase/dcommit) run on the devel branch returns me the same message:
>
> Unable to determine upstream SVN information from HEAD history.
>
> I've also tried a `git svn log`, which returns: fatal: your current branch
> appears to be broken
>
> Any ideas what's going on here? I'm a self-admitted novice when it comes to
> SVN.
>
> Thanks
> Matt
>
> --
> Matthew Richards
> Postdoctoral Fellow
> Institute for Systems Biology
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.




-- 
Matthew Richards
Postdoctoral Fellow
Institute for Systems Biology

[[alternative HTML version deleted]]

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

Re: [Rd] translateChar in NewName in bind.c

2017-07-31 Thread Martin Maechler

> Suharto Anggono Suharto Anggono via R-devel 
> on Sun, 30 Jul 2017 14:57:53 + writes:

> R devel's bind.c has been ported to R patched. Is it OK while names of 
'unlist' or 'c' result may be not strictly the same as in R 3.4.1 because of 
changed function 'NewName' in bind.c?

> Using 'translateCharUTF8' instead of 'translateChar' is as it should be. 
It has an effect in non-UTF-8 locale for this example.

> x <- list(1:2)
> names(x) <- "\ue7"
> res <- unlist(x)
> charToRaw(names(res)[1])

> Directly assigning 'tag' to 'ans' is more efficient, but
> may be different from in R 3.4.1 that involves
> 'translateCharUTF8', that is also correct. It has an
> effect for this example. 

> x <- 0
> names(x) <- "\xe7"
> Encoding(names(x)) <- "latin1"
> res <- c(x)
> Encoding(names(res))
> charToRaw(names(res))

Yes, you are right, thank you:

That part of the changes in bind.c was *not* directly related to
the two R-bugs (PR#17284 & PR#17292)... and therefore, maybe I
should not have ported it to R-patched (= R 3.4.1 patched).

Your examples above are instructive..  notably the 2nd one seems
to demonstrate to me, that the change also *did* fix a bug:

   Encoding(names(res))

is "latin1" in R-devel  but interestingly is "UTF-8" in R 3.4.1,
indeed independently of the locale.

I would argue R-devel (and current R-patched) is more faithful
by keeping the Encoding "latin1" that was set for names(x) also
in the  names(c(x)) .

I could revert R-patched's  bind.c (so it only contains the two
official bug fixes PR#172(84|92)   but I wonder if it is
desirable in this case.

I'm glad for further reasoning.
Given current "knowledge"/"evidence",  I would not  revert
R-patched to R 3.4.1's behavior.

Martin

> 
> On Tue, 13/6/17, Tomas Kalibera  wrote:

> Subject: Re: [Rd] translateChar in NewName in bind.c

> @r-project.org
> Date: Tuesday, 13 June, 2017, 2:35 PM

> Thanks, fixed in R-devel.
> Best
> Tomas

[.]

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

Re: [Bioc-devel] transitioning scater/scran to SingleCellExperiment

2017-07-31 Thread Aaron Lun

Dear developers,

Both scater and scran will be migrating to the SingleCellExperiment 
class (https://bioconductor.org/packages/SingleCellExperiment) in the
next BioC release. This is based on a SummarizedExperiment and provides 
a more modern user interface, as well as supporting different matrix
representations (e.g., dgCMatrix, HDF5Matrix).

We note that there are a number of Bioconductor packages that depend 
on/import/suggest scater or scran, which we have listed below:

scDD
scone
SIMLR
splatter
Glimma
SC3
phenopath
switchde

To the maintainers of these packages, we advise switching from SCESet to
SingleCellExperiment as soon as possible; the former will be deprecated
in the next release cycle. There are several things to note here:

- The SCESet previously contained a number of slots relating to
distances and clustering results. These are no longer present in the
SingleCellExperiment, in line with the minimalist design philosophy of
that package. If these are necessary, we suggest extending the
SingleCellExperiment class in your own packages(*).

- For packages that depend directly on methods in scater or scran, a
number of methods have been removed. This aims to simplify the analysis
workflow and code maintenance by reducing redundancy. Please ensure that
your package does not need those missing methods by CHECKing it against 
the experimental versions(**) of these two packages:

https://github.com/LTLA/scran
https://github.com/davismcc/scater/tree/future

If there are any issues with the switch, please let us know and we will
do our best to figure out the most appropriate fix.

Regards,

Aaron, Davis and Davide

(*): If there is popular demand for some slots, we may consider 
including it in the base SingleCellExperiment object.

(**): These versions are highly experimental and fluid, and results are
likely to be unstable over the coming month. Nonetheless, if something
is breaking, it is best that we know sooner rather than later. Or in
other words, don't start complaining when it's close to release time.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Change in BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz

2017-07-31 Thread Janssen-10, R.R.E.

Hello Hervé,

> Hi,
> 
> On 07/30/2017 03:28 AM, Janssen-10, R.R.E. wrote:
>> Hello,
>>
>> So, are you absolutely sure nothing has changed in this package?
>
> All I'm saying it that version 1.4.0 of this package has not changed
> since it was first made on May 13, 2014. Before version 1.4.0, we had
> version 1.3.1000. Of course things have changed in the package between
> version 1.3.1000 and version 1.4.0. IIRC what changed is the way the
> chromosome sequences are stored on disk (in 2bit format since version
> 1.4.0, used to be something else).
> 
>> I can still reproduce the hash mismatch.
>>
>> In GNU Guix, the SHA256 hash is computed when the tarball is downloaded by 
>> the person who adds or changes the package. So at some point, the tarball 
>> was different (at least to to package maintainer).
> 
> Not necessarily. What if the original SHA256 hash got computed on a
> corrupted tarball?
> 
>>
>> The MD5 hashes you provided are the *current* hashes and does not say 
>> anything about the history of these files.
> 
> Note that they are the "current" hashes of tarballs that belong to
> versions of Bioconductor that have been frozen for years (every 6
> months we release a new BioC version and freeze the previous one).
> 
>> What is their last modification date?
> 
> webadmin@ip-172-30-4-20:/extra/www/bioc/packages$ ls -l
> 3.*/data/annotation/src/contrib/BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> -rw-r--r-- 1 webadmin webadmin 688190187 May 13  2014
> 3.0/data/annotation/src/contrib/BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> -rw-r--r-- 1 webadmin webadmin 688190187 Apr 15  2015
> 3.1/data/annotation/src/contrib/BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> -rw-r--r-- 1 webadmin webadmin 688190187 Oct 26  2015
> 3.2/data/annotation/src/contrib/BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> -rw-r--r-- 1 webadmin webadmin 688190187 Oct 13  2015
> 3.3/data/annotation/src/contrib/BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> -rw-r--r-- 1 webadmin webadmin 688190187 Oct 13  2015
> 3.4/data/annotation/src/contrib/BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> -rw-r--r-- 1 webadmin webadmin 688190187 Oct 13  2015
> 3.5/data/annotation/src/contrib/BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> -rw-r--r-- 1 webadmin webadmin 688190187 Oct 13  2015
> 3.6/data/annotation/src/contrib/BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> 
> Futhermore, all these tarballs are copies of a tarball I generated
> in 2014 on a server at the Fred Hutch called rhino3. I just went on
> this server and the original tarball is still there:
> 
>hpages@rhino3:~/BSgenomeForge/forged/1.4.0$ ls -l
> BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> -rw-r--r-- 1 hpages g_hpages 688190187 May 13  2014
> BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> 
> As you can see, it's from May 13, 2014. Its M5 hash is:
> 
>hpages@rhino3:~/BSgenomeForge/forged/1.4.0$ md5sum
> BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> 672a988b28d8602afb2bd5595db7303b  BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz
> 
> Same hash as in my previous email.
> 
> I hope that's enough evidence that this tarball has never
> changed on our side.
> 
> Cheers,
> H.

Yes it is. Thanks!

Kind regards,
Roel Janssen
--

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct
te informeren door het bericht te retourneren. Het Universitair Medisch
Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W.
(Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij
de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.

Denk s.v.p aan het milieu voor u deze e-mail afdrukt.

--

This message may contain confidential information and is...{{dropped:11}}

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

Re: [Rd] force promises inside lapply

[Rd] reproducible segmentation fault installing packages on FreeBSD 11.1

Re: [Rd] force promises inside lapply

Re: [Bioc-devel] Catching SVN up to Github

Re: [Rd] translateChar in NewName in bind.c

Re: [Bioc-devel] transitioning scater/scran to SingleCellExperiment

Re: [Bioc-devel] Change in BSgenome.Hsapiens.UCSC.hg19_1.4.0.tar.gz

7 matches

Site Navigation

Mail list logo

Footer information