Re: [Bioc-devel] EXTERNAL: [BULK] genefu Warning

[Marcel Ramos]

Hi Christopher,

It would be a good idea to remove the `LazyData: yes` from the DESCRIPTION.

https://bioconductor.org/developers/package-guidelines/#description 


One that is set make sure there is no pollution in function environments 
e.g., `sbt.model=scmod1.robust`
in `R/genius.R`. Create an empty data environment where you can load 
package data for the
function to use with `new.env(parent = emptyenv())`.


Best,

Marcel

On 5/18/21 6:21 PM, Eeles, Christopher wrote:
> Hello Bioc Core Team,
>
> I just noticed that one of our lab package, genefu, has a WARNING on devel 
> for all build machines.
>
> The warning is:
>
> LazyData DB of 5.0 MB without LazyDataCompression set
>See �1.1.6 of 'Writing R Extensions'
>
> I wanted to make sure that this will not affect the inclusion of genefu in 
> the 3.13 release.
>
> I have already started researching the issue and will push a fix as soon as 
> the release is complete on Thursday.
>
> ---
> Christopher Eeles
> Software Developer
> BHK 
> Laboratory
> Princess Margaret Cancer 
> Centre
> University Health 
> Network
>
>
>
>
> 
> Any review or distribution by anyone other than the person for whom it was 
> originally intended is strictly prohibited.
> If you have received this e-mail in error, please contact the sender and 
> delete all copies.
> Opinions, conclusions or other information contained in this e-mail may not 
> be that of the organization.
>
> If you feel you have received an email from UHN of a commercial nature and 
> would like to be removed from the sender's mailing list please do one of the 
> following:
> (1) Follow any unsubscribe process the sender has included in their email
> (2) Where no unsubscribe process has been included, reply to the sender and 
> type "unsubscribe" in the subject line. If you require additional information 
> please go to our UHN Newsletters and Mailing Lists page.
> Please note that we are unable to automatically unsubscribe individuals from 
> all UHN mailing lists.
>
>
> Patient Consent for Email:
>
> UHN patients may provide their consent to communicate with UHN about their 
> care using email. All electronic communication carries some risk. Please 
> visit our website 
> here
>  to learn about the risks of electronic communication and how to protect your 
> privacy. You may withdraw your consent to receive emails from UHN at any 
> time. Please contact your care provider, if you do not wish to receive emails 
> from UHN.
>
>   [[alternative HTML version deleted]]
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> Unsubscribe
>
> It appears that you have subscribed to commercial messages from this 
> sender. To stop receiving such messages from this sender, please 
> unsubscribe 
> 
>
---
Marcel Ramos
Bioconductor Core Team
Roswell Park Comprehensive Cancer Center
Dept. of Biostatistics & Bioinformatics
Elm St. & Carlton St.
Buffalo, New York 14263



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

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

[Bioc-devel] genefu Warning

[Eeles, Christopher]

Hello Bioc Core Team,

I just noticed that one of our lab package, genefu, has a WARNING on devel for 
all build machines.

The warning is:

LazyData DB of 5.0 MB without LazyDataCompression set
  See �1.1.6 of 'Writing R Extensions'

I wanted to make sure that this will not affect the inclusion of genefu in the 
3.13 release.

I have already started researching the issue and will push a fix as soon as the 
release is complete on Thursday.

---
Christopher Eeles
Software Developer
BHK 
Laboratory
Princess Margaret Cancer 
Centre
University Health 
Network




This e-mail may contain confidential and/or privileged information for the sole 
use of the intended recipient.
Any review or distribution by anyone other than the person for whom it was 
originally intended is strictly prohibited.
If you have received this e-mail in error, please contact the sender and delete 
all copies.
Opinions, conclusions or other information contained in this e-mail may not be 
that of the organization.

If you feel you have received an email from UHN of a commercial nature and 
would like to be removed from the sender's mailing list please do one of the 
following:
(1) Follow any unsubscribe process the sender has included in their email
(2) Where no unsubscribe process has been included, reply to the sender and 
type "unsubscribe" in the subject line. If you require additional information 
please go to our UHN Newsletters and Mailing Lists page.
Please note that we are unable to automatically unsubscribe individuals from 
all UHN mailing lists.


Patient Consent for Email:

UHN patients may provide their consent to communicate with UHN about their care 
using email. All electronic communication carries some risk. Please visit our 
website 
here
 to learn about the risks of electronic communication and how to protect your 
privacy. You may withdraw your consent to receive emails from UHN at any time. 
Please contact your care provider, if you do not wish to receive emails from 
UHN.

[[alternative HTML version deleted]]

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

Re: [Rd] Add to Documentation of atan2.

[Stefan Evert]

> On 18 May 2021, at 20:30, Ben Bolker  wrote:
> 
>  On my system (Ubuntu), 'man 3 catan' gives documentation on the function, 
> and says "The real part of y is chosen in the interval [-pi/2,pi/2]" - but 
> that _could_ be system-dependent.

My copy of "C in a Nutshell" suggests that this requirement is part of the C99 
standard (specified for catanh).

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

Re: [R-pkg-devel] Old version of rtracklayer on a single check server

[Martin Morgan]

It is wrong to say that ‘it will never be solved for R.4.0.0’. Rather, ‘it will 
never be a problem for R.4.0.0’.

rtracklayer 1.51.5 was only ever built, checked, distributed (and installed in 
a correctly configured system, using the rules of install.packages and 
tools:::.BioC_version_associated_with_R_version(), or of 
BiocManager::install()) on R-devel (now R-4-1-0-branch). So R-4.0.* has never 
supported version 1.51.5 of rtracklayer.

No Bioconductor package built on R-4.0.* would propagate (be visible to 
install.packages()) with a dependency on rtracklayer-1.51.5. A CRAN package 
with a dependency on rtracklayer-1.51.5 (this is hypothetical, I do not believe 
it is the case for CNVScope), would be correctly flagged as an error – this 
version of rtracklayer will never be available on R-4.0.*, and the CRAN package 
author would have to re-assess the reasons for specifying the dependency for 
that version of R.

Bioconductor does rarely produce ‘impossible’ dependencies particularly in the 
Bioconductor ‘devel’ branch (when a package builds and checks even though one 
of its dependencies builds but does not pass check), but these are transient 
and an artifact of the Bioconductor  build system – the lagging package Is 
usually promptly updated so the published dependency is satisfied.


From: Henrik Bengtsson 
Date: Tuesday, May 18, 2021 at 2:41 PM
To: Martin Morgan 
Cc: "Dalgleish, James (NIH/NCI) [F]" , 
"r-package-devel@r-project.org" 
Subject: Re: [R-pkg-devel] Old version of rtracklayer on a single check server

I stand corrected about the R-devel version (and now R 4.1.0) on CRAN.

However, isn't it the case that it will never be solved for R 4.0.0 (to become 
R-oldrel on CRAN) and CRAN will keep reporting an error on MS Windows there 
because https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html 
provides only an older version for MS Windows?

If so, an alternative to relying on Suggests is to make the package depend on R 
(>= 4.1.0).

/Henrik

On Tue, May 18, 2021, 09:08 Martin Morgan 
mailto:mtmorgan.b...@gmail.com>> wrote:
That’s not correct Henrik.

CRAN follows CRAN rules for installing packages, so uses 
tools:::BioC_version_for_R_version(). For R-devel we have

> R.version.string
[1] "R Under development (unstable) (2021-05-18 r80323)"
> tools:::.BioC_version_associated_with_R_version()
[1] '3.13'

For this version of Bioconductor, the rtracklayer version (from 
https://bioconductor.org/packages/3.13/rtracklayer, or 
`available.packages(repos = 
"https://bioconductor.org/packages/3.13/bioc;)["rtracklayer", "Version"]`) is 
1.51.5.

So the r-devel-windows-ix86+x86_64 builder mentioned in the post has the wrong 
version of rtracklayer for R-devel.

Martin Morgan

On 5/18/21, 11:49 AM, "R-package-devel on behalf of Henrik Bengtsson" 
mailto:r-package-devel-boun...@r-project.org>
 on behalf of henrik.bengts...@gmail.com> 
wrote:

It's a problem with Bioconductor and a broken release history of
'rtracklayer' on MS Windows (e.g.
https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html)
plus how each Bioconductor version is tied to a specific R version.
In other words, even if they fix it in Bioconductor 3.13 (for R
4.1.0), it can't be fixed in Bioconductor 3.12 (for R 4.0.0), so
you're package will keep failing on Windows for R 4.0.0.  The reason
why it can't be fixed in Bioconductor 3.12 is that they have now
frozen that release forever.

Because of this, I suspect the only solution is to make 'rtracklayer'
an optional package, i.e. move it to Suggests: and update all your
code to run conditionally of that package being available. I recommend
you reach out to the bioc-devel mailing list for advice.

/Henrik

On Tue, May 18, 2021 at 4:33 AM Dalgleish, James (NIH/NCI) [F] via
R-package-devel 
mailto:r-package-devel@r-project.org>> wrote:
>
> To any who might have an idea:
>
> I've been reading several posts in the digest about dependency version 
issues on the check servers and I'm having my own issue, which I can't solve 
because I can't upgrade the check server's package version:
> * installing *source* package 'CNVScope' ...
> ** using staged installation
> ** R
> ** data
> *** moving datasets to lazyload DB
> ** inst
> ** byte-compile and prepare package for lazy loading
> Warning: multiple methods tables found for 'export'
> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), 
versionCheck = vI[[j]]) :
>   namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is 
required
> Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
> Execution halted
> ERROR: lazy loading failed for package 'CNVScope'
> * removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'
>
> These errors tend to be check server dependent (only occurs on 

Re: [R-pkg-devel] Old version of rtracklayer on a single check server

[Henrik Bengtsson]

I stand corrected about the R-devel version (and now R 4.1.0) on CRAN.

However, isn't it the case that it will never be solved for R 4.0.0 (to
become R-oldrel on CRAN) and CRAN will keep reporting an error on MS
Windows there because
https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html provides
only an older version for MS Windows?

If so, an alternative to relying on Suggests is to make the package depend
on R (>= 4.1.0).

/Henrik

On Tue, May 18, 2021, 09:08 Martin Morgan  wrote:

> That’s not correct Henrik.
>
> CRAN follows CRAN rules for installing packages, so uses
> tools:::BioC_version_for_R_version(). For R-devel we have
>
> > R.version.string
> [1] "R Under development (unstable) (2021-05-18 r80323)"
> > tools:::.BioC_version_associated_with_R_version()
> [1] '3.13'
>
> For this version of Bioconductor, the rtracklayer version (from
> https://bioconductor.org/packages/3.13/rtracklayer, or
> `available.packages(repos = 
> "https://bioconductor.org/packages/3.13/bioc;)["rtracklayer",
> "Version"]`) is 1.51.5.
>
> So the r-devel-windows-ix86+x86_64 builder mentioned in the post has the
> wrong version of rtracklayer for R-devel.
>
> Martin Morgan
>
> On 5/18/21, 11:49 AM, "R-package-devel on behalf of Henrik Bengtsson" <
> r-package-devel-boun...@r-project.org on behalf of
> henrik.bengts...@gmail.com> wrote:
>
> It's a problem with Bioconductor and a broken release history of
> 'rtracklayer' on MS Windows (e.g.
> https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html)
> plus how each Bioconductor version is tied to a specific R version.
> In other words, even if they fix it in Bioconductor 3.13 (for R
> 4.1.0), it can't be fixed in Bioconductor 3.12 (for R 4.0.0), so
> you're package will keep failing on Windows for R 4.0.0.  The reason
> why it can't be fixed in Bioconductor 3.12 is that they have now
> frozen that release forever.
>
> Because of this, I suspect the only solution is to make 'rtracklayer'
> an optional package, i.e. move it to Suggests: and update all your
> code to run conditionally of that package being available. I recommend
> you reach out to the bioc-devel mailing list for advice.
>
> /Henrik
>
> On Tue, May 18, 2021 at 4:33 AM Dalgleish, James (NIH/NCI) [F] via
> R-package-devel  wrote:
> >
> > To any who might have an idea:
> >
> > I've been reading several posts in the digest about dependency
> version issues on the check servers and I'm having my own issue, which I
> can't solve because I can't upgrade the check server's package version:
> > * installing *source* package 'CNVScope' ...
> > ** using staged installation
> > ** R
> > ** data
> > *** moving datasets to lazyload DB
> > ** inst
> > ** byte-compile and prepare package for lazy loading
> > Warning: multiple methods tables found for 'export'
> > Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()),
> versionCheck = vI[[j]]) :
> >   namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is
> required
> > Calls:  ... namespaceImportFrom -> asNamespace ->
> loadNamespace
> > Execution halted
> > ERROR: lazy loading failed for package 'CNVScope'
> > * removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'
> >
> > These errors tend to be check server dependent (only occurs on
> r-devel-windows-ix86+x86_64<
> https://cran.r-project.org/web/checks/check_flavors.html#r-devel-windows-ix86_x86_64>)
> and I'm just trying to make the small change to closeAllConnections() that
> was asked earlier of maintainers by Kurt Hornik and the CRAN team, but I
> can't because of this old package version on the devel check server, which
> has the same error:
> >
> https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00check.log
> >
> https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00install.out
> >
> > Is there any way around this? I notice the maintainer of the
> 'gtsummary' package had a similar issue:
> >
> > "> I am trying to make a release that depends on gt v0.3.0, but I
> get an error
> >
> > > when I test the package on Windows Dev
> `devtools::check_win_devel()` that
> >
> > > the gt package is available but it's an unsuitable version.  Does
> anyone
> >
> > > know why the gt v0.3.0 is unavailable?"
> >
> >
> >
> > I'm open to any suggestions, but can't see a way around this issue
> from my end without the ability to service the check server.
> >
> >
> > Thanks,
> > James Dalgleish
> > Cancer Genetics Branch,
> > Center for Cancer Research,
> > National Cancer Institute,
> > National Institutes of Health,
> > Bethesda, MD
> >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 

Re: [Rd] Add to Documentation of atan2.

[Ben Bolker]

  Can you dig through into the code, see what's going on, and suggest a 
documentation patch?  To get you started, the code for the complex 
version of atan2 is in


https://svn.r-project.org/R/trunk/src/main/complex.c

z_atan2 is at line 669 (the first argument is a pointer to the result, 
args 2 [csn] and 3 [ccs] are pointers to the arguments of atan2())


 In generic cases the computation is

dr = catan(dcsn / dccs);
if(creal(dccs) < 0) dr += M_PI;
if(creal(dr) > M_PI) dr -= 2 * M_PI;

where dcsn, dccs are converted versions of the args.

catan() is *either* taken from system libraries or is defined at line 489.

  On my system (Ubuntu), 'man 3 catan' gives documentation on the 
function, and says "The real part of y is chosen in the interval 
[-pi/2,pi/2]" - but that _could_ be system-dependent.


   cheers
   Ben Bolker

On 5/18/21 10:39 AM, Jorgen Harmse via R-devel wrote:

The current documentation says that atan2(y,x) is the angle between the x-axis and 
the vector from the origin to (x,y), but what does this mean when x & y are 
complex? The function seems to pick theta with Re(theta) between -pi and pi and 
with tan(theta) (approximately) equal to y/x, but that leaves 2 (sometimes 3) 
options, and there must be a set (branch region with 3 real dimensions?) on which 
the function is discontinuous. Please add details.

Even for real inputs, it might help to spell out the behaviour on the negative 
x-axis. It mostly matches the branch-cut rules for the other functions, but 
atan2(0,0)==0 is a unexpected.

I also suggest ‘See Also’ links from trigonometric functions to hyperbolic 
functions and from hyperbolic functions to exponential & logarithmic functions.

Regards,
Jorgen Harmse.




R.version.string


[1] "R version 4.0.4 (2021-02-15)"






[[alternative HTML version deleted]]

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



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

Re: [Rd] base R pipe documentation

[Bill Dunlap]

It would be nice to have "|>" listed in the precedence table in
help(Syntax).  I think it has the same precedence as "%any%" and both are
left-associative.
  > quote( a |> f1() %any% f2())
  f1(a) %any% f2()
  > quote( a %any% f1() |> f2())
  f2(a %any% f1())

help(`|>`) does mention magrittr's pipe operator so the user can compare
and contrast them.

-Bill

On Mon, May 17, 2021 at 10:20 AM Ben Bolker  wrote:

>As of right now, as far as I can tell, the documentation for the new
> native |> pipe still says that it's experimental.
>
>
> https://github.com/wch/r-source/blob/trunk/src/library/base/man/pipeOp.Rd#L45
>
>   *Pipe support is experimental and may change prior to release.*
>
> Also still in the 4-1 branch:
>
>
> https://github.com/wch/r-source/blob/R-4-1-branch/src/library/base/man/pipeOp.Rd#L45
>
>(The corresponding comment in the NEWS file has been fixed in the
> last 24 hours, but hasn't propagated to the online/HTML version on the
> developer page yet ...)
>
>As a "wish list" item, if there are any particularly
> salient/important  differences between the |> pipe and the %>% magrittr
> pipe, it would be great to have those documented (I know that
> documenting the difference between a base-R operator and the one that's
> implemented in a non-Recommended package is a little weird, but it would
> be helpful in this case ...)  I know I could go back to the mailing list
> discussion at
> https://hypatia.math.ethz.ch/pipermail/r-devel/2020-December/080173.html
> and try to figure it out for myself ...
>
>cheers
> Ben Bolker
>
> __
> 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: [R-pkg-devel] Passing CRAN checks for a package linking to a system library on CRAN machines

[Toby Hocking]

Hi Tomas, these are really helpful suggestions, which are not at all
discussed in the current Writing R Extensions, nor in CRAN Repository
Policy. Would you please consider adding this information to one of these
official sources of documentation?

On Fri, May 14, 2021 at 3:59 AM Tomas Kalibera 
wrote:

>
> On 5/14/21 4:19 AM, SN248 wrote:
> > Thank you Tomas and Sokol for your suggestions.
> >
> > Based on Tomas' suggestion, it seems the best way forward would be to
> > first request CRAN maintainers to install libsbml on the CRAN
> > machines. It is quite straightforward to install the library from the
> > instructions provided online. If the installation fails on a
> > particular architecture, I should try bundling the source code and
> > creating the static libraries.
>
> Please let me clarify, I am not suggesting that you ask CRAN team to
> create the distribution packages for you, but only to install an
> existing distribution package (in case they are not doing that already).
>
> The distribution package is usually a script which automatically
> downloads the software, builds it, picks up the results, adds some
> meta-data about dependencies, and archives them in a supported format.
> Someone has to create the distribution package, and I am suggesting that
> you as R package maintainer should do that, possibly getting help from
> other volunteers e.g even on the R-devel mailing list. The CRAN team
> would only add that package name to their list of installed packages (in
> case it is not there implicitly, i.e. they possibly won't have to do
> anything).
>
> So first, I would should check for existing distribution packages. Most
> distributions have their own indexing/search support, but you can also
> look online as follows.
>
> For Linux distributions, there is e.g. pkgs.org for the first quick
> search (libsml-devel, libsbml-dev might be what you are looking for).
>
> For Windows, msys2 packages are here
> https://github.com/msys2/MINGW-packages/, rtools packages are here
> https://github.com/r-windows/rtools-packages (so there is
> mingw-w64-libsbml). MXE packages are here
> https://github.com/mxe/mxe/tree/master/src and the customized version
> for R is here
>
> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/src/
> (so upstream MXE doesn't have sbml, but the customized has libsbml).
>
> For macOS, recipes for R are here
> https://github.com/R-macos/recipes/tree/master/recipes and it does not
> have sbml library as far as I can see.
>
> So, if you wanted your package to use sbml, the best way would be to
> test it with the sbml package from all the distributions mentioned above
> (from Linux, at least the ones used by CRAN - Debian/Ubuntu, Fedora).
> Then, you would create a recipe (distribution package) for macOS, test
> it with your package, and contribute to the "recipes" above. When
> creating the recipe, look at other recipes to get the form, and look at
> sbml in the previously mentioned distributions to see how to
> download/build it (in addition to the online manual you mentioned).
>
> Once that is in, you could submit your package to CRAN, following the
> usual checks you do when submitting packages. And then, in case it
> failed on some of the CRAN machines, you could contact the individual
> maintainer and ask for installing that distribution package of the given
> name. In some cases it won't be necessary (the machines would already
> have the package, they may be installing all available packages
> automatically).
>
> This may sound like a bit of work, but that is the price for adding
> dependencies on native libraries, and someone has to do this work.
> Installing libraries manually on the check machines is not going to
> scale and may be too much burden for many end users, apart from
> difficulties with repeatability, maintenance, etc.
>
> Best
> Tomas
>
> >
> > Thanks again for your help.
> > Satya
> >
> > On Thu, May 13, 2021 at 2:28 AM Tomas Kalibera
> > mailto:tomas.kalib...@gmail.com>> wrote:
> >
> >
> > On 5/13/21 7:06 AM, SN248 wrote:
> > > I am working on a package which provides an interface to the
> > libsbml C++
> > > library (http://sbml.org/Software/libSBML
> > ) in R. The source code of this
> > > package (r2sbml) can be found at the following link
> > >
> > > https://github.com/sn248/r2sbml 
> > >
> > > The package passes CRAN checks with `R CMD check` on my machine,
> > but I do
> > > have dependency (libsbml library) installed on my machine (OSX)
> with
> > > headers and static libs at the usual locations, i.e.,
> > /usr/local/include
> > > and /usr/local/lib. The package also passes CRAN check on a
> > Windows machine
> > > with libsbml installed using Rtools40 and msys2. The DESCRIPTION
> > file lists
> > > libsbml in SystemRequirements but `R CMD check` obviously fails
> > on 

Re: [R-pkg-devel] Old version of rtracklayer on a single check server

[Martin Morgan]

That’s not correct Henrik.

CRAN follows CRAN rules for installing packages, so uses 
tools:::BioC_version_for_R_version(). For R-devel we have

> R.version.string
[1] "R Under development (unstable) (2021-05-18 r80323)"
> tools:::.BioC_version_associated_with_R_version()
[1] '3.13'

For this version of Bioconductor, the rtracklayer version (from 
https://bioconductor.org/packages/3.13/rtracklayer, or 
`available.packages(repos = 
"https://bioconductor.org/packages/3.13/bioc;)["rtracklayer", "Version"]`) is 
1.51.5. 

So the r-devel-windows-ix86+x86_64 builder mentioned in the post has the wrong 
version of rtracklayer for R-devel.

Martin Morgan

On 5/18/21, 11:49 AM, "R-package-devel on behalf of Henrik Bengtsson" 
 
wrote:

It's a problem with Bioconductor and a broken release history of
'rtracklayer' on MS Windows (e.g.
https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html)
plus how each Bioconductor version is tied to a specific R version.
In other words, even if they fix it in Bioconductor 3.13 (for R
4.1.0), it can't be fixed in Bioconductor 3.12 (for R 4.0.0), so
you're package will keep failing on Windows for R 4.0.0.  The reason
why it can't be fixed in Bioconductor 3.12 is that they have now
frozen that release forever.

Because of this, I suspect the only solution is to make 'rtracklayer'
an optional package, i.e. move it to Suggests: and update all your
code to run conditionally of that package being available. I recommend
you reach out to the bioc-devel mailing list for advice.

/Henrik

On Tue, May 18, 2021 at 4:33 AM Dalgleish, James (NIH/NCI) [F] via
R-package-devel  wrote:
>
> To any who might have an idea:
>
> I've been reading several posts in the digest about dependency version 
issues on the check servers and I'm having my own issue, which I can't solve 
because I can't upgrade the check server's package version:
> * installing *source* package 'CNVScope' ...
> ** using staged installation
> ** R
> ** data
> *** moving datasets to lazyload DB
> ** inst
> ** byte-compile and prepare package for lazy loading
> Warning: multiple methods tables found for 'export'
> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), 
versionCheck = vI[[j]]) :
>   namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is 
required
> Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
> Execution halted
> ERROR: lazy loading failed for package 'CNVScope'
> * removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'
>
> These errors tend to be check server dependent (only occurs on 
r-devel-windows-ix86+x86_64)
 and I'm just trying to make the small change to closeAllConnections() that was 
asked earlier of maintainers by Kurt Hornik and the CRAN team, but I can't 
because of this old package version on the devel check server, which has the 
same error:
> 
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00check.log
> 
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00install.out
>
> Is there any way around this? I notice the maintainer of the 'gtsummary' 
package had a similar issue:
>
> "> I am trying to make a release that depends on gt v0.3.0, but I get an 
error
>
> > when I test the package on Windows Dev `devtools::check_win_devel()` 
that
>
> > the gt package is available but it's an unsuitable version.  Does anyone
>
> > know why the gt v0.3.0 is unavailable?"
>
>
>
> I'm open to any suggestions, but can't see a way around this issue from 
my end without the ability to service the check server.
>
>
> Thanks,
> James Dalgleish
> Cancer Genetics Branch,
> Center for Cancer Research,
> National Cancer Institute,
> National Institutes of Health,
> Bethesda, MD
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Old version of rtracklayer on a single check server

[Henrik Bengtsson]

It's a problem with Bioconductor and a broken release history of
'rtracklayer' on MS Windows (e.g.
https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html)
plus how each Bioconductor version is tied to a specific R version.
In other words, even if they fix it in Bioconductor 3.13 (for R
4.1.0), it can't be fixed in Bioconductor 3.12 (for R 4.0.0), so
you're package will keep failing on Windows for R 4.0.0.  The reason
why it can't be fixed in Bioconductor 3.12 is that they have now
frozen that release forever.

Because of this, I suspect the only solution is to make 'rtracklayer'
an optional package, i.e. move it to Suggests: and update all your
code to run conditionally of that package being available. I recommend
you reach out to the bioc-devel mailing list for advice.

/Henrik

On Tue, May 18, 2021 at 4:33 AM Dalgleish, James (NIH/NCI) [F] via
R-package-devel  wrote:
>
> To any who might have an idea:
>
> I've been reading several posts in the digest about dependency version issues 
> on the check servers and I'm having my own issue, which I can't solve because 
> I can't upgrade the check server's package version:
> * installing *source* package 'CNVScope' ...
> ** using staged installation
> ** R
> ** data
> *** moving datasets to lazyload DB
> ** inst
> ** byte-compile and prepare package for lazy loading
> Warning: multiple methods tables found for 'export'
> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = 
> vI[[j]]) :
>   namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is required
> Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
> Execution halted
> ERROR: lazy loading failed for package 'CNVScope'
> * removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'
>
> These errors tend to be check server dependent (only occurs on 
> r-devel-windows-ix86+x86_64)
>  and I'm just trying to make the small change to closeAllConnections() that 
> was asked earlier of maintainers by Kurt Hornik and the CRAN team, but I 
> can't because of this old package version on the devel check server, which 
> has the same error:
> https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00check.log
> https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00install.out
>
> Is there any way around this? I notice the maintainer of the 'gtsummary' 
> package had a similar issue:
>
> "> I am trying to make a release that depends on gt v0.3.0, but I get an error
>
> > when I test the package on Windows Dev `devtools::check_win_devel()` that
>
> > the gt package is available but it's an unsuitable version.  Does anyone
>
> > know why the gt v0.3.0 is unavailable?"
>
>
>
> I'm open to any suggestions, but can't see a way around this issue from my 
> end without the ability to service the check server.
>
>
> Thanks,
> James Dalgleish
> Cancer Genetics Branch,
> Center for Cancer Research,
> National Cancer Institute,
> National Institutes of Health,
> Bethesda, MD
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [Bioc-devel] Last day to make commit before the RELEASE_3_13

[Martin, Tiphaine]

Thanks a lot for this link and explanation
Tiphaine



Tiphaine Martin
Postdoc Fellow
Parsons lab
Department of Oncological Sciences
The Tisch Cancer Institute at Mount Sinai
Icahn School of Medicine at Mount Sinai
Hess Center for Science and Medicine
1470 Madison Ave, 6th Floor
New York, NY 10029
tel: 1- 212-824-9253
Email: tiphaine.mar...@mssm.edu



From: Kern, Lori 
Sent: Tuesday, May 18, 2021 10:44 AM
To: Martin, Tiphaine ; bioc-devel@r-project.org 

Subject: Re: Last day to make commit before the RELEASE_3_13

It looks like you just pushed the changes up Sunday May 16th.  It can take up 
to 48 hours to get through the build report and landing page depending on the 
time of the push to our system because the builders only pull, build, check 
once per day.  You missed the cut off to be on yesterday's report.  I expect to 
see the updated version on today's report.

See the top of this page for timing
http://bioconductor.org/developers/how-to/troubleshoot-build-report/
Bioconductor - Troubleshooting Build 
Report
Troubleshooting Build Report How and When does the builder pull? When will my 
changes propagate? Please remember the daily builder pulls, installs, builds, 
and checks ...
bioconductor.org



Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Martin, 
Tiphaine 
Sent: Tuesday, May 18, 2021 10:32 AM
To: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Last day to make commit before the RELEASE_3_13

Hi,
I submitted my update of my package to master Sunday (1.23.1). I did not see a 
new update in build/check report 
(http://secure-web.cisco.com/17AMCgK31b8cwSa9x6pbGruTkLWwGrTeu42AoLtib4FhptXpFa-f9vMSDnapiS4gIxwbiXLhPx-WZVbl8PXapb3fIqJQpLfbQYfUSo6Oxlk-1BNn5KQwfXLXmoaD6Bvl7YH2V_hEWV1JIGzEub1okwQIz6SagNlk31mQyKF3F6nb1ij0rex7VHbYacEGSbxthiLAGdagfkOOUcMfV_Z4uYBTxRUZ7mG3TVXbymEWOGya2n8P-8x2_5AeIDpDvOjFM1HnttZRilcN_dVr1MU2SznjnqUZjULBhXk4NcNGXO7xBoQqqr4qoEyuWMFxWH8Vzt2rqFEotbVlohOIN3Vh_JQ/http%3A%2F%2Fbioconductor.org%2FcheckResults%2Fdevel%2Fbioc-LATEST%2FcoMET%2F)

Did I miss something when I submit it?
Thanks,
Tiphaine

-Original Message-
From: Bioc-devel  On Behalf Of Kern, Lori
Sent: Tuesday, May 18, 2021 7:13 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Last day to make commit before the RELEASE_3_13

USE CAUTION: External Message.

Hello Bioconductor developers,

We are still on track for Bioconductor Release 3.13 for this Thursday May 20th. 
 This means that tonight is the last day to commit changes to the devel branch 
before creating of the RELEASE_3_13 versions of your packages.  And any changes 
you make to your packages at this point will not be reflected in a build report 
before we branch.

There will be a temporary code freeze tomorrow morning (EST)  while the 
branching for RELEASE_3_13 occurs automatically by the core team.  You will 
receive emails when the freeze occurs and when commits to the branches can 
resume.

As clarification,  you will still be able to commit to the release 3.13 branch 
and the devel branch throughout the next release cycle. But any packages that 
have not been fixed for failures or bugs in devel would then have to be 
fixed/uploaded to both the 

Re: [Bioc-devel] MSstatsTMTPTM deprecation

[Kern, Lori]

Thank you. We will take care of the deprecation. There is nothing more you need 
to do

Get Outlook for iOS

From: Bioc-devel  on behalf of Devon Kohler 

Sent: Tuesday, May 18, 2021 10:36:29 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] MSstatsTMTPTM deprecation

Hello,

I wanted to request a deprecation of MSstatsTMTPTM. Its full functionality is 
now implemented in MSstatsPTM. This change should help resolve a lot of the 
long function names which were noted in the initial review of MSstatsTMTPTM. 
Please let me know if there is anything else you need me to do.

Devon

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1132xvIJXoiSOn_I5kiZuF0sKvRhTtvWH5o3LU3FSCudFhIapUn8GrZ70OcLzvnzxWKoO7bvPXT2TUVv1lW386zA5JDmnuxqTZROm19Jsqqo6xHnU3eTFj2CYR0Ja46smirCEDDP3c6iXKwPnhkJ_4Ox-3pPMzJ6d3LsUSH9IbC6o4q9zY-hA_ePHB8Mz74TmjmQq3wDR-liSRzhaTX1URR-9j9DeG6igkQa6Zx8DC95Rz-WiwEoUN2ePrlWS_xOxokzAstiX0VowtRQ9Gj_FYwQ4xZiuNxxpuZ3yd8kfB9LPD3GPiZu28POlbayJWNy31MJ8ECS9dxK5QW9LwraYNg/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



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

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

[Rd] Add to Documentation of atan2.

[Jorgen Harmse via R-devel]

The current documentation says that atan2(y,x) is the angle between the x-axis 
and the vector from the origin to (x,y), but what does this mean when x & y are 
complex? The function seems to pick theta with Re(theta) between -pi and pi and 
with tan(theta) (approximately) equal to y/x, but that leaves 2 (sometimes 3) 
options, and there must be a set (branch region with 3 real dimensions?) on 
which the function is discontinuous. Please add details.

Even for real inputs, it might help to spell out the behaviour on the negative 
x-axis. It mostly matches the branch-cut rules for the other functions, but 
atan2(0,0)==0 is a unexpected.

I also suggest ‘See Also’ links from trigonometric functions to hyperbolic 
functions and from hyperbolic functions to exponential & logarithmic functions.

Regards,
Jorgen Harmse.



> R.version.string

[1] "R version 4.0.4 (2021-02-15)"






[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Last day to make commit before the RELEASE_3_13

[Kern, Lori]

It looks like you just pushed the changes up Sunday May 16th.  It can take up 
to 48 hours to get through the build report and landing page depending on the 
time of the push to our system because the builders only pull, build, check 
once per day.  You missed the cut off to be on yesterday's report.  I expect to 
see the updated version on today's report.

See the top of this page for timing
http://bioconductor.org/developers/how-to/troubleshoot-build-report/
Bioconductor - Troubleshooting Build 
Report
Troubleshooting Build Report How and When does the builder pull? When will my 
changes propagate? Please remember the daily builder pulls, installs, builds, 
and checks ...
bioconductor.org



Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Martin, 
Tiphaine 
Sent: Tuesday, May 18, 2021 10:32 AM
To: bioc-devel@r-project.org 
Subject: Re: [Bioc-devel] Last day to make commit before the RELEASE_3_13

Hi,
I submitted my update of my package to master Sunday (1.23.1). I did not see a 
new update in build/check report 
(http://secure-web.cisco.com/17AMCgK31b8cwSa9x6pbGruTkLWwGrTeu42AoLtib4FhptXpFa-f9vMSDnapiS4gIxwbiXLhPx-WZVbl8PXapb3fIqJQpLfbQYfUSo6Oxlk-1BNn5KQwfXLXmoaD6Bvl7YH2V_hEWV1JIGzEub1okwQIz6SagNlk31mQyKF3F6nb1ij0rex7VHbYacEGSbxthiLAGdagfkOOUcMfV_Z4uYBTxRUZ7mG3TVXbymEWOGya2n8P-8x2_5AeIDpDvOjFM1HnttZRilcN_dVr1MU2SznjnqUZjULBhXk4NcNGXO7xBoQqqr4qoEyuWMFxWH8Vzt2rqFEotbVlohOIN3Vh_JQ/http%3A%2F%2Fbioconductor.org%2FcheckResults%2Fdevel%2Fbioc-LATEST%2FcoMET%2F)

Did I miss something when I submit it?
Thanks,
Tiphaine

-Original Message-
From: Bioc-devel  On Behalf Of Kern, Lori
Sent: Tuesday, May 18, 2021 7:13 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Last day to make commit before the RELEASE_3_13

USE CAUTION: External Message.

Hello Bioconductor developers,

We are still on track for Bioconductor Release 3.13 for this Thursday May 20th. 
 This means that tonight is the last day to commit changes to the devel branch 
before creating of the RELEASE_3_13 versions of your packages.  And any changes 
you make to your packages at this point will not be reflected in a build report 
before we branch.

There will be a temporary code freeze tomorrow morning (EST)  while the 
branching for RELEASE_3_13 occurs automatically by the core team.  You will 
receive emails when the freeze occurs and when commits to the branches can 
resume.

As clarification,  you will still be able to commit to the release 3.13 branch 
and the devel branch throughout the next release cycle. But any packages that 
have not been fixed for failures or bugs in devel would then have to be 
fixed/uploaded to both the RELEASE_3_13 branch and the devel master branch.


Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

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://secure-web.cisco.com/1yAJ1Ew34ir0-53X0xYhT0ozYRnulS26R-Dn9grNG1V9NNUYY7mc7sXitkm6FQtYhXOvyuDiSpDhDQgM1PCMgc9WWW8cawdpHNhDrlyHZ3TI7ONwhqKbwLlp9zH66fHlyRs0LGsN1zytQAowoJN0Krj1o2uniFYPjicmA-PEhz6PW8s78mOSvNwE1e-15Ja3qLsgOcmcsgyqfAIeu8OmpUpj3k_IoMICAtmDZV96uWrAobwErVrOsINm5aG5BFs9ARQPq57l5kKO37kcnB9sGPDZItEs1qe-rOXXMUbpkrHB4lO-pwhSVJq8jCUFCJANHEzUxbVMbKClU2-uf9t7hkQ/https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel%26d%3DDwICAg%26c%3DshNJtf5dKgNcPZ6Yh64b-A%26r%3DBH3UNPUNhOc-niJT9d00EAx3ah5AHfQlhQQ_SHtjigA%26m%3DeaCULiTxavrVFA_k5rzyIu8OQHqCyR4X8ZkPzSJvT3Y%26s%3DLLeH1zl0Z6mOeUFQge38J5i0CPJUlP8XiY4L-wiB-qI%26e%3D

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1FA_BWxa4bnWiG9kc0rTgbHC9FU7hZe40-KhX8mFhIRJpYePOjyXtL0ZtdC_WWxW1H8NZmtaplLF1VBK3pq3nn-HF3p9peBP_gOqTIsOYE9i-INWV5VSoAOC5bL-IYkRs6_pSXx37utcfdFWieKlnikXFewx_sM8KQ66Tsoip_OmLw8rYWpJ8yu05_axSGjH-naftQSzi7MSZOXBG6_UjcMkKt_MVlCBNVphunbeIznb4pukKpbeUhEqTySeVoVZclZlb6cp-jvOcS2aUFa68iPfEuLieSpzLfYuhKphYkLXLmtQtYl-mZ-bjHt99NUcofDkPlTUaUBd3qUafv2wJBQ/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message 

[Bioc-devel] MSstatsTMTPTM deprecation

[Devon Kohler]

Hello,

I wanted to request a deprecation of MSstatsTMTPTM. Its full functionality is 
now implemented in MSstatsPTM. This change should help resolve a lot of the 
long function names which were noted in the initial review of MSstatsTMTPTM. 
Please let me know if there is anything else you need me to do.

Devon

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Last day to make commit before the RELEASE_3_13

[Fabricio de Almeida]

Tiphaine, did you remember to bump package version in your DESCRIPTION file 
after making the changes?


=


Fabr�cio de Almeida Silva

Undergraduate degree in Biological Sciences (UENF)

MSc. candidate in Plant Biotechnology (PGBV/UENF - RJ/Brazil)

Laborat�rio de Qu�mica e Fun��o de Prote�nas e Pept�deos (LQFPP/CBB/UENF - 
RJ/Brazil)

Lattes CNPq: http://lattes.cnpq.br/3119358824056108

Personal website: https://almeidasilvaf.github.io/home/


De: Bioc-devel  em nome de Martin, Tiphaine 

Enviado: ter�a-feira, 18 de maio de 2021 09:32
Para: bioc-devel@r-project.org 
Assunto: Re: [Bioc-devel] Last day to make commit before the RELEASE_3_13

Hi,
I submitted my update of my package to master Sunday (1.23.1). I did not see a 
new update in build/check report 
(http://bioconductor.org/checkResults/devel/bioc-LATEST/coMET/)

Did I miss something when I submit it?
Thanks,
Tiphaine

-Original Message-
From: Bioc-devel  On Behalf Of Kern, Lori
Sent: Tuesday, May 18, 2021 7:13 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Last day to make commit before the RELEASE_3_13

USE CAUTION: External Message.

Hello Bioconductor developers,

We are still on track for Bioconductor Release 3.13 for this Thursday May 20th. 
 This means that tonight is the last day to commit changes to the devel branch 
before creating of the RELEASE_3_13 versions of your packages.  And any changes 
you make to your packages at this point will not be reflected in a build report 
before we branch.

There will be a temporary code freeze tomorrow morning (EST)  while the 
branching for RELEASE_3_13 occurs automatically by the core team.  You will 
receive emails when the freeze occurs and when commits to the branches can 
resume.

As clarification,  you will still be able to commit to the release 3.13 branch 
and the devel branch throughout the next release cycle. But any packages that 
have not been fixed for failures or bugs in devel would then have to be 
fixed/uploaded to both the RELEASE_3_13 branch and the devel master branch.


Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=shNJtf5dKgNcPZ6Yh64b-A=BH3UNPUNhOc-niJT9d00EAx3ah5AHfQlhQQ_SHtjigA=eaCULiTxavrVFA_k5rzyIu8OQHqCyR4X8ZkPzSJvT3Y=LLeH1zl0Z6mOeUFQge38J5i0CPJUlP8XiY4L-wiB-qI=

___
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] Last day to make commit before the RELEASE_3_13

[Martin, Tiphaine]

Hi,
I submitted my update of my package to master Sunday (1.23.1). I did not see a 
new update in build/check report 
(http://bioconductor.org/checkResults/devel/bioc-LATEST/coMET/)

Did I miss something when I submit it?
Thanks,
Tiphaine 

-Original Message-
From: Bioc-devel  On Behalf Of Kern, Lori
Sent: Tuesday, May 18, 2021 7:13 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Last day to make commit before the RELEASE_3_13

USE CAUTION: External Message.

Hello Bioconductor developers,

We are still on track for Bioconductor Release 3.13 for this Thursday May 20th. 
 This means that tonight is the last day to commit changes to the devel branch 
before creating of the RELEASE_3_13 versions of your packages.  And any changes 
you make to your packages at this point will not be reflected in a build report 
before we branch.

There will be a temporary code freeze tomorrow morning (EST)  while the 
branching for RELEASE_3_13 occurs automatically by the core team.  You will 
receive emails when the freeze occurs and when commits to the branches can 
resume.

As clarification,  you will still be able to commit to the release 3.13 branch 
and the devel branch throughout the next release cycle. But any packages that 
have not been fixed for failures or bugs in devel would then have to be 
fixed/uploaded to both the RELEASE_3_13 branch and the devel master branch.


Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=shNJtf5dKgNcPZ6Yh64b-A=BH3UNPUNhOc-niJT9d00EAx3ah5AHfQlhQQ_SHtjigA=eaCULiTxavrVFA_k5rzyIu8OQHqCyR4X8ZkPzSJvT3Y=LLeH1zl0Z6mOeUFQge38J5i0CPJUlP8XiY4L-wiB-qI=

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

[R-pkg-devel] Old version of rtracklayer on a single check server

[Dalgleish, James (NIH/NCI) [F] via R-package-devel]

To any who might have an idea:

I've been reading several posts in the digest about dependency version issues 
on the check servers and I'm having my own issue, which I can't solve because I 
can't upgrade the check server's package version:
* installing *source* package 'CNVScope' ...
** using staged installation
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Warning: multiple methods tables found for 'export'
Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = 
vI[[j]]) :
  namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is required
Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
Execution halted
ERROR: lazy loading failed for package 'CNVScope'
* removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'

These errors tend to be check server dependent (only occurs on 
r-devel-windows-ix86+x86_64)
 and I'm just trying to make the small change to closeAllConnections() that was 
asked earlier of maintainers by Kurt Hornik and the CRAN team, but I can't 
because of this old package version on the devel check server, which has the 
same error:
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00check.log
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00install.out

Is there any way around this? I notice the maintainer of the 'gtsummary' 
package had a similar issue:

"> I am trying to make a release that depends on gt v0.3.0, but I get an error

> when I test the package on Windows Dev `devtools::check_win_devel()` that

> the gt package is available but it's an unsuitable version.  Does anyone

> know why the gt v0.3.0 is unavailable?"



I'm open to any suggestions, but can't see a way around this issue from my end 
without the ability to service the check server.


Thanks,
James Dalgleish
Cancer Genetics Branch,
Center for Cancer Research,
National Cancer Institute,
National Institutes of Health,
Bethesda, MD


[[alternative HTML version deleted]]

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

[Bioc-devel] Last day to make commit before the RELEASE_3_13

[Kern, Lori]

Hello Bioconductor developers,

We are still on track for Bioconductor Release 3.13 for this Thursday May 20th. 
 This means that tonight is the last day to commit changes to the devel branch 
before creating of the RELEASE_3_13 versions of your packages.  And any changes 
you make to your packages at this point will not be reflected in a build report 
before we branch.

There will be a temporary code freeze tomorrow morning (EST)  while the 
branching for RELEASE_3_13 occurs automatically by the core team.  You will 
receive emails when the freeze occurs and when commits to the branches can 
resume.

As clarification,  you will still be able to commit to the release 3.13 branch 
and the devel branch throughout the next release cycle. But any packages that 
have not been fixed for failures or bugs in devel would then have to be 
fixed/uploaded to both the RELEASE_3_13 branch and the devel master branch.


Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

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: [R-pkg-devel] InvalidUrlException for fontawesome icons in Rmarkdown vignette

[Vincent Nijs]

I see the same issue come up on rhub and the issue has also started showing
up for the previous version of the package. See results link below.

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

On Mon, May 17, 2021 at 6:10 AM Uwe Ligges 
wrote:

> Perhaps simply ask the CRAN crew to run the checks again, but as you do
> not say which package this is about etc, we can hardly help.
>
> Best,
> Uwe Ligges
>
> On 16.05.2021 08:16, Vincent Nijs wrote:
> > Hi,
> >
> > I submitted a minor update to a package and ran into the vignette
> > warning/error shown. FYI the package change had nothing to do with the
> > vignette.
> >
> > Flavor: r-devel-windows-ix86+x86_64
> > Check: re-building of vignette outputs, Result: WARNING
> >Error(s) in re-building vignettes:
> >--- re-building 'programming.Rmd' using rmarkdown
> >pandoc.exe: Could not fetch
> >
> https://urldefense.com/v3/__https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css__;!!Mih3wA!RgyNlE6MVL47VVcjFz5JmMHpLjgnleTMV8PUzdHRhLsF840eotO4MEE4Up6Lwg$
> > <
> https://urldefense.com/v3/__https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css__;!!Mih3wA!QDKkOEM4b68jQTdP9_B69YPFnkWW3hUKU0TnKHzueExJp5xLhyR22STQL1kQ0BZLBY0$
> >
> >InvalidUrlException "
> >
> https://urldefense.com/v3/__https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css__;!!Mih3wA!RgyNlE6MVL47VVcjFz5JmMHpLjgnleTMV8PUzdHRhLsF840eotO4MEE4Up6Lwg$
> > <
> https://urldefense.com/v3/__https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css__;!!Mih3wA!QDKkOEM4b68jQTdP9_B69YPFnkWW3hUKU0TnKHzueExJp5xLhyR22STQL1kQ0BZLBY0$
> >"
> > "URL must be absolute"
> >Error: processing vignette 'programming.Rmd' failed with diagnostics:
> >pandoc document conversion failed with error 67
> >--- failed re-building 'programming.Rmd'
> >
> > I have used the Rmarkdown header below for this package for a number of
> > years and it has never caused an issue. The URL is absolute and links
> > properly. The vignette also builds fine locally.
> >
> > I'm stuck and hope you can shed some light on this problem.
> >
> > Thanks,
> >
> > Vincent
> >
> > ---
> > title: Programming with Radiant
> > author: "Vincent R. Nijs, Rady School of Management (UCSD)"
> > date: "`r Sys.Date()`"
> > output:
> >rmarkdown::html_vignette:
> >  css:
> >
> https://urldefense.com/v3/__https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css__;!!Mih3wA!RgyNlE6MVL47VVcjFz5JmMHpLjgnleTMV8PUzdHRhLsF840eotO4MEE4Up6Lwg$
> > vignette: >
> >%\VignetteIndexEntry{Programming with Radiant}
> >%\VignetteEngine{knitr::rmarkdown}
> >\usepackage[utf8]{inputenc}
> > ---
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> >
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!Mih3wA!RgyNlE6MVL47VVcjFz5JmMHpLjgnleTMV8PUzdHRhLsF840eotO4MEEPPgZZbg$
> >
>

[[alternative HTML version deleted]]

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

Re: [Rd] `mode`

[Martin Maechler]

> Dmichael Parrish via R-devel 
> on Tue, 18 May 2021 02:05:04 + (UTC) writes:

> Hello, Kindly revise the documentation for `mode` to
> reflect foo <- function () {} typeof(foo) # [1] "closure"
> mode(foo)# [1] "function"


> `help(mode)` states: Modes have the same set of names as
> types (see typeof) except that

>     types "integer" and "double" are returned as
> "numeric".

>     types "special" and "builtin" are returned as
> "function".

>     type "symbol" is called mode "name".

>     type "language" is returned as "(" or "call".


Indeed, that help file is missing  "closure", ...
amazingly, for all the history of R (of 25+ years).

Thank you!

I've already fixed this in the sources' trunk (svn rev 80321) a
minute ago; of course this will not make it anymore into R 4.1.0
but in its "patched" version, and then 4.1.1 and one.

With thankful regards,
Martin

--
Martin Maechler
ETH Zurich  and  R Core team


> I am presently reading `help(mode)` on:

> write.dcf(R.Version()) # platform: x86_64-w64-mingw32 #
> arch: x86_64 # os: mingw32 # system: x86_64, mingw32 #
> status: # major: 4 # minor: 0.3 # year: 2020 # month: 10 #
> day: 10 # svn rev: 79318 # language: R # version.string: R
> version 4.0.3 (2020-10-10) # nickname: Bunny-Wunnies Freak
> Out

 
> __ Hmo < 0.1 L tanh kd ---Miche, 1951 / I have
> placed the sand for the bound of the sea... and though the
> waves thereof toss themselves... they cannot pass over it
> ---YHWH, ca. 600 B.C. (Jer. 5:22)

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