[Rd] depending on orphaned packages?

[Ben Bolker]

SuppDists is orphaned on CRAN (and has been since 2013).

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

 Oddly, the simulate method for the inverse.gaussian family
[inverse.gaussian()$simulate] depends (in a loose sense) on SuppDists
(it fails if the SuppDists namespace is not available:

if (!requireNamespace("SuppDists", quietly = TRUE))
stop("need CRAN package 'SuppDists' for simulation from the
'inverse.gaussian' family")


  The statmod package also implements inverse gaussian d/p/q/r functions
.  It is
lightweight (depends on R >= 3.0.0, imports only base packages [stats
and graphics]) and has been around for a long time (archived versions on
CRAN go back to 2003).

  Would it make sense to replace the call to SuppDists::rinvGauss with a
corresponding call to statmod::rinvgauss ?  Would a patch be considered?

  Ben Bolker

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

Re: [R-pkg-devel] Why doesn't R CMD check warn that globalVariables() is undefined/not imported?

[Henrik Bengtsson]

On Tue, Sep 24, 2019 at 11:13 AM Gábor Csárdi  wrote:
>
> I believe that this is because if it is outside of a function, then it
> runs at INSTALL time, and codetools checks the installed code, i.e.
> the function objects typically, and the checks never see the
> globalVariables() call.

That would make sense.  Would you say this is a false negative for 'R
CMD check', that is, should it ideally warn about this?

Personally, I argue that one should use:

utils::globalVariables(...)

or

globalVariables(...)
NAMESPACE: importFrom(utils, globalVariables)

/Henrik

>
> Gabor
>
> On Tue, Sep 24, 2019 at 7:08 PM Henrik Bengtsson
>  wrote:
> >
> > 'R CMD check' will give a warning that 'speed' is an unknown variable in:
> >
> >   low_speeds <- function(limit) {
> > subset(datasets::cars, speed <= limit)
> >   }
> >
> > We can tell 'R CMD check' that 'speed' is a false positive by
> > declaring it a "global" variable.  This can be done, by:
> >
> >   low_speeds <- function(limit) {
> > subset(datasets::cars, speed <= limit)
> >   }
> >   utils::globalVariables("speed")
> >
> > So, far so good. But, why doesn't 'R CMD check' complain about
> > 'globalVariables' not being defined if we use
> >
> >   globalVariables("speed")
> >
> > without utils::* and without having an importFrom("utils",
> > "globalVariables") in the NAMESPACE?
> >
> > For what it's worth, if I add a globalVariables() inside a function
> > definition, e.g.
> >
> >   low_speeds <- function(limit) {
> > globalVariables("speed")
> > subset(datasets::cars, speed <= limit)
> >   }
> >   globalVariables("speed")
> >
> > then 'R CMD check' will indeed complain about that inner globalVariables():
> >
> > $ R --vanilla CMD check teeny_0.1.0.tar.gz
> > * using log directory ‘/home/hb/repositories/teeny.Rcheck’
> > * using R version 3.6.1 (2019-07-05)
> > * using platform: x86_64-pc-linux-gnu (64-bit)
> > [...]
> > * checking R code for possible problems ... NOTE
> > low_speeds: no visible global function definition for ‘globalVariables’
> > Undefined global functions or variables:
> >   globalVariables
> > Consider adding
> >   importFrom("utils", "globalVariables")
> > to your NAMESPACE file.
> >
> > Is this an oversight in R CMD check, or is it implicit that the
> > 'utils' package is attached when installing and checking packages and
> > we can use 'utils' objects at the top level of a package?
> >
> > Thanks,
> >
> > Henrik
> >
> > __
> > 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-pkg-devel] Resubmitting after a few days

[Roy Mendelssohn - NOAA Federal via R-package-devel]

Hi All:

A few days ago I  had to resubmit because an external URL I was using in my 
vignette changed and the nightly builds were issuing warnings.  This morning a 
user reported a bug.  I have the fix and a new version,  but the test machines, 
 and I suppose it will also be true of CRAN,  are unhappy about the interval 
since last submit.  Should I just submit the new version anyway with a note in 
cram-comments that this is a bug fix.

Thanks,

-Roy

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

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

Re: [R-pkg-devel] Why doesn't R CMD check warn that globalVariables() is undefined/not imported?

[Gábor Csárdi]

I believe that this is because if it is outside of a function, then it
runs at INSTALL time, and codetools checks the installed code, i.e.
the function objects typically, and the checks never see the
globalVariables() call.

Gabor

On Tue, Sep 24, 2019 at 7:08 PM Henrik Bengtsson
 wrote:
>
> 'R CMD check' will give a warning that 'speed' is an unknown variable in:
>
>   low_speeds <- function(limit) {
> subset(datasets::cars, speed <= limit)
>   }
>
> We can tell 'R CMD check' that 'speed' is a false positive by
> declaring it a "global" variable.  This can be done, by:
>
>   low_speeds <- function(limit) {
> subset(datasets::cars, speed <= limit)
>   }
>   utils::globalVariables("speed")
>
> So, far so good. But, why doesn't 'R CMD check' complain about
> 'globalVariables' not being defined if we use
>
>   globalVariables("speed")
>
> without utils::* and without having an importFrom("utils",
> "globalVariables") in the NAMESPACE?
>
> For what it's worth, if I add a globalVariables() inside a function
> definition, e.g.
>
>   low_speeds <- function(limit) {
> globalVariables("speed")
> subset(datasets::cars, speed <= limit)
>   }
>   globalVariables("speed")
>
> then 'R CMD check' will indeed complain about that inner globalVariables():
>
> $ R --vanilla CMD check teeny_0.1.0.tar.gz
> * using log directory ‘/home/hb/repositories/teeny.Rcheck’
> * using R version 3.6.1 (2019-07-05)
> * using platform: x86_64-pc-linux-gnu (64-bit)
> [...]
> * checking R code for possible problems ... NOTE
> low_speeds: no visible global function definition for ‘globalVariables’
> Undefined global functions or variables:
>   globalVariables
> Consider adding
>   importFrom("utils", "globalVariables")
> to your NAMESPACE file.
>
> Is this an oversight in R CMD check, or is it implicit that the
> 'utils' package is attached when installing and checking packages and
> we can use 'utils' objects at the top level of a package?
>
> Thanks,
>
> Henrik
>
> __
> 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-pkg-devel] Why doesn't R CMD check warn that globalVariables() is undefined/not imported?

[Henrik Bengtsson]

'R CMD check' will give a warning that 'speed' is an unknown variable in:

  low_speeds <- function(limit) {
subset(datasets::cars, speed <= limit)
  }

We can tell 'R CMD check' that 'speed' is a false positive by
declaring it a "global" variable.  This can be done, by:

  low_speeds <- function(limit) {
subset(datasets::cars, speed <= limit)
  }
  utils::globalVariables("speed")

So, far so good. But, why doesn't 'R CMD check' complain about
'globalVariables' not being defined if we use

  globalVariables("speed")

without utils::* and without having an importFrom("utils",
"globalVariables") in the NAMESPACE?

For what it's worth, if I add a globalVariables() inside a function
definition, e.g.

  low_speeds <- function(limit) {
globalVariables("speed")
subset(datasets::cars, speed <= limit)
  }
  globalVariables("speed")

then 'R CMD check' will indeed complain about that inner globalVariables():

$ R --vanilla CMD check teeny_0.1.0.tar.gz
* using log directory ‘/home/hb/repositories/teeny.Rcheck’
* using R version 3.6.1 (2019-07-05)
* using platform: x86_64-pc-linux-gnu (64-bit)
[...]
* checking R code for possible problems ... NOTE
low_speeds: no visible global function definition for ‘globalVariables’
Undefined global functions or variables:
  globalVariables
Consider adding
  importFrom("utils", "globalVariables")
to your NAMESPACE file.

Is this an oversight in R CMD check, or is it implicit that the
'utils' package is attached when installing and checking packages and
we can use 'utils' objects at the top level of a package?

Thanks,

Henrik

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

Re: [Rd] '==' operator: inconsistency in data.frame(...) == NULL

[Hilmar Berger]

Dear Martin,

thanks a lot for looking into this. Of course you were right that the 
fix was not complete - I apologize for not having tested what I believed 
to be the solution.


My comments on the S4 classes seemed to stem from a misunderstanding on 
my side. I now believe to understand that S4 classes that inherit from R 
base object types might dispatch Ops for the same object types.


If the base object value of such S4 classes is unset and therefore 
empty, this empty value will be passed on to e.g. Ops.data.frame where 
it would trigger the same issue as e.g. logical(0).


setClass("MyClass", slots = list(x="numeric", label="character"), 
contains = "numeric")

a = new("MyClass", x=3, label="FOO")
a@.Data

> logical(0)

a == data.frame(a=1:3)
# error

I understand that this is all as expected and the error should most 
likely disappear with the fix you submitted for other 0-extent cases.


Thanks again and best regards,

Hilmar

Am 18/09/2019 um 11:29 schrieb Martin Maechler:

Martin Maechler
 on Wed, 18 Sep 2019 10:35:42 +0200 writes:

   > Hilmar Berger
   > on Sat, 14 Sep 2019 13:31:27 +0200 writes:

>> Dear all,
>> I did some more tests regarding the == operator in Ops.data.frame 
(see
>> below).  All tests done in R 3.6.1 (x86_64-w64-mingw32).

>> I find that errors are thrown also when comparing a zero length
>> data.frame to atomic objects with length>0 which should be a valid 
case
>> according to the documentation. This can be traced to a check in the
>> last line of Ops.data.frame which tests for the presence of an empty
>> result value (i.e. list() ) but does not handle a list of empty 
values
>> (i.e. list(logical(0))) which in fact is generated in those cases.

>> There  is a simple fix (see also below).

 > I'm pretty sure what you write above is wrong:  For some reason
 > you must have changed more in your own version of Ops.data.frame :

 > Because there's a line

 > value <- unlist(value, ...)

 > there, value is *not*  list(logical(0)) there, but rather  logical(0)
 > and then indeed, your proposed line change (at the end of Ops.data.frame)
 > has no effect for the examples you give.

On the other hand, there *is* a simple "fix" at the end of
Ops.data.frame()  which makes all your examples "work" (i.e. not
give an error), namely

--

@@ -1685,7 +1684,7 @@
  else { ## 'Logic' ("&","|")  and  'Compare' ("==",">","<","!=","<=",">=") 
:
value <- unlist(value, recursive = FALSE, use.names = FALSE)
matrix(if(is.null(value)) logical() else value,
-  nrow = nr, dimnames = list(rn,cn))
+  nrow = nr, ncol = length(cn), dimnames = list(rn,cn))
  }

--

i.e., explicitly specifying 'ncol' compatibly with the column names.
However, I guess that this change would *not* signal errors
where it *should* and so am *not* (yet?) proposing to "do" it.

Another remark, on  S4  which you've raised several times:
As you may know that the 'Matrix' package (part of every
"regular" R installation) uses S4 "everywhere" and it does
define many methods for its Matrix classes, all in source file  Matrix/R/Ops.R
the development version (in svn / subversion) being online on R-forge here:

   
https://r-forge.r-project.org/scm/viewvc.php/pkg/Matrix/R/Ops.R?view=markup=matrix

and "of course", there we define S4 group methods for Ops all
the time, and (almost) never S3 ones...
[[but I hope you don't want to start combining data frames
  with Matrix package matrices, now !]]

Martin Maechler
ETH Zurich  and  R Core Team


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

Re: [R-pkg-devel] Require -package.Rd?

[Georgi Boshnakov]

> help(package="utils") shows the index, not utils-package.Rd.

Indeed, I should have run it before emailing, I meant:

package ? utils

which does show "utils-package.Rd" and similarly for other packages. 

'help(topic)' shows a file which contains alias for 'topic'. In the case of 
'help(utils)', fille "utils-package.Rd" has an alias for "utils", so tht is 
shown.

For what it's worth, the index shown by 'help(package = "package")' is very 
useful for html formatted pages, where everything is linked and the links to 
the vignettes appear at the top.   If html is not the default rendering, one 
can use 

help(package = "Matrix", help_type = "html")

 to get this.


Georgi Boshnakov


-Original Message-
From: Viechtbauer, Wolfgang (SP) 
[mailto:wolfgang.viechtba...@maastrichtuniversity.nl] 
Sent: 24 September 2019 14:34
To: Georgi Boshnakov; r-package-devel@r-project.org
Subject: RE: Require -package.Rd?

Hi Georgi,

help(package="utils") shows the index, not utils-package.Rd.

help(utils) shows utils-package.Rd.

Best,
Wolfgang

-Original Message-
From: Georgi Boshnakov [mailto:georgi.boshna...@manchester.ac.uk] 
Sent: Tuesday, 24 September, 2019 15:02
To: Viechtbauer, Wolfgang (SP); r-package-devel@r-project.org
Subject: RE: Require -package.Rd?

It is worth noting that 

help(package="")

shows  file -package.Rd, while 

help()

shows topic "package".

Topic -package.Rd is also printed at the top of the pdf manual, while 
package.Rd follows the alphabetical ordering of the remaining topics. It is 
unfortunate that Hadley Wickham's tools (at least 'pkgdown') recommend and use 
.Rd, instead of -package.Rd as overall package description. 

Georgi Boshnakov

-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Viechtbauer, Wolfgang (SP)
Sent: 24 September 2019 13:16
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Require -package.Rd?

Hi All,

When starting to work with an unfamiliar package, one might typically look for 
vignettes, a paper/book accompanying the package, a package website, and of 
course the help files themselves, but

help(package="")

is often not so useful -- such a listing of functions (with titles) might not 
clarify what the main 'workhorses' of the package are and how to get started. 
Personally, the first thing I do is try:

help()

in the hopes that the package author(s) have created a -package.Rd 
file to get new users started (or to point them to appropriate places to get 
going). In my experience, if such a package help file is available, it is 
tremendously useful.

Unfortunately, many packages do not provide a -package.Rd file. I am 
curious how others and CRAN members would feel about making this a requirement 
(not retrospectively, but at least for new / resubmissions).

Best,
Wolfgang

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

Re: [R-pkg-devel] Require -package.Rd?

[David Hugh-Jones]

I would be in favour. I actually used R for several years before figuring
out that the vignette was usually where the useful introduction was. Until
then I was like “R help is way too technical”

On Tue, 24 Sep 2019 at 13:26, Joris Meys  wrote:

> Dear Dr. Vichtbauer,
>
> I'm not a CRAN member, but I personally think this is a sensible
> requirement. I try to include those in every package myself, even if it's
> only to direct people to a vignette.
>
> That said, I do look for vignettes first when I encounter an unfamiliar
> package actually. That format gives more possibilities for giving a good
> introduction to the package imho.
>
> My humble 2 cents
> Cheers
> Joris
>
> On Tue, Sep 24, 2019 at 2:17 PM Viechtbauer, Wolfgang (SP) <
> wolfgang.viechtba...@maastrichtuniversity.nl> wrote:
>
> > Hi All,
> >
> > When starting to work with an unfamiliar package, one might typically
> look
> > for vignettes, a paper/book accompanying the package, a package website,
> > and of course the help files themselves, but
> >
> > help(package="")
> >
> > is often not so useful -- such a listing of functions (with titles) might
> > not clarify what the main 'workhorses' of the package are and how to get
> > started. Personally, the first thing I do is try:
> >
> > help()
> >
> > in the hopes that the package author(s) have created a
> > -package.Rd file to get new users started (or to point them to
> > appropriate places to get going). In my experience, if such a package
> help
> > file is available, it is tremendously useful.
> >
> > Unfortunately, many packages do not provide a -package.Rd file.
> I
> > am curious how others and CRAN members would feel about making this a
> > requirement (not retrospectively, but at least for new / resubmissions).
> >
> > Best,
> > Wolfgang
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> <
> https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium=gmail=g
> >
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Require -package.Rd?

[Georgi Boshnakov]

It is worth noting that 

help(package="")

shows  file -package.Rd, while 

help()

shows topic "package".

Topic -package.Rd is also printed at the top of the pdf manual, while 
package.Rd follows the alphabetical ordering of the remaining topics. It is 
unfortunate that Hadley Wickham's tools (at least 'pkgdown') recommend and use 
.Rd, instead of -package.Rd as overall package description. 

Georgi Boshnakov



-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Viechtbauer, Wolfgang (SP)
Sent: 24 September 2019 13:16
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Require -package.Rd?

Hi All,

When starting to work with an unfamiliar package, one might typically look for 
vignettes, a paper/book accompanying the package, a package website, and of 
course the help files themselves, but

help(package="")

is often not so useful -- such a listing of functions (with titles) might not 
clarify what the main 'workhorses' of the package are and how to get started. 
Personally, the first thing I do is try:

help()

in the hopes that the package author(s) have created a -package.Rd 
file to get new users started (or to point them to appropriate places to get 
going). In my experience, if such a package help file is available, it is 
tremendously useful.

Unfortunately, many packages do not provide a -package.Rd file. I am 
curious how others and CRAN members would feel about making this a requirement 
(not retrospectively, but at least for new / resubmissions).

Best,
Wolfgang

__
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] Require -package.Rd?

[Viechtbauer, Wolfgang (SP)]

Hi Dirk,

Point well taken, but the same goes for many other CRAN requirements. For 
example, I can create totally useless help files for all the functions that 
pass all checks. Just because some will try to skirt around a requirement 
doesn't mean it's a useless requirement. In fact, the point of such 
requirements is to promote good practices and I would like to believe that most 
package authors would make an honest effort to create a somewhat useful 
-package.Rd file, even (as Joris pointed out) it is essentially just a 
pointer to the vignette(s) (which is also useful).

Best,
Wolfgang

-Original Message-
From: Dirk Eddelbuettel [mailto:e...@debian.org] 
Sent: Tuesday, 24 September, 2019 14:39
To: joris.m...@ugent.be
Cc: Viechtbauer, Wolfgang (SP); r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Require -package.Rd?

Wolfgang, Joris,

This may not necessarily work -- see "Goodhart's Law" [1]

Once you impose something like this, (some) will skirt it with just the
minimum requirement of an (essentially) empty file.  An existing set of
examples is provided by the vignettes of (at least) one developer which each
consist (or consisted ?) of just a single line with a hyperlink to the
corresponding package website.  Passes the letter of the law (hey, look, a
vignette) and all possible tests, but clearly violates the spirit of the law
that documentation and package should be self-contained (and no, connectivity
should not be assumed).

Moral persuasion may be better. We should encourage best practices and
highlight packages that follow them.

Dirk


[1] https://en.wikipedia.org/wiki/Goodhart%27s_law

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

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

Re: [R-pkg-devel] Require -package.Rd?

[Dirk Eddelbuettel]

Wolfgang, Joris,

This may not necessarily work -- see "Goodhart's Law" [1]

Once you impose something like this, (some) will skirt it with just the
minimum requirement of an (essentially) empty file.  An existing set of
examples is provided by the vignettes of (at least) one developer which each
consist (or consisted ?) of just a single line with a hyperlink to the
corresponding package website.  Passes the letter of the law (hey, look, a
vignette) and all possible tests, but clearly violates the spirit of the law
that documentation and package should be self-contained (and no, connectivity
should not be assumed).

Moral persuasion may be better. We should encourage best practices and
highlight packages that follow them.

Dirk


[1] https://en.wikipedia.org/wiki/Goodhart%27s_law

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

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

Re: [R-pkg-devel] Require -package.Rd?

[Joris Meys]

Dear Dr. Vichtbauer,

I'm not a CRAN member, but I personally think this is a sensible
requirement. I try to include those in every package myself, even if it's
only to direct people to a vignette.

That said, I do look for vignettes first when I encounter an unfamiliar
package actually. That format gives more possibilities for giving a good
introduction to the package imho.

My humble 2 cents
Cheers
Joris

On Tue, Sep 24, 2019 at 2:17 PM Viechtbauer, Wolfgang (SP) <
wolfgang.viechtba...@maastrichtuniversity.nl> wrote:

> Hi All,
>
> When starting to work with an unfamiliar package, one might typically look
> for vignettes, a paper/book accompanying the package, a package website,
> and of course the help files themselves, but
>
> help(package="")
>
> is often not so useful -- such a listing of functions (with titles) might
> not clarify what the main 'workhorses' of the package are and how to get
> started. Personally, the first thing I do is try:
>
> help()
>
> in the hopes that the package author(s) have created a
> -package.Rd file to get new users started (or to point them to
> appropriate places to get going). In my experience, if such a package help
> file is available, it is tremendously useful.
>
> Unfortunately, many packages do not provide a -package.Rd file. I
> am curious how others and CRAN members would feel about making this a
> requirement (not retrospectively, but at least for new / resubmissions).
>
> Best,
> Wolfgang
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)


tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

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

[R-pkg-devel] Require -package.Rd?

[Viechtbauer, Wolfgang (SP)]

Hi All,

When starting to work with an unfamiliar package, one might typically look for 
vignettes, a paper/book accompanying the package, a package website, and of 
course the help files themselves, but

help(package="")

is often not so useful -- such a listing of functions (with titles) might not 
clarify what the main 'workhorses' of the package are and how to get started. 
Personally, the first thing I do is try:

help()

in the hopes that the package author(s) have created a -package.Rd 
file to get new users started (or to point them to appropriate places to get 
going). In my experience, if such a package help file is available, it is 
tremendously useful.

Unfortunately, many packages do not provide a -package.Rd file. I am 
curious how others and CRAN members would feel about making this a requirement 
(not retrospectively, but at least for new / resubmissions).

Best,
Wolfgang

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

[R-pkg-devel] Package or namespace load failed: undefined symbol

[Sameh M. Abdulah]

Hi,

I am uploading my R package to CRAN. One of the dynamic libraries the package 
requires depends on LAPACKE library which usually integrated with BLAS and 
CBLAS in the same .so file (as I understand). CRAN has OpenBLAS already 
installed on the system. However, this OpenBLAS library does not maintain 
implementation of LAPACKE library. Thus, I have modified my configure file to 
install a standalone OpenBLAS library to use it.

The problem that my installation has successfully passed, however, CRAN fails 
in loading my package giving me this error:

/srv/hornik/tmp/CRAN/exageostatr.Rcheck/exageostatr/lib/libcoreblas.so: 
undefined symbol: LAPACKE_slarfb_work

LAPACKE_slarfb_work is a function defined in the LAPACKE library. I have tried 
to set the PKG_LIBS path to my OpenBLAS lib but again it fails.

Any suggestions?


--Sameh

[[alternative HTML version deleted]]

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

Re: [Rd] What is the best way to loop over an ALTREP vector?

[Romain Francois]

Thanks for these comments. I should alter the blog post or write some follow 
up. 

This was a weekend blog post that only benefited from a short time of research 
research. I’m glad people find it useful, but I’m sure a detailed documentation 
of the features from the authors would be more useful. 

Romain

> Le 24 sept. 2019 à 07:48, Gabriel Becker  a écrit :
> 
> Hi Bob,
> 
> Thanks for sending around the link to that. It looks mostly right and looks
> like a useful onramp. There are a few things to watch out for though (I've
> cc'ed Romain so he's aware of these comments). @romain I hope you taake the
> following comments as they are intended, as help rather than attacks.
> 
> The largest issue I see is that the contract for Get_region is that it
> *populates the
> provided buffer with a copy of the data. *That buffer is expected to be
> safe to destructively modify, shuffle, etc though I don't know if we are
> actually doing that anywhere. As such, if I understand his C++ correctly,
> that Get_region method  is not safe and shouldn't be used.
> 
> The other point is that Dataptr_or_null is not actually *guaranteed *not to
> allocate. The default method returns NULL, but we have no way of preventing
> an allocation in a user-defined method, and probably (?) no easy way of
> detecting that it is occurring before it causes a bug. That said, Romain is
> correct that when you are writing Dataptr_or_null methods you should write
> them so that they don't allocate, generally. Basically your methods for
> Dataptr_or_null shouldn't allocate, but you also should not write code that
> relies on hard assumptions that no one's ever will.
> 
> Also, a small nitpick, R's internal mean function doesn't hit Dataptr, it
> hits either INTEGER_ELT (which really should probably be a
> ITERATE_BY_REGION) or ITERATE_BY_REGION.
> 
> Anyway, I hope that helps.
> ~G
> 
> 
> 
> 
> 
> 
> On Mon, Sep 23, 2019 at 6:12 PM Bob Rudis mailto:b...@rud.is>> 
> wrote:
> 
>> Not sure if you're using just C++ or Rcpp for C++ access but
>> https://purrple.cat/blog/2018/10/14/altrep-and-cpp/ has some tips on
>> using C++ w/ALTREP.
>> 
>>> On Sep 23, 2019, at 3:17 PM, Wang Jiefei  wrote:
>>> 
>>> Sorry for post a lot of things, for the first part of code, I copied my
>> C++
>>> iter macro by mistake(and you can see an explicit type casting). Here is
>>> the macro definition from R_exts/Itermacros.h
>>> 
>>> #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \
>>> 
>>>strt, nfull, expr) do { \
>>> 
>>> *   const** etype *px = DATAPTR_OR_NULL(sx);   *
>> \
>>> 
>>>  if (px != NULL) {  \
>>> 
>>>  R_xlen_t __ibr_n__ = strt + nfull;\
>>> 
>>>  R_xlen_t nb = __ibr_n__;  \
>>> 
>>>  for (R_xlen_t idx = strt; idx < __ibr_n__; idx += nb) {   \
>>> 
>>> expr\
>>> 
>>>   } \
>>> 
>>>  }  \
>>> 
>>>  else ITERATE_BY_REGION_PARTIAL0(sx, px, idx, nb, etype, vtype,
>>> \
>>> 
>>> strt, nfull, expr);\
>>> 
>>>   } while (0)
>>> 
>>> 
>>> Best,
>>> 
>>> Jiefei
>>> 
>>> On Mon, Sep 23, 2019 at 3:12 PM Wang Jiefei  wrote:
>>> 
 Hi Gabriel,
 
 I have tried the macro and found a small issue, it seems like the macro
>> is
 written in C and does an implicit type conversion(const void * to const
>> int
 *), see below. While it is allowed in C, C++ seems not happy with it.
>> Is it
 possible to add an explicit type casting so that it can be compatible
>> with
 both language?
 
 
 #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \
 
strt, nfull, expr) do { \
 
  *const etype *px = (const** etype *)DATAPTR_OR_NULL(sx);  *
 \
 
  if (px != NULL) {  \
 
  R_xlen_t __ibr_n__ = strt + nfull;\
 
  R_xlen_t nb = __ibr_n__;  \
 
  for (R_xlen_t idx = strt; idx < __ibr_n__; idx += nb) {   \
 
 expr\
 
   } \
 
  }  \
 
  else ITERATE_BY_REGION_PARTIAL0(sx, px, idx, nb, etype,
 vtype,   \
 
  strt, nfull, expr);\
 
   } while (0)
 
 
 Also, I notice that the element type(etype) and vector type(vtype) has
 to be specified in the macro. Since the SEXP is the first argument in
>> the
 macro, it seems redundant to define etype and vtype for 

Re: [R-pkg-devel] unicode WARNING on solaris?

[Tomas Kalibera]

On 9/24/19 1:57 AM, Toby Hocking wrote:

Hi all,

is there a known fix for this WARNING which I am getting on solaris for my
newly submitted nc package?
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/nc-00check.html


It seems that deparse() came across some non-printable characters. Such 
characters would be replaced by \U or \u escapes. This is implemented 
using wide characters in R, but on that platform __STDC_ISO_10646__ is 
not defined, so wchar_t has unknown representation (not known to be 
Unicode), hence the warning.


Best
Tomas



A quick google search for "it is not known that wchar_t is Unicode on this
platform cran" shows that many other packages have this WARNING as well.

I searched r-devel and r-pkg-devel for the warning text but I did not find
any messages discussing a fix.

Thanks for any help
Toby

[[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: [Rd] What is the best way to loop over an ALTREP vector?

[Serguei Sokol]

Le 24/09/2019 à 07:48, Gabriel Becker a écrit :

Also, a small nitpick, R's internal mean function doesn't hit Dataptr, it
hits either INTEGER_ELT (which really should probably be a
ITERATE_BY_REGION) or ITERATE_BY_REGION.

Even if it is not the main point of this thread, I was wondering if 
mean() could take an advantage of sum() (which handles ALTREP in 
efficient way) to be defined as mean(x)=sum(x)/length(x)? Currently, 
sum(1:1e14) is almost instantaneous while mean(1:1e14) is very long.


Best Serguei.

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