Re: [R-pkg-devel] Cascade effect of non-available packages?

[Georgi Boshnakov]

A lot of packages are erring on CRAN at the moment. From time to time weird 
things happen en masse. It is better to wait a little for intermittent problems 
to clear themselves out, especially during the weekend.

Georgi Boshnakov

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

From: R-package-devel  on behalf of Dirk 
Eddelbuettel 
Sent: Sunday, November 3, 2024 2:17:21 PM
To: Tiago Olivoto 
Cc: R Package Devel 
Subject: Re: [R-pkg-devel] Cascade effect of non-available packages?


On 3 November 2024 at 11:02, Tiago Olivoto wrote:
| Today, I noticed that several stable packages, such as Rcpp and sf, were
| unavailable during the check process for this submission. This wasn�t an
| issue in the previously published version of pliman. Could this be a
| temporary problem with the package availability on CRAN?

I could be. (Auto-)build systems for 21k packages and 3 architectures can be
fragile, and we are in time of transition (R 4.4.2 just came about) so this
could have been spurious.  If in doubt, check the status of a given package
at its CRAN page. But I looked at the log links yu provided, and I saw no
build failure over 'missing Rcpp and/or sf' there.  Can you point us to an
error?

Moreover, reading
  
https://urldefense.com/v3/__https://win-builder.r-project.org/incoming_pretest/pliman_3.0.0_20241102_181842/specialChecks/noSuggests/summary.txt__;!!PDiH4ENfjr2_Jw!Af5Xuvyms6hGqaC8rcf5EXqH8icVsEPEbdr4dvBxDrdeNRZb4hlwLZo9QccOefhWkiYMiOT4lFhp93zWR5eCbGaJ$
 [win-builder[.]r-project[.]org]
I do not see your aforementioned 'check_ebi()' function at work. The
suggested package is not present, you are asked to not fail and just skip
but do not seem to do so. I think you need to fix that, and that the CRAN
messaging is fairly clear and standard here. I may of course have missed
something in which case 'my bad'.

Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!Af5Xuvyms6hGqaC8rcf5EXqH8icVsEPEbdr4dvBxDrdeNRZb4hlwLZo9QccOefhWkiYMiOT4lFhp93zWR1sto-Mt$
 [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] DESCRIPTION file corrections for accepted package

[Georgi Boshnakov]

Also, v1.1 = v1.1.0:

>  package_version("1.1.0") > package_version("1.1")
[1] FALSE
>  package_version("1.1.0") == package_version("1.1")
[1] TRUE

If you adopt the 2-digit versions but decide to keep the possibility for 
3-letter ones for minor fixes (bugs; fixing CRAN NOTES, minor bugs etc.), 
always use the four-digit development versions, e.g. 1.1.0.9000 after release 
of 1.1, to keep the possibility for 1.2 or 1.1.1 for the following release.

Georgi Boshnakov


From: R-package-devel  on behalf of 
Joshua Ulrich 
Sent: 28 October 2024 15:41
To: Duncan Murdoch
Cc: R Package Development
Subject: Re: [R-pkg-devel] DESCRIPTION file corrections for accepted package

`R CMD check` uses the `package_version()` function to check that the submitted 
package version is > the version on CRAN. You can use it to check Duncan's 
hypothesis: R$ # current update with 3-part version R$ package_version("1. 1. 
1") >
ZjQcmQRYFpfptBannerStart
This Message Is From a New External Sender
You have not previously corresponded with this sender. Please exercise caution 
when opening links or attachments included in this message.

ZjQcmQRYFpfptBannerEnd

`R CMD check` uses the `package_version()` function to check that the
submitted package version is > the version on CRAN. You can use it to
check Duncan's hypothesis:

R$ # current update with 3-part version
R$ package_version("1.1.1") > package_version("1.1")
[1] TRUE
R$ # next update with only a 2-part version
R$ package_version("1.2") > package_version("1.1.1")
[1] TRUE


On Sun, Oct 27, 2024 at 8:16 AM Duncan Murdoch  wrote:
>
> I don't think R will enforce a 3 part version just because you used it
> once.  You might have other reasons to try to maintain versioning
> consistency.
>
> Duncan Murdoch
>
> On 2024-10-27 7:48 a.m., Gianmarco Alberti wrote:
> > Dear Duncan,
> >
> > Thank you for the straightforward guidance.
> >
> > My initial query stemmed from a concern about versioning consistency - I
> > thought that once using three digits (1.1.1), I would need to maintain
> > that format (e.g., 1.2.0) in future updates. Your suggestion clarified
> > that I can use 1.1.1 for these formatting changes and still use 1.2 for
> > future substantial updates.
> >
> > Best regards,
> >
> > Gm
> >
> >
> > Il giorno dom 27 ott 2024 alle ore 11:49 Duncan Murdoch
> > mailto:murdoch.dun...@gmail.com>> ha scritto:
> >
> > On 2024-10-27 6:03 a.m., Gianmarco Alberti wrote:
> >  > Dear R Package Developers,
> >  > I am seeking guidance regarding a situation with my package
> > 'chisquare'
> >  > (version 1.1) on CRAN.
> >  >
> >  > Current situation:
> >  >
> >  > 1. The package was submitted and (automatically) accepted to CRAN
> > (version
> >  > 1.1) after thorough local testing and complete devtools checks
> >  > (check_win_oldrelease(), check_win_release(), check_win_devel())
> >  >
> >  > 2. After acceptance, I received a request to make formatting
> > changes to the
> >  > DESCRIPTION file by November 2, 2024:
> >  > -Remove version specifications for graphics and stats in Imports
> >  > -Update R version dependency format from R (>= 4.0.0) to R (>= 4.0)
> >  >
> >  > 3. Upon attempting to submit these formatting changes, I received
> > a warning
> >  > about "Insufficient package version (submitted: 1.1, existing:
> > 1.1)". I am
> >  > well aware that this warning typically indicates the need to
> > increment the
> >  > version number for new submissions of existing packages, as per CRAN
> >  > policies.
> >  >
> >  > This creates a procedural challenge:
> >  > -I need to make the requested DESCRIPTION file changes to retain
> > the package
> >  > -The changes are purely formatting-related, not functional (all
> > checks pass)
> >  > -I cannot submit without changing the version number
> >  > -However, incrementing the version number seems disproportionate for
> >  > formatting changes.
> >  >
> >  > I would greatly appreciate guidance on the proper way to handle this
> >  > situation.
> >  > What is the recommended approach for submitting DESCRIPTION file
> > formatting
> >  > corrections for an already-accepted package, given that
> > i

Re: [R-pkg-devel] R CMD check options

[Georgi Boshnakov]

In most cases, installing a recent version of R-devel will do (here, the check 
with it will show the notes about missing package anchors).

Georgi Boshnakov 


From: R-package-devel  on behalf of 
Kevin R. Coombes 
Sent: 16 August 2024 18:32
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] R CMD check options

Hi, I maintain a bunch of packages on CRAN. When updating packages, I often 
find two sort of NOTES on some of the platforms that CRAN checks that don't 
show up on my stupid Windows (I know that's redundant; you don't have to tell 
me) machine
ZjQcmQRYFpfptBannerStart
This Message Is From a New External Sender
You have not previously corresponded with this sender. Please exercise caution 
when opening links or attachments included in this message.

ZjQcmQRYFpfptBannerEnd

Hi,

I maintain a bunch of packages on CRAN. When updating packages, I often
find two sort of NOTES on some of the platforms that CRAN checks that
don't show up on my stupid Windows (I know that's redundant; you don't
have to tell me) machine at home. The two most common issues are

  * spelling (especially in the DESCRIPTION file), and
  * links in the documentation with missing package anchors.

How do I enable these checks so that when I run "R CMD check --as-cran"
it actually does behave like those CRAN machines do, so I can find and
fix the issues before submitting the package?

Thanks,
   Kevin


[[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!E2Ma-V8bhj8k-YfGsRWAQHNJSG51USXTaeHl8IHyVh3CnziYF9t3isoCoR3Lzs13rfjPktwG-mm5LBdm2sWKZVxnV7PDLaqoBMEpMJI$[stat[.]ethz[.]ch]


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

Re: [R-pkg-devel] A function in one of my package is now a method in base R

[Georgi Boshnakov]

Since the main problem is that in base-R's function your 'object' is called  
'x',  you could consider issuing an intermediate version of the package, where 
you strongly advise users not to name the first argument and to always name the 
remaining arguments. Also, make sure that your examples follow this advice.

If the function is used by package authors, you could send them emails, telling 
them exactly what to change.

After a year or so you could make the method following Duncan's advice.

Since sort_by is in package 'base', packages that use your package will no 
longer need to import sort_by from your package. There are some further 
subtleties here that could be discussed if packages that import explicitly 
sort_by from your package exist.


Georgi Boshnakov



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


From: R-package-devel  on behalf of 
Duncan Murdoch 
Sent: Friday, August 2, 2024 7:43:46 pm
To: Shu Fai Cheung ; r-package-devel@r-project.org 

Subject: Re: [R-pkg-devel]  A function in one of my package is now a method in 
base R

On 2024-08-02 10:35 a.m., Shu Fai Cheung wrote:
> Hi All,
>
> I have a function (not a method), sort_by(), in one of my packages. A
> new method with the same name was introduced in the recent versions of
> R (4.4.0 or 4.4.1, I forgot which one), resulting in potential
> conflict in users' code.
>
> Certainly, users can simply use pkg_name::function_name() to solve the
> conflict. However, I would like to be consistent with base R and so I
> am thinking about converting my function to a method for the class for
> which my function is intended to work on (e.g, est_table).
>
> However, my function has arguments different from those in the base R 
> sort_by():
>
> Base R:
>
> sort_by(x, y, ...)
>
> My function:
>
> sort_by(
>object,
>by = c("op", "lhs", "rhs"),
>op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
>number_rows = TRUE
> )
>
> If I write the function sort_by.est_table(), I would need to match the
> argument names of the base R sort_by(). However, I think it is a bad
> idea to rename the arguments in my function and it will break existing
> code.
>
> Any suggestions on how I should proceed? Is keeping my function as-is
> a better option? Name conflict is not unusual across packages and so
> users need to learn how to solve this problem anyway. Nevertheless, if
> possible, I would like to solve the conflict internally such that
> users do not need to do anything.

I think it's impossible to avoid some inconvenience to your users.

Here's what I'd suggest:

- Create a method for base::sort_by(), as you suggested you could.  Use
the generic's variable names for compatibility, but also add your extra
variable names as additional arguments, e.g.

  sort_by.est_table <- function(x, y, object,
by = c("op", "lhs", "rhs"),
op_priority = c("=~", "~", "~~", ":=", "~1", "|", "~*~"),
number_rows = TRUE, ...) {

   # This test seems unlikely:  how would we have dispatch here if we
specified object explicitly?

   if (!missing(object) {
 if (!missing(x))
   stop("both x and object specified!")
 x <- object
   }

   # This one is more likely to do something:

   if (!missing(by)) {
 if (!missing(y))
   stop("both y and by specified!")
 y <- by
   }

   # Now proceed using x and y

   ...
}

- Create a separate function, e.g. sort_by_old() which is exactly
compatible with your old sort_by().  For users where the above doesn't
just work, they can switch to sort_by_old().

Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!DMhcKnV6t06-gQP_syUMUckB9X-q2dwf-t0gwHnslUVystLyIK742SL2XYMJ-ugEvVxGfGLffUOBLR_lXvVhbltAha5tPmWPr6cdoQ$
 [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] 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]]

_

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

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

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

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-

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

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

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]

I don't know if this helps but I have the following note in  viewRd() (from 
2017!) at 
https://github.com/GeoBosh/Rdpack/blob/81af94d0e690b9f02275e89d474ce184d63fb044/R/bib.R

...
## TODO: (BUG) e is NULL under RStudio
e <- tools::loadPkgRdMacros(system.file(package = "Rdpack"))
## Rdo <- parse_Rd(infile, macros = e)
...

Maybe I have forgotten to delete the note after fixing that since it works  (I 
just checked in Rstudio) but maybe that's the reason I restricted it to just 
macros in Rdpack.

Georgi Boshnakov


-Original Message-
From: Duncan Murdoch  
Sent: 14 May 2020 12:29
To: Gábor Csárdi 
Cc: Georgi Boshnakov ; Viechtbauer, Wolfgang 
(SP) ; Helmut Schütz 
; tiagooliv...@gmail.com; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] MathJax for Rd files

On 14/05/2020 5:46 a.m., Gábor Csárdi wrote:
> On Thu, May 14, 2020 at 10:27 AM Duncan Murdoch 
>  wrote:
>>
>> On 14/05/2020 3:30 a.m., Georgi Boshnakov wrote:
>>> 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.
>>
>> Yes, the error appears to be in the pkgload::load_rd_macros() 
>> function
>> here:
>> https://github.com/r-lib/pkgload/blob/1b1adc39628671f2ea4256f0bebcdb76e1f89f45/R/dev-help.r#L47.
>>
>> It doesn't look at the DESCRIPTION file to see if there's an RdMacros entry.
> 
> Isn't that what tools::loadPkgRdMacros() does there? I believe so.

Yes, you're right.  So it's not clear why the preview isn't working.

Duncan Murdoch
__
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

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

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 par

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 definiti

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: [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: [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: [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 $ω = ∇

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

Re: [R-pkg-devel] Can I put my small data-sets into one .rda file in my CRAN package?

[Georgi Boshnakov]

Further to Joris' email, the help page of data() is very informative. 
If the reason for wishing to combine the datasets together is so that they can 
be made available in a single command,
an option might be to create an R source file which loads all datasets, thus 
giving this option without withdrawing the possibility for  loading the 
individual datasets.

Georgi Boshnakov


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Joris Meys
Sent: 05 December 2018 16:22
To: li...@dewey.myzen.co.uk
Cc: R Package Development
Subject: Re: [R-pkg-devel] Can I put my small data-sets into one .rda file in 
my CRAN package?

Hi Michael,

in the data() function you have to use the name of the rda file, not the
name of the dataset you need.
So say you have the datasets validity and data2 in a file called
alldata.rda, you need to do:

data(alldata)

and that will make both validity and data2 available to the user.

imho it only makes sense to combine data in one .rda file when they're also
related (for example an dataset with species and the similarity matrix for
those species).

Hope this helps
Cheers
Joris

On Wed, Dec 5, 2018 at 4:19 PM Michael Dewey 
wrote:

> At the moment my package (metap) has a number of small data-sets each as
> a separate .rda file. It works fine. I thought it would be neater to put
> them all into one file which I called data.rda (original choice of name
> there).
>
> Now when I do R CMD build metap
> it fails when trying to build the vignette when that executes
> data(validity)
> where validity is contained in data.rda.
>
> I cannot find anything in writing R extensions which explicitly forbids
> this but equally nothing which explicitly permits it. Am I missing
> something? Obviously this is not an important problem and as the title
> says the solution should work on CRAN too.
>
> --
> 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
>


-- 
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&entry=gmail&source=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

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

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

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: [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&r=1&w=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&entry=gmail&source=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&entry=gmail&source=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

Re: [R-pkg-devel] why can't we importFrom 'methods' ?

[Georgi Boshnakov]

The confusion may stem from (the probably inadvertent) feature that the quality 
control tools
do not raise alarm if there are imports from "stats" and "graphics" even if 
they are not in "Imports:'.

Georgi Boshnakov

-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Duncan Murdoch
Sent: 17 May 2018 16:59
To: Brian G. Peterson; R Package Development
Subject: Re: [R-pkg-devel] why can't we importFrom 'methods' ?

On 17/05/2018 11:51 AM, Brian G. Peterson wrote:
> newer versions of R require importFrom for functions from 'stats',
> 'graphics' and many other packages that used to be assumed to be on the
> search path and thus available.
> 
> 'methods' continues to have seemingly different treatment.
> 
> If you try to use importFrom to import a single function (in this case
> 'hasArg') from methods, you receive an ERROR from R CMD check
> 
>  Namespace dependency not required : 'methods'

That message usually means that you didn't list 'methods' in the Imports 
clause in DESCRIPTION.

Duncan Murdoch

> 
> but without the importFrom, you see a number of NOTE's
> 
>  no visible global function definition for 'hasArg'
> 
> I don't want to import all of 'methods', as I only need one function.
> 
> What am I doing wrong?
> 
> Regards,
> 
> Brian
>

__
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] Explicitly Calling a Method of a specific Class in a Function

[Georgi Boshnakov]

>checking dependencies in R code ... NOTE Unexported object imported by  
>‘sp:::plot.SpatialPolygons’ ...

The above message already shows that plot.SpatialPolygons is not exported. 
But are you sure that you really wish to call the method and not simply call 
plot() and let it choose the appropriate method?

You need to import 'sp' or something from it, in order to make the plot method 
for 'SpatialPolygons' available.
You can do this by putting  import(sp) in NAMESPACE or importFrom(sp, 
something), where 'something' is some object exported by 'sp'. 

Georgi Boshnakov




-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Dr. rer. nat. Michael Thrun
Sent: 06 May 2018 10:43
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Explicitly Calling a Method of a specific Class in a 
Function

Dear Developers,
I have currently one note in one of my packages I am unable to solve at my own:
“
checking dependencies in R code ... NOTE
Unexported object imported by a ':::' call: ‘sp:::plot.SpatialPolygons’
  See the note in ?`:::` about the use of this operator.
“
The goal is to explicitly call the plot function of the 'SpatialPolygons-class' 
in the function ‘plotWorldmap'.
In The CRAN checks the examples work. Manual calling 
of the function ‘plotWorldmap' also works in an clean environment yielding the 
expected plot.
Thus, I assume the call
 sp:::plot.SpatialPolygons(world_country_polygons,col =cols,…)
is in principle correct. 

Could someone please help me?
What do I have to do or to change in order to disable this note?

Best Regards
M. Thrun
__
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] vignette via devtools: sometimes found, sometimes not (same package)

[Georgi Boshnakov]

Hi,

The problem is indeed difficult to debug but there are things that can be done 
to narrow it down.

1. Are there 1/3 unlucky computers fixed? (I.e does the problem occur always on 
the same computers) Also, do you really mean computer or user?

2. Are the students working under R studio? If so, does the same problem appear 
if the same procedure is run outside R studio.

3. Further to 2.,  You mention development mode - do (some) students also have 
a copy of your repository? This may be aproblem if they don't update it too.

4. What happens if R is restarted? 

5. It may be worth checking .Rprofle and similar for the concerned computers 
(or users, see 1.)

Hope this is of some help.


 Georgi Boshnakov 



From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of 
Alexandre Courtiol [alexandre.court...@gmail.com]
Sent: 16 April 2018 14:40
To: List r-package-devel
Subject: [R-pkg-devel] vignette via devtools: sometimes found, sometimes not 
(same package)

Dear all,
I am teaching a class and for that I created a R package that mostly
contains vignettes (the slides of the course).
I host the package on GitHub because I want the students to download every
day the latest version of the package.
Building the vignettes takes a couple of hours so I pre-build the vignettes
using devtools::build_vignettes before pushing my updates to GitHub.
The student install the package using
devtools::install_github("courtiol/LM2GLMM").
Then, they do library(LM2GLMM) and browseVignettes(package = "LM2GLMM")...

... and that works on 2/3 of the computers, for the others it says
vignettes not found.

Any idea why and what can I do to make it 100% success?
Of course on my laptop it works, so I cannot investigate.
Also, since they all use different versions of R, devtools or OS... I would
like to know the one thing that must be changed if it comes from that (but
I am not sure it does).

I have added a back up function that works for the 1/3 of unfortunate
students:

get_vignettes <- function() {
  utils::browseURL(paste0(find.package("LM2GLMM"), "/doc/")) ## for
installed
  utils::browseURL(paste0(find.package("LM2GLMM"), "/inst/doc/")) ## for
development
  return(invisible(NULL))
}

This functions opens de vignette folder and that shows that all the
students actually have the html files installed correctly. But it is ugly
because then they have to find the good html file and so forth, so I would
rather have a better solution.

Many thanks,

Alex

--
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] extending as.mcmc.list

[Georgi Boshnakov]

The following is in your NAMESPACE:

export(as.mcmc.list)

Don't export as.mcmc.list, presumably this is the one from 'coda ' it is rarely 
your responsibility.


Georgi Boshnakov

-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Joe Thorley
Sent: 12 April 2018 16:01
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] extending as.mcmc.list

The S3 generic function coda::as.mcmc.list has a check exclusion in 
R-devel/src/library/tools/R/utils.R.

I am trying to extend it to objects of various classes

https://github.com/poissonconsulting/mcmcr/blob/master/R/as.mcmc.list.R 
<https://github.com/poissonconsulting/mcmcr/blob/master/R/as.mcmc.list.R>

However I get the note 

Found the following apparent S3 methods exported but not registered:
  as.mcmc.list
See section ‘Registering S3 methods’ in the ‘Writing R Extensions’
manual.

Although this note is discussed on r-package-devel

https://stat.ethz.ch/pipermail/r-package-devel/2017q2/001531.html 
<https://stat.ethz.ch/pipermail/r-package-devel/2017q2/001531.html>

I am unclear about how I should resolve the issue.

Currently I am considering renaming the function to as.mcmc_list although this 
feels somewhat unsatisfactory.

Any advice is appreciated

Joe

Joe Thorley PhD, RPBio
Computational Biologist
Poisson Consulting Ltd.
4216 Shasheen Road
Nelson, BC
V1L 6X1, Canada
Tel: +1 250 551 2194
Email: j...@poissonconsulting.ca
Web: www.poissonconsulting.ca
Skype: joethorley




[[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] Saving output of check()

[Georgi Boshnakov]

Hi, 

Not really an answer but I only recently discovered  devtools::revdep(), which 
automates checking reverse dependencies. 

Georgi Boshnakov





From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of J C 
Nash [profjcn...@gmail.com]
Sent: 11 April 2018 19:05
To: List r-package-devel
Subject: [R-pkg-devel] Saving output of check()

Hi,

In trying to test that an upgrade to my optimx package does not break other
packages, I wanted to loop over a list of all such packages in alldep, with
nall the length of this list.

cat("Check the dependent packages\n")
for (ii in 1:nall){
  cpkg <- alldep[ii]
  dd <- "/home/john/temp/wrkopt/dlpkg"
  dlname <- download.packages(cpkg, destdir=dd )[[2]]
  cat("Downloaded ", dlname,"\n")
  cpkg.chk <- devtools::check_built(dlname)
  cat("Results package:",cpkg,"\n")
  print(cpkg.chk)
}

Before running this, I did

sink("dpkgcheck.txt", split=TRUE)

and afterwards, I did sink().

But ... none of the check output, nor the result of the final print, show
up in the output file dpkgcheck.txt.

Have I totally misunderstood sink(), or is there a nasty bug?

I've tried running in Rstudio and in the terminal. I'm running Linux Mint
18.3 Sylvia.

Linux john-j6-18 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20 
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
john@john-j6-18 ~ $ R

R version 3.4.4 (2018-03-15) -- "Someone to Lean On"


J C Nash

__
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] Cannot submit package due to misspell note

[Georgi Boshnakov]

Since this message appears also in R CMD check locally, maybe change in 
Duncan's text 'submission' to something like

The Title field should be in title case!  Your title is

blah blah blah

This is not in title case, which would be

Blah, Blah, Blah"

-
Georgi Boshnakov  



From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of 
Duncan Murdoch [murdoch.dun...@gmail.com]
Sent: 07 April 2018 00:06
To: Ben Bolker; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Cannot submit package due to misspell note

On 06/04/2018 3:14 PM, Ben Bolker wrote:
>
>FWIW, the first (many) times I read the warning
>
> "The Title field should be in title case, current version then in title
> case:"
>
>I couldn't parse it at all. Brevity is wonderful, but I might submit a
> patch/wish for this warning to be changed to (something like): "The
> Title field should be in title case; the next line shows the current
> version, while the following line shows the recommended format" (or even
> "The Title field should be in title case! The next line ...")

I don't like the current wording either.  So I'd suggest putting
together something that people here agree is clear, then actually
submitting it as a patch.

What I don't like about your first one is that it is too complicated.
I'd rather have something like your second one, specifically

"The Title field should be in title case!  Your submission has

blah blah blah

This is not in title case, which would be

Blah, Blah, Blah"




>
>
>
> On 18-04-06 03:10 PM, Dudek Andrzej wrote:
>> Thanks a lot !!!
>>
>> I've been blind, I've read this message about twenty times and haven't 
>> noticed that letter v after - sign  is not capitalized so my thoughts went 
>> to spelling issues.  In fact after capitalizing this letter package has 
>> passed pre-tests. (Even without Bervin's solution which I plan to implement 
>> in next version)
>>
>> Thanks Everyone for Help !
>>
>> Andrzej
>>
>> -Original Message-
>> From: Georgi Boshnakov [mailto:georgi.boshna...@manchester.ac.uk]
>> Sent: Friday, April 6, 2018 8:32 AM
>> To: Dudek Andrzej 
>> Cc: r-package-devel@r-project.org
>> Subject: RE: [R-pkg-devel] Cannot submit package due to misspell note
>>
>> In fact, the reason for rejection is just after the 'misspelled' words:
>>
>>> The Title field should be in title case, current version then in title case:
>> '>Searching for Optimal MDS Procedure for Metric and Interval-valued 
>> Symbolic Data'
>>> 'Searching for Optimal MDS Procedure for Metric and Interval-Valued 
>>> Symbolic Data'
>>
>> Just copy the second line, which is the suggested title in 'title case'.
>> (and write in the Note field on the submission page that the misspelled 
>> words are actually names, which you have checked)
>>
>> Georgi Boshnakov
>>
>>
>>
>>
>> -Original Message-
>> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On 
>> Behalf Of Dudek Andrzej
>> Sent: 06 April 2018 07:13
>> Cc: r-package-devel@r-project.org
>> Subject: Re: [R-pkg-devel] Cannot submit package due to misspell note
>>
>> Ok, my fault sorry:
>>
>> This is the original message for current submission from prof. Ligges
>>
>> ---
>>
>> Dear maintainer,
>>
>> package mdsOpt_0.3-1.tar.gz does not pass the incoming checks automatically, 
>> please see the pre-test at:
>> <https://win-builder.r-project.org/incoming_pretest/mdsOpt_0.3-1_20180404_090906/Windows/00check.log>
>> Status: 1 NOTE
>>
>> Current CRAN status: ERROR: 1, OK: 11
>> See: <https://CRAN.R-project.org/web/checks/check_results_mdsOpt.html>
>>
>> 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/mdsOpt_0.3-1_20180404_090906/>
>> The files will be removed after roughly 7 days.
>>
>>
>> Best 

Re: [R-pkg-devel] Cannot submit package due to misspell note

[Georgi Boshnakov]

In fact, the reason for rejection is just after the 'misspelled' words:

>The Title field should be in title case, current version then in title case:
'>Searching for Optimal MDS Procedure for Metric and Interval-valued Symbolic 
Data'
>'Searching for Optimal MDS Procedure for Metric and Interval-Valued Symbolic 
>Data'

Just copy the second line, which is the suggested title in 'title case'.  
(and write in the Note field on the submission page that the misspelled words 
are actually names, which you have checked)

Georgi Boshnakov




-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Dudek Andrzej
Sent: 06 April 2018 07:13
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Cannot submit package due to misspell note

Ok, my fault sorry:

This is the original message for current submission from prof. Ligges  

---

Dear maintainer,

package mdsOpt_0.3-1.tar.gz does not pass the incoming checks automatically, 
please see the pre-test at:
<https://win-builder.r-project.org/incoming_pretest/mdsOpt_0.3-1_20180404_090906/Windows/00check.log>
Status: 1 NOTE

Current CRAN status: ERROR: 1, OK: 11
See: <https://CRAN.R-project.org/web/checks/check_results_mdsOpt.html>

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/mdsOpt_0.3-1_20180404_090906/>
The files will be removed after roughly 7 days.


Best regards,
CRAN teams' auto-check service

---

And following the first link:


* using log directory 'd:/RCompile/CRANincoming/R-devel/mdsOpt.Rcheck'
* using R version 3.5.0 alpha (2018-03-30 r74499)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file 'mdsOpt/DESCRIPTION' ... OK
* this is package 'mdsOpt' version '0.3-1'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Andrzej Dudek '

Possibly mis-spelled words in DESCRIPTION:
  De (13:2)
  Diday (14:47)
  Groenen (12:13, 14:2)
  Leeuw (13:5)
  Mair (12:30, 13:16)
  Walesiak (15:2, 16:2)
  Winsberg (14:18)

The Title field should be in title case, current version then in title case:
'Searching for Optimal MDS Procedure for Metric and Interval-valued Symbolic 
Data'
'Searching for Optimal MDS Procedure for Metric and Interval-Valued Symbolic 
Data'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking serialization versions ... OK
* checking whether package 'mdsOpt' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* loading checks for arch 'i386'
** checking whether the package can be loaded ... OK
** checking whether the package can be loaded with stated dependencies ... OK
** checking whether the package can be unloaded cleanly ... OK
** checking whether the namespace can be loaded with stated dependencies ... OK
** checking whether the namespace can be unloaded cleanly ... OK
** checking loading without being on the library search path ... OK
** checking use of S3 registration ... OK
* loading checks for arch 'x64'
** checking whether the package can be loaded ... OK
** checking whether the package can be loaded with stated dependencies ... OK
** checking whether the package can be unloaded cleanly ... OK
** checking whether the namespace can be loaded with stated dependencies ... OK
** checking whether the namespace can be unloaded cleanly ... OK
** checking loading without being on the library search path ... OK
** checking use of S3 registration ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for 

Re: [R-pkg-devel] Cannot submit package due to misspell note

[Georgi Boshnakov]

My understanding is that CRAN asks for references in the description field when 
they feel that it would not be very clear what the package is about. 
As to the possibly mis-spelled words, jus mention in the submission that you 
think they are ok, surely there is no need to put author names inquires.

--
Dr Georgi Boshnakov   tel: (+44) (0)161 306 3684
School of Mathematics fax: (+44) (0)161 306 3669
Alan Turing Building 1.125
The University of Manchester  email: georgi.boshna...@manchester.ac.uk
Oxford Road
Manchester M13 9PL
UK



From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of 
Dudek Andrzej [andrzej.du...@ue.wroc.pl]
Sent: 05 April 2018 21:27
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Cannot submit package due to misspell note

IMHO citation info is something completely different. I’ve been asked to add 
references in description field by CRAN maintainers


> Package Information:

> Package: mdsOpt

> Version: 0.1-4

> Title: Searching for Optimal MDS Procedure for Metric Data

> Author(s): Marek Walesiak   Andrzej Dudek

>

> Maintainer: Andrzej Dudek 

> Depends: smacof, clusterSim

> Suggests: testthat

> Description: Searching for optimal multidimensional scaling procedure for

>metric data.



Thanks, can you please extend your description text.



Can you provide some references in the form authors (year)  or 
 (no space after 'doi:' and 'arXiv:')?



Best,

Swetlana Herbrandt



So it is not about citation info for the package but references to methods 
implemented ☹.

Thanks anyway for your help.

Andrzej


From: David Hugh-Jones [mailto:davidhughjo...@gmail.com]
Sent: Thursday, April 5, 2018 10:05 PM
To: Dudek Andrzej 
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Cannot submit package due to misspell note

 Why not remove the references and instead put them in the package citation 
info?

On Thu, 5 Apr 2018 at 20:35, Dudek Andrzej 
mailto:andrzej.du...@ue.wroc.pl>> wrote:
Hello,

I've stuck in submitting new version of package(mdsOpt), due to the following 
note,

Possibly mis-spelled words in DESCRIPTION:
  De (13:2)
  Diday (14:48)
  Groenen (12:13, 14:2)
  Leeuw (13:5)
  Mair (12:30, 13:16)
  Walesiak (15:2, 16:2)
  Winsberg (14:19)

which cause the rejection at submission process.

The description file / section looks like this:

Description: Selecting the optimal multidimensional scaling (MDS) procedure for 
metric data via metric MDS (ratio, interval, mspline) and nonmetric MDS 
(ordinal). Selecting the optimal multidimensional scaling (MDS) procedure for 
interval-valued symbolic data via metric MDS (ratio, interval, mspline). 
Selecting the optimal MDS procedure for statistical data referring to the 
evaluation of tourist attractiveness of Lower Silesian counties.
(Borg, I., Groenen, P.J.F., Mair, P. (2013) ,
 De Leeuw, J., Mair, P. (2015) ,
 Groenen, P.J.F., Winsberg, S., Rodriguez, O., Diday, E. (2006) 
,
Walesiak, M. (2016) ,
 Walesiak, M. (2017) ).

I've tried to check  the documentation but found nothing about including 
references in description files (which AFAIK is now required).

Thank in advance for any help!

Andrzej

-
Andrzej Dudek
Professor of Wroclaw University of Economics
Department of Econometrics and Computer Science,
Nowowiejska 3, 58-506 Jelenia Góra, Poland
mail: 
andrzej.du...@ue.wroc.pl<mailto:andrzej.du...@ue.wroc.pl><mailto:andrzej.du...@ue.wroc.pl<mailto:andrzej.du...@ue.wroc.pl>>



[[alternative HTML version deleted]]

__
R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Error from svDialogs unless attached to search path

[Georgi Boshnakov]

Hi,

"svDialogs" depends on svGUI but doesn't import functions it needs. 
This happens with packages which have not been updated for some time and thus 
may not conform to the requirements to import stuff even for dependencies.
 
Try adding "svGUI" to "Depends:" as a temporary measure and contact the author 
of the package. 
The author of scGUI doesn't need to be told what is needed but for your 
information
they just need to import the functions used in svDialogs. I run `R CMD check' 
on svDialogs and it issued numerous warnings about imports. 

Georgi


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Paul Hibbing
Sent: 28 March 2018 01:40
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Error from svDialogs unless attached to search path

Hi,

I need to use dialog boxes in my package by calling functions from the 
svDialogs package, e.g. svDialogs::dlgInput().

However, I get the below error when I try to use some functions without first 
attaching svDialogs to the search path with library() or require().

   > # library(svDialogs)
   > svDialogs::dlgInput("Example")
   Error in svDialogs::dlgInput("Example") : attempt to apply non-function

After un-commenting and running the first line, the above code works fine, no 
error.

The svDialogs package is imported in my NAMESPACE, and I cannot figure out 
where this error is coming from. As best I can tell, my usage mirrors the cgam 
package, which imports svDialogs in NAMESPACE, and then calls dlgMessage in the 
ShapeSelect function.

Any tips on resolving this error are appreciated.

Best,
Paul Hibbing

__
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] Alignment of Function Arguments For PDF Manual and HTML

[Georgi Boshnakov]

Hi,

The answer probably is No.

In principle, the usage section is in verbatim and I think that the R help 
system respects that also in html.
But how the html is rendered depends on the style used by the renderer, which 
may have other ideas and may reflow the text depending on the width of the 
window.

Georgi Boshnakov


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Dario Strbenac
Sent: 01 March 2018 05:00
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Alignment of Function Arguments For PDF Manual and HTML

Good day,

If I have a function definition in the Usage section of an R documentation file 
(file name ending in .Rd) that requires two or more lines to specify, can I 
format it so that the first letter of the first variable on the second and 
subsequent lines is aligned with the opening bracket of the function in the PDF 
manual created by R CMD Rd2pdf and has the same appearance in the HTML page 
shown in RStudio? I notice that if I align the text for a particular output 
format, it doesn't look aligned in the other. The package I am developing is a 
part of Bioconductor, so I can't modify options to Rd2pdf.

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

Re: [R-pkg-devel] R package CRAN check error

[Georgi Boshnakov]

You get a source package suitable for submission by running `R CMD check 
namepackage'  or the equivalent devtools::build() 

Georgi

-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of Ilaria Amerise
Sent: 16 February 2018 11:35
To: r-package-devel
Subject: [R-pkg-devel] R package CRAN check error

Hi everybody,

on submitting a new version of a package I got a rejection because of the 
following Error in the CRAN-check.

Any help would be highly appreciated.

* using R version 3.4.3 (2017-11-30)
* using platform: x86_64-apple-darwin15.6.0 (64-bit)
* using session charset: UTF-8
* using option ‘--as-cran’
* checking for file ‘namepackage/DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘namepackage’ version ‘1.1.2’
* checking CRAN incoming feasibility ... Note_to_CRAN_maintainers
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... ERROR Only *source* packages can be 
checked.
* DONE
Status: 1 ERROR

Best regards,
Ilaria

__
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] discovering if a function in a package is called under RStudio

[Georgi Boshnakov]

Many thanks, I should have looked at rstudioapi, from rstudioapi::isAvailable():

> .Platform$GUI
[1] "RStudio"

Georgi

From: jorism...@gmail.com [mailto:jorism...@gmail.com] On Behalf Of Joris Meys
Sent: 09 February 2018 09:09
To: Georgi Boshnakov
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] discovering if a function in a package is called 
under RStudio

Hi,
you can use rstudioapi::isAvailable() for that. There's other packages with 
similar functionality (eg the assertive package), and you can always check 
whether Sys.getenv("RSTUDIO") == "1".
Cheers
Joris


On Fri, Feb 9, 2018 at 9:09 AM, Georgi Boshnakov 
mailto:georgi.boshna...@manchester.ac.uk>> 
wrote:
Hi,

Is there a canonical way for a function to discover if it has been called in a 
session under RStudio?
I looked the at the options() but none seems to be dedicated to this.

Thanks,
Georgi Boshnakov


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



--
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=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-pkg-devel] discovering if a function in a package is called under RStudio

[Georgi Boshnakov]

Hi,

Is there a canonical way for a function to discover if it has been called in a 
session under RStudio?
I looked the at the options() but none seems to be dedicated to this.

Thanks,
Georgi Boshnakov


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

Re: [R-pkg-devel] Depreciate Function

[Georgi Boshnakov]

If the calls to your deprecated function can be replaced by calls to the new 
function - just do that.
In this way users will not be tempted to use the deprecated function.

If that is difficult, you can put a print statement in your old function 
telling the users whatever you want.
But this may well go unnoticed and is likely focused trouble to your users. And 
real pain if your package is used in other packages.

Georgi Boshnakov






From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of Rami 
Krispin [rami.kris...@gmail.com]
Sent: 07 February 2018 18:49
To: Maxime Turgeon
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Depreciate Function

I follow the example of the R Packages book about depreciating a function
which can be find here:
http://r-pkgs.had.co.nz/release.html

Is there another method to rename a function name? maybe to print message
without triggering warning?

Thanks!

On Wed, Feb 7, 2018 at 1:36 PM, Maxime Turgeon <
maxime.turg...@mail.mcgill.ca> wrote:

> Hi Rami,
>
>
> Is there a reason for still using the deprecated functions in your
> examples? Because that's what's triggering the warnings.
>
>
> Best,
>
> Max
> --
> *From:* R-package-devel  on behalf
> of Rami Krispin 
> *Sent:* February 7, 2018 1:32:37 PM
> *To:* Uwe Ligges
> *Cc:* r-package-devel@r-project.org
> *Subject:* Re: [R-pkg-devel] Depreciate Function
>
> Yes, I am keeping the old version and passing the function parameters into
> the new version.
>
> I forgot in my previous email to add the log:
> https://win-builder.r-project.org/incoming_pretest/180207_
> 135041_TSstudio_011/00check.log
>
> and here is an example of the function that triggers that warning
> https://github.com/RamiKrispin/TSstudio/blob/master/R/ts_seasonal.R
>
> Thanks!
>
> On Wed, Feb 7, 2018 at 10:54 AM, Uwe Ligges  de
> > wrote:
>
> > Not sure where you get the warning. I guess only at places where you
> still
> > use the old variant?
> >
> > Best,
> > Uwe Ligges
> >
> >
> >
> > On 07.02.2018 16:38, Rami Krispin wrote:
> >
> >>   Hello all,
> >>
> >> I am trying to depreciate functions and replace them with a different
> >> function in the new version of the package, using the Depreciate
> function
> >> which triggers warnings during the package submission to CRAN. For
> >> example,
> >> I am replacing the function seasonal_ly with the function ts_seasonal
> >> using
> >> the following method:
> >>
> >> - export both of the functions
> >> - aliases seasonal_ly
> >> - pass the arguments of the new function to the old function and use
> >> the
> >> Depreciate function to trigger a warning about the depreciating of
> the
> >> function and the name of the new function.
> >>
> >> The code is available over here:
> >> https://github.com/RamiKrispin/TSstudio/blob/master/R/ts_seasonal.R
> >>
> >> Any suggestions?
> >>
> >> Thank you in advance!
> >>
> >> Best regards,
> >> Rami Krispin
> >>
> >> [[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
>

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