Re: [R-pkg-devel] Problem with loading package "devtools" from CRAN.

[Georgi Boshnakov]

I also had the problem that devtools didn't install.

I used update.packages(ask =FALSE) and that solved the problem.

Before that I tried to locate the culprit but it was not one of the direct 
dependencies of devtools.

Georgi Boshnakov

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: R-package-devel  on behalf of 
Simon Urbanek 
Sent: Monday, April 29, 2024 7:33:55 AM
To: Rolf Turner 
Cc: je...@posit.co ; r-package-devel@r-project.org 

Subject: Re: [R-pkg-devel] Problem with loading package "devtools" from CRAN.

Rolf,

what do you mean by "broken"? Since you failed to include any proof nor details 
it's unlikely that anyone can help you, but chances are pretty high that it was 
a problem on your end. I just checked with R 4.4.0 on Ubuntu 22.04 and devtools 
install and load just fine, so it is certainly broken on CRAN.

Make sure you don't have packages for old R version in your local libraries - 
that is a most common mistake - always remove them when upgrading R and 
re-install if still need them. You can check the locations of your libraries 
with .libPaths() in R. Sometimes, update.packages(checkBuilt=TRUE) can do the 
trick as well, but I prefer clean re-installs for safety as it also helps you 
clean up old cruft that is not longer needed.

Cheers,
Simon



> On Apr 29, 2024, at 1:19 PM, Rolf Turner  wrote:
>
>
> Executive summary:
>
>> The devtools package on CRAN appears to be broken.
>> Installing devtools from github (using remotes::install_github())
>> seems to give satisfactory results.
>
> This morning my software up-dater (Ubuntu 22.04.4) prompted me to
> install updated versions of some software, including r-base.  I thereby
> obtained what I believe is the latest version of R (4.4.0 (2024-04-24)).
>
> Then I could not load the "devtools" package, which is fairly crucial to
> my work.
>
> A bit of web-searching got me to a post on github by Henrik Bengtsson,
> which referred to the devtools problem.  I therefore decided to try
> installing devtools from github:
>
>remotes::install_github("r-lib/devtools",lib="/home/rolf/Rlib")
>
> Some 50-odd packages seemed to require up-dating.  I went for it, and
> after a fairly long wait, while messages about the updating flowed by,
> devtools seemed to get installed.  Now "library(devtools)" runs without
> error, so I am happy with my own situation.  However there seems to be
> a problem with the devtools package on CRAN, which ought to be fixed.
>
> cheers,
>
> Rolf Turner
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Stats. Dep't. (secretaries) phone:
> +64-9-373-7599 ext. 89622
> Home phone: +64-9-480-4619
>
> __
> R-package-devel@r-project.org mailing list
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!D1bv6hCvIc_G_5ay6dqpVMj1roESgfSV8NT0AaMD8kJ92-7-YAkFg6c4TaVx-GXHEj7yieujSDu7LATDgtP-aSPQ7C2b745lri9DbFpH$
>  [stat[.]ethz[.]ch]
>

__
R-package-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!D1bv6hCvIc_G_5ay6dqpVMj1roESgfSV8NT0AaMD8kJ92-7-YAkFg6c4TaVx-GXHEj7yieujSDu7LATDgtP-aSPQ7C2b745lri9DbFpH$
 [stat[.]ethz[.]ch]

[[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] Need help with "Lost braces" in R under development checks

[Georgi Boshnakov]

The braces are lost in the sense that they are superfluous (not typeset in the 
pdf manual but may be typeset in other formats. In your example \doi has one 
argument, so the braces enclosing the following phrase are superfluous.

This may not be harmful here but since CRAN introduced the NOTE it has 
uncovered thousands of actual typos and similar.

As to the 'invalid url', you can ignore it when you are sure that it is correct 
- some sites don't like being accessed programatically and start blocking the 
caller (eg if you run R checks several times in succession).


Georgi Boshnakov

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: R-package-devel  on behalf of 
adi...@pdx.edu 
Sent: Sunday, April 7, 2024 5:58:57 AM
To: r-package-devel@r-project.org 
Subject: [R-pkg-devel] Need help with "Lost braces" in R under development 
checks


Hello,

I would appreciate help with two build NOTEs:


First, On the Winbuilder check, the check for R version 4.4.0 alpha
(2024-04-05 r86346 ucrt) and also under the Debian R Under development
(unstable) (2024-04-05 r86348) I got a NOTE about a bunch of 'Lost
braces' in my .Rd files. I am confused because my braces appear to match
when I count them, and I don't *think* I am runing into an item/itemize
situation. Here's an example (all the reported issues in this NOTE are
within \references sections ):

  checkRd: (-1) LoopAnalyst-package.Rd:14: Lost braces
14 |  Dambacher, J. M. and Li, H. W. and Rossignol, P. A. (2002)
  \doi{10.2307/3071950}{Relevance of community structure in assessing
  indeterminacy of ecological predictions}. \emph{Ecology},
  \bold{83(5)},1372--1385.

Here's the Winbuilder log:
https://urldefense.com/v3/__https://win-builder.r-project.org/incoming_pretest/LoopAnalyst_1.2-7_20240406_215835/Windows/00check.log__;!!PDiH4ENfjr2_Jw!A109ZbFKcZjQ25lSt1JJSlLziJ-IyfouQzdKPv5pnUKRq_3-RoKd52MVDkHUoho-VQ5Ld85q6WmdGwh5eSSWPstUjY95nA$
 [win-builder[.]r-project[.]org]

And here's the Debian log:
https://urldefense.com/v3/__https://win-builder.r-project.org/incoming_pretest/LoopAnalyst_1.2-7_20240406_215835/Debian/00check.log__;!!PDiH4ENfjr2_Jw!A109ZbFKcZjQ25lSt1JJSlLziJ-IyfouQzdKPv5pnUKRq_3-RoKd52MVDkHUoho-VQ5Ld85q6WmdGwh5eSSWPstlRfRWeA$
 [win-builder[.]r-project[.]org]


The second NOTE is about "(possibly) invalid URLs:"
  URL: 
https://urldefense.com/v3/__https://www.journals.uchicago.edu/doi/10.1086/367590__;!!PDiH4ENfjr2_Jw!A109ZbFKcZjQ25lSt1JJSlLziJ-IyfouQzdKPv5pnUKRq_3-RoKd52MVDkHUoho-VQ5Ld85q6WmdGwh5eSSWPsuMHqle7Q$
 [journals[.]uchicago[.]edu]
Status: 403
Message: Forbidden

However, when I follow this URL in my browser it appears to link
appropriately to the intended page. If I use a \doi{10.1086/367590}
instead of an \href I get the same behavior: check says "(possibly)
invalid URLs" but 
https://urldefense.com/v3/__https://doi.org/10.1086/367590__;!!PDiH4ENfjr2_Jw!A109ZbFKcZjQ25lSt1JJSlLziJ-IyfouQzdKPv5pnUKRq_3-RoKd52MVDkHUoho-VQ5Ld85q6WmdGwh5eSSWPstaKkb77Q$
 [doi[.]org] appears to work just
fine in the browser. Not sure what I am doing wrong here.



Thank you!


Alexis Dinno
Associate Professor
OHSU-PSU School of Public Health
Pronouns: she/her/hers

610-R Vanport Building
1810 SW 5th Avenue, Suite 610
Portland, OR 97201-5202

p: (503) 725-3076
f: (503) 725-5100
e: alexis.di...@pdx.edu

Note: I do not use a networked calendar, so meeting dates should be 
communicated directly via email.

__
R-package-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!A109ZbFKcZjQ25lSt1JJSlLziJ-IyfouQzdKPv5pnUKRq_3-RoKd52MVDkHUoho-VQ5Ld85q6WmdGwh5eSSWPssk-Dl_sw$
 [stat[.]ethz[.]ch]

[[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] Bioconductor reverse dependency checks for a CRAN package

[Georgi Boshnakov]

Have you tried revdepcheck (https://github.com/r-lib/revdepcheck)?
It handles the dependencies and uses a local cache for the downloaded packages. 
It also checks packages with the new and old versions. 

As far as I know, it doesn't handle the system requirements though.

Georgi Boshnakov




From: R-package-devel  on behalf of Ivan 
Krylov via R-package-devel 
Sent: 30 January 2024 15:56
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Bioconductor reverse dependency checks for a CRAN package

Hello R-package-devel,

What would you recommend in order to run reverse dependency checks for
a package with 182 direct strong dependencies from CRAN and 66 from
Bioconductor (plus 3 more from annotations and experiments)?

Without extra environment variables, R CMD check requires the Suggested
packages to be available, which means installing...

revdepdep <- package_dependencies(revdep, which = 'most')
revdeprest <- package_dependencies(
 unique(unlist(revdepdep)),
 which = 'strong', recursive = TRUE
)
length(setdiff(
 unlist(c(revdepdep, revdeprest)),
 unlist(standard_package_names())
))

...up to 1316 packages. 7 of these suggested packages aren't on CRAN or
Bioconductor (because they've been archived or have always lived on
GitHub), but even if I filter those out, it's not easy. Some of the
Bioconductor dependencies are large; I now have multiple gigabytes of
genome fragments and mass spectra, but also a 500-megabyte arrow.so in
my library. As long as a data package declares a dependency on your
package, it still has to be installed and checked, right?

Manually installing the SystemRequirements is no fun at all, so I've
tried the rocker/r2u container. It got me most of the way there, but
there were a few remaining packages with newer versions on CRAN. For
these, I had to install the system packages manually in order to build
them from source.

Someone told me to try the rocker/r-base container together with pak.
It was more proactive at telling me about dependency conflicts and
would have got me most of the way there too, except it somehow got me a
'stringi' binary without the corresponding libicu*.so*, which stopped
the installation process. Again, nothing that a bit of manual work
wouldn't fix, but I don't feel comfortable setting this up on a CI
system. (Not on every commit, of course - that would be extremely
wasteful - but it would be nice if it was possible to run these checks
before release on a different computer and spot more problems this way.)

I can't help but notice that neither install.packages() nor pak() is
the recommended way to install Bioconductor packages. Could that
introduce additional problems with checking the reverse dependencies?

Then there's the check_packages_in_dir() function itself. Its behaviour
about the reverse dependencies is not very helpful: they are removed
altogether or at least moved away. Something may be wrong with my CRAN
mirror, because some of the downloaded reverse dependencies come out
with a size of zero and subsequently fail the check very quickly.

I am thinking of keeping a separate persistent library with all the
1316 dependencies required to check the reverse dependencies and a
persistent directory with the reverse dependencies themselves. Instead
of using the reverse=... argument, I'm thinking of using the following
scheme:

1. Use package_dependencies() to determine the list of packages to test.
2. Use download.packages() to download the latest version of everything
if it doesn't already exist. Retry if got zero-sized or otherwise
damaged tarballs. Remove old versions of packages if a newer version
exists.
3. Run check_packages_in_dir() on the whole directory with the
downloaded reverse dependencies.

For this to work, I need a way to run step (3) twice, ensuring that one
of the runs is performed with the CRAN version of the package in the
library and the other one is performed with the to-be-released version
of the package in the library. Has anyone already come up with an
automated way to do that?

No wonder nobody wants to maintain the XML package.

--
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!CS5KQeRz1siwuoD4-RSsRjkbQzvi1QS9jLin41C9dDDiXO1WkQ4-TZNdsLD6JyHLNedacNbjOvT05POeYHSYhLOKR4WvCNwVh37etWZ78gw$
 [stat[.]ethz[.]ch]

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

Re: [R-pkg-devel] lost braces note on CRAN pretest related to \itemize

[Georgi Boshnakov]

The notes you get illustrate why they are useful, if you look at your rendered 
documentation you probably will see something wrong. Thousands of packages on 
CRAN, including some of mines have had this kind of infelicities for years.

Firstly, the two sets of braces suggest that you meant a description 
environment, not itemize (in which  its only argument doesn't need braces).

Secondly, in the value section, \item is implicitly enclosed in \describe and 
you don't need to include the latter.

Georgi Boshnakov


Sent from Outlook for Android<https://aka.ms/AAb9ysg>


From: R-package-devel  on behalf of 
Patrick Giraudoux 
Sent: Tuesday, January 23, 2024 7:09:22 pm
To: Dirk Eddelbuettel 
Cc: R Package Development 
Subject: Re: [R-pkg-devel]  lost braces note on CRAN pretest related to \itemize

OK. Clear enough. CRAN applies a new "filter" as it was going through
without crying a note since decades ;-). However, indeed, re-checking
the manual "Writing R extensions" my syntax was wrong...
Thanks for the guidance,
Patrick

Le 23/01/2024 � 19:58, Dirk Eddelbuettel a �crit :
> On 23 January 2024 at 19:39, Patrick Giraudoux wrote:
> | Has anyone an idea about what is going wrong ?
>
> \item has no braces following it.  From a package I submitted today and for
> which I still have NEWS.Rd in the editor (indented here):
>
>\section{Changes in version 0.0.22 (2024-01-23)}{
>  \itemize{
>\item Replace empty examples macros to satisfy CRAN request.
>  }
>}
>
> Hth,  Dirk
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!Gu9AhS4Yi4k5IC8TXv4B8xpznl-8-Jhl-cdxRZ6zVrRCdmDaSTVYpaG5XDoitdms9FuHQGV7adP-Q6WD6w2bMws_b5UnszsH5VsXFBMUIvFX4Nc$
 [stat[.]ethz[.]ch]


[[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] Warning from orphaned package on check page

[Georgi Boshnakov]

Orphaned packages can't be listed in DEPENDS and IMPORTS fields in file 
DESCRIPTION. They can be in SUGGESTS but calls of functions from them should be 
guarded, eg with a message to install the offending package. In examples and 
tests the usage should be conditional on the package being installed.

Another option is to take over maintenance of that package. In your case, with 
so many dependencies someone may be working on bringing it back.

Georgi Boshnakov

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: R-package-devel  on behalf of Liam 
J. Revell 
Sent: Thursday, November 9, 2023 11:30:05 AM
To: Alexandre Courtiol 
Cc: r-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] Warning from orphaned package on check page

My apologies for the lack of clarity.

plotrix has been orphaned so my package results page now says

 checking package dependencies ... WARNING
 Requires orphaned package: �plotrix�

CRAN incoming requires maintainers to certify: 'I have fixed all
problems shown on the package check page.' Since I can't unorphan
plotrix, I can't certify this statement & thus can't get a new version
of my package on CRAN. Advice on how to proceed is welcomed.

Liam J. Revell
Professor of Biology, University of Massachusetts Boston
Web: 
https://urldefense.com/v3/__http://faculty.umb.edu/liam.revell/__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXaHjdobg$
 [faculty[.]umb[.]edu]
Book: Phylogenetic Comparative Methods in R (Princeton University Press,
2022)

On 11/9/2023 4:10 AM, Alexandre Courtiol wrote:
>
>
> You don't often get email from alexandre.court...@gmail.com. Learn why
> this is important 
> <https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXKg7CKCI$
>  [aka[.]ms]>
>
>
> CAUTION: EXTERNAL SENDER
> Dear Liam,
> I don't understand your question: if your package has plotrix listed
> as a dependency, it won't affect plotrix.
> Only the opposite would be true. Could you please clarify and indicate
> which package you are referring to?
> Thanks,
> Alex
>
>
>
> On Thu, 9 Nov 2023 at 09:57, Liam J. Revell  wrote:
>
> Dear colleagues.
>
> I'm trying to update a package on CRAN containing a dependency
> (specifically, on the popular graphing package 'plotrix') that has
> been
> orphaned because the maintainer is deceased.
>
> 'plotrix' is imported by well over 100 other CRAN packages, so I
> hope it
> is not removed from CRAN. On the other hand, I don't want to certify
> that 'I have fixed all problems shown on the package check page'
> if this
> is not, in fact, the case.
>
> Can anyone comment on how one might proceed in this situation?
>
> Thank you. -- Liam
>
> --
> Liam J. Revell
> Professor of Biology, University of Massachusetts Boston
> Web: 
> https://urldefense.com/v3/__http://faculty.umb.edu/liam.revell/__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXaHjdobg$
>  [faculty[.]umb[.]edu]
> 
> <https://urldefense.com/v3/__http://faculty.umb.edu/liam.revell/__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXaHjdobg$
>  [faculty[.]umb[.]edu]>
> Book: Phylogenetic Comparative Methods in R (Princeton University
> Press,
> 2022)
>
> __
> R-package-devel@r-project.org mailing list
> 
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXeH56VIc$
>  [stat[.]ethz[.]ch]
> 
> <https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXeH56VIc$
>  [stat[.]ethz[.]ch]>
>
>
>
> --
> Alexandre Courtiol, 
> https://urldefense.com/v3/__http://www.datazoogang.de/__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXtwIJCmI$
>  [datazoogang[.]de]
> <https://urldefense.com/v3/__http://www.datazoogang.de/__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXtwIJCmI$
>  [datazoogang[.]de]>
[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://urldefense.com/v

Re: [R-pkg-devel] Help with a github/Rstudio mess

[Georgi Boshnakov]

If I understand correctly, the errors come from github actions run on github. I 
think that you should update them first, since github switched to new versions 
in the meantime.

Georgi Boshnakov

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: R-package-devel  on behalf of 
Duncan Murdoch 
Sent: Wednesday, July 5, 2023 10:03:11 AM
To: chrish...@psyctc.org ; r-package-devel@r-project.org 

Subject: Re: [R-pkg-devel] Help with a github/Rstudio mess

I think this isn't the right place to ask for this sort of help. Maybe
stackoverflow instead?

What I'd do in this case is to rename the local dir holding the
repository, then clone a new copy from Github.  Assuming that works,
compare all the files to make sure that you have all recent changes,
commit any that were missed, then throw away the damaged one.

Duncan Murdoch

On 05/07/2023 4:44 a.m., Chris Evans wrote:
> I hope this is a legitimate question here.  I have a package of very
> simple functions: 
> https://urldefense.com/v3/__https://github.com/cpsyctc/CECPfuns__;!!PDiH4ENfjr2_Jw!FZGzBDcbpIrmi_GwRh-AOLdv_s3ZxBSRedrQOny_05Q7aFCZq6Qz2deRH-xf1t-f2t_aYV98T4tnvzDCQlxqxh28IYKhYCCSSxRo1w$
>  [github[.]com].  For the forseeable
> future it's really only to stop me constantly having to rewrite
> functions I use and it is only also used by probably two or three
> colleagues who
> also use R and are even less IT/programming/R competent than I am and
> are very happy to use my functions.
>
> I hadn't done any work on it for two years but came back to it yesterday
> and added a function (getCIforQuantiles).  There were warnings about
> things that are deprecated now in some of the older functions but
> otherwise things seemed OK.  However, I got a pkgdown error and warning
> after
> pushing the updated package to github:
>
> Annotations
> 1 error and 1 warning
> pkgdown
> Failed to get R 4.3.1: Failed to get R 4.3.1: Failed to download version
> 4.3.1: Error: Unexpected HTTP response: 404
> r-lib/actions/setup-r@v1 is deprecated.
> r-lib/actions/setup-r@v1 is deprecated. Please update your workflow to
> use the 'v2' version. Also look at the examples at
> https://urldefense.com/v3/__https://github.com/r-lib/actions/tree/v2/examples__;!!PDiH4ENfjr2_Jw!FZGzBDcbpIrmi_GwRh-AOLdv_s3ZxBSRedrQOny_05Q7aFCZq6Qz2deRH-xf1t-f2t_aYV98T4tnvzDCQlxqxh28IYKhYCD0u-NayA$
>  [github[.]com] because '@v2'
> workflows are much simpler than 'v1' workflows.
>
> So I tweaked
> https://urldefense.com/v3/__https://github.com/cpsyctc/CECPfuns/blob/main/.github/workflows/pkgdown.yaml__;!!PDiH4ENfjr2_Jw!FZGzBDcbpIrmi_GwRh-AOLdv_s3ZxBSRedrQOny_05Q7aFCZq6Qz2deRH-xf1t-f2t_aYV98T4tnvzDCQlxqxh28IYKhYCCnQO2uOA$
>  [github[.]com]
> to change
>  - uses: r-lib/actions/setup-r@v1
> to
>  - uses: r-lib/actions/setup-r@v2
> rather optimistically hoping that might make the warning go away.
>
> Today I did some work on the new function (trivial, correcting one
> "!is.na(" to the correct "is.na(" !!!).  More importantly, I created the
> test-getCIforQuantiles.R file for testthat to test the sanity checks and
> add three simple output checks.
>
> I built the source package locally, committed the changes and tried to
> push the update to github (inside Rstudio) but I get:
>
>   >>> /usr/bin/git push origin HEAD:refs/heads/main
> To 
> https://urldefense.com/v3/__https://github.com/cpsyctc/CECPfuns.git__;!!PDiH4ENfjr2_Jw!FZGzBDcbpIrmi_GwRh-AOLdv_s3ZxBSRedrQOny_05Q7aFCZq6Qz2deRH-xf1t-f2t_aYV98T4tnvzDCQlxqxh28IYKhYCCMv5veZQ$
>  [github[.]com]
>! [rejected]HEAD -> main (fetch first)
> error: failed to push some refs to 
> 'https://urldefense.com/v3/__https://github.com/cpsyctc/CECPfuns.git__;!!PDiH4ENfjr2_Jw!FZGzBDcbpIrmi_GwRh-AOLdv_s3ZxBSRedrQOny_05Q7aFCZq6Qz2deRH-xf1t-f2t_aYV98T4tnvzDCQlxqxh28IYKhYCCMv5veZQ$
>  [github[.]com]'
> hint: Updates were rejected because the remote contains work that you do
> hint: not have locally. This is usually caused by another repository pushing
> hint: to the same ref. You may want to first integrate the remote changes
> hint: (e.g., 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
> OK.  So I try to pull thinking that made sense and that the change to
> pkgdown.yaml on github that I made yesterday is the offending change.
>
> However, when I pull (in Rstudio again) I get this:
>
>   >>> /usr/bin/git pull
> fatal: pack has 6 unresolved deltas
> fatal: fetch-pack: invalid index-pack output
>
> I have never felt on top of the complexities of git and github but I'm
> clearly way out of my depth.  I am hoping someone here can see what
> I need to do to get things back in synch an

[Rd] bug in na.contiguous? Doesn't give the first tied stretch if it is at the start

[Georgi Boshnakov]

Hi.

The description of na.contiguous says:

"Find the longest consecutive stretch of non-missing values in a
 time series object.  (In the event of a tie, the first such
 stretch.)"

But this seems not to be the case if one of the tied longest stretches is at 
the start of the sequence/series. In the following example, there are three 
stretches of length 3, so I expect the result to be [1 2 3]. But:

> x <- c(1:3, NA, NA, 6:8, NA, 10:12)
> x
[1]  1  2  3 NA NA  6  7  8 NA 10 11 12
> na.contiguous(x)
[1] 6 7 8
## expected: [1] 1 2 3

(I have stripped attributes from the output for clarity.)

Below is the beginning of stats:::na.contiguous.default.
The source of the issue appears to be  the line containing the assignment to 
'seg' (marked with exclamation marks).
The calculation leading to it does

cumsum(!good)

where !good in this case is

[1] FALSE FALSE FALSE  TRUE  TRUE FALSE FALSE FALSE  TRUE FALSE FALSE FALSE

And its cumsum is:

[1] 0 0 0 1 2 2 2 2 3 3 3 3


Then the assignment to 'seg' below picks the first longest stretch and 
subtracts 1, since the cumsum at indices corresponding to FALSE stays constant 
but the length of the constant stretch is one more then the number of FALSEs, 
... except for the stretch at the start of the series which is not preceded by 
TRUE! So it is missed.

One way to patch this could be by the two commented assignments added by me to 
the code below to prepend a 0 to tt and then drop the first element of 'keep' 
to allow correct indexing later.

Georgi Boshnakov


> stats:::na.contiguous.default
function (object, ...)
{
tm <- time(object)
xfreq <- frequency(object)
if (is.matrix(object))
good <- apply(!is.na(object), 1L, all)
else good <- !is.na(object)
if (!sum(good))
stop("all times contain an NA")
tt <- cumsum(!good)
## tt <- c(0, tt)
ln <- sapply(0:max(tt), function(i) sum(tt == i))
seg <- (seq_along(ln)[ln == max(ln)])[1L] - 1  ## !!!
keep <- (tt == seg)
## keep <- keep[-1]
st <- min(which(keep))

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Mysterious "invalid z limit"

[Georgi Boshnakov]

A frequent cause of such errors is that in the offending scenario a method is 
not visible, so the call goes directly to the default method. This often can be 
verified by temporarily printing something from your method when it gets 
control.

Without more details it is difficult to be more specific. It may be a missing 
import or export, for example.

Georgi Boshnakov


Get Outlook for Android<https://aka.ms/AAb9ysg>


From: R-package-devel  on behalf of 
Duncan Murdoch 
Sent: Sunday, 8 January 2023, 10:05
To: Kevin R. Coombes ; R Package Development 

Subject: Re: [R-pkg-devel] Mysterious "invalid z limit"

On 07/01/2023 8:43 p.m., Kevin R. Coombes wrote:
> Hi,
>
> I am in the middle of developing a new package, which contains a
> markdown-knitr-html vignette. When I try to run
>
> R CMD build [mypackagedirectory]
>
> I get an error message
>
> Quitting from lines 330-336
> Error: processing vignette  failed with diagnostics:
> invalid z limits
>
> If I run the same markdown script interactively inside R Studio, there
> is no error.
> If I knit the markdown script inside R Studio, it produces the correct
> HTML output, with no error.
>
> The offending lines of code (the chunk at 330-336) invoke an "image"
> method on an object of a class defined in the package, which in turn
> computes a matrix from items inside the object and calls image.default,
> which is presumably where the error is coming from.
>
> Two questions: (1) How is it possible that the same code works error
> free in the RStudio contexts, but fails in the attempt to build the package?
> (2) Any suggestions on how to debug something that only throws an error
> from "R CMD build" would be most welcome.

Debugging that sort of thing is hard.  Here's what I would try:

 From inside an R session, run

   tools:::.build_packages("[mypackagedirectory]")

That runs the code that R CMD build runs, so it might trigger the same
error.  If so, debug in the usual way, with traceback(), etc.

If that doesn't trigger the error, try it using a different front-end,
e.g. running R at the command line instead of running it in RStudio.

If you still can't trigger it, then start modifying the vignette to find
the exact line that causes the error (e.g. by commenting out the second
half of the code in that chunk; did the error go away? etc.).  Then
modify it again to save all the inputs to the bad line in a file before
running it, and see if running that line in a different context still
triggers the error. Etc.

Duncan Murdoch

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


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

[Georgi Boshnakov]

>...functions, that are not meant to be called directly by users, should be 
>documented in a file named -internal.Rd.

This is one option, convenient in the use-case of the question. But why export 
a function that you actively don't want the users to know about? There are 
cases when this is needed or convenient but particularly with 'roxygen2' it is 
just about deleting an '@export' line.
 
Just for completeness, non-exported functions can be documented as any other 
functions. Adding

\keyword{internal}

will prevent them from appearing in manuals (but still accessible via '?'). 
Stating clearly that such functions are internal is also sensible. 


Georgi Boshnakov

-Original Message-
From: R-package-devel  On Behalf Of Rolf 
Turner
Sent: 27 September 2022 02:38
To: Andrew Simmons 
Cc: List r-package-devel 
Subject: Re: [R-pkg-devel] Inquiry


On Mon, 26 Sep 2022 20:07:28 -0400
Andrew Simmons  wrote:

> This issue isn't related to RStudio.
> 
> The issue is that you're exporting an object without providing any 
> documentation for it. It sounds like you don't want to export it, so 
> you need to go to your NAMESPACE file and remove the part was 
> export(r2). If you do want to export it, then you need to document it, 
> there's no way around that. The documentation doesn't need to be very 
> detailed.
> 
> 
> On Mon., Sep. 26, 2022, 20:01 ,  wrote:
> 
> > ​Hi there,
> > I am writing to aks your help for an issuue arising when I am 
> > writing my R package using R studio 1.2.1335 as follows.
> > ``checking for missing documentation entries ... WARNING 
> > Undocumented code objects:
> >   'r2'
> > All user-level objects in a package should have documentation
> > entries." The function r2.r is among  .r   files within R folder of
> > my package. I am not interested to present "r2" in the R topics
> > documented: as a part of first page of built pdf help file of my 
> > package. I appreciate highly if you could help me to solve this 
> > issue.

My understanding is that functions, that are not meant to be called directly by 
users, should be documented in a file named -internal.Rd.  It should 
have a structure something like:

> \name{pkgnm-internal}
> \alias{pkgnm-internal}
> \alias{foo}
> \alias{bar}
> \alias{clyde}
> \title{Internal pkgnm functions}
> \description{
>   Internal pkgnm functions.
> }
> \usage{
> foo(x,y,z)
> bar(melvin,irving,...)
> clyde(arrgh)
> }
> \details{
>   These functions are not intended to be called directly by the
>   user.  
> }
> \author{Hoo Hee
>   \email{hoo@somewhere.otr}
> }
> \keyword{internal}

Then if someone types, e.g., "help(clyde)" they get the processed form of the 
forgoing *.Rd file displayed, and are thereby told that they probably should 
not mess with clyde().

cheers,

Rolf Turner

P.S. I always export everything.

R. T.

--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

__
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

[Rd] . Re: stage=install in \doi definition could lead to problems

[Georgi Boshnakov]

> ... you could set \RdOpts{stage=build} before the Rd section containing that 
> "scary" 
\doi (and if needed revert to \RdOpts{stage=install} afterwards).

This works but R-devel CMD check then gives the warning that "Found the 
following URL's which should use doi ...".
For a reprex, see the package at 
https://github.com/GeoBosh/reprexes/tree/master/redundantDots (man/fun_3.Rd 
contains the \doi's).
Building that package with R-devel throws one warning, building it with 
non-R-devel throws two (my R-devel is from yesterday, r81914). The latter seems 
logical since with older R's \doi is expanded and therefore contains the 
expanded URL about which R-devel complains. The warnings do seem somewhat 
unpredictable in that I tried different examples and sometimes got warnings 
sometimes didn't.  

I may be missing something but would it be reasonable not to apply this check 
to packages submitted to CRAN until this is made stable?

Georgi Boshnakov











--

Message: 4
Date: Wed, 16 Mar 2022 01:07:54 +0100
From: Sebastian Meyer 
To: Ivan Krylov 
Cc: 
Subject: Re: [Rd] stage=install in \doi definition could lead to
problems
Message-ID: <3ca49400-0f53-708b-72b2-017d2f173...@fau.de>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Am 15.03.22 um 21:38 schrieb Ivan Krylov:
> Good Sys.time() everyone,
> 
> If this is not the right place for such questions, please let me know.

Thank you for your feedback! I think this is the right place (but note 
that such very recent changes *could* still be work in progress and may 
sometimes need a bit more time to be worth discussing here).

> 
> I was wondering why \doi has been changed to stage=install instead of
> stage=build in r81891 [1]. I think it might lead to problems, but in
> the spirit of Chesterton's fence, I'd like to learn the reasons. Is it
> to make R CMD build more performant, avoiding the need for the
> "installing the package to process man pages" step for the common case
> of the \doi macro?

Yes, that certainly is one of the advantages of the change, affecting 
more than 1000 packages on CRAN that currently ship a partial Rd db just 
because they use the \doi macro. Besides considerably speeding up R CMD 
build for these packages, the change also slightly reduces the size of 
the tarballs.

I think the most probable reason for the previous use of stage=build for 
that Sexpr was to avoid shipping the PDF package manual with the 
package, as generally triggered by install or render time Sexprs. This 
has now been addressed.

> 
> Some DOIs look a bit scary. One example that comes to mind is as
> follows:
> 
> 10.1002/(SICI)1099-128X(199801/02)12:1<55::AID-CEM501>3.0.CO;2-#
> 
> Until the recent fix in r81817 [2], it used to require special
> treatment in order to display correctly in a man page, but now it just
> works if I copy and paste it into \doi{}. With the macro definition
> using [stage=build], I could build a package with a recent build of
> R-devel, get the correct \doi expansion inlined, install the package on
> an older version of R, and it would still work, thanks to R keeping the
> parse tree in build/partial.rdb.
> 
> With the macro defined using [stage=install], any version of R older
> than 2022-02-25 (r81817), which doesn't have this fix, would fail to
> link to the DOI correctly, not having the correct expansion of \doi
> to rely upon any more:
> 
> Rd2HTML(parse_Rd(textConnection('\\name{foo}\n\\title{bar}\\description{\\doi{10.1002/(SICI)1099-128X(199801/02)12:1<55::AID-CEM501>3.0.CO;2-#}}'),
> fragment = FALSE), stages = c('build'))
> 
>  href="http://doi.org/10.1002/(SICI)1099-128X(199801/02)12:1%3C55::AID-CEM501%3E3.0.CO;2-#">doi:
> 10.1002/(SICI)1099-128X(199801/02)12:155::AID-CEM5013.0.CO;2-#
> 
> (The hash sign doesn't get URL-encoded, and the link gets broken.)
> 
> Sorry for giving you yet another case of <https://xkcd.com/1172/>. If I
> have to, I might be able to "unroll" the macro myself for the few cases
> where it matters.
> 

Thank you for the example. I think there is another solution: you could 
set \RdOpts{stage=build} before the Rd section containing that "scary" 
\doi (and if needed revert to \RdOpts{stage=install} afterwards). Then 
the corresponding Sexpr would get evaluated during the build stage as 
before and the correctly escaped hyperlink from building with 
R-devel/4.2.0 would be available also in older R versions.

Sebastian




--

Message: 5
Date: Wed, 16 Mar 2022 13:14:32 +0300
From: Ivan Krylov 
To: Sebastian Meyer 
Cc: 
Subject: Re: [Rd] stage=install in \doi definition could lead to
problems
Message-ID: <20220316131432.5fe64185@arachnoid>
Content-Type: text/plain; cha

Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

[Georgi Boshnakov]

It turns out that it is not difficult to find, the excerpt below is from 
help(setMethod). Maybe  mentioning this in help(setGeneric) would be helpful, 
as well.

Georgi Boshnakov


===
Method definitions can have default expressions for arguments, but
 only if the generic function must have _some_ default expression
 for the same argument. (This restriction is imposed by the way R
 manages formal arguments.)  If so, and if the corresponding
 argument is missing in the call to the generic function, the
 default expression in the method is used.  If the method
 definition has no default for the argument, then the expression
 supplied in the definition of the generic function itself is used,
 but note that this expression will be evaluated using the
 enclosing environment of the method, not of the generic function.
 Method selection does not evaluate default expressions.  All
 actual (non-missing) arguments in the signature of the generic
 function will be evaluated when a method is selected-when the call
 to 'standardGeneric(f)' occurs.  Note that specifying class
 '"missing"' in the signature does not require any default
 expressions.

-Original Message-
From: Martin Maechler  
Sent: 08 November 2021 15:44
To: Georgi Boshnakov 
Cc: Andrew Simmons ; Dario Strbenac 
; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

>>>>> Georgi Boshnakov 
>>>>> on Mon, 8 Nov 2021 09:46:00 + writes:

> You need to define the generic with a default value for
> this parameter. Methods can then have a different default
> value for it. 
> I remember reading this in S4's documentation but don't remember where.

> Georgi Boshnakov

interesting ... and would make quite some sense.

Can others confirm / disprove ?

Even as co-author of the "using S4 almost everywhere" package 'Matrix'
I wouldn't have known this.

If this is seen to be true (I don't have time for checking just now), I think 
it's something we really *should* add to one or more of the related help pages.

Martin Maechler


> 

> Sent: Monday, November 8, 2021 5:37:18 AM
> To: Dario Strbenac 
> Cc: r-package-devel@r-project.org 
> Subject: Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

>> From the line `function(A, B) standardGeneric("SetOfParams")`, A and B 
will
> always have default values of R_MissingArg
> Providing default values within the methods does nothing since A and B 
have
> already been initialized before arriving at the method.
> You could do something like:


> if (missing(A))
> A <- ...
> if (missing(B))
> B <- ...


> within each method, and that would emulate having default values for A and
> B.

> On Mon, Nov 8, 2021 at 12:00 AM Dario Strbenac 

> wrote:

>> Good day,
>> 
>> How can a parameter take a default value from a vector of permitted ones,
>> if it is missing?
>> 
>> setClassUnion("characterOrMissing", c("character", "missing"))
>> setClassUnion("integerOrMissing", c("integer", "missing"))
>> setClass("SetOfParams", representation(A = "characterOrMissing", B =
>> "integer"))
>> setGeneric("SetOfParams", function(A, B) standardGeneric("SetOfParams"))
>> 
>> setMethod("SetOfParams", c("missing", "missing"), function() # Empty 
constructor
>> {
>> new("SetOfParams", A = "M", B = 100L)
>> })
>> 
>> setMethod("SetOfParams", c("characterOrMissing", "integerOrMissing"),
>> function(A = c("L", "M", "N"), B = 100L)
>> {
>> A <- match.arg(A)
>> new("SetOfParams", A = A, B = B)
>> })
>> 
>> SetOfParams(B = 500L)
>> Error in match.arg(A) : argument "A" is missing, with no default.
>> 
>> How can I avoid the error about A having no default? I thought I 
specified
>> it so that it does have one, which match.arg would set for me if the user
>> did not specify one.
>> 
>> --
>> Dario Strbenac
>> University of Sydney
>> Camperdown NSW 2050
>> Australia
>> __
>> R-package-devel@r-project.org mailing list

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

Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

[Georgi Boshnakov]

You need to define  the generic with a default value for this parameter. 
Methods can then have a different default value for it. I remember reading this 
in S4's documentation but don't remember where.

Georgi Boshnakov

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: R-package-devel  on behalf of 
Andrew Simmons 
Sent: Monday, November 8, 2021 5:37:18 AM
To: Dario Strbenac 
Cc: r-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

>From the line `function(A, B) standardGeneric("SetOfParams")`, A and B will
always have default values of R_MissingArg
Providing default values within the methods does nothing since A and B have
already been initialized before arriving at the method.
You could do something like:


if (missing(A))
A <- ...
if (missing(B))
B <- ...


within each method, and that would emulate having default values for A and
B.

On Mon, Nov 8, 2021 at 12:00 AM Dario Strbenac 
wrote:

> Good day,
>
> How can a parameter take a default value from a vector of permitted ones,
> if it is missing?
>
> setClassUnion("characterOrMissing", c("character", "missing"))
> setClassUnion("integerOrMissing", c("integer", "missing"))
> setClass("SetOfParams", representation(A = "characterOrMissing", B =
> "integer"))
> setGeneric("SetOfParams", function(A, B) standardGeneric("SetOfParams"))
>
> setMethod("SetOfParams", c("missing", "missing"), function() # Empty
> constructor
> {
>   new("SetOfParams", A = "M", B = 100L)
> })
>
> setMethod("SetOfParams", c("characterOrMissing", "integerOrMissing"),
> function(A = c("L", "M", "N"), B = 100L)
> {
>   A <- match.arg(A)
>   new("SetOfParams", A = A, B = B)
> })
>
> SetOfParams(B = 500L)
>   Error in match.arg(A) : argument "A" is missing, with no default.
>
> How can I avoid the error about A having no default? I thought I specified
> it so that it does have one, which match.arg would set for me if the user
> did not specify one.
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

[[alternative HTML version deleted]]

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

Re: [Rd] Bug 18208 - tools:::latexToUtf8(tools::parseLatex("\\'i")) should generate í

[Georgi Boshnakov]

Resending this as the original message went out as html and the special 
characters got garbled.

tools:::latexToUtf8() doesn't convert the LaTeX accented character "\\'i" to  í 
(see Bug #18208 https://bugs.r-project.org/show_bug.cgi?id=18208,  reported by 
Manuel López-Ibáñez for details and justification). For example:

> tools:::latexToUtf8(tools::parseLatex("\\'i"))
\'i 

It does the conversion if i is replaced by '\i':

> tools:::latexToUtf8(tools::parseLatex("file:\\'\\i"))
í 


I think that this can be fixed by adding a line to the definition of 
makeLatexTable() in R/src/library/tools/R/parseLatex.R, just before it returns: 

makeLatexTable <- function(utf8table)
{
    ...

    table[["file://textemdash"]] <- "\u2014"
    latexArgCount[["file://textemdash"]] <<- 0

    table$"\\'"$"i"  <- table$"\\'"$"\\i"    # Georgi

    table
}

I can submit a patch if I get access  to bugzilla.

After building R-devel svn 81022 from 2021-10-08 with the above change, we get 
what we want:

> tools:::latexToUtf8(tools::parseLatex("\\'i"))
í 
> tools:::latexToUtf8(tools::parseLatex("\\'\\i"))
í 

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

[Rd] Bug 18208 - tools:::latexToUtf8(tools::parseLatex("\\'i")) should generate í

[Georgi Boshnakov]

tools:::latexToUtf8() doesn't convert the LaTeX accented character 
"\\'i" to  í (see Bug #18208 
https://bugs.r-project.org/show_bug.cgi?id=18208,  reported by Manuel 
López-Ibáñez for details and justification). For example:

> tools:::latexToUtf8(tools::parseLatex("\\'i"))
\'i

It does the conversion if i is replaced by '\i':

> tools:::latexToUtf8(tools::parseLatex("\\'\\i"))
í

Both are acceptable in LaTeX.

I think that this can be fixed by adding a line to the definition of 
makeLatexTable() in R/src/library/tools/R/parseLatex.R, just before it returns:

makeLatexTable <- function(utf8table)
{
...

table[["\\textemdash"]] <- "\u2014"
latexArgCount[["\\textemdash"]] <<- 0

table$"\\'"$"i"  <- table$"\\'"$"\\i"# Georgi

table
}

I can submit a patch if I get access  to bugzilla.

After building R-devel svn 81022 from 2021-10-08 with the above change, we get 
what we want:

> tools:::latexToUtf8(tools::parseLatex("\\'i"))
í
> tools:::latexToUtf8(tools::parseLatex("\\'\\i"))
í
Georgi Boshnakov





[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] submitting package update failed, since old version out of date (?)

[Georgi Boshnakov]

When the previous version has problems, you get an email listing them, followed 
with something like 'Did you fix them? Please Reply-All...'

Maybe you missed the last phrase?

Georgi Boshnakov



Get Outlook for Android<https://aka.ms/AAb9ysg>

From: R-package-devel  on behalf of 
Aisouda Hoshiyar 
Sent: Tuesday, August 17, 2021 12:59:13 PM
To: r-package-devel@r-project.org 
Subject: [R-pkg-devel] submitting package update failed, since old version out 
of date (?)

Hi,

submitting an update of our package ordPens failed (update version is 1.0.0), 
reporting the following:
Version: 1.0.0
ok
Version: 0.3-1
Check: R code for possible problems, Result: NOTE
  genRidge: no visible global function definition for 'plogis'
  ordGene: no visible global function definition for 'anova'
  ordGene: no visible global function definition for 'lm'
  ordSelect: no visible binding for global variable 'sd'
  ordSmooth: no visible binding for global variable 'sd'
  plot.ordPen: no visible global function definition for 'grey'
  plot.ordPen: no visible global function definition for 'devAskNewPage'
  plot.ordPen: no visible global function definition for 'lines'
  predict.ordPen: no visible global function definition for 'plogis'
  Undefined global functions or variables:
anova devAskNewPage grey lines lm plogis sd
  Consider adding
importFrom("grDevices", "devAskNewPage", "grey")
importFrom("graphics", "lines")
importFrom("stats", "anova", "lm", "plogis", "sd")
  to your NAMESPACE file.
Version: 0.3-1
Check: package dependencies, Result: NOTE
  Package suggested but not available for checking: �IsoGene�
https://cran.r-project.org/web/checks/check_results_ordPens.html 
<https://cran.r-project.org/web/checks/check_results_ordPens.html>

https://win-builder.r-project.org/incoming_pretest/ordPens_1.0.0_20210817_114846/Debian/
 
<https://win-builder.r-project.org/incoming_pretest/ordPens_1.0.0_20210817_114846/Debian/>

But these are exactly the new changes that we already took care of in the 
updated version 1.0.0
The previous version 0.3-1 is from 2015 and due to R updates, the old package 
won�t work any more.
That is exactly the reason for update version 1.0.0, were everything is fixed 
now.

Also,
- there is a NOTE about change in maintainer, which is already stated in the 
cran-comments.md, and the previous maintainer sent an e-main to CRAN as well
- there is a NOTE saying 'Examples with CPU (user + system) or elapsed time > 
10s�
which is also stated in the cran-comments.md explaining that cross-validation 
examples are important for illustrating the package usage.


So is this a false positive?

Best
Aisouda





[[alternative HTML version deleted]]

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

[[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] How to debug build-time dynamic documentation issues?

[Georgi Boshnakov]

(Sorry for the previous messages, accidentally sent it prematurely while typing 
on the phone.)

It may be worth checking if the users can install the package if you send them 
(1) tarball or (2) a binary build (if you don't have Windows, win-builder 
creates one). A user had a similar issue with a package of mine and (1) didn't 
work but (2) did. On my Windows laptop I had  similar issue and resolved it by 
updating the packages in the current  installation. 
The reason for the problem seemed to be inconsistent versions of some installed 
packages, almost certainly Matrix and matrixStats in my case.

Georgi Boshnakov


-Original Message-
From: R-package-devel  On Behalf Of 
Georgi Boshnakov
Sent: 13 August 2021 07:47
To: Pavel N. Krivitsky ; R Package Devel 

Subject: Re: [R-pkg-devel] How to debug build-time dynamic documentation issues?

It may be worth checking if the users can install the package if you send them 
(1) tarball or (2) a binary build (if you don't have Windows, win-builder 
creates one).

A user had a similar issue with a package

Get Outlook for Android<https://aka.ms/AAb9ysg> 
From: R-package-devel  on behalf of 
Pavel N. Krivitsky 
Sent: Friday, August 13, 2021 4:06:33 AM
To: R Package Devel 
Subject: [R-pkg-devel] How to debug build-time dynamic documentation issues?

Dear All,

TL;DR: Is there a way to get a full traceback and/or frame dump for errors that 
occur in build-time and install-time \Sexpr{} calls in R documentation files?


# Context

I am working on a package (
https://github.com/joycecheng/ergm/tree/ergm-term-index ) whose documentation 
includes a number of \Sexpr[stage=render]{} calls, and I am getting reports 
that some Windows users are not able to install the package because they get 
errors when the HTML indices are being built.

Complicating the matter is that this only seems to affect some Windows systems 
but not others.

Unfortunately, R's output is not very helpful in identifying the problem beyond 
the help file in which it had occurred and the terminal error message. For 
example, on those systems with R 4.1.0:

remotes::install_github("joycecheng/ergm@ergm-term-index")

gives (for those users):

[SNIP]
ergmConstraint html
Error: incorrect number of dimensions
- removing
'C:/Users/[SNIP]/AppData/Local/Temp/RtmpURZYMP/Rinst1144e5a2698/ergm'
---
ERROR: package installation failed
Error: Failed to install 'ergm' from GitHub:
System command 'Rcmd.exe' failed, exit status: 1, stdout + stderr (last
10 lines):
E> ergm.exact html
E> ergm.geodistdist html
E> ergm.getnetwork html
E> ergm.godfather html
E> ergm.mple html
E> ergmConstraint html
E> Error: incorrect number of dimensions
E> * removing
'C:/Users/[SNIP]/AppData/Local/Temp/RtmpURZYMP/Rinst1144e5a2698/ergm'
E> ---
E> ERROR: package installation failed


# What I've tried so far

 * Running the code in the \Sexpr{} manually in an R session doesn't
   reproduce the error: this seems to be a build/install-time issue.
 * options(error=...) does the wrong thing, because the \Sexpr{} code
   is run inside tryCatch(), so what gets traced and/or dumped is
   catching code, not the original error.

Thanks in advance,
Pavel

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

[[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: [R-pkg-devel] How to debug build-time dynamic documentation issues?

[Georgi Boshnakov]

It may be worth checking if the users can install the package if you send them 
(1) tarball or (2) a binary build (if you don't have Windows, win-builder 
creates one).

A user had a similar issue with a package

Get Outlook for Android

From: R-package-devel  on behalf of 
Pavel N. Krivitsky 
Sent: Friday, August 13, 2021 4:06:33 AM
To: R Package Devel 
Subject: [R-pkg-devel] How to debug build-time dynamic documentation issues?

Dear All,

TL;DR: Is there a way to get a full traceback and/or frame dump for
errors that occur in build-time and install-time \Sexpr{} calls in R
documentation files?


# Context

I am working on a package (
https://github.com/joycecheng/ergm/tree/ergm-term-index ) whose
documentation includes a number of \Sexpr[stage=render]{} calls, and I
am getting reports that some Windows users are not able to install the
package because they get errors when the HTML indices are being built.

Complicating the matter is that this only seems to affect some Windows
systems but not others.

Unfortunately, R's output is not very helpful in identifying the
problem beyond the help file in which it had occurred and the terminal
error message. For example, on those systems with R 4.1.0:

remotes::install_github("joycecheng/ergm@ergm-term-index")

gives (for those users):

[SNIP]
ergmConstraint html
Error: incorrect number of dimensions
- removing
'C:/Users/[SNIP]/AppData/Local/Temp/RtmpURZYMP/Rinst1144e5a2698/ergm'
---
ERROR: package installation failed
Error: Failed to install 'ergm' from GitHub:
System command 'Rcmd.exe' failed, exit status: 1, stdout + stderr (last
10 lines):
E> ergm.exact html
E> ergm.geodistdist html
E> ergm.getnetwork html
E> ergm.godfather html
E> ergm.mple html
E> ergmConstraint html
E> Error: incorrect number of dimensions
E> * removing
'C:/Users/[SNIP]/AppData/Local/Temp/RtmpURZYMP/Rinst1144e5a2698/ergm'
E> ---
E> ERROR: package installation failed


# What I've tried so far

 * Running the code in the \Sexpr{} manually in an R session doesn't
   reproduce the error: this seems to be a build/install-time issue.
 * options(error=...) does the wrong thing, because the \Sexpr{} code
   is run inside tryCatch(), so what gets traced and/or dumped is
   catching code, not the original error.

Thanks in advance,
Pavel

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

[[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] can't reproduce 'Additional issues' on CRAN with valgrind

[Georgi Boshnakov]

Thanks Bill for taking the time to look into this, the patch, and the 
enlightening comments. 
 
I incorporated it and it resolved the valgrind issues. An old compiler issue 
resurfaced (Wstringop-truncation warning from strncopy) whose dodgy fix had 
introduced the current bug but it is now fixed.

As to valgrind, I adapted a Github actions workflow kindly provided by Martin 
R. Smith which reproduced the errors from CRAN. 

Georgi Boshnakov

==

From: Bill Dunlap  
Sent: 07 August 2021 03:09
To: Georgi Boshnakov 
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] can't reproduce 'Additional issues' on CRAN with 
valgrind

I think the following change to str.c, in str_strcpy_internal(), fixes the 
valgrind issues.  It was easier to track down after the calloc() was changed to 
malloc(), since before it only happened after a realloc().
 $ diff -u rbibutils/src/str.c rbibutils-fixed/src/str.c
--- rbibutils/src/str.c 2021-06-16 04:13:48.0 -0700
+++ rbibutils-fixed/src/str.c   2021-08-06 18:38:56.763556500 -0700
@@ -217,8 +217,8 @@
        unsigned long size = str_initlen;
        assert( s );
        if ( minsize > str_initlen ) size = minsize;
-       // 2021-06-16 was: s->data = (char *) malloc( sizeof( *(s->data) ) * 
size );
-       //     changing to calloc() to avoid this kind of error from valgrind:
+       s->data = (char *) malloc( sizeof( *(s->data) ) * size );
+       //     tried changing to calloc() to avoid this kind of error from 
valgrind:
         //      > bibConvert(fn_med, bib, informat = "med")
         //      ==16041== Conditional jump or move depends on uninitialised 
value(s)
         //      ==16041==    at 0x10CCF2A3: xml_processtag (xml.c:174)
@@ -249,8 +249,9 @@
        //
        // TODO:
        //    The data is not really left uninitialised and there may be a 
better way to let the compiler know.
+        // WWD: fixing str_strcpy_internal takes care of memory misuse.
        //
-       s->data = (char *) calloc( size, sizeof( *(s->data) ) );
+       // s->data = (char *) calloc( size, sizeof( *(s->data) ) );
        if ( !s->data ) {
          error("Error.  Cannot allocate memory in str_initalloc, requested %lu 
characters.\n\n", size );
          // error("\n"); // error( EXIT_FAILURE );
@@ -552,9 +553,9 @@
        // Georgi: this fixes the warning about truncation in strncpy
        //   strcpy cannot be used here since at least one of the calls below
        //   passes a non-NULL terminated 'p'
-       strncpy( s->data, p, n + 1);
-       // strncpy( s->data, p, n );
-       // s->data[n] = '\0';
+       // strncpy( s->data, p, n + 1); // WWD: ???
+       strncpy( s->data, p, n );
+       s->data[n] = '\0';
        s->len = n;
 }

I don't know why valgrind isn't working for you.

-Bill

On Mon, Aug 2, 2021 at 4:23 PM Georgi Boshnakov 
<mailto:georgi.boshna...@manchester.ac.uk> wrote:
Thanks for looking into this. I probably didn’t make it clear that I am not 
questioning the errors on CRAN but my own configuration. I have pretty good 
idea where the error comes from, since the only change from the previous CRAN 
version was in medin.c (function medin_readf from line 94 and most probably 
line 144-145). I think also that all errors have medin.c on the trace.
 
It would be very helpful if somebody can spot from the description of my 
configuration in the original email where I have gone wrong in the setup of R 
with valgrind.
 
>realloc() does not initialize memory.  str.c contains a comment about 
>replacing malloc() with calloc() to avoid…
 
    //    The data is not really left uninitialised and there may be a 
better way to let the compiler know.
    //
    s->data = (char *) calloc( size, sizeof( *(s->data) ) );
    if ( !s->data ) {
      error("Error.  Cannot allocate memory in str_initalloc, requested 
%lu characters.\n\n", size );
      // error("\n"); // error( EXIT_FAILURE );
    }
    s->data[0]='\0';
    s->dim=size;
    s->len=0;
 
My comment is indeed sloppy but the first byte is initialised to zero and the 
rest is used for writing only
(valgrind has no way to know, of course, and it is fair to question how a human 
can possibly be sure).
 
 
Thanks again,
Georgi Boshnakov
 
 
From: Bill Dunlap <mailto:williamwdun...@gmail.com> 
Sent: 02 August 2021 19:48
To: Georgi Boshnakov <mailto:georgi.boshna...@manchester.ac.uk>
Cc: mailto:r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] can't reproduce 'Additional issues' on CRAN with 
valgrind
 
I ran the tests of rbibutils-2.2.2, using the latest devel version of R 
configured to use valgrind, with
 
R --debugger=valgrind --debugger-args=--track-origins=yes --quiet -e 
'testthat::test_package("rbibutils")'
 
I saw a lot of

Re: [R-pkg-devel] can't reproduce 'Additional issues' on CRAN with valgrind

[Georgi Boshnakov]

Thanks for looking into this. I probably didn’t make it clear that I am not 
questioning the errors on CRAN but my own configuration. I have pretty good 
idea where the error comes from, since the only change from the previous CRAN 
version was in medin.c (function medin_readf from line 94 and most probably 
line 144-145). I think also that all errors have medin.c on the trace.

It would be very helpful if somebody can spot from the description of my 
configuration in the original email where I have gone wrong in the setup of R 
with valgrind.

>realloc() does not initialize memory.  str.c contains a comment about 
>replacing malloc() with calloc() to avoid…

//The data is not really left uninitialised and there may be a 
better way to let the compiler know.
//
s->data = (char *) calloc( size, sizeof( *(s->data) ) );
if ( !s->data ) {
  error("Error.  Cannot allocate memory in str_initalloc, requested 
%lu characters.\n\n", size );
  // error("\n"); // error( EXIT_FAILURE );
}
s->data[0]='\0';
s->dim=size;
s->len=0;

My comment is indeed sloppy but the first byte is initialised to zero and the 
rest is used for writing only
(valgrind has no way to know, of course, and it is fair to question how a human 
can possibly be sure).


Thanks again,
Georgi Boshnakov


From: Bill Dunlap 
Sent: 02 August 2021 19:48
To: Georgi Boshnakov 
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] can't reproduce 'Additional issues' on CRAN with 
valgrind

I ran the tests of rbibutils-2.2.2, using the latest devel version of R 
configured to use valgrind, with

R --debugger=valgrind --debugger-args=--track-origins=yes --quiet -e 
'testthat::test_package("rbibutils")'

I saw a lot of 'conditional jump depends on uninitialized value' errors:

==27280== Conditional jump or move depends on uninitialised value(s)
==27280==at 0x11C420B7: UnknownInlinedFun (xml.c:178)
==27280==by 0x11C420B7: xml_parse (xml.c:241)
==27280==by 0x11C514EF: medin_processf (medin.c:683)
==27280==by 0x11C67ADE: UnknownInlinedFun (bibcore.c:479)
==27280==by 0x11C67ADE: bibl_read.part.0 (bibcore.c:862)
==27280==by 0x11C68C66: bibprog (bibprog.c:36)
==27280==by 0x11C69327: any2xml_main (any2xml.c:127)
==27280==by 0x307639: do_dotCode (dotcode.c:1814)
==27280==by 0x2B4600: bcEval.lto_priv.0 (eval.c:7128)
==27280==by 0x2DADB7: Rf_eval (eval.c:740)
==27280==by 0x2DD28E: R_execClosure.lto_priv.0 (eval.c:1910)
==27280==by 0x2DE1EC: Rf_applyClosure (eval.c:1836)
==27280==by 0x2DAFD3: Rf_eval (eval.c:863)
==27280==by 0x2D7F22: do_begin (eval.c:2530)
==27280==  Uninitialised value was created by a heap allocation
==27280==at 0x483DFAF: realloc (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==27280==by 0x11C38DB2: str_realloc.part.0 (str.c:90)
==27280==by 0x11C3B63D: UnknownInlinedFun (str.c:85)
==27280==by 0x11C3B63D: UnknownInlinedFun (str.c:543)
==27280==by 0x11C3B63D: UnknownInlinedFun (str.c:551)
==27280==by 0x11C3B63D: UnknownInlinedFun (str.c:547)
==27280==by 0x11C3B63D: UnknownInlinedFun (str.c:607)
==27280==by 0x11C3B63D: str_segcpy (str.c:585)
==27280==by 0x11C4DDFA: medin_readf (medin.c:144)
==27280==by 0x11C67A96: UnknownInlinedFun (bibcore.c:471)
==27280==by 0x11C67A96: bibl_read.part.0 (bibcore.c:862)
==27280==by 0x11C68C66: bibprog (bibprog.c:36)
==27280==by 0x11C69327: any2xml_main (any2xml.c:127)
==27280==by 0x307639: do_dotCode (dotcode.c:1814)

realloc() does not initialize memory.  str.c contains a comment about replacing 
malloc() with calloc() to avoid similar problems that valgrind found.  It 
states that valgrind is mistaken, that that memory really is initialized.  Hmm.

I also see the error about reading off the end of a malloc'ed array:

==27280== Invalid read of size 1
==27280==at 0x11C420A8: UnknownInlinedFun (xml.c:174)
==27280==by 0x11C420A8: xml_parse (xml.c:241)
==27280==by 0x11C514EF: medin_processf (medin.c:683)
==27280==by 0x11C67ADE: UnknownInlinedFun (bibcore.c:479)
==27280==by 0x11C67ADE: bibl_read.part.0 (bibcore.c:862)
==27280==by 0x11C68C66: bibprog (bibprog.c:36)
==27280==by 0x11C69327: any2xml_main (any2xml.c:127)
==27280==by 0x307639: do_dotCode (dotcode.c:1814)
==27280==by 0x2B4600: bcEval.lto_priv.0 (eval.c:7128)
==27280==by 0x2DADB7: Rf_eval (eval.c:740)
==27280==by 0x2DD28E: R_execClosure.lto_priv.0 (eval.c:1910)
==27280==by 0x2DE1EC: Rf_applyClosure (eval.c:1836)
==27280==by 0x2DAFD3: Rf_eval (eval.c:863)
==27280==by 0x2D7F22: do_begin (eval.c:2530)
==27280==  Address 0x125028af is 0 bytes after a block of size 10,927 alloc'd
==27280==at 0x483DD99: calloc (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==27280

[R-pkg-devel] can't reproduce 'Additional issues' on CRAN with valgrind

[Georgi Boshnakov]

An update to my package rbibutils triggered 'Additional issues' on CRAN from 
valgrind, CRAN Package Check Results for Package rbibutils 
(r-project.org)<https://cran.r-project.org/web/checks/check_results_rbibutils.html>.

However, running the checks with -use-valgrind  on my machine gives zero errors.
I am on Ubuntu (the latest stable version), my R-devel installation was updated 
earlier today and I rebuild it adding the
--with-valgrind-instrumentation=2 to the call to configure.
Valgrind coming with Ubuntu is 3.5.0, so I installed its latest version from  
github (also no errors).

rbibutils has no dependencies, except that testthat is used for testing.

What am I missing? Do I need to have a separate library for the instrumented 
R-devel version?

As a side note, is there a way to find out if R has been built with valgrind? 
It seems that 'capabilities()' and 'R CMD config' do not offer this information.

Thanks,
Georgi Boshnakov

[[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] Scrapping R CRAN website from package

[Georgi Boshnakov]

If you need only DESCRIPTION, you can get it from github/cran - just open the 
file in any package and see how its web address is formed. There is a small 
delay between a package appearing on CRAN and it being mirrowed on github/CRAN 
though.

For caching strategies you could check, for example, revdepcheck (which does it 
on an epic scale).

Georgi Boshnakov

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: R-package-devel  on behalf of 
Maciej Nasinski 
Sent: Friday, July 16, 2021 11:13:50 AM
To: r-package-devel@r-project.org 
Subject: [R-pkg-devel] Scrapping R CRAN website from package

Dear Sir or Madam,

I am creating a new package `pacs` https://github.com/Polkas/pacs, which
I want to send to R CRAN shortly. However I am not sure about R
CRAN policy regarding scraping CRAN per package page with its archive.
More precisely I am fetching the data from
https://CRAN.R-project.org/package=%s and
https://cran.r-project.org/src/contrib/Archive/%s/ (downloading an old
tar.gz too).

Why I need this: I could read any DESCRIPTION files for any time point and
get a true dependency tree.  Moreover I could get a life duration of any
released package version, where shorter than 7 days are marked as risky. I
could compare a package min required dependencies difference before we
update it.  And much more.

I made a few notices like "Please as a courtesy to the R CRAN, don't
overload their server by constantly using this function." inside the
package.

Optionally If scrapping R CRAN from my package is a problem I will try to
build a separate DB with such data (updated everyday). Still any old tar.gz
has to be downloaded.

Maciej Nasinski, University of Warsaw

[[alternative HTML version deleted]]

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

[[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] How to communicate WARNINGS fixed from *last* CRAN version of a package

[Georgi Boshnakov]

>... Hence please reply-all and explain: Have these been fixed?

Maybe 'reply-all' to CRAN team's  email?

Georgi Boshnakov

-Original Message-
From: R-package-devel  On Behalf Of 
Alberto Garre
Sent: 22 June 2021 09:11
To: R-package-devel@r-project.org
Subject: [R-pkg-devel] How to communicate WARNINGS fixed from *last* CRAN 
version of a package

Hi,

I submitted yesterday a new version of the biogrowth package ( 
https://cran.r-project.org/package=biogrowth). In the automatic response, I got 
the following message:

The auto-check found additional issues for the *last* version released on
CRAN:
  donttest <https://www.stats.ox.ac.uk/pub/bdr/donttest/biogrowth.out>
  M1mac <https://www.stats.ox.ac.uk/pub/bdr/M1mac/biogrowth.out>
CRAN incoming checks do not test for these additional issues.
Hence please reply-all and explain: Have these been fixed?

I resubmitted mentioning in cran-comments.md that these problems had been 
resolved, but I got again the same automatic response. Then, I answered 
directly to the automatic email with no effect.

How should I communicate these issues have been fixed? Is there any additional 
issue I am not seeing?

Thank you,
Alberto

[[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: [R-pkg-devel] Troubleshoot unknown macro '\backslashemph' warning

[Georgi Boshnakov]

This is probably from Rdpack (actually, 'rbibutils', see below). Several 
references in your REFERENCES.bib contain \emph In 'title' fields. The 
backslash in \emph is converted to \backslash, resulting in \backslashemph. 

This looks like a bug, please open an issue on github (for Rdpack or rbibutils).

Georgi Boshnakov

===
diwan <- "@article{diwan_methods_1995,
title = {Methods of developing a core collection of annual \\emph{{Medicago}} 
species}, volume = {90}, language = {en}, number = {6}, journal = {Theoretical 
and Applied Genetics}, author = {Diwan, N. and McIntosh, M. S. and Bauchan, G. 
R.}, month = may, year = {1995}, keywords = {Annual Medicago species, Core 
collection, Germplasm collection, Relative Diversity method}, pages = 
{755--761} }"

rbibutils::charToBib(diwan) # devel version on github, otherwise use readBib(() 
to read from file.

## Diwan N, McIntosh MS, Bauchan GR (1995). "Methods of developing a core ## 
collection of annual \backslashemph{{Medicago}} species." _Theoretical ## and 
Applied Genetics_, *90*(6), 755-761.



-Original Message-
From: R-package-devel  On Behalf Of 
Aravind J.
Sent: 23 May 2021 20:21
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Troubleshoot unknown macro '\backslashemph' warning

Hi,

While checking two of my packages
(https://github.com/aravind-j/EvaluateCore and 
https://github.com/aravind-j/augmentedRCBD)with winbuilder while preparing for 
submitting an updated version, I am getting the following warning.


* checking Rd files ... [4s] WARNING
prepare_Rd: :2: unknown macro '\backslashemph'
prepare_Rd: :6: unknown macro '\backslashemph'
prepare_Rd: :2: unknown macro '\backslashemph'
prepare_Rd: :4: unknown macro '\backslashemph

I am not able to find the offending macros anywhere in the Rd files being 
generated. I am using two RdMacros, mathjaxr and Rdpack.

How to troubleshoot?

-- 

J.Aravind
Scientist,
Division of Germplasm Conservation,
ICAR-National Bureau of Plant Genetic Resources, New Delhi - 110 012

[[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: [R-pkg-devel] Another newbie question: vignettes not appearing in GitHub hosted package

[Georgi Boshnakov]

Vignettes are not built by default when using remotes::install_github, request 
it explicitly:

remotes::install_github("cpsyctc/CECPfuns", build_vignettes = TRUE)

Georgi Boshnakov


-Original Message-
From: R-package-devel  On Behalf Of 
Chris Evans
Sent: 14 April 2021 17:53
To: r-package-devel 
Subject: [R-pkg-devel] Another newbie question: vignettes not appearing in 
GitHub hosted package

As ever, my package is https://github.com/cpsyctc/CECPfuns and I am building 
withing Rstudio 1.4.1103 

I am aiming for the package to have fairly comprehensive vignettes and there 
are four now, but two are very incomplete. 

The problem I have may relate to 
https://github.com/Kenkleinman/clusterPower/issues/113 and to
https://github.com/rstudio/rstudio/issues/1766 or it may not. I have a nasty 
feeling that I am just looking straight through something obvious. 

When I run
browseVignettes(package = "CECPfuns")
within Rstudio working on the package I see the vignettes and I have now got 
pkgdown working to compile the lovely web site around the package (at 
https://cecpfuns.psyctc.org/) and I see the vignettes there and they update. 

The bizarre thing that is beating me is that when I pull the package down to 
any machine with
remotes::install_github("cpsyctc/CECPfuns")
gets the function but no vignettes! Here's an example from my little Pi 
machine: 

> remotes::install_github("cpsyctc/CECPfuns")
Downloading GitHub repo cpsyctc/CECPfuns@HEAD ✔ checking for file 
‘/tmp/RtmpPhD1Rg/remotes294e1d1ff9d6/cpsyctc-CECPfuns-ab23518/DESCRIPTION’ 
(722ms) ─ preparing ‘CECPfuns’: 
✔ checking DESCRIPTION meta-information ... 
─ installing the package to process help pages ─ checking for LF line-endings 
in source and make files and shell scripts (13.7s) ─ checking for empty or 
unneeded directories ─ looking to see if a ‘data/datalist’ file should be added 
─ building ‘CECPfuns_0.0.0.9041.tar.gz’ 

* installing *source* package ‘CECPfuns’ ... 
** using staged installation
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (CECPfuns) 
> browseVignettes(package = "CECPfuns")
No vignettes found by browseVignettes(package = "CECPfuns") 

I hope someone can see what I'm doing wrong! As ever, TIA, 

Chris 

-- 
Chris Evans (he/him)  Visiting Professor, University of 
Sheffield  
I do some consultation work for the University of Roehampton 
 and other places 
but  remains my main Email address. I have a work web site 
at: 
https://www.psyctc.org/psyctc/ 
and a site I manage for CORE and CORE system trust at: 
http://www.coresystemtrust.org.uk/ 
I have "semigrated" to France, see: 
https://www.psyctc.org/pelerinage2016/semigrating-to-france/ 
https://www.psyctc.org/pelerinage2016/register-to-get-updates-from-pelerinage2016/
 

If you want an Emeeting, I am trying to keep them to Thursdays and my diary is 
at: 
https://www.psyctc.org/pelerinage2016/ceworkdiary/ 
Beware: French time, generally an hour ahead of UK. 

__
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] Problem with S4 method for plotting a raster file

[Georgi Boshnakov]

> library(DEPONS2R)
> 
> data("bathymetry")
> plot(bathymetry)
> data("coastline")
> library(rgdal)
> # Change projection of coastline to match that of bathymetry data
> coastline2 <- spTransform(coastline, crs(bathymetry)) plot(coastline2, 
> add=TRUE, col="lightyellow2")

The inclusion of 'library(rgdal)' above suggests that your plot method needs 
something from 'rgdal'. If that something is a plot method from that package, 
it may not be visible from your function (due to changes introduced in R-4.0.0, 
search NEWS for R-4.0.0 'plot'), you would need to import plot methods from 
rgdal if that is the case (and maybe move rgdal from Suggests to Imports). 

Georgi Boshnakov


-Original Message-
From: R-package-devel  On Behalf Of 
Duncan Murdoch
Sent: 14 April 2021 13:45
To: Jacob Nabe-Nielsen ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Problem with S4 method for plotting a raster file

On 14/04/2021 5:41 a.m., Jacob Nabe-Nielsen wrote:
> Dear all,
> 
> I have just discovered an error in a package that I have already 
> uploaded to CRAN, and cannot figure out how to fix it. All help will be 
> greatly appreciated.
> The package is called DEPONS2R, and is available from:
> https://cran.r-project.org/web/packages/DEPONS2R/index.html
> 
> The problem is related to one of the included examples, where I plot 
> the coastline on top of a raster file. In the example, where the 
> plotting is embedded in an S4 method called plot.DeponsRaster, the 
> coastline does not show. But if I run the functions that the method is 
> composed of, everything works fine (see below). So I am wondering if 
> the graphics devise is not passed on correctly within the package, or what 
> actually happens.
> 
> The example that does not run correctly is available from ?plot.DeponsRaster:
> 
> library(DEPONS2R)
> 
> data("bathymetry")
> plot(bathymetry)
> data("coastline")
> library(rgdal)
> # Change projection of coastline to match that of bathymetry data
> coastline2 <- spTransform(coastline, crs(bathymetry)) plot(coastline2, 
> add=TRUE, col="lightyellow2")
> 
> 
> Here the coastline is not plotted. The method is defined as:
> 
> 
> setMethod("plot", signature("DeponsRaster", "ANY"),
>function(x, y, maxpixels=50, col, alpha=NULL, colNA=NA, 
> add=FALSE,
> ext=NULL, useRaster=TRUE, interpolate=FALSE, addfun=NULL,
> nc, nr, maxnl=16, main, npretty=0, axes=TRUE,
> legend=TRUE, trackToPlot=1, ...)  {
>  oldpar <- graphics::par(no.readonly = TRUE)
>  on.exit(graphics::par(oldpar))
>  if (missing(main)) {
>main <- paste(x@landscape, x@type, sep=" - ")
>  }
>  # Define colours specific or 'type'
>  if(missing(col) && x@type=="bathymetry") {
>tmp.col <- grDevices::rainbow(1000)[501:800]
>col <- c(tmp.col[1:100], rep(tmp.col[101:250], each=5))
>  }
>  # Use {raster}-package for plotting
>  if(x@crs=="NA") {
>crs2 <- sp::CRS(as.character(NA))
>  } else {
>crs2 <- sp::CRS(x@crs)
>  }
>  rdata <- raster::raster(x=x@data, xmn=x@ext$xleft, 
> xmx=x@ext$xright,
>  ymn=x@ext$ybottom, ymx=x@ext$ytop,
>  crs=crs2)
>  raster::plot(rdata, col=col, main=main,
>   alpha=alpha, add=add, ext=ext, axes=axes, 
> legend=legend)
>}
> )
> 
> 
> But when I use the functions that are at the core of this method it is 
> not a problem adding the coastline correctly:
> 
> x <- bathymetry
> crs2 <- raster::crs(x@crs)
> rdata <- raster::raster(x = x@data, xmn = x@ext$xleft, xmx = 
> x@ext$xright, ymn = x@ext$ybottom, ymx = x@ext$ytop, crs = crs2)
> raster::plot(rdata)
> plot(coastline2, add=TRUE, col="lightyellow2")
> 
> If would be fantastic if someone can figure out how I should modify 
> the method to plot the coastline correctly on top of the map.
> 
> 

I'm not sure exactly what is going wrong, but if you plot the coastline first 
and the bathymetry second, things do show up.  Maybe that's enough of a hint 
for you:

library(DEPONS2R)
data("coastline")
library(rgdal)
coastline2 <- spTransform(coastline, crs(bathymetry)) plot(coastline2, 
col="lightyellow2")

data("bathymetry")
plot(bathymetry, add=TRUE)

This puts the legend on top of the plotted coastline data, so my guess is that 
the limits of the bathymetry plot aren't being made available to the coastline 
plot when you do things in the original order.

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: [R-pkg-devel] CRAN note about \href{https://doi.org/...}{label} in Rd files

[Georgi Boshnakov]

> When running R CMD check on R-devel, a CRAN note appears about 
> \href{https://doi.org/...}{label} in Rd files...
>... Can this be resolved using \doi{} as suggested, while still resulting in a 
>working link to doi.org? I didn't find a way to do that.

This is a recent addition to R checks. I am pretty sure that \doi{} with the 
suggested syntax does produce proper links in the documentation.

Georgi Boshnakov

-Original Message-
From: R-package-devel  On Behalf Of 
Floris Vanderhaeghe
Sent: 30 March 2021 14:45
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] CRAN note about \href{https://doi.org/...}{label} in Rd 
files

Hi,

When running R CMD check on R-devel, a CRAN note appears about 
\href{https://doi.org/...}{label} in Rd files. Like:

Found the following URLs which should use \doi (with the DOI name only):
   File ‘read_GRTSmh.Rd’:
     https://doi.org/10.5281/zenodo.2611233
     https://doi.org/10.5281/zenodo.3354403
   File ‘read_GRTSmh_base4frac.Rd’:
     https://doi.org/10.5281/zenodo.3354401

(Full output is at
https://github.com/inbo/n2khab/runs/2219662325?check_suite_focus=true#step:10:35)

The note does not appear in R 4.0.4.

The cause is documentation hyperlinks to doi.org, ** inside \href{} **:

./man/read_GRTSmh.Rd:42:\href{https://doi.org/10.5281/zenodo.2611233}{Zenodo},
is a monolayered GeoTIFF
./man/read_GRTSmh.Rd:73:\href{https://doi.org/10.5281/zenodo.3354403}{Zenodo},
and can only be
./man/read_GRTSmh_base4frac.Rd:33:\href{https://doi.org/10.5281/zenodo.3354401}{Zenodo}.
./man/read_GRTSmh_diffres.Rd:45:at
\href{https://doi.org/10.5281/zenodo.3354405}{Zenodo}), composed of 
./man/read_habitatmap_stdized.Rd:68:\href{https://doi.org/10.5281/zenodo.3355192}{Zenodo},
that
./man/read_habitatmap_terr.Rd:117:\href{https://doi.org/10.5281/zenodo.3468948}{Zenodo},
that contains:
./man/read_habitatquarries.Rd:70:\href{https://doi.org/10.5281/zenodo.4072967}{Zenodo},
that contains:
./man/read_habitatsprings.Rd:83:\href{https://doi.org/10.5281/zenodo.3550994}{Zenodo}.
./man/read_soilmap.Rd:225:\href{https://doi.org/10.5281/zenodo.3732903}{Zenodo}.
./man/read_watercourse_100mseg.Rd:73:\href{https://doi.org/10.5281/zenodo.4452577}{Zenodo},
and contains two
./man/read_watercourse_100mseg.Rd:83:\href{https://doi.org/10.5281/zenodo.4420904}{\code{watercourses}}
data
./man/read_watersurfaces_hab.Rd:66:\href{https://doi.org/10.5281/zenodo.3386857}{watersurface
map of Flanders}.
./man/read_watersurfaces_hab.Rd:71:\href{https://doi.org/10.5281/zenodo.3374645}{Zenodo},
that contains:


Can this be resolved using \doi{} as suggested, while still resulting in a 
working link to doi.org? I didn't find a way to do that.

Perhaps a 'https://doi.org' address which does not show as such in the 
documentation (because of the clickable label) should still be allowed.


With regards

Floris Vanderhaeghe

__
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 (newbie/luser) questions about adding CI to github hosted package

[Georgi Boshnakov]

>  ── R CMD build 
> ─
>  * checking DESCRIPTION meta-information ... OK
> Error in 
> parse_Rd("/tmp/RtmpydYbB0/Rbuild4d3e1cce5e37/CECPfuns/man/getCSC.Rd",  : 
>   Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
> Execution halted
> Error: Error in proc$get_built_file() : Build process failed
>  Calls:  ... build_package -> with_envvar -> force -> 
>  Execution halted
 > Error: Process completed with exit code 1.

The error seems to be in building the documentation. There used to be a buglet 
in older versions of R, 
that caused some errors in processing to cause this kind of uninformative 
message from low level code. 
I don't remember the R version but the time frame seems consistent. 
It may well be that some \Sexpr code is spread over more than one line, which 
sometimes threw errors, sometimes silently ignored the lines after the first.

Maybe it's easiest just to require R >= "more recent version.

Georgi Boshnakov


-Original Message-
From: R-package-devel  On Behalf Of Dirk 
Eddelbuettel
Sent: 16 March 2021 12:46
To: Duncan Murdoch 
Cc: r-package-devel 
Subject: Re: [R-pkg-devel] Two (newbie/luser) questions about adding CI to 
github hosted package


On 16 March 2021 at 06:48, Duncan Murdoch wrote:
| On 16/03/2021 5:58 a.m., Chris Evans wrote:
| You have 5 workflows, and their current content doesn't appear to 
| match the results on your actions page.  Pick one, run it, and I'll 
| see if I can spot the reason for a failure.

More granularly, one of these five workflow spawns nine builds of which the 
ones with older R version (3.3, 3.4, 3.5) fail as seen eg for run #3:

https://github.com/cpsyctc/CECPfuns/actions/runs/657501549

Maybe you want to comment out runs for R versions that old, or debug why they 
fail. The error shown in R 3.5 (a version soon three years out of date you are 
not obliged to care for: CRAN uses only current, previous and next
release) is not something I have seen before:

  ── R CMD build 
─
  * checking for file ‘.../DESCRIPTION’ ... OK
  * preparing ‘CECPfuns’:
  * checking DESCRIPTION meta-information ... OK
  Error in 
parse_Rd("/tmp/RtmpydYbB0/Rbuild4d3e1cce5e37/CECPfuns/man/getCSC.Rd",  : 
Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
  Execution halted
  Error: Error in proc$get_built_file() : Build process failed
  Calls:  ... build_package -> with_envvar -> force -> 
  Execution halted
  Error: Process completed with exit code 1.

Here proce$get_built_file points to `pkgbuild` which is part of a non-CRAN 
toolchain.  So this may not be caused by your package -- I can't tell. My 
preference is to keep it simpler: I usually get by with one workflow and 
generally at most two builds.

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

[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

[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: [R-pkg-devel] How to build *-package description from *-package.R files ... and a luser/newbie question about pkgdown

[Georgi Boshnakov]

Please note that most rooygen2 users don't call the overview file 
'pkgname-package' but just 'pkgname'. 
Also, these days people mostly use README.md for approximately that purpose and 
put a very minimal statement in pkgname-package or equivalent.

Georgi Boshnakov

-Original Message-
From: R-package-devel  On Behalf Of 
Chris Evans
Sent: 12 February 2021 15:52
To: Duncan Murdoch 
Cc: r-package-devel 
Subject: Re: [R-pkg-devel] How to build *-package description from *-package.R 
files ... and a luser/newbie question about pkgdown

Apologies, I think that was clear.   

Do you or anyone else have an example of a -package.R that Rstudio's check 
has built into a package documentation file that was well populated and useful?

I think that's the key exemplar I am seeking and I'm finding it hard to craft 
any web search that finds me such a thing.

Any offer?!  TIA,

Chris

- Original Message -
> From: "Duncan Murdoch" 
> To: "Chris Evans" 
> Cc: "r-package-devel" 
> Sent: Friday, 12 February, 2021 15:40:25
> Subject: Re: [R-pkg-devel] How to build *-package description from 
> *-package.R files ... and a luser/newbie question about pkgdown

> Just one clarification:
> 
> On 12/02/2021 9:59 a.m., Chris Evans wrote:
> [ lots deleted ]
> 
>>>   - I don't think RStudio supports a "Preview" for the help page for 
>>> a function (but I might be wrong about this, since I don't use it much).
>> 
>> I haven't found it if it is there.  I'm guessing you use ESS?
> 
> No, I use RStudio.  When I said "I don't use it much", I meant Roxygen2.
> 
> Duncan Murdoch

--
Small contribution in our coronavirus rigours: 
https://www.coresystemtrust.org.uk/home/free-options-to-replace-paper-core-forms-during-the-coronavirus-pandemic/

Chris Evans  Visiting Professor, University of Sheffield 
 I do some consultation work for the University of 
Roehampton  and other places but 
 remains my main Email address.  I have a work web site at:
   https://www.psyctc.org/psyctc/
and a site I manage for CORE and CORE system trust at:
   http://www.coresystemtrust.org.uk/
I have "semigrated" to France, see: 
   https://www.psyctc.org/pelerinage2016/semigrating-to-france/ 
   
https://www.psyctc.org/pelerinage2016/register-to-get-updates-from-pelerinage2016/

If you want an Emeeting, I am trying to keep them to Thursdays and my diary is 
at:
   https://www.psyctc.org/pelerinage2016/ceworkdiary/
Beware: French time, generally an hour ahead of UK.

__
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] How to build *-package description from *-package.R files ... and a luser/newbie question about pkgdown

[Georgi Boshnakov]

Regarding 'pkgdown', can't you just use the default directory , docs/, that 
pkgdown populates? When you push to your repository, github will automatically 
regenerate the pkgdown website (for this to work, you need to go to the 
settings on your github repo and activate building the website). 

As to documentation, go to the github site of pkgdown and start from there. To 
customise the site, you can add an yaml file, as documented in pkgdown. 

I am not sure why you wish to use DIY directory for the site generated by 
pkgdown. When you run build_site(), pkgdown builds it and opens it in a browser 
by default. Also, it only rebuilds the pages that have changed since the 
previous built. So, it is useful also during development. I don't remember at 
the moment if you could even set it up to watch for changes in the package and 
rebuild the site behind the scene. 


Georgi Boshnakov


-Original Message-
From: R-package-devel  On Behalf Of 
Duncan Murdoch
Sent: 12 February 2021 13:50
To: Chris Evans ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] How to build *-package description from *-package.R 
files ... and a luser/newbie question about pkgdown

On 12/02/2021 6:28 a.m., Chris Evans wrote:
> This feels embarrassingly trivial compared with most of the posts I try to 
> understand here: apologies.
> 
> I am taking my first clumsy steps to build my own library of source code 
> functions I have created and use a lot and want to share with a few 
> collaborators.  I tried once before, a few years ago and failed to show the 
> perseverance to succeed.  With help from so many wonderful tools so many 
> people have created, and working in Rstudio, I do now have a package with 
> some functions that work and a bit of function documentation.  It's at 
> https://github.com/cpsyctc/CECPfuns if that helps anyone help me with my 
> questions below ... if you do look you'll see it's just a baby steps as yet 
> and there's a huge amount still to do.
> 
> Q1: I don't envisage it ever going beyond github but I would still like to 
> document it well.  I am starting to understand documenting functions using 
> the Code, Document in Rstudio and seem to have found good examples and 
> documentation for that.  However, I am failing to find similar information 
> about creating the CECPfuns-package documentation I would like to build.  I 
> have a CECPfuns-package.R that I think I created with a packaged function 
> that generates that skeleton (embarrassingly, I have forgotten now what that 
> was).   I think that created my CECPfuns-package.Rd so I do have a vestigial 
> answer to CECPfuns-package.  I also have a CECPfuns-package.Rd file generated 
> with utils::promptPackage but I have left this in my package root directory 
> (against the warning note) as it looks as if people recommend creating 
> package documentation from *-package.R files in the R directory and I guess 
> I'd prefer not to have to learn .Rd syntax if I can stick with working from R 
> (or Rmd?).  I did
  c
>   reate a minimal one but CECPfuns.R (in the R directory) but I'm not sure 
> what syntax I should be using to build on that.  So ...  I would really like 
> to find advice on how to build CECPfuns-package docucmentation from that file 
> or I'd love it if someone has created package documentation from a 
> *-package.R file they'd be willing to share with me.

There are two general approaches for writing help pages in R.

The older approach (that I use) is to use functions like prompt() and
promptPackage() to create skeletons of documentation in the man directory, then 
edit them by hand.  The main disadvantage of this approach is that the Rd 
format is pretty ugly:  it's kind of like LaTeX, but different enough that even 
if you know LaTeX, you'll have to spend some time learning it.  It's also a bit 
of a pain to keep your documentation in sync with your source code:  when you 
change the arguments to a function, you don't get automatic changes to the help 
page.

RStudio has pretty good support for this approach, in that you can preview the 
pages as you work on them, it knows a bit about their syntax so things are 
highlighted nicely, and there are easy methods to jump from a function to the 
corresponding .Rd file.

To set this up you uncheck the "Generate documentation with ROxygen" 
option in the project build tools options.  That's it!

The approach that a lot of newer packages use is to generate the .Rd files from 
comments in the .R files using Roxygen2.  In recent versions of Roxygen2, what 
you type can be entered in Markdown instead of Rd format.  Some parts of the Rd 
file will be generated automatically, so you don't need to type them at all:  
that's another advantage.

What I don't like about this approach is:

  - Mixing source code and documentation makes your source files bigger which 
discourages ca

Re: [R-pkg-devel] CRAN check texi2dvi failure

[Georgi Boshnakov]

The problem is not in the Warning from the example but from the \verb commands 
in the references.
You use space to delimit the argument of \verb and I was surprised that it 
worked since TeX ignores spaces after commands. 
Apparently, this has been an exception for \verb but now this feature is 
considered a bug and hs been recently fixed, see the atacjexchange question 
below and the relevant paragraph from LaTeX News. Probably the linux machines 
have updated their TeX installations.

In short, changing the space tp  say  +  delimiter for \verb command should fix 
the issue.

Georgi Boshnakov

 
https://tex.stackexchange.com/questions/566085/how-does-verb-detect-spaces-that-shouldnt-exist
 

Avoid problematic spaces after \verb
If a user typed \verb␣!~!␣foo instead of \verb!~!␣foo
by mistake, then surprisingly the result was “!~!foo”
without any warning or error. What happened was that
the ␣ became the argument delimiter due to the rather
complex processing done by \verb to render verbatim.
This has been fixed and spaces directly following the
command \verb or \verb* are now ignored as elsewhere.
(github issue 327)


-Original Message-
From: R-package-devel  On Behalf Of Paul 
Gilbert
Sent: 09 January 2021 21:44
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] CRAN check texi2dvi failure

I am trying to debug a problem that is appearing in the linux and Solaris 
checks, but not Windows or Mac checks, of my package tsfa as reported at 
https://cran.r-project.org/web/checks/check_results_tsfa.html

The problem is with re-building the vignette
   ...
   this is package 'tsfa' version '2014.10-1'
   ...
  checking re-building of vignette outputs ... [6s/9s] WARNING
  Error(s) in re-building vignettes:
   ...
 Running 'texi2dvi' on 'Guide.tex' failed.
 LaTeX errors:
 ! LaTeX Error: \verb ended by end of line.
   ...

In responding to the threat of removal I have also fixes some long standing 
warnings about adding imports to the NAMESPACE. The new version builds with 
--as-cran giving no errors or warnings with both R-devel on win-builder 
(2021-01-07 r79806) and on my linux machine (R 2021-01-08
r79812 on Linux Mint 19.3 Tricia). When I submit it to CRAN the Windows build 
is OK but the same error happens at the 'texi2dvi' step in the debian vignette 
re-build.

This seems to happens after an example that correctly has a warning message 
(about Heywood cases). In my linux build the the warning happens but the 
message does not appear in the pdf output, so one possibility is that the 
handling of the warning on the CRAN Unix check machines fails to produce clean 
tex or suppress output. Another possibility is that my build using --as-cran is 
different from the actual CRAN build options. 
For example, my 00check.log shows
...
* checking package vignettes in ‘inst/doc’ ... OK
* checking re-building of vignette outputs ... OK
* checking PDF version of manual ... OK
* checking for non-standard things in the check directory ... OK ...

so I am not sure if it uses texi2dvi. (I haven't used dvi myself for a long 
time.)

I'm not sure how to debug this when I can't reproduce the error. 
Suggestions would be appreciated.

Paul Gilbert

__
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] Debugging library.dynam to include a manual shared object

[Georgi Boshnakov]

> Building this works fine in RStudio with devtools::load_all('.'), but 
> | when I try to run R CMD INSTALL,...

Note that the devtools equivalents of 'R CMD build/check/install' are 
devtools::build(), devtools::check(), devtools::install().
devtools::load_all() has a different purpose. 

Georgi Boshnakov


-Original Message-
From: R-package-devel  On Behalf Of Dirk 
Eddelbuettel
Sent: 18 November 2020 12:57
To: Jon Davidson 
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Debugging library.dynam to include a manual shared 
object


Jon,

On 16 November 2020 at 12:27, Jon Davidson wrote:
| I am trying to build an R package with a manually compiled .so file. 
| To do so, I have included a call to useDynLib() in my NAMESPACE file.

In general you would not need to do that, or do that:

 - A package knows how to turn files in src/* into a .so (and a .dylib and a
   .dll none of which you need to explicitly, a huge win for you)

 - A package knows how to load a dynamic library declared in NAMESPACE
 
| Building this works fine in RStudio with devtools::load_all('.'), but 
| when I try to run R CMD INSTALL, I get the error: package or namespace 
| load failed in library.dynam(lib, package, package.lib): shared object 
| 'filename.so' not found.

Only `R CMD INSTALL` matters here for (scripted) CRAN operations. If that fails 
you have a problem, no matter how helpful the optional tools are.

| Is there any way I can debug library.dynam to see where it's looking 
| for my .so and why it can't find it? Thanks for your help!

As said, R knows where to find a package's shared library file. For the rest, 
it is (on Linux) ld.so and its documentation but you (as far as I can
remember) cannot set LD_LIBRARY_PATH from within a running R session.

It might help if you described your problem in more detail with a reproducible 
example.

Regards,  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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] vignettes present in 2 folders or won't work

[Georgi Boshnakov]

From: Duncan Murdoch 
To: Mark van der Loo 
Cc: Dirk Eddelbuettel , r-devel



Further to Duncan's comments:

> It would be nice if the documents in inst/doc were linked to on the CRAN 
> landing page of a package. I think that documents under inst/doc are a 
> bit hard to find if package authors do not create (possibly many) links 
> to them in Rd files or vignettes.

There is the seemingly underused option "package" of help():

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

The vignettes and other documents (including sources of vignettes, etc) are at 
the top of the html page (help_type is used in case the default for help is 
text format, when the output is less convenient in this case). 

What is shown can be customised by a custom index.tml under inst/doc (described 
in WRE).  An inconvenience for users of devtools::check()  is that it wipes out 
inst/doc (but it does ask for confirmation).


Georgi Boshnakov



--

Message: 12
Date: Mon, 2 Nov 2020 05:22:02 -0500
From: Duncan Murdoch 
To: Mark van der Loo 
Cc: Dirk Eddelbuettel , r-devel

Subject: Re: [Rd] vignettes present in 2 folders or won't work
Message-ID: <92e51613-b647-5d72-793a-dd64e0eda...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 02/11/2020 4:07 a.m., Mark van der Loo wrote:
> 
> 
> On Sun, Nov 1, 2020 at 10:39 PM Duncan Murdoch  <mailto:murdoch.dun...@gmail.com>> wrote:
> 
> On 01/11/2020 2:57 p.m., Dirk Eddelbuettel wrote:
>  >
>  > The closest to a canonical reference for a static vignette is the
> basic blog
>  > post by Mark at
>  >
>  >
> 
> https://www.markvanderloo.eu/yaRb/2019/01/11/add-a-static-pdf-vignette-to-an-r-package/
>  >
>  > which I follow in a number of packages.
>  >
>  > Back to the original point by Alexandre: No, I do _not_ think we
> can do
>  > without a double copy of the _pre-made_ pdf ("input") and the
> _resulting_ pdf
>  > ("output").
>  >
>  > That bugs me a little too but I take it as a given as static /
> pre-made
>  > vignettes are non-standard (given lack of any mention in WRE, and
> the pretty
>  > obvious violation of the "spirit of the law" of vignette which is
> after all
>  > made to run code, not to avoid it). Yet uses for static vignettes
> are pretty
>  > valid and here we are with another clear as mud situation.
>  >
> 
> In many cases such files aren't vignettes.
> 
> By definition, packages should contain plain text source code for
> vignettes.  They can contain other PDF files in inst/doc, but if you
> don't include the plain text source, those aren't vignettes.
> 
> An exception would be a package that contains the source code but
> doesn't want to require CRAN or other users to run it, because it's too
> time-consuming, or needs obscure resources.  The CRAN policy
> discusses this.
> 
> Duncan Murdoch
> 
> 
> It would be nice if the documents in inst/doc were linked to on the CRAN 
> landing page of a package. I think that documents under inst/doc are a 
> bit hard to find if package authors do not create (possibly many) links 
> to them in Rd files or vignettes.

What I'd suggest is that you write a "browseDocs" function that displays 
them in some nice format (similar to "browseVignettes").  Maybe CRAN 
would choose to add a new category listing its results, but at a 
minimum, you could very easily add a vignette called "Other documents" 
that contains a list of links.   It wouldn't be as prominent as 
"Vignettes" on CRAN, but you could make the display as prominent as you 
want on your own web page.

Duncan Murdoch




--

Subject: Digest Footer

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


--

End of R-devel Digest, Vol 213, Issue 1
***
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] checking PDF version of manual without hyperrefs or index ... ERROR

[Georgi Boshnakov]

This seems to be  the code for "small latin capital fl". Such characters often 
occur when copying text from external programs 
(similar to the familiar problem with fancy quotes). If that is the case, Just 
changing the offending symbol to  the two letters 'f' and 'l' should suffice. 

Georgi Boshnakov

-Original Message-
From: R-package-devel  On Behalf Of 
Anthony Hammond
Sent: 29 October 2020 14:34
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] checking PDF version of manual without hyperrefs or 
index ... ERROR

Hello,
I'm attempting to upload a package to CRAN and although it passes the R CMD 
checks that I run, it doesn't pass the CRAN check and the response I get is 
pasted below. I've looked online and found numerous solutions; some made no 
sense to me & others didn't work.
I tried downloading and putting upquote.sty and inconsolata.sty files into the 
latex folder. I also tried typing --no-manual in the project options under R 
CMD check options.
Still the CRAN submission email response provided the below error.
What can I do to make this go away and have my package accepted?
It probably doesn't help that I know next to nothing about LaTeX.
Incidentally I don't mind not having a pdf manual, so if there is a simple way 
to avoid the check by requesting not to have one, that'll do.
Any assistance would be greatly appreciated.

Kind Regards
Anthony

* checking PDF version of manual ... WARNING LaTeX errors when creating PDF 
version.
This typically indicates Rd problems.
LaTeX errors found:
! Package inputenc Error: Unicode char fl (U+FB02)
(inputenc)not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H   for immediate help.
* checking PDF version of manual without hyperrefs or index ... ERROR
* checking for detritus in the temp directory ... OK
* DONE
Status: 1 ERROR, 1 WARNING, 3 NOTEs

[[alternative HTML version deleted]]

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

[R-pkg-devel] dependency fails checking a package on ASAN/UBSAN (on r-hub)

[Georgi Boshnakov]

Hi,

A package submitted on CRAN shows problems only on ASAN/UBSAN.
I  used 'r-hub' (rhub::check()) to check if my update has fixed that on that 
platform but
This is unsuccessful since a dependency fails to install.

The dependency in question is 'xml2'  so it surely can be installed one way or 
another but do I need to give additional parameters? The report from r-hub is at
HTML<https://builder.r-hub.io/status/rbibutils_1.3.tar.gz-74c7a41c4a1d4c36940fcc78b85e800b>


Georgi Boshnakov

[[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] force revdepcheck to use local version of a dependency

[Georgi Boshnakov]

Thanks, adding remotes to DESCRIPTION did what I was after. 

For reference (including me), here is an outline of a possible workflow:

1. run revdep_check(), with many reverse dependencies something like  
revdep_check(num_workers = 4)
 speeds the things up dramatically. 

2, if there are  failures run   revdep_add_broken() 
 
3. bug-fix

4. run revdep_check() or revdep_check(num_workers = 4),
 Due to 2. Above, this will run only the checks that failed the previous 
time. Of course this assumes that the bug-fixes didn't break things that work.

5. repeat 2. - 4. 


Georgi Boshnakov
   





-Original Message-
From: Gábor Csárdi  
Sent: 28 September 2020 18:46
To: Georgi Boshnakov 
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] force revdepcheck to use local version of a 
dependency

You can define the special dependency of the revdep-checked package in the 
`Remotes` field. More info:
https://cran.rstudio.com/web/packages/remotes/vignettes/dependencies.html

E.g. if you are revdep-checking package PKG, then you can add something like 
this in the DESCRIPTION file of PKG:
Remotes: local::/path/to/your/package
or if the package is on GitHub:
Remotes: user/repo

Then revdepcheck will automatically install the special version of the 
dependency, for the dev version of the revdep-checked package. (But not for the 
CRAN version of the package.)

Best,
Gabor

On Mon, Sep 28, 2020 at 6:17 PM Georgi Boshnakov 
 wrote:
>
> Hi,
>
> I am using package 'revdepcheck' to check reverse dependencies of a package 
> and it works great. But now I have a scenario such that I wish it to use a 
> local version of one of the dependencies of the checked package and am not 
> able to find out how.
>
> Some context: Package A imports package B. Package A has many reverse 
> dependencies. I wish to check if an update to package B will break some of 
> the reverse dependencies of A and/or repair broken reverse dependencies of A. 
> It is obvious to update B on CRAN but this may lead unnecessarily to a number 
> of CRAN updates.
>
>
> Georgi Boshnakov
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] force revdepcheck to use local version of a dependency

[Georgi Boshnakov]

Hi,

I am using package 'revdepcheck' to check reverse dependencies of a package and 
it works great. But now I have a scenario such that I wish it to use a local 
version of one of the dependencies of the checked package and am not able to 
find out how.

Some context: Package A imports package B. Package A has many reverse 
dependencies. I wish to check if an update to package B will break some of the 
reverse dependencies of A and/or repair broken reverse dependencies of A. It is 
obvious to update B on CRAN but this may lead unnecessarily to a number of CRAN 
updates.


Georgi Boshnakov


[[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] Use of `:::` in a package for code run in a parallel cluster

[Georgi Boshnakov]

You may have a case to argue to CRAN that you can get the "almost" exemption 
(can't say without details) but your views look overly rigid.

Exporting an object and marking it as internal is not a "work around", even 
less a "dirty trick". 
Export makes the object available outside the package's namespace and makes it 
clear that this is intentional. 
If you can't drop the 'package:::' prefix in your use case, this means that 
this is what you actually do (i.e. use those objects outside the namespace of 
the package). I would be grateful to CRAN for asking me to export and hence 
document this. 


Georgi Boshnakov

PS Note that there is no such thing as "public namespace".


-Original Message-
From: R-package-devel  On Behalf Of 
David Kepplinger
Sent: 13 September 2020 20:52
To: R Package Devel 
Subject: [R-pkg-devel] Use of `:::` in a package for code run in a parallel 
cluster

Dear list members,

I submitted an update for my package and got automatically rejected by the 
incoming checks (as expected from my own checks) for using `:::` calls to 
access the package's namespace.
"There are ::: calls to the package's namespace in its code. A package
*almost* never needs to use ::: for its own objects:…" (emphasis mine)

This was a conscious decision on my part as the package runs code on a 
user-supplied parallel cluster and I consider cluster-exporting the required 
functions a no-go as it would potentially overwrite objects in the clusters R 
sessions. The package code does not own the cluster and hence the R sessions. 
Therefore overwriting objects could potentially lead to unintended behaviour 
which is opaque to the user and difficult to debug.

Another solution to circumvent the R CMD check note is to export the functions 
to the public namespace but mark them as internal. This was also suggested in 
another thread on this mailing list (c.f. "Etiquette for package submissions 
that do not automatically pass checks?"). I do not agree with this work-around 
as the methods are indeed internal and should never be used by users. Exporting 
truly internal functions for the sake of satisfying R CMD check is a bad 
argument, in particular if there is a clean, well-documented, solution by using 
`:::`.

I argue `:::` is the only clean solution to this problem and no dirty 
work-arounds are necessary. This is a prime example of where `:::` is actually 
useful and needed inside a package. If the R community disagrees, I think R CMD 
check should at least emit a WARNING instead of a NOTE and elaborate on the 
problem and accepted work-arounds in "Writing R extensions". Or keep emitting a 
NOTE but listing those nebulous reasons where `:::` would be tolerated inside a 
package. Having more transparent criteria for submitting to CRAN would be 
really helpful to the entire R community and probably also reduce the traffic 
on this mailing list.

Best,
David

[[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] more Matrix weirdness

[Georgi Boshnakov]

Abby, my answer was too concise. The thrust is that even if you define a method 
for 
"[<-" with signature x="matrix" and value ="Matrix", for example, it will never 
be used since "matrix" is S3. 
If instead x="someS4class" then the S4 method will be invoked.

There may be cases when changing the class of the left-hand side make sense 
(such as one subclass of "Matrix" to another) but certainly not for the base R 
vector classes.


Georgi Boshnakov


-Original Message-
From: Abby Spurdle  
Sent: 11 September 2020 03:03
To: Martin Maechler 
Cc: Georgi Boshnakov ; r-devel@r-project.org
Subject: Re: [Rd] more Matrix weirdness

> > "These operators are also implicit S4 generics, but as
> > primitives, S4 methods will be dispatched only on S4
> > objects ‘x’."

> Yes, exactly,  very well found, Georgi!

I'm sorry Martin, but I don't understand your point here.

I'm assuming that you want the (S3) matrix, x, to be converted to an
(S4) Matrix.

However, this is not a question of method dispatch, as such.
But rather a question of type conversion (integer to numeric to complex, etc).

Specifically, can/should automatic type conversion, convert an S3 data type to 
an S4 data type, even where user-defined data types are involved?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] more Matrix weirdness

[Georgi Boshnakov]

If the current semantics is to be kept, one approach might be to insert in the 
internal code of "[<-" something like the equivalent of 

If(isS4(value))
value <- coreData(value)

with the contract that classes that wish to be treated as equivalent to basic 
vector classes define suitable method for coreData(). So, a matrix class would 
return a plain matrix, a vector class - a vector, etc. This is akin to 
coredata() for time series in package 'zoo' and others. 


Georgi Boshnakov

-Original Message-
From: Martin Maechler  
Sent: 10 September 2020 13:48
To: Georgi Boshnakov 
Cc: r-devel@r-project.org
Subject: Re: [Rd] more Matrix weirdness

>>>>> Georgi Boshnakov 
>>>>> on Wed, 9 Sep 2020 10:48:56 + writes:

> I think that this is because `[<-` dispatches on S4
> methods only if the first argument is S4.  ?"[<-" says:

> "These operators are also implicit S4 generics, but as
> primitives, S4 methods will be dispatched only on S4
> objects ‘x’."

> Georgi Boshnakov

Yes, exactly,  very well found, Georgi!

This is something I would have wanted different for years, exactly because of 
several such problems with the Matrix package of which I'm the maintainer.

Long time ago I had also looked if I saw how to fix this behavior inside 
'methods' (i.e. the S4 infrastructure pkg) and I think in this case also, 
inside R's basic C code.

At the time (~ 10 yrs ago) I gave up, but don't remember why.

I'm happy if you create a formal bug report, possibly "wishlist"
as it is documented behavior, for this infelicity...
and then I will probably add the  'HELPWANTED'  keyword.

Martin


> -Original Message-


> Message: 19 Date: Tue, 8 Sep 2020 22:04:44 -0400 From: Ben
> Bolker  To: r-devel
>  Subject: [Rd] more Matrix
> weirdness Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"; Format="flowed"

>Am I being too optimistic in expecting this (mixing and
> matching matrices and Matrices) to work?  If x is a matrix
> and m is a Matrix, replacing a commensurately sized
> sub-matrix of x with m throws "number of items to replace
> is not a multiple of replacement length" ...

> x <- matrix(0,nrow=3,ncol=10,
> dimnames=list(letters[1:3],LETTERS[1:10])) rr <-
> c("a","b","c") cc <- c("B","C","E") m <-
> Matrix(matrix(1:9,3,3)) x[rr,cc] <- m

> cheers Ben Bolker




> --

> Message: 20 Date: Wed, 9 Sep 2020 07:03:47 +0100 From: Rui
> Barradas  To: Ben Bolker
> , r-devel 
> Subject: Re: [Rd] more Matrix weirdness Message-ID:
> <7037975c-22b6-6eca-d871-743eead53...@sapo.pt>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"

> Hello,

> R 4.0.2 on Ubuntu 20.04, sessionInfo() below.

> I can reproduce this, sort of. The error I'm getting is
> different:


> x[rr, cc] <- m #Error in x[rr, cc] <- m : replacement has
> length zero

> But if I check lengths and dimensions, they are
> identical().

> identical(length(x[rr, cc]), length(m)) #[1] TRUE
> identical(dim(x[rr, cc]), dim(m)) #[1] TRUE


> What works is


> x[rr, cc] <- as.matrix(m)

> I ran Ben's code on RStudio 1.3.1073, the following is run
> with Rscript and the error message is the same.


> rui@rui:~$ Rscript --vanilla rhelp.R R version 4.0.2
> (2020-06-22) Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 20.04.1 LTS

> Matrix products: default BLAS:
> /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0 LAPACK:
> /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0

> locale: [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C [3]
> LC_TIME=pt_PT.UTF-8 LC_COLLATE=pt_PT.UTF-8 [5]
> LC_MONETARY=pt_PT.UTF-8 LC_MESSAGES=pt_PT.UTF-8 [7]
> LC_PAPER=pt_PT.UTF-8 LC_NAME=C [9] LC_ADDRESS=C
> LC_TELEPHONE=C [11] LC_MEASUREMENT=pt_PT.UTF-8
> LC_IDENTIFICATION=C

> attached base packages: [1] stats graphics grDevices utils
> datasets methods base

> other attached packages: [1] Matrix_1.2-18

> loaded via a namespace (and not attached): [1]
> compiler_4.0.2 grid_4.0.2 lattice_0.20-41 Error in x[rr,
> cc] <- m : number of items to replace is not a multiple of
> replacement length Execution halted


> Hope this helps,

> Rui Barradas


> Às 03:04 de 09/09/20, Ben Bolker escreveu:
>>   Am I being too optimistic in expecting this (mixing and
>> matching matrices and Matrices) t

Re: [Rd] more Matrix weirdness

[Georgi Boshnakov]

I think that this is because `[<-` dispatches on S4 methods only if the first 
argument is S4.  
?"[<-" says:

"These operators are also implicit S4 generics, but as primitives,
 S4 methods will be dispatched only on S4 objects ‘x’."

Georgi Boshnakov

-Original Message-


Message: 19
Date: Tue, 8 Sep 2020 22:04:44 -0400
From: Ben Bolker 
To: r-devel 
Subject: [Rd] more Matrix weirdness
Message-ID: 
Content-Type: text/plain; charset="utf-8"; Format="flowed"

   Am I being too optimistic in expecting this (mixing and matching 
matrices and Matrices) to work?  If x is a matrix and m is a Matrix, 
replacing a commensurately sized sub-matrix of x with m throws "number 
of items to replace is not a multiple of replacement length" ...

x <- matrix(0,nrow=3,ncol=10, dimnames=list(letters[1:3],LETTERS[1:10]))
rr <- c("a","b","c")
cc <- c("B","C","E")
m <- Matrix(matrix(1:9,3,3))
x[rr,cc] <- m

cheers
 Ben Bolker




--

Message: 20
Date: Wed, 9 Sep 2020 07:03:47 +0100
From: Rui Barradas 
To: Ben Bolker , r-devel 
Subject: Re: [Rd] more Matrix weirdness
Message-ID: <7037975c-22b6-6eca-d871-743eead53...@sapo.pt>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hello,

R 4.0.2 on Ubuntu 20.04, sessionInfo() below.

I can reproduce this, sort of. The error I'm getting is different:


x[rr, cc] <- m
#Error in x[rr, cc] <- m : replacement has length zero

But if I check lengths and dimensions, they are identical().

identical(length(x[rr, cc]), length(m))
#[1] TRUE
identical(dim(x[rr, cc]), dim(m))
#[1] TRUE


What works is


x[rr, cc] <- as.matrix(m)

I ran Ben's code on RStudio 1.3.1073, the following is run with Rscript 
and the error message is the same.


rui@rui:~$ Rscript --vanilla rhelp.R
R version 4.0.2 (2020-06-22)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.1 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0

locale:
  [1] LC_CTYPE=pt_PT.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
  [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
  [7] LC_PAPER=pt_PT.UTF-8   LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] Matrix_1.2-18

loaded via a namespace (and not attached):
[1] compiler_4.0.2  grid_4.0.2  lattice_0.20-41
Error in x[rr, cc] <- m :
   number of items to replace is not a multiple of replacement length
Execution halted


Hope this helps,

Rui Barradas


Às 03:04 de 09/09/20, Ben Bolker escreveu:
>    Am I being too optimistic in expecting this (mixing and matching 
> matrices and Matrices) to work?  If x is a matrix and m is a Matrix, 
> replacing a commensurately sized sub-matrix of x with m throws "number 
> of items to replace is not a multiple of replacement length" ...
> 
> x <- matrix(0,nrow=3,ncol=10, dimnames=list(letters[1:3],LETTERS[1:10]))
> rr <- c("a","b","c")
> cc <- c("B","C","E")
> m <- Matrix(matrix(1:9,3,3))
> x[rr,cc] <- m
> 
>     cheers
>      Ben Bolker
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel




--

Message: 21
Date: Wed, 9 Sep 2020 08:27:06 +0200
From: Uwe Ligges 
To: r-devel@r-project.org
Subject: Re: [Rd] failing automatic incoming check
Message-ID:

Content-Type: text/plain; charset="utf-8"; Format="flowed"



On 08.09.2020 21:34, Sebastian P. Luque wrote:
> Hello,
> 
> I got a notification regarding a failure to pass incoming checks
> automatically after a CRAN submission.  The details are given here:
> 
> https://win-builder.r-project.org/incoming_pretest/diveMove_1.5.0_20200908_191325/
> 
> The only visible issue is a NOTE from the macosx build, with the very
> terse:
> 
> "No Protocol Specified"
> 
> My searches suggest this can be ignored, but it would be nice to squash
> it.  Any tips welcome.
> 


For some reason this should hgave undergone manual inpection but got 
auto rejected. Ideally you would reduce the test timing so that the 
overall check time is less than 10 min .

Best,
Uwe Ligges




--

Message: 22
Date: Wed, 9 Sep 2020 16:48:40 +1000
From: Hugh Parsonage 
To: Jeroen Ooms 
Cc: Tomas Kalibera , Luke Tierney
,  R-devel , Martin
Maechler 
Subject: Re: [Rd] [External] Re: Operations with long altrep ve

Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

[Georgi Boshnakov]

I think that the current behaviour is documented in WRE:

"...There are two other forms of optional argument specified as \link[pkg]{foo} 
and
\link[pkg:bar]{foo} to link to the package pkg, to files foo.html and bar.html 
respectively.
These are rarely needed, perhaps to refer to not-yet-installed packages (but 
there the HTML
help system will resolve the link at run time) or in the normally undesirable 
event that more
than one package offers help on a topic7 (in which case the present package has 
precedence so
this is only needed to refer to other packages). They are currently only used 
in HTML help
(and ignored for hyperlinks in LATEX conversions of help pages), and link to 
the file rather
than the topic (since there is no way to know which topics are in which files 
in an uninstalled
package) ...   Because they have been frequently misused, the HTML help system 
looks for topic foo in package pkg 
if it does not find file foo.html."

Unless I am missing something, it seems that it would be relatively painless to 
reverse the logic of the current behaviour of the help system,
i.e. to start looking first for the topic and then for a file.

Georgi Boshnakov

-Original Message-
From: R-package-devel  On Behalf Of 
Gábor Csárdi
Sent: 16 June 2020 13:44
To: Duncan Murdoch 
Cc: List r-package-devel 
Subject: Re: [R-pkg-devel] check cross-references error: Non-file 
package-anchored link(s)

On Mon, Jun 15, 2020 at 5:30 PM Duncan Murdoch  wrote:
>
> On 15/06/2020 12:05 p.m., Martin Maechler wrote:
> >>>>>> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:
> >
> >  > I agree with almost everything you wrote, except one thing:  this 
> > isn't
> >  > newly enforced, it has been enforced since the help system began.  
> > What
> >  > I think is new is that there are now tests for it.  Previously those
> >  > links just wouldn't work.
> >
> >  > Duncan Murdoch
> >
> > Yes, to all... including Duncan's agreement with Gábor.
> >
> > Also, Duncan M earlier did mention that he had wanted to
> > *change* the link-to-file behavior for these cases (when he wrote 
> > most of the Rd2html source code) but somehow did not get it.
>
> Actually, I don't think I pushed for this change at the time (or at 
> least I didn't push much).  I just wish now that I had, because I 
> think it will be harder to do it now than it would have been then.
>
> Duncan

I am not entirely sure, but maybe just documenting the current behaviour and 
undoing 78674 could work. With some tweaks? E.g.

* updating R-exts to say that \link[pkg:topic]{text} will link to `topic.html` 
in `pkg` first (for historical reasons), and falls back to searching for 
`topic` in `pkg` at render time.
* updating Rd2HTML to look for the topic and use it in the link, instead of 
throwing a warning, in it cannot find `topic.html`
* removing the `R CMD check` warning for non-file links, that was added in 
78674 :)

Is there anything else?

Gabor

[...]

__
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] check cross-references error: Non-file package-anchored link(s)

[Georgi Boshnakov]

The Rd file is mplus.Rd, so   
‘[lubridate:mplus]{lubridate::add_with_rollback()}’ would do. 

Georgi Boshnakov

-Original Message-
From: R-package-devel  On Behalf Of 
David Hugh-Jones
Sent: 16 June 2020 07:51
To: Duncan Murdoch 
Cc: List r-package-devel 
Subject: Re: [R-pkg-devel] check cross-references error: Non-file 
package-anchored link(s)

On this note, I just got

Non-file package-anchored link(s) in documentation object
'brk_width-for-datetime.Rd':
  ‘[lubridate:%m+%]{lubridate::add_with_rollback()}’

The correct filename appears to be %m+% in the lubridate help. Can anyone tell 
me the right way to format this? I would work it out myself, but the check 
didn't cause problems on the r-devel systems I tested with, so I'd be testing 
blind.

Cheers,
David


On Mon, 15 Jun 2020 at 17:30, Duncan Murdoch 
wrote:

> On 15/06/2020 12:05 p.m., Martin Maechler wrote:
> >>>>>> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:
> >
> >  > I agree with almost everything you wrote, except one thing:  
> > this
> isn't
> >  > newly enforced, it has been enforced since the help system
> began.  What
> >  > I think is new is that there are now tests for it.  
> > Previously
> those
> >  > links just wouldn't work.
> >
> >  > Duncan Murdoch
> >
> > Yes, to all... including Duncan's agreement with Gábor.
> >
> > Also, Duncan M earlier did mention that he had wanted to
> > *change* the link-to-file behavior for these cases (when he wrote 
> > most of the Rd2html source code) but somehow did not get it.
>
> Actually, I don't think I pushed for this change at the time (or at 
> least I didn't push much).  I just wish now that I had, because I 
> think it will be harder to do it now than it would have been then.
>
> Duncan
>
> >
> > And that's why we had partial workarounds (as the dynamic server 
> > still finding the links under some circumstances).
> >
> > My personal opinions was also that "we" (the R community; i.e., 
> > people providing good patches to the R sources / collaborating with 
> > R core / ...) should rather work to fix the current 
> > design/implementation "infelicity" than the current checks starting 
> > to enforce something which is really a wart in my view, and indeed, 
> > as Gábor also notes, will create R source documentation that depends 
> > on implementation details of other package's documentation.
> > I don't like it either, not at all.
> >
> > Martin
> >
> >  > On 14/06/2020 6:26 a.m., Gábor Csárdi wrote:
> >  >> On Sun, Jun 14, 2020 at 10:44 AM Duncan Murdoch
> >  >>  wrote:
> >  >> [...]
> >  >>>
> >  >>> I think the argument was that static builds of the help 
> > pages
> would have
> >  >>> trouble resolving the links.  With the current system, you 
> > can
> build a
> >  >>> help page that links to a page in package foo even if 
> > package
> foo is not
> >  >>> installed yet, and have the link work later after you 
> > install
> foo.
> >  >>
> >  >> That is true, but it is also not a big problem, I think. The CRAN
> >  >> Windows R installer does indeed build static help pages by
> default.
> >  >> But the built-in web server that serves these works around broken
> >  >> links by treating them as help topics instead of files. As 
> > you
> know.
> >  >> :) So this would only be a problem if you wanted to serve 
> > the
> static
> >  >> help pages with another web server. (Which is not a bad use
> case, but
> >  >> then maybe Rd2HTML() can just resolve them as topics and 
> > avoid
> the
> >  >> broken links.)
> >  >>
> >  >> Btw. the problem of linking to the wrong page is even worse with
> >  >> static builds of help pages, because if a link w/o a package
> (e.g.
> >  >> \link{filter}) picks up the wrong package at install time, 
> > then
> the
> >  >> wrong link is hard-coded in the html. If you are building binary
> >  >> packages, then they will link to the wrong help pages.
> >  >>
> >  >> WRE says that specifying the package in the link is rarely
> needed.
> >  >> This was probably the case some time ago, especially when
> packages did
> >  >> not have (compulsory) namespaces. But I am not sure if it 
> > still
> holds.

Re: [R-pkg-devel] *not* re-making package if contents haven't changed

[Georgi Boshnakov]

Maybe let 'git' decide which files have changed?

Georgi Boshnakov

-Original Message-
From: R-package-devel  On Behalf Of Greg 
Minshall
Sent: 01 June 2020 03:57
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] *not* re-making package if contents haven't changed

hi.  i use emacs org-mode to write my literate (semi-, in my case) code.  then, 
'tangle' the results into package/R/foo.R, etc.

the tangling is driven by a makefile.  (my methodology is to make the package 
source tree as a subdirectory of where my makefile sits; i realize this is 
non-standard, and in many respects sub-optimal.)

the makefile then proceeds to R-CMD-build, R-CMD-check, and, assuming those 
pass, Rscript-install the package.

i would like to *not* do the build/check/install if, in fact, nothing has 
changed in the tangled files since the last time the build/check/install ran.  
the *dates* of the files (which is what make typically looks at) *will* have 
changed.  but, i want to rely on the contents, not on the dates.

i can imagine various hacks to accomplish this.  but, i thought that someone on 
the list may have run into this before and have a recommendation.

if so, i'm all ears!  thanks in advance.

cheers, Greg

__
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] MathJax for Rd files

[Georgi Boshnakov]

The issue is not with Rstudio per se but that in devtools' development mode  
help() is modified to show the Rd files in the source directory, as one would 
expect, but doesn't load the RdMacros. So, the issue appears when one is 
development mode. 

Rdpack::viewRd() can be of some help but it currently loads only the RdMacro's 
from its package.

Georgi Boshnakov

-Original Message-
From: R-package-devel  On Behalf Of 
Viechtbauer, Wolfgang (SP)
Sent: 13 May 2020 17:14
To: Helmut Schütz ; tiagooliv...@gmail.com; 
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] MathJax for Rd files

Thanks for the info! Can confirm now that I tried this (I don't usually use 
RStudio). That's an RStudio issue then. My guess is that 'Preview' uses 
tools::Rd2HTML() and that indeed won't automatically understand macros coming 
from mathjaxr (or any add-on package for that matter). This would be an issue 
to raise with the RStudio folks then.

But once a package is installed, the equations are nicely rendered also in the 
RStudio help browser, so that part works.

Best,
Wolfgang

>-Original Message-
>From: Helmut Schütz [mailto:helmut.schu...@bebac.at]
>Sent: Wednesday, 13 May, 2020 17:01
>To: Viechtbauer, Wolfgang (SP); tiagooliv...@gmail.com; 
>r-package-devel@r- project.org
>Subject: Re: [R-pkg-devel] MathJax for Rd files
>
>Hi Wolfgang,
>
>Viechtbauer, Wolfgang (SP) wrote on 2020-05-13 16:53:
>> Seems like you are using roxygen2. I have little experience with 
>> that, as
>all my Rd files are 'handcrafted' (plus 100% organic and biodegradable).
>
>As are mine. ;-)
>In the HTML-preview of RStudio the LaTeX is indeed not parsed. I get it 
>only (in the HTML man-page and the PDF) if I build the package.
>
>Helmut
>
>--
>Ing. Helmut Schütz
>BEBAC – Consultancy Services for
>Bioequivalence and Bioavailability Studies Neubaugasse 36/11
>1070 Vienna, Austria
>E helmut.schu...@bebac.at
>W https://bebac.at/
>F https://forum.bebac.at/
__
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] Error vignette rebuilding and package imports when re-submitting package

[Georgi Boshnakov]

Just add 

importFrom(Rdpack,  reprompt) 

in the NAMESPACE file (any function from Rdpack will do). 

Georgi Boshnakov

-Original Message-
From: R-package-devel  On Behalf Of Paul 
SAVARY
Sent: 15 April 2020 10:15
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Error vignette rebuilding and package imports when 
re-submitting package

Hello, 

I'm having trouble re-submitting a package (graph4lg). 

- With r-patched_osx, vignette rebuilding fails with the following message : 

checking re-building of vignette outputs ... [12s/16s] WARNING
Error(s) in re-building vignettes: 
... 
--- re-building ‘vignette_graph4lg.Rmd’ using rmarkdown
dyld: lazy symbol binding failed: Symbol not found: chkstk_darwin 
Referenced from: /usr/local/bin/pandoc (which was built for Mac OS X 10.15) 
Expected in: /usr/lib/libSystem.B.dylib 

dyld: Symbol not found: chkstk_darwin Referenced from: 
/usr/local/bin/pandoc (which was built for Mac OS X 10.15) Expected in: 
/usr/lib/libSystem.B.dylib 

Error: processing vignette 'vignette_graph4lg.Rmd' failed with diagnostics: 
pandoc document conversion failed with error 6
--- failed re-building ‘vignette_graph4lg.Rmd’ 

SUMMARY: processing the following file failed: 
‘vignette_graph4lg.Rmd’ 

Error: Vignette re-building failed. 
Execution halted 

- Besides, although I removed some unused packages from the imports in 
DESCRIPTION file, I still obtain this message : 

checking dependencies in R code ... NOTE Namespaces in Imports field not 
imported from: 
‘Imap’ ‘Rdpack’ ‘ade4’ ‘doBy’ ‘mclust’ 
All declared Imports should be used. 

Except Rdpack which is needed to build the vignette, I removed these packages. 

Finally, although I submit version 0.4.0, I receive checking errors relative to 
version 0.3.0. 

I thank you in advance for your feedbacks. 
Regards
Paul Savary 







[[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: [R-pkg-devel] First R package, want to release to CRAN, have some questions about R CMD check and README.md

[Georgi Boshnakov]

When writing README.md, keep in mind that it may (and will!) appear and be 
rendered at many places, not only CRAN and Github. METACRAN is a prime example 
with always up-to-date information but there are a number of others. So links 
need to be written with that in mind. 

Also, some sites providing information about R packages may not be updated 
regularly or consistently, or may stop being updated altogether. I have also 
seen sites that render README 
but do not link to CRAN. A visitor in such sites may not have a clue when the 
information on it is obsolete.  So, it is a must to have a link in the 
README(.md) to the CRAN page of the package, even though on CRAN this looks 
strange. The most straightforward is probably a badge.  

Georgi Boshnakov

-Original Message-
From: R-package-devel  On Behalf Of 
Michael Dewey
Sent: 08 March 2020 12:24
To: Jeffry Hesse ; Jeff Newmiller 

Cc: Brittany Belle ; Adrian Powell ; 
Ken Duck ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] First R package, want to release to CRAN, have some 
questions about R CMD check and README.md

As well as having a vignette one thing which encourages me to investigate a 
package is having NEWS. You may already have this of course.

Michael

On 07/03/2020 23:05, Jeffry Hesse wrote:
> Good to know!
> 
> Right now we are using the README.rmd file to create the README.md, I 
> imagine we'd create something akin to oysteR.rmd to create the vignette?
> The documentation on publishing to CRAN is great, but it's hard to 
> tell what a best practice is in this area. Also are vignettes strongly 
> suggested or mandatory? R CMD check is not failing for us right now 
> without having them, hence the question!
> 
> Appreciate the help!
> 
> On Sat, Mar 7, 2020 at 1:55 PM Jeff Newmiller 
> 
> wrote:
> 
>> README.md is a github convention... do not try to treat it like part 
>> of the R package documentation. Instead, list it in your 
>> .Rbuildignore file and use it to inform developers how to change the 
>> package and to direct
>> (potential) users browsing the GitHub repo to read the more 
>> conventional R documentation of vignettes.
>>
>> On March 7, 2020 1:55:24 PM PST, Jeffry Hesse  wrote:
>>> Hi there!
>>>
>>> I and a few others have been working on an R package we'd like to 
>>> get on CRAN. The package itself checks R dependencies to see if they 
>>> have a known CWE or CVE attached to them, and is intended to help R 
>>> developers get a better understanding on the quality of the 
>>> dependencies they use!
>>>
>>> An example of it running is here:
>>>
>>>
>> https://61-244738782-gh.circle-artifacts.com/0/~/oysteR/oysteR.Rcheck
>> /00install.out
>>>
>>> And example of the output of R CMD check is here:
>>>
>>>
>> https://61-244738782-gh.circle-artifacts.com/0/~/oysteR/oysteR.Rcheck
>> /00check.log
>>>
>>> I have had some confusing experiences thus far with a README.md 
>>> file, and excluded it in our .Rbuildignore, because I kept getting:
>>>
>>> * checking top-level files ... WARNING Conversion of ‘README.md’ 
>>> failed:
>>> "template" (line 18, column 17):
>>> unexpected "("
>>> expecting "." or "$"
>>>
>>> This error is very cryptic to me, and I couldn't figure it out after 
>>> a bunch of wonderful googling :)
>>>
>>> The README.rmd file is here:
>>> https://github.com/sonatype-nexus-community/oysteR/blob/master/READM
>>> E.Rmd
>>>
>>> Output README.md generated with rmarkdown is here:
>>>
>> https://raw.githubusercontent.com/sonatype-nexus-community/oysteR/mas
>> ter/README.md
>>>
>>> Ideally I think it would be nice to include it in our R package, but 
>>> that WARNING keeps scaring me :)
>>>
>>> If anyone has any insight into the cause of that warning, would love 
>>> to know.
>>>
>>> Any other feedback on the package would be great too! I'm not an R 
>>> developer by trade (but love it), and this is my first go at this.
>>> Figured
>>> I'd reach out here to hopefully help save some back and forth 
>>> between CRAN maintainers when I go to submit.
>>>
>>> CODE: https://github.com/sonatype-nexus-community/oysteR
>>>
>>> Also, we are actively looking for contributors that want to help 
>>> out, so if this project interests you, come on over!
>>>
>>> Cheers, and thanks in advance for any help!
>>
>> --
>> Sent from my phone. Please excuse my brevity.
>>
> 
> 

--
Michael
http://www.dewey.myzen.co.uk/home.html

__
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] [FORGED] Re: Help on Windows CRAN Check

[Georgi Boshnakov]

It's not about god imposing style:).  Consider this variant of your example:
>flag <- !is.null(x) && x > 0

With the strict checking this will throw error when you run it (good). If you 
replace && with & and x is a vector, flag will silently become a vector and the 
error be masked or delayed  and pop up far away.

Georgi Boshnakov


-Original Message-
From: R-package-devel  On Behalf Of Rolf 
Turner
Sent: 05 March 2020 08:46
To: Tomas Kalibera 
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [FORGED] Re: Help on Windows CRAN Check


On 5/03/20 9:04 pm, Tomas Kalibera wrote:

> On 3/5/20 4:26 AM, John Lawson wrote:
>> I see this error on the CRAN Check report



>> Fatal error: the condition has length > 1
> 
> The problem is that the condition t1 == "I" & t2 == "(" of the if 
> statement in the code is not a scalar. Even though this has been 
> allowed in R historically, the first element has been used, it is 
> almost always a sign of coding error, so it is going to become a runtime 
> error.
> 
> So what one should do is fix the code to only use scalar conditions - 
> ensure t1, t2 are scalar, replace & by &&.

Perhaps I'm being even thicker than usual (imagine that!) but I don't grok that 
last recommendation:  "replace & by &&".  It's usually harmless but indicates a 
lack of understanding.  The "&&" operator evaluates the second condition only 
if the first condition is TRUE.  It is useful (only) in setting where the 
second condition is meaningful only when the first condition is TRUE.

Things like:

if(!is.null(x) && x > 0)

If "x" were null then the second  condition would cause an error to be thrown 
if you used "&" rather than "&&".

In all (???) situations where "&&" works, then "&" works as well. 
However it's a Good Idea to use the language as intended.

It I'm missing some point here, please enlighten me.



cheers,

Rolf

--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

__
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

[Rd] changed names from lm() in R-devel

[Georgi Boshnakov]

In the last week or so lm() in R-devel (and Rpatched, see 
https://cran.rstudio.com/web/checks/check_results_pcts.html) started to produce 
different names for some interactions, compared to R-3.6.x. A full example is 
at the end of this email but the gist is that a term  
"TimeIndex:Season", where "Season" is a factor produces names like 
"TimeIndex:Season1", while R-devel changes the order of the names to 
"Season1:TimeIndex", etc. 

Is this change on purpose? 

Georgi Boshnakov

---

ex_fac<- as.factor(rep(1:4, 10))
ex_fo <- as.formula("x ~ -1 - Season  + TimeIndex:Season")
ex_data   <- data.frame(x = rnorm(40), Season = ex_fac, TimeIndex = 1:40)
lm(ex_fo, data = ex_data, na.action = na.exclude)

## R version 3.6.1 (2019-07-05) -- "Action of the Toes"
##
## Call:
## lm(formula = ex_fo, data = ex_data, na.action = na.exclude)
##
## Coefficients:
## TimeIndex:Season1  TimeIndex:Season2  TimeIndex:Season3  TimeIndex:Season4
## 0.0036876 -0.0033619  0.0211838 -0.0008042


## R Under development (unstable) (2020-02-12 r77798) -- "Unsuffered
Consequences"
##
## Call:
## lm(formula = ex_fo, data = ex_data, na.action = na.exclude)
##
## Coefficients:
## Season1:TimeIndex  Season2:TimeIndex  Season3:TimeIndex  Season4:TimeIndex
##  -0.010330.029000.017910.01596
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] Possibly invalid URL note about canonical form of link to cran package

[Georgi Boshnakov]

I believe that the canonical form is without 'cloud':

https://cran.r-project.org/package=kernlab


Georgi Boshnakov

-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Joris Meys
Sent: 17 December 2019 09:30
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Possibly invalid URL note about canonical form of link 
to cran package

Dear all,


I link in a vignette to the CRAN page of another package using the following 
form:


https://cloud.r-project.org/package=kernlab<https://cloud.r-project.org/package=pkgname>


I believed this was the correct way to do it, but I get following note in R CMD 
check --as-cran :


Found the following (possibly) invalid URLs:
  URL: https://cloud.r-project.org/package=kernlab (moved to 
https://cloud.r-project.org/web/packages/kernlab/index.html)
From: inst/doc/xnet_ShortIntroduction.html
Status: 200
Message: OK
CRAN URL not in canonical form
  Canonical CRAN.R-project.org URLs use https.


So now I'm a bit confused. Aren't we supposed to use the canonical form as 
mentioned on every CRAN package page, or should I use cran.r-project.org 
specifically? I wanted to use cloud.r-project.org to limit traffic to the CRAN 
repo directly.


Advice is appreciated, I'd like to submit this package before the holidays.


Cheers

Joris


--
Joris Meys
Statistical consultant

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

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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] DOI in of package in DESCRIPTION file

[Georgi Boshnakov]

Something like the following should do:  

 

Note that https://zenodo.org/record/3229615 is an URL. Not doi.


Georgi Boshnakov

-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Rainer M Krug
Sent: 16 December 2019 14:35
To: List r-package-devel
Subject: [R-pkg-devel] DOI in of package in DESCRIPTION file

Hi

UI am preparing my package for CRAN. I have a DOI for my package, and would 
like to add Ito the DESCRIPTION file.

At the moment, I am adding

DOI: https://zenodo.org/record/3229615

To the DESCRIPTION file. This raises not an error during check, but tells me, 
that DOI is a unknown field.

Is there a recommended way, of adding the DOI of a package to the DESCRIPTION 
file? I did not find anything when googling.

Thanks,

Rainer



--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:   +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug

PGP: 0x0F52F982

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

[Georgi Boshnakov]

Sorry, in the sequence of emails the context was probably lost, package ? 
package was a side note.
I was referring to (what I believe is a fact) that  -package.Rd is not 
treated by pkgdown as an 
overall package description but package.Rd is and I think that the 
recommendation by devtools-related 
tools is to use package.Rd for this purpose.   There are probably subtleties 
with aliases,  as well.
In my experience pkgdown, doesn't treat specially package-package.Rd (i.e., it 
puts the topic in alphabetical order with the rest of the index), which has 
nudged  me to create yaml files (a good practice!) which I otherwise would not 
have done.

I was not criticising this, only pointing out the difference. I think it is 
unfortunate but it is not  a big issue and I also see
the point of avoiding a '-' in such a crucial name. On the other hand, some 
packages have a main function with the same name as the package, and it may or 
may not be appropriate package.Rd to serve as a doc for both the function and 
the overall description of such a package.

Georgi




-Original Message-
From: Hadley Wickham [mailto:h.wick...@gmail.com] 
Sent: 30 September 2019 21:17
To: Georgi Boshnakov
Cc: Viechtbauer, Wolfgang (SP); r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Require -package.Rd?

On Tue, Sep 24, 2019 at 8:07 AM Georgi Boshnakov
 wrote:
>
> 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.

I'm not sure what lead you to that believe, but we definitely support
(and have supported for years) package?.  See, e.g.
https://usethis.r-lib.org/reference/use_package_doc.html

Hadley

-- 
http://hadley.nz
__
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]

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

[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] unable to run 'make clean' in 'src'

[Georgi Boshnakov]

I don't know about Windows 10 but I think that the pointers to Rtools need to 
be to the bin subdirectory. Also, it is prudent to have these at the beginning 
of the search path, e.g.

PATH=c:\Rtools\bin;c:\Rtools\mingw_64\bin;c:\ProgramF\R\R-3.6.0patched\bin;

I am not sure if the entry for ming_w64 above is (still) needed.


Georgi Boshnakov


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Spencer Graves
Sent: 18 September 2019 07:47
To: R Package Development
Subject: [R-pkg-devel] unable to run 'make clean' in 'src'

Hello:


   "R CMD build bssm" complains:


         unable to run 'make clean' in 'src'


   This is on a Windows 10 computer with R 3.6.1 installed with, I 
think, Rtools35.exe.  "sessionInfo()" says, "Platform: 
x86_64-w64-mingw32/x64 (64-bit)".


   This is trying to build a local clone of 
"https://github.com/sbgraves237/bssm;, which is only slightly different 
from "helske/bssm".


   What do you suggest?


   Thanks,
   Spencer Graves


p.s. 
"https://stackoverflow.com/questions/28723882/problems-installing-development-package-from-either-github-or-local#28724622;
 
documents a discussion of this message from 2015.  It asks if "Rtools is 
in your PATH?"  The "path" includes "C:\RBuildTools\3.5" and "C:\Program 
Files\R\R3.6.1\bin" plus other non-R stuff.  That discussion also said, 
"The .o files in the src directory were messing things up."  bssm/src 
does not contain any *.o files.

__
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] install_github and survival

[Georgi Boshnakov]

I cloned therneau/survival and the installation failed since there is no 
definition for exported function survfit().
A file seems to be missing - there is survfit0() and survfit0.R but, compared 
to CRAN, no survfit.R.

Georgi Boshnakov


--

Message: 1
Date: Thu, 05 Sep 2019 12:53:11 -0500
From: "Therneau, Terry M., Ph.D." 
To: "r-devel@r-project.org" 
Subject: [Rd] install_github and survival
Message-ID: <771925$cbi...@ironport10.mayo.edu>
Content-Type: text/plain; charset="utf-8"

I treat CRAN as the main repository for survival, but I have also had a github 
(therneau/survival) version for a couple of years.  It has a vignette2 
directory, for 
instance, that contains extra vignettes that either take too long to run or 
depend on 
other packages.  It also gets updated more often than CRAN (though those 
updates mght not 
be as well tested yet).

In any case, since it is there, people will of course run install_github 
against it.   
I've added a config script to do the one extra step necessary, but when I try 
install_github it fails.   I'm clearly doing something wrong.  If someone were 
willing to 
contribute a fix I would be most grateful.

survival3.1-0 is almost ready for CRAN, by the way.   Reverse dependency checks 
of hdnom 
turned up one last thing to repair...


Terry Therneau


[[alternative HTML version deleted]]




--

Subject: Digest Footer

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


--

End of R-devel Digest, Vol 199, Issue 6
***
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] URL of a frame (or a vignette)?

[Georgi Boshnakov]

I personally would not link to rdocumentation. They update packages rather 
erratically and the information can be months or even years old, without any 
indication. The drop down list "Other versions" at the top of the package page 
is a misnomer, it should be "Older versions".

My main objection though is that, in my opinion, they blatantly disrespect the 
GPL license. Their pages are like a trap, with all their links 
pointing back to their site. They do not put even a link to CRAN, the place 
where they take the files from. Even the authors' names are linked them! The 
only way to ensure a prominent link to CRAN is to have a badge or link at the 
top of the README file, which they show. This is one of the reasons a put a 
CRAN badge at the top of my README file, even though it looks strange on CRAN. 

I alerted them about this a couple of years ago in their 'Comments' area but 
they did not respond. 


Georgi Boshnakov
 

-Original Message-
From: Spencer Graves [mailto:spencer.gra...@effectivedefense.org] 
Sent: 01 September 2019 20:19
To: Duncan Murdoch; Georgi Boshnakov; Jeff Newmiller; 
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] URL of a frame (or a vignette)?

   I just learned that finding the package on "rdocumentation.org", 
then clicking on the vignette I want at the end of the page, "bssm.Rmd", 
gave me a URL that is portable, at least for the moment:


https://www.rdocumentation.org/packages/bssm/versions/0.1.7/vignettes/bssm.Rmd


   This seems less likely to be trapped by CRAN checks unless it 
actually stops working ;-)


   Thanks to all who replied to my question.
   Spencer


On 2019-09-01 10:49, Duncan Murdoch wrote:
> On 01/09/2019 11:33 a.m., Spencer Graves wrote:
>>     What's the difference between
>>
>>
>> https://cran.r-project.org/package=bssm/vignettes/bssm.pdf
>>
>>
>>     and
>>
>>
>> https://cran.r-project.org/web/packages/bssm/vignettes/bssm.pdf
>>
>>
>>     When I tried the former, it automatically changed to the latter.
>> Is the former considered to be more stable?
>
> CRAN puts this on every package page:
>
> "Please use the canonical form https://CRAN.R-project.org/package= 
> to link to this page."
>
> I think one of the checks will complain if it notices you give the 
> link in a different form.  I forget which URLs it checks.
>
> Duncan Murdoch
>

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

Re: [R-pkg-devel] URL of a frame (or a vignette)?

[Georgi Boshnakov]

The link  https://cran.r-project.org/package=bssm  is stable (and given at the 
bottom of the CRAN page. 
Jeff is right that adding vignettes/bssm.pdf to it is not guaranteed in any 
way. 

GB

-Original Message-
From: Spencer Graves [mailto:spencer.gra...@effectivedefense.org] 
Sent: 01 September 2019 16:33
To: Georgi Boshnakov; Jeff Newmiller; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] URL of a frame (or a vignette)?

   What's the difference between


https://cran.r-project.org/package=bssm/vignettes/bssm.pdf


   and


https://cran.r-project.org/web/packages/bssm/vignettes/bssm.pdf


   When I tried the former, it automatically changed to the latter.  
Is the former considered to be more stable?


   Thanks,
   Spencer


On 2019-09-01 10:13, Georgi Boshnakov wrote:
> Correction:
>
> https://cran.r-project.org/package=bssm/vignettes/bssm.pdf
>
>
> -Original Message-
> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On 
> Behalf Of Georgi Boshnakov
> Sent: 01 September 2019 15:57
> To: Spencer Graves; Jeff Newmiller; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] URL of a frame (or a vignette)?
>
> It may be better to use the canonical url, 
> https://cran.r-project.org/package=bssm, as in:
>
> https://cran.r-project.org/package=bssm/bssm.pdf
>
> By the way, the vignettes for an installed package can be found by
>
> vignette(package="bssm")
>
> or
>
> help(package="bssm", help_type = "html")
>
> The latter has the advantage that it present links in a browser even if by 
> default the help is presented in text mode.
>
>
> Georgi Boshnakov
>
>
>
> -Original Message-
> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On 
> Behalf Of Spencer Graves
> Sent: 01 September 2019 15:42
> To: Jeff Newmiller; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] URL of a frame (or a vignette)?
>
> Hi, Jeff:
>
>
>     That's what I needed.  I clicked on the vignette I wanted and got
> the following:
>
>
> https://cran.r-project.org/web/packages/bssm/vignettes/bssm.pdf
>
>
>     Thanks,
>     Spencer Graves
>
>
> On 2019-09-01 09:37, Jeff Newmiller wrote:
>> Wouldn't you just refer to [1] or one of the links mentioned there?
>>
>> [1] https://cran.r-project.org/package=bssm
>>
>> On September 1, 2019 7:22:43 AM PDT, Spencer Graves 
>>  wrote:
>>> Hello:
>>>
>>>
>>>     How can I get a URL for a frame?
>>>
>>>
>>>     Specifically, I want a URL that I can cite for the "bssm:
>>> Bayesian Inference of Non-linear and
>>> Non-Gaussian State Space Models in R" vignette in the bssm package on
>>> CRAN.  If the package is installed, it's available there as
>>> "bssm.pdf".
>>> However, I want to include it in an RMarkdown vignette I'm writing, and
>>>
>>> I'd rather not force the reader to be on a computer with the package
>>> installed -- and force myself to figure out a way to find it in that
>>> case, if that can even be done.
>>>
>>>
>>>     Thanks,
>>>     Spencer Graves
>>>
>>> __
>>> 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

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

Re: [R-pkg-devel] URL of a frame (or a vignette)?

[Georgi Boshnakov]

Correction: 

https://cran.r-project.org/package=bssm/vignettes/bssm.pdf


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Georgi Boshnakov
Sent: 01 September 2019 15:57
To: Spencer Graves; Jeff Newmiller; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] URL of a frame (or a vignette)?

It may be better to use the canonical url, 
https://cran.r-project.org/package=bssm, as in:

https://cran.r-project.org/package=bssm/bssm.pdf

By the way, the vignettes for an installed package can be found by

vignette(package="bssm")

or

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

The latter has the advantage that it present links in a browser even if by 
default the help is presented in text mode.


Georgi Boshnakov



-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Spencer Graves
Sent: 01 September 2019 15:42
To: Jeff Newmiller; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] URL of a frame (or a vignette)?

Hi, Jeff:


   That's what I needed.  I clicked on the vignette I wanted and got 
the following:


https://cran.r-project.org/web/packages/bssm/vignettes/bssm.pdf


   Thanks,
   Spencer Graves


On 2019-09-01 09:37, Jeff Newmiller wrote:
> Wouldn't you just refer to [1] or one of the links mentioned there?
>
> [1] https://cran.r-project.org/package=bssm
>
> On September 1, 2019 7:22:43 AM PDT, Spencer Graves 
>  wrote:
>> Hello:
>>
>>
>>    How can I get a URL for a frame?
>>
>>
>>    Specifically, I want a URL that I can cite for the "bssm:
>> Bayesian Inference of Non-linear and
>> Non-Gaussian State Space Models in R" vignette in the bssm package on
>> CRAN.  If the package is installed, it's available there as
>> "bssm.pdf".
>> However, I want to include it in an RMarkdown vignette I'm writing, and
>>
>> I'd rather not force the reader to be on a computer with the package
>> installed -- and force myself to figure out a way to find it in that
>> case, if that can even be done.
>>
>>
>>    Thanks,
>>    Spencer Graves
>>
>> __
>> 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
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] URL of a frame (or a vignette)?

[Georgi Boshnakov]

It may be better to use the canonical url, 
https://cran.r-project.org/package=bssm, as in:

https://cran.r-project.org/package=bssm/bssm.pdf

By the way, the vignettes for an installed package can be found by

vignette(package="bssm")

or

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

The latter has the advantage that it present links in a browser even if by 
default the help is presented in text mode.


Georgi Boshnakov



-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Spencer Graves
Sent: 01 September 2019 15:42
To: Jeff Newmiller; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] URL of a frame (or a vignette)?

Hi, Jeff:


   That's what I needed.  I clicked on the vignette I wanted and got 
the following:


https://cran.r-project.org/web/packages/bssm/vignettes/bssm.pdf


   Thanks,
   Spencer Graves


On 2019-09-01 09:37, Jeff Newmiller wrote:
> Wouldn't you just refer to [1] or one of the links mentioned there?
>
> [1] https://cran.r-project.org/package=bssm
>
> On September 1, 2019 7:22:43 AM PDT, Spencer Graves 
>  wrote:
>> Hello:
>>
>>
>>    How can I get a URL for a frame?
>>
>>
>>    Specifically, I want a URL that I can cite for the "bssm:
>> Bayesian Inference of Non-linear and
>> Non-Gaussian State Space Models in R" vignette in the bssm package on
>> CRAN.  If the package is installed, it's available there as
>> "bssm.pdf".
>> However, I want to include it in an RMarkdown vignette I'm writing, and
>>
>> I'd rather not force the reader to be on a computer with the package
>> installed -- and force myself to figure out a way to find it in that
>> case, if that can even be done.
>>
>>
>>    Thanks,
>>    Spencer Graves
>>
>> __
>> 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] General considerations about vignettes

[Georgi Boshnakov]

When adding static vignettes, it is a good idea to put the 'real' ones 
somewhere under inst/doc. 
A manual index file under inst/doc/ will add the benefit that the help system 
will present to the user the real code and not the stub Rnw  in the approach 
suggested by Michael. Package Countr 
(https://cran.r-project.org/package=Countr) uses this approach for its 
vignettes (sorry for the self-reference). 

Georgi Boshnakov


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Mark van der Loo
Sent: 30 August 2019 16:08
To: Michael Dewey
Cc: List r-package-devel
Subject: Re: [R-pkg-devel] General considerations about vignettes

At the cost of some level of reproducibility, you could use a static
vignette and be very clear about the package versions used in the
comparisons:
http://www.markvanderloo.eu/yaRb/2019/01/11/add-a-static-pdf-vignette-to-an-r-package/

As this does diminish the coherence of CRAN somewhat I'm not really
favoring it, but I can see cases where this may be useful (e.g. I use a
static vignette in one pkg to include a published paper).

-Mark

On Fri, Aug 30, 2019 at 5:00 PM Michael Dewey 
wrote:

> Comments in-line
>
> On 30/08/2019 14:59, Iñaki Ucar wrote:
> > On Fri, 30 Aug 2019 at 15:26, J C Nash  wrote:
> >>
> >> I'm seeking some general advice about including vignettes in my
> packages,
> >> which are largely for nonlinear estimation and function minimization
> (optimization).
> >> This means that my packages offer alternatives to many other tools, and
> the user
> >> then has the chore of deciding which is appropriate. Bad choices can be
> very
> >> costly in inappropriate results or computational efficiencies. Hence, I
> include
> >> vignettes to offer comparisons and examples of use.
> >>
> >> Unfortunately, as in a case this week, changes in the comparison
> packages break
> >> my package(s), and I get an email from CRAN telling me to fix it before
> some
> >> date not far in the future. This means a) work for me, possibly at an
> inopportune
> >> time; b) risk of loss of capability, in the present case in the nlsr
> package which
> >> offers some unique capabilities, and c) extra work for CRAN for what
> is, arguably,
> >> updating of peripheral documentation. Updating optimization packages on
> CRAN can be,
> >> I have discovered, a very time-consuming task. Package optimx took over
> 3 months
> >> to get updated.
> >>
> >> It should be noted in the present situation that just before I got the
> msg from
> >> CRAN I got a msg from the maintainer of the package that has changed
> and breaks
> >> the vignette with some suggestions on a fix. The issue is that his
> package has
> >> changed function syntax -- a situation all of us know is fraught with
> troubles,
> >> since improvements may cause breakage.
> >>
> >> I am NOT saying that my vignettes should not be updated. However, I'm
> wondering
> >> if I should set up a repository for my vignettes on Github/Gitlab or
> similar, and
> >> simply link to them. This would separate the updating of vignettes from
> the central
> >> packages. Their updating could be less strictly tied to CRAN
> activities, and could
> >> also be a task undertaken by others who are not listed as maintainer.
> >>
> >> I'd welcome some (hopefully constructive) comments. Would CRAN
> maintainers feel
> >> this to be helpful, or does it lower the value of official R packages?
> Do
> >> other maintainers experience the same requests, or do they just not
> include
> >> vignettes (and many do not)?
> >
> > My two cents:
> >
> > For me, as a user, vignettes are the most valuable form of
> > documentation in a package. Of course, this is personal opinion.
>
> Yes, but it is widely shared (in the sense that I think it too).
>
> I think the issue here is whether the intention is to compare with a
> particular implementation of a technique in which case you probably do
> need to do what you are currently doing or to compare with the technique
> in general terms. If the latter then Iñaki's solution seems perfect to
> me since even if the package interface changes it still implemented the
> same technique (I assume).
>
> Michael
>
>   But
> > these days with so many good packages out there, I don't have time to
> > install all of them and dive into the manual and the examples just to
> > decide which one is better for my use case. A good written vignette
> > most of the time is my driving factor (sometimes, if it's a small
> > package wit

Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

[Georgi Boshnakov]

It seems that expansion of \ldots occurs in two different circumstances. 

1) The Rd2XXX converters treat specially \ldots and \dots but in different 
ways. tools::Rd2latex() defines in its body texify(), which, when called with a 
piece of R code, starts by replacing \ldots and \dots with

 x <- psub("[l]{0,1}dots", "...", as.character(x))

Similarly, Rd2ex(), defines a function remap() which does a similar thing. The 
'html' and 'txt' renderers also treat specially \dots and \ldots but only in 
more restricted cases. I didn't find what 'R CMD check' does. 

This might explain the differences between 'html'  and 'text' on the one hand, 
and 'pdf' output on the other hand. 
(as Duncan pointed out, he didn't see this in html).

But macros starting with '\l'  seem to be expanded in R code in all formats, if 
the backslash is not escaped, example a) below illustrates this. I redefined 
'\ldots' to demonstrate that this is  not due to the special treatment that 
literally replaces \ldots with '...' as above. I think this follows from the 
specification of Rd format p. 8 of the 'parseRd' document  referenced in my 
previous email. 


For illiustration, I added the following lines before the Usage section in 
Bill's file topic_long_table_header.Rd.

\renewcommand{\ldots}{Aaaargh }
\renewcommand{\lmydots}{Uuugh }
\renewcommand{\mydots}{this is mydots }

Here the Usage entry for the shown argument  only is modified (with 3 
backslashes)

topic_long_table_header(x, col_names = NULL,
  (not changed)
  subsequent_page_notification = "\\\ldots continued \\\lmydots \\\mydots",
  (not changed)
   )

In the pdf file we see 

subsequent_page_notification = "\Aaaargh continued \Uuugh \\mydots"

\ldots and \lmydots are expanded but \mydots is not. I believe that \lmydots is 
expanded since it starts with 'l', see my previous email. In this case, 'R CMD 
check' gives an additional warning about the unescaped backslash: 

...
subsequent_page_notification = "Aaaargh  continued \Uuugh  
\\mydots"

This seems to happen since an attempt is made later to parse \Aaaargh and 
\Uuugh. If the Rd entry in the Usage section contaiin only one backslash, as in 
 
 subsequent_page_notification = "\ldots continued \lmydots \\\mydots",

then we get in all renderings: 

subsequent_page_notification = "Aaaargh continued Uuugh \\mydots"

'R CMD check' also shows this text (and complains, since it obviously is not as 
in the function deifnition,



b) With proper escaping (using 4, instead of 3 backslashes above) we get (in 
the pdf rendering):

subsequent_page_notification = "\... continued \\lmydots \\mydots"

\ldots is expanded but the other macros are not. Note that the expansion of 
\ldots here is due is due to the specific rendering for LaTeX, which replaces 
\\ldots by three dots (...), and doesn't use my Rd definition for \ldots, 
suggesting that  this occurs at a different place.


Georgi Boshnakov

From: b...@denney.ws [b...@denney.ws]
Sent: 24 August 2019 14:46
To: 'Duncan Murdoch'; Georgi Boshnakov; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Duncan,

The original Rd generated by roxygen2 had 4 backslashes:

https://github.com/billdenney/TopicLongTableR/blob/master/man/topic_long_table_header.Rd#L9

That generated a similar issue but check showed "\..." (backslash then 3 dots) 
instead of what is shown in the 2 backslashes case when check showed just "...".

So, while I agree that 4 backslashes would make the most sense for the .Rd 
file, there is still an issue somewhere with that 4 backslashes case.

Thanks,

Bill

-Original Message-----
From: Duncan Murdoch 
Sent: Saturday, August 24, 2019 8:37 AM
To: b...@denney.ws; 'Georgi Boshnakov' ; 
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

On 24/08/2019 7:35 a.m., Duncan Murdoch wrote:
> On 23/08/2019 1:33 p.m., b...@denney.ws wrote:
>> Hi Georgi,
>>
>> Thanks for this pointer.  My guess at this point is that I've found a
>> bug (or maybe a couple of bugs with 'utils::prompt()' and with the Rd
>> to help conversion), but let me know if you think otherwise.
>
> It's certainly not a bug in utils:prompt:  that's never called except
> by the user.

Actually, that's wrong.  utils::prompt() is generating bad code:  you need to 
have 4 backslashes in order to display 2.  It is just showing the string as it 
would be deparsed for display, it isn't modifying it so that it is appropriate 
as Rd source.

Duncan Murdoch


>
> It might be a bug in the .Rd parsing, but I don't think so, because
> I'm not seeing it when I write the .Rd file manually and view it in HTML.
>
> It's most likely a bug in the check code, because I am seeing the same
> &quo

Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

[Georgi Boshnakov]

HI Bill, 

I checked this as well, using the package you put on github for this purpose 
(note that the link you gave didn't work for me).
I tried a few variants but the bottom line is that "\ldots" and "\dots" are 
expanded even if the backslash is escaped. 

It is a feature rather than a bug, see towards the bottom of p. 8 in parseRd 
(https://developer.r-project.org/parseRd.pdf). 
In R strings, macros starting with "\l" are expanded (this is how 
\code{\link{sss}} works). 

But '\dots' is also expanded and this seems undocumented. I now recall that I 
have seen similar behaviour for "\dots" in R strings in the Examples section. 

I tried some hacks, such as redefining the '\ldots' but they don't work, since 
the Rd parser works recursively.
 


Georgi Boshnakov   



From: b...@denney.ws [b...@denney.ws]
Sent: 23 August 2019 18:33
To: Georgi Boshnakov; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Georgi,

Thanks for this pointer.  My guess at this point is that I've found a bug
(or maybe a couple of bugs with 'utils::prompt()' and with the Rd to help
conversion), but let me know if you think otherwise.

I just did that way, and the usage lines that were generated by
'utils::prompt()' and copied into the docs are:

topic_long_table_header(x, col_names = NULL,
  above_col_names = "\\hline", below_col_names = "\\hline",
  subsequent_page_notification = "\\ldots continued",
  latex_header = NULL, verbatim = NULL)

topic_long_table_footer(x, bottom_border = "\\hline",
  bottom_all_pages = NULL, bottom_last_page = NULL,
  subsequent_page_notification = "continued \\ldots",
  verbatim = NULL)

It is giving a very similar error with 'R CMD check' (outside devtools).
The escape of the backslashes appears to be needed, but "\\ldots" continues
to be translated into "...":

Codoc mismatches from documentation object 'topic_long_table_header':
topic_long_table_header
  Code: function(x, col_names = NULL, above_col_names = "\\hline",
 below_col_names = "\\hline",
 subsequent_page_notification = "\\ldots continued",
 latex_header = NULL, verbatim = NULL)
  Docs: function(x, col_names = NULL, above_col_names = "\hline",
 below_col_names = "\hline",
 subsequent_page_notification = "... continued",
 latex_header = NULL, verbatim = NULL)
  Mismatches in argument default values:
Name: 'above_col_names' Code: "\\hline" Docs: "\hline"
Name: 'below_col_names' Code: "\\hline" Docs: "\hline"
Name: 'subsequent_page_notification' Code: "\\ldots continued" Docs:
"... continued"
topic_long_table_footer
  Code: function(x, bottom_border = "\\hline", bottom_all_pages = NULL,
 bottom_last_page = NULL, subsequent_page_notification
 = "continued \\ldots", verbatim = NULL)
  Docs: function(x, bottom_border = "\hline", bottom_all_pages = NULL,
 bottom_last_page = NULL, subsequent_page_notification
 = "continued ...", verbatim = NULL)
  Mismatches in argument default values:
Name: 'bottom_border' Code: "\\hline" Docs: "\hline"
Name: 'subsequent_page_notification' Code: "continued \\ldots" Docs:
"continued ..."

Thanks,

Bill

-Original Message-
From: Georgi Boshnakov 
Sent: Friday, August 23, 2019 11:27 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Bill,

Sorry, I misunderstood the question.

To check if the problem is with R's tools, run
'utils::prompt(topic_long_table_header)" and see the usage section of the
generated file. Presumably, this should be the 'canonical way' to write the
usage entry for the function.
You can copy and paste it in the Rd file generated by roxygen2, then run 'R
CMD build' and 'R CMD check' (outside devtools).

Georgi


-Original Message-
From: b...@denney.ws [mailto:b...@denney.ws]
Sent: 23 August 2019 15:27
To: Georgi Boshnakov; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Georgi,

I'm not trying to use it as part of my documentation, it is one of my
function arguments.  I want the function argument to be displayed correctly
in the help, but it is not.  I'm curious how I should document the
"subsequent_page_notification" function argument in Rd.

Specifically, the actual function definition (R code) looks like:

R code:
--
topic_long_table_header <- function(x,
col_names=NULL,

Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

[Georgi Boshnakov]

Hi Bill,

Sorry, I misunderstood the question.

To check if the problem is with R's tools, run 
'utils::prompt(topic_long_table_header)" and see the usage section of the 
generated file. Presumably, this should be the 'canonical way' to write the 
usage entry for the function.
You can copy and paste it in the Rd file generated by roxygen2, then run 'R CMD 
build' and 'R CMD check' (outside devtools). 

Georgi


-Original Message-
From: b...@denney.ws [mailto:b...@denney.ws] 
Sent: 23 August 2019 15:27
To: Georgi Boshnakov; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Georgi,

I'm not trying to use it as part of my documentation, it is one of my
function arguments.  I want the function argument to be displayed correctly
in the help, but it is not.  I'm curious how I should document the
"subsequent_page_notification" function argument in Rd.

Specifically, the actual function definition (R code) looks like:

R code:
--
topic_long_table_header <- function(x,
col_names=NULL,
above_col_names="\\hline",
below_col_names="\\hline",
subsequent_page_notification="\\ldots
continued",
latex_header=NULL) {
  # The function body
}
--

So, I'm not trying to use LaTeX in the .Rd file; I'm trying to use it in R,
and I'm then copying it into the .Rd with extra escaping for the backslashes
(well, roxygen2 is doing the extra escaping).

Rd text
--
topic_long_table_header(x, col_names = NULL,
  above_col_names = "hline", below_col_names = "hline",
  subsequent_page_notification = "ldots continued",
  latex_header = NULL)
--

Thanks,

Bill

-Original Message-
From: Georgi Boshnakov  
Sent: Friday, August 23, 2019 9:52 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Rd is not LaTeX, although it resembles it.  You should use only markup
described in WRE.
For example, \dots is for the use case you mention. 

Georgi Boshnakov





-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
Behalf Of b...@denney.ws
Sent: 23 August 2019 04:15
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hello,

 

Does anyone know how to include verbatim \ldots (and maybe other LaTeX) in
an .Rd file correctly? 

 

When LaTeX is in the default arguments for a function, the code is
interpreted which makes the documentation not match the default formal
arguments.

 

An example is:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/R/topic_long_table_header_footer.R#L20

 

Which yields:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/man/topic_long_table_header.Rd#L10

 

Which gives the following warning with `devtools::check()`:

```

checking for code/documentation mismatches ... WARNING

Codoc mismatches from documentation object 'topic_long_table_header':

topic_long_table_header

  Code: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\\ldots continued
 ",

 latex_header = NULL)

  Docs: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\... continued",

 latex_header = NULL)

```

 

I'm not sure, but I think that the solution is to add more protection to the
\s when generating the roxygen or perhaps wrapping the arguments in some
form of verbatim block (if it's available).

 

Thanks,

 

Bill

 

P.S. This is also discussed in https://github.com/r-lib/roxygen2/issues/837
where it appears to be related to the conversion of .Rd to help files not
the roxygen step.

 


[[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: [R-pkg-devel] Literal LaTeX Text in Function Arguments

[Georgi Boshnakov]

Rd is not LaTeX, although it resembles it.  You should use only markup 
described in WRE.
For example, \dots is for the use case you mention. 

Georgi Boshnakov





-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of b...@denney.ws
Sent: 23 August 2019 04:15
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hello,

 

Does anyone know how to include verbatim \ldots (and maybe other LaTeX) in
an .Rd file correctly? 

 

When LaTeX is in the default arguments for a function, the code is
interpreted which makes the documentation not match the default formal
arguments.

 

An example is:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/R/topic_long_table_header_footer.R#L20

 

Which yields:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/man/topic_long_table_header.Rd#L10

 

Which gives the following warning with `devtools::check()`:

```

checking for code/documentation mismatches ... WARNING

Codoc mismatches from documentation object 'topic_long_table_header':

topic_long_table_header

  Code: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\\ldots continued
 ",

 latex_header = NULL)

  Docs: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\... continued",

 latex_header = NULL)

```

 

I'm not sure, but I think that the solution is to add more protection to the
\s when generating the roxygen or perhaps wrapping the arguments in some
form of verbatim block (if it's available).

 

Thanks,

 

Bill

 

P.S. This is also discussed in https://github.com/r-lib/roxygen2/issues/837
where it appears to be related to the conversion of .Rd to help files not
the roxygen step.

 


[[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] Documenting else's greed

[Georgi Boshnakov]

Indeed, an example in the documentation about this feature would be helpful, 
may be the one Hugh used. If an explanation is deemed appropriate, I would 
suggest including something along the lines of the following
(after the second paragraph of the Details section for if/while/etc.).

===

In these constructs the opening braces, if any, are part of the expression to 
be evaluated, not syntax delimiters. 
In particular, the expression does not necessarily end with the closing brace. 
For example, '{2} + 3' and '2 + 3' are equivalent expressions, so the first 
command below gives 0, not 3.

> if(TRUE) 0 else {2} + 3
[1] 0
> if(TRUE) 0 else 2 + 3
[1] 0


In practice, this confusion appears mainly in the 'else' part of 'if' 
constructs. But it is not limited there. For example, this defines a function 
with body x^2 + 1, for the same reasons, although one might expect an error. 

> f <- function(x){x^2} + 1
> f(2)
[1] 5
> as.character(body(f))
[1] "+" "{\nx^2\n}" "1"
> 

Georgi Boshnakov 

--

Message: 5
Date: Sat, 17 Aug 2019 02:36:39 +1000
From: Hugh Parsonage 
To: R-devel 
Subject: [Rd] Documenting else's greed
Message-ID:

Content-Type: text/plain; charset="utf-8"

I was initially pretty shocked by the result in this question:
https://stackoverflow.com/questions/57527434/when-do-i-need-parentheses-around-an-if-statement-to-control-the-sequence-of-a-f

Briefly, the following returns 0, not 3 as might be expected:

if (TRUE) {
0
} else {
2
} + 3> f
function(x){x^2} + 1
> body(f)
{
x^2
} + 1
> f(2)
[1] 5

At first I thought it the question was simply one of syntax
precedence, but I believe the result is too surprising to not warrant
note in the documentation of Control. I believe the documentation
should highlight that the `alt.expr` is demarcated by a semicolon or
newline and the end of a *statement*, not a closing brace per se.

Perhaps in the paragraph starting 'Note that it is a common mistake to
forget to put braces...' it should end with. "Note too that it is the
end of a *statement*, not a closing brace per se, that determines
where `alt.expr` ends. Thus if (cond) {0} else {2} + 2 means if (cond)
{0} else {2 + 2} not {if (cond) {0} else {2}} + 2."




--

Message: 6
Date: Fri, 16 Aug 2019 16:31:15 -0400
From: Duncan Murdoch 
To: Hugh Parsonage , R-devel

Subject: Re: [Rd] Documenting else's greed
Message-ID: 
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 16/08/2019 12:36 p.m., Hugh Parsonage wrote:
> I was initially pretty shocked by the result in this question:
> https://stackoverflow.com/questions/57527434/when-do-i-need-parentheses-around-an-if-statement-to-control-the-sequence-of-a-f
>
> Briefly, the following returns 0, not 3 as might be expected:
>
> if (TRUE) {
>  0
> } else {
>  2
> } + 3
>
> At first I thought it the question was simply one of syntax
> precedence, but I believe the result is too surprising to not warrant
> note in the documentation of Control. I believe the documentation
> should highlight that the `alt.expr` is demarcated by a semicolon or
> newline and the end of a *statement*, not a closing brace per se.
>
> Perhaps in the paragraph starting 'Note that it is a common mistake to
> forget to put braces...' it should end with. "Note too that it is the
> end of a *statement*, not a closing brace per se, that determines
> where `alt.expr` ends. Thus if (cond) {0} else {2} + 2 means if (cond)
> {0} else {2 + 2} not {if (cond) {0} else {2}} + 2."



I agree this is surprising, and should perhaps be pointed out in the
docs, but I don't think your suggestion is quite right.  { 2 } + 3 is a
legal expression.  It doesn't have to be the end of a statement that
limits the alt.expr, e.g. this could be one big statement:


  { if (TRUE) {
   0
 } else {
   2
 } + 3 }

What ends alt.expr is a token that isn't collected as part of alt.expr,
not just a semicolon (which separates statements) or a newline.  I don't
know how many of those there are, but the list would include at least
semicolon, newline, }, ), ], and maybe others.

Duncan Murdoch


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

Re: [R-pkg-devel] CRAN pre-test failed on NOTE "no visible binding for global variable"

[Georgi Boshnakov]

> ...
> if(getRversion() >= "2.15.1") utils::globalVariables(c("."))

Using such a general pattern eventually and  inevitably will prevent the check 
from reporting legitimate bugs. 
One alternative is to list explicitly the variables in question and make sure 
that they are not commonly used names like 'x'. 
If that is not practical and you use non-standard evaluation a lot,  consider 
'.data' from package 'lang' , see its documentation and/or Google it 
to find out how to use it. 

#' @importFrom rlang .data


Georgi Boshnakov

-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Iñaki Ucar
Sent: 02 July 2019 15:19
To: Berlanga, Antonio J
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] CRAN pre-test failed on NOTE "no visible binding for 
global variable"

raúl

On Tue, 2 Jul 2019 at 14:18, Berlanga, Antonio J
 wrote:
>
> Hi r-package-devel,
>
> I've submitted my first package but it failed the CRAN pre-tests on
> NOTES. I got:
>
> - my email
>
> - an extra non-standard file (which I have now added to .Rbuildignore)
>
> - NOTEs on "no visible global function definition"
>
> The first two I assume are harmless. The third I do not know how to fix
> (possible solutions below). Can it be ignored and suggest the fail was a
> false-positive?
>
> The third NOTE is:
>
> ###
>
> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
> Check: R code for possible problems, Result: NOTE
>   epi_clean_count_classes: no visible global function definition for
> '%>%'
>   epi_clean_count_classes: no visible binding for global variable '.'
>   epi_plot_heatmap: no visible binding for global variable 'Var1'
>   epi_plot_heatmap: no visible binding for global variable 'Var2'
>   epi_plot_heatmap: no visible binding for global variable 'value'
>   epi_plot_heatmap_triangle: no visible binding for global variable
> 'Var1'
>   epi_plot_heatmap_triangle: no visible binding for global variable
> 'Var2'
>   epi_plot_heatmap_triangle: no visible binding for global variable
> 'value'
>   epi_plot_heatmap_triangle: no visible global function definition for
> 'element_text'
>   epi_plot_heatmap_triangle: no visible global function definition for
> 'coord_fixed'
>   epi_plot_heatmap_triangle: no visible global function definition for
> 'element_blank'
>   epi_plot_heatmap_triangle: no visible global function definition for
> 'element_rect'
>   epi_plot_heatmap_triangle: no visible global function definition for
> 'guide_colorbar'
>   epi_stats_summary: no visible global function definition for '%>%'
>   epi_stats_tidy: no visible global function definition for '%>%'
>   epi_stats_tidy: no visible binding for global variable '.'
>   epi_stats_tidy: no visible binding for global variable 'x'
>   epi_stats_tidy: no visible binding for global variable 'n'
>   epi_stats_tidy: no visible binding for global variable 'id'
>   Undefined global functions or variables:
> %>% . Var1 Var2 coord_fixed element_blank element_rect element_text
> guide_colorbar id n value x
> ###
>
>
> Solutions seem to cause errors elsewhere and there does not appear to be
> an ideal one unfortunately. It seems to me that adding a file in the
> directory 'R' containing eg:
>
> ###
>
> if(getRversion() >= "2.15.1") utils::globalVariables(c("."))
>
> ###
>
> is one of the preferred ways. This seems far from ideal though.

If you use NSE in your package, this is the best solution. You may
also switch to SE.

Iñaki

__
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] methods package: A _R_CHECK_LENGTH_1_LOGIC2_=true

[Georgi Boshnakov]

I run checks with  R-devel rev. 76756 on several of my packages which use S4, 
with no ill effects. 

With the risk of not adding much, it seems that Martin's example, which I 
repeat below, suggests a crossover between several "signatures" involved here - 
the signature of the generic, the signature of the method (the argument for 
setMethod()), and the signature of the function object defining the method.

>> r2 <- oligoFn(object=diag(2),  target=array(42))
> Error in .local(object, target) :
> argument "target" is missing, with no default
>> getMethod("oligoFn", signature(object="matrix", subset="missing", 
target="array"))
> Method Definition:

> function (object, subset, target, value)
> {
> .local <- function (object, subset, target, value)
> list(object = object, target = target)
> .local(object, target)
> }


a) .local() seems superfluous here, since the signature of the function object 
is identical to that of the generic.

b) "subset" is "missing" in the signature of the method but it is (legally, I 
believe) present in the function object. The call .local(object, target) would 
be appropriate if "subset" was missing also from the signature of the function 
object (the latter would be illegal here). Alternatively, it could be named, as 
in .local(object, target = target)  or maybe even 
.local(object, , target).

--
Georgi Boshnakov 

--
Date: Sat, 29 Jun 2019 22:44:49 +0200
From: Martin Maechler 
To: R-devel , Henrik Bengtsson

Cc: Martin Maechler 
Subject: Re: [Rd] methods package: A _R_CHECK_LENGTH_1_LOGIC2_=true
error
Message-ID: <23831.52673.201433.320...@stat.math.ethz.ch>
Content-Type: text/plain; charset="utf-8"

>>>>> Martin Maechler
>>>>> on Sat, 29 Jun 2019 12:05:49 +0200 writes:

>>>>> Martin Maechler
>>>>> on Sat, 29 Jun 2019 10:33:10 +0200 writes:

>>>>> peter dalgaard
>>>>> on Fri, 28 Jun 2019 16:20:03 +0200 writes:

>>> > On 28 Jun 2019, at 16:03 , Martin Maechler 
 wrote:
>>> >
>>> >>>>>> Henrik Bengtsson
>>> >>>>>>on Thu, 27 Jun 2019 16:00:39 -0700 writes:
>>> >
>>> >> Using:
>>> >>
>>> >> untrace(methods::conformMethod)
>>> >> at <- c(12,4,3,2)
>>> >> str(body(methods::conformMethod)[[at]])
>>> >> ## language omittedSig <- omittedSig && (signature[omittedSig] != 
"missing")
>>> >> cc <- 0L
>>> >> trace(methods::conformMethod, tracer = quote({
>>> >>  cc <<- cc + 1L
>>> >>  print(cc)
>>> >>  if (cc == 31) {  ## manually identified
>>> >>untrace(methods::conformMethod)
>>> >>trace(methods::conformMethod, at = list(at), tracer = quote({
>>> >>  str(list(signature = signature, mnames = mnames, fnames = 
fnames))
>>> >>  print(ls())
>>> >>  try(str(list(omittedSig = omittedSig, signature = signature)))
>>> >>}))
>>> >>  }
>>> >> }))
>>> >> loadNamespace("oligo")
>>> >>
>>> >> gives:
>>> >>
>>> >> Untracing function "conformMethod" in package "methods"
>>> >> Tracing function "conformMethod" in package "methods"
>>> >> Tracing conformMethod(signature, mnames, fnames, f, fdef, definition)
>>> >> step 12,4,3,2
>>> >> List of 3
>>> >> $ signature: Named chr [1:4] "TilingFeatureSet" "ANY" "ANY" "array"
>>> >>  ..- attr(*, "names")= chr [1:4] "object" "subset" "target" "value"
>>> >>  ..- attr(*, "package")= chr [1:4] "oligoClasses" "methods" 
"methods" "methods"
>>> >> $ mnames   : chr [1:2] "object" "value"
>>> >> $ fnames   : chr [1:4] "object" "subset" "target" "value"
>>> >> [1] "f"  "fdef"   "fnames" "fsig"   "imf"
>>> >> [6] "method" "mnames" "omitted""o

Re: [R-pkg-devel] implications of staged install for data processing packages

[Georgi Boshnakov]

You need to give details what exactly gets you into trouble and about your use 
case, since any advice would be conditional on making assumptions about that. 
It is usually a bad a idea to have a function working on a hardcoded full 
filename. You will thank yourself later if you at least make it argument to 
your function(s). It can have for default value the one that is currently 
hardcoded. 

Please note that your use case does not seem inherently related to staged 
installation.
"Hardcoded" in the context of staged installation does not refer to any 
hardcoded path
but to those paths that contain the temporary installation directory. Such 
paths can be obtained, 
for example, with calls to system.path(), as illustrated by Tomas. 

Georgi Boshnakov



-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Florian Oswald
Sent: 28 June 2019 09:17
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] implications of staged install for data processing 
packages

Hi all

I ran into trouble with the changes starting to come in with R3.6 stemming
from the new staged installation, which checks and errors on hard coded
paths in R code. I understand there is an opt out, but still want to know.
here's the blog post:
https://developer.r-project.org/Blog/public/2019/02/14/staged-install/

I have several packages which look like that:

   1. large messy dataset stored on disk as `filename`, maybe a csv.
   2. R package has a function `clean(filename)` which reads the data and
   brings it into useable form
   3. R package does analysis
   4. R package exports results

`filename` is hard coded. What is the proper way to do this instead? Should
I store the inital raw data inside the R package in `/inst`? These things
are typically very large, so I like to decouple the raw data from the
package (easier to share).

thanks for any suggestions!

[[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] tools::package_native_routine_registration_skeleton?

[Georgi Boshnakov]

> ... reports that the fortran names of all the registered fortran functions 
> are “undocumented objects”...  

Those symbols should not be exported. In quantreg v5.33, NAMESPACE has 
'exportPattern(".")'. Maybe it is a good time to remove that and export 
explicitly the symbols that are meant for export.

Georgi Boshnakov


--

Message: 6
Date: Fri, 28 Jun 2019 09:06:52 +
From: "Koenker, Roger W" 
To: "r-devel@r-project.org" 
Subject: [Rd] tools::package_native_routine_registration_skeleton?
Message-ID: <00702a4f-67b0-4b0c-a791-e72af51c4...@illinois.edu>
Content-Type: text/plain; charset="utf-8"

I’m trying to sort out the consequences of adding registration for my quantreg 
package.
I’ve generated a quantreg_init.c file with the directive in the message title, 
and placed it
in my src directory.  The first issue is that 3 of the 20, or so registered 
functions have
the same name in fortran as the calling function in R.   This seems easy to 
fix.  More
puzzling is that R CMD check now reports that the fortran names of all the 
registered fortran
functions are “undocumented objects”.  Can someone point me to the officially 
sanctioned
way to deal with this:  presumably I don’t need to document them as if they 
were R functions.

Roger Koenker
r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk>
Department of Economics, UCL
London  WC1H 0AX.



[[alternative HTML version deleted]]



--

Subject: Digest Footer

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


--

End of R-devel Digest, Vol 196, Issue 25

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

Re: [R-pkg-devel] .Rd, LaTeX and Unicode

[Georgi Boshnakov]

Sorry, I failed to clarify that the link to ltnews.pdf was the point of my 
message. In some ways it is definitive from the LaTeX team. 

My understanding is that option 'mathletters' is not the default in ucs, since 
it produces math Greek and Hebrew letters also in text mode. 

Georgi Boshnakov


-Original Message-
From: Serguei Sokol [mailto:serguei.so...@gmail.com] 
Sent: 19 June 2019 09:51
To: Georgi Boshnakov; Martin Maechler; Hugh Parsonage
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] .Rd, LaTeX and Unicode

On 18/06/2019 17:10, Georgi Boshnakov wrote:
> 
> Since April 2018 'utf8' is the default input encoding in LaTeX, see
> http://anorien.csc.warwick.ac.uk/mirrors/CTAN/macros/latex/doc/ltnews.pdf and 
> they added some symbols in December.
Interesting ... but still not sufficient. I have a fairly recent latex 
system:
$ latex --version
pdfTeX 3.14159265-2.6-1.40.19 (TeX Live 2018/Mageia)

but unfortunately utf8 alone (and even including
\usepackage[mathletters]{ucs}) cannot compile utf8 math expressions.

I have also tried a full scale test on a tex file obtained with
$ R CMD Rd2pdf --no-clean pkgname
where I replaced

\usepackage[utf8]{inputenc}

by

\usepackage[mathletters]{ucs}
\usepackage[utf8x]{inputenc}

and it did not compile either. In addition, I had to replace every 
occurrence of

\inputencoding{utf8}

by

\inputencoding{utf8x}

after what pdflatex worked like a charm.

Serguei.

> 
> -Original Message-
> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On 
> Behalf Of Martin Maechler
> Sent: 18 June 2019 15:01
> To: serguei.so...@gmail.com; Hugh Parsonage
> Cc: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] .Rd, LaTeX and Unicode
> 
>>>>>> Hugh Parsonage
>>>>>>  on Tue, 18 Jun 2019 20:03:41 +1000 writes:
> 
>  > utf8x is deprecated
>  > 
> https://tex.stackexchange.com/questions/13067/utf8x-vs-utf8-inputenc#13070
> 
> Hmm... interestingly, I've tried quite a few versions of the
> above which started in 2011, but had been updated in April 2016 :
> https://tex.stackexchange.com/a/203804/7228
> from where it seems that
> 
>   \usepackage[T1]{fontenc}
>   \usepackage[utf8]{inputenc}
> 
> should be sufficient.  Further, note that from
>https://tex.stackexchange.com/a/238135/7228
> the {ucs} package should no longer be needed since ca. 2013,
> hence your \usepackage[mathletters]{ucs}  would not be needed either.
> 
> HOWEVER:  After losing at least half an hour now, trying many
> variants I found that the only version that works correctly for
> me (with a teTeX / TeXlive version of 2018) is the version
> Serguei Sokol proposes (below), including the use of the 'utf8x'
> option *and* the 'ucs' package ...
> 
> which is pretty surprising after having read the
> tex.statexchange threads ...
> 
>  > On Tue, 18 Jun 2019 at 7:52 pm, Serguei Sokol 
>  > wrote:
> 
>  >> Hi,
>  >>
>  >> I am preparing a package where I would like to use UTF characters in 
> .Rd
>  >> files. When the LaTeX comes to play, I got well known errors e.g.:
>  >> ! Package inputenc Error: Unicode character ∂ (U+2202)
>  >> (inputenc)not set up for use with LaTeX.
>  >>
>  >> It is coherent with what is said on this page
>  >> https://developer.r-project.org/Encodings_and_R.html :
>  >> "Since LaTeX cannot handle Unicode we would have to convert the 
> encoding
>  >> of latex help files or use Lambda (and tell it they were in UTF-8)."
> 
> That whole document has been very important and crucial, written
> by Prof Brian Ripley  who had worked a *LOT* to bring unicode to R,
> -- but it has been written 2004-2005  and indeed, I think it is
> probably fair to say that the above sentence no longer applies
> to current LaTeX engines (including "simple" pdflatex)... though really,
> I'm not the expert here, but I think it's a good point in time
> to reconsider how much UTF8 should be allowed/supported in *.Rd files.
> 
> One problem: This is (slightly) the wrong mailing list; this would have
> been a perfect topic for 'R-devel' (discussing about new
> features etc for R) instead
> ( but we'd rather keep it here for now.)
> 
> Martin Maechler
> ETH Zurich and R Core Team
> 
> 
> 
>  >> But LaTeX can support UTF8 as shown with this small example:
> 
>   \documentclass{article}
>   \usepackage[mathletters]{ucs}
>   \usepackage[utf8x]{inputenc}
>   
>   \begin{document}
>   The vorticity ω is defined as $ω = ∇ × u$.
>   \end{document}
> 
>  >> I can compile it

Re: [R-pkg-devel] .Rd, LaTeX and Unicode

[Georgi Boshnakov]

Since April 2018 'utf8' is the default input encoding in LaTeX, see
http://anorien.csc.warwick.ac.uk/mirrors/CTAN/macros/latex/doc/ltnews.pdf and 
they added some symbols in December.


Georgi Boshnakov






-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Martin Maechler
Sent: 18 June 2019 15:01
To: serguei.so...@gmail.com; Hugh Parsonage
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] .Rd, LaTeX and Unicode

>>>>> Hugh Parsonage 
>>>>> on Tue, 18 Jun 2019 20:03:41 +1000 writes:

> utf8x is deprecated
> https://tex.stackexchange.com/questions/13067/utf8x-vs-utf8-inputenc#13070

Hmm... interestingly, I've tried quite a few versions of the
above which started in 2011, but had been updated in April 2016 :
   https://tex.stackexchange.com/a/203804/7228
from where it seems that

\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}

should be sufficient.  Further, note that from
  https://tex.stackexchange.com/a/238135/7228 
the {ucs} package should no longer be needed since ca. 2013,
hence your \usepackage[mathletters]{ucs}  would not be needed either.

HOWEVER:  After losing at least half an hour now, trying many
variants I found that the only version that works correctly for
me (with a teTeX / TeXlive version of 2018) is the version
Serguei Sokol proposes (below), including the use of the 'utf8x'
option *and* the 'ucs' package ...

which is pretty surprising after having read the
tex.statexchange threads ...

> On Tue, 18 Jun 2019 at 7:52 pm, Serguei Sokol 
> wrote:

>> Hi,
>> 
>> I am preparing a package where I would like to use UTF characters in .Rd
>> files. When the LaTeX comes to play, I got well known errors e.g.:
>> ! Package inputenc Error: Unicode character ∂ (U+2202)
>> (inputenc)not set up for use with LaTeX.
>> 
>> It is coherent with what is said on this page
>> https://developer.r-project.org/Encodings_and_R.html :
>> "Since LaTeX cannot handle Unicode we would have to convert the encoding
>> of latex help files or use Lambda (and tell it they were in UTF-8)."

That whole document has been very important and crucial, written
by Prof Brian Ripley  who had worked a *LOT* to bring unicode to R,
-- but it has been written 2004-2005  and indeed, I think it is
probably fair to say that the above sentence no longer applies
to current LaTeX engines (including "simple" pdflatex)... though really,
I'm not the expert here, but I think it's a good point in time
to reconsider how much UTF8 should be allowed/supported in *.Rd files.

One problem: This is (slightly) the wrong mailing list; this would have
been a perfect topic for 'R-devel' (discussing about new
features etc for R) instead
( but we'd rather keep it here for now.)

Martin Maechler
ETH Zurich and R Core Team



>> But LaTeX can support UTF8 as shown with this small example:

 \documentclass{article}
 \usepackage[mathletters]{ucs}
 \usepackage[utf8x]{inputenc}
 
 \begin{document}
 The vorticity ω is defined as $ω = ∇ × u$.
 \end{document}

>> I can compile it with my LaTeX without problem. May be you too?
>> So my suggestion would be to place these two lines somewhere in LaTeX
>> header generated by R doc system:
>> \usepackage[mathletters]{ucs}
>> \usepackage[utf8x]{inputenc}
>> 
>> Note "utf8x" and not just "utf8" which is crucial for this example.
>> With a hope that it would fix unicode errors from LaTeX.
>> 
>> Best,
>> Serguei.

__
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] checks on CRAN notes 'examples_i386', but checks elsewhere do not

[Georgi Boshnakov]

It looks like you get the note when you run the check on the package directory, 
rather than on the tarball of the package. Undoubtedly, you submitted the 
tarball towinbuilder. develops::check also first builds the package and then 
does the flecks on the tarball.

If unwanted files do creep into the tarball, use file.Rbuildignore to tell the 
builder not to include them.


 Georgi Boshnakov 



From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of 
Kassel Hingee [kassel.hin...@research.uwa.edu.au]
Sent: 07 June 2019 05:35
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] checks on CRAN notes 'examples_i386', but checks 
elsewhere do not

Hi All,

This is my first time submitting a package to CRAN, and posting here. I
hope I get everything right.

Checks ran by CRAN for Windows systems generated a note that I don't know
where to start to solve:

* checking for non-standard things in the check directory ... NOTE
Found the following files/directories:
  examples_i386 examples_x64 lacunaritycovariance-Ex_i386.Rout
  lacunaritycovariance-Ex_x64.Rout tests_i386 tests_x64


This note was not generated when I uploaded the package directly to
winbuilder in either release or development versions of R.
It also wasn't generated when I ran devtools::check() on my own (unix) computer.

The results of the CRAN check can be seen here for another few days:
https://win-builder.r-project.org/incoming_pretest/lacunaritycovariance_1.0-3_20190606_051128/
The check log containing the above note is here:
https://win-builder.r-project.org/incoming_pretest/lacunaritycovariance_1.0-3_20190606_051128/Windows/00check.log
The package source can bee seen here:
https://github.com/kasselhingee/lacunaritycovariance/tree/release

I haven't noticed a solution discussed earlier on this email list and
web searching gave me no joy. I am hoping you can help!

yours
Kassel

[[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: [R-pkg-devel] Function Overloading of S4 Methods

[Georgi Boshnakov]

>Both are dispatched ONLY through the type of arguments.

Not quite. The dispatch may be by type but C++ identifies the arguments by 
position, while S4 applies R's dispatch rules
and respect the names, if present.  

Regarding your example from a previous email:

> ...You can write the previous function prototypes simply as
>
> int larger(int x, int y);
> char larger(char first, char second);

You can do this in C++ only because C++ doesn't care what you call the 
parameters. 
I don't know why you would want to do this (in C++ or R), it seems such a bad 
style even if possible.
In R you can define methods with different arguments, e.g. by declaring your 
function with a signature like:

larger <- function(x, y, first, second)

but then to use argument 'first' you need  to use it something like 
'larger(first = whatever, ...)'. 


Georgi Boshnakov

-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Linus Chen
Sent: 18 May 2019 10:28
To: Dario Strbenac
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Function Overloading of S4 Methods

Dear Dario,

I think differently, I think my examples show the resemblance between
the way of "dispatching" for S4 generic and that for C++ overloaded
function.
Both are dispatched ONLY through the type of arguments.

Again following your original example:
int larger(int x, int y);
char larger(char first, char second);
char larger(char x, char y){ # This will work!
if y>x y else x;
}
x = 'a' ; b='b';
larger(x,y);  # this will still call the second function.

The declaration "char largerChar(char first, char second);" does not
make any constraint on the name of argument...

Hope this helps.

Best,
Lei Chen

On Sat, May 18, 2019 at 10:00 AM Dario Strbenac
 wrote:
>
> Good day,
>
> Your conclusion seems to be different to the details you discussed. Don't you 
> intend to conclude that it's not possible with an S4 generic to define 
> methods with different argument names which is different to a language such 
> as C++?
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> __
> 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] Registered S3 methods from standard package

[Georgi Boshnakov]

> The general idea is to replace plot.default() with an alternative
(matching all arguments) and export. This would allow users to simply
load the package and use base graphics functions as normal, but get a
pretty graph.

Have you checked that this actually works? Many base R functions do some 
preparation and call directly plot.default(), so they both bypass the method 
and see graphics::plot.default, not yours, see e.g. plot.ts().


Georgi Boshnakov


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Colin Gillespie
Sent: 13 May 2019 08:22
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Registered S3 methods from standard package

Dear All,

I'm developing a small package to make plotting methods a little bit
nicer looking:

https://github.com/jumpingrivers/prettyB/

The general idea is to replace plot.default() with an alternative
(matching all arguments) and export. This would allow users to simply
load the package and use base graphics functions as normal, but get a
pretty graph.

The general pattern I follow is:

https://github.com/jumpingrivers/prettyB/blob/master/R/plot.R#L23

which then includes S3method(plot,default) in my NAMESPACE file. When
building and checking the package I get

Registered S3 methods from standard package(s) overwritten by 'prettyB':
method  from
plot.defaultgraphics

which CRAN does not permit.

Question: Is it possible to achieve the functionality I'm after
(replacing the default plot.default() functions) while following the
CRAN rules?

Thanks

Colin

__
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] can't commit changes to a package on R-Forge

[Georgi Boshnakov]

Thanks, I didn't realise that password approach has been dropped.

Georgi Boshnakov


-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com] 
Sent: 06 April 2019 12:40
To: Georgi Boshnakov; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] can't commit changes to a package on R-Forge

On 06/04/2019 6:39 a.m., Georgi Boshnakov wrote:
> Hi,
> 
> I was given admin access to an R package developed on R-Forge, which I have 
> not used before. I installed a command line svn client, checked out the 
> package
>> svn checkout svn://geob...@svn.r-forge.r-project.org/svnroot/fints/
> 
> update, etc works fine, until I try to commit the changes:
> 
>> svn commit -m "update by Georgi"
> svn: E170001: Commit failed (details follow):
> svn: E170001: Authorization failed
> 
> The commit command doesn't ask me for username/password and all my attempts 
> were in vain. Google search finds similar queries but the answers didn't help.
> 
> I can't find any way to make it ask me for credentials and will appreciate 
> any help.

I believe r-forge uses ssh public keys for authorization.  The manual 
(http://download.r-forge.r-project.org/R-Forge_Manual.pdf) mentions the 
possibility of password authentication, but I think that was dropped 
several years ago.  You need to upload your key in the Account 
Maintenance page:  detailed instructions are in the manual.

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

[R-pkg-devel] can't commit changes to a package on R-Forge

[Georgi Boshnakov]

Hi,

I was given admin access to an R package developed on R-Forge, which I have not 
used before. I installed a command line svn client, checked out the package
>svn checkout svn://geob...@svn.r-forge.r-project.org/svnroot/fints/

update, etc works fine, until I try to commit the changes:

>svn commit -m "update by Georgi"
svn: E170001: Commit failed (details follow):
svn: E170001: Authorization failed

The commit command doesn't ask me for username/password and all my attempts 
were in vain. Google search finds similar queries but the answers didn't help.

I can't find any way to make it ask me for credentials and will appreciate any 
help.


Georgi Boshnakov




[[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] attempt to re-insert old removed package

[Georgi Boshnakov]

It depends on the specific case but attempting to check with the previous 
maintainer/author looks like a courteous first step
before taking over.

Georgi Boshnakov


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Dirk Eddelbuettel
Sent: 05 April 2019 12:53
To: peter dalgaard
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] attempt to re-insert old removed package


On 5 April 2019 at 13:30, peter dalgaard wrote:
| For most packages[*], I assume that you can just take on the role as 
maintainer, bump the version number and resubmit. If you don't actually 
maintain it, then of course it might fall of CRAN again after a while.
| 
| -pd
| 
| [*] Actually, I expect that CRAN policy implies "all" here; I just can't be 
bothered to check...

One important aspect, though, is that 

| > However some small changes to the source were enough to get it installed
| > via R CMD INSTALL, so I thought I might how difficult it would be to get it

may not be enough.  Re-admitting a dead package is closer to admitting a new
package so it is expected to be free and clear of WARNING, NOTE and ERROR too.

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

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

Re: [R-pkg-devel] Help request on Rd2pdf | Fwd: [CRAN-pretest-archived] CRAN submission spsh 1.0.190311

[Georgi Boshnakov]

Hi,

> Turning to the R-Terminal executing /R CMD Rd2pdf/ Leads to:
> 
> Converting Rd files to LaTeX ...
> 
>   spsh_1.0.1.tar.gz
>
> Warning in readLines(f) : line 1 appears to contain an embedded nul

You really need to give the exact command you run, it is not just 'R CMD 
Rd2pdf'.
The error message indicates that probably you run  'R CMD Rd2pdf 
spsh_1.0.1.tar.gz ',
which is incorrect - you need to run Rd2pdf on the directory were your source 
package is, not on the tar ball,  eg. 'R CMD Rd2pdf spsh '.

The LaTeX error indicates that you probably used something like \code{some 
code} but omitted the closing curly parenthesis. 

Georgi Boshnakov


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Tobias KD Weber
Sent: 13 March 2019 09:50
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Help request on Rd2pdf | Fwd: [CRAN-pretest-archived] 
CRAN submission spsh 1.0.190311

Dear people,

I submitted a package to CRAN and got an error on the pdf manual creation 
(solved other minor issues, full response from cran-submissi...@r-project.org 
please see email below).

The response to an error and warnings detailed:

* using log directory 'd:/RCompile/CRANincoming/R-devel/spsh.Rcheck'

* using R Under development (unstable) (2019-03-09 r76216) * using
platform: x86_64-w64-mingw32 (64-bit) * using session charset: ISO8859-1
* checking for file 'spsh/DESCRIPTION' ... OK * checking extension type ... 
Package * this is package 'spsh' version '1.0.190311' * package
encoding: UTF-8 * checking CRAN incoming feasibility ... WARNING [... 
deleted  all OK ...] * checking PDF version of manual ... WARNING LaTeX 
errors when creating PDF version. This typically indicates Rd problems. LaTeX 
errors found: ! LaTeX Error: There's no line here to end. See the LaTeX manual 
or LaTeX Companion for explanation. Type H  for immediate help. ... ! 
Paragraph ended before \Rd@code was complete.  \par l.1340 * 
checking PDF version of manual without hyperrefs or index ... ERROR * DONE 
Status: 1 ERROR, 2 WARNINGs, 1 NOTE


Turning to the R-Terminal executing /R CMD Rd2pdf/ Leads to:

Converting Rd files to LaTeX ...

   spsh_1.0.1.tar.gz

Warning in readLines(f) : line 1 appears to contain an embedded nul

Warning in readLines(f) : line 19 appears to contain an embedded nul

[... deleted many more lines ... ]

Warning in readLines(f) : line 3058 appears to contain an embedded nul

Warning in readLines(f) : line 3117 appears to contain an embedded nul

Warning in readLines(f) :

   incomplete final line found on 'spsh_1.0.1.tar.gz'

Error in iconv(lines, encoding, "UTF-8", sub = "byte") :

   embedded nul in string: 
'\001\f\023aIeK\021\030\023U\\,%\035\002\003\n\v\\}s\021heyt\036m\037
PaK\032\027Z,C %2u@\031w\021('\017}gcn\004L\006\0267#!|E\017\

177\\1w\032|Gf\005JS*a\177F\\\aa_Yr]\033sVA~~\\,\026Sa_QnXMF\017B?O,<\003~\toMZ\023i\006\177\0\006\005qKvB_~\t\a\a5l\001\177=MWu\030]\t>JF\nDx\004T\t\023

`[\025?n)g^\004oMhW{%l\aO\fo>\033>\016{_n?]d|\v>V'


I have truely searched most of the morning for a solution, but none to be found.
Any ideas how to solve this would be very much appreciated.

Kind Regards,
Tobias



 Weitergeleitete Nachricht 
Betreff:[CRAN-pretest-archived] CRAN submission spsh 1.0.190311
Datum:  Tue, 12 Mar 2019 19:43:25 +0100
Von:lig...@statistik.tu-dortmund.de
Antwort an: cran-submissi...@r-project.org
An: tobias.we...@uni-hohenheim.de
Kopie (CC): cran-submissi...@r-project.org



Dear maintainer,
package spsh_1.0.190311.tar.gz does not pass the incoming checks automatically, 
please see the following pre-tests:
Windows: 
<https://win-builder.r-project.org/incoming_pretest/spsh_1.0.190311_20190312_152345/Windows/00check.log>
Status: 1 ERROR, 2 WARNINGs, 1 NOTE
Debian: 
<https://win-builder.r-project.org/incoming_pretest/spsh_1.0.190311_20190312_152345/Debian/00check.log>
Status: 1 ERROR, 2 WARNINGs, 1 NOTE

Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on the 
R-package-devel mailing list:
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
If you are fairly certain the rejection is a false positive, please reply-all 
to this message and explain.
More details are given in the directory:
<https://win-builder.r-project.org/incoming_pretest/spsh_1.0.190311_20190312_152345/>
The files will be removed after roughly 7 days.
No strong reverse dependencies to be checked.
Best regards,
CRAN teams' auto-check service

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

Re: [R-pkg-devel] Package update submission to CRAN fails on pretest

[Georgi Boshnakov]

The link you gave, 
https://cran.r-project.org/web/checks/check_results_cNORM.html,
is to the check results for the package currently on CRAN and it is indeed v. 
1.0.1
(it is linked from https://CRAN.R-project.org/package=cNORM).

Was this really the link you got from CRAN's pretest? Sometimes they ask if 
care has been taken about NOTEs/WARNINGs for the current CRAN version, since 
some tests are not done during submission, but this doesn't seem the case here.

Georgi Boshnakov


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Wolfgang Lenhard
Sent: 07 December 2018 07:55
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Package update submission to CRAN fails on pretest

Dear list,
I am getting problems when trying to submit an update of the package 
cNORM to CRAN. I am developing the package with RStudio and devtools and 
I am using Travis for automatic testing. The package is tested locally 
on Win10 and Mac OS X and on Travis with Ubuntu and Mac both for 
development and release versions of R. All local tests and tests on 
Travis work flawlessly - no errors, warning or notes. When submitting to 
CRAN, a note and an error show up on some of the Linux OS (Fedora & 
Solaris) and Mac OS X, while others display an 'OK' (Win, Debian). The 
results: https://cran.r-project.org/web/checks/check_results_cNORM.html

- error: This seems to be related to the vignette with the following 
message:
> * checking examples ... ERROR
> Running examples in ‘cNORM-Ex.R’ failed
I can however not identify the location of the error

- Note: Check: data for non-ASCII characters

The strange thing is: I checked all data files multiple times. They 
mainly consist of data.frames with numerics and all colnames  are ASCII. 
I am not able to replicate the issue. The same is true for the error, 
which does not show up on Travis and as well locally. And finally, the 
results state, that the version of the package is 1.0.1, which had been 
the first submission to CRAN a month ago. The current version of the 
package is 1.1.1. Could this be the reason for the problem?

Do you have an idea how to progress with the testing or how to locate 
the errors? Any help is welcome.

Best regards,
     Wolfgang Lenhard


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

[Rd] incomplete description of return value of stats::uniroot()?

[Georgi Boshnakov]

The "Value" section in the documentation of stats::uniroot() mentions component 
"init.it" of the returned result:

> "... Further components may be added in future: component \code{init.it}  was 
> added in \R 3.1.0."

I don't see "init.it"  described anywhere in that help page. It is technically 
not an omission, since the description says "at least the following 
components...", so maybe it is absent on purpose?

>From my reading of the source something like the following could be added to 
>src/library/stats/man/uniroot.Rd, before the sentence quoted above:

\code{iter} includes the number of iterations, if any, done initially to ensure 
opposite signs at the ends of the interval.
This number is available separately in component \code{init.it}. If no 
extension of the interval was attempted, \code{init.it} is set to NA. 


Georgi Boshnakov

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

Re: [R-pkg-devel] creating a link to a vignette in a .Rd file

[Georgi Boshnakov]

It is somewhat problematic to make the link to the vignette fully portable.  
The solution with "../doc/..." may not work if the reference manual is read off 
the CRAN page of a package. For a CRAN package, an alternative is to link to 
the vignette on its CRAN page (if the vignette is already there), with the 
downside that the link will not work offline. 

An alternative, which can be used along with a link, is to give a command that 
opens the vignette \code{vignette("xxx", package = "pkg")} or even 
\code{browseVignettes(package = "pkg")}. This will be directly usable also when 
the help is rendered in text mode. The vignette() command could also be put in 
the "Examples" section. 

Georgi Boshnakov


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Fox, John
Sent: 20 November 2018 01:16
To: Hadley Wickham
Cc: R Package Development
Subject: Re: [R-pkg-devel] creating a link to a vignette in a .Rd file

Dear Hadley,

You're right -- my approach was flawed and the document doesn't open even when 
the file URL is hard-coded in the .Rd file. With that hint, I found the 
following solution:

\href{../doc/partial-residuals.pdf}{partial-residuals vignette}

This works and passes package checking. A caveat: I tried it only under 
Windows, both inside and outside of RStudio. I'll follow up on macOS and Linux 
and report if there are problems.

I'm surprised that this question hasn't arisen more frequently -- wanting to 
link to vignettes from help pages seems natural to me. I found a couple of 
queries in a web search but no solution. 

Thanks for this,
 John

> -Original Message-
> From: Hadley Wickham [mailto:h.wick...@gmail.com]
> Sent: Monday, November 19, 2018 6:21 PM
> To: Fox, John 
> Cc: R Package Development 
> Subject: Re: [R-pkg-devel] creating a link to a vignette in a .Rd file
> 
> On Mon, Nov 19, 2018 at 4:49 PM Fox, John  wrote:
> >
> > Dear r-package-devel list members,
> >
> > I'd like to create a link to a package vignette from a help file in the same
> package, for example to the "partial-residuals" vignette in the effects 
> package
> from effect.Rd. I'm able to generate a URL for the vignette as follows:
> >
> > \Sexpr[results=text]{paste0("file://", system.file("doc",
> > "partial-residuals.pdf", package="effects"))}
> >
> > but I'm unable to link to the resulting text string using href{}{} or url{}
> because \Sexpr[etc]{etc.} is treated as verbatim text rather than evaluated.
> >
> > Is there a way around this problem or another approach that works?
> 
> Have you confirmed that a raw file:// url works?  I would be mildly surprised 
> if
> it did, given my understanding of how web browser security works (which is
> patchy, but you should still check before going too far down this path).
> 
> Don't you just need `results=rd` ?
> 
> \Sexpr[results=rd]{paste0("\\url{file://", system.file("doc", "partial-
> residuals.pdf", package="effects"), "}")}
> 
> Hadley
> 
> --
> http://hadley.nz
__
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] nativeRoutines error when using roxygen2 in RStudio

[Georgi Boshnakov]

Without code we are guessing.  A bug is possible but I will make another guess 
suggestion.

Delete all binary files created by devtools during compilation in your package 
directory.
devtools::load_all() is so fast partly because it recompiles the C/Fortran 
files only when necessary
but sometimes compilation may be needed even if devtools thinks otherwise.

 Georgi Boshnakov


-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com] 
Sent: 07 November 2018 00:26
To: Rampal Etienne; Georgi Boshnakov; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] nativeRoutines error when using roxygen2 in RStudio

On 06/11/2018 5:17 PM, Rampal Etienne wrote:
> Dear Duncan,
> 
> I don't get it when using R CMD check.
> 
> I only get it when building/loading using roxygen2 or when I call
> load_all (which roxygen2 does too, I think). load_all calls load_dll
> which then throws this error. I have registered my routines in
> R_init_secsse.c:
> 
> void R_init_secsse(DllInfo *dll)
> {
>     R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
>     R_useDynamicSymbols(dll, FALSE);
> }
> 
> Any suggestions?

Nope!  Sounds like a bug in devtools/roxygen2, but I don't know either 
of those packages well.

Duncan Murdoch

> 
> Cheers, Rampal
> 
> 
> On 06-Nov-18 22:50, Duncan Murdoch wrote:
>> On 06/11/2018 3:27 PM, Rampal Etienne wrote:
>>> Dear Georgi,
>>>
>>> Thanks for your suggestions. I have tried to install the development
>>> version of roxygen2, but to no avail.
>>>
>>> I don't have a Collate field in DESCRIPTION.
>>>
>>> devtools::check() gives me:
>>>
>>> Updating secsse documentation Loading secsse Registered S3 method
>>> overwritten by 'dplyr': method from as.data.frame.tbl_df tibble
>>> Registered S3 method overwritten by 'geiger': method from
>>> unique.multiPhylo ape Error in nativeRoutines[[lib]] <- routines :
>>> object 'nativeRoutines' not found
>>
>> Do you get that error if you run "R CMD check" on the tarball of your
>> package?
>>
>> If so, how comfortable are you with debugging R code?  I can tell you
>> how to debug the check process, but it's a little tricky.
>>
>> Duncan Murdoch
>>
>>>
>>>
>>> Any other suggestions?
>>>
>>> Cheers, Rampal
>>>
>>> On 02-Nov-18 08:33, Georgi Boshnakov wrote:
>>>> Try installing the latest development version of roxygen2, if you
>>>> are not using it already.
>>>> There was a bug in the released version preventing installation in
>>>> some cases.
>>>> If you don't want to use development version of roxygen2,
>>>> try putting all filenames in the Collate field in DESCRIPTION on one
>>>> line and make sure that there is a single space
>>>> between them. This should work if your problem is what I think.
>>>>
>>>> By the way, in such cases you will get more informative messages if
>>>> you run devtools::check().
>>>>
>>>> -- 
>>>> Georgi Boshnakov
>>>>
>>>>
>>>> 
>>>> From: R-package-devel [r-package-devel-boun...@r-project.org] on
>>>> behalf of Rampal Etienne [rampaletie...@gmail.com]
>>>> Sent: 01 November 2018 22:40
>>>> To: r-package-devel@r-project.org
>>>> Subject: [R-pkg-devel] nativeRoutines error when using roxygen2 in
>>>> RStudio
>>>>
>>>> Since a few weeks (after updating R-devel and Rtools) I get the
>>>> following error when trying to build a package or document it, when
>>>> using roxygen2 in RStudio:
>>>>
>>>> In R CMD INSTALL Error in nativeRoutines[[lib]] <- routines : object
>>>> 'nativeRoutines' not found Calls: suppressPackageStartupMessages ...
>>>> withCallingHandlers ->  -> load_all -> load_dll Execution
>>>> halted
>>>>
>>>> When I disable roxygen2, I do not get this error, but of course the
>>>> documentation is not created.
>>>>
>>>> I have installed the latest versions of RStudio, Rtools, R-devel,
>>>> roxygen2, pkgload, but the problem persists.
>>>>
>>>> Does anybody have a clue what is causing this? I am using Windows 10,
>>>> and the package contains Fortran code.
>>>>
>>>> Kind regards,
>>>> Rampal Etienne
>>>>
>>>>    [[alternative HTML version deleted]]
>>>>
>>>> __
>>>> R-package-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>>
>>>  [[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: [R-pkg-devel] nativeRoutines error when using roxygen2 in RStudio

[Georgi Boshnakov]

Try installing the latest development version of roxygen2, if you are not using 
it already.
There was a bug in the released version preventing installation in some cases. 
If you don't want to use development version of roxygen2,
try putting all filenames in the Collate field in DESCRIPTION on one line and 
make sure that there is a single space
between them. This should work if your problem is what I think.

By the way, in such cases you will get more informative messages if you run 
devtools::check(). 

--
Georgi Boshnakov  



From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of 
Rampal Etienne [rampaletie...@gmail.com]
Sent: 01 November 2018 22:40
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] nativeRoutines error when using roxygen2 in RStudio

Since a few weeks (after updating R-devel and Rtools) I get the
following error when trying to build a package or document it, when
using roxygen2 in RStudio:

In R CMD INSTALL Error in nativeRoutines[[lib]] <- routines : object
'nativeRoutines' not found Calls: suppressPackageStartupMessages ...
withCallingHandlers ->  -> load_all -> load_dll Execution halted

When I disable roxygen2, I do not get this error, but of course the
documentation is not created.

I have installed the latest versions of RStudio, Rtools, R-devel,
roxygen2, pkgload, but the problem persists.

Does anybody have a clue what is causing this? I am using Windows 10,
and the package contains Fortran code.

Kind regards,
Rampal Etienne

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

[Rd] disappearing paragraphs in html rendering of text from Rd macros

[Georgi Boshnakov]

Recent changes in R-devel seem to change the HTML rendering of text returned by 
Rd macros,
in that now empty lines do not cause paragraphs to end (the empty lines are 
kept but  tags are not set).
As a result, multiple paragraphs are output as a single one.

A complete example Rd file is at: 
https://github.com/GeoBosh/reprexes/blob/master/disappearingParagraphs/a.Rd

rendered (2018-10-28) with R-devel: 
https://github.com/GeoBosh/reprexes/blob/master/disappearingParagraphs/a.html 

and R-3.5.1patched: 
https://github.com/GeoBosh/reprexes/blob/master/disappearingParagraphs/a351.html
 

The exact system information used for rendering is in the above html files. 

In essence, the following:

\newcommand{\abc}{\Sexpr[stage=build,results=rd]{paste0(letters[1:4], collapse 
= "\n\n")}}

produces in R-devel something like 

a

b

c

d

where the empty lines may be distorted in this email, while in R-3.5.1 the 
empty lines cause paragraph tags around each chunk:

a

b

c

d

Directly embedding the Sexpr in the Rd file also produces all  tags in 
R-devel and R-3.5.1patched.,

---

Georgi Boshnakov

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

Re: [R-pkg-devel] Trying to work around missing functionality

[Georgi Boshnakov]

If you don't insist on putting the variable in the global environment, 
variations of the following give a cleaner solution:

TraceSetup_1 <- local({
ifn = 0
igr = 0
ftrace = FALSE
fn = NA
gr = NA

function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
ifn<<- ifn
igr<<- igr
ftrace <<- ftrace
fn <<- fn
gr <<- gr
parent.env(environment())
}
})

For example,

TraceSetup_1 <- local({
+ ifn = 0
+ igr = 0
+ ftrace = FALSE
+ fn = NA
+ gr = NA
+ function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
+ ifn<<- ifn
+ igr<<- igr
+ ftrace <<- ftrace
+ fn <<- fn
+ gr <<- gr
+ parent.env(environment())
+ }
+ })
> 
> e <- TraceSetup_1(fn = function(x) x^2)
> ls(e)
[1] "fn" "ftrace" "gr" "ifn""igr"   
> e$fn
function(x) x^2

## let's change 'fn':
> e$fn <- function(x) x^4
> e$fn
function(x) x^4


Note that the environment is always the same, so can be accessed from anywhere 
in your code:

> e2 <- environment(TraceSetup_1)
> e2

> identical(e2, e)
[1] TRUE
> 

If you need a new environment every time, a basic setup might be:

TraceSetup_2 <- local({
staticVar1 <- NULL
## other variables here

function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
## force evaluation of the arguments
ifn
igr
ftrace 
fn 
gr 
environment()
}
})

There is no need for local() here but usually one needs also some static 
variables.
Now every call gives a different environment  (but all have the same parent):

ea <- TraceSetup_2(fn = function(x) x^2 - 2*x + 1)
> ls(ea)
[1] "fn" "ftrace" "gr" "ifn""igr"   
> ea$fn
function(x) x^2 - 2*x + 1
> 
> eb <- TraceSetup_2(fn = function(x) x^2 + 1)
> eb$fn
function(x) x^2 + 1
> 
> ## ea$fn is still the same:
> ea$fn
function(x) x^2 - 2*x + 1
>

Obviously, in this case some further arrangements are  needed for the 
environments to be made available to the external world.

Hope this helps,
Georgi Boshnakov


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of J C Nash
Sent: 28 August 2018 14:18
To: Fox, John; Richard M. Heiberger
Cc: List r-package-devel
Subject: Re: [R-pkg-devel] Trying to work around missing functionality

Indeed, it appears that globalVariables must be outside the function. However, 
I had quite a bit of
fiddle to get things to work without errors or warnings or notes. While I now 
have a package that
does not complain with R CMD check, I am far from satisfied that I can give a 
prescription. I had
to remove lines in the rootfinder like
   envroot$fn <- fn
that were used to set the function to be used inside my instrumented function, 
and instead
call TraceSetup(fn=fn, ...) where a similar statement was given. Why that 
worked while the direct
assignment (note, not a <<- one) did not, I do not understand. However, I will 
work with this for
a while and try to get a better handle on it.

Thanks for the pointer. As an old-time programmer from days when you even set 
the add table, I'm
still uncomfortable just putting code in a directory and assuming it will be 
executed, i.e., the
globals.R file. However, I now have this set to establish the global structure 
as follows

> ## Put in R directory. 
> if(getRversion() >= "2.15.1") { utils::globalVariables(c('envroot')) } # Try 
> declaring here 
> groot<-list(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA, label="none")
> envroot <- list2env(groot) # Note globals in FnTrace

Then TraceSetup() is

> TraceSetup <- function(ifn=0, igr=0, ftrace=FALSE, fn=NA, gr=NA){
>envroot$ifn <- ifn
>envroot$igr <- igr
>envroot$ftrace <- ftrace
>envroot$fn <- fn
>envroot$gr <- gr
>return()
> }

and it is called at the start of the rootfinder routine.

Thus I am establishing a global, then (re-)setting values in TraceSetup(), then
incrementing counters etc. in the instrumented FnTrace() that is the function 
for which I find
the root, which calls fn() given by the "user". Messy, but I can now track 
progress and measure
effort.

I'm sure there are cleaner solutions. I suggest offline discussion would be 
better until such
options are clearer.

Thanks again.

JN



On 2018-08-28 12:01 AM, Fox, John wrote:
> Hi John,
> 
> It's possible that I didn’t follow what you did, but it appears as if you 
> call globalVariables() *inside* the function. Instead try to do as Richard 
> Heiberger suggested and place the call outside of t

Re: [R-pkg-devel] CRAN note: src/Makevars: SHLIB_OPENMP_CXXFLAGS is included in PKG_CXXFLAGS but not in PKG_LIBS

[Georgi Boshnakov]

Dirk and James,

Many thanks for the detailed advice.

Georgi


From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of 
Balamuta, James Joseph [balam...@illinois.edu]
Sent: 21 August 2018 02:44
To: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] CRAN note: src/Makevars: SHLIB_OPENMP_CXXFLAGS is 
included in PKG_CXXFLAGS but not in PKG_LIBS

In short, the default Makevars{.win} file should be updated with:

CXX_STD = CXX11
PKG_CXXFLAGS = $(SHLIB_OPENMP_CXXFLAGS)
PKG_LIBS = $(SHLIB_OPENMP_CXXFLAGS) $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

c.f. 
https://github.com/RcppCore/RcppArmadillo/blob/58b11c738d31b9e8d9fa6b39e2290b2ac08aefc4/inst/skeleton/Makevars#L11-L14

Sincerely,

JJB

On 8/20/18, 5:40 PM, "R-package-devel on behalf of Dirk Eddelbuettel" 
 wrote:


On 20 August 2018 at 22:14, Georgi Boshnakov wrote:
| Hi,
|
| Recently the results page of my package on CRAN at
| https://cran.r-project.org/web/checks/check_results_sarima.html,
| started to show the NOTE below for some systems.
| I am using Rcpp/RcppArmadillo without any manual interventions on my side.
|
| Is it reasonable to expect that the NOTE will disappear if I rebuild the 
package with an up-to-date version of  Rcpp
| and maybe rerunning RcppAttributes().?

No you have to edit src/Makevars{,win} yourself.

| ==
|
| Check: use of SHLIB_OPENMP_*FLAGS in Makefiles
| Result: NOTE
|  src/Makevars: SHLIB_OPENMP_CXXFLAGS is included in PKG_CXXFLAGS but 
not in PKG_LIBS
|  src/Makevars: SHLIB_OPENMP_CFLAGS is included in PKG_LIBS but not in 
PKG_CFLAGS
|  src/Makevars.win: SHLIB_OPENMP_CXXFLAGS is included in PKG_CXXFLAGS 
but not in PKG_LIBS
|  src/Makevars.win: SHLIB_OPENMP_CFLAGS is included in PKG_LIBS but 
not in PKG_CFLAGS

Basically just use SHLIB_OPENMP_CXXFLAGS in PKG_LIBS as well. As the
paragraph quoted below suggests.

Our initial example in RcppArmadillo was sloppy was mix *_CFLAGS and
*_CXXFLAGS use, and that is no longer liked at the CRAN side.

Dirk

| Use of these macros is discussed in sect 1.2.1.1 of 'Writing R
| Extensions'. The macros for different languages may differ so the
| matching macro must be used in PKG_CXXFLAGS (etc) and match that used
| in PKG_LIBS (except for F77: see the manual).
|
| 
|
| __
| R-package-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel

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


__
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] CRAN note: src/Makevars: SHLIB_OPENMP_CXXFLAGS is included in PKG_CXXFLAGS but not in PKG_LIBS

[Georgi Boshnakov]

Hi,

Recently the results page of my package on CRAN at
https://cran.r-project.org/web/checks/check_results_sarima.html,
started to show the NOTE below for some systems.
I am using Rcpp/RcppArmadillo without any manual interventions on my side. 

Is it reasonable to expect that the NOTE will disappear if I rebuild the 
package with an up-to-date version of  Rcpp
and maybe rerunning RcppAttributes().?

Georgi Boshnakov

==

Check: use of SHLIB_OPENMP_*FLAGS in Makefiles 
Result: NOTE 
 src/Makevars: SHLIB_OPENMP_CXXFLAGS is included in PKG_CXXFLAGS but not in 
PKG_LIBS
 src/Makevars: SHLIB_OPENMP_CFLAGS is included in PKG_LIBS but not in 
PKG_CFLAGS
 src/Makevars.win: SHLIB_OPENMP_CXXFLAGS is included in PKG_CXXFLAGS but 
not in PKG_LIBS
 src/Makevars.win: SHLIB_OPENMP_CFLAGS is included in PKG_LIBS but not in 
PKG_CFLAGS
Use of these macros is discussed in sect 1.2.1.1 of 'Writing R
Extensions'. The macros for different languages may differ so the
matching macro must be used in PKG_CXXFLAGS (etc) and match that used
in PKG_LIBS (except for F77: see the manual).



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

Re: [R-pkg-devel] Printing examples conditionally on another package in Suggests

[Georgi Boshnakov]

Maybe  Martin Maechler's post in response to a similar question answers your 
question:

https://stat.ethz.ch/pipermail/r-package-devel/2018q2/002780.html   

In summary, wrap the code in:

  if (requireNamespace("MASS", quietly = TRUE)) withAutoprint({

  your code

  })


Georgi Boshnakov

-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Zhian Kamvar
Sent: 10 August 2018 12:26
To: Alexandre Courtiol
Cc: R-list Package Devel
Subject: Re: [R-pkg-devel] Printing examples conditionally on another package 
in Suggests

Thanks, but my use of print here is really a toy example, not necessarily
the end-goal. This strategy would fail if I were to attempt load a data set
from some_package or use any functions from some_package.

A more specific example of what I'm dealing with is here:
http://www.repidemicsconsortium.org/incidence/reference/get_counts.html#examples.
This is what the user would see if they were to use example(get_counts).

On Fri, Aug 10, 2018 at 12:14 PM Alexandre Courtiol <
alexandre.court...@gmail.com> wrote:

> Perhaps then something like:
> Print <- function(x) if (requireNamespace("some.package", quietly = TRUE))
> print(x)
> Print("Hi")
> Print("Hello")
> Print("Goodbye")
>
>
>
> On Fri, 10 Aug 2018 at 12:33, Zhian Kamvar  wrote:
>
>> Mainly, I would like to see the value printed after the print statement
>> like it would appear in a normal R session:
>>
>> print("Hi")
>> #> [1] "Hi"
>> print("Hello")
>> #> [1] "Hello"
>> print("Goodbye")
>> #> [1] "Goodbye"
>>
>>
>> On Fri, Aug 10, 2018 at 11:28 AM Alexandre Courtiol <
>> alexandre.court...@gmail.com> wrote:
>>
>>> Hi Zhian,
>>> Could you please explain what behaviour you would like to obtain?
>>> I really don't understand what your problem is from your description...
>>> Alex
>>>
>>> On Fri, 10 Aug 2018 at 12:18, Zhian Kamvar  wrote:
>>>
>>>> Hello,
>>>>
>>>> I know it's good practice to use
>>>>
>>>> if (require("some_package")) {
>>>>   # some code that needs some_package
>>>> }
>>>>
>>>> In R examples that needs a package listed in Suggests.
>>>>
>>>> The problem with this approach is that if there are any print statements
>>>> within this structure, then they only get printed after the braces and
>>>> not
>>>> after the lines like so:
>>>>
>>>> if (TRUE) {
>>>>   print("Hi")
>>>>   print("Hello")
>>>>   print("Goodbye")
>>>> }
>>>> #> [1] "Hi"
>>>> #> [1] "Hello"
>>>> #> [1] "Goodbye"
>>>>
>>>> The only way I can think of circumventing this is by replacing the if
>>>> statement with a stopifnot statement:
>>>>
>>>> stopifnot(require("some_package"))
>>>> # some code that needs some_package
>>>>
>>>> But, I'm not sure if that's okay to do in a function example. Does
>>>> anyone
>>>> have any ideas or suggestions on how to help with this kind of thing?
>>>>
>>>> Cheers,
>>>> Zhian
>>>>
>>>> [[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
>>>
>>
>
> --
> 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

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

Re: [R-pkg-devel] Package builds, installs, and runs but does not pass devtools::check()

[Georgi Boshnakov]

It seems that the R session used by 'check' doesn't look in the library used by 
your interactive session. This discrepancy may happen since the check tools do 
not load the same Renviron files as interactive sessions. This may result in 
different libraries in interactive and 'check' sessions. See ?Startup, 
especially section Note.
It is difficult to give more specific advice without details of your setup.


Hope this helps,
Georgi Boshnakov 



From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of 
Michael Hannon [jmhannon.ucda...@gmail.com]
Sent: 15 July 2018 02:13
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Package builds, installs, and runs but does not pass 
devtools::check()

Greetings.  I'm working on a small package, and I'm using the devtools
functions to create, build, etc., the package.

As indicated in the subject line, I get no errors when I do:

> build()
> install()

When I run a separate R session and load the package, i.e.,

> library(my_pkg)

the package loads without error, and the two exported functions appear
to work as advertised.

OTOH, if I include devtools::check() in the construction of the
package, I consistently get an error:

* installing *source* package ‘my_pkg’ ...
** R
** preparing package for lazy loading
Error in loadNamespace(from, lib.loc = .library) :
  there is no package called ‘dplyr’
Error : unable to load R code in package 'my_pkg'

Clearly there *is* a package called "dplyr" on my system (see the
session info below, for instance).  And, as I've mentioned, the code
*does* run, and I can watch it successfully reading CSV files.

Here's the relevant part of my DESCRIPTION file:

Depends: R (>= 3.4.4)
Imports: readr,
dplyr,
ggplot2,
purrr,
magrittr

I suspect the problem may be that I'm misunderstanding something about
the `import::from()` function, which I'm using for the first time to
load required functions into my code.  In each of the three files that
use dplyr I have the line:

import::from(dplyr, mutate, filter, rename, select, setdiff, slice, "%>%")

I've tried:

(1) putting that line in just one of the files (the lexically first one)
(2) including different subsets of dplyr functions, as needed, in
the various files

Needless to say, I haven't seen any improvement with any of the above
(or any of the other thrashing I've done).

If you can point me in the right direction, I'd appreciate it.  Thanks.

-- Mike


> session_info()
Session info --
 setting  value
 version  R version 3.4.4 (2018-03-15)
 system   x86_64, linux-gnu
 ui   X11
 language en_US
 collate  en_US.UTF-8
 tz   America/Los_Angeles
 date 2018-07-14

Packages --
 package* version date   source
 assertthat   0.2.0   2017-04-11 CRAN (R 3.3.3)
 base   * 3.4.4   2018-03-16 local
 bindr0.1.1   2018-03-13 CRAN (R 3.4.3)
 bindrcpp 0.2.2   2018-03-29 CRAN (R 3.4.4)
 compiler 3.4.4   2018-03-16 local
 crayon   1.3.4   2017-09-16 CRAN (R 3.4.1)
 datasets   * 3.4.4   2018-03-16 local
 devtools   * 1.13.6  2018-06-27 CRAN (R 3.4.4)
 digest   0.6.15  2018-01-28 CRAN (R 3.4.3)
 dplyr  * 0.7.6   2018-06-29 CRAN (R 3.4.4)
 glue 1.2.0   2017-10-29 CRAN (R 3.4.2)
 graphics   * 3.4.4   2018-03-16 local
 grDevices  * 3.4.4   2018-03-16 local
 magrittr 1.5 2014-11-22 CRAN (R 3.2.2)
 memoise  1.1.0   2017-04-21 CRAN (R 3.3.3)
 methods* 3.4.4   2018-03-16 local
 pillar   1.3.0   2018-07-14 CRAN (R 3.4.4)
 pkgconfig2.0.1   2017-03-21 CRAN (R 3.4.0)
 purrr0.2.5   2018-05-29 CRAN (R 3.4.4)
 R6   2.2.2   2017-06-17 CRAN (R 3.4.0)
 Rcpp 0.12.17 2018-05-18 CRAN (R 3.4.4)
 rlang0.2.1   2018-05-30 CRAN (R 3.4.4)
 stats  * 3.4.4   2018-03-16 local
 tibble   1.4.2   2018-01-22 CRAN (R 3.4.3)
 tidyselect   0.2.4   2018-02-26 CRAN (R 3.4.3)
 utils  * 3.4.4   2018-03-16 local
 withr2.1.2   2018-03-15 CRAN (R 3.4.3)
>

__
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] incomplete results from as.character.srcref() in some cases involving quote()

[Georgi Boshnakov]

Thanks for looking into this and sorry for the noise. I should have realised 
that the outermost quote() in my examples is not part of the parsed expression. 
 

Best,
Georgi

-Original Message-
From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com] 
Sent: 20 June 2018 11:01
To: Georgi Boshnakov; r-devel@r-project.org
Subject: Re: [Rd] incomplete results from as.character.srcref() in some cases 
involving quote()

wholeSrcref attribute is documented in ?parse to be the source reference 
corresponding to the already parsed text. The implementation in the 
parser matches the documentation - the code stops at the last 
byte/character of the expression, that is, on the closing brace - which 
is the "already parsed text". I think this works as documented (also 
source() uses the current implementation of wholeSrcref).

Best
Tomas

On 06/18/2018 04:20 PM, Georgi Boshnakov wrote:
> Hi,
>
> The result of  as,character() on  'srcref' objects doesn't have the closing 
> ')' in some cases involving 'quote':
>
>> e4 <- quote({2+2})
>> class(attr(e4, "wholeSrcref"))
> [1] "srcref"
>> as.character(attr(e4, "wholeSrcref"))
> [1] "e4 <- quote({2+2}"
>
> As a result printing the object also lacks it and gives an incomplete 
> expression:
>
>> attr(e4, "wholeSrcref")
> e4 <- quote({2+2}
>
> It seems that it is the top level quote that suffers from this. Here the 
> inner 'quote' has the matching ')' but the outer one doesn't:
>
>> e5 <- quote({quote({2+2})})
>> class(attr(e5, "wholeSrcref"))
> [1] "srcref"
>> attr(e5, "wholeSrcref")
> e5 <- quote({quote({2+2})}
>> as.character(attr(e5, "wholeSrcref"))
> [1] "e5 <- quote({quote({2+2})}"
>> attributes(e5)
> ...
>
> $wholeSrcref
> e5 <- quote({quote({2+2})}
>
>
> Attribute 'wholeSrcref' seems undocumented but it is of class 'srcref' which 
> is documented (eg ?srcref) and has supporting methods.
>
>
> Georgi Boshnakov
>
>
>
>   [[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

[Rd] incomplete results from as.character.srcref() in some cases involving quote()

[Georgi Boshnakov]

Hi,

The result of  as,character() on  'srcref' objects doesn't have the closing ')' 
in some cases involving 'quote':

> e4 <- quote({2+2})
> class(attr(e4, "wholeSrcref"))
[1] "srcref"
> as.character(attr(e4, "wholeSrcref"))
[1] "e4 <- quote({2+2}"

As a result printing the object also lacks it and gives an incomplete 
expression:

> attr(e4, "wholeSrcref")
e4 <- quote({2+2}

It seems that it is the top level quote that suffers from this. Here the inner 
'quote' has the matching ')' but the outer one doesn't:

> e5 <- quote({quote({2+2})})
> class(attr(e5, "wholeSrcref"))
[1] "srcref"
> attr(e5, "wholeSrcref")
e5 <- quote({quote({2+2})}
> as.character(attr(e5, "wholeSrcref"))
[1] "e5 <- quote({quote({2+2})}"
> attributes(e5)
...

$wholeSrcref
e5 <- quote({quote({2+2})}


Attribute 'wholeSrcref' seems undocumented but it is of class 'srcref' which is 
documented (eg ?srcref) and has supporting methods.


Georgi Boshnakov



[[alternative HTML version deleted]]

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

Re: [Rd] Rd parser throws error for user macros invoked with empty argument

[Georgi Boshnakov]

While on the topic of Rd macro arguments, it seems that  if a multiline 
argument is supplied, the lines after the first are silently ignored:

f <- tempfile()
mac6 <- "\\newcommand{\\mac6}{mac6: #1}"

cat(mac6, "\\mac6{2*3
2+2
sin(pi)
}\n", file = f)
rd <- tools::parse_Rd(f)

> rd
 mac6: 2*3

---

Georgi Boshnakov


-Original Message-
From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com] 
Sent: 25 May 2018 10:05
To: Georgi Boshnakov; r-devel@r-project.org
Subject: Re: [Rd] Rd parser throws error for user macros invoked with empty 
argument

Thanks for the report and the examples - and they do not have to be that 
verbose, it is enough to just define and use a command, e.g.

cat("\\newcommand{\\mac1}{MAC1:#1}\\mac1{}", file=f)
rd <- tools::parse_Rd(f)

Whenever you get an error message like "Value of SET_STRING_ELT() must 
be a 'CHARSXP' not a 'NULL'", there is a bug (at least the error message 
should be relevant/informative).

I am testing a patch that will allow empty arguments to macros (they 
will expand to an empty string, like in LaTeX).

Best
Tomas

On 05/14/2018 11:23 PM, Georgi Boshnakov wrote:
> Bug or feature?
>
> I get the following error from parse_Rd() when a user Rd macro (including 
> system ones) is invoked with empty argument {},
> eg \mymacro{}:
>
> Error in tools::parse_Rd(fn) :
>Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
>
> A full example is further below with the system macro \CRANpkg{}. In this 
> example it doesn't make sense to use empty argument but the error is not 
> specific to this particular macro.
>
> --
> Georgi Boshnakov
>
>
> Create an Rd file containing system macro \CRANpkg{bibtex}, parse_Rd() is ok:
>
> =
> fn <- tempfile()
> writeLines("\\name{dummyfun}
> \\alias{dummyfun}
> \\title{Dummy title}
> \\description{Dummy description}
> \\usage{
> dummyfun(x, ...)
> }
> \\arguments{
>\\item{x}{a value.}
>\\item{\\dots}{further arguments.}
> }
> \\details{
>  \\CRANpkg{bibtex}
> }
> ", fn)
>
>> tools::parse_Rd(fn)
> ...
> \details{
>  \href{{https://CRAN.R-project.org/package=bibtex}{\pkg{bibtex}}}
> }
>
> 
>
> With empty argument - \CRANpkg{} - Rd parser throws error. Of course it is 
> silly in this example but I have used it with other user defined  macros 
> where it may make sense to have empty argument.
>
> 
>> writeLines("\\name{dummyfun}
> \\alias{dummyfun}
> \\title{Dummy title}
> \\description{Dummy description}
> \\usage{
> dummyfun(x, ...)
> }
> \\arguments{
>\\item{x}{a value.}
>\\item{\\dots}{further arguments.}
> }
> \\details{
>  \\CRANpkg{}
> }
> ", fn)
>> tools::parse_Rd(fn)
> Error in tools::parse_Rd(fn) :
>Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
>
>   [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


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

Re: [Rd] Rd parser throws error for user macros invoked with empty argument

[Georgi Boshnakov]

Thanks for looking into this, empty string is the natural solution indeed.

Georgi


-Original Message-
From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com] 
Sent: 25 May 2018 10:05
To: Georgi Boshnakov; r-devel@r-project.org
Subject: Re: [Rd] Rd parser throws error for user macros invoked with empty 
argument

Thanks for the report and the examples - and they do not have to be that 
verbose, it is enough to just define and use a command, e.g.

cat("\\newcommand{\\mac1}{MAC1:#1}\\mac1{}", file=f)
rd <- tools::parse_Rd(f)

Whenever you get an error message like "Value of SET_STRING_ELT() must 
be a 'CHARSXP' not a 'NULL'", there is a bug (at least the error message 
should be relevant/informative).

I am testing a patch that will allow empty arguments to macros (they 
will expand to an empty string, like in LaTeX).

Best
Tomas

On 05/14/2018 11:23 PM, Georgi Boshnakov wrote:
> Bug or feature?
>
> I get the following error from parse_Rd() when a user Rd macro (including 
> system ones) is invoked with empty argument {},
> eg \mymacro{}:
>
> Error in tools::parse_Rd(fn) :
>Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
>
> A full example is further below with the system macro \CRANpkg{}. In this 
> example it doesn't make sense to use empty argument but the error is not 
> specific to this particular macro.
>
> --
> Georgi Boshnakov
>
>
> Create an Rd file containing system macro \CRANpkg{bibtex}, parse_Rd() is ok:
>
> =
> fn <- tempfile()
> writeLines("\\name{dummyfun}
> \\alias{dummyfun}
> \\title{Dummy title}
> \\description{Dummy description}
> \\usage{
> dummyfun(x, ...)
> }
> \\arguments{
>\\item{x}{a value.}
>\\item{\\dots}{further arguments.}
> }
> \\details{
>  \\CRANpkg{bibtex}
> }
> ", fn)
>
>> tools::parse_Rd(fn)
> ...
> \details{
>  \href{{https://CRAN.R-project.org/package=bibtex}{\pkg{bibtex}}}
> }
>
> 
>
> With empty argument - \CRANpkg{} - Rd parser throws error. Of course it is 
> silly in this example but I have used it with other user defined  macros 
> where it may make sense to have empty argument.
>
> 
>> writeLines("\\name{dummyfun}
> \\alias{dummyfun}
> \\title{Dummy title}
> \\description{Dummy description}
> \\usage{
> dummyfun(x, ...)
> }
> \\arguments{
>\\item{x}{a value.}
>\\item{\\dots}{further arguments.}
> }
> \\details{
>  \\CRANpkg{}
> }
> ", fn)
>> tools::parse_Rd(fn)
> Error in tools::parse_Rd(fn) :
>Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
>
>   [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


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

Re: [R-pkg-devel] Creating S3 methods for S4 classes

[Georgi Boshnakov]

Dear Martin,

Thanks for the clarification and sorry for the noise.

Georgi


-Original Message-
From: Martin Maechler [mailto:maech...@stat.math.ethz.ch] 
Sent: 25 May 2018 09:11
To: Georgi Boshnakov
Cc: joris.m...@ugent.be; R Package Development
Subject: Re: [R-pkg-devel] Creating S3 methods for S4 classes

>>>>> Georgi Boshnakov 
>>>>> on Thu, 24 May 2018 16:07:43 + writes:

> Hi Joris, At least some aspects of this topic are of
> interest on this list, given its complexity.

I'm sorry, Georgi, but "of interest" (to some readers) still
does not make this the correct mailing list for the topic,
rather really *does* belong to R-devel instead :

This has been about 

- if an S4 generic for "predict" and similar
  generics should be instantiated in the (base R) 'stats4' package
  (==> change of R, not of a developer's package)

- and about good strategies to define S3 and S4 methods and generics
  (==> general advanced R programming, not directly related get a
   package accepted by CRAN standards)

Followups please on R-devel
((Unfortunately, because of severe spamming of people posting to
  the list, we have delayed archiving the official archives considerably for 
now;
  to still see the current thread on R-devel, you can use one of
  the *other* archives: ==> https://marc.info/?t=15271693562=1=2 ))


Best,
Martin Maechler

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

Re: [R-pkg-devel] Errors in my package

[Georgi Boshnakov]

Well, the computer is very good at doing what we ask it to, not what we intend 
to.

In your case coef.freekt() clearly expects an S4 object (clue: object@) and 
apparently that's what you feed it with.
A simple way to see where the problem actually comes from is

> options(error=recover)
> coef(xy.freekt)


Then explore what is going on.

Georgi Boshnakov 

-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Steven Spiriti
Sent: 24 May 2018 21:11
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Errors in my package

To Whom It May Concern:

I have created a package called "freeknotsplines" in R, and I need to
make a few updates to it.  I resubmitted the package, and received the
following error message:

checking examples ... ERROR
Running examples in ‘freeknotsplines-Ex.R’ failed
The error most likely occurred in:

> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: coef.freekt
> ### Title: Compute Coefficients of B-Splines For Free-Knot Splines
> ### Aliases: coef.freekt
> ### Keywords: nonparametric regression smooth
>
> ### ** Examples
>
> x <- 0:30/30
> truey <- x*sin(10*x)
> set.seed(10556)
> y <- truey + rnorm(31, 0, 0.2)
> xy.freekt <- freelsgen(x, y, degree = 2, numknot = 2, 555)
> coef(xy.freekt)
Error: $ operator not defined for this S4 class
Execution halted

 This error occurs in one of the examples in the documentation.   It is
platform dependent, and does not occur on the machine I am using to create
the package.  freekt is a new class, which is intended to be a S3 class,
not a S4 class.

 Here is the code for coef.freekt:

coef.freekt <- function(object, ...)
{
  xdat <- object@x
  ydat <- object@y
  optknot <- object@optknot
  ord <- object@degree + 1
  lambda <- object@lambda
  fulloptknot <- c(rep(min(xdat), ord), optknot, rep(max(xdat), ord))  #
includes endpoints
  Xmat <- splineDesign(fulloptknot, xdat, ord)
  if ((lambda == 0) | (length(optknot) == 0))
coef <- solve(t(Xmat)%*%Xmat, t(Xmat)%*%ydat)
  else
{
  numknots <- length(optknot)
  Amat <- chgbasismat(fulloptknot, ord)
  Istar <- diag(c(rep(0, times = ord), rep(1, times = numknots)))
  coef <- solve(t(Xmat)%*%Xmat + lambda*t(Amat)%*%Istar%*%Amat,
t(Xmat)%*%ydat)
}
  return(coef)
}

Can someone please help me figure out what I am doing that is causing this
error?

Sincerely,

Steven Spiriti

[[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: [R-pkg-devel] Creating S3 methods for S4 classes

[Georgi Boshnakov]

Hi Joris,

At least some aspects of this topic are of interest on this list, given its 
complexity.

I think that your example:

setGeneric("predict")
setMethod("predict", "ANY", stats::predict)

creates a new function 'predict' in your namespace, it doesn't make 
stats::predict S4 generic. This is fine when your 'predict' is visible
but  when it is not, stats::predict will be called. 

So, for classes for which you define methods for predict, what happens may 
depend on whether or not your package is attached. 
On the other hand, S3 methods defined for predict, will be used (if exported) 
as long as  the package is attached. 

I may be wrong but for this or similar reasons I believe that 'stats4' needs to 
be in "Depends" to ensure that it shadows the base functions it redefines. 

Georgi Boshnakov




> coef
function (object, ...) 
UseMethod("coef")



> library(stats4)
> coef
standardGeneric for "coef" defined from package "stats"

function (object, ...) 
standardGeneric("coef")

Methods may be defined for arguments: object
Use  showMethods("coef")  for currently available ones.

===



-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Georgi Boshnakov
Sent: 24 May 2018 15:38
To: joris.m...@ugent.be; R Package Development
Subject: Re: [R-pkg-devel] Creating S3 methods for S4 classes

My understanding is that the  S3 methods guard against situations where only S3 
dispatch is done,
e.g. by some internal generics. It may well be that for 'predict' this is not 
theoretical possibility.

I second your suggestion about predict and stats4. I have wondered in the past 
why 'predict' has been left out of stats4. 

Georgi Boshnakov




-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Joris Meys
Sent: 24 May 2018 13:17
To: R Package Development
Subject: [R-pkg-devel] Creating S3 methods for S4 classes

Dear all,

per the manual, one should create and register both the S3 and a S4 method
if one needs a method for an S4 class for a function using S3 dispatching.
This is cumbersome, and not very optimal.

I was wondering if there's a better way to do this. Currently I recreate a
generic in my package and create a default method that sends all the other
classes to the S3 generic, eg:

setGeneric("predict")
setMethod("predict", "ANY", stats::predict)

I'm not sure if this hasn't any adverse consequences, as it is not the
recommended approach

It would be great if these generics could be made available through stats4.
If this would be the prefered route, I volunteer to create the patch for
that.

Any thoughts?
Cheers
Joris

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

__
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] Creating S3 methods for S4 classes

[Georgi Boshnakov]

My understanding is that the  S3 methods guard against situations where only S3 
dispatch is done,
e.g. by some internal generics. It may well be that for 'predict' this is not 
theoretical possibility.

I second your suggestion about predict and stats4. I have wondered in the past 
why 'predict' has been left out of stats4. 

Georgi Boshnakov




-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Joris Meys
Sent: 24 May 2018 13:17
To: R Package Development
Subject: [R-pkg-devel] Creating S3 methods for S4 classes

Dear all,

per the manual, one should create and register both the S3 and a S4 method
if one needs a method for an S4 class for a function using S3 dispatching.
This is cumbersome, and not very optimal.

I was wondering if there's a better way to do this. Currently I recreate a
generic in my package and create a default method that sends all the other
classes to the S3 generic, eg:

setGeneric("predict")
setMethod("predict", "ANY", stats::predict)

I'm not sure if this hasn't any adverse consequences, as it is not the
recommended approach

It would be great if these generics could be made available through stats4.
If this would be the prefered route, I volunteer to create the patch for
that.

Any thoughts?
Cheers
Joris

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

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

[Rd] Rd parser throws error for user macros invoked with empty argument

[Georgi Boshnakov]

Bug or feature?

I get the following error from parse_Rd() when a user Rd macro (including 
system ones) is invoked with empty argument {},
eg \mymacro{}:

Error in tools::parse_Rd(fn) :
  Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'

A full example is further below with the system macro \CRANpkg{}. In this 
example it doesn't make sense to use empty argument but the error is not 
specific to this particular macro.

--
Georgi Boshnakov


Create an Rd file containing system macro \CRANpkg{bibtex}, parse_Rd() is ok:

=
fn <- tempfile()
writeLines("\\name{dummyfun}
\\alias{dummyfun}
\\title{Dummy title}
\\description{Dummy description}
\\usage{
dummyfun(x, ...)
}
\\arguments{
  \\item{x}{a value.}
  \\item{\\dots}{further arguments.}
}
\\details{
\\CRANpkg{bibtex}
}
", fn)

> tools::parse_Rd(fn)
...
\details{
\href{{https://CRAN.R-project.org/package=bibtex}{\pkg{bibtex}}}
}



With empty argument - \CRANpkg{} - Rd parser throws error. Of course it is 
silly in this example but I have used it with other user defined  macros where 
it may make sense to have empty argument.


> writeLines("\\name{dummyfun}
\\alias{dummyfun}
\\title{Dummy title}
\\description{Dummy description}
\\usage{
dummyfun(x, ...)
}
\\arguments{
  \\item{x}{a value.}
  \\item{\\dots}{further arguments.}
}
\\details{
\\CRANpkg{}
}
", fn)
> tools::parse_Rd(fn)
Error in tools::parse_Rd(fn) :
  Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'

[[alternative HTML version deleted]]

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