Re: [Bioc-devel] namespace question

[Martin Morgan]

On 04/07/2016 03:54 AM, Karim Mezhoud wrote:

unfortunately,

Bioconductor version 3.3 (BiocInstaller 1.21.4), ?biocLite for help
Bioconductor does not yet support R version 3.4.0


The release of Bioconductor on May 4 and the next release in the fall 
will both be based on the R-3.3.* series, because that is the version of 
R that users (rather than 'developers') will have. The spring release 
next year is the first that will use R-devel. Bioconductor will not 
support (has no need to support) R-devel again until after the fall 
release, when the Bioc-devel branch will use R-devel.  So for the next 
six months there is no sense (or support) for Bioconductor packages to 
use features that are only available in R-devel.


Michael has ported this new feature to the R-3-3-0 branch

R-3-3-branch$ svn log -r70426

r70426 | lawrence | 2016-04-05 17:06:10 -0400 (Tue, 05 Apr 2016) | 2 lines

port c70412 from trunk



so that with a sufficiently new R you can use this functionality. The 
build systems will eventually be updated to an appropriately recent 
version of R from the 3-3-branch.


Martin



On Tue, Apr 5, 2016 at 9:17 PM, Michael Lawrence <lawrence.mich...@gene.com>
wrote:


You need R 3.4 for right now.

On Tue, Apr 5, 2016 at 1:16 PM, Karim Mezhoud <kmezh...@gmail.com> wrote:

==> R CMD INSTALL --no-multiarch --with-keep.source bioCancer

* installing to library
‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library’
* installing *source* package ‘bioCancer’ ...
** R
** inst
** preparing package for lazy loading
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck =

vI[[i]]) :

   there is no package called ‘c("dataTableOutput", "renderDataTable")’
ERROR: lazy loading failed for package ‘bioCancer’
* removing


‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/bioCancer’

* restoring previous


‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/bioCancer’


Exited with status 1

On Tue, Apr 5, 2016 at 8:58 PM, Michael Lawrence <

lawrence.mich...@gene.com>

wrote:


Yea, with the closing )

On Tue, Apr 5, 2016 at 12:37 PM, Karim Mezhoud <kmezh...@gmail.com>

wrote:

If I include manually the exception, I hve to write this?

import(shiny, except=c('dataTableOutput','renderDataTable')
Thanks
Karim

On Tue, Apr 5, 2016 at 7:28 PM, Michael Lawrence
<lawrence.mich...@gene.com>
wrote:


Roxygen does not yet support the feature. For now you'll have to live
with the warning or just importFrom(shiny, ...). Maybe there is some
way to manually patch the NAMESPACE with Roxygen?

Honestly, I would recommend against using Roxygen to manage your
NAMESPACE. Just write the thing...



On Tue, Apr 5, 2016 at 11:07 AM, Karim Mezhoud <kmezh...@gmail.com>
wrote:

Hi,
Actually I have conflict between DT and shiny
  Warning: replacing previous import ‘shiny::dataTableOutput’ by
‘DT::dataTableOutput’ when loading ‘bioCancer’
   Warning: replacing previous import ‘shiny::renderDataTable’ by
‘DT::renderDataTable’ when loading ‘bioCancer’

I would like to import shiny except dataTableOutput and
renderDataTable.

#'@import shiny except dataTableOutput renderDataTable
I am using roxygen2
R Under development (unstable) (2016-03-11 r70310)
Which package Can I update to get the new import argument.
Thanks
Karim


On Tue, Apr 5, 2016 at 6:50 PM, Michael Lawrence
<lawrence.mich...@gene.com>
wrote:


I will try to sneak that in since it seems to work and it would be
nice to use it before this Fall.

On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum
<dtene...@fredhutch.org>
wrote:

Michael, do you know if this change will be (or has already

been)

backported into R-3.3.0?

Thanks.
Dan


- Original Message -

From: "Lihua Zhu" <julie@umassmed.edu>
To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "Michael

Lawrence"

<lawrence.mich...@gene.com>
Cc: "bioc-devel" <bioc-devel@r-project.org>
Sent: Tuesday, April 5, 2016 9:49:26 AM
Subject: Re: [Bioc-devel] namespace question



Dan,

That is great! Thanks for letting us know!

Michael, thank for making it happen so quickly! It works like a
charm!

Best,

Julie

On 4/2/16 1:58 PM, "Bioc-devel on behalf of Dan Tenenbaum"
<bioc-devel-boun...@r-project.org on behalf of
dtene...@fredhutch.org>
wrote:


BTW, looks like the change has been made to R-devel:

 CHANGES IN R-devel NEW FEATURES

  * The Œimport()¹ namespace directive now accepts an argument
Œexcept¹
which names symbols to exclude from the imports. The Œexcept¹
expression
should evaluate to a character vector (after substituting

symbols

for
strings). See Writing R Extensions.

URL:









https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.









o

Re: [Bioc-devel] namespace question

[Karim Mezhoud]

unfortunately,

Bioconductor version 3.3 (BiocInstaller 1.21.4), ?biocLite for help
Bioconductor does not yet support R version 3.4.0

On Tue, Apr 5, 2016 at 9:17 PM, Michael Lawrence <lawrence.mich...@gene.com>
wrote:

> You need R 3.4 for right now.
>
> On Tue, Apr 5, 2016 at 1:16 PM, Karim Mezhoud <kmezh...@gmail.com> wrote:
> > ==> R CMD INSTALL --no-multiarch --with-keep.source bioCancer
> >
> > * installing to library
> > ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library’
> > * installing *source* package ‘bioCancer’ ...
> > ** R
> > ** inst
> > ** preparing package for lazy loading
> > Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck =
> vI[[i]]) :
> >   there is no package called ‘c("dataTableOutput", "renderDataTable")’
> > ERROR: lazy loading failed for package ‘bioCancer’
> > * removing
> >
> ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/bioCancer’
> > * restoring previous
> >
> ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/bioCancer’
> >
> > Exited with status 1
> >
> > On Tue, Apr 5, 2016 at 8:58 PM, Michael Lawrence <
> lawrence.mich...@gene.com>
> > wrote:
> >>
> >> Yea, with the closing )
> >>
> >> On Tue, Apr 5, 2016 at 12:37 PM, Karim Mezhoud <kmezh...@gmail.com>
> wrote:
> >> > If I include manually the exception, I hve to write this?
> >> >
> >> > import(shiny, except=c('dataTableOutput','renderDataTable')
> >> > Thanks
> >> > Karim
> >> >
> >> > On Tue, Apr 5, 2016 at 7:28 PM, Michael Lawrence
> >> > <lawrence.mich...@gene.com>
> >> > wrote:
> >> >>
> >> >> Roxygen does not yet support the feature. For now you'll have to live
> >> >> with the warning or just importFrom(shiny, ...). Maybe there is some
> >> >> way to manually patch the NAMESPACE with Roxygen?
> >> >>
> >> >> Honestly, I would recommend against using Roxygen to manage your
> >> >> NAMESPACE. Just write the thing...
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Apr 5, 2016 at 11:07 AM, Karim Mezhoud <kmezh...@gmail.com>
> >> >> wrote:
> >> >> > Hi,
> >> >> > Actually I have conflict between DT and shiny
> >> >> >  Warning: replacing previous import ‘shiny::dataTableOutput’ by
> >> >> > ‘DT::dataTableOutput’ when loading ‘bioCancer’
> >> >> >   Warning: replacing previous import ‘shiny::renderDataTable’ by
> >> >> > ‘DT::renderDataTable’ when loading ‘bioCancer’
> >> >> >
> >> >> > I would like to import shiny except dataTableOutput and
> >> >> > renderDataTable.
> >> >> >
> >> >> > #'@import shiny except dataTableOutput renderDataTable
> >> >> > I am using roxygen2
> >> >> > R Under development (unstable) (2016-03-11 r70310)
> >> >> > Which package Can I update to get the new import argument.
> >> >> > Thanks
> >> >> > Karim
> >> >> >
> >> >> >
> >> >> > On Tue, Apr 5, 2016 at 6:50 PM, Michael Lawrence
> >> >> > <lawrence.mich...@gene.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> I will try to sneak that in since it seems to work and it would be
> >> >> >> nice to use it before this Fall.
> >> >> >>
> >> >> >> On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum
> >> >> >> <dtene...@fredhutch.org>
> >> >> >> wrote:
> >> >> >> > Michael, do you know if this change will be (or has already
> been)
> >> >> >> > backported into R-3.3.0?
> >> >> >> >
> >> >> >> > Thanks.
> >> >> >> > Dan
> >> >> >> >
> >> >> >> >
> >> >> >> > - Original Message -
> >> >> >> >> From: "Lihua Zhu" <julie@umassmed.edu>
> >> >> >> >> To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "Michael
> Lawrence"
> >> >> >> >> <lawrence.mich...@gene.com>
> >> >> >> >> Cc: "bioc-deve

Re: [Bioc-devel] namespace question

[Michael Lawrence]

You need R 3.4 for right now.

On Tue, Apr 5, 2016 at 1:16 PM, Karim Mezhoud <kmezh...@gmail.com> wrote:
> ==> R CMD INSTALL --no-multiarch --with-keep.source bioCancer
>
> * installing to library
> ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library’
> * installing *source* package ‘bioCancer’ ...
> ** R
> ** inst
> ** preparing package for lazy loading
> Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
>   there is no package called ‘c("dataTableOutput", "renderDataTable")’
> ERROR: lazy loading failed for package ‘bioCancer’
> * removing
> ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/bioCancer’
> * restoring previous
> ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/bioCancer’
>
> Exited with status 1
>
> On Tue, Apr 5, 2016 at 8:58 PM, Michael Lawrence <lawrence.mich...@gene.com>
> wrote:
>>
>> Yea, with the closing )
>>
>> On Tue, Apr 5, 2016 at 12:37 PM, Karim Mezhoud <kmezh...@gmail.com> wrote:
>> > If I include manually the exception, I hve to write this?
>> >
>> > import(shiny, except=c('dataTableOutput','renderDataTable')
>> > Thanks
>> > Karim
>> >
>> > On Tue, Apr 5, 2016 at 7:28 PM, Michael Lawrence
>> > <lawrence.mich...@gene.com>
>> > wrote:
>> >>
>> >> Roxygen does not yet support the feature. For now you'll have to live
>> >> with the warning or just importFrom(shiny, ...). Maybe there is some
>> >> way to manually patch the NAMESPACE with Roxygen?
>> >>
>> >> Honestly, I would recommend against using Roxygen to manage your
>> >> NAMESPACE. Just write the thing...
>> >>
>> >>
>> >>
>> >> On Tue, Apr 5, 2016 at 11:07 AM, Karim Mezhoud <kmezh...@gmail.com>
>> >> wrote:
>> >> > Hi,
>> >> > Actually I have conflict between DT and shiny
>> >> >  Warning: replacing previous import ‘shiny::dataTableOutput’ by
>> >> > ‘DT::dataTableOutput’ when loading ‘bioCancer’
>> >> >   Warning: replacing previous import ‘shiny::renderDataTable’ by
>> >> > ‘DT::renderDataTable’ when loading ‘bioCancer’
>> >> >
>> >> > I would like to import shiny except dataTableOutput and
>> >> > renderDataTable.
>> >> >
>> >> > #'@import shiny except dataTableOutput renderDataTable
>> >> > I am using roxygen2
>> >> > R Under development (unstable) (2016-03-11 r70310)
>> >> > Which package Can I update to get the new import argument.
>> >> > Thanks
>> >> > Karim
>> >> >
>> >> >
>> >> > On Tue, Apr 5, 2016 at 6:50 PM, Michael Lawrence
>> >> > <lawrence.mich...@gene.com>
>> >> > wrote:
>> >> >>
>> >> >> I will try to sneak that in since it seems to work and it would be
>> >> >> nice to use it before this Fall.
>> >> >>
>> >> >> On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum
>> >> >> <dtene...@fredhutch.org>
>> >> >> wrote:
>> >> >> > Michael, do you know if this change will be (or has already been)
>> >> >> > backported into R-3.3.0?
>> >> >> >
>> >> >> > Thanks.
>> >> >> > Dan
>> >> >> >
>> >> >> >
>> >> >> > - Original Message -
>> >> >> >> From: "Lihua Zhu" <julie@umassmed.edu>
>> >> >> >> To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "Michael Lawrence"
>> >> >> >> <lawrence.mich...@gene.com>
>> >> >> >> Cc: "bioc-devel" <bioc-devel@r-project.org>
>> >> >> >> Sent: Tuesday, April 5, 2016 9:49:26 AM
>> >> >> >> Subject: Re: [Bioc-devel] namespace question
>> >> >> >
>> >> >> >> Dan,
>> >> >> >>
>> >> >> >> That is great! Thanks for letting us know!
>> >> >> >>
>> >> >> >> Michael, thank for making it happen so quickly! It works like a
>> >> >> >> charm!
>> >> >> >>
>> >> >> >> Best,
>> >> >> >>
>> >> >> >> Ju

Re: [Bioc-devel] namespace question

[Karim Mezhoud]

==> R CMD INSTALL --no-multiarch --with-keep.source bioCancer

* installing to library
‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library’
* installing *source* package ‘bioCancer’ ...
** R
** inst
** preparing package for lazy loading
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]])
:
  there is no package called ‘c("dataTableOutput", "renderDataTable")’
ERROR: lazy loading failed for package ‘bioCancer’
* removing
‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/bioCancer’
* restoring previous
‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/bioCancer’

Exited with status 1

On Tue, Apr 5, 2016 at 8:58 PM, Michael Lawrence <lawrence.mich...@gene.com>
wrote:

> Yea, with the closing )
>
> On Tue, Apr 5, 2016 at 12:37 PM, Karim Mezhoud <kmezh...@gmail.com> wrote:
> > If I include manually the exception, I hve to write this?
> >
> > import(shiny, except=c('dataTableOutput','renderDataTable')
> > Thanks
> > Karim
> >
> > On Tue, Apr 5, 2016 at 7:28 PM, Michael Lawrence <
> lawrence.mich...@gene.com>
> > wrote:
> >>
> >> Roxygen does not yet support the feature. For now you'll have to live
> >> with the warning or just importFrom(shiny, ...). Maybe there is some
> >> way to manually patch the NAMESPACE with Roxygen?
> >>
> >> Honestly, I would recommend against using Roxygen to manage your
> >> NAMESPACE. Just write the thing...
> >>
> >>
> >>
> >> On Tue, Apr 5, 2016 at 11:07 AM, Karim Mezhoud <kmezh...@gmail.com>
> wrote:
> >> > Hi,
> >> > Actually I have conflict between DT and shiny
> >> >  Warning: replacing previous import ‘shiny::dataTableOutput’ by
> >> > ‘DT::dataTableOutput’ when loading ‘bioCancer’
> >> >   Warning: replacing previous import ‘shiny::renderDataTable’ by
> >> > ‘DT::renderDataTable’ when loading ‘bioCancer’
> >> >
> >> > I would like to import shiny except dataTableOutput and
> renderDataTable.
> >> >
> >> > #'@import shiny except dataTableOutput renderDataTable
> >> > I am using roxygen2
> >> > R Under development (unstable) (2016-03-11 r70310)
> >> > Which package Can I update to get the new import argument.
> >> > Thanks
> >> > Karim
> >> >
> >> >
> >> > On Tue, Apr 5, 2016 at 6:50 PM, Michael Lawrence
> >> > <lawrence.mich...@gene.com>
> >> > wrote:
> >> >>
> >> >> I will try to sneak that in since it seems to work and it would be
> >> >> nice to use it before this Fall.
> >> >>
> >> >> On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum <
> dtene...@fredhutch.org>
> >> >> wrote:
> >> >> > Michael, do you know if this change will be (or has already been)
> >> >> > backported into R-3.3.0?
> >> >> >
> >> >> > Thanks.
> >> >> > Dan
> >> >> >
> >> >> >
> >> >> > - Original Message -
> >> >> >> From: "Lihua Zhu" <julie@umassmed.edu>
> >> >> >> To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "Michael Lawrence"
> >> >> >> <lawrence.mich...@gene.com>
> >> >> >> Cc: "bioc-devel" <bioc-devel@r-project.org>
> >> >> >> Sent: Tuesday, April 5, 2016 9:49:26 AM
> >> >> >> Subject: Re: [Bioc-devel] namespace question
> >> >> >
> >> >> >> Dan,
> >> >> >>
> >> >> >> That is great! Thanks for letting us know!
> >> >> >>
> >> >> >> Michael, thank for making it happen so quickly! It works like a
> >> >> >> charm!
> >> >> >>
> >> >> >> Best,
> >> >> >>
> >> >> >> Julie
> >> >> >>
> >> >> >> On 4/2/16 1:58 PM, "Bioc-devel on behalf of Dan Tenenbaum"
> >> >> >> <bioc-devel-boun...@r-project.org on behalf of
> >> >> >> dtene...@fredhutch.org>
> >> >> >> wrote:
> >> >> >>
> >> >> >>>BTW, looks like the change has been made to R-devel:
> >> >> >>>
> >> >> >>> CHANGES IN R-devel NEW FEATURES
> >> >> >>

Re: [Bioc-devel] namespace question

[Michael Lawrence]

Yea, with the closing )

On Tue, Apr 5, 2016 at 12:37 PM, Karim Mezhoud <kmezh...@gmail.com> wrote:
> If I include manually the exception, I hve to write this?
>
> import(shiny, except=c('dataTableOutput','renderDataTable')
> Thanks
> Karim
>
> On Tue, Apr 5, 2016 at 7:28 PM, Michael Lawrence <lawrence.mich...@gene.com>
> wrote:
>>
>> Roxygen does not yet support the feature. For now you'll have to live
>> with the warning or just importFrom(shiny, ...). Maybe there is some
>> way to manually patch the NAMESPACE with Roxygen?
>>
>> Honestly, I would recommend against using Roxygen to manage your
>> NAMESPACE. Just write the thing...
>>
>>
>>
>> On Tue, Apr 5, 2016 at 11:07 AM, Karim Mezhoud <kmezh...@gmail.com> wrote:
>> > Hi,
>> > Actually I have conflict between DT and shiny
>> >  Warning: replacing previous import ‘shiny::dataTableOutput’ by
>> > ‘DT::dataTableOutput’ when loading ‘bioCancer’
>> >   Warning: replacing previous import ‘shiny::renderDataTable’ by
>> > ‘DT::renderDataTable’ when loading ‘bioCancer’
>> >
>> > I would like to import shiny except dataTableOutput and renderDataTable.
>> >
>> > #'@import shiny except dataTableOutput renderDataTable
>> > I am using roxygen2
>> > R Under development (unstable) (2016-03-11 r70310)
>> > Which package Can I update to get the new import argument.
>> > Thanks
>> > Karim
>> >
>> >
>> > On Tue, Apr 5, 2016 at 6:50 PM, Michael Lawrence
>> > <lawrence.mich...@gene.com>
>> > wrote:
>> >>
>> >> I will try to sneak that in since it seems to work and it would be
>> >> nice to use it before this Fall.
>> >>
>> >> On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum <dtene...@fredhutch.org>
>> >> wrote:
>> >> > Michael, do you know if this change will be (or has already been)
>> >> > backported into R-3.3.0?
>> >> >
>> >> > Thanks.
>> >> > Dan
>> >> >
>> >> >
>> >> > - Original Message -
>> >> >> From: "Lihua Zhu" <julie@umassmed.edu>
>> >> >> To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "Michael Lawrence"
>> >> >> <lawrence.mich...@gene.com>
>> >> >> Cc: "bioc-devel" <bioc-devel@r-project.org>
>> >> >> Sent: Tuesday, April 5, 2016 9:49:26 AM
>> >> >> Subject: Re: [Bioc-devel] namespace question
>> >> >
>> >> >> Dan,
>> >> >>
>> >> >> That is great! Thanks for letting us know!
>> >> >>
>> >> >> Michael, thank for making it happen so quickly! It works like a
>> >> >> charm!
>> >> >>
>> >> >> Best,
>> >> >>
>> >> >> Julie
>> >> >>
>> >> >> On 4/2/16 1:58 PM, "Bioc-devel on behalf of Dan Tenenbaum"
>> >> >> <bioc-devel-boun...@r-project.org on behalf of
>> >> >> dtene...@fredhutch.org>
>> >> >> wrote:
>> >> >>
>> >> >>>BTW, looks like the change has been made to R-devel:
>> >> >>>
>> >> >>> CHANGES IN R-devel NEW FEATURES
>> >> >>>
>> >> >>>  * The Œimport()¹ namespace directive now accepts an argument
>> >> >>> Œexcept¹
>> >> >>>which names symbols to exclude from the imports. The Œexcept¹
>> >> >>> expression
>> >> >>>should evaluate to a character vector (after substituting symbols
>> >> >>> for
>> >> >>>strings). See Writing R Extensions.
>> >> >>>
>> >> >>>URL:
>> >>
>> >> >>>
>> >> >>> >>> >>>https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.
>> >>
>> >> >>>
>> >> >>> >>> >>>org_blosxom.cgi_R-2Ddevel_NEWS_2016_04_02-23n2016-2D04-2D02=BQIGaQ=WJB
>> >>
>> >> >>>
>> >> >>> >>> >>>j9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5g
>> >>
>> >> >>>
>> >> >>> >>> >>>JMlij5cC5bLU=HCJuUKMo50mOyj

Re: [Bioc-devel] namespace question

[Karim Mezhoud]

If I include manually the exception, I hve to write this?

import(shiny, except=c('dataTableOutput','renderDataTable')
Thanks
Karim

On Tue, Apr 5, 2016 at 7:28 PM, Michael Lawrence <lawrence.mich...@gene.com>
wrote:

> Roxygen does not yet support the feature. For now you'll have to live
> with the warning or just importFrom(shiny, ...). Maybe there is some
> way to manually patch the NAMESPACE with Roxygen?
>
> Honestly, I would recommend against using Roxygen to manage your
> NAMESPACE. Just write the thing...
>
>
>
> On Tue, Apr 5, 2016 at 11:07 AM, Karim Mezhoud <kmezh...@gmail.com> wrote:
> > Hi,
> > Actually I have conflict between DT and shiny
> >  Warning: replacing previous import ‘shiny::dataTableOutput’ by
> > ‘DT::dataTableOutput’ when loading ‘bioCancer’
> >   Warning: replacing previous import ‘shiny::renderDataTable’ by
> > ‘DT::renderDataTable’ when loading ‘bioCancer’
> >
> > I would like to import shiny except dataTableOutput and renderDataTable.
> >
> > #'@import shiny except dataTableOutput renderDataTable
> > I am using roxygen2
> > R Under development (unstable) (2016-03-11 r70310)
> > Which package Can I update to get the new import argument.
> > Thanks
> > Karim
> >
> >
> > On Tue, Apr 5, 2016 at 6:50 PM, Michael Lawrence <
> lawrence.mich...@gene.com>
> > wrote:
> >>
> >> I will try to sneak that in since it seems to work and it would be
> >> nice to use it before this Fall.
> >>
> >> On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum <dtene...@fredhutch.org>
> >> wrote:
> >> > Michael, do you know if this change will be (or has already been)
> >> > backported into R-3.3.0?
> >> >
> >> > Thanks.
> >> > Dan
> >> >
> >> >
> >> > ----- Original Message -
> >> >> From: "Lihua Zhu" <julie@umassmed.edu>
> >> >> To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "Michael Lawrence"
> >> >> <lawrence.mich...@gene.com>
> >> >> Cc: "bioc-devel" <bioc-devel@r-project.org>
> >> >> Sent: Tuesday, April 5, 2016 9:49:26 AM
> >> >> Subject: Re: [Bioc-devel] namespace question
> >> >
> >> >> Dan,
> >> >>
> >> >> That is great! Thanks for letting us know!
> >> >>
> >> >> Michael, thank for making it happen so quickly! It works like a
> charm!
> >> >>
> >> >> Best,
> >> >>
> >> >> Julie
> >> >>
> >> >> On 4/2/16 1:58 PM, "Bioc-devel on behalf of Dan Tenenbaum"
> >> >> <bioc-devel-boun...@r-project.org on behalf of
> dtene...@fredhutch.org>
> >> >> wrote:
> >> >>
> >> >>>BTW, looks like the change has been made to R-devel:
> >> >>>
> >> >>> CHANGES IN R-devel NEW FEATURES
> >> >>>
> >> >>>  * The Œimport()¹ namespace directive now accepts an argument
> Œexcept¹
> >> >>>which names symbols to exclude from the imports. The Œexcept¹
> >> >>> expression
> >> >>>should evaluate to a character vector (after substituting symbols for
> >> >>>strings). See Writing R Extensions.
> >> >>>
> >> >>>URL:
> >>
> >> >>> >>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.
> >>
> >> >>>
> >>>org_blosxom.cgi_R-2Ddevel_NEWS_2016_04_02-23n2016-2D04-2D02=BQIGaQ=WJB
> >>
> >> >>>
> >>>j9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5g
> >>
> >> >>>
> >>>JMlij5cC5bLU=HCJuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo=MbBj5lNGwkIfP
> >> >>>hrHI2clfQd1aq1yPyROa3utKrCP4ug=
> >> >>>
> >> >>>
> >> >>>
> >> >>>- Original Message -
> >> >>>> From: "Michael Lawrence" <lawrence.mich...@gene.com>
> >> >>>> To: "Hervé Pagès" <hpa...@fredhutch.org>
> >> >>>> Cc: "Michael Lawrence" <lawrence.mich...@gene.com>, "bioc-devel"
> >> >>>><bioc-devel@r-project.org>
> >> >>>> Sent: Saturday, April 2, 2016 4:10:10 AM
> >> >>>> Subject: Re: [Bioc-devel] na

Re: [Bioc-devel] namespace question

[Michael Lawrence]

Roxygen does not yet support the feature. For now you'll have to live
with the warning or just importFrom(shiny, ...). Maybe there is some
way to manually patch the NAMESPACE with Roxygen?

Honestly, I would recommend against using Roxygen to manage your
NAMESPACE. Just write the thing...



On Tue, Apr 5, 2016 at 11:07 AM, Karim Mezhoud <kmezh...@gmail.com> wrote:
> Hi,
> Actually I have conflict between DT and shiny
>  Warning: replacing previous import ‘shiny::dataTableOutput’ by
> ‘DT::dataTableOutput’ when loading ‘bioCancer’
>   Warning: replacing previous import ‘shiny::renderDataTable’ by
> ‘DT::renderDataTable’ when loading ‘bioCancer’
>
> I would like to import shiny except dataTableOutput and renderDataTable.
>
> #'@import shiny except dataTableOutput renderDataTable
> I am using roxygen2
> R Under development (unstable) (2016-03-11 r70310)
> Which package Can I update to get the new import argument.
> Thanks
> Karim
>
>
> On Tue, Apr 5, 2016 at 6:50 PM, Michael Lawrence <lawrence.mich...@gene.com>
> wrote:
>>
>> I will try to sneak that in since it seems to work and it would be
>> nice to use it before this Fall.
>>
>> On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum <dtene...@fredhutch.org>
>> wrote:
>> > Michael, do you know if this change will be (or has already been)
>> > backported into R-3.3.0?
>> >
>> > Thanks.
>> > Dan
>> >
>> >
>> > - Original Message -
>> >> From: "Lihua Zhu" <julie@umassmed.edu>
>> >> To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "Michael Lawrence"
>> >> <lawrence.mich...@gene.com>
>> >> Cc: "bioc-devel" <bioc-devel@r-project.org>
>> >> Sent: Tuesday, April 5, 2016 9:49:26 AM
>> >> Subject: Re: [Bioc-devel] namespace question
>> >
>> >> Dan,
>> >>
>> >> That is great! Thanks for letting us know!
>> >>
>> >> Michael, thank for making it happen so quickly! It works like a charm!
>> >>
>> >> Best,
>> >>
>> >> Julie
>> >>
>> >> On 4/2/16 1:58 PM, "Bioc-devel on behalf of Dan Tenenbaum"
>> >> <bioc-devel-boun...@r-project.org on behalf of dtene...@fredhutch.org>
>> >> wrote:
>> >>
>> >>>BTW, looks like the change has been made to R-devel:
>> >>>
>> >>> CHANGES IN R-devel NEW FEATURES
>> >>>
>> >>>  * The Œimport()¹ namespace directive now accepts an argument Œexcept¹
>> >>>which names symbols to exclude from the imports. The Œexcept¹
>> >>> expression
>> >>>should evaluate to a character vector (after substituting symbols for
>> >>>strings). See Writing R Extensions.
>> >>>
>> >>>URL:
>>
>> >>> >>>https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.
>>
>> >>> >>>org_blosxom.cgi_R-2Ddevel_NEWS_2016_04_02-23n2016-2D04-2D02=BQIGaQ=WJB
>>
>> >>> >>>j9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5g
>>
>> >>> >>>JMlij5cC5bLU=HCJuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo=MbBj5lNGwkIfP
>> >>>hrHI2clfQd1aq1yPyROa3utKrCP4ug=
>> >>>
>> >>>
>> >>>
>> >>>- Original Message -
>> >>>> From: "Michael Lawrence" <lawrence.mich...@gene.com>
>> >>>> To: "Hervé Pagès" <hpa...@fredhutch.org>
>> >>>> Cc: "Michael Lawrence" <lawrence.mich...@gene.com>, "bioc-devel"
>> >>>><bioc-devel@r-project.org>
>> >>>> Sent: Saturday, April 2, 2016 4:10:10 AM
>> >>>> Subject: Re: [Bioc-devel] namespace question
>> >>>
>> >>>> Also, just btw, there are two other places where arbitrary R code can
>> >>>> be evaluated in the NAMESPACE, but no one has abused them yet. as far
>> >>>> as I know. The first argument to if() and the .fixes argument to
>> >>>> useDynLib(). The latter sets the precedent for the except= behavior.
>> >>>> Although someone forgot to document it, you can do .fixes=c("prefix",
>> >>>> "suffix") to both prefix and suffix incoming native symbols.
>> >>>> Currently, the documentation only mentions prefixing. Not sure when
>>

Re: [Bioc-devel] namespace question

[Karim Mezhoud]

Hi,
Actually I have conflict between DT and shiny
 Warning: replacing previous import ‘shiny::dataTableOutput’ by
‘DT::dataTableOutput’ when loading ‘bioCancer’
  Warning: replacing previous import ‘shiny::renderDataTable’ by
‘DT::renderDataTable’ when loading ‘bioCancer’

I would like to import shiny except dataTableOutput and renderDataTable.

#'@import shiny except dataTableOutput renderDataTable
I am using roxygen2
R Under development (unstable) (2016-03-11 r70310)
Which package Can I update to get the new import argument.
Thanks
Karim


On Tue, Apr 5, 2016 at 6:50 PM, Michael Lawrence <lawrence.mich...@gene.com>
wrote:

> I will try to sneak that in since it seems to work and it would be
> nice to use it before this Fall.
>
> On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum <dtene...@fredhutch.org>
> wrote:
> > Michael, do you know if this change will be (or has already been)
> backported into R-3.3.0?
> >
> > Thanks.
> > Dan
> >
> >
> > - Original Message -
> >> From: "Lihua Zhu" <julie@umassmed.edu>
> >> To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "Michael Lawrence" <
> lawrence.mich...@gene.com>
> >> Cc: "bioc-devel" <bioc-devel@r-project.org>
> >> Sent: Tuesday, April 5, 2016 9:49:26 AM
> >> Subject: Re: [Bioc-devel] namespace question
> >
> >> Dan,
> >>
> >> That is great! Thanks for letting us know!
> >>
> >> Michael, thank for making it happen so quickly! It works like a charm!
> >>
> >> Best,
> >>
> >> Julie
> >>
> >> On 4/2/16 1:58 PM, "Bioc-devel on behalf of Dan Tenenbaum"
> >> <bioc-devel-boun...@r-project.org on behalf of dtene...@fredhutch.org>
> >> wrote:
> >>
> >>>BTW, looks like the change has been made to R-devel:
> >>>
> >>> CHANGES IN R-devel NEW FEATURES
> >>>
> >>>  * The Œimport()¹ namespace directive now accepts an argument Œexcept¹
> >>>which names symbols to exclude from the imports. The Œexcept¹ expression
> >>>should evaluate to a character vector (after substituting symbols for
> >>>strings). See Writing R Extensions.
> >>>
> >>>URL:
> >>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.
>
> >>>org_blosxom.cgi_R-2Ddevel_NEWS_2016_04_02-23n2016-2D04-2D02=BQIGaQ=WJB
>
> >>>j9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5g
>
> >>>JMlij5cC5bLU=HCJuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo=MbBj5lNGwkIfP
> >>>hrHI2clfQd1aq1yPyROa3utKrCP4ug=
> >>>
> >>>
> >>>
> >>>- Original Message -
> >>>> From: "Michael Lawrence" <lawrence.mich...@gene.com>
> >>>> To: "Hervé Pagès" <hpa...@fredhutch.org>
> >>>> Cc: "Michael Lawrence" <lawrence.mich...@gene.com>, "bioc-devel"
> >>>><bioc-devel@r-project.org>
> >>>> Sent: Saturday, April 2, 2016 4:10:10 AM
> >>>> Subject: Re: [Bioc-devel] namespace question
> >>>
> >>>> Also, just btw, there are two other places where arbitrary R code can
> >>>> be evaluated in the NAMESPACE, but no one has abused them yet. as far
> >>>> as I know. The first argument to if() and the .fixes argument to
> >>>> useDynLib(). The latter sets the precedent for the except= behavior.
> >>>> Although someone forgot to document it, you can do .fixes=c("prefix",
> >>>> "suffix") to both prefix and suffix incoming native symbols.
> >>>> Currently, the documentation only mentions prefixing. Not sure when
> >>>> suffixing would be desirable.
> >>>>
> >>>>
> >>>> On Fri, Apr 1, 2016 at 4:14 PM, Hervé Pagès <hpa...@fredhutch.org>
> >>>>wrote:
> >>>>> On 04/01/2016 01:39 PM, Michael Lawrence wrote:
> >>>>>>
> >>>>>> Yes, it's arbitrary R code that is evaluated, so paste0() would
> work.
> >>>>>> You're right that it's a big door and could let people do weird
> >>>>>> things. Do you foresee a problem with that?
> >>>>>
> >>>>>
> >>>>> Opening such a big door raises many questions. In addition to
> allowing
> >>>>> people do weird/crazy things (like putting calls to library()
> >

Re: [Bioc-devel] namespace question

[Michael Lawrence]

I will try to sneak that in since it seems to work and it would be
nice to use it before this Fall.

On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum <dtene...@fredhutch.org> wrote:
> Michael, do you know if this change will be (or has already been) backported 
> into R-3.3.0?
>
> Thanks.
> Dan
>
>
> - Original Message -
>> From: "Lihua Zhu" <julie@umassmed.edu>
>> To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "Michael Lawrence" 
>> <lawrence.mich...@gene.com>
>> Cc: "bioc-devel" <bioc-devel@r-project.org>
>> Sent: Tuesday, April 5, 2016 9:49:26 AM
>> Subject: Re: [Bioc-devel] namespace question
>
>> Dan,
>>
>> That is great! Thanks for letting us know!
>>
>> Michael, thank for making it happen so quickly! It works like a charm!
>>
>> Best,
>>
>> Julie
>>
>> On 4/2/16 1:58 PM, "Bioc-devel on behalf of Dan Tenenbaum"
>> <bioc-devel-boun...@r-project.org on behalf of dtene...@fredhutch.org>
>> wrote:
>>
>>>BTW, looks like the change has been made to R-devel:
>>>
>>> CHANGES IN R-devel NEW FEATURES
>>>
>>>  * The Œimport()¹ namespace directive now accepts an argument Œexcept¹
>>>which names symbols to exclude from the imports. The Œexcept¹ expression
>>>should evaluate to a character vector (after substituting symbols for
>>>strings). See Writing R Extensions.
>>>
>>>URL:
>>>https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.
>>>org_blosxom.cgi_R-2Ddevel_NEWS_2016_04_02-23n2016-2D04-2D02=BQIGaQ=WJB
>>>j9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5g
>>>JMlij5cC5bLU=HCJuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo=MbBj5lNGwkIfP
>>>hrHI2clfQd1aq1yPyROa3utKrCP4ug=
>>>
>>>
>>>
>>>- Original Message -
>>>> From: "Michael Lawrence" <lawrence.mich...@gene.com>
>>>> To: "Hervé Pagès" <hpa...@fredhutch.org>
>>>> Cc: "Michael Lawrence" <lawrence.mich...@gene.com>, "bioc-devel"
>>>><bioc-devel@r-project.org>
>>>> Sent: Saturday, April 2, 2016 4:10:10 AM
>>>> Subject: Re: [Bioc-devel] namespace question
>>>
>>>> Also, just btw, there are two other places where arbitrary R code can
>>>> be evaluated in the NAMESPACE, but no one has abused them yet. as far
>>>> as I know. The first argument to if() and the .fixes argument to
>>>> useDynLib(). The latter sets the precedent for the except= behavior.
>>>> Although someone forgot to document it, you can do .fixes=c("prefix",
>>>> "suffix") to both prefix and suffix incoming native symbols.
>>>> Currently, the documentation only mentions prefixing. Not sure when
>>>> suffixing would be desirable.
>>>>
>>>>
>>>> On Fri, Apr 1, 2016 at 4:14 PM, Hervé Pagès <hpa...@fredhutch.org>
>>>>wrote:
>>>>> On 04/01/2016 01:39 PM, Michael Lawrence wrote:
>>>>>>
>>>>>> Yes, it's arbitrary R code that is evaluated, so paste0() would work.
>>>>>> You're right that it's a big door and could let people do weird
>>>>>> things. Do you foresee a problem with that?
>>>>>
>>>>>
>>>>> Opening such a big door raises many questions. In addition to allowing
>>>>> people do weird/crazy things (like putting calls to library()
>>>>> or requireNamespace() etc... in them), NAMESPACE files with arbitrary
>>>>> R code in them become more complicated to maintain and the tools for
>>>>> parsing/processing them also become more complicated to write and
>>>>> maintain.
>>>>>
>>>>> Now we have a new category of errors that can happen at package
>>>>> installation time: errors triggered by the evaluation of the R
>>>>> expressions embedded in the NAMESPACE file. Hopefully 'R CMD INSTALL'
>>>>> will report something that can be understood by mere mortals when this
>>>>> happens.
>>>>>
>>>>> Once you create the feeling that a NAMESPACE file is just a file
>>>>> that contains arbitrary R code then people expect import(), export()
>>>>> etc.. to be ordinary R functions with a man page (being able to do
>>>>> ?import would not hurt actually) and they'll naturally try to do
>>>&g

Re: [Bioc-devel] namespace question

[Dan Tenenbaum]

Michael, do you know if this change will be (or has already been) backported 
into R-3.3.0?

Thanks.
Dan


- Original Message -
> From: "Lihua Zhu" <julie@umassmed.edu>
> To: "Dan Tenenbaum" <dtene...@fredhutch.org>, "Michael Lawrence" 
> <lawrence.mich...@gene.com>
> Cc: "bioc-devel" <bioc-devel@r-project.org>
> Sent: Tuesday, April 5, 2016 9:49:26 AM
> Subject: Re: [Bioc-devel] namespace question

> Dan,
> 
> That is great! Thanks for letting us know!
> 
> Michael, thank for making it happen so quickly! It works like a charm!
> 
> Best,
> 
> Julie
> 
> On 4/2/16 1:58 PM, "Bioc-devel on behalf of Dan Tenenbaum"
> <bioc-devel-boun...@r-project.org on behalf of dtene...@fredhutch.org>
> wrote:
> 
>>BTW, looks like the change has been made to R-devel:
>>
>> CHANGES IN R-devel NEW FEATURES
>>
>>  * The Œimport()¹ namespace directive now accepts an argument Œexcept¹
>>which names symbols to exclude from the imports. The Œexcept¹ expression
>>should evaluate to a character vector (after substituting symbols for
>>strings). See Writing R Extensions.
>>
>>URL:
>>https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.
>>org_blosxom.cgi_R-2Ddevel_NEWS_2016_04_02-23n2016-2D04-2D02=BQIGaQ=WJB
>>j9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5g
>>JMlij5cC5bLU=HCJuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo=MbBj5lNGwkIfP
>>hrHI2clfQd1aq1yPyROa3utKrCP4ug=
>>
>>
>>
>>- Original Message -
>>> From: "Michael Lawrence" <lawrence.mich...@gene.com>
>>> To: "Hervé Pagès" <hpa...@fredhutch.org>
>>> Cc: "Michael Lawrence" <lawrence.mich...@gene.com>, "bioc-devel"
>>><bioc-devel@r-project.org>
>>> Sent: Saturday, April 2, 2016 4:10:10 AM
>>> Subject: Re: [Bioc-devel] namespace question
>>
>>> Also, just btw, there are two other places where arbitrary R code can
>>> be evaluated in the NAMESPACE, but no one has abused them yet. as far
>>> as I know. The first argument to if() and the .fixes argument to
>>> useDynLib(). The latter sets the precedent for the except= behavior.
>>> Although someone forgot to document it, you can do .fixes=c("prefix",
>>> "suffix") to both prefix and suffix incoming native symbols.
>>> Currently, the documentation only mentions prefixing. Not sure when
>>> suffixing would be desirable.
>>> 
>>> 
>>> On Fri, Apr 1, 2016 at 4:14 PM, Hervé Pagès <hpa...@fredhutch.org>
>>>wrote:
>>>> On 04/01/2016 01:39 PM, Michael Lawrence wrote:
>>>>>
>>>>> Yes, it's arbitrary R code that is evaluated, so paste0() would work.
>>>>> You're right that it's a big door and could let people do weird
>>>>> things. Do you foresee a problem with that?
>>>>
>>>>
>>>> Opening such a big door raises many questions. In addition to allowing
>>>> people do weird/crazy things (like putting calls to library()
>>>> or requireNamespace() etc... in them), NAMESPACE files with arbitrary
>>>> R code in them become more complicated to maintain and the tools for
>>>> parsing/processing them also become more complicated to write and
>>>> maintain.
>>>>
>>>> Now we have a new category of errors that can happen at package
>>>> installation time: errors triggered by the evaluation of the R
>>>> expressions embedded in the NAMESPACE file. Hopefully 'R CMD INSTALL'
>>>> will report something that can be understood by mere mortals when this
>>>> happens.
>>>>
>>>> Once you create the feeling that a NAMESPACE file is just a file
>>>> that contains arbitrary R code then people expect import(), export()
>>>> etc.. to be ordinary R functions with a man page (being able to do
>>>> ?import would not hurt actually) and they'll naturally try to do
>>>> things like
>>>>
>>>>   unwanted_foo_symbols <- ... long and complicated expression
>>>>   eventually calling user-defined helper
>>>>   functions located in the NAMESPACE file
>>>>...
>>>>   import(foo, except=unwanted_foo_symbols)
>>>>
>>>> Can't blame them for that. But is this the kind of things that we're
>>>> ready to see in NAMESPACE files?
>>>>
>>>

Re: [Bioc-devel] namespace question

[Zhu, Lihua (Julie)]

Dan,

That is great! Thanks for letting us know!

Michael, thank for making it happen so quickly! It works like a charm!

Best,

Julie

On 4/2/16 1:58 PM, "Bioc-devel on behalf of Dan Tenenbaum"
<bioc-devel-boun...@r-project.org on behalf of dtene...@fredhutch.org>
wrote:

>BTW, looks like the change has been made to R-devel:
>
> CHANGES IN R-devel NEW FEATURES
>
>  * The Œimport()¹ namespace directive now accepts an argument Œexcept¹
>which names symbols to exclude from the imports. The Œexcept¹ expression
>should evaluate to a character vector (after substituting symbols for
>strings). See Writing R Extensions.
>
>URL: 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.
>org_blosxom.cgi_R-2Ddevel_NEWS_2016_04_02-23n2016-2D04-2D02=BQIGaQ=WJB
>j9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5g
>JMlij5cC5bLU=HCJuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo=MbBj5lNGwkIfP
>hrHI2clfQd1aq1yPyROa3utKrCP4ug=
>
>
>
>- Original Message -
>> From: "Michael Lawrence" <lawrence.mich...@gene.com>
>> To: "Hervé Pagès" <hpa...@fredhutch.org>
>> Cc: "Michael Lawrence" <lawrence.mich...@gene.com>, "bioc-devel"
>><bioc-devel@r-project.org>
>> Sent: Saturday, April 2, 2016 4:10:10 AM
>> Subject: Re: [Bioc-devel] namespace question
>
>> Also, just btw, there are two other places where arbitrary R code can
>> be evaluated in the NAMESPACE, but no one has abused them yet. as far
>> as I know. The first argument to if() and the .fixes argument to
>> useDynLib(). The latter sets the precedent for the except= behavior.
>> Although someone forgot to document it, you can do .fixes=c("prefix",
>> "suffix") to both prefix and suffix incoming native symbols.
>> Currently, the documentation only mentions prefixing. Not sure when
>> suffixing would be desirable.
>> 
>> 
>> On Fri, Apr 1, 2016 at 4:14 PM, Hervé Pagès <hpa...@fredhutch.org>
>>wrote:
>>> On 04/01/2016 01:39 PM, Michael Lawrence wrote:
>>>>
>>>> Yes, it's arbitrary R code that is evaluated, so paste0() would work.
>>>> You're right that it's a big door and could let people do weird
>>>> things. Do you foresee a problem with that?
>>>
>>>
>>> Opening such a big door raises many questions. In addition to allowing
>>> people do weird/crazy things (like putting calls to library()
>>> or requireNamespace() etc... in them), NAMESPACE files with arbitrary
>>> R code in them become more complicated to maintain and the tools for
>>> parsing/processing them also become more complicated to write and
>>> maintain.
>>>
>>> Now we have a new category of errors that can happen at package
>>> installation time: errors triggered by the evaluation of the R
>>> expressions embedded in the NAMESPACE file. Hopefully 'R CMD INSTALL'
>>> will report something that can be understood by mere mortals when this
>>> happens.
>>>
>>> Once you create the feeling that a NAMESPACE file is just a file
>>> that contains arbitrary R code then people expect import(), export()
>>> etc.. to be ordinary R functions with a man page (being able to do
>>> ?import would not hurt actually) and they'll naturally try to do
>>> things like
>>>
>>>   unwanted_foo_symbols <- ... long and complicated expression
>>>   eventually calling user-defined helper
>>>   functions located in the NAMESPACE file
>>>...
>>>   import(foo, except=unwanted_foo_symbols)
>>>
>>> Can't blame them for that. But is this the kind of things that we're
>>> ready to see in NAMESPACE files?
>>>
>>> Also once you've open that door, people will naturally wonder why they
>>> can use an R expression in the 'except' part of import( , except=) but
>>> not elsewhere e.g. in
>>>
>>>   import(foo, only=paste0("bar", 1:10))
>>>
>>> as a more elegant way of doing importFrom(foo, bar1, bar2, ..., bar10).
>>> This dissymmetry between the syntax of "import only this" and "import
>>> all except this" feels very arbitrary. If you don't support the
>>> import( , only=) syntax, people might legitimately ask things like
>>>
>>>   do.call(importFrom, c(list("foo"), as.list(paste0("bar", 1:10
>>>
>>> to work. Again, can't blame them for that. But do we want this kind of
>>> 

Re: [Bioc-devel] namespace question

[Dan Tenenbaum]

BTW, looks like the change has been made to R-devel:

 CHANGES IN R-devel NEW FEATURES 

  * The ‘import()’ namespace directive now accepts an argument ‘except’ which 
names symbols to exclude from the imports. The ‘except’ expression should 
evaluate to a character vector (after substituting symbols for strings). See 
Writing R Extensions.

URL: 
http://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2016/04/02#n2016-04-02



- Original Message -
> From: "Michael Lawrence" <lawrence.mich...@gene.com>
> To: "Hervé Pagès" <hpa...@fredhutch.org>
> Cc: "Michael Lawrence" <lawrence.mich...@gene.com>, "bioc-devel" 
> <bioc-devel@r-project.org>
> Sent: Saturday, April 2, 2016 4:10:10 AM
> Subject: Re: [Bioc-devel] namespace question

> Also, just btw, there are two other places where arbitrary R code can
> be evaluated in the NAMESPACE, but no one has abused them yet. as far
> as I know. The first argument to if() and the .fixes argument to
> useDynLib(). The latter sets the precedent for the except= behavior.
> Although someone forgot to document it, you can do .fixes=c("prefix",
> "suffix") to both prefix and suffix incoming native symbols.
> Currently, the documentation only mentions prefixing. Not sure when
> suffixing would be desirable.
> 
> 
> On Fri, Apr 1, 2016 at 4:14 PM, Hervé Pagès <hpa...@fredhutch.org> wrote:
>> On 04/01/2016 01:39 PM, Michael Lawrence wrote:
>>>
>>> Yes, it's arbitrary R code that is evaluated, so paste0() would work.
>>> You're right that it's a big door and could let people do weird
>>> things. Do you foresee a problem with that?
>>
>>
>> Opening such a big door raises many questions. In addition to allowing
>> people do weird/crazy things (like putting calls to library()
>> or requireNamespace() etc... in them), NAMESPACE files with arbitrary
>> R code in them become more complicated to maintain and the tools for
>> parsing/processing them also become more complicated to write and
>> maintain.
>>
>> Now we have a new category of errors that can happen at package
>> installation time: errors triggered by the evaluation of the R
>> expressions embedded in the NAMESPACE file. Hopefully 'R CMD INSTALL'
>> will report something that can be understood by mere mortals when this
>> happens.
>>
>> Once you create the feeling that a NAMESPACE file is just a file
>> that contains arbitrary R code then people expect import(), export()
>> etc.. to be ordinary R functions with a man page (being able to do
>> ?import would not hurt actually) and they'll naturally try to do
>> things like
>>
>>   unwanted_foo_symbols <- ... long and complicated expression
>>   eventually calling user-defined helper
>>   functions located in the NAMESPACE file ...
>>   import(foo, except=unwanted_foo_symbols)
>>
>> Can't blame them for that. But is this the kind of things that we're
>> ready to see in NAMESPACE files?
>>
>> Also once you've open that door, people will naturally wonder why they
>> can use an R expression in the 'except' part of import( , except=) but
>> not elsewhere e.g. in
>>
>>   import(foo, only=paste0("bar", 1:10))
>>
>> as a more elegant way of doing importFrom(foo, bar1, bar2, ..., bar10).
>> This dissymmetry between the syntax of "import only this" and "import
>> all except this" feels very arbitrary. If you don't support the
>> import( , only=) syntax, people might legitimately ask things like
>>
>>   do.call(importFrom, c(list("foo"), as.list(paste0("bar", 1:10
>>
>> to work. Again, can't blame them for that. But do we want this kind of
>> things to work? I'm worried debugging NAMESPACE files would become a
>> full-time job...
>>
>>> I guess one could have implemented NAMESPACE parsing by evaluating the
>>> code in an environment (inheriting from the base namespace) where
>>> import(), export(), etc, were defined. Maybe there's a good reason why
>>> it was not implemented that way.
>>
>>
>> I'm sure there is ;-)
>>
>> H.
>>
>>
>>>
>>> On Fri, Apr 1, 2016 at 12:55 PM, Hervé Pagès <hpa...@fredhutch.org> wrote:
>>>>
>>>> On 03/31/2016 04:07 PM, Michael Lawrence wrote:
>>>>>
>>>>>
>>>>> I agree. The importExcept idea also works that way: importExcept(foo,
>>>>> bar,
>>>>> baz)
>>>>>
>>>>

Re: [Bioc-devel] namespace question

[Michael Lawrence]

Also, just btw, there are two other places where arbitrary R code can
be evaluated in the NAMESPACE, but no one has abused them yet. as far
as I know. The first argument to if() and the .fixes argument to
useDynLib(). The latter sets the precedent for the except= behavior.
Although someone forgot to document it, you can do .fixes=c("prefix",
"suffix") to both prefix and suffix incoming native symbols.
Currently, the documentation only mentions prefixing. Not sure when
suffixing would be desirable.


On Fri, Apr 1, 2016 at 4:14 PM, Hervé Pagès  wrote:
> On 04/01/2016 01:39 PM, Michael Lawrence wrote:
>>
>> Yes, it's arbitrary R code that is evaluated, so paste0() would work.
>> You're right that it's a big door and could let people do weird
>> things. Do you foresee a problem with that?
>
>
> Opening such a big door raises many questions. In addition to allowing
> people do weird/crazy things (like putting calls to library()
> or requireNamespace() etc... in them), NAMESPACE files with arbitrary
> R code in them become more complicated to maintain and the tools for
> parsing/processing them also become more complicated to write and
> maintain.
>
> Now we have a new category of errors that can happen at package
> installation time: errors triggered by the evaluation of the R
> expressions embedded in the NAMESPACE file. Hopefully 'R CMD INSTALL'
> will report something that can be understood by mere mortals when this
> happens.
>
> Once you create the feeling that a NAMESPACE file is just a file
> that contains arbitrary R code then people expect import(), export()
> etc.. to be ordinary R functions with a man page (being able to do
> ?import would not hurt actually) and they'll naturally try to do
> things like
>
>   unwanted_foo_symbols <- ... long and complicated expression
>   eventually calling user-defined helper
>   functions located in the NAMESPACE file ...
>   import(foo, except=unwanted_foo_symbols)
>
> Can't blame them for that. But is this the kind of things that we're
> ready to see in NAMESPACE files?
>
> Also once you've open that door, people will naturally wonder why they
> can use an R expression in the 'except' part of import( , except=) but
> not elsewhere e.g. in
>
>   import(foo, only=paste0("bar", 1:10))
>
> as a more elegant way of doing importFrom(foo, bar1, bar2, ..., bar10).
> This dissymmetry between the syntax of "import only this" and "import
> all except this" feels very arbitrary. If you don't support the
> import( , only=) syntax, people might legitimately ask things like
>
>   do.call(importFrom, c(list("foo"), as.list(paste0("bar", 1:10
>
> to work. Again, can't blame them for that. But do we want this kind of
> things to work? I'm worried debugging NAMESPACE files would become a
> full-time job...
>
>> I guess one could have implemented NAMESPACE parsing by evaluating the
>> code in an environment (inheriting from the base namespace) where
>> import(), export(), etc, were defined. Maybe there's a good reason why
>> it was not implemented that way.
>
>
> I'm sure there is ;-)
>
> H.
>
>
>>
>> On Fri, Apr 1, 2016 at 12:55 PM, Hervé Pagès  wrote:
>>>
>>> On 03/31/2016 04:07 PM, Michael Lawrence wrote:


 I agree. The importExcept idea also works that way: importExcept(foo,
 bar,
 baz)

 But import(foo, except=c(bar, baz)) reads better.
>>>
>>>
>>>
>>> mmh... so R expressions with calls to base functions like base::c() are
>>> making their way in the NAMESPACE file. That's opening a big door. Does
>>> that mean that we'll be able to do things like:
>>>
>>> import(foo, except=paste0("bar", 1:10))
>>>
>>> Or maybe c(bar, baz) in your above example is just an arbitrary syntax
>>> that just happens to look like an R expression but won't be evaluated
>>> as such?
>>>
>>>
>>> H.
>>>


 On Thu, Mar 31, 2016 at 4:00 PM,   wrote:
>
>
> I don't think you want to separate it from the import. Better to allow
> something like
>
> import(foo, exclude=bar)
>
> or
>
> import(foo, exclude=c("bar", "baz"))
>
> This seems reasonably natural and shouldn't be too hard to
> implement. (But is has been a while since I've worked on this code).
>
> Best,
>
> luke
>
>
> On Thu, 31 Mar 2016, Karim Mezhoud wrote:
>
>> I think "From" is needed to specify which package we want to exlude
>> functions.
>>
>> I think  excludeFrom (package, function)  seems to be intuitive.
>>
>> thanks,
>> Karim
>>
>>
>>
>> On Thu, Mar 31, 2016 at 9:54 PM, Hervé Pagès 
>> wrote:
>>
>>> On 03/31/2016 12:55 PM, Michael Lawrence wrote:
>>>
 Probably should just stick to exact symbols for now. If there is a
 case where a pattern is actually useful, rather than just an
 

Re: [Bioc-devel] namespace question

[Michael Lawrence]

At the same time, it would empower developers, who should be free to
assume their own risks. There are already many ways an R user can
break things.

But I agree with the simplicity argument. NAMESPACE, while conforming
to R syntax, does not have "standard" R semantics. Mixing semantics,
especially within the same general syntax, is confusing. It would
become difficult to document the rules to which a valid NAMESPACE file
must conform.

One solution would be to support defining a namespace in pure R via a
NAMESPACE.R that is evaluated in a special environment where the
import/export functions are defined. It would be required to pass
symbols as character vectors. I'm not going there though.

I do think that the current NAMESPACE parser could be simplified by
evaluating the code in a highly constrained environment, only
borrowing if() from base.

For now though I will just change it to only support 'c'. Or, what
about this syntax:

import(foo, except(bar, baz))

Not so R-like but seems to fit in with all of the variadic calls in NAMESPACE.

Michael

On Fri, Apr 1, 2016 at 4:14 PM, Hervé Pagès  wrote:
> On 04/01/2016 01:39 PM, Michael Lawrence wrote:
>>
>> Yes, it's arbitrary R code that is evaluated, so paste0() would work.
>> You're right that it's a big door and could let people do weird
>> things. Do you foresee a problem with that?
>
>
> Opening such a big door raises many questions. In addition to allowing
> people do weird/crazy things (like putting calls to library()
> or requireNamespace() etc... in them), NAMESPACE files with arbitrary
> R code in them become more complicated to maintain and the tools for
> parsing/processing them also become more complicated to write and
> maintain.
>
> Now we have a new category of errors that can happen at package
> installation time: errors triggered by the evaluation of the R
> expressions embedded in the NAMESPACE file. Hopefully 'R CMD INSTALL'
> will report something that can be understood by mere mortals when this
> happens.
>
> Once you create the feeling that a NAMESPACE file is just a file
> that contains arbitrary R code then people expect import(), export()
> etc.. to be ordinary R functions with a man page (being able to do
> ?import would not hurt actually) and they'll naturally try to do
> things like
>
>   unwanted_foo_symbols <- ... long and complicated expression
>   eventually calling user-defined helper
>   functions located in the NAMESPACE file ...
>   import(foo, except=unwanted_foo_symbols)
>
> Can't blame them for that. But is this the kind of things that we're
> ready to see in NAMESPACE files?
>
> Also once you've open that door, people will naturally wonder why they
> can use an R expression in the 'except' part of import( , except=) but
> not elsewhere e.g. in
>
>   import(foo, only=paste0("bar", 1:10))
>
> as a more elegant way of doing importFrom(foo, bar1, bar2, ..., bar10).
> This dissymmetry between the syntax of "import only this" and "import
> all except this" feels very arbitrary. If you don't support the
> import( , only=) syntax, people might legitimately ask things like
>
>   do.call(importFrom, c(list("foo"), as.list(paste0("bar", 1:10
>
> to work. Again, can't blame them for that. But do we want this kind of
> things to work? I'm worried debugging NAMESPACE files would become a
> full-time job...
>
>> I guess one could have implemented NAMESPACE parsing by evaluating the
>> code in an environment (inheriting from the base namespace) where
>> import(), export(), etc, were defined. Maybe there's a good reason why
>> it was not implemented that way.
>
>
> I'm sure there is ;-)
>
> H.
>
>
>>
>> On Fri, Apr 1, 2016 at 12:55 PM, Hervé Pagès  wrote:
>>>
>>> On 03/31/2016 04:07 PM, Michael Lawrence wrote:


 I agree. The importExcept idea also works that way: importExcept(foo,
 bar,
 baz)

 But import(foo, except=c(bar, baz)) reads better.
>>>
>>>
>>>
>>> mmh... so R expressions with calls to base functions like base::c() are
>>> making their way in the NAMESPACE file. That's opening a big door. Does
>>> that mean that we'll be able to do things like:
>>>
>>> import(foo, except=paste0("bar", 1:10))
>>>
>>> Or maybe c(bar, baz) in your above example is just an arbitrary syntax
>>> that just happens to look like an R expression but won't be evaluated
>>> as such?
>>>
>>>
>>> H.
>>>


 On Thu, Mar 31, 2016 at 4:00 PM,   wrote:
>
>
> I don't think you want to separate it from the import. Better to allow
> something like
>
> import(foo, exclude=bar)
>
> or
>
> import(foo, exclude=c("bar", "baz"))
>
> This seems reasonably natural and shouldn't be too hard to
> implement. (But is has been a while since I've worked on this code).
>
> Best,
>
> luke
>
>
> On Thu, 31 Mar 2016, Karim Mezhoud 

Re: [Bioc-devel] namespace question

[Hervé Pagès]

On 04/01/2016 01:39 PM, Michael Lawrence wrote:

Yes, it's arbitrary R code that is evaluated, so paste0() would work.
You're right that it's a big door and could let people do weird
things. Do you foresee a problem with that?


Opening such a big door raises many questions. In addition to allowing
people do weird/crazy things (like putting calls to library()
or requireNamespace() etc... in them), NAMESPACE files with arbitrary
R code in them become more complicated to maintain and the tools for
parsing/processing them also become more complicated to write and
maintain.

Now we have a new category of errors that can happen at package
installation time: errors triggered by the evaluation of the R
expressions embedded in the NAMESPACE file. Hopefully 'R CMD INSTALL'
will report something that can be understood by mere mortals when this
happens.

Once you create the feeling that a NAMESPACE file is just a file
that contains arbitrary R code then people expect import(), export()
etc.. to be ordinary R functions with a man page (being able to do
?import would not hurt actually) and they'll naturally try to do
things like

  unwanted_foo_symbols <- ... long and complicated expression
  eventually calling user-defined helper
  functions located in the NAMESPACE file ...
  import(foo, except=unwanted_foo_symbols)

Can't blame them for that. But is this the kind of things that we're
ready to see in NAMESPACE files?

Also once you've open that door, people will naturally wonder why they
can use an R expression in the 'except' part of import( , except=) but
not elsewhere e.g. in

  import(foo, only=paste0("bar", 1:10))

as a more elegant way of doing importFrom(foo, bar1, bar2, ..., bar10).
This dissymmetry between the syntax of "import only this" and "import
all except this" feels very arbitrary. If you don't support the
import( , only=) syntax, people might legitimately ask things like

  do.call(importFrom, c(list("foo"), as.list(paste0("bar", 1:10

to work. Again, can't blame them for that. But do we want this kind of
things to work? I'm worried debugging NAMESPACE files would become a
full-time job...


I guess one could have implemented NAMESPACE parsing by evaluating the
code in an environment (inheriting from the base namespace) where
import(), export(), etc, were defined. Maybe there's a good reason why
it was not implemented that way.


I'm sure there is ;-)

H.



On Fri, Apr 1, 2016 at 12:55 PM, Hervé Pagès  wrote:

On 03/31/2016 04:07 PM, Michael Lawrence wrote:


I agree. The importExcept idea also works that way: importExcept(foo, bar,
baz)

But import(foo, except=c(bar, baz)) reads better.



mmh... so R expressions with calls to base functions like base::c() are
making their way in the NAMESPACE file. That's opening a big door. Does
that mean that we'll be able to do things like:

import(foo, except=paste0("bar", 1:10))

Or maybe c(bar, baz) in your above example is just an arbitrary syntax
that just happens to look like an R expression but won't be evaluated
as such?


H.




On Thu, Mar 31, 2016 at 4:00 PM,   wrote:


I don't think you want to separate it from the import. Better to allow
something like

import(foo, exclude=bar)

or

import(foo, exclude=c("bar", "baz"))

This seems reasonably natural and shouldn't be too hard to
implement. (But is has been a while since I've worked on this code).

Best,

luke


On Thu, 31 Mar 2016, Karim Mezhoud wrote:


I think "From" is needed to specify which package we want to exlude
functions.

I think  excludeFrom (package, function)  seems to be intuitive.

thanks,
Karim



On Thu, Mar 31, 2016 at 9:54 PM, Hervé Pagès 
wrote:


On 03/31/2016 12:55 PM, Michael Lawrence wrote:


Probably should just stick to exact symbols for now. If there is a
case where a pattern is actually useful, rather than just an
obfuscation, we can extend the feature set.



Fair enough. Not really intuitive that excludeImport uses the same
syntax as (but does the opposite of) importFrom though. Maybe having
the name of the directive start with "import" would help e.g.

importExcept(hash, values)  # opposite of importFrom(hash, values)

Thanks,
H.




On Thu, Mar 31, 2016 at 12:11 PM, Zhu, Lihua (Julie)
 wrote:


Herve,

That is a very interesting idea and works for me! Thanks!

importPatternFrom(IRanges, "^values$")


Best,

Julie

On 3/31/16 2:51 PM, "Bioc-devel on behalf of Hervé Pagès"

wrote:

On 03/30/2016 08:35 PM, Michael Lawrence wrote:





That would work, but R is not going to be happy about redundant
imports. Interactively, users would balk at symbol qualification.

There are two classes of conflict:
1) Same semantics, where a common generic would arbitrate, or one
package could depend on the other, and
2) Different semantics, in which case one of the 

Re: [Bioc-devel] namespace question

[Michael Lawrence]

Yes, it's arbitrary R code that is evaluated, so paste0() would work.
You're right that it's a big door and could let people do weird
things. Do you foresee a problem with that?

I guess one could have implemented NAMESPACE parsing by evaluating the
code in an environment (inheriting from the base namespace) where
import(), export(), etc, were defined. Maybe there's a good reason why
it was not implemented that way.

On Fri, Apr 1, 2016 at 12:55 PM, Hervé Pagès  wrote:
> On 03/31/2016 04:07 PM, Michael Lawrence wrote:
>>
>> I agree. The importExcept idea also works that way: importExcept(foo, bar,
>> baz)
>>
>> But import(foo, except=c(bar, baz)) reads better.
>
>
> mmh... so R expressions with calls to base functions like base::c() are
> making their way in the NAMESPACE file. That's opening a big door. Does
> that mean that we'll be able to do things like:
>
> import(foo, except=paste0("bar", 1:10))
>
> Or maybe c(bar, baz) in your above example is just an arbitrary syntax
> that just happens to look like an R expression but won't be evaluated
> as such?
>
>
> H.
>
>>
>>
>> On Thu, Mar 31, 2016 at 4:00 PM,   wrote:
>>>
>>> I don't think you want to separate it from the import. Better to allow
>>> something like
>>>
>>> import(foo, exclude=bar)
>>>
>>> or
>>>
>>> import(foo, exclude=c("bar", "baz"))
>>>
>>> This seems reasonably natural and shouldn't be too hard to
>>> implement. (But is has been a while since I've worked on this code).
>>>
>>> Best,
>>>
>>> luke
>>>
>>>
>>> On Thu, 31 Mar 2016, Karim Mezhoud wrote:
>>>
 I think "From" is needed to specify which package we want to exlude
 functions.

 I think  excludeFrom (package, function)  seems to be intuitive.

 thanks,
 Karim



 On Thu, Mar 31, 2016 at 9:54 PM, Hervé Pagès 
 wrote:

> On 03/31/2016 12:55 PM, Michael Lawrence wrote:
>
>> Probably should just stick to exact symbols for now. If there is a
>> case where a pattern is actually useful, rather than just an
>> obfuscation, we can extend the feature set.
>>
>
> Fair enough. Not really intuitive that excludeImport uses the same
> syntax as (but does the opposite of) importFrom though. Maybe having
> the name of the directive start with "import" would help e.g.
>
> importExcept(hash, values)  # opposite of importFrom(hash, values)
>
> Thanks,
> H.
>
>
>
>> On Thu, Mar 31, 2016 at 12:11 PM, Zhu, Lihua (Julie)
>>  wrote:
>>
>>> Herve,
>>>
>>> That is a very interesting idea and works for me! Thanks!
>>>
>>> importPatternFrom(IRanges, "^values$")
>>>
>>>
>>> Best,
>>>
>>> Julie
>>>
>>> On 3/31/16 2:51 PM, "Bioc-devel on behalf of Hervé Pagès"
>>> 
>>> wrote:
>>>
>>> On 03/30/2016 08:35 PM, Michael Lawrence wrote:



> That would work, but R is not going to be happy about redundant
> imports. Interactively, users would balk at symbol qualification.
>
> There are two classes of conflict:
> 1) Same semantics, where a common generic would arbitrate, or one
> package could depend on the other, and
> 2) Different semantics, in which case one of the functions should
> probably be renamed, although that might not be practical or easy
> to
> agree upon.
>
> When those approaches fail, qualification is the only recourse.
>
> I will think about adding an excludeImport() or importAs().
>

 What about having something like an importPatternFrom() directive
 similar to the exportPattern() directive and have these directives
 support some of the grep() toggles like 'ignore.case', 'fixed',
 'invert' etc... ?

 Then Julie could just do:

 importPatternFrom(hash, "^values$", invert=TRUE)

 H.


>
> On Wed, Mar 30, 2016 at 8:20 PM, Robert M. Flight
> >
>>
> wrote:
>
>> In the cases of having conflicting names, is it not appropriate
>> then
>> to use
>> the "package::function" form for calling a particular function?
>>
>> On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence
>> 
>> wrote:
>>
>> I can't find the hash function in IRanges. Are you sure it has
>> one?
>>>
>>>
>>>
>>> On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
>>>  wrote:
>>>
 Michael,

 I have the same user case as Kasper. Another example is that

Re: [Bioc-devel] namespace question

[Hervé Pagès]

On 03/31/2016 04:07 PM, Michael Lawrence wrote:

I agree. The importExcept idea also works that way: importExcept(foo, bar, baz)

But import(foo, except=c(bar, baz)) reads better.


mmh... so R expressions with calls to base functions like base::c() are
making their way in the NAMESPACE file. That's opening a big door. Does
that mean that we'll be able to do things like:

import(foo, except=paste0("bar", 1:10))

Or maybe c(bar, baz) in your above example is just an arbitrary syntax
that just happens to look like an R expression but won't be evaluated
as such?

H.




On Thu, Mar 31, 2016 at 4:00 PM,   wrote:

I don't think you want to separate it from the import. Better to allow
something like

import(foo, exclude=bar)

or

import(foo, exclude=c("bar", "baz"))

This seems reasonably natural and shouldn't be too hard to
implement. (But is has been a while since I've worked on this code).

Best,

luke


On Thu, 31 Mar 2016, Karim Mezhoud wrote:


I think "From" is needed to specify which package we want to exlude
functions.

I think  excludeFrom (package, function)  seems to be intuitive.

thanks,
Karim



On Thu, Mar 31, 2016 at 9:54 PM, Hervé Pagès  wrote:


On 03/31/2016 12:55 PM, Michael Lawrence wrote:


Probably should just stick to exact symbols for now. If there is a
case where a pattern is actually useful, rather than just an
obfuscation, we can extend the feature set.



Fair enough. Not really intuitive that excludeImport uses the same
syntax as (but does the opposite of) importFrom though. Maybe having
the name of the directive start with "import" would help e.g.

importExcept(hash, values)  # opposite of importFrom(hash, values)

Thanks,
H.




On Thu, Mar 31, 2016 at 12:11 PM, Zhu, Lihua (Julie)
 wrote:


Herve,

That is a very interesting idea and works for me! Thanks!

importPatternFrom(IRanges, "^values$")


Best,

Julie

On 3/31/16 2:51 PM, "Bioc-devel on behalf of Hervé Pagès"

wrote:

On 03/30/2016 08:35 PM, Michael Lawrence wrote:




That would work, but R is not going to be happy about redundant
imports. Interactively, users would balk at symbol qualification.

There are two classes of conflict:
1) Same semantics, where a common generic would arbitrate, or one
package could depend on the other, and
2) Different semantics, in which case one of the functions should
probably be renamed, although that might not be practical or easy to
agree upon.

When those approaches fail, qualification is the only recourse.

I will think about adding an excludeImport() or importAs().



What about having something like an importPatternFrom() directive
similar to the exportPattern() directive and have these directives
support some of the grep() toggles like 'ignore.case', 'fixed',
'invert' etc... ?

Then Julie could just do:

importPatternFrom(hash, "^values$", invert=TRUE)

H.




On Wed, Mar 30, 2016 at 8:20 PM, Robert M. Flight

wrote:

I can't find the hash function in IRanges. Are you sure it has one?



On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
 wrote:


Michael,

I have the same user case as Kasper. Another example is that both
IRanges
and hash packages have hash. I need to use the hash from the hash
package
instead of the one from IRanges.

Best,

Julie

On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
 wrote:

My usecase is when I import() two packages who has a conflict in a
name.
For example, both Biobase and matrixStats has both anyMissing and
rowMedians. I am happy to get all of these two packages, but I
need
to
resolve the conflict.  Since I want to keep the ones from
matrixStats I


know


need to figure out how to import Biobase selectively.  Which I
can,
using
the tools from codetoolsBioC, but I would also be happy with an
importFromExcept(), which would make my life much easier.

Best,
Kasper

On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
 wrote:



I'm curious about which symbols you wouldn't want to import, and
why.

On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
 wrote:


Hi,

Is there a function to import all the exported objects from a
package
except a few named ones in NAMESPACE file?

For example, I would like to import all the functions in
S4Vectors
except fold. Is there a way to  specify this without listing all
other
functions using importFrom?

Many thanks for your help!

Best regards,

Julie


Lihua Julie Zhu, Ph.D
Research Professor
Department of Molecular, Cell and Cancer Biology (MCCB)
Head of MCCB Bioinformatics Core

Re: [Bioc-devel] namespace question

[Michael Lawrence]

I agree. The importExcept idea also works that way: importExcept(foo, bar, baz)

But import(foo, except=c(bar, baz)) reads better.


On Thu, Mar 31, 2016 at 4:00 PM,   wrote:
> I don't think you want to separate it from the import. Better to allow
> something like
>
> import(foo, exclude=bar)
>
> or
>
> import(foo, exclude=c("bar", "baz"))
>
> This seems reasonably natural and shouldn't be too hard to
> implement. (But is has been a while since I've worked on this code).
>
> Best,
>
> luke
>
>
> On Thu, 31 Mar 2016, Karim Mezhoud wrote:
>
>> I think "From" is needed to specify which package we want to exlude
>> functions.
>>
>> I think  excludeFrom (package, function)  seems to be intuitive.
>>
>> thanks,
>> Karim
>>
>>
>>
>> On Thu, Mar 31, 2016 at 9:54 PM, Hervé Pagès  wrote:
>>
>>> On 03/31/2016 12:55 PM, Michael Lawrence wrote:
>>>
 Probably should just stick to exact symbols for now. If there is a
 case where a pattern is actually useful, rather than just an
 obfuscation, we can extend the feature set.

>>>
>>> Fair enough. Not really intuitive that excludeImport uses the same
>>> syntax as (but does the opposite of) importFrom though. Maybe having
>>> the name of the directive start with "import" would help e.g.
>>>
>>> importExcept(hash, values)  # opposite of importFrom(hash, values)
>>>
>>> Thanks,
>>> H.
>>>
>>>
>>>
 On Thu, Mar 31, 2016 at 12:11 PM, Zhu, Lihua (Julie)
  wrote:

> Herve,
>
> That is a very interesting idea and works for me! Thanks!
>
> importPatternFrom(IRanges, "^values$")
>
>
> Best,
>
> Julie
>
> On 3/31/16 2:51 PM, "Bioc-devel on behalf of Hervé Pagès"
> 
> wrote:
>
> On 03/30/2016 08:35 PM, Michael Lawrence wrote:
>>
>>
>>> That would work, but R is not going to be happy about redundant
>>> imports. Interactively, users would balk at symbol qualification.
>>>
>>> There are two classes of conflict:
>>> 1) Same semantics, where a common generic would arbitrate, or one
>>> package could depend on the other, and
>>> 2) Different semantics, in which case one of the functions should
>>> probably be renamed, although that might not be practical or easy to
>>> agree upon.
>>>
>>> When those approaches fail, qualification is the only recourse.
>>>
>>> I will think about adding an excludeImport() or importAs().
>>>
>>
>> What about having something like an importPatternFrom() directive
>> similar to the exportPattern() directive and have these directives
>> support some of the grep() toggles like 'ignore.case', 'fixed',
>> 'invert' etc... ?
>>
>> Then Julie could just do:
>>
>> importPatternFrom(hash, "^values$", invert=TRUE)
>>
>> H.
>>
>>
>>>
>>> On Wed, Mar 30, 2016 at 8:20 PM, Robert M. Flight
>>> >> >
>>> wrote:
>>>
 In the cases of having conflicting names, is it not appropriate then
 to use
 the "package::function" form for calling a particular function?

 On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence
 
 wrote:

 I can't find the hash function in IRanges. Are you sure it has one?
>
>
> On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
>  wrote:
>
>> Michael,
>>
>> I have the same user case as Kasper. Another example is that both
>> IRanges
>> and hash packages have hash. I need to use the hash from the hash
>> package
>> instead of the one from IRanges.
>>
>> Best,
>>
>> Julie
>>
>> On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
>>  wrote:
>>
>> My usecase is when I import() two packages who has a conflict in a
>> name.
>> For example, both Biobase and matrixStats has both anyMissing and
>> rowMedians. I am happy to get all of these two packages, but I
>> need
>> to
>> resolve the conflict.  Since I want to keep the ones from
>> matrixStats I
>>
> know
>
>> need to figure out how to import Biobase selectively.  Which I
>> can,
>> using
>> the tools from codetoolsBioC, but I would also be happy with an
>> importFromExcept(), which would make my life much easier.
>>
>> Best,
>> Kasper
>>
>> On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
>>  wrote:
>>
>>>
>>> I'm curious about which symbols you wouldn't want to import, and
>>> why.
>>>

Re: [Bioc-devel] namespace question

[Michael Lawrence]

Probably should just stick to exact symbols for now. If there is a
case where a pattern is actually useful, rather than just an
obfuscation, we can extend the feature set.

On Thu, Mar 31, 2016 at 12:11 PM, Zhu, Lihua (Julie)
 wrote:
> Herve,
>
> That is a very interesting idea and works for me! Thanks!
>
> importPatternFrom(IRanges, "^values$")
>
>
> Best,
>
> Julie
>
> On 3/31/16 2:51 PM, "Bioc-devel on behalf of Hervé Pagès"
>  wrote:
>
>>On 03/30/2016 08:35 PM, Michael Lawrence wrote:
>>> That would work, but R is not going to be happy about redundant
>>> imports. Interactively, users would balk at symbol qualification.
>>>
>>> There are two classes of conflict:
>>> 1) Same semantics, where a common generic would arbitrate, or one
>>> package could depend on the other, and
>>> 2) Different semantics, in which case one of the functions should
>>> probably be renamed, although that might not be practical or easy to
>>> agree upon.
>>>
>>> When those approaches fail, qualification is the only recourse.
>>>
>>> I will think about adding an excludeImport() or importAs().
>>
>>What about having something like an importPatternFrom() directive
>>similar to the exportPattern() directive and have these directives
>>support some of the grep() toggles like 'ignore.case', 'fixed',
>>'invert' etc... ?
>>
>>Then Julie could just do:
>>
>>importPatternFrom(hash, "^values$", invert=TRUE)
>>
>>H.
>>
>>>
>>>
>>> On Wed, Mar 30, 2016 at 8:20 PM, Robert M. Flight 
>>>wrote:
 In the cases of having conflicting names, is it not appropriate then
to use
 the "package::function" form for calling a particular function?

 On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence

 wrote:

> I can't find the hash function in IRanges. Are you sure it has one?
>
> On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
>  wrote:
>> Michael,
>>
>> I have the same user case as Kasper. Another example is that both
>>IRanges
>> and hash packages have hash. I need to use the hash from the hash
>>package
>> instead of the one from IRanges.
>>
>> Best,
>>
>> Julie
>>
>> On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
>>  wrote:
>>
>> My usecase is when I import() two packages who has a conflict in a
>>name.
>> For example, both Biobase and matrixStats has both anyMissing and
>> rowMedians. I am happy to get all of these two packages, but I need
>>to
>> resolve the conflict.  Since I want to keep the ones from
>>matrixStats I
> know
>> need to figure out how to import Biobase selectively.  Which I can,
>>using
>> the tools from codetoolsBioC, but I would also be happy with an
>> importFromExcept(), which would make my life much easier.
>>
>> Best,
>> Kasper
>>
>> On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
>>  wrote:
>>>
>>> I'm curious about which symbols you wouldn't want to import, and
>>>why.
>>>
>>> On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
>>>  wrote:
 Hi,

 Is there a function to import all the exported objects from a
package
 except a few named ones in NAMESPACE file?

 For example, I would like to import all the functions in S4Vectors
 except fold. Is there a way to  specify this without listing all
other
 functions using importFrom?

 Many thanks for your help!

 Best regards,

 Julie

 
 Lihua Julie Zhu, Ph.D
 Research Professor
 Department of Molecular, Cell and Cancer Biology (MCCB)
 Head of MCCB Bioinformatics Core
 Program in Molecular Medicine
 Program in Bioinformatics and Integrative Biology
 University of Massachusetts Medical School
 364 Plantation Street, Room 613
 Worcester, MA 01605
 508-856-5256 phone
 (508) 856 5460 fax


>
>http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE
>n=1134


  [[alternative HTML version deleted]]

 ___
 Bioc-devel@r-project.org mailing list

https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_ma
ilman_listinfo_bioc-2Ddevel=BQIF-g=WJBj9sUF1mbpVIAf3biu3CPHX4MeR
jY_w4DerPlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=Rxzbh
vEdYoq-VrN42rfiK5-UIIwjUIHLTQjy9s7-pzs=TmgPkRkAcsTjcIVvzaBFADs-tx8
CzeHHAAJ5kmgmJxQ=
>>>
>>> ___

Re: [Bioc-devel] namespace question

[Zhu, Lihua (Julie)]

Herve,

That is a very interesting idea and works for me! Thanks!

importPatternFrom(IRanges, "^values$")


Best,

Julie

On 3/31/16 2:51 PM, "Bioc-devel on behalf of Hervé Pagès"
 wrote:

>On 03/30/2016 08:35 PM, Michael Lawrence wrote:
>> That would work, but R is not going to be happy about redundant
>> imports. Interactively, users would balk at symbol qualification.
>>
>> There are two classes of conflict:
>> 1) Same semantics, where a common generic would arbitrate, or one
>> package could depend on the other, and
>> 2) Different semantics, in which case one of the functions should
>> probably be renamed, although that might not be practical or easy to
>> agree upon.
>>
>> When those approaches fail, qualification is the only recourse.
>>
>> I will think about adding an excludeImport() or importAs().
>
>What about having something like an importPatternFrom() directive
>similar to the exportPattern() directive and have these directives
>support some of the grep() toggles like 'ignore.case', 'fixed',
>'invert' etc... ?
>
>Then Julie could just do:
>
>importPatternFrom(hash, "^values$", invert=TRUE)
>
>H.
>
>>
>>
>> On Wed, Mar 30, 2016 at 8:20 PM, Robert M. Flight 
>>wrote:
>>> In the cases of having conflicting names, is it not appropriate then
>>>to use
>>> the "package::function" form for calling a particular function?
>>>
>>> On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence
>>>
>>> wrote:
>>>
 I can't find the hash function in IRanges. Are you sure it has one?

 On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
  wrote:
> Michael,
>
> I have the same user case as Kasper. Another example is that both
>IRanges
> and hash packages have hash. I need to use the hash from the hash
>package
> instead of the one from IRanges.
>
> Best,
>
> Julie
>
> On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
>  wrote:
>
> My usecase is when I import() two packages who has a conflict in a
>name.
> For example, both Biobase and matrixStats has both anyMissing and
> rowMedians. I am happy to get all of these two packages, but I need
>to
> resolve the conflict.  Since I want to keep the ones from
>matrixStats I
 know
> need to figure out how to import Biobase selectively.  Which I can,
>using
> the tools from codetoolsBioC, but I would also be happy with an
> importFromExcept(), which would make my life much easier.
>
> Best,
> Kasper
>
> On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
>  wrote:
>>
>> I'm curious about which symbols you wouldn't want to import, and
>>why.
>>
>> On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
>>  wrote:
>>> Hi,
>>>
>>> Is there a function to import all the exported objects from a
>>>package
>>> except a few named ones in NAMESPACE file?
>>>
>>> For example, I would like to import all the functions in S4Vectors
>>> except fold. Is there a way to  specify this without listing all
>>>other
>>> functions using importFrom?
>>>
>>> Many thanks for your help!
>>>
>>> Best regards,
>>>
>>> Julie
>>>
>>> 
>>> Lihua Julie Zhu, Ph.D
>>> Research Professor
>>> Department of Molecular, Cell and Cancer Biology (MCCB)
>>> Head of MCCB Bioinformatics Core
>>> Program in Molecular Medicine
>>> Program in Bioinformatics and Integrative Biology
>>> University of Massachusetts Medical School
>>> 364 Plantation Street, Room 613
>>> Worcester, MA 01605
>>> 508-856-5256 phone
>>> (508) 856 5460 fax
>>>
>>>
 
http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE
n=1134
>>>
>>>
>>>  [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> 
>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_ma
>>>ilman_listinfo_bioc-2Ddevel=BQIF-g=WJBj9sUF1mbpVIAf3biu3CPHX4MeR
>>>jY_w4DerPlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=Rxzbh
>>>vEdYoq-VrN42rfiK5-UIIwjUIHLTQjy9s7-pzs=TmgPkRkAcsTjcIVvzaBFADs-tx8
>>>CzeHHAAJ5kmgmJxQ=
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> 
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mai
>>lman_listinfo_bioc-2Ddevel=BQIF-g=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY
>>_w4DerPlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=RxzbhvEd
>>Yoq-VrN42rfiK5-UIIwjUIHLTQjy9s7-pzs=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeH
>>HAAJ5kmgmJxQ=
>
>

 

Re: [Bioc-devel] namespace question

[Hervé Pagès]

On 03/30/2016 08:35 PM, Michael Lawrence wrote:

That would work, but R is not going to be happy about redundant
imports. Interactively, users would balk at symbol qualification.

There are two classes of conflict:
1) Same semantics, where a common generic would arbitrate, or one
package could depend on the other, and
2) Different semantics, in which case one of the functions should
probably be renamed, although that might not be practical or easy to
agree upon.

When those approaches fail, qualification is the only recourse.

I will think about adding an excludeImport() or importAs().


What about having something like an importPatternFrom() directive
similar to the exportPattern() directive and have these directives
support some of the grep() toggles like 'ignore.case', 'fixed',
'invert' etc... ?

Then Julie could just do:

importPatternFrom(hash, "^values$", invert=TRUE)

H.




On Wed, Mar 30, 2016 at 8:20 PM, Robert M. Flight  wrote:

In the cases of having conflicting names, is it not appropriate then to use
the "package::function" form for calling a particular function?

On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence 
wrote:


I can't find the hash function in IRanges. Are you sure it has one?

On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
 wrote:

Michael,

I have the same user case as Kasper. Another example is that both IRanges
and hash packages have hash. I need to use the hash from the hash package
instead of the one from IRanges.

Best,

Julie

On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
 wrote:

My usecase is when I import() two packages who has a conflict in a name.
For example, both Biobase and matrixStats has both anyMissing and
rowMedians. I am happy to get all of these two packages, but I need to
resolve the conflict.  Since I want to keep the ones from matrixStats I

know

need to figure out how to import Biobase selectively.  Which I can, using
the tools from codetoolsBioC, but I would also be happy with an
importFromExcept(), which would make my life much easier.

Best,
Kasper

On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
 wrote:


I'm curious about which symbols you wouldn't want to import, and why.

On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
 wrote:

Hi,

Is there a function to import all the exported objects from a package
except a few named ones in NAMESPACE file?

For example, I would like to import all the functions in S4Vectors
except fold. Is there a way to  specify this without listing all other
functions using importFrom?

Many thanks for your help!

Best regards,

Julie


Lihua Julie Zhu, Ph.D
Research Professor
Department of Molecular, Cell and Cancer Biology (MCCB)
Head of MCCB Bioinformatics Core
Program in Molecular Medicine
Program in Bioinformatics and Integrative Biology
University of Massachusetts Medical School
364 Plantation Street, Room 613
Worcester, MA 01605
508-856-5256 phone
(508) 856 5460 fax



http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE=1134



 [[alternative HTML version deleted]]

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


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





___
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
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: [Bioc-devel] namespace question

[Michael Lawrence]

You might also consider whether you really need the hash package. It
seems like a pretty lightweight wrapper around environments.

On Thu, Mar 31, 2016 at 7:16 AM, Zhu, Lihua (Julie)
<julie@umassmed.edu> wrote:
> Thanks Kasper! Importing Iranges piecewise is difficult.
>
> Michael, I did use importFrom(hash, …)
>
> importFrom(hash, values, hash)
>
> Also, this is just an example. Thanks for willing to add a function similar
> to importFromExcept()
>
> Best,
>
> Julie
>
>
> From: Kasper Daniel Hansen <kasperdanielhan...@gmail.com>
> Date: Thursday, March 31, 2016 9:09 AM
> To: Michael Lawrence <lawrence.mich...@gene.com>
> Cc: Lihua Julie Zhu <julie@umassmed.edu>, "bioc-devel@r-project.org"
> <bioc-devel@r-project.org>
> Subject: Re: [Bioc-devel] namespace question
>
> Of course, that depends on whether Julie actually uses hash::values or this
> is just trying to avoid a conflict.  Importing IRanges piecewise is ...
> probably difficult.
>
> Best,
> Kasper
>
> On Thu, Mar 31, 2016 at 10:05 AM, Michael Lawrence
> <lawrence.mich...@gene.com> wrote:
>>
>> We should probably deprecate values(). It has long been superseded by
>> mcols(). But for now, it would seem pragmatic to importFrom(hash, ...)
>> since it has so few functions.
>>
>> On Thu, Mar 31, 2016 at 6:54 AM, Zhu, Lihua (Julie)
>> <julie@umassmed.edu> wrote:
>> > Sorry. I meant values.
>> >
>> > replacing previous import ŒIRanges::values¹ by Œhash::values¹ when
>> > loading
>> > ŒCRISPRseek¹
>> >
>> > Best,
>> >
>> > Julie
>> >
>> >
>> > On 3/30/16 11:13 PM, "Michael Lawrence" <lawrence.mich...@gene.com>
>> > wrote:
>> >
>> >>I can't find the hash function in IRanges. Are you sure it has one?
>> >>
>> >>On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
>> >><julie@umassmed.edu> wrote:
>> >>> Michael,
>> >>>
>> >>> I have the same user case as Kasper. Another example is that both
>> >>>IRanges
>> >>> and hash packages have hash. I need to use the hash from the hash
>> >>>package
>> >>> instead of the one from IRanges.
>> >>>
>> >>> Best,
>> >>>
>> >>> Julie
>> >>>
>> >>> On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
>> >>> <kasperdanielhan...@gmail.com> wrote:
>> >>>
>> >>> My usecase is when I import() two packages who has a conflict in a
>> >>> name.
>> >>> For example, both Biobase and matrixStats has both anyMissing and
>> >>> rowMedians. I am happy to get all of these two packages, but I need to
>> >>> resolve the conflict.  Since I want to keep the ones from matrixStats
>> >>> I
>> >>>know
>> >>> need to figure out how to import Biobase selectively.  Which I can,
>> >>>using
>> >>> the tools from codetoolsBioC, but I would also be happy with an
>> >>> importFromExcept(), which would make my life much easier.
>> >>>
>> >>> Best,
>> >>> Kasper
>> >>>
>> >>> On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
>> >>> <lawrence.mich...@gene.com> wrote:
>> >>>>
>> >>>> I'm curious about which symbols you wouldn't want to import, and why.
>> >>>>
>> >>>> On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
>> >>>> <julie@umassmed.edu> wrote:
>> >>>> > Hi,
>> >>>> >
>> >>>> > Is there a function to import all the exported objects from a
>> >>>> > package
>> >>>> > except a few named ones in NAMESPACE file?
>> >>>> >
>> >>>> > For example, I would like to import all the functions in S4Vectors
>> >>>> > except fold. Is there a way to  specify this without listing all
>> >>>>other
>> >>>> > functions using importFrom?
>> >>>> >
>> >>>> > Many thanks for your help!
>> >>>> >
>> >>>> > Best regards,
>> >>>> >
>> >>>> > Julie
>> >>>> >
>> >>>> > 
>> >>>> &

Re: [Bioc-devel] namespace question

[Hervé Pagès]

On 03/31/2016 07:05 AM, Michael Lawrence wrote:

We should probably deprecate values(). It has long been superseded by
mcols().


FWIW this is on my long-term list but it can't be done now. values()
was originally (and is still) a RangedData accessor. At some point it
was also made a synonym of elementMetadata() (a.k.a. mcols()) for
Vector derivatives. The goal was to make it easier for package
developers to write code that would operate the same way on GRanges
or RangedData objects. I think easyRNASeq is one of those packages.
Those packages need to be modified to use only GRanges objects
before they can start using mcols() instead of values(). It will
take a long time before we can deprecate values()...

H.


But for now, it would seem pragmatic to importFrom(hash, ...)
since it has so few functions.

On Thu, Mar 31, 2016 at 6:54 AM, Zhu, Lihua (Julie)
 wrote:

Sorry. I meant values.

replacing previous import ŒIRanges::values¹ by Œhash::values¹ when loading
ŒCRISPRseek¹

Best,

Julie


On 3/30/16 11:13 PM, "Michael Lawrence"  wrote:


I can't find the hash function in IRanges. Are you sure it has one?

On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
 wrote:

Michael,

I have the same user case as Kasper. Another example is that both
IRanges
and hash packages have hash. I need to use the hash from the hash
package
instead of the one from IRanges.

Best,

Julie

On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
 wrote:

My usecase is when I import() two packages who has a conflict in a name.
For example, both Biobase and matrixStats has both anyMissing and
rowMedians. I am happy to get all of these two packages, but I need to
resolve the conflict.  Since I want to keep the ones from matrixStats I
know
need to figure out how to import Biobase selectively.  Which I can,
using
the tools from codetoolsBioC, but I would also be happy with an
importFromExcept(), which would make my life much easier.

Best,
Kasper

On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
 wrote:


I'm curious about which symbols you wouldn't want to import, and why.

On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
 wrote:

Hi,

Is there a function to import all the exported objects from a package
except a few named ones in NAMESPACE file?

For example, I would like to import all the functions in S4Vectors
except fold. Is there a way to  specify this without listing all

other

functions using importFrom?

Many thanks for your help!

Best regards,

Julie


Lihua Julie Zhu, Ph.D
Research Professor
Department of Molecular, Cell and Cancer Biology (MCCB)
Head of MCCB Bioinformatics Core
Program in Molecular Medicine
Program in Bioinformatics and Integrative Biology
University of Massachusetts Medical School
364 Plantation Street, Room 613
Worcester, MA 01605
508-856-5256 phone
(508) 856 5460 fax



http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE
=1134



 [[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list


https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
n_listinfo_bioc-2Ddevel=BQIBaQ=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
PlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=K-j995DBKSpPEMWrL
Wklcv4lQEiFC7wPFwn1ssv9dtg=fijAc5Y3bbV4ei4vYEx_SXy9kDcQ8vNUPOrE0cq1eZk
=

___
Bioc-devel@r-project.org mailing list

https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
n_listinfo_bioc-2Ddevel=BQIBaQ=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
PlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=K-j995DBKSpPEMWrL
Wklcv4lQEiFC7wPFwn1ssv9dtg=fijAc5Y3bbV4ei4vYEx_SXy9kDcQ8vNUPOrE0cq1eZk
=







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



--
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: [Bioc-devel] namespace question

[Michael Lawrence]

But using hash::values() is not so bad.

On Thu, Mar 31, 2016 at 7:09 AM, Kasper Daniel Hansen
 wrote:
> Of course, that depends on whether Julie actually uses hash::values or this
> is just trying to avoid a conflict.  Importing IRanges piecewise is ...
> probably difficult.
>
> Best,
> Kasper
>
> On Thu, Mar 31, 2016 at 10:05 AM, Michael Lawrence
>  wrote:
>>
>> We should probably deprecate values(). It has long been superseded by
>> mcols(). But for now, it would seem pragmatic to importFrom(hash, ...)
>> since it has so few functions.
>>
>> On Thu, Mar 31, 2016 at 6:54 AM, Zhu, Lihua (Julie)
>>  wrote:
>> > Sorry. I meant values.
>> >
>> > replacing previous import ŒIRanges::values¹ by Œhash::values¹ when
>> > loading
>> > ŒCRISPRseek¹
>> >
>> > Best,
>> >
>> > Julie
>> >
>> >
>> > On 3/30/16 11:13 PM, "Michael Lawrence" 
>> > wrote:
>> >
>> >>I can't find the hash function in IRanges. Are you sure it has one?
>> >>
>> >>On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
>> >> wrote:
>> >>> Michael,
>> >>>
>> >>> I have the same user case as Kasper. Another example is that both
>> >>>IRanges
>> >>> and hash packages have hash. I need to use the hash from the hash
>> >>>package
>> >>> instead of the one from IRanges.
>> >>>
>> >>> Best,
>> >>>
>> >>> Julie
>> >>>
>> >>> On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
>> >>>  wrote:
>> >>>
>> >>> My usecase is when I import() two packages who has a conflict in a
>> >>> name.
>> >>> For example, both Biobase and matrixStats has both anyMissing and
>> >>> rowMedians. I am happy to get all of these two packages, but I need to
>> >>> resolve the conflict.  Since I want to keep the ones from matrixStats
>> >>> I
>> >>>know
>> >>> need to figure out how to import Biobase selectively.  Which I can,
>> >>>using
>> >>> the tools from codetoolsBioC, but I would also be happy with an
>> >>> importFromExcept(), which would make my life much easier.
>> >>>
>> >>> Best,
>> >>> Kasper
>> >>>
>> >>> On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
>> >>>  wrote:
>> 
>>  I'm curious about which symbols you wouldn't want to import, and why.
>> 
>>  On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
>>   wrote:
>>  > Hi,
>>  >
>>  > Is there a function to import all the exported objects from a
>>  > package
>>  > except a few named ones in NAMESPACE file?
>>  >
>>  > For example, I would like to import all the functions in S4Vectors
>>  > except fold. Is there a way to  specify this without listing all
>> other
>>  > functions using importFrom?
>>  >
>>  > Many thanks for your help!
>>  >
>>  > Best regards,
>>  >
>>  > Julie
>>  >
>>  > 
>>  > Lihua Julie Zhu, Ph.D
>>  > Research Professor
>>  > Department of Molecular, Cell and Cancer Biology (MCCB)
>>  > Head of MCCB Bioinformatics Core
>>  > Program in Molecular Medicine
>>  > Program in Bioinformatics and Integrative Biology
>>  > University of Massachusetts Medical School
>>  > 364 Plantation Street, Room 613
>>  > Worcester, MA 01605
>>  > 508-856-5256 phone
>>  > (508) 856 5460 fax
>>  >
>>  >
>>
>>  http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE
>> =1134
>>  >
>>  >
>>  > [[alternative HTML version deleted]]
>>  >
>>  > ___
>>  > Bioc-devel@r-project.org mailing list
>>  >
>>
>>  https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
>>
>>  n_listinfo_bioc-2Ddevel=BQIBaQ=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
>>
>>  PlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=K-j995DBKSpPEMWrL
>>
>>  Wklcv4lQEiFC7wPFwn1ssv9dtg=fijAc5Y3bbV4ei4vYEx_SXy9kDcQ8vNUPOrE0cq1eZk
>> =
>> 
>>  ___
>>  Bioc-devel@r-project.org mailing list
>> 
>>
>>  https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
>>
>>  n_listinfo_bioc-2Ddevel=BQIBaQ=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
>>
>>  PlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=K-j995DBKSpPEMWrL
>>
>>  Wklcv4lQEiFC7wPFwn1ssv9dtg=fijAc5Y3bbV4ei4vYEx_SXy9kDcQ8vNUPOrE0cq1eZk
>> =
>> >>>
>> >>>
>> >
>
>

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

Re: [Bioc-devel] namespace question

[Zhu, Lihua (Julie)]

Thanks Kasper! Importing Iranges piecewise is difficult.

Michael, I did use importFrom(hash, …)

importFrom(hash, values, hash)

Also, this is just an example. Thanks for willing to add a function similar to 
importFromExcept()

Best,

Julie


From: Kasper Daniel Hansen 
<kasperdanielhan...@gmail.com<mailto:kasperdanielhan...@gmail.com>>
Date: Thursday, March 31, 2016 9:09 AM
To: Michael Lawrence 
<lawrence.mich...@gene.com<mailto:lawrence.mich...@gene.com>>
Cc: Lihua Julie Zhu <julie@umassmed.edu<mailto:julie@umassmed.edu>>, 
"bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>" 
<bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>>
Subject: Re: [Bioc-devel] namespace question

Of course, that depends on whether Julie actually uses hash::values or this is 
just trying to avoid a conflict.  Importing IRanges piecewise is ... probably 
difficult.

Best,
Kasper

On Thu, Mar 31, 2016 at 10:05 AM, Michael Lawrence 
<lawrence.mich...@gene.com<mailto:lawrence.mich...@gene.com>> wrote:
We should probably deprecate values(). It has long been superseded by
mcols(). But for now, it would seem pragmatic to importFrom(hash, ...)
since it has so few functions.

On Thu, Mar 31, 2016 at 6:54 AM, Zhu, Lihua (Julie)
<julie@umassmed.edu<mailto:julie@umassmed.edu>> wrote:
> Sorry. I meant values.
>
> replacing previous import ŒIRanges::values¹ by Œhash::values¹ when loading
> ŒCRISPRseek¹
>
> Best,
>
> Julie
>
>
> On 3/30/16 11:13 PM, "Michael Lawrence" 
> <lawrence.mich...@gene.com<mailto:lawrence.mich...@gene.com>> wrote:
>
>>I can't find the hash function in IRanges. Are you sure it has one?
>>
>>On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
>><julie@umassmed.edu<mailto:julie@umassmed.edu>> wrote:
>>> Michael,
>>>
>>> I have the same user case as Kasper. Another example is that both
>>>IRanges
>>> and hash packages have hash. I need to use the hash from the hash
>>>package
>>> instead of the one from IRanges.
>>>
>>> Best,
>>>
>>> Julie
>>>
>>> On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
>>> <kasperdanielhan...@gmail.com<mailto:kasperdanielhan...@gmail.com>> wrote:
>>>
>>> My usecase is when I import() two packages who has a conflict in a name.
>>> For example, both Biobase and matrixStats has both anyMissing and
>>> rowMedians. I am happy to get all of these two packages, but I need to
>>> resolve the conflict.  Since I want to keep the ones from matrixStats I
>>>know
>>> need to figure out how to import Biobase selectively.  Which I can,
>>>using
>>> the tools from codetoolsBioC, but I would also be happy with an
>>> importFromExcept(), which would make my life much easier.
>>>
>>> Best,
>>> Kasper
>>>
>>> On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
>>> <lawrence.mich...@gene.com<mailto:lawrence.mich...@gene.com>> wrote:
>>>>
>>>> I'm curious about which symbols you wouldn't want to import, and why.
>>>>
>>>> On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
>>>> <julie@umassmed.edu<mailto:julie@umassmed.edu>> wrote:
>>>> > Hi,
>>>> >
>>>> > Is there a function to import all the exported objects from a package
>>>> > except a few named ones in NAMESPACE file?
>>>> >
>>>> > For example, I would like to import all the functions in S4Vectors
>>>> > except fold. Is there a way to  specify this without listing all
>>>>other
>>>> > functions using importFrom?
>>>> >
>>>> > Many thanks for your help!
>>>> >
>>>> > Best regards,
>>>> >
>>>> > Julie
>>>> >
>>>> > 
>>>> > Lihua Julie Zhu, Ph.D
>>>> > Research Professor
>>>> > Department of Molecular, Cell and Cancer Biology (MCCB)
>>>> > Head of MCCB Bioinformatics Core
>>>> > Program in Molecular Medicine
>>>> > Program in Bioinformatics and Integrative Biology
>>>> > University of Massachusetts Medical School
>>>> > 364 Plantation Street, Room 613
>>>> > Worcester, MA 01605
>>>> > 508-856-5256 phone
>>>> > (508) 856 5460<tel:%28508%29%20856%205460> fax
>>>> >
>>

Re: [Bioc-devel] namespace question

[Kasper Daniel Hansen]

Of course, that depends on whether Julie actually uses hash::values or this
is just trying to avoid a conflict.  Importing IRanges piecewise is ...
probably difficult.

Best,
Kasper

On Thu, Mar 31, 2016 at 10:05 AM, Michael Lawrence <
lawrence.mich...@gene.com> wrote:

> We should probably deprecate values(). It has long been superseded by
> mcols(). But for now, it would seem pragmatic to importFrom(hash, ...)
> since it has so few functions.
>
> On Thu, Mar 31, 2016 at 6:54 AM, Zhu, Lihua (Julie)
>  wrote:
> > Sorry. I meant values.
> >
> > replacing previous import ŒIRanges::values¹ by Œhash::values¹ when
> loading
> > ŒCRISPRseek¹
> >
> > Best,
> >
> > Julie
> >
> >
> > On 3/30/16 11:13 PM, "Michael Lawrence" 
> wrote:
> >
> >>I can't find the hash function in IRanges. Are you sure it has one?
> >>
> >>On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
> >> wrote:
> >>> Michael,
> >>>
> >>> I have the same user case as Kasper. Another example is that both
> >>>IRanges
> >>> and hash packages have hash. I need to use the hash from the hash
> >>>package
> >>> instead of the one from IRanges.
> >>>
> >>> Best,
> >>>
> >>> Julie
> >>>
> >>> On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
> >>>  wrote:
> >>>
> >>> My usecase is when I import() two packages who has a conflict in a
> name.
> >>> For example, both Biobase and matrixStats has both anyMissing and
> >>> rowMedians. I am happy to get all of these two packages, but I need to
> >>> resolve the conflict.  Since I want to keep the ones from matrixStats I
> >>>know
> >>> need to figure out how to import Biobase selectively.  Which I can,
> >>>using
> >>> the tools from codetoolsBioC, but I would also be happy with an
> >>> importFromExcept(), which would make my life much easier.
> >>>
> >>> Best,
> >>> Kasper
> >>>
> >>> On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
> >>>  wrote:
> 
>  I'm curious about which symbols you wouldn't want to import, and why.
> 
>  On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
>   wrote:
>  > Hi,
>  >
>  > Is there a function to import all the exported objects from a
> package
>  > except a few named ones in NAMESPACE file?
>  >
>  > For example, I would like to import all the functions in S4Vectors
>  > except fold. Is there a way to  specify this without listing all
> other
>  > functions using importFrom?
>  >
>  > Many thanks for your help!
>  >
>  > Best regards,
>  >
>  > Julie
>  >
>  > 
>  > Lihua Julie Zhu, Ph.D
>  > Research Professor
>  > Department of Molecular, Cell and Cancer Biology (MCCB)
>  > Head of MCCB Bioinformatics Core
>  > Program in Molecular Medicine
>  > Program in Bioinformatics and Integrative Biology
>  > University of Massachusetts Medical School
>  > 364 Plantation Street, Room 613
>  > Worcester, MA 01605
>  > 508-856-5256 phone
>  > (508) 856 5460 fax
>  >
>  >
> 
> http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE
> =1134
>  >
>  >
>  > [[alternative HTML version deleted]]
>  >
>  > ___
>  > Bioc-devel@r-project.org mailing list
>  >
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
>
> n_listinfo_bioc-2Ddevel=BQIBaQ=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
>
> PlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=K-j995DBKSpPEMWrL
>
> Wklcv4lQEiFC7wPFwn1ssv9dtg=fijAc5Y3bbV4ei4vYEx_SXy9kDcQ8vNUPOrE0cq1eZk
> =
> 
>  ___
>  Bioc-devel@r-project.org mailing list
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
>
> n_listinfo_bioc-2Ddevel=BQIBaQ=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
>
> PlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=K-j995DBKSpPEMWrL
>
> Wklcv4lQEiFC7wPFwn1ssv9dtg=fijAc5Y3bbV4ei4vYEx_SXy9kDcQ8vNUPOrE0cq1eZk
> =
> >>>
> >>>
> >
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] namespace question

[Michael Lawrence]

We should probably deprecate values(). It has long been superseded by
mcols(). But for now, it would seem pragmatic to importFrom(hash, ...)
since it has so few functions.

On Thu, Mar 31, 2016 at 6:54 AM, Zhu, Lihua (Julie)
 wrote:
> Sorry. I meant values.
>
> replacing previous import ŒIRanges::values¹ by Œhash::values¹ when loading
> ŒCRISPRseek¹
>
> Best,
>
> Julie
>
>
> On 3/30/16 11:13 PM, "Michael Lawrence"  wrote:
>
>>I can't find the hash function in IRanges. Are you sure it has one?
>>
>>On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
>> wrote:
>>> Michael,
>>>
>>> I have the same user case as Kasper. Another example is that both
>>>IRanges
>>> and hash packages have hash. I need to use the hash from the hash
>>>package
>>> instead of the one from IRanges.
>>>
>>> Best,
>>>
>>> Julie
>>>
>>> On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
>>>  wrote:
>>>
>>> My usecase is when I import() two packages who has a conflict in a name.
>>> For example, both Biobase and matrixStats has both anyMissing and
>>> rowMedians. I am happy to get all of these two packages, but I need to
>>> resolve the conflict.  Since I want to keep the ones from matrixStats I
>>>know
>>> need to figure out how to import Biobase selectively.  Which I can,
>>>using
>>> the tools from codetoolsBioC, but I would also be happy with an
>>> importFromExcept(), which would make my life much easier.
>>>
>>> Best,
>>> Kasper
>>>
>>> On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
>>>  wrote:

 I'm curious about which symbols you wouldn't want to import, and why.

 On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
  wrote:
 > Hi,
 >
 > Is there a function to import all the exported objects from a package
 > except a few named ones in NAMESPACE file?
 >
 > For example, I would like to import all the functions in S4Vectors
 > except fold. Is there a way to  specify this without listing all
other
 > functions using importFrom?
 >
 > Many thanks for your help!
 >
 > Best regards,
 >
 > Julie
 >
 > 
 > Lihua Julie Zhu, Ph.D
 > Research Professor
 > Department of Molecular, Cell and Cancer Biology (MCCB)
 > Head of MCCB Bioinformatics Core
 > Program in Molecular Medicine
 > Program in Bioinformatics and Integrative Biology
 > University of Massachusetts Medical School
 > 364 Plantation Street, Room 613
 > Worcester, MA 01605
 > 508-856-5256 phone
 > (508) 856 5460 fax
 >
 >
http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE
=1134
 >
 >
 > [[alternative HTML version deleted]]
 >
 > ___
 > Bioc-devel@r-project.org mailing list
 >
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
n_listinfo_bioc-2Ddevel=BQIBaQ=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
PlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=K-j995DBKSpPEMWrL
Wklcv4lQEiFC7wPFwn1ssv9dtg=fijAc5Y3bbV4ei4vYEx_SXy9kDcQ8vNUPOrE0cq1eZk
=

 ___
 Bioc-devel@r-project.org mailing list

https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
n_listinfo_bioc-2Ddevel=BQIBaQ=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
PlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=K-j995DBKSpPEMWrL
Wklcv4lQEiFC7wPFwn1ssv9dtg=fijAc5Y3bbV4ei4vYEx_SXy9kDcQ8vNUPOrE0cq1eZk
=
>>>
>>>
>

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

Re: [Bioc-devel] namespace question

[Zhu, Lihua (Julie)]

Sorry. I meant values.

replacing previous import ŒIRanges::values¹ by Œhash::values¹ when loading
ŒCRISPRseek¹ 

Best,

Julie


On 3/30/16 11:13 PM, "Michael Lawrence"  wrote:

>I can't find the hash function in IRanges. Are you sure it has one?
>
>On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
> wrote:
>> Michael,
>>
>> I have the same user case as Kasper. Another example is that both
>>IRanges
>> and hash packages have hash. I need to use the hash from the hash
>>package
>> instead of the one from IRanges.
>>
>> Best,
>>
>> Julie
>>
>> On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
>>  wrote:
>>
>> My usecase is when I import() two packages who has a conflict in a name.
>> For example, both Biobase and matrixStats has both anyMissing and
>> rowMedians. I am happy to get all of these two packages, but I need to
>> resolve the conflict.  Since I want to keep the ones from matrixStats I
>>know
>> need to figure out how to import Biobase selectively.  Which I can,
>>using
>> the tools from codetoolsBioC, but I would also be happy with an
>> importFromExcept(), which would make my life much easier.
>>
>> Best,
>> Kasper
>>
>> On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
>>  wrote:
>>>
>>> I'm curious about which symbols you wouldn't want to import, and why.
>>>
>>> On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
>>>  wrote:
>>> > Hi,
>>> >
>>> > Is there a function to import all the exported objects from a package
>>> > except a few named ones in NAMESPACE file?
>>> >
>>> > For example, I would like to import all the functions in S4Vectors
>>> > except fold. Is there a way to  specify this without listing all
>>>other
>>> > functions using importFrom?
>>> >
>>> > Many thanks for your help!
>>> >
>>> > Best regards,
>>> >
>>> > Julie
>>> >
>>> > 
>>> > Lihua Julie Zhu, Ph.D
>>> > Research Professor
>>> > Department of Molecular, Cell and Cancer Biology (MCCB)
>>> > Head of MCCB Bioinformatics Core
>>> > Program in Molecular Medicine
>>> > Program in Bioinformatics and Integrative Biology
>>> > University of Massachusetts Medical School
>>> > 364 Plantation Street, Room 613
>>> > Worcester, MA 01605
>>> > 508-856-5256 phone
>>> > (508) 856 5460 fax
>>> >
>>> > 
>>>http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE
>>>=1134
>>> >
>>> >
>>> > [[alternative HTML version deleted]]
>>> >
>>> > ___
>>> > Bioc-devel@r-project.org mailing list
>>> > 
>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
>>>n_listinfo_bioc-2Ddevel=BQIBaQ=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
>>>PlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=K-j995DBKSpPEMWrL
>>>Wklcv4lQEiFC7wPFwn1ssv9dtg=fijAc5Y3bbV4ei4vYEx_SXy9kDcQ8vNUPOrE0cq1eZk
>>>= 
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> 
>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
>>>n_listinfo_bioc-2Ddevel=BQIBaQ=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
>>>PlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=K-j995DBKSpPEMWrL
>>>Wklcv4lQEiFC7wPFwn1ssv9dtg=fijAc5Y3bbV4ei4vYEx_SXy9kDcQ8vNUPOrE0cq1eZk
>>>= 
>>
>>

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

Re: [Bioc-devel] namespace question

[Michael Lawrence]

That would work, but R is not going to be happy about redundant
imports. Interactively, users would balk at symbol qualification.

There are two classes of conflict:
1) Same semantics, where a common generic would arbitrate, or one
package could depend on the other, and
2) Different semantics, in which case one of the functions should
probably be renamed, although that might not be practical or easy to
agree upon.

When those approaches fail, qualification is the only recourse.

I will think about adding an excludeImport() or importAs().


On Wed, Mar 30, 2016 at 8:20 PM, Robert M. Flight  wrote:
> In the cases of having conflicting names, is it not appropriate then to use
> the "package::function" form for calling a particular function?
>
> On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence 
> wrote:
>
>> I can't find the hash function in IRanges. Are you sure it has one?
>>
>> On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
>>  wrote:
>> > Michael,
>> >
>> > I have the same user case as Kasper. Another example is that both IRanges
>> > and hash packages have hash. I need to use the hash from the hash package
>> > instead of the one from IRanges.
>> >
>> > Best,
>> >
>> > Julie
>> >
>> > On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
>> >  wrote:
>> >
>> > My usecase is when I import() two packages who has a conflict in a name.
>> > For example, both Biobase and matrixStats has both anyMissing and
>> > rowMedians. I am happy to get all of these two packages, but I need to
>> > resolve the conflict.  Since I want to keep the ones from matrixStats I
>> know
>> > need to figure out how to import Biobase selectively.  Which I can, using
>> > the tools from codetoolsBioC, but I would also be happy with an
>> > importFromExcept(), which would make my life much easier.
>> >
>> > Best,
>> > Kasper
>> >
>> > On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
>> >  wrote:
>> >>
>> >> I'm curious about which symbols you wouldn't want to import, and why.
>> >>
>> >> On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
>> >>  wrote:
>> >> > Hi,
>> >> >
>> >> > Is there a function to import all the exported objects from a package
>> >> > except a few named ones in NAMESPACE file?
>> >> >
>> >> > For example, I would like to import all the functions in S4Vectors
>> >> > except fold. Is there a way to  specify this without listing all other
>> >> > functions using importFrom?
>> >> >
>> >> > Many thanks for your help!
>> >> >
>> >> > Best regards,
>> >> >
>> >> > Julie
>> >> >
>> >> > 
>> >> > Lihua Julie Zhu, Ph.D
>> >> > Research Professor
>> >> > Department of Molecular, Cell and Cancer Biology (MCCB)
>> >> > Head of MCCB Bioinformatics Core
>> >> > Program in Molecular Medicine
>> >> > Program in Bioinformatics and Integrative Biology
>> >> > University of Massachusetts Medical School
>> >> > 364 Plantation Street, Room 613
>> >> > Worcester, MA 01605
>> >> > 508-856-5256 phone
>> >> > (508) 856 5460 fax
>> >> >
>> >> >
>> http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE=1134
>> >> >
>> >> >
>> >> > [[alternative HTML version deleted]]
>> >> >
>> >> > ___
>> >> > Bioc-devel@r-project.org mailing list
>> >> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>
>> >> ___
>> >> Bioc-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >
>> >
>>
>> ___
>> 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] namespace question

[Robert M. Flight]

In the cases of having conflicting names, is it not appropriate then to use
the "package::function" form for calling a particular function?

On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence 
wrote:

> I can't find the hash function in IRanges. Are you sure it has one?
>
> On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
>  wrote:
> > Michael,
> >
> > I have the same user case as Kasper. Another example is that both IRanges
> > and hash packages have hash. I need to use the hash from the hash package
> > instead of the one from IRanges.
> >
> > Best,
> >
> > Julie
> >
> > On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
> >  wrote:
> >
> > My usecase is when I import() two packages who has a conflict in a name.
> > For example, both Biobase and matrixStats has both anyMissing and
> > rowMedians. I am happy to get all of these two packages, but I need to
> > resolve the conflict.  Since I want to keep the ones from matrixStats I
> know
> > need to figure out how to import Biobase selectively.  Which I can, using
> > the tools from codetoolsBioC, but I would also be happy with an
> > importFromExcept(), which would make my life much easier.
> >
> > Best,
> > Kasper
> >
> > On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
> >  wrote:
> >>
> >> I'm curious about which symbols you wouldn't want to import, and why.
> >>
> >> On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
> >>  wrote:
> >> > Hi,
> >> >
> >> > Is there a function to import all the exported objects from a package
> >> > except a few named ones in NAMESPACE file?
> >> >
> >> > For example, I would like to import all the functions in S4Vectors
> >> > except fold. Is there a way to  specify this without listing all other
> >> > functions using importFrom?
> >> >
> >> > Many thanks for your help!
> >> >
> >> > Best regards,
> >> >
> >> > Julie
> >> >
> >> > 
> >> > Lihua Julie Zhu, Ph.D
> >> > Research Professor
> >> > Department of Molecular, Cell and Cancer Biology (MCCB)
> >> > Head of MCCB Bioinformatics Core
> >> > Program in Molecular Medicine
> >> > Program in Bioinformatics and Integrative Biology
> >> > University of Massachusetts Medical School
> >> > 364 Plantation Street, Room 613
> >> > Worcester, MA 01605
> >> > 508-856-5256 phone
> >> > (508) 856 5460 fax
> >> >
> >> >
> http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE=1134
> >> >
> >> >
> >> > [[alternative HTML version deleted]]
> >> >
> >> > ___
> >> > Bioc-devel@r-project.org mailing list
> >> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>
> >> ___
> >> Bioc-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> >
>
> ___
> 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] namespace question

[Michael Lawrence]

Thanks. If we can identify specific conflicts between popular
packages, we might be able to work around them. I think S4Vectors is
coming to depend on matrixStats, so those conflicts will start
happening a lot more often now.

Michael

On Wed, Mar 30, 2016 at 4:56 PM, Kasper Daniel Hansen
 wrote:
> My usecase is when I import() two packages who has a conflict in a name.
> For example, both Biobase and matrixStats has both anyMissing and
> rowMedians. I am happy to get all of these two packages, but I need to
> resolve the conflict.  Since I want to keep the ones from matrixStats I know
> need to figure out how to import Biobase selectively.  Which I can, using
> the tools from codetoolsBioC, but I would also be happy with an
> importFromExcept(), which would make my life much easier.
>
> Best,
> Kasper
>
> On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
>  wrote:
>>
>> I'm curious about which symbols you wouldn't want to import, and why.
>>
>> On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
>>  wrote:
>> > Hi,
>> >
>> > Is there a function to import all the exported objects from a package
>> > except a few named ones in NAMESPACE file?
>> >
>> > For example, I would like to import all the functions in S4Vectors
>> > except fold. Is there a way to  specify this without listing all other
>> > functions using importFrom?
>> >
>> > Many thanks for your help!
>> >
>> > Best regards,
>> >
>> > Julie
>> >
>> > 
>> > Lihua Julie Zhu, Ph.D
>> > Research Professor
>> > Department of Molecular, Cell and Cancer Biology (MCCB)
>> > Head of MCCB Bioinformatics Core
>> > Program in Molecular Medicine
>> > Program in Bioinformatics and Integrative Biology
>> > University of Massachusetts Medical School
>> > 364 Plantation Street, Room 613
>> > Worcester, MA 01605
>> > 508-856-5256 phone
>> > (508) 856 5460 fax
>> >
>> > http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE=1134
>> >
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > ___
>> > Bioc-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>

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

Re: [Bioc-devel] namespace question

[Michael Lawrence]

I'm curious about which symbols you wouldn't want to import, and why.

On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
 wrote:
> Hi,
>
> Is there a function to import all the exported objects from a package except 
> a few named ones in NAMESPACE file?
>
> For example, I would like to import all the functions in S4Vectors except 
> fold. Is there a way to  specify this without listing all other functions 
> using importFrom?
>
> Many thanks for your help!
>
> Best regards,
>
> Julie
>
> 
> Lihua Julie Zhu, Ph.D
> Research Professor
> Department of Molecular, Cell and Cancer Biology (MCCB)
> Head of MCCB Bioinformatics Core
> Program in Molecular Medicine
> Program in Bioinformatics and Integrative Biology
> University of Massachusetts Medical School
> 364 Plantation Street, Room 613
> Worcester, MA 01605
> 508-856-5256 phone
> (508) 856 5460 fax
> http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE=1134
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

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

Re: [Bioc-devel] namespace question

[Zhu, Lihua (Julie)]

Kasper,

Thanks so much for such a quick response!

It would be very nice to have  importFromExcept especially for some of the 
packages with tons of exported objects.

Best,

Julie

From: Kasper Daniel Hansen 
<kasperdanielhan...@gmail.com<mailto:kasperdanielhan...@gmail.com>>
Date: Wednesday, March 30, 2016 2:22 PM
To: Lihua Julie Zhu <julie@umassmed.edu<mailto:julie@umassmed.edu>>
Cc: "bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>" 
<bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>>
Subject: Re: [Bioc-devel] namespace question

No, as far as I know. I asked about this on R-devel a long time ago; would be 
nice to have importFromExcept()

Best,
Kasper

On Wed, Mar 30, 2016 at 3:19 PM, Zhu, Lihua (Julie) 
<julie@umassmed.edu<mailto:julie@umassmed.edu>> wrote:
Hi,

Is there a function to import all the exported objects from a package except a 
few named ones in NAMESPACE file?

For example, I would like to import all the functions in S4Vectors except fold. 
Is there a way to  specify this without listing all other functions using 
importFrom?

Many thanks for your help!

Best regards,

Julie


Lihua Julie Zhu, Ph.D
Research Professor
Department of Molecular, Cell and Cancer Biology (MCCB)
Head of MCCB Bioinformatics Core
Program in Molecular Medicine
Program in Bioinformatics and Integrative Biology
University of Massachusetts Medical School
364 Plantation Street, Room 613
Worcester, MA 01605
508-856-5256 phone
(508) 856 5460<tel:%28508%29%20856%205460> fax
http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE=1134


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel<https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=BQMFaQ=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU=UpTcGkW9YjtNtY_r30mgNzZgUYWFj4ELJPOcV6W0RJU=WAqsI7lD8zkJYbTPS5S_fuzT4hf1fGLTZLoHkqxgTs8=>


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] namespace question

[Kasper Daniel Hansen]

No, as far as I know. I asked about this on R-devel a long time ago; would
be nice to have importFromExcept()

Best,
Kasper

On Wed, Mar 30, 2016 at 3:19 PM, Zhu, Lihua (Julie) 
wrote:

> Hi,
>
> Is there a function to import all the exported objects from a package
> except a few named ones in NAMESPACE file?
>
> For example, I would like to import all the functions in S4Vectors except
> fold. Is there a way to  specify this without listing all other functions
> using importFrom?
>
> Many thanks for your help!
>
> Best regards,
>
> Julie
>
> 
> Lihua Julie Zhu, Ph.D
> Research Professor
> Department of Molecular, Cell and Cancer Biology (MCCB)
> Head of MCCB Bioinformatics Core
> Program in Molecular Medicine
> Program in Bioinformatics and Integrative Biology
> University of Massachusetts Medical School
> 364 Plantation Street, Room 613
> Worcester, MA 01605
> 508-856-5256 phone
> (508) 856 5460 fax
>
> http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE=1134
>
>
> [[alternative HTML version deleted]]
>
> ___
> 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] namespace question

[Zhu, Lihua (Julie)]

Hi,

Is there a function to import all the exported objects from a package except a 
few named ones in NAMESPACE file?

For example, I would like to import all the functions in S4Vectors except fold. 
Is there a way to  specify this without listing all other functions using 
importFrom?

Many thanks for your help!

Best regards,

Julie


Lihua Julie Zhu, Ph.D
Research Professor
Department of Molecular, Cell and Cancer Biology (MCCB)
Head of MCCB Bioinformatics Core
Program in Molecular Medicine
Program in Bioinformatics and Integrative Biology
University of Massachusetts Medical School
364 Plantation Street, Room 613
Worcester, MA 01605
508-856-5256 phone
(508) 856 5460 fax
http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE=1134


[[alternative HTML version deleted]]

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

Re: [Bioc-devel] NAMESPACE question

[Robert Castelo]

hi Martin,

thanks for your recommendations regarding the conditional loading of 
packages. I think however, that they are not related to the problem I'm 
referring. Let me put here a reproducible example which works with 
qpgraph version 0.99.7 that I have just pushed to svn:


library(qtl)
library(qpgraph)

map - sim.map(len=100, n.mar=10, anchor.tel=FALSE, eq.spacing=TRUE, 
include.x=FALSE)


eqtlcross - eQTLcross(map)
eqtlcross - addGenes(eqtlcross, 5)
eqtlcross - addeQTL(eqtlcross, g1, location=map[[1]][1])

sim.eqtl - reQTLcross(eqtlcross, rho=0.5, a=1)
cross - sim.cross(map, sim.eqtl, n.ind=100)

gstarts -runif(5, min=range(map[[1]])[1], max=range(map[[1]])[2])

annot - data.frame(chr=rep(names(map)[1], 5),
start=gstarts, end=gstarts+1,
strand=rep(+, 5),
row.names=sim.eqtl$model$Y,
stringsAsFactors=FALSE)

## the following is the method that triggers the
## unexpected behavior. Its last but one instruction
## in line 208 of file qpgraph/R/eQTLnetworkEstimationParam-methods.R
## is the following:
##
## geneAnnotation - geneAnnotation[genes]
##
## and should be using the method [ imported from GenomicRanges
## however it starts loading a number of packages to do the job

param - eQTLnetworkEstimationParam(cross, geneAnnotation=annot, 
genome=simulatedGenome)

Loading required package: parallel

Attaching package: ‘BiocGenerics’

The following objects are masked from ‘package:parallel’:

[...etc...]

sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF8   LC_NUMERIC=C 
LC_TIME=en_US.UTF8LC_COLLATE=en_US.UTF8
 [5] LC_MONETARY=en_US.UTF8LC_MESSAGES=en_US.UTF8 
LC_PAPER=en_US.UTF8   LC_NAME=C
 [9] LC_ADDRESS=C  LC_TELEPHONE=C 
LC_MEASUREMENT=en_US.UTF8 LC_IDENTIFICATION=C


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


other attached packages:
[1] IRanges_1.99.28 S4Vectors_0.2.4 BiocGenerics_0.11.5 
qpgraph_1.99.7  qtl_1.33-7

[6] vimcom_0.9-93   setwidth_1.0-3  colorout_1.0-2

loaded via a namespace (and not attached):
 [1] annotate_1.43.5  AnnotationDbi_1.27.16base64enc_0.1-2 
 BatchJobs_1.4
 [5] BBmisc_1.7   Biobase_2.25.0 
BiocParallel_0.99.22 biomaRt_2.21.1
 [9] Biostrings_2.33.14   bitops_1.0-6 brew_1.0-6 
 checkmate_1.4
[13] codetools_0.2-9  DBI_0.3.1digest_0.6.4 
fail_1.2
[17] foreach_1.4.2futile.logger_1.3.7 
futile.options_1.0.0 GenomeInfoDb_1.1.23
[21] GenomicAlignments_1.1.30 GenomicFeatures_1.17.19 
GenomicRanges_1.17.42graph_1.43.0
[25] grid_3.1.0   iterators_1.0.7  lambda.r_1.1.6 
lattice_0.20-29
[29] Matrix_1.1-4 mvtnorm_1.0-0RCurl_1.95-4.3 
Rgraphviz_2.9.1
[33] Rsamtools_1.17.34RSQLite_0.11.4 
rtracklayer_1.25.17  sendmailR_1.2-1
[37] stringr_0.6.2tools_3.1.0  XML_3.98-1.1 
xtable_1.7-4

[41] XVector_0.5.8zlibbioc_1.11.1


cheers,
robert.



On 10/07/2014 05:54 PM, Martin Morgan wrote:

On 10/07/2014 08:15 AM, Robert Castelo wrote:

hi, it happens only with [, that's why i'm puzzled.

it behaves as if you load a GRanges object 'x' and try to subset it

x[1]

without loading 'GenomicRanges' first.


Is there a reproducible example? I see in your code there are several
places where you require() or library() various packages. I think one of
these Depends: on GenomicRanges, and the messages you see are the effect
of moving GenomicRanges from 'loaded' to 'attached'. You can see the
effect with

library(qpgraph)
sessionInfo() ## GenomicRanges loaded but not attached
library(GenomicRanges) ## information about the package being attached

Probably in your code you do not actually want to require() ad hoc
packages and influence the user search path (and implicitly rely on
search path order for correct functionality), but rather to
requireNamespace(foo); foo::fun(...) (or possibly loadNamespace()).

Complicated!

Martin



robert.

On 10/07/2014 05:05 PM, Michael Lawrence wrote:

Does that happen with the other methods or just [? As a last resort,
you could just drop the import (because [ is a primitive, it should
just work).

On Tue, Oct 7, 2014 at 3:08 AM, Robert Castelo robert.cast...@upf.edu
mailto:robert.cast...@upf.edu wrote:

hi Martin,

On 10/06/2014 07:24 PM, Martin Morgan wrote:
[...]

There are two 'as.vector' generics, one defined in Matrix and one in
BiocGenerics (and made available via IRanges). These generics have
different methods

 showMethods(Matrix::as.vector)
Function: as.vector (package base)
x=abIndex, mode=ANY
x=abIndex, mode=character
x=ANY, mode=ANY
x=dgCMatrix, mode=missing
x=dgeMatrix, mode=missing
x=diagonalMatrix, mode=missing
x=dsCMatrix, mode=missing
x=ldenseMatrix, 

Re: [Bioc-devel] NAMESPACE question

[Hervé Pagès]

Hi Robert, Martin,

Yes using requireNamespace() internally is much cleaner than using
require(). Sorry for that. Just made the change in S4Vectors 0.2.6.
FYI the need to load IRanges namespace in a couple of places
inside S4Vectors is temporary and will go away soon.

Cheers,
H.

On 10/09/2014 09:33 AM, Martin Morgan wrote:

On 10/09/2014 08:00 AM, Robert Castelo wrote:

hi Martin,

thanks for your recommendations regarding the conditional loading of
packages. I
think however, that they are not related to the problem I'm referring.
Let me
put here a reproducible example which works with qpgraph version
0.99.7 that I
have just pushed to svn:

library(qtl)
library(qpgraph)

map - sim.map(len=100, n.mar=10, anchor.tel=FALSE, eq.spacing=TRUE,
include.x=FALSE)

eqtlcross - eQTLcross(map)
eqtlcross - addGenes(eqtlcross, 5)
eqtlcross - addeQTL(eqtlcross, g1, location=map[[1]][1])

sim.eqtl - reQTLcross(eqtlcross, rho=0.5, a=1)
cross - sim.cross(map, sim.eqtl, n.ind=100)

gstarts -runif(5, min=range(map[[1]])[1], max=range(map[[1]])[2])

annot - data.frame(chr=rep(names(map)[1], 5),
 start=gstarts, end=gstarts+1,
 strand=rep(+, 5),
 row.names=sim.eqtl$model$Y,
 stringsAsFactors=FALSE)

## the following is the method that triggers the
## unexpected behavior. Its last but one instruction
## in line 208 of file qpgraph/R/eQTLnetworkEstimationParam-methods.R
## is the following:
##
## geneAnnotation - geneAnnotation[genes]
##
## and should be using the method [ imported from GenomicRanges
## however it starts loading a number of packages to do the job

param - eQTLnetworkEstimationParam(cross, geneAnnotation=annot,
genome=simulatedGenome)
Loading required package: parallel

Attaching package: ‘BiocGenerics’

The following objects are masked from ‘package:parallel’:

[...etc...]


Hmm, I see that the parallel, BiocGenerics, and stats4 packages are
being attached. In a new R session I did this:

  trace(loadNamespace, tracer=recover)
Tracing function loadNamespace in package base
[1] loadNamespace
  param - eQTLnetworkEstimationParam(cross, geneAnnotation=annot,
genome=simulatedGenome)
Loading required package: parallel
Tracing loadNamespace(package, c(which.lib.loc, lib.loc)) on entry

Enter a frame number, or 0 to exit

  1: eQTLnetworkEstimationParam(cross, geneAnnotation = annot, genome =
simulat
  2: geneAnnotation[genes]
  3: geneAnnotation[genes]
  4: extractROWS(x, i)
  5: extractROWS(x, i)
  6: extractROWS(seqnames(x), i)
  7: extractROWS(seqnames(x), i)
  8: suppressWarnings(require(IRanges, quietly = TRUE))
  9: withCallingHandlers(expr, warning = function(w)
invokeRestart(muffleWarnin
10: require(IRanges, quietly = TRUE)
...

and it's likely from

./S4Vectors/R/Rle-class.R:if (!suppressWarnings(require(IRanges,
quietly=TRUE)))
./S4Vectors/R/Rle-class.R:if (!suppressWarnings(require(IRanges,
quietly=TRUE)))

could be addressed with suppressPackageStartupMessages()
(less-preferred) or requireNamespace(IRanges) followed by
IRanges::...; let's see if we can get that fixed...

Martin



sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
  [1] LC_CTYPE=en_US.UTF8   LC_NUMERIC=C LC_TIME=en_US.UTF8
LC_COLLATE=en_US.UTF8
  [5] LC_MONETARY=en_US.UTF8LC_MESSAGES=en_US.UTF8
LC_PAPER=en_US.UTF8
LC_NAME=C
  [9] LC_ADDRESS=C  LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF8
LC_IDENTIFICATION=C

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

other attached packages:
[1] IRanges_1.99.28 S4Vectors_0.2.4 BiocGenerics_0.11.5
qpgraph_1.99.7  qtl_1.33-7
[6] vimcom_0.9-93   setwidth_1.0-3  colorout_1.0-2

loaded via a namespace (and not attached):
  [1] annotate_1.43.5  AnnotationDbi_1.27.16base64enc_0.1-2
BatchJobs_1.4
  [5] BBmisc_1.7   Biobase_2.25.0 BiocParallel_0.99.22
biomaRt_2.21.1
  [9] Biostrings_2.33.14   bitops_1.0-6 brew_1.0-6
checkmate_1.4
[13] codetools_0.2-9  DBI_0.3.1digest_0.6.4
fail_1.2
[17] foreach_1.4.2futile.logger_1.3.7 futile.options_1.0.0
GenomeInfoDb_1.1.23
[21] GenomicAlignments_1.1.30 GenomicFeatures_1.17.19
GenomicRanges_1.17.42
graph_1.43.0
[25] grid_3.1.0   iterators_1.0.7  lambda.r_1.1.6
lattice_0.20-29
[29] Matrix_1.1-4 mvtnorm_1.0-0RCurl_1.95-4.3
Rgraphviz_2.9.1
[33] Rsamtools_1.17.34RSQLite_0.11.4 rtracklayer_1.25.17
sendmailR_1.2-1
[37] stringr_0.6.2tools_3.1.0  XML_3.98-1.1
xtable_1.7-4
[41] XVector_0.5.8zlibbioc_1.11.1


cheers,
robert.



On 10/07/2014 05:54 PM, Martin Morgan wrote:

On 10/07/2014 08:15 AM, Robert Castelo wrote:

hi, it happens only with [, that's why i'm puzzled.

it behaves as if you load a GRanges object 'x' and try to subset it

x[1]

without loading 'GenomicRanges' first.

Re: [Bioc-devel] NAMESPACE question

[Michael Lawrence]

Does that happen with the other methods or just [? As a last resort, you
could just drop the import (because [ is a primitive, it should just
work).

On Tue, Oct 7, 2014 at 3:08 AM, Robert Castelo robert.cast...@upf.edu
wrote:

 hi Martin,

 On 10/06/2014 07:24 PM, Martin Morgan wrote:
 [...]

  There are two 'as.vector' generics, one defined in Matrix and one in
 BiocGenerics (and made available via IRanges). These generics have
 different methods

   showMethods(Matrix::as.vector)
 Function: as.vector (package base)
 x=abIndex, mode=ANY
 x=abIndex, mode=character
 x=ANY, mode=ANY
 x=dgCMatrix, mode=missing
 x=dgeMatrix, mode=missing
 x=diagonalMatrix, mode=missing
 x=dsCMatrix, mode=missing
 x=ldenseMatrix, mode=missing
 x=Matrix, mode=missing
 x=ndenseMatrix, mode=missing
 x=sparseVector, mode=character
 x=sparseVector, mode=missing

   showMethods(BiocGenerics::as.vector)
 Function: as.vector (package BiocGenerics)
 x=ANY
 x=AtomicList
 x=Rle
 x=XDouble
 x=XInteger
 x=XRaw
 x=XString
 x=XStringSet

 so it's important that your code clearly distinguish between generics.
 One possibility is to remove importMethodsFrom(IRanges, as.vector) from
 the NAMESPACE, and explicitly use IRanges::as.vector(...) in your code.


 ok, i've done this as it is the easiest at the moment to meet the release
 schedule. i guess that in the future i should try to avoid using the '::'
 operator by importing exclusively what is needed from each package.

  codetoolsBioC::writeNamespaceImports(qpgraph) might provide you with
 some guidance (it's not 100% reliable; available via svn at
 https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC
 )
 about what functionality is being imported.


 thanks for the heads up about codetoolsBioC, i've tried it out and seen
 that some of the suggested imports are not necessary but some others i was
 really missing them (which makes me wonder how was it possible that he
 package did not break at those points).

 one further question related to NAMESPACE. i subset GRanges objects in the
 package via the '[' operator, i've included this into the NAMESPACE file as:

 importMethodsFrom(GenomicRanges,
   c, cbind, rbind,
   mcols-, start, end, strand, sort,
   [, [-, [[, [[-, $, $-)

 however, when the package reaches a subset operation x[i] with x being a
 GRanges object, an entire package loading sequence starts:

 Loading required package: GenomicRanges
 Loading required package: BiocGenerics
 Loading required package: parallel

 Attaching package: ‘BiocGenerics’
 [... etc ...]

 which may look a bit odd to the user. for every other imported method the
 package uses them silently without loading the corresponding package, am i
 importing '[' for GRanges objects from the wrong package? is there a way to
 import '[' so that my package can use it without triggering that package
 loading sequence?


 thanks again!
 robert.


 ___
 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] NAMESPACE question

[Martin Morgan]

On 10/07/2014 08:15 AM, Robert Castelo wrote:

hi, it happens only with [, that's why i'm puzzled.

it behaves as if you load a GRanges object 'x' and try to subset it

x[1]

without loading 'GenomicRanges' first.


Is there a reproducible example? I see in your code there are several places 
where you require() or library() various packages. I think one of these 
Depends: on GenomicRanges, and the messages you see are the effect of moving 
GenomicRanges from 'loaded' to 'attached'. You can see the effect with


  library(qpgraph)
  sessionInfo()   ## GenomicRanges loaded but not attached
  library(GenomicRanges)  ## information about the package being attached

Probably in your code you do not actually want to require() ad hoc packages and 
influence the user search path (and implicitly rely on search path order for 
correct functionality), but rather to requireNamespace(foo); foo::fun(...) (or 
possibly loadNamespace()).


Complicated!

Martin



robert.

On 10/07/2014 05:05 PM, Michael Lawrence wrote:

Does that happen with the other methods or just [? As a last resort,
you could just drop the import (because [ is a primitive, it should
just work).

On Tue, Oct 7, 2014 at 3:08 AM, Robert Castelo robert.cast...@upf.edu
mailto:robert.cast...@upf.edu wrote:

hi Martin,

On 10/06/2014 07:24 PM, Martin Morgan wrote:
[...]

There are two 'as.vector' generics, one defined in Matrix and one in
BiocGenerics (and made available via IRanges). These generics have
different methods

  showMethods(Matrix::as.vector)
Function: as.vector (package base)
x=abIndex, mode=ANY
x=abIndex, mode=character
x=ANY, mode=ANY
x=dgCMatrix, mode=missing
x=dgeMatrix, mode=missing
x=diagonalMatrix, mode=missing
x=dsCMatrix, mode=missing
x=ldenseMatrix, mode=missing
x=Matrix, mode=missing
x=ndenseMatrix, mode=missing
x=sparseVector, mode=character
x=sparseVector, mode=missing

  showMethods(BiocGenerics::as.__vector)
Function: as.vector (package BiocGenerics)
x=ANY
x=AtomicList
x=Rle
x=XDouble
x=XInteger
x=XRaw
x=XString
x=XStringSet

so it's important that your code clearly distinguish between
generics.
One possibility is to remove importMethodsFrom(IRanges,
as.vector) from
the NAMESPACE, and explicitly use IRanges::as.vector(...) in
your code.


ok, i've done this as it is the easiest at the moment to meet the
release schedule. i guess that in the future i should try to avoid
using the '::' operator by importing exclusively what is needed from
each package.

codetoolsBioC::__writeNamespaceImports(__qpgraph) might
provide you with
some guidance (it's not 100% reliable; available via svn at

https://hedgehog.fhcrc.org/__bioconductor/trunk/madman/__Rpacks/codetoolsBioC

https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC)
about what functionality is being imported.


thanks for the heads up about codetoolsBioC, i've tried it out and
seen that some of the suggested imports are not necessary but some
others i was really missing them (which makes me wonder how was it
possible that he package did not break at those points).

one further question related to NAMESPACE. i subset GRanges objects
in the package via the '[' operator, i've included this into the
NAMESPACE file as:

importMethodsFrom(__GenomicRanges,
   c, cbind, rbind,
mcols-, start, end, strand, sort,
[, [-, [[, [[-, $, $-)

however, when the package reaches a subset operation x[i] with x
being a GRanges object, an entire package loading sequence starts:

Loading required package: GenomicRanges
Loading required package: BiocGenerics
Loading required package: parallel

Attaching package: ‘BiocGenerics’
[... etc ...]

which may look a bit odd to the user. for every other imported
method the package uses them silently without loading the
corresponding package, am i importing '[' for GRanges objects from
the wrong package? is there a way to import '[' so that my package
can use it without triggering that package loading sequence?


thanks again!
robert.


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







--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

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

Re: [Bioc-devel] NAMESPACE question

[Martin Morgan]

On 10/07/2014 07:05 PM, Michael Lawrence wrote:

I think the intent there is that if you virtually always need a package to
generate the input or analyze the output of a documented function, it
should be in Depends. If it's a package that is only useful for
demonstration, it should be in Suggests, and one should abide by the same
guidelines (requireNamespace, etc) as Martin contributed.


I adjusted the wording a bit. I was also quite disturbed to find how similar my 
Suggests illustration is to the advice in Writing R Extensions, 
RShowDoc('R-exts'), section 1.1.3.1.


Martin



On Tue, Oct 7, 2014 at 6:00 PM, Dario Strbenac dstr7...@uni.sydney.edu.au
wrote:


The guidelines state :

Depends: is appropriate when a package is used in the example section of a
man page.

I think such packages should be in Suggests. In the example, the package
should be loaded by :

if(require(examplePackage))
{
   exampleFunction(data)
}

--
Dario Strbenac
PhD Student
University of Sydney
Camperdown NSW 2050
Australia
___
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




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

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

Re: [Bioc-devel] NAMESPACE question

[Martin Morgan]

On 10/05/2014 01:39 PM, Robert Castelo wrote:

hi,

i have the following warning message when installing the devel version
(0.99.5) of my package 'qpgraph':

** testing if installed package can be loaded
Warning: replacing previous import by 'IRanges::as.vector' when loading
'qpgraph'
* DONE (qpgraph)

after investigating the issue i think it has to do with the fact that in
the NAMESPACE of 'qpgraph' i'm importing the whole Matrix package and
later the 'as.vector()' method defined in IRanges. The NAMESPACE file
looks like this:

useDynLib(qpgraph)

import(methods)

import(graph)

import(Matrix)

... (few lines later) ...

importMethodsFrom(IRanges,
  as.vector)

... (rest of the file) ...

from what i have learned while reading documentation and googling about
this issue, it seems that the solution would be to import every
function/method i use from Matrix before i do the import from IRanges,
but i use the dspMatrix-class all over the package and i don't know how
would i find out what set of functions/methods i have to explicitly
import. i can import a few of the methods from Matrix i know from the
top of my head that the package is using but i'm afraid i'll be missing
other methods that will break the package when using it in situations
outside current examples and unit tests.

i'd appreciate if you have a suggestion about what to do in this situation.


There are two 'as.vector' generics, one defined in Matrix and one in 
BiocGenerics (and made available via IRanges). These generics have different methods


 showMethods(Matrix::as.vector)
Function: as.vector (package base)
x=abIndex, mode=ANY
x=abIndex, mode=character
x=ANY, mode=ANY
x=dgCMatrix, mode=missing
x=dgeMatrix, mode=missing
x=diagonalMatrix, mode=missing
x=dsCMatrix, mode=missing
x=ldenseMatrix, mode=missing
x=Matrix, mode=missing
x=ndenseMatrix, mode=missing
x=sparseVector, mode=character
x=sparseVector, mode=missing

 showMethods(BiocGenerics::as.vector)
Function: as.vector (package BiocGenerics)
x=ANY
x=AtomicList
x=Rle
x=XDouble
x=XInteger
x=XRaw
x=XString
x=XStringSet

so it's important that your code clearly distinguish between generics. One 
possibility is to remove importMethodsFrom(IRanges, as.vector) from the 
NAMESPACE, and explicitly use IRanges::as.vector(...) in your code.


codetoolsBioC::writeNamespaceImports(qpgraph) might provide you with some 
guidance (it's not 100% reliable; available via svn at 
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC) about 
what functionality is being imported.


Martin



thanks!
robert.

[[alternative HTML version deleted]]

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




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

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

[Bioc-devel] NAMESPACE question

[Robert Castelo]

hi,

i have the following warning message when installing the devel version 
(0.99.5) of my package 'qpgraph':

** testing if installed package can be loaded
Warning: replacing previous import by 'IRanges::as.vector' when loading 
'qpgraph'
* DONE (qpgraph)

after investigating the issue i think it has to do with the fact that in 
the NAMESPACE of 'qpgraph' i'm importing the whole Matrix package and 
later the 'as.vector()' method defined in IRanges. The NAMESPACE file 
looks like this:

useDynLib(qpgraph)

import(methods)

import(graph)

import(Matrix)

... (few lines later) ...

importMethodsFrom(IRanges,
 as.vector)

... (rest of the file) ...

from what i have learned while reading documentation and googling about 
this issue, it seems that the solution would be to import every 
function/method i use from Matrix before i do the import from IRanges, 
but i use the dspMatrix-class all over the package and i don't know how 
would i find out what set of functions/methods i have to explicitly 
import. i can import a few of the methods from Matrix i know from the 
top of my head that the package is using but i'm afraid i'll be missing 
other methods that will break the package when using it in situations 
outside current examples and unit tests.

i'd appreciate if you have a suggestion about what to do in this situation.

thanks!
robert.

[[alternative HTML version deleted]]

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