Re: [Bioc-devel] Rhtslib on arm64

[Martin Grigorov]

Hi Ulrich,

The issue with the LOCK files and folders have been addressed with
https://github.com/Bioconductor/BBS/pull/291
https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/Rhtslib/kjohnson2-install.html
says "This page was generated on 2023-06-02 11:02:20". I guess the issue
will be gone with the next report.

In addition I could say that Rhtslib builds fine on Linux ARM64 -
https://bio-arm.github.io/latest/report/Rhtslib/

Regards,
Martin



On Wed, Jun 7, 2023 at 12:29 PM  wrote:

> Dear Hervé, dear Rhtslib developers, dear BioC core team,
>
> I am regularly checking all BioC check results in order to make sure that I
> do not miss any issues of the four Bioconductor packages that I am
> maintaining. It seems that the ‘podkat’ package in BioC 3.17 release has
> not
> been built for arm64 yet. On the results page
> https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/,
> ‘podkat’
> has been “red” for weeks now. It seems to me that the reason for this is
> that ‘Rhtslib’ does not build either. I have now looked at the results page
> of ‘Rhtslib’
> (https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/Rhtslib/
> )
> and it seems that it is a simple issue with a lock file on the build
> server,
> but not a major problem why the package is not built (who knows, but I
> suppose so). I am therefore asking if anybody is able to resolve that issue
> such that the ‘Rhtslib’ package builds for arm64 and , as a consequence,
> hopefully, my ‘podkat’ package too.
>
> Thanks a lot in advance and best regards,
> Ulrich
>
> ___
> 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] Rhtslib on arm64

[bodenhofer]

Great, Martin, thanks!

Best regards, Ulrich


From: Martin Grigorov  
Sent: Wednesday, June 7, 2023 12:04 PM
To: bodenho...@bioinf.jku.at
Cc: bioc-devel@r-project.org; Hervé Pagès 
Subject: Re: [Bioc-devel] Rhtslib on arm64

Hi Ulrich,

The issue with the LOCK files and folders have been addressed with 
https://github.com/Bioconductor/BBS/pull/291
https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/Rhtslib/kjohnson2-install.html
 says "This page was generated on 2023-06-02 11:02:20". I guess the issue will 
be gone with the next report.

In addition I could say that Rhtslib builds fine on Linux ARM64 - 
https://bio-arm.github.io/latest/report/Rhtslib/

Regards,
Martin



On Wed, Jun 7, 2023 at 12:29 PM  wrote:
Dear Hervé, dear Rhtslib developers, dear BioC core team,

I am regularly checking all BioC check results in order to make sure that I
do not miss any issues of the four Bioconductor packages that I am
maintaining. It seems that the ‘podkat’ package in BioC 3.17 release has not
been built for arm64 yet. On the results page
https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/, ‘podkat’
has been “red” for weeks now. It seems to me that the reason for this is
that ‘Rhtslib’ does not build either. I have now looked at the results page
of ‘Rhtslib’
(https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/Rhtslib/)
and it seems that it is a simple issue with a lock file on the build server,
but not a major problem why the package is not built (who knows, but I
suppose so). I am therefore asking if anybody is able to resolve that issue
such that the ‘Rhtslib’ package builds for arm64 and , as a consequence,
hopefully, my ‘podkat’ package too.

Thanks a lot in advance and best regards,
Ulrich

___
mailto: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] Rhtslib on arm64

[bodenhofer]

Dear Hervé, dear Rhtslib developers, dear BioC core team,

I am regularly checking all BioC check results in order to make sure that I
do not miss any issues of the four Bioconductor packages that I am
maintaining. It seems that the ‘podkat’ package in BioC 3.17 release has not
been built for arm64 yet. On the results page
https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/, ‘podkat’
has been “red” for weeks now. It seems to me that the reason for this is
that ‘Rhtslib’ does not build either. I have now looked at the results page
of ‘Rhtslib’
(https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/Rhtslib/)
and it seems that it is a simple issue with a lock file on the build server,
but not a major problem why the package is not built (who knows, but I
suppose so). I am therefore asking if anybody is able to resolve that issue
such that the ‘Rhtslib’ package builds for arm64 and , as a consequence,
hopefully, my ‘podkat’ package too.

Thanks a lot in advance and best regards,
Ulrich

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

Re: [Rd] codetools wrongly complains about lazy evaluation in S4 methods

[Gabriel Becker]

The API supported workaround is to call globalVariables, which,
essentially, declares the variables without defining them (a distinction R
does not usually make).

The issue with this approach, of course, is that its a very blunt
instrument. It will cause false negatives if you accidentally use the same
symbol in a standard evaluation context elsewhere in your code.
Nonetheless, that's the intended approach as far as i know.

Best,
~G



On Wed, Jun 7, 2023 at 1:07 AM Serguei Sokol via R-devel <
r-devel@r-project.org> wrote:

> Le 03/06/2023 à 17:50, Mikael Jagan a écrit :
> > In a package, I define a method for not-yet-generic function 'qr.X'
> > like so:
> >
> > > setOldClass("qr")
> > > setMethod("qr.X", signature(qr = "qr"), function(qr, complete,
> > ncol) NULL)
> >
> > The formals of the newly generic 'qr.X' are inherited from the
> > non-generic
> > function in the base namespace.  Notably, the inherited default value of
> > formal argument 'ncol' relies on lazy evaluation:
> >
> > > formals(qr.X)[["ncol"]]
> > if (complete) nrow(R) else min(dim(R))
> >
> > where 'R' must be defined in the body of any method that might
> > evaluate 'ncol'.
> > To my surprise, tools:::.check_code_usage_in_package() complains about
> > the
> > undefined symbol:
> >
> > qr.X: no visible binding for global variable 'R'
> > qr.X,qr: no visible binding for global variable 'R'
> > Undefined global functions or variables:
> >   R
> I think this issue is similar to the complaints about non defined
> variables in expressions involving non standard evaluation, e.g. column
> names in a data frame which are used as unquoted symbols. One of
> workarounds is simply to declare them somewhere in your code. In your
> case, it could be something as simple as:
>
>R=NULL
>
> Best,
> Serguei.
>
> >
> > I claim that it should _not_ complain, given that lazy evaluation is a
> > really
> > a feature of the language _and_ given that it already does not
> > complain about
> > the formals of functions that are not S4 methods.
> >
> > Having said that, it is not obvious to me what in codetools would need
> > to change
> > here.  Any ideas?
> >
> > I've attached a script that creates and installs a test package and
> > reproduces
> > the check output by calling tools:::.check_code_usage_in_package().
> > Hope it
> > gets through.
> >
> > Mikael
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] codetools wrongly complains about lazy evaluation in S4 methods

[Serguei Sokol via R-devel]

Le 03/06/2023 à 17:50, Mikael Jagan a écrit :
In a package, I define a method for not-yet-generic function 'qr.X' 
like so:


    > setOldClass("qr")
    > setMethod("qr.X", signature(qr = "qr"), function(qr, complete, 
ncol) NULL)


The formals of the newly generic 'qr.X' are inherited from the 
non-generic

function in the base namespace.  Notably, the inherited default value of
formal argument 'ncol' relies on lazy evaluation:

    > formals(qr.X)[["ncol"]]
    if (complete) nrow(R) else min(dim(R))

where 'R' must be defined in the body of any method that might 
evaluate 'ncol'.
To my surprise, tools:::.check_code_usage_in_package() complains about 
the

undefined symbol:

    qr.X: no visible binding for global variable 'R'
    qr.X,qr: no visible binding for global variable 'R'
    Undefined global functions or variables:
  R
I think this issue is similar to the complaints about non defined 
variables in expressions involving non standard evaluation, e.g. column 
names in a data frame which are used as unquoted symbols. One of 
workarounds is simply to declare them somewhere in your code. In your 
case, it could be something as simple as:


  R=NULL

Best,
Serguei.



I claim that it should _not_ complain, given that lazy evaluation is a 
really
a feature of the language _and_ given that it already does not 
complain about

the formals of functions that are not S4 methods.

Having said that, it is not obvious to me what in codetools would need 
to change

here.  Any ideas?

I've attached a script that creates and installs a test package and 
reproduces
the check output by calling tools:::.check_code_usage_in_package().  
Hope it

gets through.

Mikael

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


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