Re: [Rd] Fw: Calling a LAPACK subroutine from R

[Avraham Adler]

I think better stated that it is subset that relied on a “bug” that was
never trapped for until now. We’re it written “properly” this never would
have arisen. At least to the best of my understanding.

Avi

On Wed, Sep 11, 2019 at 4:34 PM Göran Broström 
wrote:

>
>
> On 2019-09-11 22:16, Avraham Adler wrote:
> > Can you write a small C function that calls LAPACK call that fro your
> > Fortran code? Yes, an extra step but maybe less traumatic than rewriting
> > parts of LAPACK directly.
>
> Yes, I know how to do that, but I find it somewhat bizarre that it is
> impossible to call a Fortran subroutine from Fortran. And rewriting
> 'dgemv' was simple: Just change character to integer and 'N' to 1. And
> rename the subroutine. The hard (tedious) part was to include all the
> LAPACK authors in my DESCRIPTION file.
>
> My guess is that the root cause is that BLAS/LAPACK is written in
> FORTRAN 77, which is said to be a subset of the current Fortran version
> but obviously isn't.
>
> Thanks, Göran
>
> >
> > Avi
> >
> > On Wed, Sep 11, 2019 at 4:08 PM Göran Broström  > > wrote:
> >
> > Berend,
> >
> > I do not think this works with gfortran 7+. I am calling the BLAS
> > subroutine dgemv from Fortran code in my package eha, and the check
> > (with R-devel) gives:
> >
> > gmlfun.f:223:1: warning: type of ‘dgemv’ does not match original
> > declaration [-Wlto-type-mismatch]
> > & score, ione)
> >^
> > /home/gobr0002/R/src/R-devel/include/R_ext/BLAS.h:107:1: note: type
> > mismatch in parameter 12
> >F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
> >
> > Type of a Fortran subroutine is matched against type of a C
> function?!
> > My conclusion is that it is impossible to call a BLAS subroutine
> with a
> > character parameter from Fortran code (nowadays). Calling from C
> > code is
> > fine, on the other hand(!).
> >
> > I have recently asked about this on R-pkg-devel, but not received any
> > useful answers, and my submission to CRAN is rejected. I solve it by
> > making a personal copy of dgemv and changing the character parameter
> to
> > integer, and adding Jack Dongarra, Jeremy Du Croz, Sven Hammarling,
> and
> > Richard Hanson as authors of eha. And a Copyright note, all in the
> > DESCRIPTION file. Ugly but what can I do (except rewriting the
> Fortran
> > code in C with f2c)?
> >
> > Göran
> >
> > On 2019-09-11 21:38, Berend Hasselman wrote:
> >  >
> >  > The Lapack library is loaded automatically by R itself when it
> > needs it  for doing some calculation.
> >  > You can force it to do that with a (dummy) solve for example.
> >  > Put this at start of your script:
> >  >
> >  > 
> >  > # dummy code to get LAPACK library loaded
> >  > X1 <- diag(2,2)
> >  > x1 <- rep(2,2)
> >  > # X1;x1
> >  > z <- solve(X1,x1)
> >  > 
> >  >
> >  > followed by the rest of your script.
> >  > You will get a warning (I do) that  "passing a character vector
> > to .Fortran is not portable".
> >  > On other systems this may gave fatal errors. This is quick and
> > very dirty. Don't do it.
> >  >
> >  > I believe there is a better and much safer way to achieve what
> > you want.
> >  > Here goes.
> >  >
> >  > Create a folder (directory) src in the directory where your
> > script resides.
> >  > Create a wrapper for "dpbtrf" file in a file xdpbtrf.f that takes
> > an integer instead of character
> >  >
> >  > 
> >  > c intermediate for dpbtrf
> >  >
> >  >SUBROUTINE xDPBTRF( kUPLO, N, KD, AB, LDAB, INFO )
> >  >
> >  > c  .. Scalar Arguments ..
> >  >integer kUPLO
> >  >INTEGER INFO, KD, LDAB, N
> >  >
> >  > c  .. Array Arguments ..
> >  >DOUBLE PRECISION   AB( LDAB, * )
> >  >
> >  >character UPLO
> >  > c convert integer argument to character
> >  >if(kUPLO .eq. 1 ) then
> >  >UPLO = 'L'
> >  >else
> >  >UPLO = 'U'
> >  >endif
> >  >
> >  >call dpbtrf(UPLO,N,KD,AB,LDAB,INFO)
> >  >return
> >  >end
> >  > 
> >  >
> >  >
> >  > Instead of a character argument UPLO it takes an integer argument
> > kUPLO.
> >  > The meaning should be obvious from the code.
> >  >
> >  > Now create a shell script in the folder of your script to
> > generate a dynamic library to be loaded in your script:
> >  >
> >  > 
> >  > # Build a binary dynamic library for accessing Lapack dpbtrf
> >  >
> >  > # syntax checking
> >  >
> >  > SONAME=xdpbtrf.so
> >  >
> >  > echo Strict syntax checking
> >  > echo --
> >  > gfortran -c -fsyntax-only 

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Michael Lawrence via Bioc-devel]

Good call. Didn't know about seqlevelsInUse().

On Wed, Sep 11, 2019 at 8:29 AM Pages, Herve  wrote:
>
> Or more accurately:
>
>as(seqinfo(bsgenome)[seqlevelsInUse(grl)], "GRanges")
>
> since not all seqlevels are necessarily "in use" (i.e. not necessarily
> represented in seqnames(grl)).
>
> H.
>
> On 9/11/19 08:26, Hervé Pagès wrote:
> > The unique seqnames is what we call the seqlevels. So just:
> >
> >as(seqinfo(bsgenome)[seqlevels(grl)], "GRanges")
> >
> > H.
> >
> > On 9/11/19 07:42, Michael Lawrence wrote:
> >> So why not just do:
> >>
> >> as(seqinfo(bsgenome)[unique(unlist(seqnames(grl)))], "GRanges")
> >>
> >> Michael
> >>
> >> On Wed, Sep 11, 2019 at 5:55 AM Bhagwat, Aditya
> >>  wrote:
> >>>
> >>> Thanks Michael,
> >>>
> >>> The important detail is that I want to plot the relevant chromosomes
> >>> only
> >>>
> >>>  relevant_chromosomes <- GenomeInfoDb::seqnames(grangeslist)  %>%
> >>>  S4Vectors::runValue() %>%
> >>>  Reduce(union, .) %>%
> >>>  unique()
> >>>
> >>>  genomeranges <- GenomeInfoDb::seqinfo(grangeslist) %>%
> >>>  as('GRanges') %>%
> >>> (function(gr){
> >>> gr [ as.character(GenomeInfoDb::seqnames(gr))
> >>> %in%
> >>>  relevant_chromosomes ]
> >>> })
> >>>
> >>>  kp <- karyoploteR::plotKaryotype(genomeranges)
> >>>  karyoploteR::kpPlotRegions(kp, grangeslist) # grangeslist
> >>> contains crispr target sites
> >>>
> >>>
> >>> And, this process required as("GRanges")
> >>>
> >>>  #' Convert BSgenome into GRanges
> >>>  #' @param from BSgenome, e.g.
> >>> BSgenome.Mmusculus.UCSC.mm10::Mmusculus
> >>>  #' @examples
> >>>  #' require(magrittr)
> >>>  #' BSgenome.Mmusculus.UCSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
> >>>  #' as('GRanges')
> >>>  #' @importClassesFrom BSgenome BSgenome
> >>>  #' @export
> >>>  methods::setAs( "BSgenome",
> >>>  "GRanges",
> >>>  function(from)  from %>%
> >>>  GenomeInfoDb::seqinfo() %>%
> >>>  as('GRanges'))
> >>>
> >>> Thankyou for feedback,
> >>>
> >>> Aditya
> >>>
> >>> 
> >>> From: Michael Lawrence [lawrence.mich...@gene.com]
> >>> Sent: Wednesday, September 11, 2019 2:31 PM
> >>> To: Bhagwat, Aditya
> >>> Cc: Pages, Herve; bioc-devel@r-project.org
> >>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching
> >>> BiocGenerics (and others)?
> >>>
> >>> I'm pretty surprised that the karyoploteR package does not accept a
> >>> Seqinfo since it is plotting chromosomes. But again, please consider
> >>> just doing as(seqinfo(bsgenome), "GRanges").
> >>>
> >>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
> >>>  wrote:
> 
>  Hi Herve,
> 
>  Thank you for your responses.
>   From your response, it is clear that the vcountPDict use case does
>  not need a BSgenome -> GRanges coercer.
> 
>  The karyoploteR use case still requires it, though, to allow
>  plotting of only the chromosomal BSgenome portions:
> 
>   chromranges <- as(bsegenome, "GRanges")
>   kp <- karyoploteR::plotKaryotype(chromranges)
>   karyoploteR::kpPlotRegions(kp, crispr_target_sites)
> 
>  Or do you see any alternative for this purpose too?
> 
>  Aditya
> 
>  
>  From: Pages, Herve [hpa...@fredhutch.org]
>  Sent: Wednesday, September 11, 2019 12:24 PM
>  To: Bhagwat, Aditya; bioc-devel@r-project.org
>  Subject: Re: [Bioc-devel] Import BSgenome class without attaching
>  BiocGenerics (and others)?
> 
>  Hi Aditya,
> 
>  On 9/11/19 01:31, Bhagwat, Aditya wrote:
> > Hi Herve,
> >
> >
> >   > It feels that a coercion method from BSgenome to GRanges should
> > rather be defined in the BSgenome package itself.
> >
> > :-)
> >
> >
> >   > Patch/PR welcome on GitHub.
> >
> > Owkies. What pull/fork/check/branch protocol to be followed?
> >
> >
> >   > Is this what you have in mind for this coercion?
> >   > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
> >
> > Yes.
> >
> > Perhaps also useful to share the wider context, allowing your and
> > others
> > feedback for improved software design.
> > I wanted to subset a
> > BSgenome
> >
> > (without the _random or _unassigned), but Lori explained this is not
> > possible.
> > 

Re: [Rd] Fw: Calling a LAPACK subroutine from R

[Avraham Adler]

Can you write a small C function that calls LAPACK call that fro your
Fortran code? Yes, an extra step but maybe less traumatic than rewriting
parts of LAPACK directly.

Avi

On Wed, Sep 11, 2019 at 4:08 PM Göran Broström 
wrote:

> Berend,
>
> I do not think this works with gfortran 7+. I am calling the BLAS
> subroutine dgemv from Fortran code in my package eha, and the check
> (with R-devel) gives:
>
> gmlfun.f:223:1: warning: type of ‘dgemv’ does not match original
> declaration [-Wlto-type-mismatch]
>& score, ione)
>   ^
> /home/gobr0002/R/src/R-devel/include/R_ext/BLAS.h:107:1: note: type
> mismatch in parameter 12
>   F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
>
> Type of a Fortran subroutine is matched against type of a C function?!
> My conclusion is that it is impossible to call a BLAS subroutine with a
> character parameter from Fortran code (nowadays). Calling from C code is
> fine, on the other hand(!).
>
> I have recently asked about this on R-pkg-devel, but not received any
> useful answers, and my submission to CRAN is rejected. I solve it by
> making a personal copy of dgemv and changing the character parameter to
> integer, and adding Jack Dongarra, Jeremy Du Croz, Sven Hammarling, and
> Richard Hanson as authors of eha. And a Copyright note, all in the
> DESCRIPTION file. Ugly but what can I do (except rewriting the Fortran
> code in C with f2c)?
>
> Göran
>
> On 2019-09-11 21:38, Berend Hasselman wrote:
> >
> > The Lapack library is loaded automatically by R itself when it needs it
> for doing some calculation.
> > You can force it to do that with a (dummy) solve for example.
> > Put this at start of your script:
> >
> > 
> > # dummy code to get LAPACK library loaded
> > X1 <- diag(2,2)
> > x1 <- rep(2,2)
> > # X1;x1
> > z <- solve(X1,x1)
> > 
> >
> > followed by the rest of your script.
> > You will get a warning (I do) that  "passing a character vector  to
> .Fortran is not portable".
> > On other systems this may gave fatal errors. This is quick and very
> dirty. Don't do it.
> >
> > I believe there is a better and much safer way to achieve what you want.
> > Here goes.
> >
> > Create a folder (directory) src in the directory where your script
> resides.
> > Create a wrapper for "dpbtrf" file in a file xdpbtrf.f that takes an
> integer instead of character
> >
> > 
> > c intermediate for dpbtrf
> >
> >SUBROUTINE xDPBTRF( kUPLO, N, KD, AB, LDAB, INFO )
> >
> > c  .. Scalar Arguments ..
> >integer kUPLO
> >INTEGER INFO, KD, LDAB, N
> >
> > c  .. Array Arguments ..
> >DOUBLE PRECISION   AB( LDAB, * )
> >
> >character UPLO
> > c convert integer argument to character
> >if(kUPLO .eq. 1 ) then
> >UPLO = 'L'
> >else
> >UPLO = 'U'
> >endif
> >
> >call dpbtrf(UPLO,N,KD,AB,LDAB,INFO)
> >return
> >end
> > 
> >
> >
> > Instead of a character argument UPLO it takes an integer argument kUPLO.
> > The meaning should be obvious from the code.
> >
> > Now create a shell script in the folder of your script to generate a
> dynamic library to be loaded in your script:
> >
> > 
> > # Build a binary dynamic library for accessing Lapack dpbtrf
> >
> > # syntax checking
> >
> > SONAME=xdpbtrf.so
> >
> > echo Strict syntax checking
> > echo --
> > gfortran -c -fsyntax-only -fimplicit-none -Wall src/*.f || exit 1
> >
> > LAPACK=$(R CMD config LAPACK_LIBS)
> > R CMD SHLIB --output=${SONAME} src/*.f ${LAPACK} || exit 1
> > 
> >
> > To load the dynamic library xdpbtrf.so  change your script into this
> >
> > 
> > dyn.load("xdpbtrf.so")
> > n <- 4L
> > phi <- 0.64
> > AB <- matrix(0, 2, n)
> > AB[1, ] <- c(1, rep(1 + phi^2, n-2), 1)
> > AB[2, -n] <- -phi
> > round(AB, 3)
> >
> > AB.ch <- .Fortran("xdpbtrf", kUPLO=1L, N = as.integer(n),
> >  KD = 1L, AB = AB, LDAB = 2L, INFO =
> as.integer(0))$AB
> > AB.ch
> >
> > 
> >
> > and you are good to go.
> >
> > You should always do something  as described above when you need to pass
> character arguments to Fortran code.
> >
> > All of this was tested and run on macOS using the CRAN version of R.
> >
> > Berend Hasselman
> >
> >> On 11 Sep 2019, at 15:47, Giovanni Petris  wrote:
> >>
> >> Sorry for cross-posting, but I realized my question might be more
> appropriate for r-devel...
> >>
> >> Thank you,
> >> Giovanni
> >>
> >> 
> >> From: R-help  on behalf of Giovanni
> Petris 
> >> Sent: Tuesday, September 10, 2019 16:44
> >> To: r-h...@r-project.org
> >> Subject: [R] Calling a LAPACK subroutine from R
> >>
> >> Hello R-helpers!
> >>
> >> I am trying to call a LAPACK subroutine directly from my R code using
> .Fortran(), but R cannot find the symbol name. How can I register/load the
> appropriate library?
> >>
> >>> ### AR(1) Precision matrix
> >>> n <- 4L
> >>> phi <- 0.64
> >>> AB <- matrix(0, 2, n)
> >>> AB[1, ] <- 

Re: [Rd] Fw: Calling a LAPACK subroutine from R

[Göran Broström]

Berend,

I do not think this works with gfortran 7+. I am calling the BLAS 
subroutine dgemv from Fortran code in my package eha, and the check 
(with R-devel) gives:


gmlfun.f:223:1: warning: type of ‘dgemv’ does not match original 
declaration [-Wlto-type-mismatch]

  & score, ione)
 ^
/home/gobr0002/R/src/R-devel/include/R_ext/BLAS.h:107:1: note: type 
mismatch in parameter 12

 F77_NAME(dgemv)(const char *trans, const int *m, const int *n,

Type of a Fortran subroutine is matched against type of a C function?! 
My conclusion is that it is impossible to call a BLAS subroutine with a 
character parameter from Fortran code (nowadays). Calling from C code is 
fine, on the other hand(!).


I have recently asked about this on R-pkg-devel, but not received any 
useful answers, and my submission to CRAN is rejected. I solve it by 
making a personal copy of dgemv and changing the character parameter to 
integer, and adding Jack Dongarra, Jeremy Du Croz, Sven Hammarling, and 
Richard Hanson as authors of eha. And a Copyright note, all in the 
DESCRIPTION file. Ugly but what can I do (except rewriting the Fortran 
code in C with f2c)?


Göran

On 2019-09-11 21:38, Berend Hasselman wrote:


The Lapack library is loaded automatically by R itself when it needs it  for 
doing some calculation.
You can force it to do that with a (dummy) solve for example.
Put this at start of your script:


# dummy code to get LAPACK library loaded
X1 <- diag(2,2)
x1 <- rep(2,2)
# X1;x1
z <- solve(X1,x1)


followed by the rest of your script.
You will get a warning (I do) that  "passing a character vector  to .Fortran is not 
portable".
On other systems this may gave fatal errors. This is quick and very dirty. 
Don't do it.

I believe there is a better and much safer way to achieve what you want.
Here goes.

Create a folder (directory) src in the directory where your script resides.
Create a wrapper for "dpbtrf" file in a file xdpbtrf.f that takes an integer 
instead of character


c intermediate for dpbtrf

   SUBROUTINE xDPBTRF( kUPLO, N, KD, AB, LDAB, INFO )

c  .. Scalar Arguments ..
   integer kUPLO
   INTEGER INFO, KD, LDAB, N

c  .. Array Arguments ..
   DOUBLE PRECISION   AB( LDAB, * )

   character UPLO
c convert integer argument to character
   if(kUPLO .eq. 1 ) then
   UPLO = 'L'
   else
   UPLO = 'U'
   endif

   call dpbtrf(UPLO,N,KD,AB,LDAB,INFO)
   return
   end



Instead of a character argument UPLO it takes an integer argument kUPLO.
The meaning should be obvious from the code.

Now create a shell script in the folder of your script to generate a dynamic 
library to be loaded in your script:


# Build a binary dynamic library for accessing Lapack dpbtrf

# syntax checking
  
SONAME=xdpbtrf.so


echo Strict syntax checking
echo --
gfortran -c -fsyntax-only -fimplicit-none -Wall src/*.f || exit 1

LAPACK=$(R CMD config LAPACK_LIBS)
R CMD SHLIB --output=${SONAME} src/*.f ${LAPACK} || exit 1


To load the dynamic library xdpbtrf.so  change your script into this


dyn.load("xdpbtrf.so")
n <- 4L
phi <- 0.64
AB <- matrix(0, 2, n)
AB[1, ] <- c(1, rep(1 + phi^2, n-2), 1)
AB[2, -n] <- -phi
round(AB, 3)

AB.ch <- .Fortran("xdpbtrf", kUPLO=1L, N = as.integer(n),
 KD = 1L, AB = AB, LDAB = 2L, INFO = 
as.integer(0))$AB
AB.ch



and you are good to go.

You should always do something  as described above when you need to pass 
character arguments to Fortran code.

All of this was tested and run on macOS using the CRAN version of R.

Berend Hasselman


On 11 Sep 2019, at 15:47, Giovanni Petris  wrote:

Sorry for cross-posting, but I realized my question might be more appropriate 
for r-devel...

Thank you,
Giovanni


From: R-help  on behalf of Giovanni Petris 

Sent: Tuesday, September 10, 2019 16:44
To: r-h...@r-project.org
Subject: [R] Calling a LAPACK subroutine from R

Hello R-helpers!

I am trying to call a LAPACK subroutine directly from my R code using 
.Fortran(), but R cannot find the symbol name. How can I register/load the 
appropriate library?


### AR(1) Precision matrix
n <- 4L
phi <- 0.64
AB <- matrix(0, 2, n)
AB[1, ] <- c(1, rep(1 + phi^2, n-2), 1)
AB[2, -n] <- -phi
round(AB, 3)

  [,1]  [,2]  [,3] [,4]
[1,]  1.00  1.41  1.411
[2,] -0.64 -0.64 -0.640


### Cholesky factor
AB.ch <- .Fortran("dpbtrf", UPLO = 'L', N = as.integer(n),

+  KD = 1L, AB = AB, LDAB = 2L, INFO = as.integer(0))$AB
Error in .Fortran("dpbtrf", UPLO = "L", N = as.integer(n), KD = 1L, AB = AB,  :
  Fortran symbol name "dpbtrf" not in load table

sessionInfo()

R version 3.6.0 (2019-04-26)
Platform: x86_64-apple-darwin18.5.0 (64-bit)
Running under: macOS Mojave 10.14.6

Matrix products: default
BLAS/LAPACK: /usr/local/Cellar/openblas/0.3.6_1/lib/libopenblasp-r0.3.6.dylib

locale:
[1] 

Re: [Rd] R-intro: Appendix A: attach position

[Kurt Hornik]

> Suharto Anggono Suharto Anggono via R-devel writes:

Thanks: fixed now in the trunk.

Best
-k

> In "An Introduction to R", in "Appendix A  A sample session", in the part on 
> Michelson data, information for
> attach(mm)
> is
> Make the data frame visible at position 3 (the default).

> In fact, the 'attach' is at position 2.

> __
> 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

Re: [Rd] Fw: Calling a LAPACK subroutine from R

[Berend Hasselman]

The Lapack library is loaded automatically by R itself when it needs it  for 
doing some calculation.
You can force it to do that with a (dummy) solve for example.
Put this at start of your script:


# dummy code to get LAPACK library loaded
X1 <- diag(2,2)
x1 <- rep(2,2)
# X1;x1
z <- solve(X1,x1)


followed by the rest of your script.
You will get a warning (I do) that  "passing a character vector  to .Fortran is 
not portable".
On other systems this may gave fatal errors. This is quick and very dirty. 
Don't do it.

I believe there is a better and much safer way to achieve what you want.
Here goes.

Create a folder (directory) src in the directory where your script resides.
Create a wrapper for "dpbtrf" file in a file xdpbtrf.f that takes an integer 
instead of character


c intermediate for dpbtrf

  SUBROUTINE xDPBTRF( kUPLO, N, KD, AB, LDAB, INFO )

c  .. Scalar Arguments ..
  integer kUPLO
  INTEGER INFO, KD, LDAB, N

c  .. Array Arguments ..
  DOUBLE PRECISION   AB( LDAB, * )

  character UPLO
c convert integer argument to character
  if(kUPLO .eq. 1 ) then
  UPLO = 'L'
  else
  UPLO = 'U'
  endif

  call dpbtrf(UPLO,N,KD,AB,LDAB,INFO)
  return
  end



Instead of a character argument UPLO it takes an integer argument kUPLO.
The meaning should be obvious from the code.

Now create a shell script in the folder of your script to generate a dynamic 
library to be loaded in your script:


# Build a binary dynamic library for accessing Lapack dpbtrf

# syntax checking
 
SONAME=xdpbtrf.so

echo Strict syntax checking
echo --
gfortran -c -fsyntax-only -fimplicit-none -Wall src/*.f || exit 1

LAPACK=$(R CMD config LAPACK_LIBS)
R CMD SHLIB --output=${SONAME} src/*.f ${LAPACK} || exit 1


To load the dynamic library xdpbtrf.so  change your script into this


dyn.load("xdpbtrf.so")
n <- 4L
phi <- 0.64
AB <- matrix(0, 2, n)
AB[1, ] <- c(1, rep(1 + phi^2, n-2), 1)
AB[2, -n] <- -phi
round(AB, 3)

AB.ch <- .Fortran("xdpbtrf", kUPLO=1L, N = as.integer(n),
KD = 1L, AB = AB, LDAB = 2L, INFO = 
as.integer(0))$AB
AB.ch



and you are good to go.

You should always do something  as described above when you need to pass 
character arguments to Fortran code.

All of this was tested and run on macOS using the CRAN version of R.

Berend Hasselman

> On 11 Sep 2019, at 15:47, Giovanni Petris  wrote:
> 
> Sorry for cross-posting, but I realized my question might be more appropriate 
> for r-devel...
> 
> Thank you,
> Giovanni
> 
> 
> From: R-help  on behalf of Giovanni Petris 
> 
> Sent: Tuesday, September 10, 2019 16:44
> To: r-h...@r-project.org
> Subject: [R] Calling a LAPACK subroutine from R
> 
> Hello R-helpers!
> 
> I am trying to call a LAPACK subroutine directly from my R code using 
> .Fortran(), but R cannot find the symbol name. How can I register/load the 
> appropriate library?
> 
>> ### AR(1) Precision matrix
>> n <- 4L
>> phi <- 0.64
>> AB <- matrix(0, 2, n)
>> AB[1, ] <- c(1, rep(1 + phi^2, n-2), 1)
>> AB[2, -n] <- -phi
>> round(AB, 3)
>  [,1]  [,2]  [,3] [,4]
> [1,]  1.00  1.41  1.411
> [2,] -0.64 -0.64 -0.640
>> 
>> ### Cholesky factor
>> AB.ch <- .Fortran("dpbtrf", UPLO = 'L', N = as.integer(n),
> +  KD = 1L, AB = AB, LDAB = 2L, INFO = as.integer(0))$AB
> Error in .Fortran("dpbtrf", UPLO = "L", N = as.integer(n), KD = 1L, AB = AB,  
> :
>  Fortran symbol name "dpbtrf" not in load table
>> sessionInfo()
> R version 3.6.0 (2019-04-26)
> Platform: x86_64-apple-darwin18.5.0 (64-bit)
> Running under: macOS Mojave 10.14.6
> 
> Matrix products: default
> BLAS/LAPACK: /usr/local/Cellar/openblas/0.3.6_1/lib/libopenblasp-r0.3.6.dylib
> 
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> loaded via a namespace (and not attached):
> [1] compiler_3.6.0 tools_3.6.0
> 
> Thank you in advance for your help!
> 
> Best,
> Giovanni Petris
> 
> 
> 
> --
> Giovanni Petris, PhD
> Professor
> Director of Statistics
> Department of Mathematical Sciences
> University of Arkansas - Fayetteville, AR 72701
> 
> 
> __
> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dhelp=DwICAg=7ypwAowFJ8v-mw8AB-SdSueVQgSDL4HiiSaLK01W8HA=C3DNvy_azplKSvJKgvsgjA=C-MwKl__0xz-98RBbu7QNXJjqWkRr4xp6c0cz9Dck7A=a1vAu3mcXKObTLwP19vOmRPq55h6oQTh_vnS6BEibF0=
> PLEASE do read the posting guide 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.R-2Dproject.org_posting-2Dguide.html=DwICAg=7ypwAowFJ8v-mw8AB-SdSueVQgSDL4HiiSaLK01W8HA=C3DNvy_azplKSvJKgvsgjA=C-MwKl__0xz-98RBbu7QNXJjqWkRr4xp6c0cz9Dck7A=qFGlplF9cOSmnDUvugsPRDn4iZS7v-LuWNAvfY69sbA=
> and provide commented, minimal, 

Re: [Rd] [ALTREP] What is the meaning of the return value of Is_sorted and No_NA function?

[Wang Jiefei]

Hi Gabriel,

Thanks for your answer and future update plan. Somehow this email has been
delayed for a week, so there might be a wired reply from me saying that I
have found the answer from the R source code, it was sent from me last
week. Hopefully, this reply will not cost another week to post:)

As a side note, I like the idea that defining a macro for sortedness, and I
can see why we can only have a binary answer for NO_NA (since the return
value is actually bool). For making the code more readable, and for
possibly working with the future R release, is it possible to define a
macro for NO_NA function in RInternal.h? So if there is any change in NO_NA
function, there is no need to modify the code. Also, the code can be more
readable by doing that.

Best,
Jiefei

On Wed, Sep 11, 2019 at 1:58 PM Gabriel Becker 
wrote:

> Hi Jiefei,
>
> The meanings of the return values for sortedness can be found in
> RInternals.h, and are as follows:
>
> /* ALTREP sorting support */
> enum {SORTED_DECR_NA_1ST = -2,
>   SORTED_DECR = -1,
>   UNKNOWN_SORTEDNESS = INT_MIN, /*INT_MIN is NA_INTEGER! */
>   SORTED_INCR = 1,
>   SORTED_INCR_NA_1ST = 2,
>   KNOWN_UNSORTED = 0};
>
> The default value there is NA_INTEGER (ie INT_MIN), indicating that there
> is no sortedness information.
>
> Currently, *_NO_NA  effectively return a boolean, (even though the actual
> return value is int). This can be seen in the method we provide for compact
> sequences in altclasses.c:
>
>
> static int compact_intseq_No_NA(SEXP x)
> {
> #ifdef COMPACT_INTSEQ_MUTABLE
> /* If the vector has been expanded it may have been modified. */
> if (COMPACT_SEQ_EXPANDED(x) != R_NilValue)
> return FALSE;
> #endif
> return TRUE;
> }
>
> (FALSE is a macro for 0, TRUE is a macro for 1).
>
> Think of the meaning of the return value to No_NA methods as the object's
> answer to the following question
>
> "Are you sure there are zero NAs in your data?"
>
> When it is sure of that, it  says "yes" (returning 1, ie TRUE). When it
> either is sure there are NAs *OR* doesn't have any information about
> whether there are NAs, it says "no" (returning 0, ie FALSE).
>
> Also please note, it is possible there may be another API point in the
> future which asks the object *how many NAs it has.∫ˆ* If that
> materializes, No_NA would just  consume the answer to thatto get the
> binarized version, but again there is nothing like that in there now.
>
> Hope that helps.
>
> Best,
> ~G
>
> On Wed, Sep 11, 2019 at 12:04 AM Wang Jiefei  wrote:
>
>> Hi,
>>
>>
>>
>> I would like to figure out the meaning of the return value of these two
>> functions. Here are the default definitions I find from R source code:
>>
>>
>>
>> static int altreal_Is_sorted_default(SEXP x) { return UNKNOWN_SORTEDNESS;
>> }
>>
>> static int altreal_No_NA_default(SEXP x) { return 0; }
>>
>> I guess the macro *UNKNOWN_SORTEDNESS *in *Is_sorted* and 0 in *No_NA
>> *simply means
>> unknown sorted/NA status of the vector, so R will loop over the vector and
>> find the answer. However, what should we return in these functions to
>> indicate whether the vector has been sorted/ contains NA? My initial guess
>> is 0/1 but since *NA_NA *uses 0 as its default value so it will be
>> ambiguous. Are there any macros to define yes/no return values for these
>> functions? I would appreciate any thought here.
>>
>>
>>
>> Best,
>>
>> Jiefei
>>
>> [[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] [ALTREP] What is the meaning of the return value of Is_sorted and No_NA function?

[Gabriel Becker]

Hi Jiefei,

The meanings of the return values for sortedness can be found in
RInternals.h, and are as follows:

/* ALTREP sorting support */
enum {SORTED_DECR_NA_1ST = -2,
  SORTED_DECR = -1,
  UNKNOWN_SORTEDNESS = INT_MIN, /*INT_MIN is NA_INTEGER! */
  SORTED_INCR = 1,
  SORTED_INCR_NA_1ST = 2,
  KNOWN_UNSORTED = 0};

The default value there is NA_INTEGER (ie INT_MIN), indicating that there
is no sortedness information.

Currently, *_NO_NA  effectively return a boolean, (even though the actual
return value is int). This can be seen in the method we provide for compact
sequences in altclasses.c:


static int compact_intseq_No_NA(SEXP x)
{
#ifdef COMPACT_INTSEQ_MUTABLE
/* If the vector has been expanded it may have been modified. */
if (COMPACT_SEQ_EXPANDED(x) != R_NilValue)
return FALSE;
#endif
return TRUE;
}

(FALSE is a macro for 0, TRUE is a macro for 1).

Think of the meaning of the return value to No_NA methods as the object's
answer to the following question

"Are you sure there are zero NAs in your data?"

When it is sure of that, it  says "yes" (returning 1, ie TRUE). When it
either is sure there are NAs *OR* doesn't have any information about
whether there are NAs, it says "no" (returning 0, ie FALSE).

Also please note, it is possible there may be another API point in the
future which asks the object *how many NAs it has.∫ˆ* If that materializes,
No_NA would just  consume the answer to thatto get the binarized version,
but again there is nothing like that in there now.

Hope that helps.

Best,
~G

On Wed, Sep 11, 2019 at 12:04 AM Wang Jiefei  wrote:

> Hi,
>
>
>
> I would like to figure out the meaning of the return value of these two
> functions. Here are the default definitions I find from R source code:
>
>
>
> static int altreal_Is_sorted_default(SEXP x) { return UNKNOWN_SORTEDNESS; }
>
> static int altreal_No_NA_default(SEXP x) { return 0; }
>
> I guess the macro *UNKNOWN_SORTEDNESS *in *Is_sorted* and 0 in *No_NA
> *simply means
> unknown sorted/NA status of the vector, so R will loop over the vector and
> find the answer. However, what should we return in these functions to
> indicate whether the vector has been sorted/ contains NA? My initial guess
> is 0/1 but since *NA_NA *uses 0 as its default value so it will be
> ambiguous. Are there any macros to define yes/no return values for these
> functions? I would appreciate any thought here.
>
>
>
> Best,
>
> Jiefei
>
> [[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: [Bioc-devel] Troubles with Windows build

[Pages, Herve]

Hi Ulrich,

On 9/11/19 07:38, Ulrich Bodenhofer wrote:
> Dear colleagues,
> 
> I have two issues with the Windows BUILD BIN of our 'msa' package. (to 
> my horror, I figured out that the first problem has existed for quite a 
> while; I am deeply sorry for that!)
> 
> The main problem can be seen on
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_3.10_bioc-2DLATEST_msa_tokay1-2Dbuildbin.html=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Bbc5FnQ1tPzoXMRA0p9nTFzEteGG4DDk4xWg6Ovo96s=aQA86FP5YPxBCHegE31FVVctmIAN1B4A43LLRj-UvKk=
>  
> 
> It seems that something is wrong with the file 
> src/ClustalOmega/src/exceptions4c/e4c_lite.o. Since it does not seem to 
> me that e4c_lite.c is freshly compiled (I may be wrong in this point) 
> and based on a StackOverflow post 
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_questions_54797615_trouble-2Ddownloading-2Dr-2Dpackage-2Do-2Dfile-2Dformat-2Dnot-2Drecognized=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Bbc5FnQ1tPzoXMRA0p9nTFzEteGG4DDk4xWg6Ovo96s=xQ9kThPXTO4xy8JqGDzmoDzcEULvnqEHpjjW0CbKa9g=
>  
> ), I have the impression that the build system might still have an on 
> old version of some .o files. I can hardly imagine this, but it would 
> explain the problem. To be frank, I am quite lost and have no idea what 
> else could be the problem. Any hint is gratefully appreciated!

On our Windows servers the BUILD BIN stage uses the following compound 
command to produce the binary package:

   rm -rf msa.buildbin-libdir && mkdir msa.buildbin-libdir && 
C:\Users\biocbuild\bbs-3.10-bioc\R\bin\R.exe CMD INSTALL 
--merge-multiarch --build --library=msa.buildbin-libdir msa_1.17.0.tar.gz

(Note that you can see this command at the top of the details page for 
this stage).

As you can see, we use --library=msa.buildbin-libdir to install to a 
freshly created folder created at the beginning of the command. Command 
components are chained with && to make sure that it will not proceed 
further if one component fails so the 'R CMD INSTALL' component won't 
run if for example 'rm -rf msa.buildbin-libdir' fails which guarantees 
that we start with a fresh folder.

I think this looks indeed like a leftover/stale .o file but I think the 
file is in the source tarball produced by the BUILD stage 
(msa_1.17.0.tar.gz). If you look at your cleanup.win script, it doesn't 
remove the stuff in src/ClustalOmega/src/exceptions4c/ so I think what 
happens is that at the end of compilation the folder contains all the 
*.o files for the 64-bit arch and these files get included in the source 
tarball. Then the BUILD BIN stage choke on these files during the 
'install for i386' step.

'diff cleanup cleanup.win' actually shows many differences between the 2 
scripts. You might want to review them closely as it looks like some of 
them are not intended.

> 
> The second issue: the 'msa' package integrates multiple other open 
> source packages in one shared library. In order to to so, it uses the 
> 'ar' tool to compile static libraries of the individual packages and 
> then combines them to a shared library.

AFAIK, 'ar' stands for "archive". It doesn't compile anything, it only 
bundles things in one single *static* (not shared) library (.a file).

> This has always worked fine, and 
> on the Bioconductor build servers, too. Now it seems I can no longer run 
> the binary build on my Windows system. My Windows makefiles refer to the 
> '$(AR)' variable, but it seems this variable is not correctly expanded 
> to the actual location of the 'ar' tool (in Rtools 35, it is not in 
> Rtools\bin, but in Rtools\mingw_(32|64)\bin) . Any thoughts on this?

Don't know. You might want to try SO or R-devel for this one.

Cheers,
H.

> 
> Thank you very much in advance and best regards,
> Ulrich
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Bbc5FnQ1tPzoXMRA0p9nTFzEteGG4DDk4xWg6Ovo96s=Rio_ObsWJj-17QELDDBmNSEiJ8lxupnodfbXhHgXc5Q=
>  
> 

-- 
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

Re: [R-pkg-devel] OFFICIAL: R-devel check error: package or NAMESPACE load failed, there is no package called broom

[Georgina Anderson]

OFFICIAL
Many thanks Pedro and Hadley 

Just to complete the thread if anyone else experiencing similar problems.  
This package uploaded to CRAN with no problems on second attempt so likely just 
bad timing.
  
Interesting that broom is failing CRAN tests though.  I will keep an eye on 
that as I import it with my package.

Georgie

-Original Message-
From: Aphalo, Pedro J  
Sent: 10 September 2019 15:39
To: Hadley Wickham ; Georgina Anderson 

Cc: r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] OFFICIAL: R-devel check error: package or NAMESPACE 
load failed, there is no package called broom

It seems that 'broom' itself is failing tests on CRAN under Windows oldrel, and 
this may cause it to be missing from the R installation running tests on CRAN.

See:
https://cran.r-project.org/web/checks/check_results_broom.html

Pedro.

--

Pedro J. Aphalo
University Lecturer, Principal Investigator Organismal and Evolutionary Biology 
(OEB) Research Programme University of Helsinki Finland


> -Original Message-
> From: R-package-devel  On 
> Behalf Of Hadley Wickham
> Sent: 10 September 2019 15:16
> To: Georgina Anderson 
> Cc: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] OFFICIAL: R-devel check error: package or 
> NAMESPACE load failed, there is no package called broom
> 
> This works for me locally too, so I'd recommend trying win-devel again.
> Sometimes you catch it in an inconsistent state and your check fails 
> for reasons unrelated to your package.
> 
> Hadley
> 
> On Sat, Sep 7, 2019 at 3:50 PM Georgina Anderson 
>  wrote:
> >
> > OFFICIAL
> >
> > Hi
> >
> > Any help with the following update to my package PHEindicatormethods
> would be appreciated.
> >
> > I have made a very minor change to the package to fix dependencies 
> > on the
> tidyr:nest() function as tidyr v 1.0.0 is due to be released with 
> breaking changes on 9th September.
> > The version I am trying to upload to CRAN is 1.1.5 available here:
> > https://github.com/PublicHealthEngland/PHEindicatormethods
> >
> >
> > When I run devtools::check_win_devel locally (Windows 10 laptop, R 
> > 3.6.1, rStudio 1.2.1335) it passes with no NOTES, ERRORS or WARNINGS 
> > (locally it also passes devtools::check_win on release and 
> > oldrelease and devtools::check_rhub)
> >
> > When I submit to CRAN I have been notified that package
> PHEindicatormethods_1.1.5.tar.gz does not pass the incoming checks 
> automatically, signposting failing pre-tests on Windows:
> >
> > * using R Under development (unstable) (2019-09-02 r77130)
> >
> > * using platform: x86_64-w64-mingw32 (64-bit)
> >
> > * using session charset: ISO8859-1
> >
> >
> >
> > This is the log file available for 7 days:
> > https://win-builder.r-project.org/incoming_pretest/PHEindicatormetho
> > ds _1.1.5_20190905_224346/Windows/00check.log
> >
> > Below are two sections from the log that show the errors:
> >
> >
> > > library('PHEindicatormethods')
> >
> > Error: package or namespace load failed for 'PHEindicatormethods' in
> loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
> >
> >  there is no package called 'broom'
> >
> > Execution halted
> >
> > ** running examples for arch 'x64' ... ERROR
> >
> > Running examples in 'PHEindicatormethods-Ex.R' failed
> >
> > The error occurred in:
> >
> > R Under development (unstable) (2019-09-02 r77130) -- "Unsuffered
> Consequences"
> >
> > Copyright (C) 2019 The R Foundation for Statistical Computing
> >
> > Platform: x86_64-w64-mingw32/x64 (64-bit)
> >
> >
> > Error: processing vignette 'WorkedExamples_phe_sii.Rmd' failed with
> diagnostics:
> >
> > package or namespace load failed for 'PHEindicatormethods' in
> loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
> >
> >  there is no package called 'broom'
> >
> > --- failed re-building 'WorkedExamples_phe_sii.Rmd'
> >
> > SUMMARY: processing the following file failed:
> >
> >   'WorkedExamples_phe_sii.Rmd'
> >
> > Error: Vignette re-building failed.
> >
> > Execution halted
> >
> > I have checked the broom package and its upstream dependency on 
> > generics -
> I notice the tidy() function was moved from broom to generics a while 
> back but this was before I submitted the current version (1.1.3) of my 
> package to CRAN so not sure this can be the problem, although one of 
> my functions does reference broom::tidy().  The evidence seems to 
> point to changes in R-devel causing something in my package to break 
> but without being able to reproduce the errors seen by CRAN I'm finding it 
> difficult to pinpoint the problem.
> >
> > Thanks
> > Georgie
> >
> >
> >
> *
> *
> >  The information contained in the EMail and any attachments is 
> > confidential and intended solely and for the attention and use of 
> > the named addressee(s). It may not be disclosed to any other person 
> > without the express authority of Public Health England, or the 
> > 

[Bioc-devel] Bioconductor Developers Forum - Thursday 19th September

[Mike Smith]

Dear all,

The next Bioconductor Developers' Forum is scheduled for Thursday 19th
September at 09:00 PDT/ 12:00 EDT / 18:00 CEST

We will be using BlueJeans and  the meeting can be joined via:

https://bluejeans.com/645510122?src=join_info (Meeting ID: 645 510 122)

More details can be found in the #developers-forum channel of the
Bioconductor Slack (https://bioc-community.herokuapp.com/)

Best wishes,

Mike

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Failing to build vignette because of problems with ImageMagick

[Pages, Herve]

New to me too. But it seems that knitr suggests magick, which itself has

   SystemRequirements: ImageMagick++: ImageMagick-c++-devel (rpm) or 
libmagick++-dev (deb)

Don't know when this knitr dep on magick was introduced tough... Bummer!

H.

On 9/11/19 06:13, Kasper Daniel Hansen wrote:
> Yeah, does this imply that the render operation uses (or tries to use) 
> ImageMagick? That's news to me, but I am not following this closely.
> 
> On Wed, Sep 11, 2019 at 5:21 AM Pages, Herve  > wrote:
> 
> On 9/11/19 00:50, Vincent Carey wrote:
>  > I seem to be running into a similar problem with BiocOncoTK on
> windows
>  >
>  > The build report for tokay1 shows:
>  >
>  > Loading required package: ontologyIndex
>  > Invalid Parameter - /figure-html
>  > Warning in shell(paste(c(cmd, args), collapse = " ")) :
>  >    'convert "BiocOncoTK_files/figure-html/lkgbm-1.png" -trim
>  > "BiocOncoTK_files/figure-html/lkgbm-1.png"' execution failed with
>  > error code 4
>  > Invalid Parameter - /figure-html
>  >
>  > The figure code is introduced with ```{r
> lkgbm,fig=TRUE,message=FALSE}
>  > ... the 'convert' process is not requested by me
>  >
>  > Is the fig=TRUE problematic for windows?  It seems unnecessary.
> 
> Not sure what's going on. A few observations:
> 
> a) About 500 software packages use fig=TRUE.
> 
> b) The convert warning is just a warning. The actual error in the case
> of BiocOncoTK is:
> 
>     Error: processing vignette 'BiocOncoTK.Rmd' failed with diagnostics:
> argument is of length zero
> 
>     Note that the ndexr vignette also fails with this error on tokay1
> only but it doesn't have the convert warning (this vignette does not
> use
> 'fig' at all). So it's not clear to me that the "argument is of length
> zero" error is related to the convert warning.
> 
> c) The devel build report shows the convert warning for 4 other
> packages
> (CAGEfightR, CATALYST, CTDquerier, specL) but each of them actually
> fails with a different error message:
> 
>     CAGEfightR:
>       colData(object1) not identical to colData(object2)
> 
>     CATALYST:
>       no slot of name "reducedDims" for this object of class "daFrame"
> 
>     CTDquerier:
>       bfcadd() failed; see warnings()
> 
>     specL:
>       pandoc.exe: Out of memory
> 
>     These errors don't seem related to the convert warning either.
> 
> So I'm wondering: could it be that the convert warning is actually
> common but we generally don't see it because 'R CMD build' doesn't
> report warnings? And that we just happen to see the warning when 'R CMD
> build' fails to build a vignette.
> 
> We'll investigate more.
> 
> H.
> 
> 
>  >
>  > On Tue, Sep 10, 2019 at 11:35 AM Christian Mertes
> mailto:mer...@in.tum.de>> wrote:
>  >
>  >> Thanks a lot for the info! So from my understanding we dont use any
>  >> trimming or editing function from ImageMagick directly. I think
> this is
>  >> rather knitr based since we just include png files in the vignette.
>  >>
>  >> I guess it was an hickup since now the error is gone over night.
>  >>
>  >> Best regards,
>  >>
>  >> Christian
>  >>
>  >> On 9/9/19 4:34 PM, Kasper Daniel Hansen wrote:
>  >>> You don't declare any systems requirements for ImageMagick
> (doing so
>  >>> will probably not solve your problem, but you really should).
>  >>>
>  >>> Alternatively you could look into using the tools provided by the
>  >>> magick package, which wraps ImageMagick.
>  >>>
>  >>> But it looks like you're editing PNG files for your vignette. I
> would
>  >>> really recommend not doing so. It introduces a system
> dependency which
>  >>> is just going to increase headaches on your end, for (perhaps)
> no real
>  >>> tangible benefits. If you're trimming PNGs, you should be able to
>  >>> achieve the same effect when using the png device(s) in R, and that
>  >>> will make everything more portable anyway.
>  >>>
>  >>> On Mon, Sep 9, 2019 at 9:42 AM Christian Mertes
> mailto:mer...@in.tum.de>
>  >>> >> wrote:
>  >>>
>  >>>      Dear BioC team,
>  >>>
>  >>>      I just noticed that our package is failing on the
> bioconductor build
>  >>>      system during the build of the vignette on Windows and on
> MacOS
>  >>>      platforms.
>  >>>
>  >>>      From the error I would guess its a problem with the
> installation
>  >>>      of the
>  >>>      ImageMagick package. Please correct me if Im wrong.
>  >>>
>  >>>      It goes through on travis and appveyor. Any suggestions?
>  >>>
>  >>>      Here are some links to the build logs:
>  >>>
> 

Re: [Bioc-devel] RGL warning

[Shepherd, Lori]

Ideally yes all ERROR/WARNING/NOTES should be cleaned up.  Depending on the 
NOTES/WARNINGS some may be out of your control.  You could open a discussion 
with your reviewer on your open submission for BioTIP to see if there could be 
an exception or what else could be done about it.   
https://github.com/Bioconductor/Contributions/issues/1220



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 Zhezhen Wang 

Sent: Wednesday, September 11, 2019 10:49 AM
To: Kasper Daniel Hansen 
Cc: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] RGL warning

Thanks, do we need to solve all the warnings?

Zhezhen

From: Kasper Daniel Hansen 
Sent: Wednesday, September 11, 2019 8:12 AM
To: Zhezhen Wang 
Cc: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] RGL warning

GLX is a module for X11. You need that module installed in whatever X11 
installation you have. My understanding (which is weak) is that GLX is a 
standard module so it is weird it is missing.

On Tue, Sep 10, 2019 at 12:39 PM Zhezhen Wang 
mailto:zhez...@uchicago.edu>> wrote:
Hi

I am having the following warnings and not sure what to update.

Warning in rgl.init(initValue, onlyNULL) :
  RGL: GLX extension missing on server
Warning: 'rgl_init' failed, running with rgl.useNULL = TRUE

The package github link is here : https://github.com/xyang2uchicago/BioTIP

Zhezhen

[[alternative HTML version deleted]]

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


--
Best,
Kasper

[[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.
[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Pages, Herve]

The unique seqnames is what we call the seqlevels. So just:

   as(seqinfo(bsgenome)[seqlevels(grl)], "GRanges")

H.

On 9/11/19 07:42, Michael Lawrence wrote:
> So why not just do:
> 
> as(seqinfo(bsgenome)[unique(unlist(seqnames(grl)))], "GRanges")
> 
> Michael
> 
> On Wed, Sep 11, 2019 at 5:55 AM Bhagwat, Aditya
>  wrote:
>>
>> Thanks Michael,
>>
>> The important detail is that I want to plot the relevant chromosomes only
>>
>>  relevant_chromosomes <- GenomeInfoDb::seqnames(grangeslist)  %>%
>>  S4Vectors::runValue() %>%
>>  Reduce(union, .) %>%
>>  unique()
>>
>>  genomeranges <- GenomeInfoDb::seqinfo(grangeslist) %>%
>>  as('GRanges') %>%
>> (function(gr){
>> gr [ as.character(GenomeInfoDb::seqnames(gr)) %in%
>>  relevant_chromosomes ]
>> })
>>
>>  kp <- karyoploteR::plotKaryotype(genomeranges)
>>  karyoploteR::kpPlotRegions(kp, grangeslist) # grangeslist contains 
>> crispr target sites
>>
>>
>> And, this process required as("GRanges")
>>
>>  #' Convert BSgenome into GRanges
>>  #' @param from BSgenome, e.g. BSgenome.Mmusculus.UCSC.mm10::Mmusculus
>>  #' @examples
>>  #' require(magrittr)
>>  #' BSgenome.Mmusculus.UCSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
>>  #' as('GRanges')
>>  #' @importClassesFrom BSgenome BSgenome
>>  #' @export
>>  methods::setAs( "BSgenome",
>>  "GRanges",
>>  function(from)  from %>%
>>  GenomeInfoDb::seqinfo() %>%
>>  as('GRanges'))
>>
>> Thankyou for feedback,
>>
>> Aditya
>>
>> 
>> From: Michael Lawrence [lawrence.mich...@gene.com]
>> Sent: Wednesday, September 11, 2019 2:31 PM
>> To: Bhagwat, Aditya
>> Cc: Pages, Herve; bioc-devel@r-project.org
>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>> BiocGenerics (and others)?
>>
>> I'm pretty surprised that the karyoploteR package does not accept a
>> Seqinfo since it is plotting chromosomes. But again, please consider
>> just doing as(seqinfo(bsgenome), "GRanges").
>>
>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>>  wrote:
>>>
>>> Hi Herve,
>>>
>>> Thank you for your responses.
>>>  From your response, it is clear that the vcountPDict use case does not 
>>> need a BSgenome -> GRanges coercer.
>>>
>>> The karyoploteR use case still requires it, though, to allow plotting of 
>>> only the chromosomal BSgenome portions:
>>>
>>>  chromranges <- as(bsegenome, "GRanges")
>>>  kp <- karyoploteR::plotKaryotype(chromranges)
>>>  karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>>
>>> Or do you see any alternative for this purpose too?
>>>
>>> Aditya
>>>
>>> 
>>> From: Pages, Herve [hpa...@fredhutch.org]
>>> Sent: Wednesday, September 11, 2019 12:24 PM
>>> To: Bhagwat, Aditya; bioc-devel@r-project.org
>>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>>> BiocGenerics (and others)?
>>>
>>> Hi Aditya,
>>>
>>> On 9/11/19 01:31, Bhagwat, Aditya wrote:
 Hi Herve,


   > It feels that a coercion method from BSgenome to GRanges should
 rather be defined in the BSgenome package itself.

 :-)


   > Patch/PR welcome on GitHub.

 Owkies. What pull/fork/check/branch protocol to be followed?


   > Is this what you have in mind for this coercion?
   > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")

 Yes.

 Perhaps also useful to share the wider context, allowing your and others
 feedback for improved software design.
 I wanted to subset a
 BSgenome
 (without the _random or _unassigned), but Lori explained this is not
 possible.
 

 Instead Lori suggested to coerce a BSgenome into a GRanges
 ,
 which is a useful solution, but for which currently no exported S4
 method exists
 

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Pages, Herve]

Or more accurately:

   as(seqinfo(bsgenome)[seqlevelsInUse(grl)], "GRanges")

since not all seqlevels are necessarily "in use" (i.e. not necessarily 
represented in seqnames(grl)).

H.

On 9/11/19 08:26, Hervé Pagès wrote:
> The unique seqnames is what we call the seqlevels. So just:
> 
>    as(seqinfo(bsgenome)[seqlevels(grl)], "GRanges")
> 
> H.
> 
> On 9/11/19 07:42, Michael Lawrence wrote:
>> So why not just do:
>>
>> as(seqinfo(bsgenome)[unique(unlist(seqnames(grl)))], "GRanges")
>>
>> Michael
>>
>> On Wed, Sep 11, 2019 at 5:55 AM Bhagwat, Aditya
>>  wrote:
>>>
>>> Thanks Michael,
>>>
>>> The important detail is that I want to plot the relevant chromosomes 
>>> only
>>>
>>>  relevant_chromosomes <- GenomeInfoDb::seqnames(grangeslist)  %>%
>>>  S4Vectors::runValue() %>%
>>>  Reduce(union, .) %>%
>>>  unique()
>>>
>>>  genomeranges <- GenomeInfoDb::seqinfo(grangeslist) %>%
>>>  as('GRanges') %>%
>>>     (function(gr){
>>>     gr [ as.character(GenomeInfoDb::seqnames(gr)) 
>>> %in%
>>>  relevant_chromosomes ]
>>>     })
>>>
>>>  kp <- karyoploteR::plotKaryotype(genomeranges)
>>>  karyoploteR::kpPlotRegions(kp, grangeslist) # grangeslist 
>>> contains crispr target sites
>>>
>>>
>>> And, this process required as("GRanges")
>>>
>>>  #' Convert BSgenome into GRanges
>>>  #' @param from BSgenome, e.g. 
>>> BSgenome.Mmusculus.UCSC.mm10::Mmusculus
>>>  #' @examples
>>>  #' require(magrittr)
>>>  #' BSgenome.Mmusculus.UCSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
>>>  #' as('GRanges')
>>>  #' @importClassesFrom BSgenome BSgenome
>>>  #' @export
>>>  methods::setAs( "BSgenome",
>>>  "GRanges",
>>>  function(from)  from %>%
>>>  GenomeInfoDb::seqinfo() %>%
>>>  as('GRanges'))
>>>
>>> Thankyou for feedback,
>>>
>>> Aditya
>>>
>>> 
>>> From: Michael Lawrence [lawrence.mich...@gene.com]
>>> Sent: Wednesday, September 11, 2019 2:31 PM
>>> To: Bhagwat, Aditya
>>> Cc: Pages, Herve; bioc-devel@r-project.org
>>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>>> BiocGenerics (and others)?
>>>
>>> I'm pretty surprised that the karyoploteR package does not accept a
>>> Seqinfo since it is plotting chromosomes. But again, please consider
>>> just doing as(seqinfo(bsgenome), "GRanges").
>>>
>>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>>>  wrote:

 Hi Herve,

 Thank you for your responses.
  From your response, it is clear that the vcountPDict use case does 
 not need a BSgenome -> GRanges coercer.

 The karyoploteR use case still requires it, though, to allow 
 plotting of only the chromosomal BSgenome portions:

  chromranges <- as(bsegenome, "GRanges")
  kp <- karyoploteR::plotKaryotype(chromranges)
  karyoploteR::kpPlotRegions(kp, crispr_target_sites)

 Or do you see any alternative for this purpose too?

 Aditya

 
 From: Pages, Herve [hpa...@fredhutch.org]
 Sent: Wednesday, September 11, 2019 12:24 PM
 To: Bhagwat, Aditya; bioc-devel@r-project.org
 Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
 BiocGenerics (and others)?

 Hi Aditya,

 On 9/11/19 01:31, Bhagwat, Aditya wrote:
> Hi Herve,
>
>
>   > It feels that a coercion method from BSgenome to GRanges should
> rather be defined in the BSgenome package itself.
>
> :-)
>
>
>   > Patch/PR welcome on GitHub.
>
> Owkies. What pull/fork/check/branch protocol to be followed?
>
>
>   > Is this what you have in mind for this coercion?
>   > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>
> Yes.
>
> Perhaps also useful to share the wider context, allowing your and 
> others
> feedback for improved software design.
> I wanted to subset a
> BSgenome
>  
>
> (without the _random or _unassigned), but Lori explained this is not
> possible.
> 
>  
>
>
> Instead Lori suggested to coerce a BSgenome into a GRanges
> 

Re: [Bioc-devel] RGL warning

[Zhezhen Wang]

Thanks, do we need to solve all the warnings?

Zhezhen

From: Kasper Daniel Hansen 
Sent: Wednesday, September 11, 2019 8:12 AM
To: Zhezhen Wang 
Cc: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] RGL warning

GLX is a module for X11. You need that module installed in whatever X11 
installation you have. My understanding (which is weak) is that GLX is a 
standard module so it is weird it is missing.

On Tue, Sep 10, 2019 at 12:39 PM Zhezhen Wang 
mailto:zhez...@uchicago.edu>> wrote:
Hi

I am having the following warnings and not sure what to update.

Warning in rgl.init(initValue, onlyNULL) :
  RGL: GLX extension missing on server
Warning: 'rgl_init' failed, running with rgl.useNULL = TRUE

The package github link is here : https://github.com/xyang2uchicago/BioTIP

Zhezhen

[[alternative HTML version deleted]]

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


--
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Michael Lawrence via Bioc-devel]

So why not just do:

as(seqinfo(bsgenome)[unique(unlist(seqnames(grl)))], "GRanges")

Michael

On Wed, Sep 11, 2019 at 5:55 AM Bhagwat, Aditya
 wrote:
>
> Thanks Michael,
>
> The important detail is that I want to plot the relevant chromosomes only
>
> relevant_chromosomes <- GenomeInfoDb::seqnames(grangeslist)  %>%
> S4Vectors::runValue() %>%
> Reduce(union, .) %>%
> unique()
>
> genomeranges <- GenomeInfoDb::seqinfo(grangeslist) %>%
> as('GRanges') %>%
>(function(gr){
>gr [ as.character(GenomeInfoDb::seqnames(gr)) %in%
> relevant_chromosomes ]
>})
>
> kp <- karyoploteR::plotKaryotype(genomeranges)
> karyoploteR::kpPlotRegions(kp, grangeslist) # grangeslist contains crispr 
> target sites
>
>
> And, this process required as("GRanges")
>
> #' Convert BSgenome into GRanges
> #' @param from BSgenome, e.g. BSgenome.Mmusculus.UCSC.mm10::Mmusculus
> #' @examples
> #' require(magrittr)
> #' BSgenome.Mmusculus.UCSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
> #' as('GRanges')
> #' @importClassesFrom BSgenome BSgenome
> #' @export
> methods::setAs( "BSgenome",
> "GRanges",
> function(from)  from %>%
> GenomeInfoDb::seqinfo() %>%
> as('GRanges'))
>
> Thankyou for feedback,
>
> Aditya
>
> 
> From: Michael Lawrence [lawrence.mich...@gene.com]
> Sent: Wednesday, September 11, 2019 2:31 PM
> To: Bhagwat, Aditya
> Cc: Pages, Herve; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
> I'm pretty surprised that the karyoploteR package does not accept a
> Seqinfo since it is plotting chromosomes. But again, please consider
> just doing as(seqinfo(bsgenome), "GRanges").
>
> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>  wrote:
> >
> > Hi Herve,
> >
> > Thank you for your responses.
> > From your response, it is clear that the vcountPDict use case does not need 
> > a BSgenome -> GRanges coercer.
> >
> > The karyoploteR use case still requires it, though, to allow plotting of 
> > only the chromosomal BSgenome portions:
> >
> > chromranges <- as(bsegenome, "GRanges")
> > kp <- karyoploteR::plotKaryotype(chromranges)
> > karyoploteR::kpPlotRegions(kp, crispr_target_sites)
> >
> > Or do you see any alternative for this purpose too?
> >
> > Aditya
> >
> > 
> > From: Pages, Herve [hpa...@fredhutch.org]
> > Sent: Wednesday, September 11, 2019 12:24 PM
> > To: Bhagwat, Aditya; bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> > BiocGenerics (and others)?
> >
> > Hi Aditya,
> >
> > On 9/11/19 01:31, Bhagwat, Aditya wrote:
> > > Hi Herve,
> > >
> > >
> > >  > It feels that a coercion method from BSgenome to GRanges should
> > > rather be defined in the BSgenome package itself.
> > >
> > > :-)
> > >
> > >
> > >  > Patch/PR welcome on GitHub.
> > >
> > > Owkies. What pull/fork/check/branch protocol to be followed?
> > >
> > >
> > >  > Is this what you have in mind for this coercion?
> > >  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
> > >
> > > Yes.
> > >
> > > Perhaps also useful to share the wider context, allowing your and others
> > > feedback for improved software design.
> > > I wanted to subset a
> > > BSgenome
> > > (without the _random or _unassigned), but Lori explained this is not
> > > possible.
> > > 
> > >
> > > Instead Lori suggested to coerce a BSgenome into a GRanges
> > > ,
> > > which is a useful solution, but for which currently no exported S4
> > > method exists
> > > 
> > > So I defined an S4 coercer in my multicrispr package, making sure to
> > > 

[Bioc-devel] Troubles with Windows build

[Ulrich Bodenhofer]

Dear colleagues,

I have two issues with the Windows BUILD BIN of our 'msa' package. (to 
my horror, I figured out that the first problem has existed for quite a 
while; I am deeply sorry for that!)


The main problem can be seen on

   
http://bioconductor.org/checkResults/3.10/bioc-LATEST/msa/tokay1-buildbin.html

It seems that something is wrong with the file 
src/ClustalOmega/src/exceptions4c/e4c_lite.o. Since it does not seem to 
me that e4c_lite.c is freshly compiled (I may be wrong in this point) 
and based on a StackOverflow post 
(https://stackoverflow.com/questions/54797615/trouble-downloading-r-package-o-file-format-not-recognized), 
I have the impression that the build system might still have an on old 
version of some .o files. I can hardly imagine this, but it would 
explain the problem. To be frank, I am quite lost and have no idea what 
else could be the problem. Any hint is gratefully appreciated!


The second issue: the 'msa' package integrates multiple other open 
source packages in one shared library. In order to to so, it uses the 
'ar' tool to compile static libraries of the individual packages and 
then combines them to a shared library. This has always worked fine, and 
on the Bioconductor build servers, too. Now it seems I can no longer run 
the binary build on my Windows system. My Windows makefiles refer to the 
'$(AR)' variable, but it seems this variable is not correctly expanded 
to the actual location of the 'ar' tool (in Rtools 35, it is not in 
Rtools\bin, but in Rtools\mingw_(32|64)\bin) . Any thoughts on this?


Thank you very much in advance and best regards,
Ulrich

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

[Rd] Fw: Calling a LAPACK subroutine from R

[Giovanni Petris]

Sorry for cross-posting, but I realized my question might be more appropriate 
for r-devel...

Thank you,
Giovanni


From: R-help  on behalf of Giovanni Petris 

Sent: Tuesday, September 10, 2019 16:44
To: r-h...@r-project.org
Subject: [R] Calling a LAPACK subroutine from R

Hello R-helpers!

I am trying to call a LAPACK subroutine directly from my R code using 
.Fortran(), but R cannot find the symbol name. How can I register/load the 
appropriate library?

> ### AR(1) Precision matrix
> n <- 4L
> phi <- 0.64
> AB <- matrix(0, 2, n)
> AB[1, ] <- c(1, rep(1 + phi^2, n-2), 1)
> AB[2, -n] <- -phi
> round(AB, 3)
  [,1]  [,2]  [,3] [,4]
[1,]  1.00  1.41  1.411
[2,] -0.64 -0.64 -0.640
>
> ### Cholesky factor
> AB.ch <- .Fortran("dpbtrf", UPLO = 'L', N = as.integer(n),
+  KD = 1L, AB = AB, LDAB = 2L, INFO = as.integer(0))$AB
Error in .Fortran("dpbtrf", UPLO = "L", N = as.integer(n), KD = 1L, AB = AB,  :
  Fortran symbol name "dpbtrf" not in load table
> sessionInfo()
R version 3.6.0 (2019-04-26)
Platform: x86_64-apple-darwin18.5.0 (64-bit)
Running under: macOS Mojave 10.14.6

Matrix products: default
BLAS/LAPACK: /usr/local/Cellar/openblas/0.3.6_1/lib/libopenblasp-r0.3.6.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

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

Thank you in advance for your help!

Best,
Giovanni Petris



--
Giovanni Petris, PhD
Professor
Director of Statistics
Department of Mathematical Sciences
University of Arkansas - Fayetteville, AR 72701


__
r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dhelp=DwICAg=7ypwAowFJ8v-mw8AB-SdSueVQgSDL4HiiSaLK01W8HA=C3DNvy_azplKSvJKgvsgjA=C-MwKl__0xz-98RBbu7QNXJjqWkRr4xp6c0cz9Dck7A=a1vAu3mcXKObTLwP19vOmRPq55h6oQTh_vnS6BEibF0=
PLEASE do read the posting guide 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.R-2Dproject.org_posting-2Dguide.html=DwICAg=7ypwAowFJ8v-mw8AB-SdSueVQgSDL4HiiSaLK01W8HA=C3DNvy_azplKSvJKgvsgjA=C-MwKl__0xz-98RBbu7QNXJjqWkRr4xp6c0cz9Dck7A=qFGlplF9cOSmnDUvugsPRDn4iZS7v-LuWNAvfY69sbA=
and provide commented, minimal, self-contained, reproducible code.

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

Re: [Bioc-devel] RGL warning

[Kasper Daniel Hansen]

GLX is a module for X11. You need that module installed in whatever X11
installation you have. My understanding (which is weak) is that GLX is a
standard module so it is weird it is missing.

On Tue, Sep 10, 2019 at 12:39 PM Zhezhen Wang  wrote:

> Hi
>
> I am having the following warnings and not sure what to update.
>
> Warning in rgl.init(initValue, onlyNULL) :
>   RGL: GLX extension missing on server
> Warning: 'rgl_init' failed, running with rgl.useNULL = TRUE
>
> The package github link is here : https://github.com/xyang2uchicago/BioTIP
>
> Zhezhen
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Failing to build vignette because of problems with ImageMagick

[Kasper Daniel Hansen]

Yeah, does this imply that the render operation uses (or tries to use)
ImageMagick? That's news to me, but I am not following this closely.

On Wed, Sep 11, 2019 at 5:21 AM Pages, Herve  wrote:

> On 9/11/19 00:50, Vincent Carey wrote:
> > I seem to be running into a similar problem with BiocOncoTK on windows
> >
> > The build report for tokay1 shows:
> >
> > Loading required package: ontologyIndex
> > Invalid Parameter - /figure-html
> > Warning in shell(paste(c(cmd, args), collapse = " ")) :
> >'convert "BiocOncoTK_files/figure-html/lkgbm-1.png" -trim
> > "BiocOncoTK_files/figure-html/lkgbm-1.png"' execution failed with
> > error code 4
> > Invalid Parameter - /figure-html
> >
> > The figure code is introduced with ```{r lkgbm,fig=TRUE,message=FALSE}
> > ... the 'convert' process is not requested by me
> >
> > Is the fig=TRUE problematic for windows?  It seems unnecessary.
>
> Not sure what's going on. A few observations:
>
> a) About 500 software packages use fig=TRUE.
>
> b) The convert warning is just a warning. The actual error in the case
> of BiocOncoTK is:
>
>Error: processing vignette 'BiocOncoTK.Rmd' failed with diagnostics:
> argument is of length zero
>
>Note that the ndexr vignette also fails with this error on tokay1
> only but it doesn't have the convert warning (this vignette does not use
> 'fig' at all). So it's not clear to me that the "argument is of length
> zero" error is related to the convert warning.
>
> c) The devel build report shows the convert warning for 4 other packages
> (CAGEfightR, CATALYST, CTDquerier, specL) but each of them actually
> fails with a different error message:
>
>CAGEfightR:
>  colData(object1) not identical to colData(object2)
>
>CATALYST:
>  no slot of name "reducedDims" for this object of class "daFrame"
>
>CTDquerier:
>  bfcadd() failed; see warnings()
>
>specL:
>  pandoc.exe: Out of memory
>
>These errors don't seem related to the convert warning either.
>
> So I'm wondering: could it be that the convert warning is actually
> common but we generally don't see it because 'R CMD build' doesn't
> report warnings? And that we just happen to see the warning when 'R CMD
> build' fails to build a vignette.
>
> We'll investigate more.
>
> H.
>
>
> >
> > On Tue, Sep 10, 2019 at 11:35 AM Christian Mertes 
> wrote:
> >
> >> Thanks a lot for the info! So from my understanding we dont use any
> >> trimming or editing function from ImageMagick directly. I think this is
> >> rather knitr based since we just include png files in the vignette.
> >>
> >> I guess it was an hickup since now the error is gone over night.
> >>
> >> Best regards,
> >>
> >> Christian
> >>
> >> On 9/9/19 4:34 PM, Kasper Daniel Hansen wrote:
> >>> You don't declare any systems requirements for ImageMagick (doing so
> >>> will probably not solve your problem, but you really should).
> >>>
> >>> Alternatively you could look into using the tools provided by the
> >>> magick package, which wraps ImageMagick.
> >>>
> >>> But it looks like you're editing PNG files for your vignette. I would
> >>> really recommend not doing so. It introduces a system dependency which
> >>> is just going to increase headaches on your end, for (perhaps) no real
> >>> tangible benefits. If you're trimming PNGs, you should be able to
> >>> achieve the same effect when using the png device(s) in R, and that
> >>> will make everything more portable anyway.
> >>>
> >>> On Mon, Sep 9, 2019 at 9:42 AM Christian Mertes  >>> > wrote:
> >>>
> >>>  Dear BioC team,
> >>>
> >>>  I just noticed that our package is failing on the bioconductor
> build
> >>>  system during the build of the vignette on Windows and on MacOS
> >>>  platforms.
> >>>
> >>>  From the error I would guess its a problem with the installation
> >>>  of the
> >>>  ImageMagick package. Please correct me if Im wrong.
> >>>
> >>>  It goes through on travis and appveyor. Any suggestions?
> >>>
> >>>  Here are some links to the build logs:
> >>>
> >>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.riken.jp_checkResults_3.9_bioc-2DLATEST_OUTRIDER_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EwnHWfrov-A-kbkOeSotrFEWVXwIUuSJog3NysTJUnE=NA7UQNLz8lFT9bIMHiFka2iUJDarMgfT0uW36-nO9og=
> >>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_gagneurlab_OUTRIDER=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EwnHWfrov-A-kbkOeSotrFEWVXwIUuSJog3NysTJUnE=lf9cL5c-plgiqIP3Hx6Eht_Ataw3bG3x3rP7gi79flg=
> >>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__ci.appveyor.com_project_c-2Dmertes_OUTRIDER=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EwnHWfrov-A-kbkOeSotrFEWVXwIUuSJog3NysTJUnE=l-gS-eeyNnK7JCEdHKIUQifQoI40TZZXQox80MniKEA=
> >>>
> >>>  Best,
> >>>
> >>>  Christian
> >>>
> >>>  PS: the error message on the bioc build system:
> >>>

Re: [Bioc-devel] Collapsing a GRangesList into a GRanges without loosing names(GRangesList)

[Bhagwat, Aditya]

Oh, that's pretty cool :-)
I knew I was overlooking something!
Thanks Lori

Aditya

From: Shepherd, Lori [lori.sheph...@roswellpark.org]
Sent: Wednesday, September 11, 2019 2:54 PM
To: Bhagwat, Aditya; bioc-devel@r-project.org
Subject: Re: Collapsing a GRangesList into a GRanges without loosing 
names(GRangesList)

In what way are you feeling they loose names?

> grlist <- GenomicRanges::GRangesList( gr1 = GenomicRanges::GRanges('chr1', 
> '1-100',   strand = '-'), gr2 = GenomicRanges::GRanges('chr1', '101-200', 
> strand = '-'))

> names(grlist)
[1] "gr1" "gr2"

> temp = unlist(grlist)
> names(temp)
[1] "gr1" "gr2"

> temp
GRanges object with 2 ranges and 0 metadata columns:
  seqnamesranges strand

  gr1 chr1 1-100  -
  gr2 chr1   101-200  -
  ---
  seqinfo: 1 sequence from an unspecified genome; no seqlengths

> temp["gr1"]
GRanges object with 1 range and 0 metadata columns:
  seqnamesranges strand

  gr1 chr1 1-100  -
  ---
  seqinfo: 1 sequence from an unspecified genome; no seqlengths



The names "gr1" and "gr2"  were preserved. You can see them as the first entry 
in my temp object.



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 Bhagwat, 
Aditya 
Sent: Wednesday, September 11, 2019 8:47 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Collapsing a GRangesList into a GRanges without loosing 
names(GRangesList)

Dear bioc-devel,

When using unlist to collapse a GRangesList into a 
GRanges  one looses 
names(GRangesList).
Since I need a name-preserving collapser, I defined the following in 
multicrispr.
My feedback request is: did I overlook existing similar functionality?

#' Collapse a GRangesList
#' @param grangeslist GenomicRanges::GRangesList
#' @examples
#' # Consider a GRangesList
#' grlist <- GenomicRanges::GRangesList(
#' gr1 = GenomicRanges::GRanges('chr1', '1-100',   strand = '-'),
#' gr2 = GenomicRanges::GRanges('chr1', '101-200', strand = '-'))
#'
#' # unlist() drops names(grlist)
#' unlist(grlist)
#'
#' # collapse() preserves them
#' collapse(grlist)
#'
#' # in a way similar to as.data.frame()
#' as.data.frame(grlist)
#' @export
collapse <- function(grangeslist){
add_series <- function(granges, group_name){
granges$group_name <- group_name;
granges }
S4Vectors::mendoapply(add_series, grangeslist, names(grangeslist)) %>%
unlist() %>%
sort()
}


Aditya

[[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.

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Bhagwat, Aditya]

Thanks Michael, 

The important detail is that I want to plot the relevant chromosomes only

relevant_chromosomes <- GenomeInfoDb::seqnames(grangeslist)  %>% 
S4Vectors::runValue() %>% 
Reduce(union, .) %>% 
unique()

genomeranges <- GenomeInfoDb::seqinfo(grangeslist) %>% 
as('GRanges') %>% 
   (function(gr){
   gr [ as.character(GenomeInfoDb::seqnames(gr)) %in% 
relevant_chromosomes ]
   })

kp <- karyoploteR::plotKaryotype(genomeranges)
karyoploteR::kpPlotRegions(kp, grangeslist) # grangeslist contains crispr 
target sites


And, this process required as("GRanges")

#' Convert BSgenome into GRanges 
#' @param from BSgenome, e.g. BSgenome.Mmusculus.UCSC.mm10::Mmusculus
#' @examples 
#' require(magrittr)
#' BSgenome.Mmusculus.UCSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
#' as('GRanges')
#' @importClassesFrom BSgenome BSgenome
#' @export
methods::setAs( "BSgenome", 
"GRanges", 
function(from)  from %>% 
GenomeInfoDb::seqinfo() %>% 
as('GRanges'))

Thankyou for feedback,

Aditya


From: Michael Lawrence [lawrence.mich...@gene.com]
Sent: Wednesday, September 11, 2019 2:31 PM
To: Bhagwat, Aditya
Cc: Pages, Herve; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

I'm pretty surprised that the karyoploteR package does not accept a
Seqinfo since it is plotting chromosomes. But again, please consider
just doing as(seqinfo(bsgenome), "GRanges").

On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
 wrote:
>
> Hi Herve,
>
> Thank you for your responses.
> From your response, it is clear that the vcountPDict use case does not need a 
> BSgenome -> GRanges coercer.
>
> The karyoploteR use case still requires it, though, to allow plotting of only 
> the chromosomal BSgenome portions:
>
> chromranges <- as(bsegenome, "GRanges")
> kp <- karyoploteR::plotKaryotype(chromranges)
> karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>
> Or do you see any alternative for this purpose too?
>
> Aditya
>
> 
> From: Pages, Herve [hpa...@fredhutch.org]
> Sent: Wednesday, September 11, 2019 12:24 PM
> To: Bhagwat, Aditya; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
> Hi Aditya,
>
> On 9/11/19 01:31, Bhagwat, Aditya wrote:
> > Hi Herve,
> >
> >
> >  > It feels that a coercion method from BSgenome to GRanges should
> > rather be defined in the BSgenome package itself.
> >
> > :-)
> >
> >
> >  > Patch/PR welcome on GitHub.
> >
> > Owkies. What pull/fork/check/branch protocol to be followed?
> >
> >
> >  > Is this what you have in mind for this coercion?
> >  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
> >
> > Yes.
> >
> > Perhaps also useful to share the wider context, allowing your and others
> > feedback for improved software design.
> > I wanted to subset a
> > BSgenome
> > (without the _random or _unassigned), but Lori explained this is not
> > possible.
> > 
> >
> > Instead Lori suggested to coerce a BSgenome into a GRanges
> > ,
> > which is a useful solution, but for which currently no exported S4
> > method exists
> > 
> > So I defined an S4 coercer in my multicrispr package, making sure to
> > properly import the Bsgenome class
> > .
> > Then, after coercing a BSgenome into a GRanges, I can extract the
> > 

Re: [Bioc-devel] Collapsing a GRangesList into a GRanges without loosing names(GRangesList)

[Shepherd, Lori]

In what way are you feeling they loose names?

> grlist <- GenomicRanges::GRangesList( gr1 = GenomicRanges::GRanges('chr1', 
> '1-100',   strand = '-'), gr2 = GenomicRanges::GRanges('chr1', '101-200', 
> strand = '-'))

> names(grlist)
[1] "gr1" "gr2"

> temp = unlist(grlist)
> names(temp)
[1] "gr1" "gr2"

> temp
GRanges object with 2 ranges and 0 metadata columns:
  seqnamesranges strand

  gr1 chr1 1-100  -
  gr2 chr1   101-200  -
  ---
  seqinfo: 1 sequence from an unspecified genome; no seqlengths

> temp["gr1"]
GRanges object with 1 range and 0 metadata columns:
  seqnamesranges strand

  gr1 chr1 1-100  -
  ---
  seqinfo: 1 sequence from an unspecified genome; no seqlengths



The names "gr1" and "gr2"  were preserved. You can see them as the first entry 
in my temp object.



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 Bhagwat, 
Aditya 
Sent: Wednesday, September 11, 2019 8:47 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Collapsing a GRangesList into a GRanges without loosing 
names(GRangesList)

Dear bioc-devel,

When using unlist to collapse a GRangesList into a 
GRanges  one looses 
names(GRangesList).
Since I need a name-preserving collapser, I defined the following in 
multicrispr.
My feedback request is: did I overlook existing similar functionality?

#' Collapse a GRangesList
#' @param grangeslist GenomicRanges::GRangesList
#' @examples
#' # Consider a GRangesList
#' grlist <- GenomicRanges::GRangesList(
#' gr1 = GenomicRanges::GRanges('chr1', '1-100',   strand = '-'),
#' gr2 = GenomicRanges::GRanges('chr1', '101-200', strand = '-'))
#'
#' # unlist() drops names(grlist)
#' unlist(grlist)
#'
#' # collapse() preserves them
#' collapse(grlist)
#'
#' # in a way similar to as.data.frame()
#' as.data.frame(grlist)
#' @export
collapse <- function(grangeslist){
add_series <- function(granges, group_name){
granges$group_name <- group_name;
granges }
S4Vectors::mendoapply(add_series, grangeslist, names(grangeslist)) %>%
unlist() %>%
sort()
}


Aditya

[[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.
[[alternative HTML version deleted]]

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

[Bioc-devel] Collapsing a GRangesList into a GRanges without loosing names(GRangesList)

[Bhagwat, Aditya]

Dear bioc-devel,

When using unlist to collapse a GRangesList into a 
GRanges  one looses 
names(GRangesList).
Since I need a name-preserving collapser, I defined the following in 
multicrispr.
My feedback request is: did I overlook existing similar functionality?

#' Collapse a GRangesList
#' @param grangeslist GenomicRanges::GRangesList
#' @examples
#' # Consider a GRangesList
#' grlist <- GenomicRanges::GRangesList(
#' gr1 = GenomicRanges::GRanges('chr1', '1-100',   strand = '-'),
#' gr2 = GenomicRanges::GRanges('chr1', '101-200', strand = '-'))
#'
#' # unlist() drops names(grlist)
#' unlist(grlist)
#'
#' # collapse() preserves them
#' collapse(grlist)
#'
#' # in a way similar to as.data.frame()
#' as.data.frame(grlist)
#' @export
collapse <- function(grangeslist){
add_series <- function(granges, group_name){
granges$group_name <- group_name;
granges }
S4Vectors::mendoapply(add_series, grangeslist, names(grangeslist)) %>%
unlist() %>%
sort()
}


Aditya

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Michael Lawrence via Bioc-devel]

I'm pretty surprised that the karyoploteR package does not accept a
Seqinfo since it is plotting chromosomes. But again, please consider
just doing as(seqinfo(bsgenome), "GRanges").

On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
 wrote:
>
> Hi Herve,
>
> Thank you for your responses.
> From your response, it is clear that the vcountPDict use case does not need a 
> BSgenome -> GRanges coercer.
>
> The karyoploteR use case still requires it, though, to allow plotting of only 
> the chromosomal BSgenome portions:
>
> chromranges <- as(bsegenome, "GRanges")
> kp <- karyoploteR::plotKaryotype(chromranges)
> karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>
> Or do you see any alternative for this purpose too?
>
> Aditya
>
> 
> From: Pages, Herve [hpa...@fredhutch.org]
> Sent: Wednesday, September 11, 2019 12:24 PM
> To: Bhagwat, Aditya; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
> Hi Aditya,
>
> On 9/11/19 01:31, Bhagwat, Aditya wrote:
> > Hi Herve,
> >
> >
> >  > It feels that a coercion method from BSgenome to GRanges should
> > rather be defined in the BSgenome package itself.
> >
> > :-)
> >
> >
> >  > Patch/PR welcome on GitHub.
> >
> > Owkies. What pull/fork/check/branch protocol to be followed?
> >
> >
> >  > Is this what you have in mind for this coercion?
> >  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
> >
> > Yes.
> >
> > Perhaps also useful to share the wider context, allowing your and others
> > feedback for improved software design.
> > I wanted to subset a
> > BSgenome
> > (without the _random or _unassigned), but Lori explained this is not
> > possible.
> > 
> >
> > Instead Lori suggested to coerce a BSgenome into a GRanges
> > ,
> > which is a useful solution, but for which currently no exported S4
> > method exists
> > 
> > So I defined an S4 coercer in my multicrispr package, making sure to
> > properly import the Bsgenome class
> > .
> > Then, after coercing a BSgenome into a GRanges, I can extract the
> > chromosomes, after properly importing IRanges::`%in%`
> > 
>
> Looks like you don't need to coerce the BSgenome object to GRanges. See
> https://support.bioconductor.org/p/123489/#124581
>
> H.
>
> > Which I can then on end to karyoploteR
> > ,
> > for genome-wide plots of crispr target sites.
> >
> > A good moment also to say thank you to all of you who helped me out, it
> > helps me to make multicrispr fit nicely into the BioC ecosystem.
> >
> > Speeking of BioC design philosophy, can any of you suggest concise and
> > to-the-point reading material to deepen my understanding of the core
> > BioC software design philosophy?
> > I am trying to understand that better (which was the context for asking
> > recently why there are three Vector -> data.frame coercers in S4Vectors
> > )
> >
> > Cheers,
> >
> > Aditya
> >
> >
> >
> >
> > 
> 

Re: [R-pkg-devel] R, BLAS, and FCLEN

[Göran Broström]

A followup question: Is it possible to call a BLAS/LAPACK subroutine, 
where one parameter is character, from FORTRAN (77) code called by 
.Fortran? (No problem "in the past".)


And if yes, how?  Documentation describes calls from C to Fortran and 
vice versa, but not this situation (AFAICS).


Yes, I know that .Fortran is not well seen these days, but my fortran 
code is ancient, from the before-R era, and I would like to leave it as-is.


G,

Den 2019-09-01 kl. 21:46, skrev Göran Broström:



On 2019-08-31 18:47, Göran Broström wrote:
I'm having difficulties updating my package eha: When I run standard 
checks 'at home' everything is fine, but 'CRAN-submissions' reports 
(among other things):


geomsup.f:324:9: warning: type of ‘dgemv’ does not match original 
declaration [-Wlto-type-mismatch]

   324 |  & one, score, ione)
   | ^
/home/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:107:1: note: type mismatch 
in parameter 12

   107 | F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
   | ^

This is odd since the LAPACK subroutine dgemv takes only 11 
parameters. However, in include/R_ext/BLAS.h we have


F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
 const double *alpha, const double *a, const int *lda,
 const double *x, const int *incx, const double *beta,
 double *y, const int *incy FCLEN);

with a 12th parameter FCLEN?? How am I supposed to fix this, and what 
the ... is FCLEN? googling leads to nothing useful (for me). It seems 
as if R is redefining some standard LAPACK routines.


Also a note I do not understand (in this context):

note: type ‘void’ should match type ‘long int’

Any help is much appreciated.

Best, Göran

PS. How can I trigger these Warnings 'at home'?


See https://www.stats.ox.ac.uk/pub/bdr/LTO/README.txt (thanks to Uwe 
Ligges).


Another relevant document seems to be (2019-05-15):

https://developer.r-project.org/Blog/public/2019/05/15/gfortran-issues-with-lapack/index.html 



First sentence:
"Recent version of the GNU Fortran compiler (7, 8, 9) include 
optimizations that break interoperability between C and Fortran code 
with BLAS/LAPACK."


And later:
"For the time being, everyone should use -fno-optimize-sibling-calls 
with GFortran version 7 and newer."


G,


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


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


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

Re: [Bioc-devel] new package for accessing some chemical and biological databases

[Shepherd, Lori]

No we do not allow such submodules currently in Bioconductor.

How big is the object?  I assume putting the data object in the package 
increases the package size over the limit?

If this is the case, We would recommend storing the data in the ExperimentHub. 
See [Creating An ExperimentHub 
package](https://bioconductor.org/packages/devel/bioc/vignettes/ExperimentHub/inst/doc/CreateAnExperimentHubPackage.html)




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 Pierrick Roger 

Sent: Wednesday, September 11, 2019 5:04 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] new package for accessing some chemical and biological 
databases

Dear all,

I'd like to submit by package biodb (https://github.com/pkrog/biodb) in the 
near future.
The aim of this package is to present a unified access to diverse
databases (ChEBI, KEGG databases, Uniprot, ...).
For running examples, building vignettes and running tests, I use a
cache that is stored in another GitHub repository
(https://github.com/pkrog/biodb-cache), and registered as a Git submodule of
biodb.
This cache is currently necessary, since accessing the databases during
"R CMD check" would lead to some connection errors and would take too
much time.
I would like to know if this scheme is acceptable for Bioconductor.

Best regards,
--
Research engineer Pierrick Roger
http://www.cea-tech.fr | http://workflow4metabolomics.org | 
http://www.metabohub.fr
https://fr.linkedin.com/in/pkrog | https://github.com/pkrog
In varietate concordia.

___
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.
[[alternative HTML version deleted]]

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

Re: [Rd] '==' operator: inconsistency in data.frame(...) == NULL

[Hilmar Berger]

Sorry, I can't reproduce the example below even on the same machine. 
However, the following example produces the same error as NULL values in 
prior examples:


> setClass("FOOCLASS",
+  representation("list")
+ )
> ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10)))
> isS4(ma)
[1] TRUE
> data.frame(a=1:3) == ma
Error in matrix(unlist(value, recursive = FALSE, use.names = FALSE), 
nrow = nr,  :

  length of 'dimnames' [2] not equal to array extent

Best,
Hilmar


On 11/09/2019 12:24, Hilmar Berger wrote:
Another example where a data.frame is compared to (here non-null, 
non-empty) non-atomic values in Ops.data.frame, resulting in an error 
message:


setClass("FOOCLASS2",
 slots = c(M="matrix")
)
ma = new("FOOCLASS2", M=matrix(rnorm(300), 30,10))

> isS4(ma)
[1] TRUE
> ma == data.frame(a=1:3)
Error in eval(f) : dims [product 1] do not match the length of object [3]

As for the NULL/logical(0) cases I would suggest to explicitly test 
for invalid conditions in Ops.data.frame and generate a comprehensible 
message (e.g. "comparison is possible only for atomic and list types") 
if appropriate.


Best regards,
Hilmar


On 11/09/2019 11:55, Hilmar Berger wrote:


In the data.frame()==NULL cases I have the impression that the fact 
that both sides are non-atomic is not properly detected and therefore 
R tries to go on with the == method for data.frames.


From a cursory check in Ops.data.frame() and some debugging I have 
the impression that the case of the second argument being non-atomic 
or empty is not handled at all and the function progresses until the 
end, where it fails in the last step on an empty value:


matrix(unlist(value, recursive = FALSE, use.names = FALSE),
    nrow = nr, dimnames = list(rn, cn)) 




--
Dr. Hilmar Berger, MD
Max Planck Institute for Infection Biology
Charitéplatz 1
D-10117 Berlin
GERMANY

Phone:  + 49 30 28460 430
Fax:+ 49 30 28460 401
 
E-Mail: ber...@mpiib-berlin.mpg.de

Web   : www.mpiib-berlin.mpg.de

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

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Bhagwat, Aditya]

Hi Herve,

Thank you for your responses. 
>From your response, it is clear that the vcountPDict use case does not need a 
>BSgenome -> GRanges coercer.

The karyoploteR use case still requires it, though, to allow plotting of only 
the chromosomal BSgenome portions:

chromranges <- as(bsegenome, "GRanges")
kp <- karyoploteR::plotKaryotype(chromranges)
karyoploteR::kpPlotRegions(kp, crispr_target_sites)

Or do you see any alternative for this purpose too?

Aditya


From: Pages, Herve [hpa...@fredhutch.org]
Sent: Wednesday, September 11, 2019 12:24 PM
To: Bhagwat, Aditya; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

Hi Aditya,

On 9/11/19 01:31, Bhagwat, Aditya wrote:
> Hi Herve,
>
>
>  > It feels that a coercion method from BSgenome to GRanges should
> rather be defined in the BSgenome package itself.
>
> :-)
>
>
>  > Patch/PR welcome on GitHub.
>
> Owkies. What pull/fork/check/branch protocol to be followed?
>
>
>  > Is this what you have in mind for this coercion?
>  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>
> Yes.
>
> Perhaps also useful to share the wider context, allowing your and others
> feedback for improved software design.
> I wanted to subset a
> BSgenome
> (without the _random or _unassigned), but Lori explained this is not
> possible.
> 
>
> Instead Lori suggested to coerce a BSgenome into a GRanges
> ,
> which is a useful solution, but for which currently no exported S4
> method exists
> 
> So I defined an S4 coercer in my multicrispr package, making sure to
> properly import the Bsgenome class
> .
> Then, after coercing a BSgenome into a GRanges, I can extract the
> chromosomes, after properly importing IRanges::`%in%`
> 

Looks like you don't need to coerce the BSgenome object to GRanges. See
https://support.bioconductor.org/p/123489/#124581

H.

> Which I can then on end to karyoploteR
> ,
> for genome-wide plots of crispr target sites.
>
> A good moment also to say thank you to all of you who helped me out, it
> helps me to make multicrispr fit nicely into the BioC ecosystem.
>
> Speeking of BioC design philosophy, can any of you suggest concise and
> to-the-point reading material to deepen my understanding of the core
> BioC software design philosophy?
> I am trying to understand that better (which was the context for asking
> recently why there are three Vector -> data.frame coercers in S4Vectors
> )
>
> Cheers,
>
> Aditya
>
>
>
>
> 
> From: Pages, Herve [hpa...@fredhutch.org]
> Sent: Tuesday, September 10, 2019 6:45 PM
> To: Bhagwat, Aditya; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching
> BiocGenerics (and others)?
>
> Hi Aditya,
>
>
> More generally speaking, coercion methods should be defined in a place
> that is "as close as possible" to the "from" or "to" classes rather than
> in a package 

Re: [Bioc-devel] Reset to a previous commit

[Simon Dirmeier]

Hello,

thanks Nitesh. I reverted the commits accordingly.

Cheers,

Simon

On 10.09.19 16:45, Turaga, Nitesh wrote:

Hi Simon,

I take this back actually. I think the best way forward is just undo the code 
changes, and add a new version number to it ( 1.9.3) and push.

Step 1,

Since your version 1.9.2 is already on Bioconductor, first sync your 
GitHub with that version.

Step 2,

Undo the code changes, and add a new version 1.9.3 to it.

Step 3,

You should be able to just do a regular push to Bioconductor here on 
out.

Best,

Nitesh


On Sep 10, 2019, at 8:51 AM, Turaga, Nitesh  
wrote:

Hi Simon,

Bioconductor's git system doesn't allow force push (This is a feature) .  It 
only allows a force push by administrators (Bioconductor Core team). Please 
send me a link to your GitHub repo which is at 1.9.0, and I will sync it for 
you.

I've updated the link where the instructions are outdated. Thank you for 
bringing this to our attention.

Best,

Nitesh


On Sep 10, 2019, at 3:42 AM, Simon Dirmeier  wrote:

Hi all,
following our previous TensorFlow discussion, I am trying to reset to a
previous commit and get rid of the TF changes in the meantime.Resetting
back to the last working commit [1] that doesn't use TF gives me this
error though:

$ git reset --hard 4e267949562a0b38b16495892c4ef4c0dcf7b6f3


$ git push -f upstream master

$ remote: Error: Illegal version bump from '1.9.2' to '1.9.0'. Check
$ remote: http://bioconductor.org/developers/how-to/version-numbering/
$ remote: for details
$ To git.bioconductor.org:packages/netReg.git
$  ! [remote rejected] master -> master (pre-receive hook declined)
$ error: failed to push some refs to
'g...@git.bioconductor.org:packages/netReg.git'

Trying to circumvent this by incrementing to '1.9.3' doesn't do the
trick either. Does anyone have any ideas how I could fix this issue?

Many thanks in advance again.

Best,
Simon

[1]
http://bioconductor.org/developers/how-to/git/abandon-changes/#reset-to-a-previous-commit



On 05.09.19 15:35, Martin Morgan wrote:

I'm with Simon on the value of using TensorFlow here, and it's too bad the build 
system is unable to support more flexible use of python (there are additional 
challenges, for instance inter-operability between packages each depending on & 
starting their own python interpreter...)

It seems like the keras model

https://github.com/rstudio/keras
https://keras.rstudio.com/

is reasonable -- providing an `install_keras()` and related convenience functions, 
but writing the package so that it does not depend on an available python for build 
& check. Obviously not checking the TensorFlow interface on a daily basis 
compromises the robustness of the software, and hopefully the build system will be 
able to provide a more robust testing environment in the future.

Martin

On 9/5/19, 9:10 AM, "Bioc-devel on behalf of Kasper Daniel Hansen" 
 wrote:

 It might be true that the code is much easier on your end, but it comes
 with the complexity of using TensorFlow, which is a huge dependency. And
 that library can be easy or impossible to install depending on your box.  I
 am not saying people shouldn't use TensorFlow, but I am saying it brings a
 lot of complexities with it.

 And (trying to) installing TensorFlow as part of .onLoad seems ... not the
 right way to deal with this.

 On Thu, Sep 5, 2019 at 6:27 AM Simon Dirmeier  
wrote:


Hi Herve,


All this means that if you replace some old C++ code with TensorFlow
then we will need to mark your package as unavailable on Windows and
Mac, at least for now. Sorry. I wonder if there was something wrong
with this old C++ code. I would recommend that you stick to it if you

can.
The code is fine, but still an impractical complexity that doesn't need
to exist:

1) It's hard to extend and read for others.

2) It needs a custom configure.ac.

3) Extending the package to other models/families is a huge pain, as one
needs to derive custom coordinate descents (or other optimizers for that
matter) for each.

On the other side:

1) TF allowed me to replace like 5000 lines of source code with 100
lines of R.

2) TF allows to easily extend with other models with just a few lines.

3) I don't need a huge test suite.

4) On GPUs it's a huge speedup.

So, I'll revert the changes back on Bioc devel for now and continue
development on another branch.

Cheers,

Simon


Am 04.09.19 um 16:53 schrieb Pages, Herve:

Hi Simon,

On 9/3/19 09:11, Simon Dirmeier wrote:

...
Do you think it would be possible to install TensorFlow and
TensorFlow-Probability on the builders? I'd assume that many would
profit from that.


As Lori mentioned at the end of her email (see below), we can't make
the tensorflow Python module available on our Windows builders at the
moment because we need to update Python to Python 3 on these machines
first (AFAIK tensorflow is only available for Python 3 on Windows).
This is something that we are currently 

Re: [Rd] '==' operator: inconsistency in data.frame(...) == NULL

[Hilmar Berger]

Another example where a data.frame is compared to (here non-null, 
non-empty) non-atomic values in Ops.data.frame, resulting in an error 
message:


setClass("FOOCLASS2",
 slots = c(M="matrix")
)
ma = new("FOOCLASS2", M=matrix(rnorm(300), 30,10))

> isS4(ma)
[1] TRUE
> ma == data.frame(a=1:3)
Error in eval(f) : dims [product 1] do not match the length of object [3]

As for the NULL/logical(0) cases I would suggest to explicitly test for 
invalid conditions in Ops.data.frame and generate a comprehensible 
message (e.g. "comparison is possible only for atomic and list types") 
if appropriate.


Best regards,
Hilmar


On 11/09/2019 11:55, Hilmar Berger wrote:


In the data.frame()==NULL cases I have the impression that the fact 
that both sides are non-atomic is not properly detected and therefore 
R tries to go on with the == method for data.frames.


From a cursory check in Ops.data.frame() and some debugging I have the 
impression that the case of the second argument being non-atomic or 
empty is not handled at all and the function progresses until the end, 
where it fails in the last step on an empty value:


matrix(unlist(value, recursive = FALSE, use.names = FALSE),
    nrow = nr, dimnames = list(rn, cn)) 


--
Dr. Hilmar Berger, MD
Max Planck Institute for Infection Biology
Charitéplatz 1
D-10117 Berlin
GERMANY

Phone:  + 49 30 28460 430
Fax:+ 49 30 28460 401
 
E-Mail: ber...@mpiib-berlin.mpg.de

Web   : www.mpiib-berlin.mpg.de

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

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Pages, Herve]

Hi Aditya,

On 9/11/19 01:31, Bhagwat, Aditya wrote:
> Hi Herve,
> 
> 
>  > It feels that a coercion method from BSgenome to GRanges should 
> rather be defined in the BSgenome package itself.
> 
> :-)
> 
> 
>  > Patch/PR welcome on GitHub.
> 
> Owkies. What pull/fork/check/branch protocol to be followed?
> 
> 
>  > Is this what you have in mind for this coercion?
>  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
> 
> Yes.
> 
> Perhaps also useful to share the wider context, allowing your and others 
> feedback for improved software design.
> I wanted to subset a 
> BSgenome
>  
> (without the _random or _unassigned), but Lori explained this is not 
> possible. 
> 
>  
> 
> Instead Lori suggested to coerce a BSgenome into a GRanges 
> ,
>  
> which is a useful solution, but for which currently no exported S4 
> method exists 
> 
> So I defined an S4 coercer in my multicrispr package, making sure to 
> properly import the Bsgenome class 
> .
> Then, after coercing a BSgenome into a GRanges, I can extract the 
> chromosomes, after properly importing IRanges::`%in%` 
> 

Looks like you don't need to coerce the BSgenome object to GRanges. See 
https://support.bioconductor.org/p/123489/#124581

H.

> Which I can then on end to karyoploteR 
> ,
>  
> for genome-wide plots of crispr target sites.
> 
> A good moment also to say thank you to all of you who helped me out, it 
> helps me to make multicrispr fit nicely into the BioC ecosystem.
> 
> Speeking of BioC design philosophy, can any of you suggest concise and 
> to-the-point reading material to deepen my understanding of the core 
> BioC software design philosophy?
> I am trying to understand that better (which was the context for asking 
> recently why there are three Vector -> data.frame coercers in S4Vectors 
> )
> 
> Cheers,
> 
> Aditya
> 
> 
> 
> 
> 
> From: Pages, Herve [hpa...@fredhutch.org]
> Sent: Tuesday, September 10, 2019 6:45 PM
> To: Bhagwat, Aditya; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
> 
> Hi Aditya,
> 
> 
> More generally speaking, coercion methods should be defined in a place
> that is "as close as possible" to the "from" or "to" classes rather than
> in a package that doesn't own any of the 2 classes involved.
> Is this what you have in mind for this coercion?
> 
>  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
> GRanges object with 7 ranges and 0 metadata columns:
> seqnames ranges strand
>   
> chrI chrI 1-15072423 *
> chrII chrII 1-15279345 *
> chrIII chrIII 1-13783700 *
> chrIV chrIV 1-17493793 *
> chrV chrV 1-20924149 *
> chrX chrX 1-17718866 *
> chrM chrM 1-13794 *
> ---
> seqinfo: 7 sequences (1 circular) from ce10 genome
> 
> Thanks,
> H.
> 
> 
> On 9/6/19 03:39, Bhagwat, Aditya wrote:
>  > Dear Bioc devel,
>  >
>  > Is it possible to import the BSgenome class without attaching 
> BiocGenerics (to keep a clean namespace 

Re: [R-pkg-devel] GSL update on CRAN

[Raphael Hartmann]

Hi,

I hope you don't mind me asking again:
Does anybody have an idea on how to implement the whole GSL library in
my package? I was not able to find sth. on Google.

Whom should I contact for asking whether it is possible to update GSL
for Windows on CRAN? There were no warnings or errors in the CRAN
checks for debian. For Windows on CRAN, the compiler gives only an
error where a GSL routine of version 2.3 is used.

Best wishes
Raphael



On Fri, 06 Sep 2019 08:19:37 +0200
 "Raphael Hartmann" 
wrote:
>
>Hello,
> 
>I developed an R package that requires at least version 2.3 of GSL
>(ftp://ftp.gnu.org/gnu/gsl/). The newest version is 2.6.
> 
>Version 2.3 is now available for over two years, and I was wondering
>whether it was possible to update GSL on the win-builder? I would
>really appreciate it. Without it my package will be rejected on CRAN.
> 
>Or is there an option to include the whole GSL library in the package?
> 
>On my machines (two debian based and one Windows server 16 and one
>Windows 10) the package passes the checks of "R CMD check --as-cran".
>On builder.r-hub.io with Windows server 12 it is also successful.
>
>I would be glad for any advice / suggestions / hints. 
>
> 
>Best wishes
>Raphael
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

--
Albert-Ludwigs-Universität Freiburg
Institute of Psychology, Cognition, Action, and Sustainability
Engelbergerstrasse 41
D-79085 Freiburg
Phone: +49 761 203 2465

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

Re: [Bioc-devel] Failing to build vignette because of problems with ImageMagick

[Pages, Herve]

On 9/11/19 00:50, Vincent Carey wrote:
> I seem to be running into a similar problem with BiocOncoTK on windows
> 
> The build report for tokay1 shows:
> 
> Loading required package: ontologyIndex
> Invalid Parameter - /figure-html
> Warning in shell(paste(c(cmd, args), collapse = " ")) :
>'convert "BiocOncoTK_files/figure-html/lkgbm-1.png" -trim
> "BiocOncoTK_files/figure-html/lkgbm-1.png"' execution failed with
> error code 4
> Invalid Parameter - /figure-html
> 
> The figure code is introduced with ```{r lkgbm,fig=TRUE,message=FALSE}
> ... the 'convert' process is not requested by me
> 
> Is the fig=TRUE problematic for windows?  It seems unnecessary.

Not sure what's going on. A few observations:

a) About 500 software packages use fig=TRUE.

b) The convert warning is just a warning. The actual error in the case 
of BiocOncoTK is:

   Error: processing vignette 'BiocOncoTK.Rmd' failed with diagnostics:
argument is of length zero

   Note that the ndexr vignette also fails with this error on tokay1 
only but it doesn't have the convert warning (this vignette does not use 
'fig' at all). So it's not clear to me that the "argument is of length 
zero" error is related to the convert warning.

c) The devel build report shows the convert warning for 4 other packages 
(CAGEfightR, CATALYST, CTDquerier, specL) but each of them actually 
fails with a different error message:

   CAGEfightR:
 colData(object1) not identical to colData(object2)

   CATALYST:
 no slot of name "reducedDims" for this object of class "daFrame"

   CTDquerier:
 bfcadd() failed; see warnings()

   specL:
 pandoc.exe: Out of memory

   These errors don't seem related to the convert warning either.

So I'm wondering: could it be that the convert warning is actually 
common but we generally don't see it because 'R CMD build' doesn't 
report warnings? And that we just happen to see the warning when 'R CMD 
build' fails to build a vignette.

We'll investigate more.

H.


> 
> On Tue, Sep 10, 2019 at 11:35 AM Christian Mertes  wrote:
> 
>> Thanks a lot for the info! So from my understanding we dont use any
>> trimming or editing function from ImageMagick directly. I think this is
>> rather knitr based since we just include png files in the vignette.
>>
>> I guess it was an hickup since now the error is gone over night.
>>
>> Best regards,
>>
>> Christian
>>
>> On 9/9/19 4:34 PM, Kasper Daniel Hansen wrote:
>>> You don't declare any systems requirements for ImageMagick (doing so
>>> will probably not solve your problem, but you really should).
>>>
>>> Alternatively you could look into using the tools provided by the
>>> magick package, which wraps ImageMagick.
>>>
>>> But it looks like you're editing PNG files for your vignette. I would
>>> really recommend not doing so. It introduces a system dependency which
>>> is just going to increase headaches on your end, for (perhaps) no real
>>> tangible benefits. If you're trimming PNGs, you should be able to
>>> achieve the same effect when using the png device(s) in R, and that
>>> will make everything more portable anyway.
>>>
>>> On Mon, Sep 9, 2019 at 9:42 AM Christian Mertes >> > wrote:
>>>
>>>  Dear BioC team,
>>>
>>>  I just noticed that our package is failing on the bioconductor build
>>>  system during the build of the vignette on Windows and on MacOS
>>>  platforms.
>>>
>>>  From the error I would guess its a problem with the installation
>>>  of the
>>>  ImageMagick package. Please correct me if Im wrong.
>>>
>>>  It goes through on travis and appveyor. Any suggestions?
>>>
>>>  Here are some links to the build logs:
>>>
>>>  
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.riken.jp_checkResults_3.9_bioc-2DLATEST_OUTRIDER_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EwnHWfrov-A-kbkOeSotrFEWVXwIUuSJog3NysTJUnE=NA7UQNLz8lFT9bIMHiFka2iUJDarMgfT0uW36-nO9og=
>>>  
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_gagneurlab_OUTRIDER=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EwnHWfrov-A-kbkOeSotrFEWVXwIUuSJog3NysTJUnE=lf9cL5c-plgiqIP3Hx6Eht_Ataw3bG3x3rP7gi79flg=
>>>  
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__ci.appveyor.com_project_c-2Dmertes_OUTRIDER=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=EwnHWfrov-A-kbkOeSotrFEWVXwIUuSJog3NysTJUnE=l-gS-eeyNnK7JCEdHKIUQifQoI40TZZXQox80MniKEA=
>>>
>>>  Best,
>>>
>>>  Christian
>>>
>>>  PS: the error message on the bioc build system:
>>>
>>>
>>   
>> ##
>>>
>>   
>> ##
>>>  ###
>>>  ### Running command:
>>>  ###
>>>  ###   chmod a+r OUTRIDER -R &&
>>>  C:\Users\biocbuild\bbs-3.9-bioc\R\bin\R.exe CMD build
>>>  --keep-empty-dirs 

[Bioc-devel] new package for accessing some chemical and biological databases

[Pierrick Roger]

Dear all,

I'd like to submit by package biodb (https://github.com/pkrog/biodb) in the 
near future.
The aim of this package is to present a unified access to diverse
databases (ChEBI, KEGG databases, Uniprot, ...).
For running examples, building vignettes and running tests, I use a
cache that is stored in another GitHub repository
(https://github.com/pkrog/biodb-cache), and registered as a Git submodule of
biodb.
This cache is currently necessary, since accessing the databases during
"R CMD check" would lead to some connection errors and would take too
much time.
I would like to know if this scheme is acceptable for Bioconductor.

Best regards,
-- 
Research engineer Pierrick Roger
http://www.cea-tech.fr | http://workflow4metabolomics.org | 
http://www.metabohub.fr
https://fr.linkedin.com/in/pkrog | https://github.com/pkrog
In varietate concordia.

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

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

[Bhagwat, Aditya]

Hi Herve,


> It feels that a coercion method from BSgenome to GRanges should rather be 
> defined in the BSgenome package itself.

:-)


> Patch/PR welcome on GitHub.

Owkies. What pull/fork/check/branch protocol to be followed?


> Is this what you have in mind for this coercion?
> as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")

Yes.

Perhaps also useful to share the wider context, allowing your and others 
feedback for improved software design.
I wanted to subset a  BSgenome 
(without the _random or _unassigned), but Lori explained this is not 
possible.
Instead Lori suggested to coerce a BSgenome into a 
GRanges, which is a useful solution, 
but for which currently no exported S4 method 
exists
So I defined an S4 coercer in my multicrispr package, making sure to properly 
import the Bsgenome class.
Then, after coercing a BSgenome into a GRanges, I can extract the chromosomes, 
after properly importing 
IRanges::`%in%`
Which I can then on end to 
karyoploteR, for genome-wide plots 
of crispr target sites.

A good moment also to say thank you to all of you who helped me out, it helps 
me to make multicrispr fit nicely into the BioC ecosystem.

Speeking of BioC design philosophy, can any of you suggest concise and 
to-the-point reading material to deepen my understanding of the core BioC 
software design philosophy?
I am trying to understand that better (which was the context for asking 
recently why there are three Vector -> data.frame coercers in 
S4Vectors)

Cheers,

Aditya





From: Pages, Herve [hpa...@fredhutch.org]
Sent: Tuesday, September 10, 2019 6:45 PM
To: Bhagwat, Aditya; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

Hi Aditya,


More generally speaking, coercion methods should be defined in a place
that is "as close as possible" to the "from" or "to" classes rather than
in a package that doesn't own any of the 2 classes involved.
Is this what you have in mind for this coercion?

> as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
GRanges object with 7 ranges and 0 metadata columns:
seqnames ranges strand
  
chrI chrI 1-15072423 *
chrII chrII 1-15279345 *
chrIII chrIII 1-13783700 *
chrIV chrIV 1-17493793 *
chrV chrV 1-20924149 *
chrX chrX 1-17718866 *
chrM chrM 1-13794 *
---
seqinfo: 7 sequences (1 circular) from ce10 genome

Thanks,
H.


On 9/6/19 03:39, Bhagwat, Aditya wrote:
> Dear Bioc devel,
>
> Is it possible to import the BSgenome class without attaching BiocGenerics 
> (to keep a clean namespace during the development of 
> multicrispr  >).
>
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> (Posted earlier on BioC 
> support  > and redirected here following Martin's suggestion)
>
> Thankyou :-)
>
> Aditya
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cXJaaEvfNbOioopXgFWQms1qny1xehFQyb3V3xDy55M=cEojiObibdSuzmh21opvy85DZyRrjtfo1vEMopKWmAg=
>

--
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

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Failing to build vignette because of problems with ImageMagick

[Vincent Carey]

I seem to be running into a similar problem with BiocOncoTK on windows

The build report for tokay1 shows:

Loading required package: ontologyIndex
Invalid Parameter - /figure-html
Warning in shell(paste(c(cmd, args), collapse = " ")) :
  'convert "BiocOncoTK_files/figure-html/lkgbm-1.png" -trim
"BiocOncoTK_files/figure-html/lkgbm-1.png"' execution failed with
error code 4
Invalid Parameter - /figure-html

The figure code is introduced with ```{r lkgbm,fig=TRUE,message=FALSE}
... the 'convert' process is not requested by me

Is the fig=TRUE problematic for windows?  It seems unnecessary.


On Tue, Sep 10, 2019 at 11:35 AM Christian Mertes  wrote:

> Thanks a lot for the info! So from my understanding we dont use any
> trimming or editing function from ImageMagick directly. I think this is
> rather knitr based since we just include png files in the vignette.
>
> I guess it was an hickup since now the error is gone over night.
>
> Best regards,
>
> Christian
>
> On 9/9/19 4:34 PM, Kasper Daniel Hansen wrote:
> > You don't declare any systems requirements for ImageMagick (doing so
> > will probably not solve your problem, but you really should).
> >
> > Alternatively you could look into using the tools provided by the
> > magick package, which wraps ImageMagick.
> >
> > But it looks like you're editing PNG files for your vignette. I would
> > really recommend not doing so. It introduces a system dependency which
> > is just going to increase headaches on your end, for (perhaps) no real
> > tangible benefits. If you're trimming PNGs, you should be able to
> > achieve the same effect when using the png device(s) in R, and that
> > will make everything more portable anyway.
> >
> > On Mon, Sep 9, 2019 at 9:42 AM Christian Mertes  > > wrote:
> >
> > Dear BioC team,
> >
> > I just noticed that our package is failing on the bioconductor build
> > system during the build of the vignette on Windows and on MacOS
> > platforms.
> >
> > From the error I would guess its a problem with the installation
> > of the
> > ImageMagick package. Please correct me if Im wrong.
> >
> > It goes through on travis and appveyor. Any suggestions?
> >
> > Here are some links to the build logs:
> >
> > http://bioconductor.riken.jp/checkResults/3.9/bioc-LATEST/OUTRIDER/
> > https://travis-ci.org/gagneurlab/OUTRIDER
> > https://ci.appveyor.com/project/c-mertes/OUTRIDER
> >
> > Best,
> >
> > Christian
> >
> > PS: the error message on the bioc build system:
> >
> >
>  
> ##
> >
>  
> ##
> > ###
> > ### Running command:
> > ###
> > ###   chmod a+r OUTRIDER -R &&
> > C:\Users\biocbuild\bbs-3.9-bioc\R\bin\R.exe CMD build
> > --keep-empty-dirs --no-resave-data OUTRIDER
> > ###
> >
>  
> ##
> >
>  
> ##
> >
> >
> > * checking for file 'OUTRIDER/DESCRIPTION' ... OK
> > * preparing 'OUTRIDER':
> > * checking DESCRIPTION meta-information ... OK
> > * cleaning src
> > * installing the package to build vignettes
> > * creating vignettes ... ERROR
> > --- re-building 'OUTRIDER.Rnw' using knitr
> > Invalid Parameter - /deVsOutlier-1.png"
> > Warning in shell(paste(c(cmd, args), collapse = " ")) :
> >   'convert "figure/deVsOutlier-1.png" -trim
> > "figure/deVsOutlier-1.png"' execution failed with error code 4
> > 229 genes did not passed the filter due to zero counts. This is
> > 22.9% of the genes.
> > Sat Sep 07 01:16:53 2019: SizeFactor estimation ...
> > Sat Sep 07 01:16:53 2019: Controlling for confounders ...
> > Using estimated q with: 23
> > Sat Sep 07 01:16:53 2019: Using the autoencoder implementation for
> > controlling.
> > Sat Sep 07 01:17:52 2019: Used the autoencoder implementation for
> > controlling.
> > Sat Sep 07 01:17:52 2019: P-value calculation ...
> > Sat Sep 07 01:17:52 2019: Zscore calculation ...
> > Invalid Parameter - /quick_guide-1.png"
> > Warning in shell(paste(c(cmd, args), collapse = " ")) :
> >   'convert "figure/quick_guide-1.png" -trim
> > "figure/quick_guide-1.png"' execution failed with error code 4
> > Quitting from lines 222-232 (OUTRIDER.Rnw)
> > Error: processing vignette 'OUTRIDER.Rnw' failed with diagnostics:
> > no lines available in input
> > --- failed re-building 'OUTRIDER.Rnw'
> >
> > SUMMARY: processing the following file failed:
> >   'OUTRIDER.Rnw'
> >
> > Error: Vignette re-building failed.
> > Execution halted
> >
> > --
> >
> > Christian Mertes
> > PhD Student / Lab Administrator
> > Gagneur lab
> >
> > Computational Genomics
> > I12 

[Rd] R-intro: Appendix A: attach position

[Suharto Anggono Suharto Anggono via R-devel]

In "An Introduction to R", in "Appendix A  A sample session", in the part on 
Michelson data, information for
attach(mm)
is
Make the data frame visible at position 3 (the default).

In fact, the 'attach' is at position 2.

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