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

[Bhagwat, Aditya]

Waaw, thanks Michael, that is really clarifying. 


From: Michael Lawrence [lawrence.mich...@gene.com]
Sent: Friday, September 06, 2019 7:32 PM
To: Bhagwat, Aditya
Cc: Kasper Daniel Hansen; Michael Lawrence; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

There's never a need to attach a package to satisfy the dependencies
of another package. That would defeat the purpose of namespaces.

The three coercion functions gets at the heart of the S3/S4 mess.
setAs() provides a dynamic coercion mechanism, so is useful for as(x,
class) when class can be anything. as.data.frame() is an S3 generic
defined by the base package, so every package sees it. Something
promotes as.data.frame() to an S4 generic, but only packages that
import the generic can see it. That likely excludes the vast majority
of CRAN packages. Thus, we define an S3 method for calls to the S3
generic. The S4 generic will fall back to the S3 methods; however, it
will first check all S4 methods. Defining as.data.frame,Vector()
defends against the definition of a method above it, such as
as.data.frame,Annotated(), which would intercept dispatch to the S3
as.data.frame.Vector().

Michael

On Fri, Sep 6, 2019 at 10:08 AM Bhagwat, Aditya
 wrote:
>
> Thanks Kasper and Michael.
>
>
>
> The importClassesFrom  sounds like something that would allow an 
> attachment-free S4 class import, will check them out.
>
> Michael, the current auto-attach is causing 66 namespace clashes – not 
> feeling very comfortable about that, so trying to avoid them.
>
>
>
> I also think there’s something about S4 coercion that I don’t yet fully 
> understand.
>
> For instance: the S4Vectors package has three different versions of a 
> S4Vectors::Vector -> data.frame coercer. Why? Any useful pointers?
>
>
>
> setAs("Vector", "data.frame", function(from) as.data.frame(from))
>
>
>
> as.data.frame.Vector <- function(x, row.names=NULL, optional=FALSE, ...) {
>
> as.data.frame(x, row.names=NULL, optional=optional, ...)
>
> }
>
>
>
> setMethod("as.data.frame", "Vector",
>
>   function(x, row.names=NULL, optional=FALSE, ...)
>
>   {
>
>   x <- as.vector(x)
>
>   as.data.frame(x, row.names=row.names, optional=optional, ...)
>
>   })
>
>
>
>
>
>
>
> From: Kasper Daniel Hansen 
> Sent: Freitag, 6. September 2019 17:49
> To: Michael Lawrence 
> Cc: Bhagwat, Aditya ; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
>
>
> There are
>
>   importMethodsFrom(PACKAGE, NAME_OF_METHODS)
>
>   importClassesFrom(PACKAGE, NAME_OF_METHODS)
>
> to help with selective importing S4 methods/classes.  See section 1.5.6 of 
> WRE.
>
>
>
> On Fri, Sep 6, 2019 at 9:24 AM Michael Lawrence via Bioc-devel 
>  wrote:
>
> It sounds like you are trying to defer loading of namespaces in order
> to save time when they are unnecessary? That's probably going to end
> up a losing battle.
>
> On Fri, Sep 6, 2019 at 5:47 AM Bhagwat, Aditya
>  wrote:
> >
> > Thank you Michael,
> >
> > Appreciate your time for helping me fill the gaps in my understanding of 
> > the S4 flow :-).
> >
> > It all started when I defined (in my multicrispr package) the S4 coercer :
> > methods::setAs( "BSgenome",
> >
> > "GRanges",
> > function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")
> >
> > When building, I noticed the message
> > in method for 'coerce' with signature '"BSgenome","GRanges"': no definition 
> > for class "BSgenome"
> >
> > So, I added
> > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> >
> > That loads all these dependencies.
> > From your answer, I understand that there is currently no alternative to 
> > loading all these dependencies.
> > I guess because these dependencies are needed to provide for all required 
> > S4 methods for the BSgenome class, am I right?
> >
> > Is there a way to define a methods::setAs without loading the class 
> > definition?
> >
> > Aditya
> >
> >
> >
> >
> > 
> > From: Michael Lawrence [lawrence.mich...@gene.com]
> > Sent: Friday, September 06, 2019 1:09 PM
> > To: Bhagwat, Aditya
> > Cc: bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> > BiocGenerics (and others)?
> >
> > The way to keep a "clean namespace" is to selectively import symbols
> > into your namespace, not to import _nothing_ into your namespace.
> > Otherwise, your code will fill with namespace qualifications that
> > distract from what is more important to communicate: the intent of the
> > code. And no, there's no way to define method signatures using
> > anything other than simple class names.
> >
> > It would be interesting to explore alternative ways of specifying
> > method signatures. One way would be if every package exported a "class
> > reference" (class name with 

Re: [Rd] [EXTERNAL] Re: RE: install_github and survival

[Therneau, Terry M., Ph.D. via R-devel]

Many thanks.  Something obvious is sometimes the hardest thing for me to see.

Terry


On 9/6/19 7:10 AM, Iñaki Ucar wrote:
> On Fri, 6 Sep 2019 at 14:08, Therneau, Terry M., Ph.D. via R-devel
>  wrote:
>> Yes, that is exactly the problem.  The code found in the "config" script is 
>> never run.
>> But why doesn't it get run?
> It should be called "configure", not "config".
>
> Iñaki


[[alternative HTML version deleted]]

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

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

[Michael Lawrence via Bioc-devel]

There's never a need to attach a package to satisfy the dependencies
of another package. That would defeat the purpose of namespaces.

The three coercion functions gets at the heart of the S3/S4 mess.
setAs() provides a dynamic coercion mechanism, so is useful for as(x,
class) when class can be anything. as.data.frame() is an S3 generic
defined by the base package, so every package sees it. Something
promotes as.data.frame() to an S4 generic, but only packages that
import the generic can see it. That likely excludes the vast majority
of CRAN packages. Thus, we define an S3 method for calls to the S3
generic. The S4 generic will fall back to the S3 methods; however, it
will first check all S4 methods. Defining as.data.frame,Vector()
defends against the definition of a method above it, such as
as.data.frame,Annotated(), which would intercept dispatch to the S3
as.data.frame.Vector().

Michael

On Fri, Sep 6, 2019 at 10:08 AM Bhagwat, Aditya
 wrote:
>
> Thanks Kasper and Michael.
>
>
>
> The importClassesFrom  sounds like something that would allow an 
> attachment-free S4 class import, will check them out.
>
> Michael, the current auto-attach is causing 66 namespace clashes – not 
> feeling very comfortable about that, so trying to avoid them.
>
>
>
> I also think there’s something about S4 coercion that I don’t yet fully 
> understand.
>
> For instance: the S4Vectors package has three different versions of a 
> S4Vectors::Vector -> data.frame coercer. Why? Any useful pointers?
>
>
>
> setAs("Vector", "data.frame", function(from) as.data.frame(from))
>
>
>
> as.data.frame.Vector <- function(x, row.names=NULL, optional=FALSE, ...) {
>
> as.data.frame(x, row.names=NULL, optional=optional, ...)
>
> }
>
>
>
> setMethod("as.data.frame", "Vector",
>
>   function(x, row.names=NULL, optional=FALSE, ...)
>
>   {
>
>   x <- as.vector(x)
>
>   as.data.frame(x, row.names=row.names, optional=optional, ...)
>
>   })
>
>
>
>
>
>
>
> From: Kasper Daniel Hansen 
> Sent: Freitag, 6. September 2019 17:49
> To: Michael Lawrence 
> Cc: Bhagwat, Aditya ; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
>
>
> There are
>
>   importMethodsFrom(PACKAGE, NAME_OF_METHODS)
>
>   importClassesFrom(PACKAGE, NAME_OF_METHODS)
>
> to help with selective importing S4 methods/classes.  See section 1.5.6 of 
> WRE.
>
>
>
> On Fri, Sep 6, 2019 at 9:24 AM Michael Lawrence via Bioc-devel 
>  wrote:
>
> It sounds like you are trying to defer loading of namespaces in order
> to save time when they are unnecessary? That's probably going to end
> up a losing battle.
>
> On Fri, Sep 6, 2019 at 5:47 AM Bhagwat, Aditya
>  wrote:
> >
> > Thank you Michael,
> >
> > Appreciate your time for helping me fill the gaps in my understanding of 
> > the S4 flow :-).
> >
> > It all started when I defined (in my multicrispr package) the S4 coercer :
> > methods::setAs( "BSgenome",
> >
> > "GRanges",
> > function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")
> >
> > When building, I noticed the message
> > in method for 'coerce' with signature '"BSgenome","GRanges"': no definition 
> > for class "BSgenome"
> >
> > So, I added
> > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> >
> > That loads all these dependencies.
> > From your answer, I understand that there is currently no alternative to 
> > loading all these dependencies.
> > I guess because these dependencies are needed to provide for all required 
> > S4 methods for the BSgenome class, am I right?
> >
> > Is there a way to define a methods::setAs without loading the class 
> > definition?
> >
> > Aditya
> >
> >
> >
> >
> > 
> > From: Michael Lawrence [lawrence.mich...@gene.com]
> > Sent: Friday, September 06, 2019 1:09 PM
> > To: Bhagwat, Aditya
> > Cc: bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> > BiocGenerics (and others)?
> >
> > The way to keep a "clean namespace" is to selectively import symbols
> > into your namespace, not to import _nothing_ into your namespace.
> > Otherwise, your code will fill with namespace qualifications that
> > distract from what is more important to communicate: the intent of the
> > code. And no, there's no way to define method signatures using
> > anything other than simple class names.
> >
> > It would be interesting to explore alternative ways of specifying
> > method signatures. One way would be if every package exported a "class
> > reference" (class name with package attribute, at least) for each of
> > its classes. Those could be treated like any other exported object,
> > and referenced via namespace qualification. It would require major
> > changes to the methods package but that should probably happen anyway
> > to support disambiguation when two packages define a class of the same
> > name. It would be nice to get away 

Re: [Rd] Cryptic error message from namespaceExport

[Thierry Onkelinx via R-devel]

Dear Michael,

my package has setOldClass("inla") and the NAMESPACE
contains exportClasses(inla) and importFrom(INLA, inla.posterior.sample)

the old version of INLA uses the S3 class "inla" but does not export it.
the new version of INLA has setOldClass("inla") and the NAMESPACE
contains exportClasses(inla)

installing my package in combination with an older INLA version works

install.packages("
https://inla.r-inla-download.org/R/stable/src/contrib/INLA_18.07.12.tar.gz;,
repos = NULL)
remotes::install_github("inbo/inlatools", upgrade = FALSE, force = TRUE)

installing my package with a recent INLA versions yields the error

install.packages("
https://inla.r-inla-download.org/R/stable/src/contrib/INLA_19.09.03.tar.gz;,
repos = NULL)
remotes::install_github("inbo/inlatools", upgrade = FALSE, force = TRUE)

Warning: INLA is a very large package. The old version is 87 MB, the new
one 250 MB

Best regards,

ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be

///
To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey
///




Op vr 6 sep. 2019 om 17:16 schreef Michael Lawrence <
lawrence.mich...@gene.com>:

> Just to clarify, your package is exporting a class that is not
> defined? Or is it exporting a class that is defined by a dependency
> and then masked by setOldClass()? A simple reproducible example would
> help.
>
> On Fri, Sep 6, 2019 at 7:48 AM Thierry Onkelinx via R-devel
>  wrote:
> >
> > Dear all,
> >
> > Today I got this error message (R 3.6.1) when installing my package:
> >
> > Error: package or namespace load failed for ‘inlatools’ in
> > namespaceExport(ns, exports):
> >  undefined exports: .__C__inla
> >
> > My package was using setOldClass("inla") and exported the "inla" class
> via
> > the NAMESPACE. It imports functions from the INLA package. Older versions
> > of the INLA package did not export the "inla" class. Hence the use of
> > setOldClass().
> > The current version of the INLA package does export the "inla" class
> > through it NAMESPACE. This triggered the error described above.
> >
> > Is the possible to improve this error message? The current message is
> > misleading as neither packages contain the string ".__C__inla"
> >
> > Best regards,
> >
> > ir. Thierry Onkelinx
> > Statisticus / Statistician
> >
> > Vlaamse Overheid / Government of Flanders
> > INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE
> AND
> > FOREST
> > Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> > thierry.onkel...@inbo.be
> > Havenlaan 88 bus 73, 1000 Brussel
> > www.inbo.be
> >
> >
> ///
> > To call in the statistician after the experiment is done may be no more
> > than asking him to perform a post-mortem examination: he may be able to
> say
> > what the experiment died of. ~ Sir Ronald Aylmer Fisher
> > The plural of anecdote is not data. ~ Roger Brinner
> > The combination of some data and an aching desire for an answer does not
> > ensure that a reasonable answer can be extracted from a given body of
> data.
> > ~ John Tukey
> >
> ///
> >
> > 
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Michael Lawrence
> Scientist, Bioinformatics and Computational Biology
> Genentech, A Member of the Roche Group
> Office +1 (650) 225-7760
> micha...@gene.com
>
> Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube
>

[[alternative HTML version deleted]]

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

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

[Bhagwat, Aditya]

Thanks Kasper and Michael.

The importClassesFrom  sounds like something that would allow an 
attachment-free S4 class import, will check them out.
Michael, the current auto-attach is causing 66 namespace 
clashes – not feeling very 
comfortable about that, so trying to avoid them.

I also think there’s something about S4 coercion that I don’t yet fully 
understand.
For instance: the S4Vectors package has three different versions of a 
S4Vectors::Vector -> data.frame coercer. Why? Any useful pointers?

setAs("Vector", "data.frame", function(from) as.data.frame(from))

as.data.frame.Vector <- function(x, row.names=NULL, optional=FALSE, ...) {
as.data.frame(x, row.names=NULL, optional=optional, ...)
}

setMethod("as.data.frame", "Vector",
  function(x, row.names=NULL, optional=FALSE, ...)
  {
  x <- as.vector(x)
  as.data.frame(x, row.names=row.names, optional=optional, ...)
  })



From: Kasper Daniel Hansen 
Sent: Freitag, 6. September 2019 17:49
To: Michael Lawrence 
Cc: Bhagwat, Aditya ; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

There are
  importMethodsFrom(PACKAGE, NAME_OF_METHODS)
  importClassesFrom(PACKAGE, NAME_OF_METHODS)
to help with selective importing S4 methods/classes.  See section 1.5.6 of WRE.

On Fri, Sep 6, 2019 at 9:24 AM Michael Lawrence via Bioc-devel 
mailto:bioc-devel@r-project.org>> wrote:
It sounds like you are trying to defer loading of namespaces in order
to save time when they are unnecessary? That's probably going to end
up a losing battle.

On Fri, Sep 6, 2019 at 5:47 AM Bhagwat, Aditya
mailto:aditya.bhag...@mpi-bn.mpg.de>> wrote:
>
> Thank you Michael,
>
> Appreciate your time for helping me fill the gaps in my understanding of the 
> S4 flow :-).
>
> It all started when I defined (in my multicrispr package) the S4 coercer :
> methods::setAs( "BSgenome",
>
> "GRanges",
> function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")
>
> When building, I noticed the message
> in method for 'coerce' with signature '"BSgenome","GRanges"': no definition 
> for class "BSgenome"
>
> So, I added
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> That loads all these dependencies.
> From your answer, I understand that there is currently no alternative to 
> loading all these dependencies.
> I guess because these dependencies are needed to provide for all required S4 
> methods for the BSgenome class, am I right?
>
> Is there a way to define a methods::setAs without loading the class 
> definition?
>
> Aditya
>
>
>
>
> 
> From: Michael Lawrence 
> [lawrence.mich...@gene.com]
> Sent: Friday, September 06, 2019 1:09 PM
> To: Bhagwat, Aditya
> Cc: bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
> The way to keep a "clean namespace" is to selectively import symbols
> into your namespace, not to import _nothing_ into your namespace.
> Otherwise, your code will fill with namespace qualifications that
> distract from what is more important to communicate: the intent of the
> code. And no, there's no way to define method signatures using
> anything other than simple class names.
>
> It would be interesting to explore alternative ways of specifying
> method signatures. One way would be if every package exported a "class
> reference" (class name with package attribute, at least) for each of
> its classes. Those could be treated like any other exported object,
> and referenced via namespace qualification. It would require major
> changes to the methods package but that should probably happen anyway
> to support disambiguation when two packages define a class of the same
> name. It would be nice to get away from the exportClasses() and
> importClasses() stuff. File that under the "rainy year" category.
>
> Michael
>
> On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
> mailto:aditya.bhag...@mpi-bn.mpg.de>> wrote:
> >
> > Dear Bioc devel,
> >
> > Is it possible to import the BSgenome class without attaching BiocGenerics 
> > (to keep a clean namespace during the development of 
> > multicrispr).
> >
> > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> >
> > (Posted earlier on BioC support 
> > and redirected here following Martin's suggestion)
> >
> > Thankyou :-)
> >
> > Aditya
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>
> --
> Michael Lawrence
> Scientist, Bioinformatics and Computational Biology
> Genentech, A Member of the 

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

[Kasper Daniel Hansen]

There are
  importMethodsFrom(PACKAGE, NAME_OF_METHODS)
  importClassesFrom(PACKAGE, NAME_OF_METHODS)
to help with selective importing S4 methods/classes.  See section 1.5.6 of
WRE.

On Fri, Sep 6, 2019 at 9:24 AM Michael Lawrence via Bioc-devel <
bioc-devel@r-project.org> wrote:

> It sounds like you are trying to defer loading of namespaces in order
> to save time when they are unnecessary? That's probably going to end
> up a losing battle.
>
> On Fri, Sep 6, 2019 at 5:47 AM Bhagwat, Aditya
>  wrote:
> >
> > Thank you Michael,
> >
> > Appreciate your time for helping me fill the gaps in my understanding of
> the S4 flow :-).
> >
> > It all started when I defined (in my multicrispr package) the S4 coercer
> :
> > methods::setAs( "BSgenome",
> >
> > "GRanges",
> > function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")
> >
> > When building, I noticed the message
> > in method for 'coerce' with signature '"BSgenome","GRanges"': no
> definition for class "BSgenome"
> >
> > So, I added
> > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> >
> > That loads all these dependencies.
> > From your answer, I understand that there is currently no alternative to
> loading all these dependencies.
> > I guess because these dependencies are needed to provide for all
> required S4 methods for the BSgenome class, am I right?
> >
> > Is there a way to define a methods::setAs without loading the class
> definition?
> >
> > Aditya
> >
> >
> >
> >
> > 
> > From: Michael Lawrence [lawrence.mich...@gene.com]
> > Sent: Friday, September 06, 2019 1:09 PM
> > To: Bhagwat, Aditya
> > Cc: bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] Import BSgenome class without attaching
> BiocGenerics (and others)?
> >
> > The way to keep a "clean namespace" is to selectively import symbols
> > into your namespace, not to import _nothing_ into your namespace.
> > Otherwise, your code will fill with namespace qualifications that
> > distract from what is more important to communicate: the intent of the
> > code. And no, there's no way to define method signatures using
> > anything other than simple class names.
> >
> > It would be interesting to explore alternative ways of specifying
> > method signatures. One way would be if every package exported a "class
> > reference" (class name with package attribute, at least) for each of
> > its classes. Those could be treated like any other exported object,
> > and referenced via namespace qualification. It would require major
> > changes to the methods package but that should probably happen anyway
> > to support disambiguation when two packages define a class of the same
> > name. It would be nice to get away from the exportClasses() and
> > importClasses() stuff. File that under the "rainy year" category.
> >
> > Michael
> >
> > On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
> >  wrote:
> > >
> > > Dear Bioc devel,
> > >
> > > Is it possible to import the BSgenome class without attaching
> BiocGenerics (to keep a clean namespace during the development of
> multicrispr).
> > >
> > > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> > >
> > > (Posted earlier on BioC support<
> https://support.bioconductor.org/p/124442/> and redirected here following
> Martin's suggestion)
> > >
> > > Thankyou :-)
> > >
> > > Aditya
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> >
> >
> > --
> > Michael Lawrence
> > Scientist, Bioinformatics and Computational Biology
> > Genentech, A Member of the Roche Group
> > Office +1 (650) 225-7760
> > micha...@gene.com
> >
> > Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube
>
>
>
> --
> Michael Lawrence
> Scientist, Bioinformatics and Computational Biology
> Genentech, A Member of the Roche Group
> Office +1 (650) 225-7760
> micha...@gene.com
>
> Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

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

Re: [Rd] Cryptic error message from namespaceExport

[Michael Lawrence via R-devel]

Just to clarify, your package is exporting a class that is not
defined? Or is it exporting a class that is defined by a dependency
and then masked by setOldClass()? A simple reproducible example would
help.

On Fri, Sep 6, 2019 at 7:48 AM Thierry Onkelinx via R-devel
 wrote:
>
> Dear all,
>
> Today I got this error message (R 3.6.1) when installing my package:
>
> Error: package or namespace load failed for ‘inlatools’ in
> namespaceExport(ns, exports):
>  undefined exports: .__C__inla
>
> My package was using setOldClass("inla") and exported the "inla" class via
> the NAMESPACE. It imports functions from the INLA package. Older versions
> of the INLA package did not export the "inla" class. Hence the use of
> setOldClass().
> The current version of the INLA package does export the "inla" class
> through it NAMESPACE. This triggered the error described above.
>
> Is the possible to improve this error message? The current message is
> misleading as neither packages contain the string ".__C__inla"
>
> Best regards,
>
> ir. Thierry Onkelinx
> Statisticus / Statistician
>
> Vlaamse Overheid / Government of Flanders
> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
> FOREST
> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> thierry.onkel...@inbo.be
> Havenlaan 88 bus 73, 1000 Brussel
> www.inbo.be
>
> ///
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of. ~ Sir Ronald Aylmer Fisher
> The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
> ///
>
> 
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

[Rd] Cryptic error message from namespaceExport

[Thierry Onkelinx via R-devel]

Dear all,

Today I got this error message (R 3.6.1) when installing my package:

Error: package or namespace load failed for ‘inlatools’ in
namespaceExport(ns, exports):
 undefined exports: .__C__inla

My package was using setOldClass("inla") and exported the "inla" class via
the NAMESPACE. It imports functions from the INLA package. Older versions
of the INLA package did not export the "inla" class. Hence the use of
setOldClass().
The current version of the INLA package does export the "inla" class
through it NAMESPACE. This triggered the error described above.

Is the possible to improve this error message? The current message is
misleading as neither packages contain the string ".__C__inla"

Best regards,

ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be

///
To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey
///



[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] set pkg_config for 3rd party software

[Dirk Eddelbuettel]

Martin,

On 6 September 2019 at 07:19, Dirk Eddelbuettel wrote:
| So can't you replace / update that package?  That's what I do over in the
| .deb world, and for Ubuntu it is particularly easy with PPAs.

And then there is of course this too:

  edd@rob:~$ pkg-config --modversion nlopt
  2.4.2
  edd@rob:~$ pkg-config --modversion quantlib
  1.16
  edd@rob:~$

so eg in QuantLib (which uses its own quantlib-config from going back to the
days before we had pkg-config) I test for minimally-viable versions, and only
if pkg-config reveals and insufficient version do I check explicit configure
options to supply a library dir and include dir.

Dirk

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

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

[Bioc-devel] List of Deprecated Packages Bioc 3.10

[Shepherd, Lori]

The Bioconductor Team is continuing to identify packages that will be 
deprecated in the next release to allow for the Bioconductor community to 
respond accordingly. The list will be updated monthly.
The current list of deprecated packages for Bioc 3.10 is as follows:

Maintainer requested deprecation:

Software:

SNPchip
GenomeGraphs
HTSanalyzeR
Rchemcpp
charm
Pbase


Experiment Data Package:

charmData



Unresponsive/not-maintained packages:

Software:

dSimer
flipflop
exomePeak
CNPBayes
brainImageR
plateCore
rHVDM
SEPA
condcomp
PathNet
scone
birte
mlm4omics


Experiment Data Package:

facopy.annot
allenpvc


The following Annotation Packages have been user requested deprecated:

MafDb.gnomADex.r2.0.1.GRCh38
MafDb.gnomAD.r2.0.1.GRCh38
MafDb.gnomADex.r2.0.1.hs37d5
MafDb.gnomAD.r2.0.1.hs37d5

They are replaced with

MafDb.gnomADex.r2.1.GRCh38
MafDb.gnomAD.r2.1.GRCh38
MafDb.gnomADex.r2.1.hs37d5
MafDb.gnomAD.r2.1.hs37d5


We will be sending emails out to packages that have been broken across all 
platforms for an extended period of time as those are packages that are up for 
immediate deprecation if not corrected in a timely fashion.

Thank you



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

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

[Michael Lawrence via Bioc-devel]

It sounds like you are trying to defer loading of namespaces in order
to save time when they are unnecessary? That's probably going to end
up a losing battle.

On Fri, Sep 6, 2019 at 5:47 AM Bhagwat, Aditya
 wrote:
>
> Thank you Michael,
>
> Appreciate your time for helping me fill the gaps in my understanding of the 
> S4 flow :-).
>
> It all started when I defined (in my multicrispr package) the S4 coercer :
> methods::setAs( "BSgenome",
>
> "GRanges",
> function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")
>
> When building, I noticed the message
> in method for 'coerce' with signature '"BSgenome","GRanges"': no definition 
> for class "BSgenome"
>
> So, I added
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> That loads all these dependencies.
> From your answer, I understand that there is currently no alternative to 
> loading all these dependencies.
> I guess because these dependencies are needed to provide for all required S4 
> methods for the BSgenome class, am I right?
>
> Is there a way to define a methods::setAs without loading the class 
> definition?
>
> Aditya
>
>
>
>
> 
> From: Michael Lawrence [lawrence.mich...@gene.com]
> Sent: Friday, September 06, 2019 1:09 PM
> To: Bhagwat, Aditya
> Cc: bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
> The way to keep a "clean namespace" is to selectively import symbols
> into your namespace, not to import _nothing_ into your namespace.
> Otherwise, your code will fill with namespace qualifications that
> distract from what is more important to communicate: the intent of the
> code. And no, there's no way to define method signatures using
> anything other than simple class names.
>
> It would be interesting to explore alternative ways of specifying
> method signatures. One way would be if every package exported a "class
> reference" (class name with package attribute, at least) for each of
> its classes. Those could be treated like any other exported object,
> and referenced via namespace qualification. It would require major
> changes to the methods package but that should probably happen anyway
> to support disambiguation when two packages define a class of the same
> name. It would be nice to get away from the exportClasses() and
> importClasses() stuff. File that under the "rainy year" category.
>
> Michael
>
> On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
>  wrote:
> >
> > Dear Bioc devel,
> >
> > Is it possible to import the BSgenome class without attaching BiocGenerics 
> > (to keep a clean namespace during the development of 
> > multicrispr).
> >
> > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> >
> > (Posted earlier on BioC support 
> > and redirected here following Martin's suggestion)
> >
> > Thankyou :-)
> >
> > Aditya
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>
> --
> Michael Lawrence
> Scientist, Bioinformatics and Computational Biology
> Genentech, A Member of the Roche Group
> Office +1 (650) 225-7760
> micha...@gene.com
>
> Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

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

[Bhagwat, Aditya]

I noticed the unfriendly indentation and formatting of my response , so I 
updated my original question on BioC support (with a much more eye-friendly 
formatting):

https://support.bioconductor.org/p/124442



From: Bhagwat, Aditya
Sent: Friday, September 06, 2019 2:47 PM
To: Michael Lawrence
Cc: bioc-devel@r-project.org
Subject: RE: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

Thank you Michael,

Appreciate your time for helping me fill the gaps in my understanding of the S4 
flow :-).

It all started when I defined (in my multicrispr package) the S4 coercer :
methods::setAs( "BSgenome",
"GRanges",
function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")

When building, I noticed the message
in method for 'coerce' with signature '"BSgenome","GRanges"': no definition for 
class "BSgenome"

So, I added
BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')

That loads all these dependencies.
>From your answer, I understand that there is currently no alternative to 
>loading all these dependencies.
I guess because these dependencies are needed to provide for all required S4 
methods for the BSgenome class, am I right?

Is there a way to define a methods::setAs without loading the class definition?

Aditya





From: Michael Lawrence [lawrence.mich...@gene.com]
Sent: Friday, September 06, 2019 1:09 PM
To: Bhagwat, Aditya
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

The way to keep a "clean namespace" is to selectively import symbols
into your namespace, not to import _nothing_ into your namespace.
Otherwise, your code will fill with namespace qualifications that
distract from what is more important to communicate: the intent of the
code. And no, there's no way to define method signatures using
anything other than simple class names.

It would be interesting to explore alternative ways of specifying
method signatures. One way would be if every package exported a "class
reference" (class name with package attribute, at least) for each of
its classes. Those could be treated like any other exported object,
and referenced via namespace qualification. It would require major
changes to the methods package but that should probably happen anyway
to support disambiguation when two packages define a class of the same
name. It would be nice to get away from the exportClasses() and
importClasses() stuff. File that under the "rainy year" category.

Michael

On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
 wrote:
>
> Dear Bioc devel,
>
> Is it possible to import the BSgenome class without attaching BiocGenerics 
> (to keep a clean namespace during the development of 
> multicrispr).
>
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> (Posted earlier on BioC support 
> and redirected here following Martin's suggestion)
>
> Thankyou :-)
>
> Aditya
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

[[alternative HTML version deleted]]

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

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

[Bhagwat, Aditya]

Thank you Michael,

Appreciate your time for helping me fill the gaps in my understanding of the S4 
flow :-).

It all started when I defined (in my multicrispr package) the S4 coercer :
methods::setAs( "BSgenome",
"GRanges",
function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")

When building, I noticed the message
in method for 'coerce' with signature '"BSgenome","GRanges"': no definition for 
class "BSgenome"

So, I added
BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')

That loads all these dependencies.
>From your answer, I understand that there is currently no alternative to 
>loading all these dependencies.
I guess because these dependencies are needed to provide for all required S4 
methods for the BSgenome class, am I right?

Is there a way to define a methods::setAs without loading the class definition?

Aditya





From: Michael Lawrence [lawrence.mich...@gene.com]
Sent: Friday, September 06, 2019 1:09 PM
To: Bhagwat, Aditya
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

The way to keep a "clean namespace" is to selectively import symbols
into your namespace, not to import _nothing_ into your namespace.
Otherwise, your code will fill with namespace qualifications that
distract from what is more important to communicate: the intent of the
code. And no, there's no way to define method signatures using
anything other than simple class names.

It would be interesting to explore alternative ways of specifying
method signatures. One way would be if every package exported a "class
reference" (class name with package attribute, at least) for each of
its classes. Those could be treated like any other exported object,
and referenced via namespace qualification. It would require major
changes to the methods package but that should probably happen anyway
to support disambiguation when two packages define a class of the same
name. It would be nice to get away from the exportClasses() and
importClasses() stuff. File that under the "rainy year" category.

Michael

On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
 wrote:
>
> Dear Bioc devel,
>
> Is it possible to import the BSgenome class without attaching BiocGenerics 
> (to keep a clean namespace during the development of 
> multicrispr).
>
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> (Posted earlier on BioC support 
> and redirected here following Martin's suggestion)
>
> Thankyou :-)
>
> Aditya
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] set pkg_config for 3rd party software

[Dirk Eddelbuettel]

Martin,

And not to beat a dead horse, but isn't the root cause the outdated rpm?

So can't you replace / update that package?  That's what I do over in the
.deb world, and for Ubuntu it is particularly easy with PPAs.

Dirk

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

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

Re: [Rd] [EXTERNAL] RE: install_github and survival

[Iñaki Ucar]

On Fri, 6 Sep 2019 at 14:08, Therneau, Terry M., Ph.D. via R-devel
 wrote:
>
> Yes, that is exactly the problem.  The code found in the "config" script is 
> never run.
> But why doesn't it get run?

It should be called "configure", not "config".

Iñaki

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

Re: [Rd] [EXTERNAL] RE: install_github and survival

[Therneau, Terry M., Ph.D. via R-devel]

Yes, that is exactly the problem.  The code found in the "config" script is 
never run.  
But why doesn't it get run?

On 9/6/19 5:44 AM, Georgi Boshnakov wrote:
> I cloned therneau/survival and the installation failed since there is no 
> definition for exported function survfit().
> A file seems to be missing - there is survfit0() and survfit0.R but, compared 
> to CRAN, no survfit.R.
>
> Georgi Boshnakov
>
>
> --
>
> Message: 1
> Date: Thu, 05 Sep 2019 12:53:11 -0500
> From: "Therneau, Terry M., Ph.D." 
> To: "r-devel@r-project.org" 
> Subject: [Rd] install_github and survival
> Message-ID: <771925$cbi...@ironport10.mayo.edu>
> Content-Type: text/plain; charset="utf-8"
>
> I treat CRAN as the main repository for survival, but I have also had a github
> (therneau/survival) version for a couple of years.  It has a vignette2 
> directory, for
> instance, that contains extra vignettes that either take too long to run or 
> depend on
> other packages.  It also gets updated more often than CRAN (though those 
> updates mght not
> be as well tested yet).
>
> In any case, since it is there, people will of course run install_github 
> against it.
> I've added a config script to do the one extra step necessary, but when I try
> install_github it fails.   I'm clearly doing something wrong.  If someone 
> were willing to
> contribute a fix I would be most grateful.
>
> survival3.1-0 is almost ready for CRAN, by the way.   Reverse dependency 
> checks of hdnom
> turned up one last thing to repair...
>
>
> Terry Therneau
>
>
>   [[alternative HTML version deleted]]
>
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> R-devel@r-project.org mailing list  DIGESTED
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> --
>
> End of R-devel Digest, Vol 199, Issue 6
> ***


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Single character in Fortran function and FCONE and FCLEN macros

[Benjamin Christoffersen]

> I'd try following WRE on this exactly: include R_ext/BLAS.h and only after 
> that define FCONE (if not defined) - and FCLEN if you need it as well.
That is an embarrassing error. I will try to do exactly as is written in WRE.

> I'd try debugging this with gcc -E, checking whether the FCLEN and FCONE 
> macros work as intended. If the build process of the package seemed too 
> complicated for that, you could also look at the disassembly for the calls, 
> or compile with -fdump-tree-all  and look at the gfortran/gcc diagnostic 
> files to see if the calls include the hidden 1s.
Thanks mentioning these options.

Best regards,
Benjamin


Den tir. 3. sep. 2019 kl. 15.37 skrev Tomas Kalibera :
>
> On 9/3/19 3:07 PM, Benjamin Christoffersen wrote:
>
> Dear Sirs,
>
> I have tried to update my 'dynamichazard' package on CRAN but I have
> had some issues with the '-Wlto-type-mismatch' checks. In particular,
> I have tried to follow "Writing R Extensions" section "Fortran
> character strings" and defined a C++ header file
> (https://github.com/boennecd/dynamichazard/blob/460fe74cadad5c029c4f0ffb50074139135c2166/src/Rconfig-wrap.h)
> with the following content
>
> #ifndef RCONFIG_WRAP_H
> #define RCONFIG_WRAP_H
> #define USE_FC_LEN_T
> #include 
>
> #ifndef FCLEN
> #define FCLEN
> #endif
> #ifndef FCONE
> #define FCONE
> #endif
>
> #endif
>
> I'd try following WRE on this exactly: include R_ext/BLAS.h and only after 
> that define FCONE (if not defined) - and FCLEN if you need it as well.
>
> which I include before including 'R_ext/BLAS.h' and 'R_ext/Lapack.h'
> files. I then make the following C declaration of the Fortran
> subroutine that causes the issue
> (https://github.com/boennecd/dynamichazard/blob/460fe74cadad5c029c4f0ffb50074139135c2166/src/BLAS_LAPACK/R_BLAS_LAPACK.cpp#L2-L29)
>
> extern "C"
>   {
> void F77_NAME(dchur)(
> const char*,   // UPLO
> const char*,   // TRANS
> int*,// N
> int*,// M
> double*, // R
> int*,// LDR
> double*, // X
> double*, // Z
> int*,// LDZ
> double*, // Y
> double*, // RHO
> double*, // C
> double*, // S
> int* // INFO,
> FCLEN FCLEN
> );
>   }
>
> Lastly, I use the 'FCONE' macro when calling the function. The Fortran
> subroutine (a LINPACK subroutine) is defined in this file:
> https://github.com/boennecd/dynamichazard/blob/460fe74cadad5c029c4f0ffb50074139135c2166/src/BLAS_LAPACK/dchur.f#L7
>
> I gather the above is as done in the BLAS and LAPACK header in R. Yet,
> I still got a mail in the CRAN submission stating that
>
> We see
>
> * checking whether package ‘dynamichazard’ can be installed ...
> [207s/211s] WARNING
> Found the following significant warnings:
>BLAS_LAPACK/R_BLAS_LAPACK.cpp:12:10: warning: type of ‘dchur_’ does
> not match original declaration [-Wlto-type-mismatch]
>
> and there's also
>
> BLAS_LAPACK/R_BLAS_LAPACK.cpp:12:10: warning: type of ‘dchur_’ does not
> match original declaration [-Wlto-type-mismatch]
> 12 | void F77_NAME(dchur)(
>|  ^
> BLAS_LAPACK/dchur.f:7:1: note: type mismatch in parameter 15
>  7 |   SUBROUTINE DCHUR(UPLO,TRANS,N,M,R,LDR,X,Z,LDZ,Y,RHO,C,S,INFO)
>| ^
> BLAS_LAPACK/dchur.f:7:1: note: type ‘long int’ should match type ‘void’
> BLAS_LAPACK/dchur.f:7:1: note: ‘dchur’ was previously declared here
>
> I am not sure how to handle the issue. I am sorry if I am doing
> something which is obviously wrong.
>
> I'd try debugging this with gcc -E, checking whether the FCLEN and FCONE 
> macros work as intended. If the build process of the package seemed too 
> complicated for that, you could also look at the disassembly for the calls, 
> or compile with -fdump-tree-all  and look at the gfortran/gcc diagnostic 
> files to see if the calls include the hidden 1s. The output seems to suggest 
> that the macros have not been defined properly.
>
> I also got some messages about the declarations in RcppArmadillo but I
> gather these are upstream issues which I cannot do anything about
>
> /home/Hornik/tmp/R-d-gcc-LTO/include/R_ext/Lapack.h:1584:1: warning: 
> ‘dtrtri_’ violates the C++ One Definition Rule [-Wodr]
>  1584 | F77_NAME(dtrtri)(const char* uplo, const char* diag,
>   | ^
> /home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:421:8:
>  note: type mismatch in parameter 7
>   421 |   void arma_fortran(arma_dtrtri)(const char* uplo, const char* diag, 
> const blas_int* n, double* a, const blas_int* lda, blas_int* info, blas_len 
> uplo_len, blas_len diag_len);
>   |^
> /home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:421:8:
>  note: type ‘blas_len’ should match type ‘void’
> /home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:421:8:
>  note: ‘dtrtri_’ was previously declared here
> 

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

[Michael Lawrence via Bioc-devel]

The way to keep a "clean namespace" is to selectively import symbols
into your namespace, not to import _nothing_ into your namespace.
Otherwise, your code will fill with namespace qualifications that
distract from what is more important to communicate: the intent of the
code. And no, there's no way to define method signatures using
anything other than simple class names.

It would be interesting to explore alternative ways of specifying
method signatures. One way would be if every package exported a "class
reference" (class name with package attribute, at least)  for each of
its classes. Those could be treated like any other exported object,
and referenced via namespace qualification. It would require major
changes to the methods package but that should probably happen anyway
to support disambiguation when two packages define a class of the same
name. It would be nice to get away from the exportClasses() and
importClasses() stuff. File that under the "rainy year" category.

Michael

On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
 wrote:
>
> Dear Bioc devel,
>
> Is it possible to import the BSgenome class without attaching BiocGenerics 
> (to keep a clean namespace during the development of 
> multicrispr).
>
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> (Posted earlier on BioC support 
> and redirected here following Martin's suggestion)
>
> Thankyou :-)
>
> Aditya
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] install_github and survival

[Georgi Boshnakov]

I cloned therneau/survival and the installation failed since there is no 
definition for exported function survfit().
A file seems to be missing - there is survfit0() and survfit0.R but, compared 
to CRAN, no survfit.R.

Georgi Boshnakov


--

Message: 1
Date: Thu, 05 Sep 2019 12:53:11 -0500
From: "Therneau, Terry M., Ph.D." 
To: "r-devel@r-project.org" 
Subject: [Rd] install_github and survival
Message-ID: <771925$cbi...@ironport10.mayo.edu>
Content-Type: text/plain; charset="utf-8"

I treat CRAN as the main repository for survival, but I have also had a github 
(therneau/survival) version for a couple of years.  It has a vignette2 
directory, for 
instance, that contains extra vignettes that either take too long to run or 
depend on 
other packages.  It also gets updated more often than CRAN (though those 
updates mght not 
be as well tested yet).

In any case, since it is there, people will of course run install_github 
against it.   
I've added a config script to do the one extra step necessary, but when I try 
install_github it fails.   I'm clearly doing something wrong.  If someone were 
willing to 
contribute a fix I would be most grateful.

survival3.1-0 is almost ready for CRAN, by the way.   Reverse dependency checks 
of hdnom 
turned up one last thing to repair...


Terry Therneau


[[alternative HTML version deleted]]




--

Subject: Digest Footer

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


--

End of R-devel Digest, Vol 199, Issue 6
***
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Bhagwat, Aditya]

Dear Bioc devel,

Is it possible to import the BSgenome class without attaching BiocGenerics (to 
keep a clean namespace during the development of 
multicrispr).

BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')

(Posted earlier on BioC support and 
redirected here following Martin's suggestion)

Thankyou :-)

Aditya

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] set pkg_config for 3rd party software

[Martin Maechler]

> Ralf Stubner 
> on Fri, 6 Sep 2019 11:22:15 +0200 writes:

> On Thu, Sep 5, 2019 at 6:36 PM Martin Maechler
>  wrote:
>> For me (on Fedora 30)
>> 
>> $ R CMD config LDFLAGS
>> -L/usr/lib64

> This looks wrong. I would expect that /usr/lib64 is one of the
> standard directories that are searched anyway. So why put it into the
> very beginning of the search? BTW, this does not happen on Debian:

> $ R CMD config LDFLAGS
> -Wl,-z,relro

Thank you very much, Ralf!
Indeed my conclusion was wrong .. If I use Fedora's own R package,
then I also get something like the above :

 $ /usr/bin/R CMD config LDFLAGS
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld

(amazingly long ..)

It's just when I -- as in 99.9% of cases, as an R Core developer --
use my own built version of R, I get what you call "wrong".

... and it's  "of course" from my  ~/.R/config  settings
where added a comment for this explicit LDFLAGS setting, mentioning that
otherwise it would take -L/usr/local/lib64 and that *is*
unfortunately still true:

In current R incl R-devel's  /configure.ac  (lines 157-167)
LDFLAGS *is* set to this :

: ${LIBnn=$libnn}
## We provide these defaults so that headers and libraries in
## '/usr/local' are found (by the native tools, mostly).
if test -f "/sw/etc/fink.conf"; then
  : ${CPPFLAGS="-I/sw/include -I/usr/local/include"}
  : ${LDFLAGS="-L/sw/lib -L/usr/local/lib"}
else
  : ${CPPFLAGS="-I/usr/local/include"}
  : ${LDFLAGS="-L/usr/local/${LIBnn}"}
fi
AC_SUBST(LIBnn)


and that setting *did* harm me in the (relatively distant, ~ 7 years?)
past, and so I had replaced it with the  /usr/lib64  setting.

Hmm, maybe this should all have been on the  R-devel  mailing
list instead, and we should start asking if R's  configure.ac
(and hence configure) should be changed ?

Martin

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

Re: [R-pkg-devel] set pkg_config for 3rd party software

[Ralf Stubner]

On Thu, Sep 5, 2019 at 6:36 PM Martin Maechler
 wrote:
> For me (on Fedora 30)
>
>   $ R CMD config LDFLAGS
>   -L/usr/lib64

This looks wrong. I would expect that /usr/lib64 is one of the
standard directories that are searched anyway. So why put it into the
very beginning of the search? BTW, this does not happen on Debian:

$ R CMD config LDFLAGS
-Wl,-z,relro

> Yes, on a machine with root permission I can hack around to get
> what I want,  but of course I'd really like   'R CMD INSTALL ..'
> to do the "right thing"
> just from my  configure  plus src/Makevars{.in}  files.
> Yes, I tried  'LDFLAGS = ' (to set it to "empty") in
> src/Makevars*  but that did not help either.

I see no way to correct this within a package. The only thing that
comes to mind is adding a test in `configure{.ac}` that will fail when
a to old version of libmpfr is actually used for linking. If the test
fails, one can at least give an informative message. Then either an
admin corrects the configuration or the user overwrites LDFLAS in
~/.R/Makevars.

cheerio
ralf

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

Re: [R-pkg-devel] set pkg_config for 3rd party software

[Martin Maechler]

> Martin Maechler 
> on Thu, 5 Sep 2019 18:36:03 +0200 writes:

> Dirk Eddelbuettel 
> on Thu, 5 Sep 2019 10:14:21 -0500 writes:

>> On 5 September 2019 at 16:53, Ralf Stubner wrote:
>> | I don't know what is best, but here are three alternatives:
>> | 
>> | * Use PKG_CHECK_MODULES which sets up default variables with _CFLAGS
>> | and _LIBS suffix after searching for a library with pkg-config, c.f.
>> | https://autotools.io/pkgconfig/pkg_check_modules.html
>> | * Call pkg-config by hand in configure.ac (and hence configure).
>> | Example: 
https://github.com/eddelbuettel/rcppredis/blob/master/configure.ac#L47-L60
>> | * Call pkg-config within an "Anticonf" configure script. Example:
>> | https://github.com/jeroen/curl/blob/master/configure#L16-L24

>> Make it four alternatives:

>> * Call pkg-config from an autoconf configure script.  Examples:

>> edd@rob:~$ grep -l pkg-config git/*/configure.{ac,in}
>> git/libxls/configure.ac
>> git/nloptr/configure.ac
>> git/rcppmlpack2/configure.ac
>> git/rcppredis/configure.ac
>> git/rprotobuf/configure.ac
>> edd@rob:~$

>> I know all the cool kids these days hate autoconf, but it a) really is 
just
>> careful (and more portable) shell scripting (plus some extra glue).  And 
it
>> b) avoids having users on some marginal OSs yell at you when they do not 
have
>> bash (just yesterday a Nix user had to comment on a five year old bug in 
that
>> is no longer valid as we went back to autoconf there too).  As an extra 
bonus
>> it c) also works on Slowlaris.

>> Best, Dirk

> Thank you, Ralf, and Dirk that was very useful already !

> However, the real problem I am fighting still is not related to
> `pkg-config` and friends at all, but to the fact that my OS has
> a version of libmpfr in the main system library and that seems
> to be used in *any* case when the final .so file is linked
> together:

> For me (on Fedora 30)

> $ R CMD config LDFLAGS
> -L/usr/lib64

> $ ls -l /usr/lib64/libmpfr*
> lrwxrwxrwx. 1 root root 16 Feb  2  2019 /usr/lib64/libmpfr.so -> 
libmpfr.so.4.1.6
> lrwxrwxrwx. 1 root root 16 Feb  2  2019 /usr/lib64/libmpfr.so.4 -> 
libmpfr.so.4.1.6
> -rwxr-xr-x. 1 root root 827872 Feb  2  2019 /usr/lib64/libmpfr.so.4.1.6

> and for that reason, when R CMD INSTALL Rmpfr ...

> gets to the final linking, it uses

> gcc -shared -L/usr/lib64 -o Rmpfr.so Ops.o  utils.o 
-L/usr/local.../mpfr/4.0.2/lib -lmpfr -lgmp

> and the early -L/usr/lib64  just "ensures" that my package lib
> (Rmpfr.so) is linked against  /usr/lib64/libmpfr.so.4.1.6  which
> is old and I "hate" rather than against the much better
> libmpfr.so.6.0.2 which would be found in /usr/local.../mpfr/4.0.2/lib

> Yes, on a machine with root permission I can hack around to get
> what I want,  but of course I'd really like   'R CMD INSTALL ..'
> to do the "right thing"
> just from my  configure  plus src/Makevars{.in}  files.
> Yes, I tried  'LDFLAGS = ' (to set it to "empty") in
> src/Makevars*  but that did not help either.

> Martin

I now finally did what most of us should do before posting here:
Carefully consulting the famous WRE "Writing R Extensions" R
Manual, notably the section ('1.2.1' currently),
named "Using Makevars" :
   https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Makevars

and came to the conclusion that at least for now,
I have to revert to using a 'src/Makefile' instead of just
Makevars files, the main reason being that  R's own
/etc/Makevars  file is included *after* the package src/Makevars
file  and so it does not help if I (un)set LDFLAGS in the latter.

Thank you for listening - it helped me to get to a more systematic
answer (and if you find that my conclusion has been wrong, I'm
happy to hear about that).

Martin

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