date:20210222

Re: [Rd] Apple M1 CRAN checks

2021-02-22 Thread Travers Ching

Hi Prof Ripley,

Here is the automated message from CRAN which I thought meant needing to
fix an M1 issue:

"The auto-check found additional issues for the *last* version released on
CRAN:
  M1mac 
CRAN incoming checks do not test for these additional issues and you will
need an appropriately instrumented build of R to reproduce these.
Hence please reply-all and explain: Have these been fixed? "

However, RcppParallel (a dependency) isn't building on M1:
https://www.stats.ox.ac.uk/pub/bdr/M1mac/RcppParallel.out

If I understand you correctly, I can ignore the M1 "Additional issues"
until official R support?

Thank you,
Travers

On Mon, Feb 22, 2021 at 11:25 PM Prof Brian Ripley 
wrote:

> On 22/02/2021 08:30, Travers Ching wrote:
> > I noticed CRAN is now doing checks against Apple M1, and some packages
> are
> > failing including a dependency I use.
>
> I don't know what this refers to: M1 Mac CRAN checks are planned but
> AFAICS not yet included in the main results tables.
>
> OTOH, 'Additional issues' on M1 Mac have been reported on the results
> pages since early December.
>
> > Is building on M1 now a requirement, or can the check be ignored? If
> it's a
> > requirement, how can one test it out?
>
> 'requirement' for what?
>
> I am not aware of any CRAN package for which 'R CMD build' does not work
> on an M1 Mac.
>
> *Checking* might need an M1 Mac machine.  CRAN has only been notifying
> issues which can easily be corrected without access to M1 hardware (such
> as using suggested packages unconditionally or using optional
> capabilities without checking).
>
> > Travers
> >
> >   [[alternative HTML version deleted]]
>
> Please do re-read the posting guide (and 'Writing R Extensions').
> Also, this is not r-package-devel 
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>

[[alternative HTML version deleted]]

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

Re: [Rd] Apple M1 CRAN checks

2021-02-22 Thread Prof Brian Ripley


On 22/02/2021 08:30, Travers Ching wrote:

I noticed CRAN is now doing checks against Apple M1, and some packages are
failing including a dependency I use.


I don't know what this refers to: M1 Mac CRAN checks are planned but 
AFAICS not yet included in the main results tables.


OTOH, 'Additional issues' on M1 Mac have been reported on the results 
pages since early December.



Is building on M1 now a requirement, or can the check be ignored? If it's a
requirement, how can one test it out?


'requirement' for what?

I am not aware of any CRAN package for which 'R CMD build' does not work 
on an M1 Mac.


*Checking* might need an M1 Mac machine.  CRAN has only been notifying 
issues which can easily be corrected without access to M1 hardware (such 
as using suggested packages unconditionally or using optional 
capabilities without checking).



Travers

[[alternative HTML version deleted]]


Please do re-read the posting guide (and 'Writing R Extensions').
Also, this is not r-package-devel 

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-pkg-devel] FW: CRAN submission RIBMDB 1.0-21

2021-02-22 Thread Ivan Krylov

On Tue, 23 Feb 2021 02:03:34 +
Binit Kumar  wrote:

> I uploaded a package to CRAN but didn’t get any response on success
> or failure. How to know the status of the same?

Glad to know you were able to solve the check problems!

Your package is currently waiting in the queue to be automatically
checked: you can see it in ftp://cran.r-project.org/incoming/pretest/

See https://lockedata.github.io/cransays/articles/dashboard.html for
more information on how CRAN seems to be working.

-- 
Best regards,
Ivan

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

[R-pkg-devel] FW: CRAN submission RIBMDB 1.0-21

2021-02-22 Thread Binit Kumar

Hi Team,
I uploaded a package to CRAN but didn’t get any response on success or failure.
How to know the status of the same?


Thanks & Regards,
Binit Kumar

From: CRAN submission 
Sent: 22 February 2021 20:53
To: CRAN 
Subject: CRAN submission RIBMDB 1.0-21

EXTERNAL EMAIL



[This was generated from 
CRAN.R-project.org/submit.html]

The following package was uploaded to CRAN:
===

Package Information:
Package: RIBMDB
Version: 1.0-21
Title: DB2 Database Access
Author(s): ROCKET SOFTWARE [aut, cre]
Maintainer: ROCKET SOFTWARE 
mailto:bku...@rocketsoftware.com>>
Depends: R (>= 3.0.0),httr
Description: An ODBC database interface for DB2.
License: GPL-2 | GPL-3
Imports: methods, DBI, stats


The maintainer confirms that he or she
has read and agrees to the CRAN policies.

=

Original content of DESCRIPTION file:

Package: RIBMDB
Version: 1.0-21
Revision: $Rev: 3500 $
Date: 2021-02-21
Authors@R: c(person("ROCKET", "SOFTWARE", role = c("aut", "cre"),
email = "bku...@rocketsoftware.com"))
Title: DB2 Database Access
Description: An ODBC database interface for DB2.
SystemRequirements: An ODBC3 driver manager and drivers.
Depends: R (>= 3.0.0),httr
Imports: methods, DBI, stats
Collate: 'RODBCDBI.R' 'RODBC.R' 'ODBCConnection.R' 'ODBCDriver.R'
'ODBCResult.R' 'TypeInfo.R' 'sql.R' 'win.R'
'CLIDriver_installer.R'
LazyLoad: yes
Biarch: yes
License: GPL-2 | GPL-3
NeedsCompilation: yes
Packaged: 2021-02-22 15:16:58 UTC; bkumar
Author: ROCKET SOFTWARE [aut, cre]
Maintainer: ROCKET SOFTWARE 
mailto:bku...@rocketsoftware.com>>
Repository: CRAN
Date/Publication: 2020-01-23 05:28:45 UTC


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

[[alternative HTML version deleted]]

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

[R-pkg-devel] Unfixed error on cran submission: r-oldrel-macos-x86_64 ERROR

2021-02-22 Thread Knut Krueger




I clicked yes that I have fixed all errors, because I have no idea to 
fix Mac errors:


  No protocol specified
No protocol specified
Warning in fun(libname, pkgname) : couldn't connect to display ":0"
Error in structure(.External(.C_dotTclObjv, objv), class = "tclObj") :
 [tcl] invalid command name "font".
Calls: foo ... .tkplot.convert.font ->  -> tcl -> 
.Tcl.objv -> structure

Execution halted
Flavor: r-oldrel-macos-x86_64


What can I do with errors at unknown operating systems ...
I can fix windows and linux but not mac


Regards Knut

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

Re: [Rd] surprised matrix (1:256, 8, 8) doesn't cause error/warning

2021-02-22 Thread Hervé Pagès

Hi Martin,

It kind of does make sense to issue the warning when **recycling** (and 
this is consistent with what happens with recycling in general):

  > matrix(1:4, 6, 6)
   [,1] [,2] [,3] [,4] [,5] [,6]
  [1,]131313
  [2,]242424
  [3,]313131
  [4,]424242
  [5,]131313
  [6,]242424

  > matrix(1:4, 5, 6)
   [,1] [,2] [,3] [,4] [,5] [,6]
  [1,]123412
  [2,]234123
  [3,]341234
  [4,]412341
  [5,]123412
  Warning message:
  In matrix(1:4, 5, 6) :
data length [4] is not a sub-multiple or multiple of the number of 
rows [5]

(Note that the warning is misleading. matrix() is happy to take data 
with a length that is not a sub-multiple of the number of rows or cols 
as long as it's a sub-multiple of the length of the matrix.)

However I'm not sure that **truncating** the data is desirable behavior:

  > matrix(1:6, 1, 3)
   [,1] [,2] [,3]
  [1,]123

  > matrix(1:6, 1, 5)
   [,1] [,2] [,3] [,4] [,5]
  [1,]12345
  Warning message:
  In matrix(1:6, 1, 5) :
  data length [6] is not a sub-multiple or multiple of the number of 
columns [5]

Maybe you get a warning sometimes, if you are lucky, but still.

Finally note that you never get any warning with array():

  > array(1:4, c(5, 6))
   [,1] [,2] [,3] [,4] [,5] [,6]
  [1,]123412
  [2,]234123
  [3,]341234
  [4,]412341
  [5,]123412

  > array(1:6, c(1, 5))
   [,1] [,2] [,3] [,4] [,5]
  [1,]12345

Cheers,
H.

On 2/1/21 1:08 AM, Martin Maechler wrote:

Abby Spurdle (/əˈbi/)
 on Mon, 1 Feb 2021 19:50:32 +1300 writes:

 > I'm a little surprised that the following doesn't trigger an error or a 
warning.
 > matrix (1:256, 8, 8)

 > The help file says that the main argument is recycled, if it's too short.
 > But doesn't say what happens if it's too long.

It's somewhat subtler than one may assume :

matrix(1:9, 2,3)

  [,1] [,2] [,3]
[1,]135
[2,]246
Warning message:
In matrix(1:9, 2, 3) :
   data length [9] is not a sub-multiple or multiple of the number of rows [2]

matrix(1:8, 2,3)

  [,1] [,2] [,3]
[1,]135
[2,]246
Warning message:
In matrix(1:8, 2, 3) :
   data length [8] is not a sub-multiple or multiple of the number of columns 
[3]

matrix(1:12, 2,3)

  [,1] [,2] [,3]
[1,]135
[2,]246

So it looks to me the current behavior is quite on purpose.
Are you sure it's not documented at all when reading the docs
carefully?  (I did *not*, just now).

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

--
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

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

Re: [R-pkg-devel] Citation in DESCRIPTION file

2021-02-22 Thread Knut Krueger


Am 22.02.21 um 12:07 schrieb Sebastian Meyer:


Example: Einstein et al. (1935) .


What is the syntax if  I have multiple references f.e

For function foo1:
 Autor1 (2000) >doi:23837454235r2354.45764>
 Autor2 (2003) >doi:d73234k458f83.38358235>
For function foo2:
 Autor3 (2013) 

Regards Knut



Best regards,

Sebastian Meyer

__
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

[Bioc-devel] Bioconductor Developers Forum - 25th February

2021-02-22 Thread Mike Smith

Dear all,

The next Bioconductor Developers' Forum is this Thursday 25th February at
09:00 PST / 12:00 EST / 18:00 CET - You can find a calendar invite
attached and at https://tinyurl.com/BiocDevel-2021-02


   - This month we're going to focus on Unit Testing!  We'll introduce what
   unit tests are and why they might be useful for your R package
   development.
   - We'll also introduce some of the common R packages that help us write
   and run unit tests.  To that end Dirk Eddelbuettel will give an overview of
   'tinytest' and how he makes use of it in his work.
   - If you're a fan (or indeed not!) of testthat, RUnit, or any other
   testing strategies and would be willing to give a 10 minute overview please
   let me know ASAP!

We will be using BlueJeans and the meeting can be joined via:
https://bluejeans.com/114067881 (Meeting ID: 114 067 881)

Please let me know if you have future topics you'd like to discuss in the
Developers' Forum.

Best wishes,

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

Re: [R-pkg-devel] Two compile questions

2021-02-22 Thread Dirk Eddelbuettel



On 21 February 2021 at 19:52, Karim Rahim wrote:
| I'm in the process of incorporating some improvements that I pulled from
| github.
| I am getting a warning and a note. These occur when I run
| 
| R CMD check --as-cran fftwtools_0.9-10.tar.gz
| 
| 1.
| * checking whether package ‘fftwtools’ can be installed ... WARNING
| Found the following significant warnings:
|   'config' variable 'CPP' is deprecated
| See ‘/home/karim/PWLisp/fftwtools.Rcheck/00install.out’ for details.
| 
| In the .out file I have the following:
| 
| * installing *source* package ‘fftwtools’ ...
| ** using staged installation
| 'config' variable 'CPP' is deprecated
| checking for gcc... gcc -std=gnu99

What R version and/or OS version?  I do not see this with R 4.0.4 on Ubuntu.
But that may be related to 2. below. Read on...

| 2.
| Package has both ‘src/Makevars.in’ and ‘src/Makevars’.
| Installation with --no-configure' is unlikely to work.  If you intended
| ‘src/Makevars’ to be used on Windows, rename it to ‘src/Makevars.win’
| otherwise remove it.  If ‘configure’ created ‘src/Makevars’, you need a
| ‘cleanup’ script.
| 
| I cannot find a Makevars file. I do have a Makevars.win file.

You could be using a standard tool called 'autoconf'. There are some nice
tutorials out there. In essence it is used by calling 'autoconf' to turn a
'configure.ac' into a 'configure'.  The script 'configure' is then included
in package, executed by 'R CMD INSTALL ...' and friends and used to turn
'src/Makevars.in' into 'src/Makevars'.

| I would appreciate any help.

However, when I run 'autoconf' I

a) get the CPP warning (and we can likely remove the line from configure.ac)

b) worse, the resulting configure no longer works as the PKG_CHECK_MODULE
   use appears broken.

yet you do not need or use these as you have a _fixed_ src/Makevars. So no
need for configure.

I use these tools in my packages too. I can look into this later (maybe this
evening) and send you a pull request. Long story short you probably do not
even need autoconf, we can probably just use a shell script or Makefile
snippet to use

   edd@rob:~/git/fftwtools(master)$ pkg-config --cflags fftw3

   edd@rob:~/git/fftwtools(master)$ pkg-config --libs fftw3
   -lfftw3
   edd@rob:~/git/fftwtools(master)$ 

where on my Ubuntu system no -I is needed and no -L is needed either as
headers and shared library are in a common spot.  The difficulty generally is
dealing with non-standard situations. Outsourcing that to 'pkg-config' is one
option. You can also look at other packages using fftw3, for example CRAN
package 'fftw' that you depend upon too.  It _has_ what appears to be a
working configure.ac so you could read and study that and carry it over.
Note that it is a little longer than what you in your repo.

Hope this helps, Dirk

-- 
https://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: [Bioc-devel] How to change the name of a package on Bioconductor

2021-02-22 Thread Yu Huihui

Hello,


The build is still failed and the url https://bioconductor.org/packages/VaSP 
still points to "removed packages". I could successfully build it on my own 
computer. Would you please check what's the problem?


Thanks,
Huihui




--Original--
From:   
 "Yu Huihui"

https://bioconductor.org/packages/VaSP will point to the new landing page. 
The user will install it with `BiocManager::install("VaSP")`. The user will use 
the package with `library("VaSP")`.

The old version of your package, with the original name, will remain available 
at https://bioconductor.org/packages/3.11/vasp.

Note that your users who have already installed your package may experience 
problems, e.g., on some operating systems that respect differences in directory 
case, library(vasp) and library(VaSP) will return different versions of the 
package. On operating systems with file systems that do not differentiate 
between case their previous installation of vasp will be replaced by VaSP, and 
library(vasp) will no longer work. This problem will only persist for existing 
users of Bioconductor version 3.12.

Issues like this make renaming packages very tedious. A more formal approach 
would have deprecated 'vasp' over two release cycles (introduce deprecation in 
devel, wait for next release, remove from devel, leading to final removal two 
releases from now) and at the same time introduce a new package into devel. But 
the new package could not have been named 'VaSP', for the file naming reasons 
mentioned. So you would have had to rename your package something else, 
SuperVaSP, but then you would not have addressed your concern, that you had 
published your package under the name VaSP rather than vasp.

I chose to simply replace 'vasp' with 'VaSP', in both the release and devel 
branches, rather than force you though these hoops.

We will not create and maintain a special redirect for your package.

Martin


From: Yu Huihui http://bioconductor.org/packages/vasp and 
http://bioconductor.org/packages/VaSP can jump to 
http://bioconductor.org/packages/release/bioc/html/vasp.html. Is that possible? 
Currently the link http://bioconductor.org/packages/VaSP will jump to 
http://bioconductor.org/about/removed-packages/.; Please give me your 
suggestions.

Thanks,
Huihui


-- Original --
From: "Yu Huihui" http://bioconductor.org/packages/vasp). Recently I had a manuscript about this 
package publishednbsp;on New Physiologist 
(https://nph.onlinelibrary.wiley.com/doi/10./nph.17189). However, on the 
manuscript, the link to the package is http://bioconductor.org/packages/VaSP. I 
want to change the name of the package to VaSP from vasp.nbsp; I changed 
the package name and updated it innbsp;git.bioconductor.org, but the build 
failed and it said "ERRORnbsp; (Bad DESCRIPTION file)".nbsp;


Can I change the name of a package existing on Bioconductor? How can I do that?


Thanks,
Huihui
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[[alternative HTML version deleted]]

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

[R-pkg-devel] Citation in DESCRIPTION file

2021-02-22 Thread Knut Krueger

I was suggested: "A citation in the Description file is typically a good 
idea because people can think  whether your package is appropriate 
before reading all docs and installing the package, just from reading 
the CRAN overview page."


but I do not find hints how to implement the doi and the references in 
the DESCRIPTION file


Thank's in advance Knut

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

Re: [R-pkg-devel] Citation in DESCRIPTION file

2021-02-22 Thread Uwe Ligges





On 22.02.2021 14:46, Knut Krueger wrote:

Am 22.02.21 um 12:07 schrieb Sebastian Meyer:


Example: Einstein et al. (1935) .


What is the syntax if  I have multiple references f.e

For function foo1:
  Autor1 (2000) >doi:23837454235r2354.45764>
  Autor2 (2003) >doi:d73234k458f83.38358235>
For function foo2:
  Autor3 (2013) 



Write it inline as in:

See Author 1 (2021)  and Author 2 (2004) .

Best,
Uwe Ligges


Regards Knut



Best regards,

Sebastian Meyer

__
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] Support for several versions of another package

2021-02-22 Thread Iñaki Ucar

On Mon, 22 Feb 2021 at 11:55, Gábor Csárdi  wrote:
>
> On Sun, Feb 21, 2021 at 3:47 PM Iñaki Ucar  wrote:
> >
> > Hi,
> >
> > Let's say that pkgA uses pkgB::function1. Then, version 2 of pkgB
> > removes function1 and exports function2 for the same functionality. So
> > pkgA does something along these lines:
> >
> > if (utils::packageVersion("pkgB") < 2) {
> >   pkgB::function1()
> > } else {
> >   pkgB::function2()
> > }
> >
> > I'd say that there's nothing wrong with this code, and yet checks will
> > complain about "missing o unexported object" in pkgB, for either
> > function1 or function2 depending on the version of pkgB that is
> > available.
> >
> > Isn't this a false positive? Or is there a better way of doing this?
>
> I would just do this:
>
> if (utils::packageVersion("pkgB") < 2) {
>   getExportedValue("pkgB", "function1")()
> } else {
>   getExportedValue("pkgB", "function2")()
> }
>
> I would think that the check is fine with this, although I haven't tried.

This works without warnings or notes. Thanks!

-- 
Iñaki Úcar

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

Re: [Bioc-devel] About developing package

2021-02-22 Thread Kern, Lori

Others may chime in but it seems like a reasonable Bioconductor package.

Please look in the Software biocViews.  Probably StatsticalMethods and 
Classification sound appropriate.  We can add additional biocViews if you 
proceed with the Bioconductor submission.  It would also seem reasonable to add 
a miCLIP2 biocView perhaps under Software -> Technology.

Cheers,



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 You Zhou 

Sent: Monday, February 22, 2021 3:49 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] About developing package

Dear all,

I have a question regarding the package development. We will publish a paper 
(https://www.biorxiv.org/content/10.1101/2020.12.20.423675v1) soon, and in this 
paper we develop a machine learning classifier for identify the m6A signals out 
of miCLIP2 data. Now I would like to turn the machine learning model with some 
necessary functions into a package. I was wondering whether Bioconductor could 
also accept a package like this? And if the answer is yes, which biocViews 
section should I go?

Thanks and kind regards,
You




[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1-VwW6qdS1XrQRxPEdHc1dKryvphTY2w_XpoGyS5mOpjuoRA0wJ73ikFDbzNEW7OC-LJvmAt_EdDugKQWi8BWcftnlNNntsmephOb1Qrxd0mcNXygFKqO3YCKzHq2Ygaxdpyj74t51xMPNqazKHRCx05L615etwYI2en8UHWOraO_48LbRJm0wNWWQ6bfAMzTDVtUV8aCDZ0cWGDdU_hgDSicszewL5uGTzvW_YRYdv6k7J6psoDV_QFVbCxoBRWq0DzxL9AseuPdIF4qeA-_CZf2FdHHuW4SGcgKGggWLKj2lgRKo-chh0cdhVIcCGlY/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

Re: [R-pkg-devel] Citation in DESCRIPTION file

2021-02-22 Thread Sebastian Meyer

Am 22.02.21 um 11:06 schrieb Knut Krueger:
> I was suggested: "A citation in the Description file is typically a good
> idea because people can think  whether your package is appropriate
> before reading all docs and installing the package, just from reading
> the CRAN overview page."
> 
> but I do not find hints how to implement the doi and the references in
> the DESCRIPTION file
> 
> Thank's in advance Knut


If you are submitting to CRAN, the relevant guidelines can be found in
the repository policies at
https://CRAN.R-project.org/web/packages/policies.html:

> Citations in the ‘Description’ field of the DESCRIPTION file should be in 
> author-year style, followed by a DOI or ISBN for published materials, or a 
> URL otherwise. Preferably, the year and identifier would be enclosed, 
> respectively, in parentheses and angle brackets. 


Example: Einstein et al. (1935) .


Best regards,

Sebastian Meyer

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

Re: [R-pkg-devel] Support for several versions of another package

2021-02-22 Thread Georgi Boshnakov

> This works for a renamed function. But if the function also changes 
> arguments, it doesn't work anymore.

Indeed, didn't think about that. I forgot to mention also that the NOTE appears 
only with the old version of the dependency, so it disappears after a couple of 
years. 

FWIW, CRAN accepts a package with that note.

Georgi

-Original Message-
From: Iñaki Ucar  
Sent: 22 February 2021 10:51
To: Georgi Boshnakov 
Cc: Duncan Murdoch ; Gábor Csárdi 
; R Package Development 
Subject: Re: [R-pkg-devel] Support for several versions of another package

On Mon, 22 Feb 2021 at 11:46, Georgi Boshnakov 
 wrote:
>
> One way to avoid burying the conditional deep into the code is to put it in 
> .onLoad(). When the author of a dependency informed me that from v.2.0.0  
> "as.polylist would be renamed I put the following in .onLoad():
>
> .onLoad <- function(libname, pkgname){
> if (utils::packageVersion("PolynomF") >= "2.0.0") {
> assign("as.polylist", PolynomF::as_polylist, envir = topenv())
> }
> ## add other renamed functions here
>
> NULL
> }
>
> This still raises a NOTE but is a change in a single place.

This works for a renamed function. But if the function also changes arguments, 
it doesn't work anymore. The only alternative I can think of is to 
getFromNamespace() to bypass the check. But it's hackish.

Iñaki

> Georgi Boshnakov
>
>
> -Original Message-
> From: R-package-devel  On 
> Behalf Of Duncan Murdoch
> Sent: 21 February 2021 19:43
> To: Gábor Csárdi 
> Cc: R Package Development 
> Subject: Re: [R-pkg-devel] Support for several versions of another 
> package
>
> On 21/02/2021 12:17 p.m., Gábor Csárdi wrote:
> > On Sun, Feb 21, 2021 at 6:05 PM Duncan Murdoch  
> > wrote:
> >>
> >> On 21/02/2021 9:47 a.m., Iñaki Ucar wrote:
> >>> Hi,
> >>>
> >>> Let's say that pkgA uses pkgB::function1. Then, version 2 of pkgB 
> >>> removes function1 and exports function2 for the same functionality.
> >>> So pkgA does something along these lines:
> >>>
> >>> if (utils::packageVersion("pkgB") < 2) {
> >>> pkgB::function1()
> >>> } else {
> >>> pkgB::function2()
> >>> }
> >>>
> >>> I'd say that there's nothing wrong with this code, and yet checks 
> >>> will complain about "missing o unexported object" in pkgB, for 
> >>> either
> >>> function1 or function2 depending on the version of pkgB that is 
> >>> available.
> >>>
> >>> Isn't this a false positive? Or is there a better way of doing this?
> >>
> >> I'd agree it's a false positive, but I wouldn't expect the check 
> >> code to be able to interpret the logic.
> >>
> >> A better way could be to handle it in your NAMESPACE file.  For 
> >> example, this is legal (if nonsense):
> >>
> >> if (utils::packageVersion("rgl") < "0.99.0") {
> >>  importFrom(rgl, bar = somethingNonexistent) } else
> >>  importFrom(rgl, bar = persp3d)
> >
> > Isn't this evaluated at install time? I think it is, and then you 
> > would need to potentially reinstall the package when you update rgl, 
> > which is not quite ideal, because it is easy to miss it, and then 
> > you'll get runtime errors.
>
> Yes, you're right, I didn't know that.  That's not as useful.
>
> Duncan Murdoch
>
> __
> 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



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

Re: [R-pkg-devel] Support for several versions of another package

2021-02-22 Thread Gábor Csárdi

On Sun, Feb 21, 2021 at 3:47 PM Iñaki Ucar  wrote:
>
> Hi,
>
> Let's say that pkgA uses pkgB::function1. Then, version 2 of pkgB
> removes function1 and exports function2 for the same functionality. So
> pkgA does something along these lines:
>
> if (utils::packageVersion("pkgB") < 2) {
>   pkgB::function1()
> } else {
>   pkgB::function2()
> }
>
> I'd say that there's nothing wrong with this code, and yet checks will
> complain about "missing o unexported object" in pkgB, for either
> function1 or function2 depending on the version of pkgB that is
> available.
>
> Isn't this a false positive? Or is there a better way of doing this?

I would just do this:

if (utils::packageVersion("pkgB") < 2) {
  getExportedValue("pkgB", "function1")()
} else {
  getExportedValue("pkgB", "function2")()
}

I would think that the check is fine with this, although I haven't tried.

Gabor

> Regards,
> --
> Iñaki Úcar
>
> __
> 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] Support for several versions of another package

2021-02-22 Thread Iñaki Ucar

On Mon, 22 Feb 2021 at 11:46, Georgi Boshnakov
 wrote:
>
> One way to avoid burying the conditional deep into the code is to put it in 
> .onLoad(). When the author of a dependency informed me that from v.2.0.0  
> "as.polylist would be renamed I put the following in .onLoad():
>
> .onLoad <- function(libname, pkgname){
> if (utils::packageVersion("PolynomF") >= "2.0.0") {
> assign("as.polylist", PolynomF::as_polylist, envir = topenv())
> }
> ## add other renamed functions here
>
> NULL
> }
>
> This still raises a NOTE but is a change in a single place.

This works for a renamed function. But if the function also changes
arguments, it doesn't work anymore. The only alternative I can think
of is to getFromNamespace() to bypass the check. But it's hackish.

Iñaki

> Georgi Boshnakov
>
>
> -Original Message-
> From: R-package-devel  On Behalf Of 
> Duncan Murdoch
> Sent: 21 February 2021 19:43
> To: Gábor Csárdi 
> Cc: R Package Development 
> Subject: Re: [R-pkg-devel] Support for several versions of another package
>
> On 21/02/2021 12:17 p.m., Gábor Csárdi wrote:
> > On Sun, Feb 21, 2021 at 6:05 PM Duncan Murdoch  
> > wrote:
> >>
> >> On 21/02/2021 9:47 a.m., Iñaki Ucar wrote:
> >>> Hi,
> >>>
> >>> Let's say that pkgA uses pkgB::function1. Then, version 2 of pkgB
> >>> removes function1 and exports function2 for the same functionality.
> >>> So pkgA does something along these lines:
> >>>
> >>> if (utils::packageVersion("pkgB") < 2) {
> >>> pkgB::function1()
> >>> } else {
> >>> pkgB::function2()
> >>> }
> >>>
> >>> I'd say that there's nothing wrong with this code, and yet checks
> >>> will complain about "missing o unexported object" in pkgB, for
> >>> either
> >>> function1 or function2 depending on the version of pkgB that is
> >>> available.
> >>>
> >>> Isn't this a false positive? Or is there a better way of doing this?
> >>
> >> I'd agree it's a false positive, but I wouldn't expect the check code
> >> to be able to interpret the logic.
> >>
> >> A better way could be to handle it in your NAMESPACE file.  For
> >> example, this is legal (if nonsense):
> >>
> >> if (utils::packageVersion("rgl") < "0.99.0") {
> >>  importFrom(rgl, bar = somethingNonexistent) } else
> >>  importFrom(rgl, bar = persp3d)
> >
> > Isn't this evaluated at install time? I think it is, and then you
> > would need to potentially reinstall the package when you update rgl,
> > which is not quite ideal, because it is easy to miss it, and then
> > you'll get runtime errors.
>
> Yes, you're right, I didn't know that.  That's not as useful.
>
> Duncan Murdoch
>
> __
> 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



-- 
Iñaki Úcar

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

Re: [R-pkg-devel] Support for several versions of another package

2021-02-22 Thread Georgi Boshnakov

One way to avoid burying the conditional deep into the code is to put it in 
.onLoad(). When the author of a dependency informed me that from v.2.0.0  
"as.polylist would be renamed I put the following in .onLoad():

.onLoad <- function(libname, pkgname){
if (utils::packageVersion("PolynomF") >= "2.0.0") {
assign("as.polylist", PolynomF::as_polylist, envir = topenv())
}
## add other renamed functions here

NULL
}

This still raises a NOTE but is a change in a single place.


Georgi Boshnakov


-Original Message-
From: R-package-devel  On Behalf Of 
Duncan Murdoch
Sent: 21 February 2021 19:43
To: Gábor Csárdi 
Cc: R Package Development 
Subject: Re: [R-pkg-devel] Support for several versions of another package

On 21/02/2021 12:17 p.m., Gábor Csárdi wrote:
> On Sun, Feb 21, 2021 at 6:05 PM Duncan Murdoch  
> wrote:
>>
>> On 21/02/2021 9:47 a.m., Iñaki Ucar wrote:
>>> Hi,
>>>
>>> Let's say that pkgA uses pkgB::function1. Then, version 2 of pkgB 
>>> removes function1 and exports function2 for the same functionality. 
>>> So pkgA does something along these lines:
>>>
>>> if (utils::packageVersion("pkgB") < 2) {
>>> pkgB::function1()
>>> } else {
>>> pkgB::function2()
>>> }
>>>
>>> I'd say that there's nothing wrong with this code, and yet checks 
>>> will complain about "missing o unexported object" in pkgB, for 
>>> either
>>> function1 or function2 depending on the version of pkgB that is 
>>> available.
>>>
>>> Isn't this a false positive? Or is there a better way of doing this?
>>
>> I'd agree it's a false positive, but I wouldn't expect the check code 
>> to be able to interpret the logic.
>>
>> A better way could be to handle it in your NAMESPACE file.  For 
>> example, this is legal (if nonsense):
>>
>> if (utils::packageVersion("rgl") < "0.99.0") {
>>  importFrom(rgl, bar = somethingNonexistent) } else
>>  importFrom(rgl, bar = persp3d)
> 
> Isn't this evaluated at install time? I think it is, and then you 
> would need to potentially reinstall the package when you update rgl, 
> which is not quite ideal, because it is easy to miss it, and then 
> you'll get runtime errors.

Yes, you're right, I didn't know that.  That's not as useful.

Duncan Murdoch

__
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: [Rd] sprintf, check number of parameters

2021-02-22 Thread Duncan Murdoch

This is ugly, but I think it's legal, and it doesn't trigger a warning: 
 output unused parameters as zero-length strings:


 msnx(T0, mask = '%1$.1f (SD=%2$.1f)%3$.0s%4$.0s')

Perhaps an example using %.0s could be included to show how to skip a value.

Duncan Murdoch

On 22/02/2021 5:06 a.m., Tomas Kalibera wrote:

Dear Matthias,

On 2/6/21 2:11 PM, Matthias Gondan wrote:

Dear developers,

This is a follow-up from an earlier mail about warnings of unused arguments in 
sprintf:

1. This should obviously raise an error (and it does):
sprintf('%i %i', 1)
Fehler in sprintf("%i %i", 1) : zu wenig Argumente [= too few arguments]

2. This should, in my opinion, raise a warning about an unused argument (and I 
think it does in now R-devel):
sprintf('%i', 1, 2)

yes, it does.

3. From the conversation below, it seems that this also raises a warning (in 
R-devel):
sprintf('%1$i', 1, 2)

yes, it does as well

I think that one should be suppressed. When I reported this a few months ago, I 
didn’t really have a use case for (3), but now I think I have found something. 
Suppose I have a function that calculates some descriptive statistics, mean, 
sd, available cases, missings, something like the one below:

msnx = function(x, mask='%1$.1f (SD=%2$.1f, n=%3$i, NA=%4$i)')
{
m = mean(x, na.rm=TRUE)
s = sd(x, na.rm=TRUE)
n = sum(!is.na(x))
na = sum(is.na(x))

sprintf(mask, m, s, n, na)

}

The mask is meant to help formatting it a bit.

msnx(T0)
[1] "30.7 (SD=4.7, n=104, NA=0)"

Now I want a „less detailed“ summary, so I invoke the function with something 
like

msnx(T0, mask='%1$.1f (SD=%2$.1f)')
[1] "30.7 (SD=4.7)"

In my opinion, in the last example, sprintf should not raise the warning in (2) 
if all arguments in the mask are „dollared“. I am still a bit unsure since the 
example uses a function that calculate things that aren’t being used (n and 
na), and this could be considered bad programming style. But there might be 
other use cases, and it is, nevertheless, a deliberate choice to skip arguments 
3$ and 4$.


Thanks for the example. I am sympathetic with your concerns about the
programming style in it: the caller needs to know exactly how "mask"
will be used, that it would be in a call to sprintf() and what would be
the indices of the arguments.

The warning has been introduced a while ago and there has not been any
report yet that it would break existing good style code (particularly
CRAN packages have been tested extensively), which indicates that
currently the R code base does not rely on unused $- arguments.

It is hence I think wise to keep the warning to prevent R code base from
relying on that in the future, because gcc/clang already warn on unused
$-arguments. Not only that gcc developers must have been thinking hard
about the same thing before us getting to this conclusion: $- arguments
are a POSIX extension and gcc/clang are the key compilers for POSIX
systems, so it is safer to abide by their rules. In principle POSIX may
mandate that $- arguments are used explicitly in the future (now it is
rather vague, it seems unused are fine only when last), and even if not,
deviations from gcc/clang could cause confusion for applications and
developers using both C/C++ and R.

Best
Tomas





Best wishes,

Matthias



Dear Matthias,

thanks for the suggestion, R-devel now warns on unused arguments by
format (both numbered and un-numbered). It seems that the new warning is
useful, often it finds cases when arguments were accidentally passed to
sprintf but had been meant for a different function.

R allows combining both numbered and un-numbered references in a single
format, even though it may be better to avoid and POSIX does not allow
that.

Best
Tomas

On 9/20/20 1:03 PM, Matthias Gondan wrote:

Dear R developers,

I am wondering if this should raise an error or a warning.


sprintf('%.f, %.f', 1, 2, 3)

[1] "1, 2"

I am aware that R has „numbered“ sprintf arguments (sprintf('%1$.f', …), and in 
that case, omissing of specific arguments may be intended. But in the usual 
syntax, omission of an argument is probably a mistake.

Thank you for your consideration.

Best wishes,

Matthias

[[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



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

Re: [Rd] sprintf, check number of parameters

2021-02-22 Thread Tomas Kalibera


Dear Matthias,

On 2/6/21 2:11 PM, Matthias Gondan wrote:

Dear developers,

This is a follow-up from an earlier mail about warnings of unused arguments in 
sprintf:

1. This should obviously raise an error (and it does):
sprintf('%i %i', 1)
Fehler in sprintf("%i %i", 1) : zu wenig Argumente [= too few arguments]

2. This should, in my opinion, raise a warning about an unused argument (and I 
think it does in now R-devel):
sprintf('%i', 1, 2)

yes, it does.

3. From the conversation below, it seems that this also raises a warning (in 
R-devel):
sprintf('%1$i', 1, 2)

yes, it does as well

I think that one should be suppressed. When I reported this a few months ago, I 
didn’t really have a use case for (3), but now I think I have found something. 
Suppose I have a function that calculates some descriptive statistics, mean, 
sd, available cases, missings, something like the one below:

msnx = function(x, mask='%1$.1f (SD=%2$.1f, n=%3$i, NA=%4$i)')
{
   m = mean(x, na.rm=TRUE)
   s = sd(x, na.rm=TRUE)
   n = sum(!is.na(x))
   na = sum(is.na(x))
   
   sprintf(mask, m, s, n, na)

}

The mask is meant to help formatting it a bit.

msnx(T0)
[1] "30.7 (SD=4.7, n=104, NA=0)"

Now I want a „less detailed“ summary, so I invoke the function with something 
like

msnx(T0, mask='%1$.1f (SD=%2$.1f)')
[1] "30.7 (SD=4.7)"

In my opinion, in the last example, sprintf should not raise the warning in (2) 
if all arguments in the mask are „dollared“. I am still a bit unsure since the 
example uses a function that calculate things that aren’t being used (n and 
na), and this could be considered bad programming style. But there might be 
other use cases, and it is, nevertheless, a deliberate choice to skip arguments 
3$ and 4$.


Thanks for the example. I am sympathetic with your concerns about the 
programming style in it: the caller needs to know exactly how "mask" 
will be used, that it would be in a call to sprintf() and what would be 
the indices of the arguments.


The warning has been introduced a while ago and there has not been any 
report yet that it would break existing good style code (particularly 
CRAN packages have been tested extensively), which indicates that 
currently the R code base does not rely on unused $- arguments.


It is hence I think wise to keep the warning to prevent R code base from 
relying on that in the future, because gcc/clang already warn on unused 
$-arguments. Not only that gcc developers must have been thinking hard 
about the same thing before us getting to this conclusion: $- arguments 
are a POSIX extension and gcc/clang are the key compilers for POSIX 
systems, so it is safer to abide by their rules. In principle POSIX may 
mandate that $- arguments are used explicitly in the future (now it is 
rather vague, it seems unused are fine only when last), and even if not, 
deviations from gcc/clang could cause confusion for applications and 
developers using both C/C++ and R.


Best
Tomas





Best wishes,

Matthias



Dear Matthias,

thanks for the suggestion, R-devel now warns on unused arguments by
format (both numbered and un-numbered). It seems that the new warning is
useful, often it finds cases when arguments were accidentally passed to
sprintf but had been meant for a different function.

R allows combining both numbered and un-numbered references in a single
format, even though it may be better to avoid and POSIX does not allow
that.

Best
Tomas

On 9/20/20 1:03 PM, Matthias Gondan wrote:

Dear R developers,

I am wondering if this should raise an error or a warning.


sprintf('%.f, %.f', 1, 2, 3)

[1] "1, 2"

I am aware that R has „numbered“ sprintf arguments (sprintf('%1$.f', …), and in 
that case, omissing of specific arguments may be intended. But in the usual 
syntax, omission of an argument is probably a mistake.

Thank you for your consideration.

Best wishes,

Matthias

[[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

[Bioc-devel] About developing package

2021-02-22 Thread You Zhou

Dear all,

I have a question regarding the package development. We will publish a paper 
(https://www.biorxiv.org/content/10.1101/2020.12.20.423675v1) soon, and in this 
paper we develop a machine learning classifier for identify the m6A signals out 
of miCLIP2 data. Now I would like to turn the machine learning model with some 
necessary functions into a package. I was wondering whether Bioconductor could 
also accept a package like this? And if the answer is yes, which biocViews 
section should I go?

Thanks and kind regards,
You




[[alternative HTML version deleted]]

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

[Rd] Apple M1 CRAN checks

2021-02-22 Thread Travers Ching

I noticed CRAN is now doing checks against Apple M1, and some packages are
failing including a dependency I use.

Is building on M1 now a requirement, or can the check be ignored? If it's a
requirement, how can one test it out?

Travers

[[alternative HTML version deleted]]

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

Re: [Rd] Apple M1 CRAN checks

Re: [Rd] Apple M1 CRAN checks

Re: [R-pkg-devel] FW: CRAN submission RIBMDB 1.0-21

[R-pkg-devel] FW: CRAN submission RIBMDB 1.0-21

[R-pkg-devel] Unfixed error on cran submission: r-oldrel-macos-x86_64 ERROR

Re: [Rd] surprised matrix (1:256, 8, 8) doesn't cause error/warning

Re: [R-pkg-devel] Citation in DESCRIPTION file

[Bioc-devel] Bioconductor Developers Forum - 25th February

Re: [R-pkg-devel] Two compile questions

Re: [Bioc-devel] How to change the name of a package on Bioconductor

[R-pkg-devel] Citation in DESCRIPTION file

Re: [R-pkg-devel] Citation in DESCRIPTION file

Re: [R-pkg-devel] Support for several versions of another package

Re: [Bioc-devel] About developing package

Re: [R-pkg-devel] Citation in DESCRIPTION file

Re: [R-pkg-devel] Support for several versions of another package

Re: [R-pkg-devel] Support for several versions of another package

Re: [R-pkg-devel] Support for several versions of another package

Re: [R-pkg-devel] Support for several versions of another package

Re: [Rd] sprintf, check number of parameters

Re: [Rd] sprintf, check number of parameters

[Bioc-devel] About developing package

[Rd] Apple M1 CRAN checks

23 matches

Site Navigation

Mail list logo

Footer information