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

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

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