Re: [Rd] A weird behaviour of strsplit?

[Pages, Herve]

The fact that strsplit() doesn't say anything about 'split' being longer 
than 'x' adds to the confusion:

   > strsplit(c("xAy", "xxByB", "xCyCCz"), split=c("A", "B", "C", "D"))
   [[1]]
   [1] "x" "y"

   [[2]]
   [1] "xx" "y"

   [[3]]
   [1] "x" "y" ""  "z"

A warning (or error) would go a long way in helping the user realize 
they're doing something wrong.

No warning either when 'split' is shorter than 'x' but the length of the 
latter is not a multiple of the length of the former:

   > strsplit(c("xAy", "xxByB", "xCyCCz"), split=c("A", "B"))
   [[1]]
   [1] "x" "y"

   [[2]]
   [1] "xx" "y"

   [[3]]
   [1] "xCyCCz"

Which is also unexpected given that most binary operations do issue a 
warning in this case (e.g. 11:13 * 1:2).

H.


On 12/18/19 06:48, Duncan Murdoch wrote:
> On 18/12/2019 9:42 a.m., IAGO GINÉ VÁZQUEZ wrote:
>> Hi all,
>>
>> In the help of strsplit one can read
>>
>> split   character vector (or object which can be coerced to such) 
>> containing regular 
>> expression>  
>> >(s) (unless fixed = TRUE) to use for splitting. If empty matches 
>> occur, in particular if split has length 0, x is split into single 
>> characters. Ifsplit has length greater than 1, it is re-cycled along x.
>>
>> Taking into account that split is said to be a vector (not a length 1 
>> vector) and the last claim above, I would expect that the output of
>>
>>
>> strsplit("3:4", split = c(",",":"), fixed = TRUE)
>>
>> was the same than the output of
>>
>> strsplit("3:4", split = c(":"), fixed = TRUE)
>>
>> that is, splitting by "," (without effect in this example) and also by 
>> ":"
>>
>> [[1]]
>> [1] "3" "4"
>>
>> But, instead, I get
>> [[1]]
>> [1] "3:4"
>>
>> Am I wrongly understanding the help? Is it an expected output?
>> I tried with R 3.6.1 for Windows (10).
> 
> Yes, you are misunderstanding the help.  Your input x has length 1, so 
> only the first element of split will be used.  If you wanted to use 
> both, you would need a longer x.  For example,
> 
>  > strsplit(c("1:2", "3:4"), split=c(",", ":"), fixed=TRUE)
> [[1]]
> [1] "1:2"
> 
> [[2]]
> [1] "3" "4"
> 
> The first element is split using "," -- since there are none, there's no 
> splitting done.  The second element is split using ":".
> 
> Duncan Murdoch
> 
> __
> R-devel@r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=8oX1lQmqWY3lK0RSHzCrjkg95jmR7nr4Q0GU3Nw13qA=9m5muon8TUVCJdnvZtnyuxUQ88pc7qHCUsC6JGDF1qM=
>  
> 

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] head/tail breaking change

[Jan Gorecki]

Thank you Gabriel,
I agree that new behaviour makes much more sense. Just wanted to confirm
before resolving compatibility of my unit tests.
Best,
Jan

On Wed 18 Dec, 2019, 10:46 PM Gabriel Becker,  wrote:

> Jan,
>
> That is an intentional change as you can see in the documentation for
> head/tail in R-devel. Last time I discussed it with Martin, this behavior
> was desired and thus is unlikely to change unless "our" (ie his) mind does.
>
> The hope is that the new behavior is actually what people would want (note
> it already behaves this way for data.frames and for matrices, which are now
> explicitly array objects with 2 dimensions as well as classed as matrices,
> so its more consistent now, and more reasonable for the object).
>
> Best,
> ~G
>
> On Wed, Dec 18, 2019 at 2:44 AM Jan Gorecki  wrote:
>
>> Hi R-devel community,
>>
>> I am aware of changes in R-devel in head/tail methods but I was not
>> expecting that to be a breaking change.
>>
>> # R 3.6.1
>> ar = array(1:27, c(3,3,3))
>> tail(ar, 1)
>> #[1] 27
>>
>> The current output of R-devel is something that I would expect from a
>>
>> tail(ar, c(1, Inf, Inf))
>>
>> or
>>
>> tail(ar, c(1, NA, NA))
>>
>> calls.
>> Is it going to stay like this or there are plans to mitigate this
>> breaking change?
>>
>> # R-devel 2019-12-17 r77592
>> ar = array(1:27, c(3,3,3))
>> tail(ar, 1)
>> #, , 1
>> #
>> # [,1] [,2] [,3]
>> #[3,]369
>> #
>> #, , 2
>> #
>> # [,1] [,2] [,3]
>> #[3,]   12   15   18
>> #
>> #, , 3
>> #
>> # [,1] [,2] [,3]
>> #[3,]   21   24   27
>>
>> Best,
>> Jan Gorecki
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

[[alternative HTML version deleted]]

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

[Bioc-devel] Question regarding pruning release of large files

[Saskia Freytag]

Hi,

I stupidly added and tracked some large files in my package repo at the start. 
I have since deleted these files and would like to permanently remove them form 
my GitHub history. I have been able to this locally. However when I try to do 
‘git push upstream RELEASE_3_10’, it asks me to fetch first. This results in 
the history being restored. I have tried to do ‘git push —force’, but this 
results in an error. Is there any way to delete the history of these files from 
the upstream?

Cheers,

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

Re: [R-pkg-devel] Manual inspection of a new CRAN submission

[Mauricio Zambrano-Bigiarini]

Thank you very much Duncan for the information.

BTW, it is incredible to me how the quality control of packages
submitted to CRAN  has improved in the last decade. Now the automatic
procedures are able to identify even "little" things (e.g., broken
links, misspelled words, size of vignettes, etc).

Thank you very much for all the effort and dedication of the CRAN
Repository Maintainers.

Kind regards,

Mauricio

=
"Success is not final, failure is not fatal.
It is the courage to continue that counts.
(Winston Churchill)
=
Linux user #454569 -- Linux Mint user

On Wed, 18 Dec 2019 at 19:50, Duncan Murdoch  wrote:
>
> On 18/12/2019 5:01 p.m., Mauricio Zambrano-Bigiarini wrote:
> > Dear List,
> >
> > Today I submitted a package to CRAN, and after correcting some NOTEs,
> > I got the following automatic message:
> >
> > "package mypackage_0.1-2.tar.gz has been auto-processed and is pending
> > a manual inspection of this new CRAN submission. A CRAN team member
> > will typically respond to you within the next 10 working days. For
> > technical reasons you may receive a second copy of this message when a
> > team member triggers a new check."
> >
> >
> > Could somebody give a short explanation about what type of checkings
> > are made in this "manual inspection" ?
> >
>
> Basically they're checking whether you are following the guidelines at
> https://cran.r-project.org/web/packages/policies.html.  Not all of those
> things can be checked automatically, and many people claim to be
> following them when they actually are not.
>
> Duncan Murdoch

-- 
La información contenida en este correo electrónico y cualquier anexo o 
respuesta relacionada, puede contener datos e información confidencial y no 
puede ser usada o difundida por personas distintas a su(s) destinatario(s). 
Si usted no es el destinatario de esta comunicación, le informamos que 
cualquier divulgación, distribución o copia de esta información constituye 
un delito conforme a la ley chilena. Si lo ha recibido por error, por favor 
borre el mensaje y todos sus anexos y notifique al remitente.

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

Re: [R-pkg-devel] Manual inspection of a new CRAN submission

[Duncan Murdoch]

On 18/12/2019 5:01 p.m., Mauricio Zambrano-Bigiarini wrote:

Dear List,

Today I submitted a package to CRAN, and after correcting some NOTEs,
I got the following automatic message:

"package mypackage_0.1-2.tar.gz has been auto-processed and is pending
a manual inspection of this new CRAN submission. A CRAN team member
will typically respond to you within the next 10 working days. For
technical reasons you may receive a second copy of this message when a
team member triggers a new check."


Could somebody give a short explanation about what type of checkings
are made in this "manual inspection" ?



Basically they're checking whether you are following the guidelines at 
https://cran.r-project.org/web/packages/policies.html.  Not all of those 
things can be checked automatically, and many people claim to be 
following them when they actually are not.


Duncan Murdoch

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

[R-pkg-devel] Manual inspection of a new CRAN submission

[Mauricio Zambrano-Bigiarini]

Dear List,

Today I submitted a package to CRAN, and after correcting some NOTEs,
I got the following automatic message:

"package mypackage_0.1-2.tar.gz has been auto-processed and is pending
a manual inspection of this new CRAN submission. A CRAN team member
will typically respond to you within the next 10 working days. For
technical reasons you may receive a second copy of this message when a
team member triggers a new check."


Could somebody give a short explanation about what type of checkings
are made in this "manual inspection" ?

Thak in advance for your help,

Mauricio



Mauricio Zambrano-Bigiarini, PhD

=
Department of Civil Engineering
Faculty of Engineering and Sciences
Universidad de La Frontera, Temuco, Chile
http://hzambran.github.io/
=
mailto : mauricio.zambr...@ufrontera.cl
work-phone : +56 45 259 2812
=
"Success is not final, failure is not fatal.
It is the courage to continue that counts.
(Winston Churchill)
=
Linux user #454569 -- Linux Mint user

-- 
La información contenida en este correo electrónico y cualquier anexo o 
respuesta relacionada, puede contener datos e información confidencial y no 
puede ser usada o difundida por personas distintas a su(s) destinatario(s). 
Si usted no es el destinatario de esta comunicación, le informamos que 
cualquier divulgación, distribución o copia de esta información constituye 
un delito conforme a la ley chilena. Si lo ha recibido por error, por favor 
borre el mensaje y todos sus anexos y notifique al remitente.

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

Re: [Rd] head/tail breaking change

[Gabriel Becker]

Jan,

That is an intentional change as you can see in the documentation for
head/tail in R-devel. Last time I discussed it with Martin, this behavior
was desired and thus is unlikely to change unless "our" (ie his) mind does.

The hope is that the new behavior is actually what people would want (note
it already behaves this way for data.frames and for matrices, which are now
explicitly array objects with 2 dimensions as well as classed as matrices,
so its more consistent now, and more reasonable for the object).

Best,
~G

On Wed, Dec 18, 2019 at 2:44 AM Jan Gorecki  wrote:

> Hi R-devel community,
>
> I am aware of changes in R-devel in head/tail methods but I was not
> expecting that to be a breaking change.
>
> # R 3.6.1
> ar = array(1:27, c(3,3,3))
> tail(ar, 1)
> #[1] 27
>
> The current output of R-devel is something that I would expect from a
>
> tail(ar, c(1, Inf, Inf))
>
> or
>
> tail(ar, c(1, NA, NA))
>
> calls.
> Is it going to stay like this or there are plans to mitigate this
> breaking change?
>
> # R-devel 2019-12-17 r77592
> ar = array(1:27, c(3,3,3))
> tail(ar, 1)
> #, , 1
> #
> # [,1] [,2] [,3]
> #[3,]369
> #
> #, , 2
> #
> # [,1] [,2] [,3]
> #[3,]   12   15   18
> #
> #, , 3
> #
> # [,1] [,2] [,3]
> #[3,]   21   24   27
>
> Best,
> Jan Gorecki
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] readBin should check that its endian argument is a legal value

[Jennifer Lyon]

Thank you!

Jen

On Wed, Dec 18, 2019 at 4:12 AM Tomas Kalibera 
wrote:

> Thank you for reporting this problem, R-devel now has a check in readBin
> and writeBin.
>
> I've identified two CRAN packages with an incorrect value for "endian"
> and reported to maintainers, unfortunately in their case the intention
> was to specify "little".
>
> Best
> Tomas
>
> On 11/18/19 11:22 PM, Jennifer Lyon wrote:
> > I think it would be helpful if readBin checked that its endian argument
> is
> > a legal value.
> >
> > Why? I was reviewing some of our code and noticed that the author had
> > readBin(..., endian="network") and never having heard of "network", I
> > looked at the man page for readBin, and it hadn't heard of "network"
> > either. Not good.
> >
> > I then looked at the R code for readBin, which has this line:
> >   swap <- endian != .Platform$endian
> >
> > and swap is passed into the .Internal(readBin). Further use of Google
> > revealed that "network" is a known endian in the universe, and our code
> was
> > working by essentially a lucky chance that the data was "big" and our
> > current machines are "little". Really not good. I don't know enough about
> > endian stuff to know if it makes sense that "network" should be one of
> the
> > choices for endian for readBin (which from the documentation currently
> are:
> > "big", "little" or "swap"), but in my opinion R should have failed with
> the
> > choice of "network" in our code in the current version of R. I did
> > eventually find an aside in the R Data Import/Export document that
> > "network" is "big" so I will patch our code to be legal. Of course some
> > code may depend on this undocumented behavior, but I would guess that in
> > the vast majority of cases an illegal value really is a mistake.
> >
> > Jen
> >
> >> sessionInfo()
> > R version 3.6.1 (2019-07-05)
> > Platform: x86_64-pc-linux-gnu (64-bit)
> > Running under: Ubuntu 18.04.3 LTS
> >
> > Matrix products: default
> > BLAS:   /home/mbr/r-project/R-3.6.1/lib/libRblas.so
> > LAPACK: /home/mbr/r-project/R-3.6.1/lib/libRlapack.so
> >
> > locale:
> >   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> >   [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> >   [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> >   [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
> >   [9] LC_ADDRESS=C   LC_TELEPHONE=C
> > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] stats graphics  grDevices utils datasets  methods   base
> >
> > loaded via a namespace (and not attached):
> > [1] compiler_3.6.1
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] A weird behaviour of strsplit?

[Duncan Murdoch]

On 18/12/2019 9:42 a.m., IAGO GINÉ VÁZQUEZ wrote:

Hi all,

In the help of strsplit one can read

split   character vector (or object which can be coerced to such) containing regular 
expression(s)
 (unless fixed = TRUE) to use for splitting. If empty matches occur, in particular if 
split has length 0, x is split into single characters. Ifsplit has length greater 
than 1, it is re-cycled along x.

Taking into account that split is said to be a vector (not a length 1 vector) 
and the last claim above, I would expect that the output of


strsplit("3:4", split = c(",",":"), fixed = TRUE)

was the same than the output of

strsplit("3:4", split = c(":"), fixed = TRUE)

that is, splitting by "," (without effect in this example) and also by ":"

[[1]]
[1] "3" "4"

But, instead, I get
[[1]]
[1] "3:4"

Am I wrongly understanding the help? Is it an expected output?
I tried with R 3.6.1 for Windows (10).


Yes, you are misunderstanding the help.  Your input x has length 1, so 
only the first element of split will be used.  If you wanted to use 
both, you would need a longer x.  For example,


> strsplit(c("1:2", "3:4"), split=c(",", ":"), fixed=TRUE)
[[1]]
[1] "1:2"

[[2]]
[1] "3" "4"

The first element is split using "," -- since there are none, there's no 
splitting done.  The second element is split using ":".


Duncan Murdoch

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

[Rd] A weird behaviour of strsplit?

[IAGO GINÉ VÁZQUEZ]

Hi all,

In the help of strsplit one can read

split   character vector (or object which can be coerced to such) containing 
regular 
expression(s)
 (unless fixed = TRUE) to use for splitting. If empty matches occur, in 
particular if split has length 0, x is split into single characters. Ifsplit 
has length greater than 1, it is re-cycled along x.

Taking into account that split is said to be a vector (not a length 1 vector) 
and the last claim above, I would expect that the output of


strsplit("3:4", split = c(",",":"), fixed = TRUE)

was the same than the output of

strsplit("3:4", split = c(":"), fixed = TRUE)

that is, splitting by "," (without effect in this example) and also by ":"

[[1]]
[1] "3" "4"

But, instead, I get
[[1]]
[1] "3:4"

Am I wrongly understanding the help? Is it an expected output?
I tried with R 3.6.1 for Windows (10).

Thank you!
Iago


[[alternative HTML version deleted]]

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

Re: [Rd] readBin should check that its endian argument is a legal value

[Tomas Kalibera]

Thank you for reporting this problem, R-devel now has a check in readBin 
and writeBin.


I've identified two CRAN packages with an incorrect value for "endian" 
and reported to maintainers, unfortunately in their case the intention 
was to specify "little".


Best
Tomas

On 11/18/19 11:22 PM, Jennifer Lyon wrote:

I think it would be helpful if readBin checked that its endian argument is
a legal value.

Why? I was reviewing some of our code and noticed that the author had
readBin(..., endian="network") and never having heard of "network", I
looked at the man page for readBin, and it hadn't heard of "network"
either. Not good.

I then looked at the R code for readBin, which has this line:
  swap <- endian != .Platform$endian

and swap is passed into the .Internal(readBin). Further use of Google
revealed that "network" is a known endian in the universe, and our code was
working by essentially a lucky chance that the data was "big" and our
current machines are "little". Really not good. I don't know enough about
endian stuff to know if it makes sense that "network" should be one of the
choices for endian for readBin (which from the documentation currently are:
"big", "little" or "swap"), but in my opinion R should have failed with the
choice of "network" in our code in the current version of R. I did
eventually find an aside in the R Data Import/Export document that
"network" is "big" so I will patch our code to be legal. Of course some
code may depend on this undocumented behavior, but I would guess that in
the vast majority of cases an illegal value really is a mistake.

Jen


sessionInfo()

R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.3 LTS

Matrix products: default
BLAS:   /home/mbr/r-project/R-3.6.1/lib/libRblas.so
LAPACK: /home/mbr/r-project/R-3.6.1/lib/libRlapack.so

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

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

loaded via a namespace (and not attached):
[1] compiler_3.6.1

[[alternative HTML version deleted]]

__
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] head/tail breaking change

[Jan Gorecki]

Hi R-devel community,

I am aware of changes in R-devel in head/tail methods but I was not
expecting that to be a breaking change.

# R 3.6.1
ar = array(1:27, c(3,3,3))
tail(ar, 1)
#[1] 27

The current output of R-devel is something that I would expect from a

tail(ar, c(1, Inf, Inf))

or

tail(ar, c(1, NA, NA))

calls.
Is it going to stay like this or there are plans to mitigate this
breaking change?

# R-devel 2019-12-17 r77592
ar = array(1:27, c(3,3,3))
tail(ar, 1)
#, , 1
#
# [,1] [,2] [,3]
#[3,]369
#
#, , 2
#
# [,1] [,2] [,3]
#[3,]   12   15   18
#
#, , 3
#
# [,1] [,2] [,3]
#[3,]   21   24   27

Best,
Jan Gorecki

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

Re: [Bioc-devel] bioctitle issue for Rmd

[Pages, Herve]

Hi Vince,

I opened an issue on GitHub for this:

   https://github.com/Bioconductor/BiocStyle/issues/68

H.

On 12/15/19 14:31, Vincent Carey wrote:
> On my mac and linux systems I am seeing a new
> 
> error.  With the latest checkout of BiocStyle
> 
> 
> rmarkdown::render("foo/BiocStyle/vignettes/AuthoringRmdVignettes.Rmd",
> BiocStyle::pdf_document())
> 
> 
> produced
> 
> 
> ! Undefined control sequence.
> 
> l.56 \bioctitle
> 
> []{Authoring R Markdown vignettes}
> 
> 
> Error: Failed to compile AuthoringRmdVignettes.tex. See
> https://urldefense.proofpoint.com/v2/url?u=https-3A__yihui.org_tinytex_r_-23debugging=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=QQEy7hX7LwNRfF2vOZqRi_8FzxYRlsfwkrE-ikutFo8=DK8vF4FSB0aOHaOmdcHCs_2qILx4O70kCr3gdn2oWyg=
>   for debugging tips. See
> AuthoringRmdVignettes.log for more info.
> 
>> sessionInfo()
> 
> R Under development (unstable) (2019-12-06 r77536)
> 
> Platform: x86_64-pc-linux-gnu (64-bit)
> 
> Running under: Debian GNU/Linux 10 (buster)
> 
> 
> Matrix products: default
> 
> BLAS/LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.3.5.so
> 
> 
> locale:
> 
>   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> 
>   [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> 
>   [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=C
> 
>   [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
> 
>   [9] LC_ADDRESS=C   LC_TELEPHONE=C
> 
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> 
> 
> attached base packages:
> 
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> 
> other attached packages:
> 
> [1] BiocStyle_2.15.2rmarkdown_2.0   BiocManager_1.30.10
> 
> 
> loaded via a namespace (and not attached):
> 
>   [1] Rcpp_1.0.3  bookdown_0.16   digest_0.6.23   magrittr_1.5
> 
>   [5] evaluate_0.14   rlang_0.4.2 stringi_1.4.3   tools_4.0.0
> 
>   [9] stringr_1.4.0   tinytex_0.18xfun_0.11   yaml_2.2.0
> 
> [13] compiler_4.0.0  htmltools_0.4.0 knitr_1.26
> 

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel