Re: [Bioc-devel] BiocInstaller: next generation

[Pariksheet Nanda]

Hi Henrik,

On Thu, May 10, 2018 at 1:21 AM, Henrik Bengtsson <
henrik.bengts...@gmail.com> wrote:
>
>
> May I suggest the package name:
>
> * Bioconductor
>
> The potential downside would be possible confusions between the version of
> this package versus the actual Bioconductor repository.  Could the
> Bioconductor *package* have a version  x.y.z that reflects the
*repository*
> x.y version?

This is a nice suggestion that also crossed my mind, but users new to both
R and Bioconductor might think "but I have 'Bioconductor' installed, why
can't I run this script?", and it might complicate web namespace / presence
by entrapping searches for the Bioconductor system to the single package.


> /Henrik

Pariksheet

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BiocInstaller: next generation

[Henrik Bengtsson]

On Thu, May 10, 2018, 00:29 Martin Morgan 
wrote:

> Developers --
>
> A preliminary heads-up and request for comments.
>
> Almost since project inception, we've used the commands
>
>source("https://bioconductor.org/biocLite.R;)
>biocLite(pkgs)
>
> to install packages. This poses security risks (e.g., typos in the url)
> and deviates from standard R package installation procedures.
>
>
> We'd like to move to a different system where a base package, call it
> 'BiocManager', is installed from CRAN and used to install Bioconductor
> packages
>
>if (!"BiocManager" %in% rownames(installed.packages()))
>install.packages("BiocManager")
>BiocManager::install(pkgs)
>
> This establishes a secure chain from user R session to Bioconductor
> package installation. It is also more consistent with base R package
> installation procedures.
>
> BiocManager exposes four functions
>
>- install() or update packages
>
>- version() version of Bioconductor in use
>
>- valid() are all Bioconductor packages from the same Bioconductor
> version?
>
>- repositories() url location for Bioconductor version-specific
> repositories
>
> install() behaves like biocLite(), using the most current version of
> Bioconductor for the version of R in use. It stores this state using a
> Bioconductor package 'BiocVersion', which is nothing more than a
> sentinel for the version in use. One can also 'use devel' or a
> particular version of Bioconductor (consistent with the version of R) with
>
>BiocManager::install(version = "3.8")   # or the synonym "devel"
>
>
> We intend to phase this in over several release cycles, and to continue
> to support the traditional biocLite() route for versions before
> BiocManager becomes available.
>
> We also intend to change the overall versioning of 'Bioconductor'
> itself, where releases are always even (3.8, 3.10, 3.12, ...) and
> 'devel' always odd.
>
> Obviously this is a large change, eventually requiring updates to many
> locations on our web site and individual vignettes.
>
>
> Of course the key question is the name of the 'BiocManager' package. It
> cannot easily be 'BiocInstaller', because of the differences in way CRAN
> and Bioconductor version packages. Some possible names are
> '
> BiocInstall::install()
> BiocPackages::install()
> BiocManager
> BiocMaestro


May I suggest the package name:

* Bioconductor

The potential downside would be possible confusions between the version of
this package versus the actual Bioconductor repository.  Could the
Bioconductor *package* have a version  x.y.z that reflects the *repository*
x.y version?

/Henrik



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

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] BiocInstaller: next generation

[Martin Morgan]

On 05/09/2018 07:05 PM, Aaron Lun wrote:

This all sounds pretty reasonable to me. The ability to choose the
version in install() is nice, especially if we can easily flip between
versions in different install locations. I presume that
version="release" will be the default?


I actually have some reservation about introducing the 'release' synonym 
-- telling a user on April 30 that they should use 'release' and then 
again on May 2 that they should use 'release', but to mean two different 
versions of Bioconductor seems confusing to me. Also the notion that a 
more-or-less casual user will get into Bioconducor enough to grok the 
whole release / devel cycle seems somehow presumptuous. Of course 
developers are a more sophisticated lot, and the notion of a 'devel' 
branch is central to Bioconductor's approach to version management...


Martin



As for the names - BiocManager seems the most sober of the lot. And
thematically appropriate - you might have an orchestra and conductor,
but you still need a manager to get everyone paid, fed and on the stage.

-Aaron

Martin Morgan wrote:

Developers --

A preliminary heads-up and request for comments.

Almost since project inception, we've used the commands

   source("https://bioconductor.org/biocLite.R;)
   biocLite(pkgs)

to install packages. This poses security risks (e.g., typos in the
url) and deviates from standard R package installation procedures.


We'd like to move to a different system where a base package, call it
'BiocManager', is installed from CRAN and used to install Bioconductor
packages

   if (!"BiocManager" %in% rownames(installed.packages()))
   install.packages("BiocManager")
   BiocManager::install(pkgs)

This establishes a secure chain from user R session to Bioconductor
package installation. It is also more consistent with base R package
installation procedures.

BiocManager exposes four functions

   - install() or update packages

   - version() version of Bioconductor in use

   - valid() are all Bioconductor packages from the same Bioconductor
version?

   - repositories() url location for Bioconductor version-specific
repositories

install() behaves like biocLite(), using the most current version of
Bioconductor for the version of R in use. It stores this state using a
Bioconductor package 'BiocVersion', which is nothing more than a
sentinel for the version in use. One can also 'use devel' or a
particular version of Bioconductor (consistent with the version of R)
with

   BiocManager::install(version = "3.8")   # or the synonym "devel"


We intend to phase this in over several release cycles, and to
continue to support the traditional biocLite() route for versions
before BiocManager becomes available.

We also intend to change the overall versioning of 'Bioconductor'
itself, where releases are always even (3.8, 3.10, 3.12, ...) and
'devel' always odd.

Obviously this is a large change, eventually requiring updates to many
locations on our web site and individual vignettes.


Of course the key question is the name of the 'BiocManager' package.
It cannot easily be 'BiocInstaller', because of the differences in way
CRAN and Bioconductor version packages. Some possible names are
'
BiocInstall::install()
BiocPackages::install()
BiocManager
BiocMaestro


Your comments are welcome...

Martin


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

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

___

The information in this email is confidential and inte...{{dropped:12}}


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

Re: [Bioc-devel] BiocInstaller: next generation

[Martin Morgan]

On 05/09/2018 06:39 PM, Ryan Thompson wrote:

Hi Martin,

Is the intent that the BiocManager package should never be loaded via 
library, but functions in the package should always be called as 
BiocManager::FUN()? If not, I would consider prefixing the functions 
with "bioc".


I would rather that all documentation use BiocManager::install(), which 
is the only failsafe way to do the disambiguation.




Also, I assume that once this BiocManager package is on CRAN, the 
biocLite.R script will become a thin wrapper around it?


biocLite.R would be a legacy script available for current and past 
versions of Bioconductor. Going forward, it would go through a cycle of 
deprecated and defunct.


Martin



-Ryan

On Wed, May 9, 2018 at 3:29 PM Martin Morgan 
> 
wrote:


Developers --

A preliminary heads-up and request for comments.

Almost since project inception, we've used the commands

    source("https://bioconductor.org/biocLite.R;)
    biocLite(pkgs)

to install packages. This poses security risks (e.g., typos in the url)
and deviates from standard R package installation procedures.


We'd like to move to a different system where a base package, call it
'BiocManager', is installed from CRAN and used to install Bioconductor
packages

    if (!"BiocManager" %in% rownames(installed.packages()))
        install.packages("BiocManager")
    BiocManager::install(pkgs)

This establishes a secure chain from user R session to Bioconductor
package installation. It is also more consistent with base R package
installation procedures.

BiocManager exposes four functions

    - install() or update packages

    - version() version of Bioconductor in use

    - valid() are all Bioconductor packages from the same Bioconductor
version?

    - repositories() url location for Bioconductor version-specific
repositories

install() behaves like biocLite(), using the most current version of
Bioconductor for the version of R in use. It stores this state using a
Bioconductor package 'BiocVersion', which is nothing more than a
sentinel for the version in use. One can also 'use devel' or a
particular version of Bioconductor (consistent with the version of
R) with

    BiocManager::install(version = "3.8")   # or the synonym "devel"


We intend to phase this in over several release cycles, and to continue
to support the traditional biocLite() route for versions before
BiocManager becomes available.

We also intend to change the overall versioning of 'Bioconductor'
itself, where releases are always even (3.8, 3.10, 3.12, ...) and
'devel' always odd.

Obviously this is a large change, eventually requiring updates to many
locations on our web site and individual vignettes.


Of course the key question is the name of the 'BiocManager' package. It
cannot easily be 'BiocInstaller', because of the differences in way
CRAN
and Bioconductor version packages. Some possible names are
'
BiocInstall::install()
BiocPackages::install()
BiocManager
BiocMaestro


Your comments are welcome...

Martin


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

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




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

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

Re: [Bioc-devel] BiocInstaller: next generation

[Aaron Lun]

This all sounds pretty reasonable to me. The ability to choose the
version in install() is nice, especially if we can easily flip between
versions in different install locations. I presume that
version="release" will be the default?

As for the names - BiocManager seems the most sober of the lot. And
thematically appropriate - you might have an orchestra and conductor,
but you still need a manager to get everyone paid, fed and on the stage.

-Aaron

Martin Morgan wrote:
> Developers --
>
> A preliminary heads-up and request for comments.
>
> Almost since project inception, we've used the commands
>
>   source("https://bioconductor.org/biocLite.R;)
>   biocLite(pkgs)
>
> to install packages. This poses security risks (e.g., typos in the
> url) and deviates from standard R package installation procedures.
>
>
> We'd like to move to a different system where a base package, call it
> 'BiocManager', is installed from CRAN and used to install Bioconductor
> packages
>
>   if (!"BiocManager" %in% rownames(installed.packages()))
>   install.packages("BiocManager")
>   BiocManager::install(pkgs)
>
> This establishes a secure chain from user R session to Bioconductor
> package installation. It is also more consistent with base R package
> installation procedures.
>
> BiocManager exposes four functions
>
>   - install() or update packages
>
>   - version() version of Bioconductor in use
>
>   - valid() are all Bioconductor packages from the same Bioconductor
> version?
>
>   - repositories() url location for Bioconductor version-specific
> repositories
>
> install() behaves like biocLite(), using the most current version of
> Bioconductor for the version of R in use. It stores this state using a
> Bioconductor package 'BiocVersion', which is nothing more than a
> sentinel for the version in use. One can also 'use devel' or a
> particular version of Bioconductor (consistent with the version of R)
> with
>
>   BiocManager::install(version = "3.8")   # or the synonym "devel"
>
>
> We intend to phase this in over several release cycles, and to
> continue to support the traditional biocLite() route for versions
> before BiocManager becomes available.
>
> We also intend to change the overall versioning of 'Bioconductor'
> itself, where releases are always even (3.8, 3.10, 3.12, ...) and
> 'devel' always odd.
>
> Obviously this is a large change, eventually requiring updates to many
> locations on our web site and individual vignettes.
>
>
> Of course the key question is the name of the 'BiocManager' package.
> It cannot easily be 'BiocInstaller', because of the differences in way
> CRAN and Bioconductor version packages. Some possible names are
> '
> BiocInstall::install()
> BiocPackages::install()
> BiocManager
> BiocMaestro
>
>
> Your comments are welcome...
>
> Martin
>
>
> This email message may contain legally privileged and/or...{{dropped:2}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
___

The information in this email is confidential and intended solely for the 
addressee.
You must not disclose, forward, print or use it without the permission of the 
sender.

The Walter and Eliza Hall Institute acknowledges the Wurundjeri people of the 
Kulin
Nation as the traditional owners of the land where our campuses are located and
the continuing connection to country and community.
___
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] BiocInstaller: next generation

[Ryan Thompson]

Hi Martin,

Is the intent that the BiocManager package should never be loaded via
library, but functions in the package should always be called as
BiocManager::FUN()? If not, I would consider prefixing the functions with
"bioc".

Also, I assume that once this BiocManager package is on CRAN, the
biocLite.R script will become a thin wrapper around it?

-Ryan

On Wed, May 9, 2018 at 3:29 PM Martin Morgan 
wrote:

> Developers --
>
> A preliminary heads-up and request for comments.
>
> Almost since project inception, we've used the commands
>
>source("https://bioconductor.org/biocLite.R;)
>biocLite(pkgs)
>
> to install packages. This poses security risks (e.g., typos in the url)
> and deviates from standard R package installation procedures.
>
>
> We'd like to move to a different system where a base package, call it
> 'BiocManager', is installed from CRAN and used to install Bioconductor
> packages
>
>if (!"BiocManager" %in% rownames(installed.packages()))
>install.packages("BiocManager")
>BiocManager::install(pkgs)
>
> This establishes a secure chain from user R session to Bioconductor
> package installation. It is also more consistent with base R package
> installation procedures.
>
> BiocManager exposes four functions
>
>- install() or update packages
>
>- version() version of Bioconductor in use
>
>- valid() are all Bioconductor packages from the same Bioconductor
> version?
>
>- repositories() url location for Bioconductor version-specific
> repositories
>
> install() behaves like biocLite(), using the most current version of
> Bioconductor for the version of R in use. It stores this state using a
> Bioconductor package 'BiocVersion', which is nothing more than a
> sentinel for the version in use. One can also 'use devel' or a
> particular version of Bioconductor (consistent with the version of R) with
>
>BiocManager::install(version = "3.8")   # or the synonym "devel"
>
>
> We intend to phase this in over several release cycles, and to continue
> to support the traditional biocLite() route for versions before
> BiocManager becomes available.
>
> We also intend to change the overall versioning of 'Bioconductor'
> itself, where releases are always even (3.8, 3.10, 3.12, ...) and
> 'devel' always odd.
>
> Obviously this is a large change, eventually requiring updates to many
> locations on our web site and individual vignettes.
>
>
> Of course the key question is the name of the 'BiocManager' package. It
> cannot easily be 'BiocInstaller', because of the differences in way CRAN
> and Bioconductor version packages. Some possible names are
> '
> BiocInstall::install()
> BiocPackages::install()
> BiocManager
> BiocMaestro
>
>
> Your comments are welcome...
>
> Martin
>
>
> This email message may contain legally privileged and/or...{{dropped:2}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

[Bioc-devel] BiocInstaller: next generation

[Martin Morgan]

Developers --

A preliminary heads-up and request for comments.

Almost since project inception, we've used the commands

  source("https://bioconductor.org/biocLite.R;)
  biocLite(pkgs)

to install packages. This poses security risks (e.g., typos in the url) 
and deviates from standard R package installation procedures.



We'd like to move to a different system where a base package, call it 
'BiocManager', is installed from CRAN and used to install Bioconductor 
packages


  if (!"BiocManager" %in% rownames(installed.packages()))
  install.packages("BiocManager")
  BiocManager::install(pkgs)

This establishes a secure chain from user R session to Bioconductor 
package installation. It is also more consistent with base R package 
installation procedures.


BiocManager exposes four functions

  - install() or update packages

  - version() version of Bioconductor in use

  - valid() are all Bioconductor packages from the same Bioconductor 
version?


  - repositories() url location for Bioconductor version-specific 
repositories


install() behaves like biocLite(), using the most current version of 
Bioconductor for the version of R in use. It stores this state using a 
Bioconductor package 'BiocVersion', which is nothing more than a 
sentinel for the version in use. One can also 'use devel' or a 
particular version of Bioconductor (consistent with the version of R) with


  BiocManager::install(version = "3.8")   # or the synonym "devel"


We intend to phase this in over several release cycles, and to continue 
to support the traditional biocLite() route for versions before 
BiocManager becomes available.


We also intend to change the overall versioning of 'Bioconductor' 
itself, where releases are always even (3.8, 3.10, 3.12, ...) and 
'devel' always odd.


Obviously this is a large change, eventually requiring updates to many 
locations on our web site and individual vignettes.



Of course the key question is the name of the 'BiocManager' package. It 
cannot easily be 'BiocInstaller', because of the differences in way CRAN 
and Bioconductor version packages. Some possible names are

'
BiocInstall::install()
BiocPackages::install()
BiocManager
BiocMaestro


Your comments are welcome...

Martin


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

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

Re: [Bioc-devel] rsvg on mac

[Obenchain, Valerie]

Kevin,

I feel like we're not on the same page. We've had this discussion and both 
Herve and I tried to explain the situation:

  https://stat.ethz.ch/pipermail/bioc-devel/2018-February/012812.html

We do not build CRAN packages from source on the Windows and Mac build 
machines. If a CRAN binary is not available for one of your dependencies, e.g., 
rsvg, the best thing for you to do is contact the maintainer or post on the 
r-sig-mac mailing list:

  https://stat.ethz.ch/mailman/listinfo/r-sig-mac

However, ChemmineR is green on both release and devel build reports. I'm not 
sure why you are asking us (again) to install the rsvg system dependency on the 
Mac builders. Did I misunderstand what you wanted?

Valerie


On 05/09/2018 07:41 AM, Kevin Horan wrote:

Now that this past bioc release is done, and R 3.5 is stable, would it be 
possible to install the "rsvg" package on your build machines? Thanks.

Kevin

On 02/19/2018 02:01 PM, Alexey Sergushichev wrote:
Valerie, thanks. Will try to ask there.

However, after looking through the mailing list it looks like R-devel builds 
for OS X aren't trivial and aren't part of CRAN...

--
Alexey

On Mon, Feb 19, 2018 at 9:05 PM, Obenchain, Valerie 
> 
wrote:
Hi,

There has been some discussion of the devel Mac binaries on the R-SIG-Mac 
mailing list. That list would be the best place to ask this question.

https://stat.ethz.ch/pipermail/r-sig-mac/2018-January/thread.html

Valerie



On 02/19/2018 08:32 AM, Alexey Sergushichev wrote:
Valerie,

Are there any estimates on how often CRAN OS X builds happen? There are still 
no builds for rsvg and other packages...

Thanks,
Alexey

On Wed, Feb 7, 2018 at 8:09 PM, Obenchain, Valerie 
> 
wrote:
Hi Kevin,

CRAN binaries for El Capitan in devel aren't available. You can see this on the 
rsvg landing page:

https://cran.r-project.org/web/packages/rsvg/index.html

Nothing we can do until CRAN makes them available.

Valerie


On 02/07/2018 08:29 AM, Kevin Horan wrote:


The ChemmineR build is failing on the mac due to a new dependency not
being available, the package "rsvg". Would it be possible to install
that on the mac build machine? Thanks.

http://bioconductor.org/checkResults/devel/bioc-LATEST/ChemmineR/merida2-install.html


Kevin

___
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



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.





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] Initial list of deprecated packages Bioc 3.8

[Shepherd, Lori]

The Bioconductor Team is continuing to identify packages that will be 
deprecated in the next release to allow for the Bioconductor community to 
respond accordingly. The list will be updated monthly.

We are identifying the initial list for deprecation in release bioc 3.8.  The 
following packages did not fix their packages before the release 3.7 deadline 
and currently have broken packages across all platforms in both Bioc release 
3.7 and Bioc devel 3.8.  Many have been failing for several weeks.  If they are 
not updated in one week we will be considering them for deprecation:


EasyqpcR

IrisSpatialFeatures

eegc


facopy


MoonlightR


RITAN


CustomProDB



The release and devel build reports can be found here:


RELEASE_3_7:  http://bioconductor.org/checkResults/3.7/bioc-LATEST/


DEVEL:  http://bioconductor.org/checkResults/3.8/bioc-LATEST/



Thank you.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


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] class name collision in cache: igvR and Gviz

[Paul Shannon]

Hi Michael,

Thank you for this work and the explanation.  It’s good to know that my problem 
will feed back into improvements in the methods package.

I opted for a simpler workaround, for now, renaming my abstract class to avoid 
the collision.  

 - Paul

> On May 8, 2018, at 8:25 AM, Michael Lawrence  
> wrote:
> 
> Thanks Paul.
> 
> I've made improvements to the methods package so that there will no longer be 
> any messages about AnnotationTrack being duplicated, but I'll need to work 
> through some failures this is causing in tests.
> 
> The first issue is interesting though. Since Gviz defines an initialize() for 
> AnnotationTrack, dispatch ends up using that intsead of the default. That 
> method (incorrectly in my opinion) silently drops unrecognized arguments in 
> "..." so it is effectively a no-op. Ideally the method would eventually call 
> callNextMethod(). Not doing so makes assumptions about how the parent object 
> is initialized. It would also make this case work, just by luck. This is one 
> reason why defining initialize() methods is tricky and should be avoided.
> 
> Unfortunately, the methods package will dispatch to a method, regardless of 
> the package of origin, unless there are methods with signatures containing 
> two or more classes of the same name.  This might be easy to fix but there 
> could be performance regressions. This problem will happen all the time if 
> there are initialize() methods around. You should be able to avoid this just 
> by defining your own initialize() method that just calls the next method. 
> Ideally though Gviz would just drop its one.
> 
> Michael
> 
> On Mon, May 7, 2018 at 11:14 AM, Paul Shannon 
>  wrote:
> Hi Michael,
> 
> > On May 4, 2018, at 1:36 PM, Michael Lawrence  
> > wrote:
> > 
> > Do you have a reproducible example of this? It's probably a bug in the 
> > methods package.
> > 
> 
> Sorry I did not get to this sooner.  Here are two symptoms of the cache class 
> name collision:
> 
>1) igvR::displayTrack, if called after motifbreakR::plotMB, fails (see 
> error message below)
>2) plotMB, if called after igvR is loaded, reports the class name 
> collision.
> 
> - Paul
> 
> library(SNPlocs.Hsapiens.dbSNP150.GRCh38)
> library(BSgenome.Hsapiens.UCSC.hg38)
> library(motifbreakR)
> 
> snp <- "rs12050029"
> 
> snps.gr <- snps.from.rsid(rsid = snp,
>   dbSNP=SNPlocs.Hsapiens.dbSNP150.GRCh38,
>   search.genome=BSgenome.Hsapiens.UCSC.hg38)
> 
> 
> results <- motifbreakR(snpList = snps.gr, filterp = TRUE,
>pwmList = query(MotifDb, "jaspar2018"),
>threshold = 1e-4,
>method = "ic",
>bkg = c(A=0.25, C=0.25, G=0.25, T=0.25),
>BPPARAM = BiocParallel::bpparam("SerialParam"))
> 
> plotMB(results = results, rsid = snp, effect = c("weak", "strong"))
> 
> 
> library(igvR)
> igv <- igvR()
> setGenome(igv, "hg38")
> snp.track <- GRangesAnnotationTrack("snp", snps.gr, color="red")
> displayTrack(igv, snp.track)
> 
># this error is only seen if motifbreakR - and thus Gviz - have been loaded
># otherwise, displayTrack works fine
># Error in if (trackType == "variant" && source == "file" && fileFormat == 
>  :
>#  missing value where TRUE/FALSE
> 
> plotMB(results = results, rsid = snp, effect = c("weak", "strong"))
> 
># Found more than one class "AnnotationTrack" in cache; using the first, 
> from namespace 'Gviz'
># Also defined by 'igvR'
># Found more than one class "AnnotationTrack" in cache; using the first, 
> from namespace 'Gviz'
># Also defined by 'igvR'
># Found more than one class "AnnotationTrack" in cache; using the first, 
> from namespace 'Gviz'
># Also defined by 'igvR'
># Found more than one class "AnnotationTrack" in cache; using the first, 
> from namespace 'Gviz'
># Also defined by 'igvR'
># Found more than one class "AnnotationTrack" in cache; using the first, 
> from namespace 'Gviz'
># Also defined by 'igvR'
># Found more than one class "AnnotationTrack" in cache; using the first, 
> from namespace 'Gviz'
># Also defined by 'igvR'
> 
> 
> 
> 
> 
> > Michael
> > 
> > On Fri, May 4, 2018 at 10:52 AM, Paul Shannon 
> >  wrote:
> > I just discovered a class name collision - AnnotationTrack, in Gviz and my 
> > new package igvR.   wish to get wise counsel before proceeding with a fix.  
> > Here’s the error message:
> > 
> >Found more than one class "AnnotationTrack" in cache; 
> >using the first, from namespace ‘igvR' Also defined by ‘Gviz’
> > 
> > AnnotationTrack is an abstract base class in my new package igvR.  The 
> > concrete derived classes at present are
> > 
> >   DataFrameAnnotationTrack
> >   GRangesAnnotationTrack
> >   UCSCBedAnnotationTrack
> > 
> > It would be 

Re: [Bioc-devel] rsvg on mac

[Kevin Horan]

     Now that this past bioc release is done, and R 3.5 is stable, would 
it be possible to install the "rsvg" package on your build machines? Thanks.

Kevin


On 02/19/2018 02:01 PM, Alexey Sergushichev wrote:
> Valerie, thanks. Will try to ask there.
>
> However, after looking through the mailing list it looks like R-devel 
> builds for OS X aren't trivial and aren't part of CRAN...
>
> --
> Alexey
>
> On Mon, Feb 19, 2018 at 9:05 PM, Obenchain, Valerie 
>  > wrote:
>
> Hi,
>
> There has been some discussion of the devel Mac binaries on the
> R-SIG-Mac mailing list. That list would be the best place to ask
> this question.
>
> https://stat.ethz.ch/pipermail/r-sig-mac/2018-January/thread.html
> 
>
> Valerie
>
>
>
> On 02/19/2018 08:32 AM, Alexey Sergushichev wrote:
>> Valerie,
>>
>> Are there any estimates on how often CRAN OS X builds happen?
>> There are still no builds for rsvg and other packages...
>>
>> Thanks,
>> Alexey
>>
>> On Wed, Feb 7, 2018 at 8:09 PM, Obenchain, Valerie
>> > > wrote:
>>
>> Hi Kevin,
>>
>> CRAN binaries for El Capitan in devel aren't available. You
>> can see this on the rsvg landing page:
>>
>> https://cran.r-project.org/web/packages/rsvg/index.html
>> 
>>
>> Nothing we can do until CRAN makes them available.
>>
>> Valerie
>>
>>
>> On 02/07/2018 08:29 AM, Kevin Horan wrote:
>>
>>
>> The ChemmineR build is failing on the mac due to a new
>> dependency not
>> being available, the package "rsvg". Would it be possible to
>> install
>> that on the mac build machine? Thanks.
>>
>> 
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/ChemmineR/merida2-install.html
>> 
>> 
>>
>>
>> Kevin
>>
>> ___
>> 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
>> 
>>
>>
>
>
> 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] BioC 2018 poster / talk / scholarship / workshop application deadline May 17

[Martin Morgan]

The scholarships support up to $500 travel. The scholarship also covers 
accommodation and registration.


A letter inviting you to the conference will be sent separately.

Martin

On 05/09/2018 01:13 AM, Pijush Das wrote:

Dear Martin Morgan,


Thank you Morgan for informing me to join your annual conference BioC 2018.
I am very much interested to attend the BioC 2018 conference.
Presently I am perusing my PhD from CSIR-Indian Institute of Chemical 
biology.
So it is not possible to collect all the money to pay all the expenses 
myself.



I would like to know if I am selected for the scholarship, they will pay 
for costs such as
travel, accommodation, and registration ? Or they will pay only $500 per 
person?



If it is possible please send me an invitation letter for the annual 
conference BioC 2018.
The invitation letter will help me for grant application to the indian 
funding body such as DBT or CSIR etc.






Thank you



regards
Pijush













On Mon, May 7, 2018 at 2:59 AM, Martin Morgan 
> 
wrote:


Join us for our annual conference BioC 2018: Where Software and
Biology Connect, at Victoria University on the University of Toronto
campus

http://bioc2018.bioconductor.org 

The deadline for poster, talk, scholarship (travel, accommodation,
and registration), and workshop applications is May 17, see

http://bioc2018.bioconductor.org/call-for-abstracts

http://bioc2018.bioconductor.org/scholarships


Martin Morgan
Bioconductor


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

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






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

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

Re: [Rd] download.file does not process gz files correctly (truncates them?)

[Dirk Eddelbuettel]

On 9 May 2018 at 10:37, Tomas Kalibera wrote:
| And for that reason the behavior should be as intuitive as possible when 
| designed. What was intuitive 15-20 years ago may not be intuitive now, 
| but that should probably not be a justification for a change in 
| documented behavior.

Time for downloadFile() (or download_file()) to complement the existing
download.file() but providing what we now think of as intuitive behaviour?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] unlist errors on a nested list of empty lists

[Steven Nydick]

I do not have access to the bug reporting system. If somebody can get me
access, I can create a formal bug report.

The latter issues seem like duplicates of:
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=12572 (with slightly
different output), but as that bug was reported nearly 10 years ago, it
might be worth creating an update under R version 3. I could not find the
first issue when searching the bug reports (which I ran into when trying to
parse JSON files), which is why I posted on r-devel.

On Tue, May 8, 2018 at 7:51 PM Duncan Murdoch 
wrote:

> On 08/05/2018 4:50 PM, Steven Nydick wrote:
> > It also does the same thing if the factor is not on the first level of
> > the list, which seems to be due to the fact that the islistfactor is
> > recursive, but if a list is a list-factor, the first level lists are
> > coerced into character strings.
> >
> >  > x <- list(list(factor(LETTERS[1])))
> >  > unlist(x)
> > Error in as.character.factor(x) : malformed factor
> >
> > However, if one of the factors is at the top level, and one is nested,
> > then the result is:
> >
> >  > x <- list(list(factor(LETTERS[1])), factor(LETTERS[2]))
> >  > unlist(x)
> >
> > [1]  B
> > Levels: B
> >
> > ... which does not seem to me to be desired behavior.
>
> The patch I suggested doesn't help with either of these.  I'd suggest
> collecting examples, and posting a bug report to bugs.r-project.org.
>
> Duncan Murdoch
>
>
> >
> >
> > On Tue, May 8, 2018 at 2:22 PM Duncan Murdoch  > > wrote:
> >
> > On 08/05/2018 2:58 PM, Duncan Murdoch wrote:
> >  > On 08/05/2018 1:48 PM, Steven Nydick wrote:
> >  >> Reproducible example:
> >  >>
> >  >> x <- list(list(list(), list()))
> >  >> unlist(x)
> >  >>
> >  >> *> Error in as.character.factor(x) : malformed factor*
> >  >
> >  > The error comes from the line
> >  >
> >  > structure(res, levels = lv, names = nm, class = "factor")
> >  >
> >  > which is called because unlist() thinks that some entry is a
> factor,
> >  > with NULL levels and NULL names.  It's not legal for a factor to
> have
> >  > NULL levels.  Probably it should never get here; the earlier test
> >  >
> >  > if (.Internal(islistfactor(x, recursive))) {
> >  >
> >  > should have been false, and then the result would have been
> >  >
> >  > .Internal(unlist(x, recursive, use.names))
> >  >
> >  > (with both recursive and use.names being TRUE), which returns
> NULL.
> >
> > And the problem is in the islistfactor function in src/main/apply.c,
> > which looks like this:
> >
> > static Rboolean islistfactor(SEXP X)
> > {
> >   int i, n = length(X);
> >
> >   switch(TYPEOF(X)) {
> >   case VECSXP:
> >   case EXPRSXP:
> >   if(n == 0) return NA_LOGICAL;
> >   for(i = 0; i < LENGTH(X); i++)
> >   if(!islistfactor(VECTOR_ELT(X, i))) return FALSE;
> >   return TRUE;
> >   break;
> >   }
> >   return isFactor(X);
> > }
> >
> > One of those deeply nested lists is length 0, so at the lowest level
> it
> > returns NA_LOGICAL.  But then it does C-style logical testing on the
> > results.  I think to C NA_LOGICAL counts as true, so at the next
> level
> > up we get the wrong answer.
> >
> > A fix would be to rewrite it like this:
> >
> > static Rboolean islistfactor(SEXP X)
> > {
> >   int i, n = length(X);
> >   Rboolean result = NA_LOGICAL, childresult;
> >   switch(TYPEOF(X)) {
> >   case VECSXP:
> >   case EXPRSXP:
> >   for(i = 0; i < LENGTH(X); i++) {
> >   childresult = islistfactor(VECTOR_ELT(X, i));
> >   if(childresult == FALSE) return FALSE;
> >   else if(childresult == TRUE) result = TRUE;
> >   }
> >   return result;
> >   break;
> >   }
> >   return isFactor(X);
> > }
> >
> >
> >
> > --
> > Steven Nydick
> > PhD, Quantitative Psychology
> > M.A., Psychology
> > M.S., Statistics
> > --
> > "Beware of the man who works hard to learn something, learns it, and
> > finds himself no wiser than before, Bokonon tells us. He is full of
> > murderous resentment of people who are ignorant without having come by
> > their ignorance the hard way."
> > -Kurt Vonnegut
>
>

-- 
Steven Nydick
PhD, Quantitative Psychology
M.A., Psychology
M.S., Statistics
--
"Beware of the man who works hard to learn something, learns it, and finds
himself no wiser than before, Bokonon tells us. He is full of murderous
resentment of people who are ignorant without having come by their
ignorance the hard way."
-Kurt Vonnegut

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list

Re: [Rd] download.file does not process gz files correctly (truncates them?)

[peter dalgaard]

There was a hint in the Twitterverse that Excel has issues with line endings in 
.csv. Can anyone elaborate on that? Then again, Excel goes belly-up on comma 
separators in central European locales anyway...

-pd

> On 8 May 2018, at 22:47 , Hadley Wickham  wrote:
> 
> 
> Also note that MS just announced support for unix line endings in notepad
> 
> https://blogs.msdn.microsoft.com/commandline/2018/05/08/extended-eol-in-notepad/
> 
> Hadley
> 

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

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

Re: [Rd] download.file does not process gz files correctly (truncates them?)

[Duncan Murdoch]

On 08/05/2018 4:47 PM, Hadley Wickham wrote:

On Tue, May 8, 2018 at 8:15 AM, Hadley Wickham  wrote:

On Thu, May 3, 2018 at 11:34 PM, Tomas Kalibera
 wrote:

On 05/03/2018 11:14 PM, Henrik Bengtsson wrote:


Also, as mentioned in my
https://stat.ethz.ch/pipermail/r-devel/2012-August/064739.html, when
not specifying the mode argument, the default on Windows is mode = "w"
*except* for certain, case-sensitive, filename extensions:

  if(missing(mode) && length(grep("\\.(gz|bz2|xz|tgz|zip|rda|RData)$",
url)))
  mode <- "wb"

Just like the need for mode = "wb" on Windows, the above
special-file-extension-hack is only happening on Windows, and is only
documented in ?download.file if you're on Windows; so someone who's on
Linux/macOS trying to help someone on Windows may not be aware of
this. This adds to even more confusions, e.g. "works for me".


If we were designing the API today, it would probably make more sense not to
convert any line endings by default. Today's editors _usually_ can cope with
different line endings and it is probably easier to detect that a text file
has incorrect line endings rather than detecting that a binary file has been
corrupted by an attempt to convert line endings. But whether to change
existing, documented behavior is a different question. In order to help
users and programmers who do not read the documentation carefully we would
create problems for users and programmers who do. The current heuristic/hack
is in line with the compatibility approach: it detects files that are
obviously binary, so it changes the default behavior only for cases when it
would obviously cause damage.


 From a purely utilitarian standpoint, there are far more users who do
not carefully read the documentation than users who do ;)

(I'd also argue that basing the decision on the file extension is
suboptimal, and it would be better to use the mime type if provided by
the server)


Also note that MS just announced support for unix line endings in notepad

https://blogs.msdn.microsoft.com/commandline/2018/05/08/extended-eol-in-notepad/


Perhaps soon RStudio will follow Notepad's lead, and not convert line 
endings when it saves a non-native file.


Duncan Murdoch

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

Re: [Rd] download.file does not process gz files correctly (truncates them?)

[Tomas Kalibera]

On 05/08/2018 05:15 PM, Hadley Wickham wrote:

On Thu, May 3, 2018 at 11:34 PM, Tomas Kalibera
 wrote:

On 05/03/2018 11:14 PM, Henrik Bengtsson wrote:

Also, as mentioned in my
https://stat.ethz.ch/pipermail/r-devel/2012-August/064739.html, when
not specifying the mode argument, the default on Windows is mode = "w"
*except* for certain, case-sensitive, filename extensions:

  if(missing(mode) && length(grep("\\.(gz|bz2|xz|tgz|zip|rda|RData)$",
url)))
  mode <- "wb"

Just like the need for mode = "wb" on Windows, the above
special-file-extension-hack is only happening on Windows, and is only
documented in ?download.file if you're on Windows; so someone who's on
Linux/macOS trying to help someone on Windows may not be aware of
this. This adds to even more confusions, e.g. "works for me".

If we were designing the API today, it would probably make more sense not to
convert any line endings by default. Today's editors _usually_ can cope with
different line endings and it is probably easier to detect that a text file
has incorrect line endings rather than detecting that a binary file has been
corrupted by an attempt to convert line endings. But whether to change
existing, documented behavior is a different question. In order to help
users and programmers who do not read the documentation carefully we would
create problems for users and programmers who do. The current heuristic/hack
is in line with the compatibility approach: it detects files that are
obviously binary, so it changes the default behavior only for cases when it
would obviously cause damage.

 From a purely utilitarian standpoint, there are far more users who do
not carefully read the documentation than users who do ;)
And for that reason the behavior should be as intuitive as possible when 
designed. What was intuitive 15-20 years ago may not be intuitive now, 
but that should probably not be a justification for a change in 
documented behavior.

(I'd also argue that basing the decision on the file extension is
suboptimal, and it would be better to use the mime type if provided by
the server)
Yes, that would be nice. Also some binary files could be detected via 
magic numbers (yet not all, e.g. RDS do not have them). It won't be as 
trivial as decoding the URL, though.


Tomas



Hadley



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