Re: [R-pkg-devel] using @inheritParams in documenting data

[Dirk Eddelbuettel]

Hi Troels,

Always good to see someone work on packaging with so much energy.

On 12 January 2019 at 08:46, Troels Ring wrote:
| BUT where and how to put the @inheritParams CMB I cannot find documented.
| Otherwise it seems to run OK

I fear you are getting confused between 'roxygen2' and base R.

'roxygen2' is a very handy and powerful add-on package extending R. But none
of its variables, (which conveniently all start with a @) will be documented
in the proper manual, Writing R Extension.

You question about \describe, however, is about Rd which is base R. And that
very command is 'shadowed' by roxygen2 which generates that section. That is
not unlike your previous question about exporting / registration.

Personally, I see value in working old-school here, and continue to argue
that one should be familiar with the _basic_ and _portable_ commands in
Writing R Extensions before putting another layer on top.  Just how I find it
helps to explain what Rcpp does if one has a mental image of the underlying
'SEXP .Call(funcname, SEXP, SEXP)' it is working with.  So I do use roxygen
to create Rd files but I also spent a decade or so writing Rd files -- and
quite a few people (hi, Duncan) still recommend doing it by hand.  I think it
helps. And you can mix and match.

Also, a decent trick is to search on GitHub with 'user:cran' to restrict your
search to the mirror (thanks, Gabor!) of CRAN packages. For just about any
question, it quite likely that there will be someone who has been there
before among the now (almost) 13,700 packages out there.

Dirk

-- 
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] shadowing a method from the stats package

[Joris Meys]

Hi,

technically you don't need permission for this. You only need permission if
you tamper with the namespace of the stats package, which you don't. You
just hide a function from another package, which is rather common actually
(eg dplyr::lag() and stats::lag() ).

Then again, I'm not sure this will always work, as you rely heavily on the
search path for your function to be found before the one in stats. I would
be interested as well in hearing how this can be solved in a more robust
way, but I can't really come up with something myself. Interesting problem!

Cheers
Joris

On Fri, Jan 11, 2019 at 10:14 PM  wrote:

> Hello,
>
> I created a package for working with a new probability
> distribution called unifed. The source code can be found at
> https://gitlab.com/oquijano/unifed .
>
> This distribution is suitable for GLMs. I have included a a
> function called unifed in the package that returns a family that can
> be used with the glm function.
>
> For a unifed glm, it is necessary for the dispersion parameter to
> be equal to one. The summary method of the glm class does this
> automatically for the poisson and binomial distributions and I would
> like the same for the unifed. In order to achieve this, I am
> including a summary.glm function in the package so it shadows
> stats::summary.glm when the package is attached. This function is
> actually just a wrapper around stats::summary.glm.  It simply checks
> if the family is unifed; If this is the case it calls
> stats::summary.glm with dispersion=1 and otherwise it simply calls
> stats::summary.glm with the same parameters.  Therefore introducing
> this in the namespace does not break or change the behavior of any
> existing code that uses summary.glm
>
>  According to the CRAN policies I need permission from the
> maintainer of the package for doing this. The maintainer of the package
> is the R core team. To whom should I write to ask for this permission?
> Otherwise is there a different way in which I could achieve the right
> default behavior and respect the CRAN policies?
>
>
> Thank you for your time.
>
> __
> 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

Re: [R-pkg-devel] using @inheritParams in documenting data

[Alexandre Courtiol]

Hi Troels,
If you want to create a R package (using roxygen2), I would highly
recommend you to read Hadley Wickham's book on the topic.
The book is easy, short, practical and legally free (here:
http://r-pkgs.had.co.nz/).
If you follow it step by step, everything should work fine.
For anything not covered by the book, as Dirk said, look for examples of
packages you know in GitHub.
++
Alex


On Sat, 12 Jan 2019 at 08:46, Troels Ring  wrote:

> Dearfriends , with your help I'm rapidly improving package development.
> When
> documenting data, I seem to be helped mpst by making the rda directly from
> RStudio via file, new file, R documentation then choosing data. However, my
> data files have a lot of params, so I thought I might use @inheritParams
> since these params are already documented elsewhere in the package. Hence,
> in the rda file created directly from RStudio I tried to add @inheritParams
> CMB (since the params are already documented in CMB) but I cannot find
> exactly how to put it in the rda file.
>
> The skeleton has
>
> \describe{
>
>\item{\code(x)}{vector}
>
> And if I put some the params in a comma separated row instead of x they are
> acknowledged in the final rda file -
>
> BUT where and how to put the @inheritParams CMB I cannot find documented.
> Otherwise it seems to run OK
>
>
>
> All best wishes
>
> Troels
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

*"Science is the belief in the ignorance of experts"*, R. Feynman

[[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] using @inheritParams in documenting data

[Troels Ring]

Hi Dirk - thank you for your kind mail - I can see I better follow the basic
ways! Also since I seem by my shortcuts to have accomplished a major
problem: I had two *.RData files with similar variables of same names in
/data - if I included both and had no rda files to document data, I had this
previously mentioned problem of "following objects are masked by "glovalEnv"
- but if I used the rda files on data directly from RStudio the data were
kept to be from only one of the RData files, I think the first one -
load("*.RData") of course was still correct. 
Thanks a lot for your patience 
Troels

-Oprindelig meddelelse-
Fra: Dirk Eddelbuettel  På vegne af Dirk
Eddelbuettel
Sendt: 12. januar 2019 13:45
Til: Troels Ring 
Cc: package-develop 
Emne: Re: [R-pkg-devel] using @inheritParams in documenting data


Hi Troels,

Always good to see someone work on packaging with so much energy.

On 12 January 2019 at 08:46, Troels Ring wrote:
| BUT where and how to put the @inheritParams CMB I cannot find documented.
| Otherwise it seems to run OK

I fear you are getting confused between 'roxygen2' and base R.

'roxygen2' is a very handy and powerful add-on package extending R. But none
of its variables, (which conveniently all start with a @) will be documented
in the proper manual, Writing R Extension.

You question about \describe, however, is about Rd which is base R. And that
very command is 'shadowed' by roxygen2 which generates that section. That is
not unlike your previous question about exporting / registration.

Personally, I see value in working old-school here, and continue to argue
that one should be familiar with the _basic_ and _portable_ commands in
Writing R Extensions before putting another layer on top.  Just how I find
it helps to explain what Rcpp does if one has a mental image of the
underlying 'SEXP .Call(funcname, SEXP, SEXP)' it is working with.  So I do
use roxygen to create Rd files but I also spent a decade or so writing Rd
files -- and quite a few people (hi, Duncan) still recommend doing it by
hand.  I think it helps. And you can mix and match.

Also, a decent trick is to search on GitHub with 'user:cran' to restrict
your search to the mirror (thanks, Gabor!) of CRAN packages. For just about
any question, it quite likely that there will be someone who has been there
before among the now (almost) 13,700 packages out there.

Dirk

--
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] using @inheritParams in documenting data

[Troels Ring]

Thanks a lot! I stumbled over the RStudio way of producing *.rda files for data 
sets individually instead of making a *.R file as Hadley writes in the book if 
I understand it correctly. 

It certainly is fun to find out about !!

All best wishes

Troels

 

Fra: Alexandre Courtiol  
Sendt: 12. januar 2019 14:28
Til: Troels Ring 
Cc: package-develop 
Emne: Re: [R-pkg-devel] using @inheritParams in documenting data

 

Hi Troels,

If you want to create a R package (using roxygen2), I would highly recommend 
you to read Hadley Wickham's book on the topic.

The book is easy, short, practical and legally free (here: 
http://r-pkgs.had.co.nz/).

If you follow it step by step, everything should work fine.

For anything not covered by the book, as Dirk said, look for examples of 
packages you know in GitHub.

++

Alex

 

 

On Sat, 12 Jan 2019 at 08:46, Troels Ring mailto:tr...@gvdnet.dk> > wrote:

Dearfriends , with your help I'm rapidly improving package development. When
documenting data, I seem to be helped mpst by making the rda directly from
RStudio via file, new file, R documentation then choosing data. However, my
data files have a lot of params, so I thought I might use @inheritParams
since these params are already documented elsewhere in the package. Hence,
in the rda file created directly from RStudio I tried to add @inheritParams
CMB (since the params are already documented in CMB) but I cannot find
exactly how to put it in the rda file.

The skeleton has

\describe{

   \item{\code(x)}{vector}

And if I put some the params in a comma separated row instead of x they are
acknowledged in the final rda file -

BUT where and how to put the @inheritParams CMB I cannot find documented.
Otherwise it seems to run OK



All best wishes

Troels


[[alternative HTML version deleted]]

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






-- 

Alexandre Courtiol

http://sites.google.com/site/alexandrecourtiol/home

"Science is the belief in the ignorance of experts", R. Feynman


[[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] shadowing a method from the stats package

[qxacur]

Hi Joris,

    thank you for your reply.

    I re-read the CRAN policy after I saw your reply and you are right,
I do not need permission for this.

    About the search PATH. unifed will always be attached after stats,
so I think the unifed function would always be found before the one in
stats (please correct me if you think I am wrong).

    Still, I found a different way to solve the problem in order to
avoid NOTEs when I run 'R CMD check --as-cran', that can be considered
more robust:

    I first changed the name of my wrapper function to something
different (this is in order to avoid a note in registering S3 methods).

    then, in the zzz.R file inside of the .onLoad function I used
setMethod with where=.GlobalEnv to rewrite the summary method of the glm
class and in there I call the wrapper function.

   This gives the behavior that I wanted and it does not depend on the
search path.

Cheers,

   Oscar.

>
> Then again, I'm not sure this will always work, as you rely heavily on
> the search path for your function to be found before the one in stats.
> I would be interested as well in hearing how this can be solved in a
> more robust way, but I can't really come up with something myself.
> Interesting problem!
>
> Cheers
> Joris
>
> On Fri, Jan 11, 2019 at 10:14 PM  > wrote:
>
> Hello,
>
>     I created a package for working with a new probability
> distribution called unifed. The source code can be found at
> https://gitlab.com/oquijano/unifed .
>
>     This distribution is suitable for GLMs. I have included a a
> function called unifed in the package that returns a family that can
> be used with the glm function.
>
>     For a unifed glm, it is necessary for the dispersion parameter to
> be equal to one. The summary method of the glm class does this
> automatically for the poisson and binomial distributions and I would
> like the same for the unifed. In order to achieve this, I am
> including a summary.glm function in the package so it shadows
> stats::summary.glm when the package is attached. This function is
> actually just a wrapper around stats::summary.glm.  It simply checks
> if the family is unifed; If this is the case it calls
> stats::summary.glm with dispersion=1 and otherwise it simply calls
> stats::summary.glm with the same parameters.  Therefore introducing
> this in the namespace does not break or change the behavior of any
> existing code that uses summary.glm
>
>      According to the CRAN policies I need permission from the
> maintainer of the package for doing this. The maintainer of the
> package
> is the R core team. To whom should I write to ask for this permission?
> Otherwise is there a different way in which I could achieve the right
> default behavior and respect the CRAN policies?
>
>
> Thank you for your time.
>
> __
> 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] R CMD check --as-cran problem

[Wang, Zhu]

I am trying to update an R package but there was some problem illustrated below.


The current version of the package appears to be fine on CRAN:

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


When R checked the package on a Linux system with R 3.5.2, I had no problem, 
but the following problem occurred with --as-cran option:


R CMD check --as-cran bujar_0.2-3.tar.gz


** testing if installed package can be loaded
Error: package or namespace load failed for 'bujar' in loadNamespace(i, 
c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
 there is no package called 'Matrix'
Error: loading failed
Execution halted
ERROR: loading failed


I will appreciate advice on the matter.


Thanks,


Zhu Wang

[[alternative HTML version deleted]]

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

[R-pkg-devel] check works in ubuntu linux, but get debian-CRAN C++ error

[Robert McCulloch]

Folks,


I am running Ubuntu:
$ lsb_release -a
LSB Version:
core-9.20170808ubuntu1-noarch:printing-9.20170808ubuntu1-noarch:security-9.20170808ubuntu1-noarch
Distributor ID: Ubuntu
Description:Ubuntu 18.04.1 LTS
Release:18.04
Codename:   bionic


my gcc is:
$ g++ --version
g++ (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ R CMD build rbart  --resave-data
$ R CMD check --as-cran rbart_1.0.tar.gz

gives:
Status: 1 NOTE

00check.log has:
* checking CRAN incoming feasibility ... NOTE
Maintainer: ‘Robert McCulloch ’

$ sudo R CMD INSTALL rbart_1.0.tar.gz
  works fine


But I get a debian error when I submit to CRAN:

Dear maintainer,

package rbart_1.0.tar.gz does not pass the incoming checks automatically,
please see the following pre-tests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/rbart_1.0_20190112_195732/Windows/00check.log
>
Status: 1 NOTE
Debian: <
https://win-builder.r-project.org/incoming_pretest/rbart_1.0_20190112_195732/Debian/00check.log
>
Status: 1 ERROR, 1 NOTE

2.01.201920:07  367 00install.out:
* installing *source* package ‘rbart’ ...
checking whether the C++ compiler works... no
configure: error: in `/srv/hornik/tmp/CRAN/rbart.Rcheck/00_pkg_src/rbart':
configure: error: C++ compiler cannot create executables
See `config.log' for more details
ERROR: configuration failed for package ‘rbart’
* removing ‘/srv/hornik/tmp/CRAN/rbart.Rcheck/rbart’


So, I don't know why there is some kind of C++ error in CRAN-debian when it
works fine on
my Ubuntu system.
And I don't know how to get more information on the problem.

rbart_1.0.tar.gz  is at
www.rob-mcculloch.org/rbart_1.0.tar.gz

This is my first time emailing this list, hope I did it in a reasonable way.
thanks,
Rob McCulloch

[[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] check works in ubuntu linux, but get debian-CRAN C++ error

[Dirk Eddelbuettel]

Hi Rob,

On 12 January 2019 at 15:40, Robert McCulloch wrote:
| checking whether the C++ compiler works... no

That line is weird.

It is difficult to debug from afar, and I bemoan that Kurt's system has no
equivalent Docker container (or alike) to make it more reproducible.

But _something_ is up with the compiler. That may, or may not, be an issue at
his end.  Did you try emailing Kurt Hornik?

Best, Dirk

-- 
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] R CMD check --as-cran problem

[Dirk Eddelbuettel]

On 11 January 2019 at 22:51, Wang, Zhu wrote:
| ** testing if installed package can be loaded
| Error: package or namespace load failed for 'bujar' in loadNamespace(i, 
c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
|  there is no package called 'Matrix'
| Error: loading failed
| Execution halted
| ERROR: loading failed
| 
| 
| I will appreciate advice on the matter.

Something tries to use package Matrix but it is not installed. You may need
it in Imports: (and then in NAMESPACE) or in Suggests: (and then test via if
(requireNamepace(...) and load).

Dirk

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