Re: [R-pkg-devel] UseR! Session: Making R easier to use (was: Navigating the jungle of R packages)

[Spencer Graves]

On 2017-02-11 7:39 AM, J C Nash wrote:

Certainly Google can be useful, but it can also be infuriatingly
time-wasting when one needs to sort out related tools that do slightly
different things. Then good, up-to-date task views are important, and
wrappers such as I and some others are trying to develop can be a way
to ease the chore of applying the tools or changing between related
ones where there isn't enough information on which is best.

Perhaps Jim, Spencer, and I (others welcome!) can come up with some
small examples to show where Google / sos / other search tools and the
task views (Julia?) can be illustrated to provide guidance. After all,
the purpose of the UseR! session is to try to develop improved ways to
access R's packages.



  The sos vignette discusses searching for "Petal.Length" and 
"spline", combining different searches, and writing the result to an 
Excel workbook with sheets for a package summary, the individual help 
pages found, and documentation of the actual search.



  With luck, this session may catalyze the formation of a committee 
with a vision for how to improve what we have and the commitment to do it.



  Spencer


p.s.  Someone complained that R was not a jungle.  I'm therefore 
proposing we consider changing the name of the session to something like 
"Making R easier to use".  John Nash thought the jungle analogy was 
good, because CRAN and a jungle are both resource rich but navigation poor.




Cheers, John Nash

On 2017-02-10 05:26 PM, Jim Lemon wrote:

This discussion started me thinking about searching for a function or
package, as many questions on the R help list indicate the that poster
couldn't find (or hasn't searched for) what they want. I don't think I
have ever used task views. If I haven't got a clue where to look for
something, I use Google. I can't recall an occasion when I didn't get
an answer, even if it was that what I wanted didn't exist. Perhaps we
should ask why Google is so good at answering uninformed questions, in
particular about R. I'm not the only person on the help list who
advises the clueless to try Google.

Jim


On Sat, Feb 11, 2017 at 3:51 AM, Ben Bolker  wrote:

  I definitely read the task views and advise others to do so.  I
don't know how representative my little corner of the world is,
though.

  I have an embryonic task view on mixed models at
https://github.com/bbolker/mixedmodels-misc/blob/master/MixedModels.ctv
but the perfect is the enemy of the good ...



  What do you think about converting the Task Views into a wiki?


  The Wikimedia rules do pretty well in inviting anyone to 
contribute material, quickly and easily deleting obvious vandalism,
managing conflicts, and ensuring that the resulting articles are 
noteworthy and high quality -- and no one person has to be responsible 
for any specific thing.



  Spencer Graves



On Fri, Feb 10, 2017 at 9:56 AM, J C Nash  wrote:

We'd be more than happy to have you contribute directly. The goal
is not
just an
information session, but to get some movement to ways to make the
package
collection(s)
easier to use effectively. Note to selves: "effectively" is
important -- we
could make
things easy by only recommending a few packages.

Best, JN


On 2017-02-10 09:29 AM, Michael Dewey wrote:


Dear all

That seems an interesting session. I am the maintainer of one of
the CRAN
Task Views (MetaAnalysis) and will attend
unless I am successful in the draw for Wimbledon tickets.

Just in case I strike lucky one question I would have raised from the
floor if I were there would have been "Does anyone
read the Task Views?". Since I started mine I have received only a
couple
of suggestions for additions including a very
abrupt one about a package which had been included for months but
whose
author clearly did not read before writing. So I
would ask whether we need to focus much energy on the Task Views.

So, maybe see you there, maybe not.


On 16/01/2017 14:57, ProfJCNash wrote:


Navigating the Jungle of R Packages

The R ecosystem has many packages in various collections,
especially CRAN, Bioconductor, and GitHub. While this
richness of choice speaks to the popularity and
importance of R, the large number of contributed packages
makes it difficult for users to find appropriate tools for
their work.

A session on this subject has been approved for UseR! in
Brussels. The tentative structure is three short
introductory presentations, followed by discussion or
planning work to improve the tools available to help
users find the best R package and function for their needs.

The currently proposed topics are

- wrapper packages that allow diverse tools that perform
  similar functions to be accessed by unified calls

- collaborative mechanisms to create and update Task Views

- search and sort tools to find packages.

At the time of writing we have t

Re: [R-pkg-devel] Referring to data in R/sysdata.rda

[Spencer Graves]

On 2017-04-15 11:24 AM, Hadley Wickham wrote:

Just ignore it.
Hadley

On Friday, April 14, 2017, Roy Mendelssohn - NOAA Federal <
roy.mendelss...@noaa.gov> wrote:


In my package I have a dataframe that I use but want to hide from the
user.  In Hadley's book on R Packages,  he says:


   • If you want to store parsed data, but not make it available to

the user, put it in R/sysdata.rda. This is the best place to put data that
your functions need.
I have done that,  and sure enough when the package is loaded, the
structure is there.  However,  when I am working on debugging code, and I
refer to the  structure in a function,  RStudio gives a warning that the
structure is out of scope, say the data frame is myDF:

myFunc  <-  function(myIndex) {
  junk  <-  myDF[index]
 return(junk)
}


  Have you tried the following:



myFunc  <-  function(myIndex) {
  junk  <-  yrPkg:::myDF[index]
 return(junk)
}



  This will turn of similar messages is slightly different 
contexts.  I don't know if it will work here (and I don't have time to 
try it myself now).  Spencer Graves



RStudio will warn that myDF is out of scope.  My question is if there is a
proper way to refer to myDF so as not to get the warning,  or just ignore
it.  Basically before submission I try to remove all warnings from the
editor,  even style ones,  just to have things cleaner.

Thanks,

-Roy





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

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

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





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

Re: [R-pkg-devel] CRAN and cmake

[Spencer Graves]

On 2017-05-23 10:56 AM, Dirk Eddelbuettel wrote:

On 23 May 2017 at 10:34, Thibault Vatter wrote:
| Hi,
|
| Back in 2015, there was a discussion on this list about CRAN and cmake.
|
| As explained by Gabor at the time, it would be useful to have cmake in a R
| package.
|
| Furthermore, Gregory mentioned that there was something available on GitHub:
|
| https://github.com/stnava/cmaker
|
| Since it seems that the package was CRAN-ready two years ago, I wondered
| what happened?
|
| Would an R package containing cmake be accepted in CRAN?

Yes. Many of them do.

A nice benefit of Gabor's CRAN mirror on GitHub is access to the GitHub.
Here I constrain on user:cran (to get just that mirror, and nothing) and
CMakeLists.txt.  Seems to find 47 repos -- corresponding to 47 packages.

https://github.com/search?q=user%3Acran+CMakeLists.txt&type=Code&utf8=%E2%9C%93



  How did you construct that search string?


  Do you think something like this should be added to some other 
general search capability like the sos or CRANsearcher packages?



  I ask in part, because there will be a session at useR!2017 on 
"NAVIGATING THE R PACKAGE UNIVERSE", and this seems possibly relevant to 
that discussion.  (That session is scheduled for Wed. July 5, from 17:00 
- 18:30.  The organizers of that session expect that a fair portion of 
that time will be devoted to discussion of other possibilities, hoping 
we can build a team who will work to improve the ability of users to 
find what they want.  See 
"https://user2017.brussels/news/2017/navigating-the-r-package-universe";.)



  Spencer Graves


Hth, Dirk



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

Re: [R-pkg-devel] Package submission - Issue with pandoc in R CMD check

[Spencer Graves]

On 2017-05-27 9:25 AM, Uwe Ligges wrote:

For geometa:

If you resubmit without the access to "img.shields.io", we can publish 
now. Otherweise, as we have not yet managed to get a univesally 
working pandoc on the CRAN master, we cannot publish your package yet.



Uwe:


  Might it be appropriate to wrap anything that uses 
"img.shields.io" in "if(!fda::CRAN())" in all the relevant *.Rd files -- 
with appropriate error messages in functions that use "img.shields.io"?



  Thanks, Spencer



Best,
Uwe Ligges





On 27.05.2017 16:20, Emmanuel Blondel wrote:
Thanks Uwe for your clarifications. Can you let me know if i need to 
change something on my side, and/or resubmit the package to CRAN? 
(the warning on Pandoc was the only one) Thanks in advance


Best,
Emmanuel

Le 26/05/2017 à 00:11, Uwe Ligges a écrit :
This is currently under inspection by the CRAN team. Apparently 
img.shields.io have changed the cypher settings and pandoc fails 
with the new settings. We may have to disable *.md processing for 
some time.


Best,
Uwe Ligges



On 25.05.2017 20:59, Emmanuel Blondel wrote:

Dear all,

I've just submitted a new package named geometa, for which i 
received the message below. Indeed i had sent in my submission some 
question mark about the warning i obtain during R CMD check:


In case of R release and R devel, I got the following warning:

Conversion of 'README.md' failed:
pandoc.exe: Could not 
fetchhttps://img.shields.io/badge/Github-0.1--0-blue.svg

TlsExceptionHostPort (HandshakeFailed Error_EOF) "img.shields.io" 443

I've been looking for information about it, and it seems to be 
reported as bug of Pandoc. Same occur if I use an http link 
instead. I didn't find any successful alternative to remove this 
warning, and of course for this package and others i maintain, i 
would like to keep the 2 badges, 1 for CRAN and 1 for Github so 
user can quickly check if there is a pending revision in Github.


R CRAN checks links:
- old release:https://win-builder.r-project.org/GphApwuaD56b
- release:https://win-builder.r-project.org/maQicmvW941l
- devel:https://win-builder.r-project.org/OLSqwXd4W442

I would be very grateful if someone can shed light on this, and 
suggest a solution, so i could re-submit the package to CRAN.


Best regards
Emmanuel


 Message transf�r� 
Sujet : [CRAN-pretest-archived] CRAN submission geometa 0.1-0
Date : Thu, 25 May 2017 20:21:22 +0200
De : uwe.lig...@r-project.org
R�pondre � : c...@r-project.org
Pour : emmanuel.blond...@gmail.com
Copie � : c...@r-project.org



Dear maintainer,
   package geometa_0.1-0.tar.gz does not pass the incoming checks 
automatically, please see the pre-test at:
 


Status: 1 WARNING, 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:


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:
 


The files will be removed after roughly 7 days.
  Best regards,
CRAN teams' auto-check service


[[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] Producing ß in help files.

[Spencer Graves]

On 2018-01-05 20:52, Rolf Turner wrote:


In a help file that I am writing I wish to cite an item by a bloke 
whose surname is Weiß.



  Write it "Weiss".


  See "https://en.wikipedia.org/wiki/%C3%9F";.


  That name is written "Weiss" in Switzerland and Liechtenstein but 
"Weiß" in Germany and Austria.  German is the official language of 
Liechtenstein and the primary of four official languages of Switzerland.



  Standard high German has several characters that are not used in 
English but have standard transliterations using the English latin 
alphabet.  These include "ß" = "ss", "ä" = "ae", "ö" = "oe" and "ü" = "ue".



  Spencer Graves



In LaTeX I would use the macro \ss, but Rd files don't accept that.

Is there any way that I can create the ß symbol in a help file? I've 
done a bit of web-searching and found nothing helpful.


Of course I could just write "Weiss", but that's *so* non-U! :-)

Thanks for any ideas.

cheers,

Rolf Turner



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

Re: [R-pkg-devel] Producing ß in help files.

[Spencer Graves]

On 2018-01-05 21:41, Rolf Turner wrote:

On 06/01/18 16:19, Spencer Graves wrote:



On 2018-01-05 20:52, Rolf Turner wrote:


In a help file that I am writing I wish to cite an item by a bloke 
whose surname is Weiß.



   Write it "Weiss".


   See "https://en.wikipedia.org/wiki/%C3%9F";.


   That name is written "Weiss" in Switzerland and Liechtenstein 
but "Weiß" in Germany and Austria.  German is the official language 
of Liechtenstein and the primary of four official languages of 
Switzerland.



   Standard high German has several characters that are not used 
in English but have standard transliterations using the English latin 
alphabet.  These include "ß" = "ss", "ä" = "ae", "ö" = "oe" and "ü" = 
"ue".




I'm sure that you're correct, but I find it frustrating not to be able 
to produce a symbol (which is readily available elsewhere --- e.g. in 
LaTeX or from the keyboard using the "compose key") under the ".Rd" 
system.  I'd like to be *able to produce it*, even if I shouldn't! :-)


cheers,

Rolf

P. S.  It also seems to me to be polite --- if that's the way the 
bloke writes his name, then  that's the way that I ought to write it 
when referring to him.



  Agreed -- except that people who have not studied German would 
not recognize "ß" as sounding like "ss":  They might want to pronounce 
it "Weib" -- old German for "woman", though transliterated as "wife" -- 
very different from "Weiß" = "White".



  "Solzhenitsyn" is the English and Spanish transliteration of a 
name that appears in German as "Solschenizyn", French as "Soljenitsyne", 
and Russian as "Солженицын", according to Wikipedia 
(https://en.wikipedia.org/wiki/Aleksandr_Solzhenitsyn).



  Hope this helps.
  spencer



R.



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

[R-pkg-devel] autotesting on GitHub with Travis or ...?

[Spencer Graves]

Hello, All:


	  What are the current recommendations for automatic testing of an R 
package on GitHub?



	  Section 19.3 in the current version of "R Packages" describes 
"Checking after every commit with Travis".  It recommends Travis.  It 
says to use Travis, first "Run usethis::use_travis()".[1]



	  However, 'help("use_travis", package="usethis")' says it's 
deprecated, but I don't understand what is recommended as an alternative.



  What do you suggest?


  Thanks,
  Spencer Graves


[1]
https://r-pkgs.org/r-cmd-check.html?q=travis#travis

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

Re: [R-pkg-devel] autotesting on GitHub with Travis or ...?

[Spencer Graves]

Hi, Ben:


  Thanks very much.


  This fixed my problem.


	  For others who may be reading this later, I missed a couple of points 
when first working through 
"https://deanattali.com/blog/migrating-travis-to-github/":



* On first pass, I missed the need to "git add" and "git commit" .github".


* And when using "usethis::use_readme_rmd()", I initially missed the 
need to "knit" the file to produce the README.md.



  Spencer Graves


On 5/13/21 7:04 PM, Ben Bolker wrote:

   GitHub Actions

   ?usethis::use_github_action

   Probably start here if you are moving from Travis: 
https://deanattali.com/blog/migrating-travis-to-github/


On 5/13/21 8:00 PM, Spencer Graves wrote:

Hello, All:


   What are the current recommendations for automatic testing of 
an R package on GitHub?



   Section 19.3 in the current version of "R Packages" describes 
"Checking after every commit with Travis".  It recommends Travis.  It 
says to use Travis, first "Run usethis::use_travis()".[1]



   However, 'help("use_travis", package="usethis")' says it's 
deprecated, but I don't understand what is recommended as an alternative.



   What do you suggest?


   Thanks,
   Spencer Graves


[1]
https://r-pkgs.org/r-cmd-check.html?q=travis#travis

__
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] GitHub Action failed re-building 'sos.Rnw'

[Spencer Graves]

Hello:


	  What do you suggest I do to enable GitHub Action to process "sos.Rnw" 
properly?



	  The development version of my "sos" package passes "R CMD check" on 
my Mac but fails in all four platforms under GitHub Action on



https://github.com/sbgraves237/sos


	  The error messages on macOS and Ubuntu release and devel all seems 
the same:



		* Error: processing vignette 'sos.Rnw' failed with diagnostics: 
Running 'texi2dvi' on 'sos.tex' failed.  Messages: You don't have a 
working TeX binary (tex) installed anywhere in your PATH, and texi2dvi 
cannot proceed without one.



  The error message under Windows seemed crudely similar but different:


		* Error: processing vignette 'sos.Rnw' failed with diagnostics: 
pdflatex is not available



  What do you suggest?
  Thanks,
  Spencer Graves

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

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

[Spencer Graves]

Hi, Duncan et al.:


	  Thanks very much to Duncan for his suggestion.  I did added the line 
Duncan suggested in three slightly different places.  That fixed the 
problems with missing tex and pdflatex, but exposed two new problems:



  On Windows and ubuntu (both release and devel) I now get:


LaTeX Error: File `tikz.sty' not found.


  On macOS, I got a different error:


there is no package called 'ks'


	  I added "ks" to "suggests" in DESCRIPTON but still got "no package 
called 'ks'.  And I studied README in https://github.com/r-lib/actions, 
and I did some other searches without figuring out how to fix 
"`tikz.sty' not found."



  For more details, see:


https://github.com/sbgraves237/sos


  Suggestions?
  Thanks,
  Spencer


On 5/23/21 4:43 AM, Duncan Murdoch wrote:

On 22/05/2021 10:05 p.m., Spencer Graves wrote:

Hello:


  What do you suggest I do to enable GitHub Action to process 
"sos.Rnw"

properly?


  The development version of my "sos" package passes "R CMD check" on
my Mac but fails in all four platforms under GitHub Action on


https://github.com/sbgraves237/sos


  The error messages on macOS and Ubuntu release and devel all seems
the same:


    * Error: processing vignette 'sos.Rnw' failed with 
diagnostics:

Running 'texi2dvi' on 'sos.tex' failed.  Messages: You don't have a
working TeX binary (tex) installed anywhere in your PATH, and texi2dvi
cannot proceed without one.


  The error message under Windows seemed crudely similar but 
different:



    * Error: processing vignette 'sos.Rnw' failed with 
diagnostics:

pdflatex is not available


  What do you suggest?


The virtual machines that run Github actions have lots of tools 
installed, but apparently not LaTeX.  So you need to figure out the 
"step" to install it.  I'm not currently using Rnw with Github actions, 
but by looking at the README for https://github.com/r-lib/actions, I'm 
pretty sure all you need is to add


   - uses: r-lib/actions/setup-tinytex@v1

somewhere after

   - uses: actions/checkout@master


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

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

[Spencer Graves]

Hi, Duncan et al.:


	  Thanks again to Duncan.  Your suggestions worked for the LaTeX 
problem, though it required multiple iterations, adding a total of 7 
different "tinytex::parse_install" clauses to overcome other LaTeX and 
pdfTeX errors.



	  However, macOS still says, "there is no package called 'ks'", even 
though I added 'install.packages("ks")' as you suggested -- to three 
different places, all without solving the problem.  I posted this 
question to 
"https://community.rstudio.com/new-topic?category=Package%20development&tags=github-actions";, 
as suggested in line 2 of "~/.github/workflows/R-CMD-check.yaml".  See:



  Spencer


On 5/23/21 11:03 AM, Duncan Murdoch wrote:

This page

https://bookdown.org/yihui/rmarkdown-cookbook/install-latex-pkgs.html

suggests that executing this in R should fix the tikz issue:

tinytex::parse_install(
   text = "! LaTeX Error: File `tikz.sty' not found."
)

The "ks" message looks like a missing R package rather than a missing 
LaTeX package, so running install.packages("ks") would fix it.


So the only question is how to do these things in a Github action.  I 
don't know if there's a pre-made recipe for this, but this one should do 
it:


   - name: Install tikz.tex and ks
     run: |
   install.packages(c('tinytex', 'ks')) # Maybe tinytex is 
already there?

   tinytex::parse_install(
      text = "! LaTeX Error: File `tikz.sty' not found."
   )
     shell: Rscript {0}

Duncan Murdoch

On 23/05/2021 11:28 a.m., Spencer Graves wrote:

Hi, Duncan et al.:


  Thanks very much to Duncan for his suggestion.  I did added the 
line

Duncan suggested in three slightly different places.  That fixed the
problems with missing tex and pdflatex, but exposed two new problems:


  On Windows and ubuntu (both release and devel) I now get:


LaTeX Error: File `tikz.sty' not found.


  On macOS, I got a different error:


there is no package called 'ks'


  I added "ks" to "suggests" in DESCRIPTON but still got "no package
called 'ks'.  And I studied README in https://github.com/r-lib/actions,
and I did some other searches without figuring out how to fix
"`tikz.sty' not found."


  For more details, see:


https://github.com/sbgraves237/sos


  Suggestions?
  Thanks,
  Spencer


On 5/23/21 4:43 AM, Duncan Murdoch wrote:

On 22/05/2021 10:05 p.m., Spencer Graves wrote:

Hello:


   What do you suggest I do to enable GitHub Action to process
"sos.Rnw"
properly?


   The development version of my "sos" package passes "R CMD 
check" on

my Mac but fails in all four platforms under GitHub Action on


https://github.com/sbgraves237/sos


   The error messages on macOS and Ubuntu release and devel all 
seems

the same:


 * Error: processing vignette 'sos.Rnw' failed with
diagnostics:
Running 'texi2dvi' on 'sos.tex' failed.  Messages: You don't have a
working TeX binary (tex) installed anywhere in your PATH, and texi2dvi
cannot proceed without one.


   The error message under Windows seemed crudely similar but
different:


 * Error: processing vignette 'sos.Rnw' failed with
diagnostics:
pdflatex is not available


   What do you suggest?


The virtual machines that run Github actions have lots of tools
installed, but apparently not LaTeX.  So you need to figure out the
"step" to install it.  I'm not currently using Rnw with Github actions,
but by looking at the README for https://github.com/r-lib/actions, I'm
pretty sure all you need is to add

    - uses: r-lib/actions/setup-tinytex@v1

somewhere after

    - uses: actions/checkout@master




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

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

[Spencer Graves]

Hi, Duncan et al.:


	  I inserted "the lines from the rgl workflow to work around the 
XQuartz issues" that Duncan provided after "env" in TWO places in 
R-CMD-check.yaml with the same result:  GitHub Action worked fine on 
Windows and ubuntu (both release and devel) but failed on macOS 
complaining, "there is no package called 'ks'".



  HOWEVER, I can NOT see how I even ask for ks.  The error message says:


processing the following file failed: 'sos.Rnw'
Error: Error: Vignette re-building failed.
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.


	  I can NOT find it with "grep 'ks' sos.Rnw".  It's NOT in DESCRIPTION 
nor NAMESPACE.



  I do NOT see how I am even asking for it.


	  PROPOSED NEXT STEP:  Do as outlined in 
"https://github.com/ThinkR-open/prepare-for-cran"; and submit to CRAN 
with a note on this problem in cran-comments.md if the package passes 
all other tests.



  Other suggestions?
  Thanks again, Duncan.
  Spencer


On 5/23/21 2:36 PM, Duncan Murdoch wrote:
For ks, if you look here: 
https://github.com/sbgraves237/sos/runs/2650960959?check_suite_focus=true


in the "Install Dependencies" section, you'll see these errors:

trying URL 'https://cloud.r-project.org/src/contrib/ks_1.13.0.tar.gz'
Content type 'application/x-gzip' length 1076044 bytes (1.0 MB)
==
downloaded 1.0 MB

* installing *source* package ‘plot3D’ ...
** package ‘plot3D’ successfully unpacked and MD5 sums checked
** using staged installation
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Error: Error: .onLoad failed in loadNamespace() for 'tcltk', details:
ERROR: lazy loading failed for package ‘plot3D’
   call: fun(libname, pkgname)
* removing ‘/Users/runner/work/_temp/Library/plot3D’
   error: X11 library is missing: install XQuartz from www.xquartz.org
Execution halted
ERROR: dependency ‘plot3D’ is not available for package ‘ks’
* removing ‘/Users/runner/work/_temp/Library/ks’

so the problem is really with plot3D, and indirectly with rgl and tcltk. 
I'm familiar with problems like that!  Here are the lines from the rgl 
workflow to work around the XQuartz issues:


     env:
   R_REMOTES_NO_ERRORS_FROM_WARNINGS: true
   _R_CHECK_FORCE_SUGGESTS_: false
   RSPM: ${{ matrix.config.rspm }}
   GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
   RGL_USE_NULL: true

The last line might be enough for you, but I think the 2nd line

_R_CHECK_FORCE_SUGGESTS_: false

may be more important:  you use ks, it imports plot3D, plot3D imports 
misc3d, but it only suggests rgl and tkrplot:  so that would let ks load 
without XQuartz support.


Duncan Murdoch

On 23/05/2021 3:09 p.m., Spencer Graves wrote:

Hi, Duncan et al.:


  Thanks again to Duncan.  Your suggestions worked for the LaTeX
problem, though it required multiple iterations, adding a total of 7
different "tinytex::parse_install" clauses to overcome other LaTeX and
pdfTeX errors.


  However, macOS still says, "there is no package called 'ks'", even
though I added 'install.packages("ks")' as you suggested -- to three
different places, all without solving the problem.  I posted this
question to
"https://community.rstudio.com/new-topic?category=Package%20development&tags=github-actions";, 


as suggested in line 2 of "~/.github/workflows/R-CMD-check.yaml".  See:


  Spencer


On 5/23/21 11:03 AM, Duncan Murdoch wrote:

This page

https://bookdown.org/yihui/rmarkdown-cookbook/install-latex-pkgs.html

suggests that executing this in R should fix the tikz issue:

tinytex::parse_install(
    text = "! LaTeX Error: File `tikz.sty' not found."
)

The "ks" message looks like a missing R package rather than a missing
LaTeX package, so running install.packages("ks") would fix it.

So the only question is how to do these things in a Github action.  I
don't know if there's a pre-made recipe for this, but this one should do
it:

    - name: Install tikz.tex and ks
      run: |
        install.packages(c('tinytex', 'ks')) # Maybe tinytex is
already there?
    tinytex::parse_install(
   text = "! LaTeX Error: File `tikz.sty' not found."
    )
      shell: Rscript {0}

Duncan Murdoch

On 23/05/2021 11:28 a.m., Spencer Graves wrote:

Hi, Duncan et al.:


   Thanks very much to Duncan for his suggestion.  I did added the
line
Duncan suggested in three slightly different places.  That fixed the
problems with missing tex and pdfla

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

[Spencer Graves]

Hi, Duncan et al.:


	  Thanks again.  I removed fda from "suggests" and added it to 
"imports" in DESCRIPTION.  I also added "importFrom('fda', 'CRAN')" to 
NAMESPACE.  Sadly, the result was the same:  It passed "R CMD check" on 
Windows, ubuntu, and my local Mac but not macOS on GitHub Action.



  How do you suggest I proceed from here?


	  You may recall that I started using "if(fda::CRAN())" as a way to 
keep checks for routine testing that take too much time on CRAN.  I've 
looked at Wickham's "skip_on_cran" but concluded, perhaps incorrectly, 
that it was not self contained and required more work to use than 
"if(fda::CRAN())".  If I'm incorrect in that assessment, I will happily 
accept instructions on how to convert "if(fda::CRAN())" to use 
"skip_on_cran".



  Again, I really appreciate the help.
  Spencer


On 5/23/21 4:44 PM, Duncan Murdoch wrote:
I don't see where the connection is, but it's almost certainly coming in 
through your unconditional use of "fda::CRAN()".  Since "fda" is not a 
hard requirement, this should be conditional on having it installed.


Duncan Murdoch

On 23/05/2021 5:25 p.m., Spencer Graves wrote:

Hi, Duncan et al.:


  I inserted "the lines from the rgl workflow to work around the
XQuartz issues" that Duncan provided after "env" in TWO places in
R-CMD-check.yaml with the same result:  GitHub Action worked fine on
Windows and ubuntu (both release and devel) but failed on macOS
complaining, "there is no package called 'ks'".


  HOWEVER, I can NOT see how I even ask for ks.  The error message 
says:



processing the following file failed: 'sos.Rnw'
Error: Error: Vignette re-building failed.
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.


  I can NOT find it with "grep 'ks' sos.Rnw".  It's NOT in 
DESCRIPTION

nor NAMESPACE.


  I do NOT see how I am even asking for it.


  PROPOSED NEXT STEP:  Do as outlined in
"https://github.com/ThinkR-open/prepare-for-cran"; and submit to CRAN
with a note on this problem in cran-comments.md if the package passes
all other tests.


  Other suggestions?
  Thanks again, Duncan.
  Spencer


On 5/23/21 2:36 PM, Duncan Murdoch wrote:

For ks, if you look here:
https://github.com/sbgraves237/sos/runs/2650960959?check_suite_focus=true 



in the "Install Dependencies" section, you'll see these errors:

trying URL 'https://cloud.r-project.org/src/contrib/ks_1.13.0.tar.gz'
Content type 'application/x-gzip' length 1076044 bytes (1.0 MB)
==
downloaded 1.0 MB

* installing *source* package ‘plot3D’ ...
** package ‘plot3D’ successfully unpacked and MD5 sums checked
** using staged installation
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Error: Error: .onLoad failed in loadNamespace() for 'tcltk', details:
ERROR: lazy loading failed for package ‘plot3D’
    call: fun(libname, pkgname)
* removing ‘/Users/runner/work/_temp/Library/plot3D’
    error: X11 library is missing: install XQuartz from www.xquartz.org
Execution halted
ERROR: dependency ‘plot3D’ is not available for package ‘ks’
* removing ‘/Users/runner/work/_temp/Library/ks’

so the problem is really with plot3D, and indirectly with rgl and tcltk.
I'm familiar with problems like that!  Here are the lines from the rgl
workflow to work around the XQuartz issues:

      env:
    R_REMOTES_NO_ERRORS_FROM_WARNINGS: true
    _R_CHECK_FORCE_SUGGESTS_: false
    RSPM: ${{ matrix.config.rspm }}
    GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
    RGL_USE_NULL: true

The last line might be enough for you, but I think the 2nd line

_R_CHECK_FORCE_SUGGESTS_: false

may be more important:  you use ks, it imports plot3D, plot3D imports
misc3d, but it only suggests rgl and tkrplot:  so that would let ks load
without XQuartz support.

Duncan Murdoch

On 23/05/2021 3:09 p.m., Spencer Graves wrote:

Hi, Duncan et al.:


   Thanks again to Duncan.  Your suggestions worked for the LaTeX
problem, though it required multiple iterations, adding a total of 7
different "tinytex::parse_install" clauses to overcome other LaTeX and
pdfTeX errors.


   However, macOS still says, "there is no package called 'ks'", 
even

though I added 'install.packages("ks")' as you suggested -- to three
different places, all without solving the problem.  I posted this
question to
"https://community.rstudio.com/new-topic?category=Package%20developm

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

[Spencer Graves]

Hi, Duncan:


  Thanks again.


	  I found XQuartz-2.8.1.dmg and added the 5 lines you suggested 
(modified to 2.8.1) to "R-CMD-check.yaml".  However, the "GitHub Action" 
status symbols disappeared, so I deleted them.



	  I copied the "CRAN" function from fda to sos and deleted the 
reference to fda from sos.



	  Now I'm getting, 'could not find function "CRAN"' in "processing 
vignette 'sos.Rnw'", even though CRAN is in the NAMESPACE for sos.



  Suggestions?


  Thanks,
  Spencer


p.s.  To use Sys.getenv("NOT_CRAN"), I'd have to set the environment 
variable "NOT_CRAN" on all the test platforms other than CRAN, and 
that's a level of complexity I'd rather not get into.



On 5/23/21 7:03 PM, Duncan Murdoch wrote:
Okay, I just worked out the chain:  The fda package depends on fds.  fds 
depends on rainbow. rainbow imports ks. ks imports plot3D. plot3D 
imports misc3d.  misc3d imports tcltk.  tcltk on macOS needs XQuartz.


I saw this item online: 
https://github.com/actions/virtual-environments/issues/771 .  It's a 
suggestion to add this to the default macOS VM, but apparently they 
didn't act on it.  You could try adding it to yours:


  if: runner.os == 'macOS'
     run: |
   wget https://dl.bintray.com/xquartz/downloads/XQuartz-2.7.11.dmg
   sudo hdiutil attach XQuartz-2.7.11.dmg
   sudo installer -package /Volumes/XQuartz-2.7.11/XQuartz.pkg 
-target /



(Though the current XQuartz version is 2.8.1, and the URL above doesn't 
work for me, so you'll probably have to spend some time finding one that 
does.)


What should you do?  I can suggest a couple of things other than 
installing XQuartz:


1.  Drop the fda dependency, and work around the lack of fda::CRAN.  It 
seems you're pulling in an awful lot of stuff for that one function. The 
on_cran function in testthat has this definition:


function ()
!identical(Sys.getenv("NOT_CRAN"), "true")

so I'd copy that to your package and then define environment variable 
NOT_CRAN=true on your Github machine (in the "env:" section).  But this 
might be inconvenient working on your own machine, where you'll also 
need to define NOT_CRAN=true.


2.  Leave in the fda dependency, but make the test conditional, i.e. change

  if (fda::CRAN())

to

  if (requireNamespace("fda") && fda::CRAN())


I'd do number 1, or just assume everything is being run on CRAN.

Duncan Murdoch

On 23/05/2021 6:49 p.m., Spencer Graves wrote:

Hi, Duncan et al.:


  Thanks again.  I removed fda from "suggests" and added it to
"imports" in DESCRIPTION.  I also added "importFrom('fda', 'CRAN')" to
NAMESPACE.  Sadly, the result was the same:  It passed "R CMD check" on
Windows, ubuntu, and my local Mac but not macOS on GitHub Action.


  How do you suggest I proceed from here?


  You may recall that I started using "if(fda::CRAN())" as a way to
keep checks for routine testing that take too much time on CRAN.  I've
looked at Wickham's "skip_on_cran" but concluded, perhaps incorrectly,
that it was not self contained and required more work to use than
"if(fda::CRAN())".  If I'm incorrect in that assessment, I will happily
accept instructions on how to convert "if(fda::CRAN())" to use
"skip_on_cran".


  Again, I really appreciate the help.
  Spencer


On 5/23/21 4:44 PM, Duncan Murdoch wrote:

I don't see where the connection is, but it's almost certainly coming in
through your unconditional use of "fda::CRAN()".  Since "fda" is not a
hard requirement, this should be conditional on having it installed.

Duncan Murdoch

On 23/05/2021 5:25 p.m., Spencer Graves wrote:

Hi, Duncan et al.:


   I inserted "the lines from the rgl workflow to work around the
XQuartz issues" that Duncan provided after "env" in TWO places in
R-CMD-check.yaml with the same result:  GitHub Action worked fine on
Windows and ubuntu (both release and devel) but failed on macOS
complaining, "there is no package called 'ks'".


   HOWEVER, I can NOT see how I even ask for ks.  The error message
says:


processing the following file failed: 'sos.Rnw'
Error: Error: Vignette re-building failed.
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.


   I can NOT find it with "grep 'ks' sos.Rnw".  It's NOT in
DESCRIPTION
nor NAMESPACE.


   I do NOT see how I am even asking for it.


   PROPOSED NEXT STEP:  Do as outlined in
"https://

Re: [R-pkg-devel] GitHub Action failed re-building 'sos.Rnw'

[Spencer Graves]

Hi, Duncan:


	  I apologize for bothering you with such an obvious thing as using 
"CRAN() before library(sos)".



	  Now I have another problem:  "zq <- ???spline(2)" now retrieves the 
default 100 pages, not the 2 requested.



	  I think the processing of "???" has changed between 4.0.3 and 4.1.0. 
 I've done "debug(`?`)" in both 4.0.3 and 4.1.0:  The condition 
(!is.call(topicExpr1) || length(topicExpr1) != 2 || topicExpr1[[1]] !=

"?" || !is.call(topicExpr1[[2]]) || length(topicExpr1[[2]]) !=
2 || topicExpr1[[2]][[1]] != "?") evaluates initially to FALSE in 
4.0.3 but TRUE in 4.1.0.



	  You graciously contributed that code several years ago when I changed 
the name of the package from RSiteSearch to sos, and it has worked 
wonderfully ... until now.  If you don't have time to look at this, I 
will try to understand it and fix it myself.  However, I really don't 
understand the code, and you certainly did when you wrote it ;-)



  Thanks,
  Spencer Graves


On 5/24/21 10:35 AM, Duncan Murdoch wrote:

On 24/05/2021 10:17 a.m., Spencer Graves wrote:

Hi, Duncan:


  Thanks again.


  I found XQuartz-2.8.1.dmg and added the 5 lines you suggested
(modified to 2.8.1) to "R-CMD-check.yaml".  However, the "GitHub Action"
status symbols disappeared, so I deleted them.


  I copied the "CRAN" function from fda to sos and deleted the
reference to fda from sos.


  Now I'm getting, 'could not find function "CRAN"' in "processing
vignette 'sos.Rnw'", even though CRAN is in the NAMESPACE for sos.


  Suggestions?


This one is easy.  You use CRAN() before library(sos).




  Thanks,
  Spencer


p.s.  To use Sys.getenv("NOT_CRAN"), I'd have to set the environment
variable "NOT_CRAN" on all the test platforms other than CRAN, and
that's a level of complexity I'd rather not get into.

I wouldn't call it "complex", but it could be tedious.

Duncan Murdoch


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

Re: [R-pkg-devel] \donttest{} and writing outputs to tempdir()

[Spencer Graves]

	  You surely should be able to have some examples that would run in 
less than 5 seconds.



	  I almost never use "donttest".  Instead I use conditional skips, and 
those only on examples that I believe are likely to run too long.  In 
those cases, I believe the standard recommendation is:



testthat::skip_on_cran


https://testthat.r-lib.org/reference/skip.html


HOWEVER:  To use this, users must manually set Sys.getenv("NOT_CRAN") to 
"true" if they want the tests to run in environments that are not CRAN. 
 I don't perceive the documentation on this to be adequate;  I'd rather 
not have to set an environment variable in every new environment that 
I'd like to have run all the tests.  Therefore, some years ago, I added 
a CRAN function to the fda package, which I use as follows:



if(!fda::CRAN()){

# code I don't want to run on CRAN
# but do want to run elsewhere.
# You can use:
# R CMD check --as-cran
# to see if it works OK on CRAN


}


  Spencer


On 6/2/21 12:29 AM, Jeff Newmiller wrote:

Make examples shorter so they can run faster. Wrapping everything in donttest 
means that running examples() does nothing, which is counterproductive.

Techinically, vignettes are not tests or examples... but they do have the 
advantage that they don't have to run quickly. But that doesn't make a vignette 
a substitute for either examples or tests.

As for writing to the wrong place, you should probably just double check.

On June 1, 2021 9:39:43 PM PDT, Danielle Maeser  wrote:

Hello,

I received the following comments from a CRAN maintainer, and I don't
understand why they were an issue. I'd appreciate any insight you can
provide.

Danielle







*All your examples are wrapped in \donttest{} and therefore do not
gettested.Please unwrap the examples if that is feasible and if they
can
beexecuted in < 5 sec for each Rd file or create additionally small
toyexamples to allow automatic testing.*

I don't think I can unwrap the examples in \donttest{} because they
cannot
be executed in <5 seconds for each Rd file, and the automatic testing
of
toy data is satisfied in the vignettes I provide for each function.
Therefore, I am not sure what change to make here.




*Please ensure that your functions do not write by default or in
yourexamples/vignettes/tests in the user's home filespace (including
thepackage directory and getwd()). This is not allowed by CRAN
policies.In
your examples/vignettes/tests you can write to tempdir().*

Additionally, all of my vignettes write the output of each function to
tempdir(). Therefore, I am not sure why this is a problem.




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

Re: [R-pkg-devel] Question about preventing CRAN package archival

[Spencer Graves]

	  The CRAN maintainers almost certainly have tried to contact the 
maintainer.  You can ask if he plans to fix the bug.  If not, if it's 
that easy to fix, you could offer to both the maintainers of both 
matrixcalc and CRAN to take over maintenance.



  Spencer


On 6/2/21 2:41 PM, Roy Mendelssohn - NOAA Federal via R-package-devel wrote:

After looking up matrixcalc on CRAN,  I would recommend contacting the 
maintainer,  who is listed as:


Frederick Novomestky 



The reason I say this is what is blowing up the package in the nightly builds 
is a careless error in one Example:


   > x <- matrix( c( 2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3 ), nrow=4, ncol=4, 
byrow=TRUE )
 Error in matrix(c(2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3), nrow = 4, ncol = 4, 
:
  data length differs from size of matrix: [12 != 4 x 4]



That should be pretty easy for the maintainer to fix and to resubmit.

-Roy



On Jun 2, 2021, at 10:36 AM, Ben Staton  wrote:

My package uses the MIT license, so would that not meet the compatibility
requirements?

I will attempt to reach out to the package author - thanks for your help!

On Wed, Jun 2, 2021 at 10:31 AM Ben Bolker  wrote:


That all sounds exactly right.
   GPL >= 2 allows you to use the material without asking permission as
long as your package is compatibly licensed (e.g. also GPL).
   Under normal circumstances it would be polite to ask permission, but
if the reason for doing this is that the maintainer is unreachable in
the first place ...

  If you want to try a little harder, it seems quite possible that you
can reach the matrixcalc maintainer at the (personal) e-mail address
shown in this page:

https://www.facebook.com/photo/?fbid=10208324530363130&set=ecnf.1000413042

   (Possibly an identity confusion, but I rate that as unlikely based on
other facebook snooping)

   I don't think a short, polite e-mail request would be out of bounds,
they can always ignore it or tell you to go away.

   cheers
Ben Bolker

On 6/2/21 1:15 PM, Ben Staton wrote:

Hello,

Thank you for your detailed list of solutions.

I was initially tempted to go with option 1 (move matrixcalc to suggests
and check for its existence before using functions that rely on it), but

as

mentioned, this is not a long term fix.

I unfortunately can't take on the responsibilities of option 2 (becoming
the package maintainer) -- there is much that this package does that I do
not understand, and do not wish to feign authority!

I plan to take option 3 (copy the needed functions into my package).

There

are only three functions I need from matrixcalc, and all three are fairly
simple (is.square.matrix
,
is.symmetric.matrix
, and
is.positive.definite
) and

there

is only one function in postpack that needs them. I plan to define them
within the postpack function. matrixcalc is licensed under GPL >= 2 and
based on my scan of the license text, this is allowed. Is that correct?

Regarding option 4 (contacting the matrixcalc maintainer), the original
email from CRAN mentioned that they have attempted to contact the package
author with no response.

Thank you!

On Wed, Jun 2, 2021 at 9:52 AM J C Nash  wrote:


I just downloaded the source matrixcalc package to see what it

contained.

The functions
I looked at seem fairly straightforward and the OP could likely develop
equivalent features
in his own code, possibly avoiding a function call. Avoiding the

function

call means NAMESPACE etc. are not involved, so fewer places for getting
into
trouble, assuming the inline code works properly.

JN


On 2021-06-02 12:37 p.m., Duncan Murdoch wrote:

On 02/06/2021 12:13 p.m., Ben Staton wrote:

Hello,

I received an email notice from CRAN indicating that my R package
('postpack') will be archived soon if I do not take any action and I

want

to avoid that outcome. The issue is not caused by my package, but

instead a

package that my package depends on:

"... package 'matrixcalc' is now scheduled for archival on 2021-06-09,
and archiving this will necessitate also archiving its strong reverse
dependencies."

Evidently, xyz has been returning errors on new R builds prompting

CRAN

to

list it as a package to be archived. My package, 'postpack' has
'matrixcalc' listed in the Imports field, which I assume is why I

received

this email.

I want to keep 'postpack' active and don't want it to be archived. I

still

need package 'matrixcalc' for my package, but not for most functions.

Could

I simply move package 'matrixcalc' to the Suggests list and submit the

new

version to CRAN to remove the "Strong Reverse Dependency" issue that
triggered this email to avoid CRAN from archiving my package?


That's part of one solution, but not the best solution.

If you move it to Suggests, you should make sure that your package

checks for it be

Re: [R-pkg-devel] How to communicate WARNINGS fixed from *last* CRAN version of a package

[Spencer Graves]

Have you followed the advice in chapter 20 of Wickham and Bryan, R 
Packages:



https://r-pkgs.org/release.html


	  In particular, does your package include a file "cran-comments.md", 
as described therein?



  I believe that's where the CRAN maintainers look for info like that.


	  Also, those instructions suggest you check reverse dependencies.  The 
last time I tried to follow those instructed, it didn't work.  Instead I 
needed:



https://github.com/r-lib/revdepcheck


devtools::install_github("r-lib/revdepcheck")


library(revdepcheck)


revdep_check()


      Hope this helps.
  Spencer Graves


On 6/22/21 6:53 AM, Alberto Garre wrote:

Thanks. I just "replied-to-all" again. Gmail then sends the email to
cran-submissi...@r-project.org. Is this the correct address?

El mar, 22 jun 2021 a las 12:38, Georgi Boshnakov (<
georgi.boshna...@manchester.ac.uk>) escribió:


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



[[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] Warning in dir.create(vd2 <- "vign_test") : 'vign_test' already exists

[Spencer Graves]

Hello, All:


	  "R CMD check Ecfun_0.2-5.tar.gz" with R 4.1.0 under macOS 11.4 gave 
"Warning in dir.create(vd2 <- "vign_test") : 'vign_test' already 
exists".  It ultimately said, "Status: OK", so maybe I shouldn't worry 
about it.  It's available at:



https://github.com/sbgraves237/Ecfun


	  This passed all 4 GitHub Actions, so maybe I should not worry about 
this.



  Comments?
  Thanks,
  Spencer Graves


sessionInfo()
R version 4.1.0 (2021-05-18)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Big Sur 10.16

Matrix products: default
LAPACK: 
/Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.dylib


locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

loaded via a namespace (and not attached):
[1] compiler_4.1.0 tools_4.1.0

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

Re: [R-pkg-devel] Change package maintainer

[Spencer Graves]

	  I can suggest one example: multcompView:  I created it during or 
before 2006 and passed it during or before 2011 to Luciano Selzer 
.  I do not remember the exact process, and 
procedures could have changed since then.  However, I think I remember 
communicating with the CRAN maintainers after Selzer and I agreed he 
would take it over.  Beyond that, I see that the DESCRIPTION file for 
multicompView0.1-3 lists BOTH of us as Maintainer.  The version before 
that lists me only, and the one after lists him.[1]



	  Second, last September, Brian Ripley sent an email to 50 different 
people saying gdata had problems, the maintainer had not responded, and 
it was scheduled to be archived along with all its strong reverse 
dependencies on 2020-09-25.  I don't know what happened from that except 
that the package is still on CRAN with date Published: 2017-06-06, but 
my Ecfun package no longer uses it.



	  Beyond that, I'm pretty sure that anyone can adopt a package in the 
archives that is no longer on CRAN and resurrect it if you agree to fix 
the problems.  However, you should discuss with the CRAN maintainers.



  Spencer


[1]
https://cran.r-project.org/src/contrib/Archive/multcompView/


On 7/2/21 5:30 AM, Lluís Revilla wrote:

Hi,

I agree that the email handshake is the best approach (and very
reasonable to expect it).
I thought that maybe in cases like this there was a waiting period
and/or multiple attempts to contact the maintainer and someone on the
mailing list might have had some experience with the process.
When I'm ready to take over the package I will ask the CRAN team and
give them more details.

Many thanks to all.

Lluís Revilla

On Fri, 2 Jul 2021 at 08:38, Uwe Ligges  wrote:




On 01.07.2021 23:52, Duncan Murdoch wrote:

On 01/07/2021 3:11 p.m., Dirk Eddelbuettel wrote:


On 1 July 2021 at 20:00, Lluís Revilla wrote:
| I have a question related to changing maintainers.
| What happens when the old/current maintainer does not respond to
| emails or other methods of contact?
| Would the new maintainer need to wait until the package is removed
| from CRAN to submit it again?

Not speaking for CRAN here but my understanding always was that a full
and
complete 'email handshake' with both old and new maintainer was strongly
preferred / the default simply to prevent misunderstandings or
shenanigans.


I'd agree in the normal case where the package is still active on CRAN.

In the case where a package has unaddressed issues with no response to
CRAN from the maintainer, they'd probably be quite happy to have someone
volunteer to take over.


... and if in doubt, ask the CRAN team and give them details.

Best,
Uwe Ligges



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



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

Re: [R-pkg-devel] [External] Re: What is a "retired"package?

[Spencer Graves]

On 9/22/21 2:38 AM, Martin Maechler wrote:

Lenth, Russell V
 on Tue, 21 Sep 2021 18:43:07 + writes:


 > As I suspected, and a good point. But please note that the term "retired" causes 
angst, and it may be good to change that to "superceded" or something else.

well,  some of us will  become "retired" somewhere in the
future rather than "superseded" .. ;-)



yes, but we'll become "superseded" long before we want to admit it ;-)



__
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] doi confusion and Data codoc mismatches

[Spencer Graves]

Hello, All:


	  The latest checks on 
"https://github.com/sbgraves237/Ecdat/runs/4634725654?check_suite_focus=true"; 
identify two problems I don't know how to fix:



FIRST:  Data codoc mismatches from documentation object 'USnewspapers':
  Variables in data frame 'USnewspapers'
Code: AdsProportion Ads_G2012dollars Ads_currentGdollars
  Circ_G2012dollars Circ_currentGdollars GDP_G2012 GDP_nominalG
  Population_M RevenuePerCap_2012 RevenuePerCap_nominal
  Revenue_G2012dollars Revenue_currentGdollars Year
  newspapers_p_GDP
Docs: Ads_G2012dollars Circ_G2012dollars Circ_currentGdollars
  Revenue_G2012dollars Revenue_currentGdollars AdsProportion
  Ads_currentGdollars GDP_G2012 GDP_nominalG Population_M
  RevenuePerCap_2012 RevenuePerCap_nominal Year newspapers_p_GDP


	  I believe that the column names in the data.frame 'USnewspapers' 
match the names in the order given in the *.Rd file and the variable 
list following "Code" here matches that following "Docs" using, e.g., 
sort(scan(what=character())).



SECOND:  Found the following URLs which should use \doi (with the DOI 
name only):

File 'AccountantsAuditorsPct.Rd':
  https://doi.org/10.18128/D010.V8.0
File 'OCC1950.Rd':
  https://doi.org/10.18128/D010.V10.0


	  My concern here is that these two urls are in, e.g., 
\href{https://doi.org/10.18128/D010.V8.0}{text to display to click to 
link to the doi url}.  If it were, e.g., 
\url{https://doi.org/10.18128/D010.V8.0} I would try replacing it with 
\doi{10.18128/D010.V8.0}.  However, if I do that, I don't know what to 
do with the "text to display to click to link to the doi url".



  Thanks,
  Spencer Graves

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

[R-pkg-devel] doi confusion and Data codoc mismatches-confusing check

[Spencer Graves]

Hello, All:


	  The latest checks on 
"https://github.com/sbgraves237/Ecdat/runs/4634725654?check_suite_focus=true"; 
identify two problems I don't know how to fix:



FIRST:  Data codoc mismatches from documentation object 'USnewspapers':
  Variables in data frame 'USnewspapers'
Code: AdsProportion Ads_G2012dollars Ads_currentGdollars
  Circ_G2012dollars Circ_currentGdollars GDP_G2012 GDP_nominalG
  Population_M RevenuePerCap_2012 RevenuePerCap_nominal
  Revenue_G2012dollars Revenue_currentGdollars Year
  newspapers_p_GDP
Docs: Ads_G2012dollars Circ_G2012dollars Circ_currentGdollars
  Revenue_G2012dollars Revenue_currentGdollars AdsProportion
  Ads_currentGdollars GDP_G2012 GDP_nominalG Population_M
  RevenuePerCap_2012 RevenuePerCap_nominal Year newspapers_p_GDP


	  I believe that the column names in the data.frame 'USnewspapers' 
match the names in the order given in the *.Rd file and the variable 
list following "Code" here matches that following "Docs" using, e.g., 
sort(scan(what=character())).



SECOND:  Found the following URLs which should use \doi (with the DOI 
name only):

File 'AccountantsAuditorsPct.Rd':
  https://doi.org/10.18128/D010.V8.0
File 'OCC1950.Rd':
  https://doi.org/10.18128/D010.V10.0


	  My concern here is that these two urls are in, e.g., 
\href{https://doi.org/10.18128/D010.V8.0}{text to display to click to 
link to the doi url}.  If it were, e.g., 
\url{https://doi.org/10.18128/D010.V8.0} I would try replacing it with 
\doi{10.18128/D010.V8.0}.  However, if I do that, I don't know what to 
do with the "text to display to click to link to the doi url".



NOTE:  I tried changing \href{}{} to \doi{}{} in 
'AccountantsAuditorsPct.Rd' and got what I expected:  First, I failed to 
mention before that this complaint does NOT appear in R CMD check on my 
local computer;  see sessionInfo() below.  when I checked how that doi 
reference displayed in Ecdat-manual.pdf, I found that "doi: 
10.18128/D010.V8.0" was displayed, followed by the "text to display to 
click to link to the doi url".



Specifically, I got:


Steven Ruggles, Sarah Flood, Ronald Goeken, Josiah Grover, Erin Meyer, 
Jose Pacas, and Matthew Sobek (2018) doi: 10.18128/D010.V8.0IPUMS USA: 
Version 8.0 [dataset]. Minneapolis, MN: IPUMS.



	  With \href{}{}, "doi: 10.18128/D010.V8.0" does not appear, and I get 
that URL by clicking on "IPUMS USA: Version 8.0 [dataset]. Minneapolis, 
MN: IPUMS."  With this version, clicking on "IPUMS USA: Version 8.0 
[dataset]. Minneapolis, MN: IPUMS." does nothing, whild clicking on 
"doi: 10.18128/D010.V8.0" takes me to that URL.



	  This looks like a change to how *.Rd files are rendered that has 
appeared in the process on GitHub but not in my local computer.  ???



  Thanks,
  Spencer Graves


> sessionInfo()
R version 4.1.2 (2021-11-01)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Big Sur 11.6.2

Matrix products: default
LAPACK: 
/Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.dylib


locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

loaded via a namespace (and not attached):
[1] compiler_4.1.2 tools_4.1.2

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

Re: [R-pkg-devel] doi confusion and Data codoc mismatches--AND THE VALUE OF GITHUB

[Spencer Graves]

	  Thanks to Duncan and Kurt for looking into this, recommending a patch 
for my code, and implementing a change to codocData.



VALUE OF GITHUB:  This exchange illustrates the value of GitHub:


	  1.  It made it easier for Duncan to diagnose the problem and 
recommend fixes both to me and to Kurt.



	  2.  I missed this email when it arrived five days after my post but 
found it after noticing a pull request from Duncan on GitHub.  I 
implemented it, and it worked!  Then I checked for a reply to my earlier 
post, and found Duncan's comment below.



  Spencer


On 1/1/22 1:11 PM, Duncan Murdoch wrote:

On 26/12/2021 8:03 a.m., Duncan Murdoch wrote:

I've now submitted a bug report for R:
https://bugs.r-project.org/show_bug.cgi?id=18266 along with a suggested
patch to remove the first of these.


And this patch was committed to the trunk by Kurt Hornik, so it should 
appear in R 4.2.0 or maybe some 4.1.x release.  Thanks Kurt!


Duncan Murdoch



Duncan Murdoch


On 26/12/2021 5:55 a.m., Duncan Murdoch wrote:

On 26/12/2021 12:07 a.m., Spencer Graves wrote:

Hello, All:


  The latest checks on
"https://github.com/sbgraves237/Ecdat/runs/4634725654?check_suite_focus=true"; 


identify two problems I don't know how to fix:


FIRST:  Data codoc mismatches from documentation object 'USnewspapers':
  Variables in data frame 'USnewspapers'
    Code: AdsProportion Ads_G2012dollars Ads_currentGdollars
  Circ_G2012dollars Circ_currentGdollars GDP_G2012 
GDP_nominalG

  Population_M RevenuePerCap_2012 RevenuePerCap_nominal
  Revenue_G2012dollars Revenue_currentGdollars Year
  newspapers_p_GDP
    Docs: Ads_G2012dollars Circ_G2012dollars Circ_currentGdollars
  Revenue_G2012dollars Revenue_currentGdollars 
AdsProportion

  Ads_currentGdollars GDP_G2012 GDP_nominalG Population_M
  RevenuePerCap_2012 RevenuePerCap_nominal Year 
newspapers_p_GDP



  I believe that the column names in the data.frame 'USnewspapers'
match the names in the order given in the *.Rd file and the variable
list following "Code" here matches that following "Docs" using, e.g.,
sort(scan(what=character())).


You can debug this by running tools::codocData("Ecdat") after the
package is installed.  It appears that some of the names in the docs are
picking up newlines, specifically the ones documented like this:

\item{Ads_currentGdollars,
 Ads_G2012dollars,
 Circ_currentGdollars,
 Circ_G2012dollars,
 Revenue_currentGdollars,
 Revenue_G2012dollars}

I think that's a bug in codocData.  A workaround is to put those all on
one line.  You don't get a "line too long" warning, because they'll be
reformatted in the display.




SECOND:  Found the following URLs which should use \doi (with the DOI
name only):
    File 'AccountantsAuditorsPct.Rd':
  https://doi.org/10.18128/D010.V8.0
    File 'OCC1950.Rd':
  https://doi.org/10.18128/D010.V10.0


  My concern here is that these two urls are in, e.g.,
\href{https://doi.org/10.18128/D010.V8.0}{text to display to click to
link to the doi url}.  If it were, e.g.,
\url{https://doi.org/10.18128/D010.V8.0} I would try replacing it with
\doi{10.18128/D010.V8.0}.  However, if I do that, I don't know what to
do with the "text to display to click to link to the doi url".


The first of those links to a page with this version of the reference:

Steven Ruggles, Sarah Flood, Ronald Goeken, Josiah Grover, Erin Meyer,
Jose Pacas, and Matthew Sobek. Integrated Public Use Microdata Series:
Version 8.0 [dataset]. Minneapolis: University of Minnesota, 2018.
http://doi.org/10.18128/D010.V8.0


You'd get a format pretty close to that if you don't try to make the
title into a link, just enter it as

 Steven Ruggles, Sarah Flood, Ronald Goeken,
   Josiah Grover, Erin Meyer, Jose Pacas, and
   Matthew Sobek (2018)
IPUMS
   USA: Version 8.0 [dataset]. Minneapolis, MN:
   IPUMS. \doi{10.18128/D010.V8.0}

Duncan Murdoch






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

Re: [R-pkg-devel] GitHub error

[Spencer Graves]

Hi, Andrew:  Thanks.  I think that was exactly what I needed:  I was in 
particular unsure about "git push --force".  Spencer Graves



On 4/20/22 8:22 PM, Andrew Simmons wrote:

Not really the place for this type of thing, but here's what I'd do:

add .DS_Store to your .gitignore file, this should ignore both
.DS_Store and inst/.DS_Store
delete both .DS_Store files from your repository
then try to pull again. You can use --force in git push, that should
force them to combine, ignoring the overwrite warning

On Wed, Apr 20, 2022 at 9:17 PM Spencer Graves
 wrote:


Hello, All:


   When I do "git pull", I get "error: Your local changes to the
following files would be overwritten by merge: .DS_Store .gitignore
inst/.DS_Store".


   I've done "git rm --cached .DS_Store", etc., which some web page told
me would remove ".DS_Store" from GitHub but not from my local copy.
Then when I try, "git push", I get "! [rejected] // master -> master
(non-fast-forward) // error: failed to push some refs to
'github.com:JamesRamsay5/fda.git'".


   What do you suggest?  Manually delete those files from the GitHub
repository?


   Thanks,
   Spencer Graves


p.s.  This is with "https://github.com/JamesRamsay5/fda";.

__
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 cross-references ... NOTE, Undeclared packages ... in Rd xrefs

[Spencer Graves]

On 6/13/22 2:22 PM, Ivan Krylov wrote:

On Mon, 13 Jun 2022 13:59:24 -0500
Spencer Graves  wrote:


I probably should have just used "Suggests" and not
bothered this list with this issue.


Why not use the \link{foo} form and let the HTML help system resolve
the link at run time? Is it considered bad form to use unqualified
links to help pages in other packages?




	  The problem is that \link{foo} cannot distinguish between 
\link[a]{foo} and \link[b]{foo}.  Using "Suggests" sounds to me more 
like how how the R Core and CRAN teams probably think the system should 
work.



  But Duncan or someone else may think differently.


  Thanks, Spencer

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

[R-pkg-devel] NOTE: Escaped LaTeX specials: \$

[Spencer Graves]

Hello, All:


	  CRAN checks of "Ecdat" on several platforms includes multiple "NOTEs" 
complaining "Escaped LaTeX specials" highlighting use of "\$", "\_", and 
"\&".[1]



  What do you suggest I do with these?


	  I could replace "\$1,000" with "1,000 US dollars", and "R\&D" could 
be replaced with "R and D".



	  However, a dataset "Benefits" includes a column that is "a factor 
with levels (slack\_work,position\_abolished,seasonal\_job\_ended,other)".



  ???
  Thanks,
  Spencer Graves


[1] e.g.:


https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/Ecdat-00check.html

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

Re: [R-pkg-devel] Rd cross-references ... NOTE, Undeclared packages ... in Rd xrefs

[Spencer Graves]

On 6/13/22 5:05 PM, Duncan Murdoch wrote:

On 13/06/2022 5:11 p.m., Spencer Graves wrote:



On 6/13/22 1:26 PM, Duncan Murdoch wrote:

On 13/06/2022 12:12 p.m., Spencer Graves wrote:

Hello, All:


   How do I fix "Rd cross-references ... NOTE
Undeclared packages ‘EnvStats’, ‘drc’, ‘zoo’, ‘prodlim’, ‘plyr’,
‘TRAMPR’, ‘raster’ in Rd xrefs"?


   This occurs with
"https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/Ecfun-00check.html"; 



and with
"https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/Ecdat-00check.html";. 



    However, this error is not raised on other platforms.  My search 
for

this note produced essentially the same message for other packages but
no advice on how to fix it.


   These are references to other packages that I do not use in my
packages but that some users may wish to consider.  If needed, I will
add them to "Suggests" for the packages.  However, that seems overkill,
because I do not use them myself.  ???


Section 2.5 of Writing R Extensions says "Packages referred to by these
‘other forms’ should be declared in the DESCRIPTION file, in the
‘Depends’, ‘Imports’, ‘Suggests’ or ‘Enhances’ fields."  Of those
fields, Suggests looks like the best fit.  You'd use Enhances if your
package provides "methods for classes from these packages, or ways to
handle objects from these packages".



  GitHub Actions failed after I added those packages to Suggests:


https://github.com/sbgraves237/Ecfun/runs/6869516417?check_suite_focus=true 



That log doesn't really give much info about what went wrong.  Maybe 
some of the packages in the Suggests list weren't available?



	  Is there a way in GitHub Action to NOT fail when a package is not 
available -- or at least to give a more useful diagnostic?



	  There probably is, but I don't know how to find the right manual to 
read nor any better place to ask for help with that than here.



  Thanks, sg



Duncan Murdoch


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

Re: [R-pkg-devel] Warning... unable to translate 'Ekstrm' to a wide string; Error... input string 1 is invalid

[Spencer Graves]

Hi, Ivan et al.:


On 7/19/22 1:03 PM, Ivan Krylov wrote:

On Tue, 19 Jul 2022 12:32:20 -0500
Spencer Graves  wrote:


Can someone provide me with a link to the correct development
version of help('iconv')?  The current version includes the exact
offending "\x" strings that I have.


http://svn.r-project.org/R/trunk/src/library/base/man/iconv.Rd

It still does, because it works with byte strings the right way: by
passing them to iconv(), which is designed to work with bytes in
"unknown" encodings.

In contrast, your use of arbitrary bytes with gsub() is invalid,
because gsub() assumes that the strings match their declared encoding:
UTF-8, Latin-1, or the native locale encoding. (See ?Encoding.)

When you write "Ekstr\xf8m", you get a string that consists of Latin-1
bytes but has the wrong encoding property set. Given this string,
gsub() and friends will break on a UTF-8 system (because "r\xf8m" is
not a valid UTF-8 sequence of bytes), while iconv() will not.

Depending on the desired semantics of subNonStandardCharacters(), you
might be able to avoid the failures with the useBytes argument, or you
might silently return invalid data in some corner cases. Is the "x"
argument supposed to be bytes in arbitrary encoding, or properly decoded
characters that might include those that don't map to ASCII?



  Wow.  So what's the recommended fix?


	  If I understand correctly, "\u**" should work with ** being f8, f6, 
df, or fc [all hex digits, I assume?].  However, "\u00**" may be 
preferred over "\u**", and "\u{**}" may be better still.



	  The blog that Tomas wrote might be more useful if it included a 
recommendation like this.



	  Thanks for all your work to make R better and thereby help people 
everywhere extract better information from the data available to them.



  Spencer

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

[R-pkg-devel] Thanks -- success after 4 package submissions in 3 days

[Spencer Graves]

Hello, All:


	  Thanks to Uwe Ligges, Max Turgeon, Duncan Murdoch, Ivan Krylov, Jeff 
Newmiller, Ben Bolker, Bill Dunlap, and Tomas Kalibera, Ecfun 0.3-0 is 
now available on CRAN, after three earlier versions were rejected in 
three days due to my limited ability to understand the error messages I 
saw.



	  My excuse for being so dense is that all the problems I encountered 
were changes required to meet new, more stringent standards implemented 
to reduce ambiguity and tighten coding standards to convert more subtle, 
intermittent problems that are difficult to trace into coding errors 
that are more easily fixed.



  Spencer Graves


On 7/20/22 11:50 AM, Uwe Ligges wrote:
Or simply read ?news which explains how the three formats (plain text 
NEWS, NEWS.Rd and NEWS.md) should look like.


Best,
Uwe Ligges

On 20.07.2022 03:27, Max Turgeon wrote:

Hi Spencer,

This NOTE was discussed a couple weeks ago on this list, it's (as you 
may expect) a new check in R-devel. Here's what Ivan had to say: 
https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008239.html


Others also chimed in, you can see the first message of the thread 
here: https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008235.html


Good luck!


Max Turgeon<https://www.name-coach.com/maxime-turgeon>
Assistant Professor

Department of Statistics
University of Manitoba

maxturgeon.ca<http://maxturgeon.ca/>


From: R-package-devel  on 
behalf of Spencer Graves 

Sent: Tuesday, July 19, 2022 8:05 PM
To: List r-package-devel 
Subject: [R-pkg-devel] NOTE, Problems with news in 'NEWS.md':, No news 
entries found.



Caution: This message was sent from outside the University of Manitoba.


Hello, All:


   Winbuilder with R-Devel complains, " NOTE
Problems with news in 'NEWS.md': No news entries found." See below.


   What should I do with this?  Document it in 
"cran-comments.md" and

not worry about it otherwise?  Thanks,


   Spencer Graves


 Forwarded Message 
Subject: winbuilder: Package Ecfun_0.2-7.tar.gz has been checked and 
built

Date: Wed, 20 Jul 2022 00:22:40 +0200
From: lig...@statistik.tu-dortmund.de
To: spencer.gra...@effectivedefense.org
CC: lig...@statistik.tu-dortmund.de

Dear package maintainer,
   this notification has been generated automatically.
Your package Ecfun_0.2-7.tar.gz has been built (if working) and checked
for Windows.
Please check the log files and (if working) the binary package at:
https://win-builder.r-project.org/e3NjJDDwiq0Z
The files will be removed after roughly 72 hours.
Installation time in seconds: 16
Check time in seconds: 141
Status: 1 NOTE
R Under development (unstable) (2022-07-18 r82603 ucrt)
   All the best,
Uwe Ligges
(CRAN maintainer of binary packages for Windows)

__
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] Misspelled words in descrition and tar.gz inside folder

[Spencer Graves]

Hello, Edward Wei:


	  Are you familiar with R Packages (2nd edition) Hadley Wickham and 
Jenny Bryan?



https://r-pkgs.org


	  This book is the most up-to-date information I know on preparing 
something for CRAN.  To your question specifically, I have a "WORDLIST" 
file in an "inst" folder.



	  Below please find notes I've prepared for myself on the various tests 
I've gotten from their book, etc.  The section numbers refer to an 
earlier version of this book.  Ignore or use with caution.



      Hope this helps.
  Spencer Graves


# File > "Open Project..." > [parent of Package file]

# https://r-pkgs.org/release.html

#20.1.  Pick a version number:
#   in DESCRIPTION: must be later than any version on CRAN
#20.3.  The submission process
#   Store submission comments in cran-comments.md
#20.3.1.  Test environments
# devtools::check_win_*()
dir()

PkgName <- "Ecdat"
PkgRegExpr <- paste0('^', PkgName, '$')
(Pkg <- dir(pattern=PkgRegExpr))

devtools::check_win_devel(Pkg)
devtools::check_win_release(Pkg)
devtools::check_win_oldrelease(Pkg)

# devtools::check_rhub(Pkg)
#Error in match_platform(platform) :
#   Unknown R-hub platform, see rhub::platforms() for a list
# on 2022-07-04.

# https://r-pkgs.org/release.html
# now recommends:

rhub::check(Pkg)

# Select
# 3.  Apple Silicon (M1), macOS 11.6 Big Sur, R-release 
(macos-m1-bigsur-release)

# This may not be correct:  I have mac)S 11.6.7 running an Intel core i7.


#20.3.3.  Reverse dependencies

# install.packages("revdepcheck")
#devtools::install_github('r-lib/revdepcheck')

# revdepcheck::revdep_reset(Pkg)

# revdepcheck::revdep_check(Pkg, num_workers = 4)

#20.4.  Update README.md and NEWS.md

#20.5.  Submit to CRAN

library(devtools)
# spell_check(Pkg)

release(Pkg)

#20.6.  Update the version number for the future
#20.7.  Publicise

#20.1.  Pick a version number:  in DESCRIPTION > what's on CRAN

#20.2.  Run & document R CMD check
# 2.1-0 because this is to match the move of
# the database maintenance to wu.ut.at

#20.3.  Check CRAN policies
#20.4.  Update README.md and NEWS.md
#20.5.  Submit to CRAN
#20.6.  Update the version number for the future
#20.7.  Publicise


On 8/9/22 3:38 PM, Edward Wei wrote:

Hello. Here is my "NOTE" message.

* checking CRAN incoming feasibility ... NOTE
Maintainer: ‘Edward Wei ’

New submission

Possibly misspelled words in DESCRIPTION:
   alphavantager (8:3, 9:7)
   Alphavantager (7:32)
   api (7:58, 8:36)
   Avfintools (10:18)
   Vantager (3:55, 10:46, 11:56)

* checking top-level files ... NOTE
Non-standard file/directory found at top level:
   ‘avfintools.tar.gz’

My questions are:

1. My misspelled words are just referencing names of packages and
programming terms etc. Is there a way to get around this or should I omit
them from my description and put them somewhere else.

2. I wanted to confirm this, but the tar.gz for CRAN submission SHOULD NOT
be in the folder of the directory for my package.

Thanks for your time,

[[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] Problems with news in ‘NEWS’

[Spencer Graves]

Hello, All:


  devtools::check_rhub("Ecdat") complained:


Problems with news in ‘NEWS’:
   Cannot process chunk/lines:
 2022-10-12:
   Cannot process chunk/lines:
 Ecdat 0.4-2 updated "terrorism" to 2020.
...


  For more see below.  This is with the current version of


https://github.com/sbgraves237/Ecdat


  I copied NEWS to NEWS.md and tried to format it as described in:


https://r-pkgs.org/other-markdown.html#news


	  Sadly, I still get the same error.  It seems to be ignoring my 
NEWS.md file and continuing to tell me I haven't fixed NEWS.



  What do you suggest?
      Thanks,
  Spencer Graves


 Forwarded Message 
Subject:Ecdat 0.4-2: NOTE
Date:   Thu, 13 Oct 2022 00:55:10 +
From:   R-hub builder 
To: spencer.gra...@effectivedefense.org



Ecdat 0.4-2: NOTE

Ecdat 0.4-2: NOTE
*Build ID:* |Ecdat_0.4-2.tar.gz-aec6a2cb4b8a43cfbab0405f54e67c64|
*Platform:* Windows Server 2022, R-devel, 64 bit
*Submitted:*5 minutes 25 seconds ago
*Build time:*   5 minutes 16.2 seconds


  NOTES:

* checking package subdirectories ... NOTE
Problems with news in 'NEWS':
   Cannot process chunk/lines:
 2022-10-12:
   Cannot process chunk/lines:
 Ecdat 0.4-2 updated "terrorism" to 2020.
   Cannot process chunk/lines:
 2022-07-01:
   Cannot process chunk/lines:
 Ecdat 0.4-1 replaced non-breaking spaces that used Latin-1 
encoding with " " in 4 "demoFiles/NIPA6.16*.csv" files, because the said 
non-breaking spaces were not valid in UTF-8 and were rejected by a 
development version of R.

 2022-06-14:
   Cannot process chunk/lines:
 Ecdat 0.4-0 adds new datasets USnewspapers and USPS (US Postal 
Service) while adding federal government budget data to USGDPpresidents.

   Cannot process chunk/lines:
 2020-11-01:
   Cannot process chunk/lines:
 Ecdat 0.3-9 deletes ~demoFiles/*_data.xls, because they were used 
to test Ecfun::financialDataFiles and Ecfun::readFinancialDataFiles, and 
those two functions were removed, because they used gdata, which was not 
being maintained, and the work required to maintain them exceeded the 
current need of the maintainer.

   Cannot process chunk/lines:
 2020-02-08:  Ecdat 0.3-6 adds variables popM, popYr, GDP_B, and 
GDPyr to data set "nuclearWeaponStates".

   Cannot process chunk/lines:
 2019-12-05:  Ecdat 0.3-5 corrects the description of Crime$density 
to read, "hundreds of people per square mile" from "people per square 
mile".  Thanks to Yungfong "Frank" Tang for identifying this error and 
confirming the needed correction.

   Cannot process chunk/lines:
 2019-11-05:  Ecdat 0.3-4 adds variable 'firstTestYr' to 
'nuclearWeaponStates'.  It also corrects an error in the 'Mroz' data 
set, in that "work" had the names of the levels incorrectly swapped.

   Cannot process chunk/lines:
 Ecdat 0.3-3 adds data set "nuclearWeaponStates", which might be 
used to model the probability distribution of the time to the next new 
nuclear weapon state.

   Cannot process chunk/lines:

* checking for detritus in the temp directory ... NOTE
Found the following files/directories:
   'lastMiKTeXException'

See the full build log: HTML 
<https://builder.r-hub.io/status/Ecdat_0.4-2.tar.gz-aec6a2cb4b8a43cfbab0405f54e67c64>, 
text 
<https://builder.r-hub.io/status/original/Ecdat_0.4-2.tar.gz-aec6a2cb4b8a43cfbab0405f54e67c64>, 
artifacts 
<https://artifacts.r-hub.io/Ecdat_0.4-2.tar.gz-aec6a2cb4b8a43cfbab0405f54e67c64>. 

Have questions, suggestions or want to report a bug? Please file an 
issue ticket at GitHub <https://github.com/r-hub/rhub/issues>. Thank You 
for using the R-hub builder.


(c) 2016 The R Consortium

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

Re: [R-pkg-devel] Problems with news in ‘NEWS’

[Spencer Graves]

On 10/13/22 4:34 AM, Ivan Krylov wrote:

В Wed, 12 Oct 2022 20:16:20 -0500
Spencer Graves  пишет:


I copied NEWS to NEWS.md and tried to format it as described in:


https://r-pkgs.org/other-markdown.html#news


  Sadly, I still get the same error.  It seems to be ignoring
my NEWS.md file and continuing to tell me I haven't fixed NEWS.


Does it help to remove the NEWS after you've created NEWS.md in the
root directory of your package? In theory, NEWS.md takes precedence
over everything except inst/NEWS.Rd, but maybe that's not the case when
checking the package.



Thanks.  I did that, and it worked.



For the record, both the plain text format R expects in the NEWS file
and the Markdown format for NEWS.md are described in help(news).



Thanks, I missed that reference but managed to find something that worked.


  Spencer

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

Re: [R-pkg-devel] Error uploading file on CRAN

[Spencer Graves]

On 11/27/22 10:44 AM, Duncan Murdoch wrote:

On 27/11/2022 11:29 a.m., Jahajeeah, Havisha wrote:

Dear CRAN team,

The Greymodels package has been debugged and the updated package has been
published on Github.

I would be very much grateful if the app could be updated on CRAN.


That needs to be done by the maintainer (that's you, I think), according 
to the CRAN submission instructions here: 
https://cran.r-project.org/web/packages/policies.html .  The last 
section tells you how to do an update, but don't skip the earlier ones.


Duncan Murdoch



Thanks, Duncan.


	  In addition to Duncan's comments, I perceive the development version 
of Wickham and Bryan's "R Packages" to be also quite useful:



https://r-pkgs.org


	  To make this simpler for me, I've summarized what I've gotten from 
the CRAN source Duncan mentioned and from Wickham and Bryan in a file 
with a name like "release_to_CRAN.R".  I add such a file to the packages 
I maintain on GitHub, while adding that file name to ".Rbuildignore". 
Anything in ".Rbuildignore" is available to me but is not submitted to 
CRAN.  For an example of the current status of one such file, see:



https://github.com/sbgraves237/Ecdat/blob/master/Ecdat_release_to_CRAN.R


  Hope this helps.
  Spencer Graves





I look forward to hearing from you.

Thanking you and sincerely
Havisha Jahajeeah

On Mon, Nov 7, 2022 at 12:30 PM Jahajeeah, Havisha 
wrote:


Dear CRAN team,

The package 'Greymodels' has just been published on CRAN. After loading
the package on CRAN, when I try to upload file (xlsx or xls)
the following error appears:

Error: cannot open the connection

What could be the problem? Is it because of the working directory?

Please advise on how to fix this.

Many thanks,
Havisha Jahajeeah



[[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] How to reduce examples in a package that takes more than 5 seconds to run?

[Spencer Graves]

On 12/15/22 9:02 AM, Ben Bolker wrote:



On 2022-12-15 9:57 a.m., Brian G. Peterson wrote:

On 12/15/22 08:34, Ismail Otoakhia wrote:
The R package 'ardl.nardl' has some examples that take more than 5 
seconds
to run. I was advised by the CRAN team to reduce the run time to less 
than

5 seconds.

How can this be achieved?


- you can lower the amount of data in the example

- you can use a faster method than your default method

- you can wrap the example in a dontrun tag so it will not run during 
checking




   If your example involves something like a fitted model object that 
takes a long time to compute, you can pre-compute the model fit and 
store the object in an inst/testdata directory, then use something like


fitted_model <- readRDS(system.file("testdata", "my_example.rds", 
package = "mypackage"))


to retrieve it



	  The "sos" package includes a function "CRAN", which is used for that 
purpose.  The examples section in "findfn.Rd" includes the following:



# Skip these tests on CRAN,
# because they take more than 5 seconds
if(!CRAN()){
...
}


	  I know that some on this list do not like this construct, but it has 
helped me manage this problem for several years.  NOTE:  This CRAN 
function is NOT maintained by anyone on CRAN, so it is NOT guaranteed to 
work.  However, the "sos" package is currently on CRAN, and I have not 
seen an email asking me to avoid it ;-)



https://github.com/sbgraves237/sos/blob/master/man/findFn.Rd


  Hope this helps.
  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-pkg-devel] Current recommendations re. GitHub Action?

[Spencer Graves]

Hello, All:


  What are current recommendations for GitHub Action?


	  My most recent change to "sos" generated "Failed to get R" for 
ubuntu-latest (release, devel, and oldrel-1).



https://github.com/sbgraves237/sos/actions/runs/3820307473/jobs/6498527786


  I would happily rtfm if I only knew which fmtr.


  Thanks,
  Spencer Graves

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

Re: [R-pkg-devel] Current recommendations re. GitHub Action?

[Spencer Graves]

On 1/2/23 12:38 PM, Dirk Eddelbuettel wrote:


As the error is common against your _all three_ of your Ubuntu runs, you
could consider the possibility that the events are correlated.  Most often it
simply means a (temporary, usually) network or server outage.  I would wait,
and then relaunch (which these days you can do just for the failed jobs).

It is also worth paying attention to warnings such as

Warning: r-lib/actions/setup-r@v1 is deprecated. Please update your
workflow to use the 'v2' version. Also look at the examples at
https://github.com/r-lib/actions/tree/v2/examples because '@v2' workflows
are much simpler than 'v1' workflows.



	  Thanks to Zhian Kamvar and Dirk Eddelbuettel for encouraging me to 
look at the warning.



	  I replaced a few lined of my "R-CMD-check.yaml" file with the the 
"v3" and "v2" versions in the example in 
"https://github.com/r-lib/actions/tree/v2/examples"; and deleted 
subsequent lines that I didn't understand, and I got an instant failure: 
 It didn't run even one of the 5 tests.  Then I did "git revert" with 
the version number from GitHub and changed several lines to match the 
example with the succeeding yaml code.  GitHub Action ran and failed on 
all 5 platforms.  I did "git revert" with that and changed 
"r-lib/actions/setup-r@v1" to "r-lib/actions/setup-r@v2".  With that, 
R-release ran successfully on Unbuntu as well as Windows and macOS.



	  However, Ubuntu failed with devel and oldrel1, complaining, "there is 
no package called ‘rcmdcheck’".



  See:


https://github.com/sbgraves237/sos


  Suggestions?
  Thanks,
  Spencer Graves



Hth,  Dirk



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

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

[Spencer Graves]

	  If you use GitHub, I highly recommend using "GitHub Action" as 
described by Wickham and Bryan, R Packages:



https://r-pkgs.org/code.html#code-style


	  I'm not sure the best way to get it set up, but I have all my 
packages on GitHub configured so each "push" that changes anything has 
"R CMD Check" run on 5 different platforms:  The release version of R on 
the latest Windows, macOS, and Ubuntu plus the development version and 
the most recent old release on Ubuntu.  I rarely run R CMD check on my 
local machine anymore:  I just "git commit" and "git push".  Then GitHub 
Action manages testing on those 5 platforms.



	  To be precise, I do "git status" before "git push" to make sure I 
have "committed" everything I want to commit before I "git push".  And I 
do "git pull" to make sure a collaborator hasn't "pushed" something new 
I should look at before I "git push".



	  Finally, I want to thank again Gábor Csárdi who helped me greatly get 
past problems I hand with "GitHub Action" for my "sos" package.  He 
provided example workflows in:



https://github.com/r-lib/actions/blob/v2-branch/examples/check-standard.yaml


  I also needed LaTeX support, for which Gábor suggested the following:


https://github.com/r-lib/actions/tree/v2/setup-tinytex#ctan-packages


  Spencer Graves


On 1/8/23 9:11 AM, Kevin R. Coombes wrote:
A very helpful answer. For some reason (probably because I have an 
ancient perl script that automates the steps i take when building and 
checking packages), I keep forgetting that the "tools" package let's me 
do these things from within R.


I had already isolated the offending line ("plot(obj)") inside the chunk 
where the error occurred, and removed any additional arguments. I 
wrapped that line in a "try" command followed by a conditional 
"traceback()" to find the problem.  This allowed the package build to 
knit the vignette and provide some feedback about what was going on. It 
turned out that I had copied and pasted an assignment line of the form


main <- [compute the title]

from earlier in the code and pasted it directly as an argument to the 
call to image.default. And R did exactly what I told it to (not 
surprisingly), and interpreted the value of that assignment as the 
unnamed "zlim" option that would have been the corresponding positional 
argument that should have been there.


And yes, I still use "left arrow" <- instead of equals = as assignments. 
(Heck, I even use emacs and ESS with a leftover keybinding that uses the 
underscore key to insert the left arrow. Apparently, I'm ancient myself.)


   Kevin

On 1/8/2023 5:04 AM, Duncan Murdoch wrote:

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


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

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

[Spencer Graves]

On 1/8/23 11:36 AM, Kevin Coombes wrote:
I have been using R-Forge for many years for package development. And I 
have been using GitLab for other projects almost as long.


However, over the past few months, the R-Forge support seems to be 
decaying, and I now have several projects that won't currently build 
there because of various items that appear to need fixing at their end. 
So, I am actively exploring what it will take to move packages and 
projects to git.



	  R-Forge was wonderful for me when I started using it.  Then several 
years ago, I started having problems like you described.  A few years 
ago I migrated from R-Forge to GitHub.



	  One problem I encountered in the transition:  On R-Forge, I had 
multiple packages in the same R-Forge project.  I had to split them 
apart for GitHub.




I already know how to use a git client to clone a Subversion repository 
from R-Forge (using "git svn"). And how to change the remote origin to 
push it to a new git location. (And I  may also be willing to lose the 
revision history if it is going to make the transition easier.)


I am now at the step of understanding the recent changes at GitLab with 
respect to support for "Educational" or "Open Source" status, especially 
in terms of how many monthly minutes of CI/CD time I can use for free. 
When working on a new package, I tend to make lots of small 
commit-pushes, and it sounds like each one of those will eat up minutes. 
So, any advice on how to manage that issue would be greatly appreciated.



	  When I first got into Subversion, I remember Doug Bates saying, 
"Commit early and often."  The word "Commit" doesn't mean the same in 
Git as in Subversion, so I would encourage you to "Git push early and 
often."



	  There may be limits on free use of GitHub, but I'm not aware of them: 
 If you want a private account, you need to pay for that, but the 
charges for that are not much.



	  If anyone knows anything different from what I've just said, I hope 
they will disabuse my of this part of my ignorance.



  Spencer



Best,
   Kevin

On Sun, Jan 8, 2023, 11:30 AM Spencer Graves 
<mailto:spencer.gra...@effectivedefense.org>> wrote:


           If you use GitHub, I highly recommend using "GitHub
Action" as
described by Wickham and Bryan, R Packages:


https://r-pkgs.org/code.html#code-style
<https://r-pkgs.org/code.html#code-style>


           I'm not sure the best way to get it set up, but I have
all my
packages on GitHub configured so each "push" that changes anything has
"R CMD Check" run on 5 different platforms:  The release version of
R on
the latest Windows, macOS, and Ubuntu plus the development version and
the most recent old release on Ubuntu.  I rarely run R CMD check on my
local machine anymore:  I just "git commit" and "git push".  Then
GitHub
Action manages testing on those 5 platforms.


           To be precise, I do "git status" before "git push" to
make sure I
have "committed" everything I want to commit before I "git push". 
And I

do "git pull" to make sure a collaborator hasn't "pushed" something new
I should look at before I "git push".


           Finally, I want to thank again Gábor Csárdi who helped me
greatly get
past problems I hand with "GitHub Action" for my "sos" package.  He
provided example workflows in:


https://github.com/r-lib/actions/blob/v2-branch/examples/check-standard.yaml 
<https://github.com/r-lib/actions/blob/v2-branch/examples/check-standard.yaml>


           I also needed LaTeX support, for which Gábor suggested
the following:


https://github.com/r-lib/actions/tree/v2/setup-tinytex#ctan-packages
<https://github.com/r-lib/actions/tree/v2/setup-tinytex#ctan-packages>


           Spencer Graves


On 1/8/23 9:11 AM, Kevin R. Coombes wrote:
 > A very helpful answer. For some reason (probably because I have an
 > ancient perl script that automates the steps i take when building
and
 > checking packages), I keep forgetting that the "tools" package
let's me
 > do these things from within R.
 >
 > I had already isolated the offending line ("plot(obj)") inside
the chunk
 > where the error occurred, and removed any additional arguments. I
 > wrapped that line in a "try" command followed by a conditional
 > "traceback()" to find the problem.  This allowed the package
build to
 > knit the vignette and provide some feedback about what was going
on. It
 > turned out that I had copied and pasted an assignment line of the
  

[R-pkg-devel] corrupted NAMESPACE file

[Spencer Graves]

Hello, All:


  The NAMESPACE file in


https://github.com/JamesRamsay5/fda


is corrupted.  RStudio 2022.12.0+353 (the current version) won't open 
it, complaining, "File is binary rather than text so cannot be opened by 
the source editor."  TextEdit (macOS 11.7.2) opened it as normal, as did 
vi.  Both allowed me to make and save changes, but RStudio still gave 
the same error.  Worse, after "git push", GitHub Action on 5 platforms 
ended with:



** byte-compile and prepare package for lazy loading
Error in parse(nsFile, keep.source = FALSE, srcfile = NULL) :
  1:1: unexpected input


  That's the same error I've gotten with "R CMD build fda" locally.


  Suggestions?
  Thanks,
  Spencer Graves

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

Re: [R-pkg-devel] corrupted NAMESPACE file

[Spencer Graves]

Hi, Ivan and Uwe:


	  Thanks for your suggestions, but I've so far been unable to get them 
to work.  see below.



On 1/20/23 9:22 AM, Uwe Ligges wrote:



On 20.01.2023 15:53, Ivan Krylov wrote:

В Fri, 20 Jan 2023 08:41:25 -0600
Spencer Graves  пишет:


** byte-compile and prepare package for lazy loading
Error in parse(nsFile, keep.source = FALSE, srcfile = NULL) :
    1:1: unexpected input


tools::showNonASCIIfile('https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')
# 1: export(AmpPhaseDecomp,

Your NAMESPACE file starts with a U+FEFF ZERO WIDTH NO-BREAK SPACE.
You'll need to remove it, e.g. by re-creating the first line.



Note that this is also called "byte order mark" (BOM). Tell your editor 
not to create files with BOM.


You can also fix in R:

x <- readLines(..., encoding="UTF-8-BOM")
writeLines(x, ..)



  In RStudio 2022.12.0+353 (the current version),


tools::showNonASCIIfile('https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')


returned "char(0)".  'readLines' and 'writeLines' as Uwe suggested 
failed to fix it for me.



	  The first problem I noticed with this was that RStudio could not read 
the NAMESPACE file.  When I tried, it said, "File is binary rather than 
text so cannot be opened by the source editor."  I changed something 
using a different editor and did "git commit" and "git push", and got 
the error on GitHub that I reported above.  I copied the file elsewhere, 
deleted it locally and from GitHub, then recreated it in LibreOffice by 
manually typing the first and last lines then copying the rest from a 
copy I had saved elsewhere.  The RStudio would open the file, but I 
still get the same error message as above from both "R CMD build fda" 
locally and from GitHub Action at:



https://github.com/JamesRamsay5/fda


  Other suggestions?
  Thanks,
  Spencer Graves



Best,
Uwe Ligges







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

Re: [R-pkg-devel] corrupted NAMESPACE file

[Spencer Graves]

Hello, All:


	  My attempts to fix this problem exposed what seems to be a completely 
unrelated problem:  All five GitHub Actions end now with:



Error: package or namespace load failed for ‘fda’ in namespaceExport(ns, 
exports):

 undefined exports: refinery


	  The package includes ~man/refinery.Rd, ~data/refinery.rda, and 
NAMESPACE includes "export( ... refinery, ...)".



  ???
	  I have Bitdefender installed on this computer.  A "Quick Scan" 
produced nothing just now.



  Thanks,
  Spencer


On 1/20/23 5:08 PM, Duncan Murdoch wrote:

On 20/01/2023 6:02 p.m., Greg Hunt wrote:

xFEFF isn't a BOM in a UTF-8 file, its not anything.   The UTF-8 BOM is a
different sequence of bits.  If tools treat it as a BOM, that is 
arguably a

problem.


You're right.  FEFF is the UTF-16 big endian BOM.  UTF-16 is a 16 bit 
encoding, not at all the same as UTF-8.  I don't know how to read UTF-16 
in R. Uwe's advice was for UTF-8.


Duncan Murdoch



On Sat, 21 Jan 2023 at 05:09, Bill Dunlap  
wrote:



Setting the locale to "C" (or perhaps some other non-UTF-8 locale) will
show the BOM bytes.  E.g., on Windows I get:


Sys.getlocale()

[1] "LC_COLLATE=English_United States.utf8;LC_CTYPE=English_United
States.utf8;LC_MONETARY=English_United
States.utf8;LC_NUMERIC=C;LC_TIME=English_United States.utf8"

tools::showNonASCIIfile('

https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')

rawToChar(readBin('

https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE',
what="raw", n=20))
[1] "export(AmpPhasDec"

Sys.setlocale(locale="C")

[1] "C"

tools::showNonASCIIfile('

https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')
1: export(AmpPhasDecomp,

rawToChar(readBin('

https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE',
what="raw", n=20))
[1] "\357\273\277export(AmpPhasDec"

-Bill


On Fri, Jan 20, 2023 at 9:16 AM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:


Hi, Ivan and Uwe:


   Thanks for your suggestions, but I've so far been unable 
to get

them
to work.  see below.


On 1/20/23 9:22 AM, Uwe Ligges wrote:



On 20.01.2023 15:53, Ivan Krylov wrote:

В Fri, 20 Jan 2023 08:41:25 -0600
Spencer Graves  пишет:


** byte-compile and prepare package for lazy loading
Error in parse(nsFile, keep.source = FALSE, srcfile = NULL) :
 1:1: unexpected input


tools::showNonASCIIfile('

https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')

# 1: export(AmpPhaseDecomp,

Your NAMESPACE file starts with a U+FEFF ZERO WIDTH NO-BREAK SPACE.
You'll need to remove it, e.g. by re-creating the first line.



Note that this is also called "byte order mark" (BOM). Tell your 
editor

not to create files with BOM.

You can also fix in R:

x <- readLines(..., encoding="UTF-8-BOM")
writeLines(x, ..)



   In RStudio 2022.12.0+353 (the current version),


tools::showNonASCIIfile('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')


returned "char(0)".  'readLines' and 'writeLines' as Uwe suggested
failed to fix it for me.


   The first problem I noticed with this was that RStudio could

not

read
the NAMESPACE file.  When I tried, it said, "File is binary rather than
text so cannot be opened by the source editor."  I changed something
using a different editor and did "git commit" and "git push", and got
the error on GitHub that I reported above.  I copied the file 
elsewhere,

deleted it locally and from GitHub, then recreated it in LibreOffice by
manually typing the first and last lines then copying the rest from a
copy I had saved elsewhere.  The RStudio would open the file, but I
still get the same error message as above from both "R CMD build fda"
locally and from GitHub Action at:


https://github.com/JamesRamsay5/fda


   Other suggestions?
   Thanks,
   Spencer Graves



Best,
Uwe Ligges







__
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


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

Re: [R-pkg-devel] corrupted NAMESPACE file

[Spencer Graves]

On 1/20/23 7:32 PM, Duncan Murdoch wrote:

On 20/01/2023 8:16 p.m., Spencer Graves wrote:

Hello, All:


  My attempts to fix this problem exposed what seems to be a 
completely

unrelated problem:  All five GitHub Actions end now with:


Error: package or namespace load failed for ‘fda’ in namespaceExport(ns,
exports):
   undefined exports: refinery


  The package includes ~man/refinery.Rd, ~data/refinery.rda, and
NAMESPACE includes "export( ... refinery, ...)".



I think if you declare something as data by putting it in the data 
directory and using LazyData:true, you shouldn't also declare it as an 
export in the NAMESPACE file.



	  I got the same negative results after deleting "LazyData: true" from 
DESCRIPTION.  (That's what I would expect, because there are 17 other 
*.rda files in the data subdirectory that are are mentioned in NAMESPACE 
and are not creating a problem.  In 2009 the package included both 
"data/refinery.rda" and "man/refinery.Rd".  They were erroneously 
removed at some point.  I'm now trying to restore them.)



  Thanks,
  Spencer



Duncan Murdoch




  ???
  I have Bitdefender installed on this computer.  A "Quick Scan"
produced nothing just now.


  Thanks,
  Spencer


On 1/20/23 5:08 PM, Duncan Murdoch wrote:

On 20/01/2023 6:02 p.m., Greg Hunt wrote:
xFEFF isn't a BOM in a UTF-8 file, its not anything.   The UTF-8 BOM 
is a

different sequence of bits.  If tools treat it as a BOM, that is
arguably a
problem.


You're right.  FEFF is the UTF-16 big endian BOM.  UTF-16 is a 16 bit
encoding, not at all the same as UTF-8.  I don't know how to read UTF-16
in R. Uwe's advice was for UTF-8.

Duncan Murdoch



On Sat, 21 Jan 2023 at 05:09, Bill Dunlap 
wrote:

Setting the locale to "C" (or perhaps some other non-UTF-8 locale) 
will

show the BOM bytes.  E.g., on Windows I get:


Sys.getlocale()

[1] "LC_COLLATE=English_United States.utf8;LC_CTYPE=English_United
States.utf8;LC_MONETARY=English_United
States.utf8;LC_NUMERIC=C;LC_TIME=English_United States.utf8"

tools::showNonASCIIfile('

https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')

rawToChar(readBin('

https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE',
what="raw", n=20))
[1] "export(AmpPhasDec"

Sys.setlocale(locale="C")

[1] "C"

tools::showNonASCIIfile('

https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')
1: export(AmpPhasDecomp,

rawToChar(readBin('

https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE',
what="raw", n=20))
[1] "\357\273\277export(AmpPhasDec"

-Bill


On Fri, Jan 20, 2023 at 9:16 AM Spencer Graves <
spencer.gra...@effectivedefense.org> wrote:


Hi, Ivan and Uwe:


    Thanks for your suggestions, but I've so far been unable
to get
them
to work.  see below.


On 1/20/23 9:22 AM, Uwe Ligges wrote:



On 20.01.2023 15:53, Ivan Krylov wrote:

В Fri, 20 Jan 2023 08:41:25 -0600
Spencer Graves  пишет:


** byte-compile and prepare package for lazy loading
Error in parse(nsFile, keep.source = FALSE, srcfile = NULL) :
  1:1: unexpected input


tools::showNonASCIIfile('

https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')

# 1: export(AmpPhaseDecomp,

Your NAMESPACE file starts with a U+FEFF ZERO WIDTH NO-BREAK SPACE.
You'll need to remove it, e.g. by re-creating the first line.



Note that this is also called "byte order mark" (BOM). Tell your
editor
not to create files with BOM.

You can also fix in R:

x <- readLines(..., encoding="UTF-8-BOM")
writeLines(x, ..)



    In RStudio 2022.12.0+353 (the current version),


tools::showNonASCIIfile('
https://raw.githubusercontent.com/JamesRamsay5/fda/master/NAMESPACE')


returned "char(0)".  'readLines' and 'writeLines' as Uwe suggested
failed to fix it for me.


    The first problem I noticed with this was that RStudio 
could

not

read
the NAMESPACE file.  When I tried, it said, "File is binary rather 
than

text so cannot be opened by the source editor."  I changed something
using a different editor and did "git commit" and "git push", and got
the error on GitHub that I reported above.  I copied the file
elsewhere,
deleted it locally and from GitHub, then recreated it in 
LibreOffice by

manually typing the first and last lines then copying the rest from a
copy I had saved elsewhere.  The RStudio would open the file, but I
still get the same error message as above from both "R CMD build fda"
locally and from GitHub Action at:


https://github.com/JamesRamsay5/fda


    Other suggestions?
    Thanks,
    Spencer Graves



Best,
Uwe Ligges

Re: [R-pkg-devel] Package submission rejected as it fails checks on Debian

[Spencer Graves]

Hi, Vasileios:


  Do you have it on GitHub?


	  If yes, do you use "GitHub Action" to test the package on multiple 
platforms?  I'm a contributor to the "fda" package.  It's version on 
GitHub is configured so every "git push" triggers auto tests on five 
different platforms, testing it against the current "release" version of 
R on the latest versions of macOS, Windows and Ubuntu plus the 
development and previous release on Ubuntu.[1]  I don't know if GitHub 
action would support testing under Debian nor if testing under Ubuntu 
would catch the problem that CRAN is catching on Debian.



	  However, having the package on GitHub also makes it easier for 
someone else to clone the package and test it it for you ;-) This 
community of R developers provides very valuable support for problems 
like this.



  Hope this help.
  Spencer Graves


[1]https://github.com/JamesRamsay5/fda/blob/master/.github/workflows/R-CMD-check.yaml


On 2/20/23 6:38 AM, Vasileios Nikolaidis wrote:
Dear R-developers, I apologize for posting something that has probably 
been discussed before (but missed it while searching the archives).


While trying to submit a newer version of my package to CRAN, it is 
rejected as it fails on Debian. I will call this package APACKAGE below 
(although it is named differently). It has passed all checks on my 
Windows system (no errors or warnings).


The package (for many versions now) is configured as follows:
Imports: Rcpp , methods
LinkingTo: Rcpp
Suggests: R.rsp

The previous version of the package (already on CRAN) shows no errors on 
CRAN checks, only NOTES for some platforms. Interestingly, a couple of 
days ago I checked the CRAN checks and noticed that this exact 
(previous) version of the package had one ERROR indicated, occurring in 
some Debian flavor (r-devel-linux-x86_64-debian-gcc, if I remember 
correctly). I changed nothing, but now it shows no errors for all 
platforms (including Debian).


Now I am trying to submit a newer version and it not accepted as it 
fails on Debian. Checking the log I see no syntax errors or warnings.


** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘APACKAGE’ in dyn.load(file, 
DLLpath = DLLpath, ...):
  unable to load shared object 
‘/srv/hornik/tmp/CRAN/APACKAGE.Rcheck/00LOCK-APACKAGE/00new/APACKAGE/libs/APACKAGE.so’:

/srv/hornik/tmp/CRAN/APACKAGE.Rcheck/00LOCK-APACKAGE/00new/APACKAGE/libs/APACKAGE.so:
 undefined symbol: _ZTIN6nnlib25layerE
Error: loading failed.


I tried the R-Hub builder and it also fails for Platform Debian Linux, 
R-devel, GCC. The process goes fine until the following:


Error: package or namespace load failed for ‘APACKAGE’ in dyn.load(file, 
DLLpath = DLLpath, ...):
  unable to load shared object 
'/home/docker/R/00LOCK-APACKAGE/00new/APACKAGE/libs/APACKAGE.so':
   /home/docker/R/00LOCK-APACKAGE/00new/APACKAGE/libs/APACKAGE.so: 
undefined symbol: _ZTIN6nnlib25layerE

Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/home/docker/R/APACKAGE’
Warning message:
In i.p(...) :
   installation of package 
‘/tmp/Rtmp7eBDvE/file1377f5861e3/APACKAGE_0.2.0.tar.gz’ had non-zero 
exit status


It maybe something obvious, but I really cannot think of what else to 
try to fix this issue.

Any help will be greatly appreciated.

__
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 submission rejected as it fails checks on Debian

[Spencer Graves]

On 2/21/23 2:34 AM, Vasileios Nikolaidis wrote:
Yes, with all this I can think where I may have messed up. So thanks for 
the help, at least it verified it is indeed an issue with the code. As 
far as OSs, I use Ubuntu variants a lot and (on several machines) but 
these days I have easier access to Windows (with WSL2 btw). I also like 
a strict compiler (and linker), there is usually a reason why they are 
strict. So if it is not obvious from examining the code,  I will set up 
something (be it WSL, VM or Docker) for testing.



	  If you have NOT tried "GitHub Action" yet, I highly recommend it. 
For my packages, every time I do "git push", it automatically runs "R 
CMD build / check" on 5 different platforms -- with no further effort on 
my part other than checking the results.



	  It should be easy to get something to work following the instructions 
in Wickham and Bryan, R Packages[1] or copying the code from another 
package.[2] If that fails, you might be able to get help from this list. 
 I got valuable suggestions from Dir Eddelbuettel and Duncan Murdoch.



	  I don't know if any version of Debian is available on GitHub Action. 
However, if CRAN is rejecting your package on GitHub Action, a question 
about that to this list might help make it available.  If you have 
special Ubuntu configuration issues that are not provided in the 
standard GitHub Action configurations, asking here might help you with 
that.



      Hope this helps,
  Spencer Graves


[1]


https://r-pkgs.org


[2] e.g.,


https://github.com/JamesRamsay5/fda



Thanks again,

Vasilis



Στις 2023-02-20 23:09, Dirk Eddelbuettel έγραψε:

On 20 February 2023 at 22:37, Vasileios Nikolaidis wrote:
| Thanks for taking the time to check it. The hint about the virtual
| 'layer' class is valuable.
| I will look into it.

Sounds good, glad to have been of assistance.  On a lark, I also tried 
your

most recent CRAN release, and it installs and loads fine here.

| PS I am tempted to set up a Debian test platform to speed up fixing the
| package.
| (Or abandon submitting the package to CRAN alltogether.)

I love working on Linux. And these days I hear from some friends that 
having

WSL2 on a (recent enough) Windows computer is also good as it effectively
gives a second machine with Ubuntu on it.  Docker can also be helpful, 
as are
the online resources -- rhub has helped me with both macos and windows 
builds.


Dirk


__
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] help fixing CRAN package sos

[Spencer Graves]

Hello, All:


  The sos package is failing some CRAN checks, complaining:[1]


LaTeX errors:
! Missing $ inserted.

$
l.303 {\tt pspline_
   checker} in the
! Emergency stop.

$
l.303 {\tt pspline_
   checker} in the
! ==> Fatal error occurred, no output PDF file produced!
--- failed re-building 'sos.Rnw'


	  I can NOT replicate these locally nor with GitHub action, and I 
failed to find 'psp' in 'sos.Rnw'.[2]  This raises two issue:



OBVIOUS:  What can I do to fix this error, or at least to understand it 
better?



SUBTLE:  How can I configure "github action", so it can replicate the 
errors reported on CRAN?



  Thanks,
  Spencer


[1]


https://cran.r-project.org


[2]


https://github.com/sbgraves237/sos


 Forwarded Message 
Subject: Re: CRAN package sos
Date: Sun, 14 May 2023 14:46:06 +0100
From: Prof Brian Ripley 
Reply-To: CRAN 
To: Spencer Graves 
CC: c...@r-project.org




On 12/05/2023 13:03, Spencer Graves wrote:

Hello, All:


You have just spammed my personal email address, contrary to the CRAN 
policy and done so deliberately and/or recklessly, overriding the 
Reply-To header.


   Is MASS being withdrawn along with multiple other packages (mgcv, 
survival, boot, lattice)?


Not so.  And that was a failure to do your own homework as you should 
have looked on CRAN to see that they are still available.


Further

options(repos=c(CRAN="http://cran.cnr.berkeley.edu";))

does not respect the user's choice of repository: that seems to make 
re-making it unreasonably slow.  On my very fast MacBook Pro


* checking re-building of vignette outputs ...^R
 [26s/265s] OK

so it is waiting 90% of the time.


   That's responsible for 3 of the 4 'warnings' listed there.  The 
warning for r-devel-linux-x86_64-fedora-gcc says "LaTeX errors:
! Missing $ inserted ... Fatal error occurred, no output PDF file 
produced! ... Vignette re-building failed."



   These all sound to me like operating system errors.  If there's 
something here I should do, I could use help in understanding what.


Do read the message -- it is a LaTeX error in the LaTeX code your 
package's vignettes generates.


   LaTeX errors:
! Missing $ inserted.

 $
l.303 {\tt pspline_
 checker} in the
! Emergency stop.

 $
l.303 {\tt pspline_
 checker} in the
! ==> Fatal error occurred, no output PDF file produced!

Underlines need to be escaped in LaTeX.  And as your results depend on 
Internet downloads,


"Packages which use Internet resources should fail gracefully with an 
informative message if the resource is not available or has changed (and 
not give a check warning nor error)."


applies: you need to anticipate that the results might include underlines.




   Thanks,
   Spencer Graves
m:  1-408-655-4567


On 5/12/23 1:38 AM, Prof Brian Ripley wrote:

Dear maintainer,

Please see the problems shown on
<https://cran.r-project.org/web/checks/check_results_sos.html>.

Please correct before 2023-05-26 to safely retain your package on CRAN.

The CRAN Team


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-pkg-devel] help fixing CRAN package sos

[Spencer Graves]

On 5/16/23 6:06 AM, Uwe Ligges wrote:



On 16.05.2023 01:46, Spencer Graves wrote:

Hello, All:


   The sos package is failing some CRAN checks, complaining:[1]


LaTeX errors:
! Missing $ inserted.

 $
l.303 {\tt pspline_
    checker} in the



I can only guess this is part of the response you got from some sos 
request? I cannot reproduce it currently.


So check:
Does your package pass check if some function names including an 
underscore in the name is returned from an sos request?



Hi, Uwe et al.:


  Thanks, Uwe, for your reply.


	  It's complaining about something in a vignette that has been part of 
the package since it appeared in The R Journal in Volume 1/2 in 2009.  I 
received an email from Prof. Ripley complaining that it reported 
problems ("WARN") on some of the CRAN checks.  When I asked, Prof. 
Ripley reply's reply included:



>>  l.303 {\tt pspline_
>>   checker} in the
>>  ! ==> Fatal error occurred, no output PDF file produced!
>>
>> Underlines need to be escaped in LaTeX.  And as your results depend on
>> Internet downloads,
>>
>> "Packages which use Internet resources should fail gracefully with an
>> informative message if the resource is not available or has changed
>> (and not give a check warning nor error)."
>>
>> applies: you need to anticipate that the results might include
>> underlines.


	  I don't know how to detect, let alone fix the "Underlines" that "need 
to be escaped in LaTeX."



	  Regarding the other issue that "Packages which use Internet resources 
should fail gracefully with an informative message if the resource is 
not available or has changed (and not give a check warning nor error)", 
I assume I should wrap in "try" all tests in *.Rd files that access the 
Internet and make sure that they don't fail "R CMD check" if the 
Internet is not available.



  Comments?
  Thanks again,
  Spencer Graves


p.s.  Yesterday I remember I got "WARN" on three of six CRAN checks 
against r-devel on different platforms and NOTE on four of the seven 
other CRAN checks.  Today I see "WARN" on only two.  If I just wait, 
these "WARN" problems may go away by themselves.  However, Prof. Ripley 
gave me other problems to fix, and I want to support our kind, smart and 
generous English professor.




Best,
Uwe Ligges







! Emergency stop.

 $
l.303 {\tt pspline_
    checker} in the
! ==> Fatal error occurred, no output PDF file produced!
--- failed re-building 'sos.Rnw'


   I can NOT replicate these locally nor with GitHub action, and I 
failed to find 'psp' in 'sos.Rnw'.[2]  This raises two issue:



OBVIOUS:  What can I do to fix this error, or at least to understand 
it better?



SUBTLE:  How can I configure "github action", so it can replicate the 
errors reported on CRAN?



   Thanks,
   Spencer


[1]


https://cran.r-project.org


[2]


https://github.com/sbgraves237/sos


 Forwarded Message 
Subject: Re: CRAN package sos
Date: Sun, 14 May 2023 14:46:06 +0100
From: Prof Brian Ripley 
Reply-To: CRAN 
To: Spencer Graves 
CC: c...@r-project.org




On 12/05/2023 13:03, Spencer Graves wrote:

Hello, All:


You have just spammed my personal email address, contrary to the CRAN 
policy and done so deliberately and/or recklessly, overriding the 
Reply-To header.


   Is MASS being withdrawn along with multiple other packages 
(mgcv, survival, boot, lattice)?


Not so.  And that was a failure to do your own homework as you should 
have looked on CRAN to see that they are still available.


Further

options(repos=c(CRAN="http://cran.cnr.berkeley.edu";))

does not respect the user's choice of repository: that seems to make 
re-making it unreasonably slow.  On my very fast MacBook Pro


* checking re-building of vignette outputs ...^R
  [26s/265s] OK

so it is waiting 90% of the time.


   That's responsible for 3 of the 4 'warnings' listed there.  
The warning for r-devel-linux-x86_64-fedora-gcc says "LaTeX errors:
! Missing $ inserted ... Fatal error occurred, no output PDF file 
produced! ... Vignette re-building failed."



   These all sound to me like operating system errors.  If 
there's something here I should do, I could use help in understanding 
what.


Do read the message -- it is a LaTeX error in the LaTeX code your 
package's vignettes generates.


    LaTeX errors:
 ! Missing $ inserted.
 
  $
 l.303 {\tt pspline_
  checker} in the
 ! Emergency stop.
 
  $
 l.303 {\tt pspline_
  checker} in the
 ! ==> Fatal error occurred, no output PDF file produced!

Un

Re: [R-pkg-devel] help fixing CRAN package sos

[Spencer Graves]

Hi, Uwe et al.:


	  Uwe suggests I postprocess output with gsub("_", "_", output). 
It's not clear to me where I should apply this.  The "WARN" flags the 
sos vignette sos.Rnw, but the offending code refers to pspline_checker, 
which is not in the version of the vignette available on CRAN.[1] The 
text of sos.Rnw is available on GitHub.[2] I am not eager to change the 
code in the package, because it could break something else that's 
currently working.



  Suggestions?
  Thanks,
  Spencer Graves


[1]


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


[2]


https://github.com/sbgraves237/sos/blob/master/vignettes/sos.Rnw


On 5/16/23 7:41 AM, Uwe Ligges wrote:



On 16.05.2023 14:02, Spencer Graves wrote:



On 5/16/23 6:06 AM, Uwe Ligges wrote:



On 16.05.2023 01:46, Spencer Graves wrote:

Hello, All:


   The sos package is failing some CRAN checks, complaining:[1]


LaTeX errors:
! Missing $ inserted.

 $
l.303 {\tt pspline_
    checker} in the



I can only guess this is part of the response you got from some sos 
request? I cannot reproduce it currently.


So check:
Does your package pass check if some function names including an 
underscore in the name is returned from an sos request?



Hi, Uwe et al.:


   Thanks, Uwe, for your reply.


   It's complaining about something in a vignette that has been 
part of the package since it appeared in The R Journal in Volume 1/2 
in 2009.  I received an email from Prof. Ripley complaining that it 
reported problems ("WARN") on some of the CRAN checks.  When I asked, 
Prof. Ripley reply's reply included:



 >>  l.303 {\tt pspline_
 >>   checker} in the
 >>  ! ==> Fatal error occurred, no output PDF file produced!
 >>
 >> Underlines need to be escaped in LaTeX.  And as your results 
depend on

 >> Internet downloads,
 >>
 >> "Packages which use Internet resources should fail gracefully with an
 >> informative message if the resource is not available or has changed
 >> (and not give a check warning nor error)."
 >>
 >> applies: you need to anticipate that the results might include
 >> underlines.


   I don't know how to detect, let alone fix the "Underlines" that 
"need to be escaped in LaTeX."


If you receive an output, postprocess it via

gsub("_", "_", output)






   Regarding the other issue that "Packages which use Internet 
resources should fail gracefully with an informative message if the 
resource is not available or has changed (and not give a check warning 
nor error)", I assume I should wrap in "try" all tests in *.Rd files 
that access the Internet and make sure that they don't fail "R CMD 
check" if the Internet is not available.


Yes.

Best,
Uwe Ligges




   Comments?
   Thanks again,
   Spencer Graves


p.s.  Yesterday I remember I got "WARN" on three of six CRAN checks 
against r-devel on different platforms and NOTE on four of the seven 
other CRAN checks.  Today I see "WARN" on only two.  If I just wait, 
these "WARN" problems may go away by themselves.  However, Prof. 
Ripley gave me other problems to fix, and I want to support our kind, 
smart and generous English professor.




Best,
Uwe Ligges







! Emergency stop.

 $
l.303 {\tt pspline_
    checker} in the
! ==> Fatal error occurred, no output PDF file produced!
--- failed re-building 'sos.Rnw'


   I can NOT replicate these locally nor with GitHub action, and 
I failed to find 'psp' in 'sos.Rnw'.[2]  This raises two issue:



OBVIOUS:  What can I do to fix this error, or at least to understand 
it better?



SUBTLE:  How can I configure "github action", so it can replicate 
the errors reported on CRAN?



   Thanks,
   Spencer


[1]


https://cran.r-project.org


[2]


https://github.com/sbgraves237/sos


 Forwarded Message 
Subject: Re: CRAN package sos
Date: Sun, 14 May 2023 14:46:06 +0100
From: Prof Brian Ripley 
Reply-To: CRAN 
To: Spencer Graves 
CC: c...@r-project.org




On 12/05/2023 13:03, Spencer Graves wrote:

Hello, All:


You have just spammed my personal email address, contrary to the 
CRAN policy and done so deliberately and/or recklessly, overriding 
the Reply-To header.


   Is MASS being withdrawn along with multiple other packages 
(mgcv, survival, boot, lattice)?


Not so.  And that was a failure to do your own homework as you 
should have looked on CRAN to see that they are still available.


Further

options(repos=c(CRAN="http://cran.cnr.berkeley.edu";))

does not respect the user's choice of repository: that seems to make 
re-making it unreasonably 

Re: [R-pkg-devel] help fixing CRAN package sos-now fails on GitHub

[Spencer Graves]

Hi, Uwe et al.:


	  The sos vignette sos.Rnw now fails on GitHub, complaining of a LaTeX 
error in "{\tt pspline_ checker}".  I don't find it in the code for 
sos.Rnw.  It may be triggered by a response to an internet search that's 
different from before.



https://github.com/sbgraves237/sos


	  Uwe suggests I postprocess output with gsub("_", "_", output). 
It's not clear to me where I should apply this.  I am not eager to 
change the code in the package, because it could break something else 
that's currently working.



      Suggestions?
  Thanks
  Spencer Graves


On 5/16/23 7:41 AM, Uwe Ligges wrote:



On 16.05.2023 14:02, Spencer Graves wrote:



On 5/16/23 6:06 AM, Uwe Ligges wrote:



On 16.05.2023 01:46, Spencer Graves wrote:

Hello, All:


   The sos package is failing some CRAN checks, complaining:[1]


LaTeX errors:
! Missing $ inserted.

 $
l.303 {\tt pspline_
    checker} in the



I can only guess this is part of the response you got from some sos 
request? I cannot reproduce it currently.


So check:
Does your package pass check if some function names including an 
underscore in the name is returned from an sos request?



Hi, Uwe et al.:


   Thanks, Uwe, for your reply.


   It's complaining about something in a vignette that has been 
part of the package since it appeared in The R Journal in Volume 1/2 
in 2009.  I received an email from Prof. Ripley complaining that it 
reported problems ("WARN") on some of the CRAN checks.  When I asked, 
Prof. Ripley reply's reply included:



 >>  l.303 {\tt pspline_
 >>   checker} in the
 >>  ! ==> Fatal error occurred, no output PDF file produced!
 >>
 >> Underlines need to be escaped in LaTeX.  And as your results 
depend on

 >> Internet downloads,
 >>
 >> "Packages which use Internet resources should fail gracefully with an
 >> informative message if the resource is not available or has changed
 >> (and not give a check warning nor error)."
 >>
 >> applies: you need to anticipate that the results might include
 >> underlines.


   I don't know how to detect, let alone fix the "Underlines" that 
"need to be escaped in LaTeX."


If you receive an output, postprocess it via

gsub("_", "_", output)






   Regarding the other issue that "Packages which use Internet 
resources should fail gracefully with an informative message if the 
resource is not available or has changed (and not give a check warning 
nor error)", I assume I should wrap in "try" all tests in *.Rd files 
that access the Internet and make sure that they don't fail "R CMD 
check" if the Internet is not available.


Yes.

Best,
Uwe Ligges




   Comments?
   Thanks again,
   Spencer Graves


p.s.  Yesterday I remember I got "WARN" on three of six CRAN checks 
against r-devel on different platforms and NOTE on four of the seven 
other CRAN checks.  Today I see "WARN" on only two.  If I just wait, 
these "WARN" problems may go away by themselves.  However, Prof. 
Ripley gave me other problems to fix, and I want to support our kind, 
smart and generous English professor.




Best,
Uwe Ligges







! Emergency stop.

 $
l.303 {\tt pspline_
    checker} in the
! ==> Fatal error occurred, no output PDF file produced!
--- failed re-building 'sos.Rnw'


   I can NOT replicate these locally nor with GitHub action, and 
I failed to find 'psp' in 'sos.Rnw'.[2]  This raises two issue:



OBVIOUS:  What can I do to fix this error, or at least to understand 
it better?



SUBTLE:  How can I configure "github action", so it can replicate 
the errors reported on CRAN?



   Thanks,
   Spencer


[1]


https://cran.r-project.org


[2]


https://github.com/sbgraves237/sos


 Forwarded Message 
Subject: Re: CRAN package sos
Date: Sun, 14 May 2023 14:46:06 +0100
From: Prof Brian Ripley 
Reply-To: CRAN 
To: Spencer Graves 
CC: c...@r-project.org




On 12/05/2023 13:03, Spencer Graves wrote:

Hello, All:


You have just spammed my personal email address, contrary to the 
CRAN policy and done so deliberately and/or recklessly, overriding 
the Reply-To header.


   Is MASS being withdrawn along with multiple other packages 
(mgcv, survival, boot, lattice)?


Not so.  And that was a failure to do your own homework as you 
should have looked on CRAN to see that they are still available.


Further

options(repos=c(CRAN="http://cran.cnr.berkeley.edu";))

does not respect the user's choice of repository: that seems to make 
re-making it unreasonably slow.  On my very fast MacBook Pro


* checking re-bu

Re: [R-pkg-devel] help fixing CRAN package sos-now fails on GitHub

[Spencer Graves]

On 5/22/23 2:38 PM, Duncan Murdoch wrote:

On 22/05/2023 3:07 p.m., Ivan Krylov wrote:

I fed your vignette to R CMD Sweave, and here's the relevant fragment
from the resulting *.tex file:


This returned a {\tt "findFn"} object identifying 405 help pages.
When this was run while preparing this manuscript, the sixth row was
{\tt pspline_checker} in the \pkg{JOPS} package, which has a {\tt
Score} of 47. (On another day, the results could be different,
because CRAN changes over time.)  This was the sixth row in this
table, because it is in the \pkg{JOPS} package, which had a total of
54 help pages matching the search term, but this was the only one
whose name matched the {\tt pattern} passed to {\tt grepFn}.


This corresponds to the following part of the vignette:


This returned a {\tt "findFn"} object identifying \Sexpr{nrow(g)}
help pages.
When this was
run while preparing this manuscript, the sixth row was
{\tt \Sexpr{gFunc6}} in the
\pkg{\Sexpr{gPac6}} package, which has a {\tt Score} of
\Sexpr{gScore6}.


So, you need to escape the underscores in gFunc6. Probably not gPac6
because underscores are not allowed in package names.



Nice find.  Just in case Spencer has trouble with escaping the escapes, 
I think he should change


   "{\tt \Sexpr{gFunc6}}"

to

   "{\tt \Sexpr{sub("_", "_", gFunc6)}}



CLOSE:  That didn't work, but the following did:


{\tt \Sexpr{gsub("_", "_", gFunc6)}}



Even better would be to write a little function "sanitizeForLatex" that 
did this and any other necessary changes, and call that.



	  That would doubtless be better, but I don't know enough to do that, 
and the above worked.



	  Thanks very much to Duncan, Ivan, Vincent and Uwe, who contributed to 
this thread and the resolution of this problem.



  Spencer Graves



Duncan Murdoch


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

[R-pkg-devel] masked from 'package:utils':,, ?

[Spencer Graves]

Hello, All:


	  CRAN checks for sos on 8 of the 13 platforms complain about the 
following:



The following object is masked from 'package:utils':

?


	  This is code that Duncan Murdoch contributed to this package around 
2009.  I have no idea how to fix this.  It's only a NOTE, so CRAN would 
probably accept it.  However, I felt a need to ask about this before I 
submitted the package to CRAN without asking this group for suggestions.



  What do you think?
  Thanks,
      Spencer Graves

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

[R-pkg-devel] masked from 'package:utils':,, ?-2

[Spencer Graves]

Hello, All:


	  CRAN checks for sos on 8 of the 13 platforms complain about the 
following:[1]



The following object is masked from 'package:utils':

?


	  This is code that Duncan Murdoch contributed to this package around 
2009.  I have no idea how to fix this.  It's only a NOTE, so CRAN would 
probably accept it.  However, I felt a need to ask about this before I 
submitted the package to CRAN without asking this group for suggestions.



  What do you think?
  Thanks,
      Spencer Graves


[1]


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

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

Re: [R-pkg-devel] Change package name

[Spencer Graves]

On 6/21/23 8:33 PM, Rolf Turner wrote:


On Tue, 20 Jun 2023 17:39:48 -0400
 wrote:


If you really need a new package name, is there an accepted way to
update the old name to at least provide a message for a while as to
the new name to use and perhaps have the load otherwise fail?


I don't know about "accepted", but the following paradigm seems to me
to be sensible and reasonably efficacious:

* you have a package "foo" the name of which you wish to change to "bar"
* create a new package "bar" which is the same as "foo" except for its
   name
* now replace foo with a skeleton package which has only the file
   First.R in its R directory
* the file First.R should be something like:


.onAttach <- function(lib, pkg) {
ver <- read.dcf(file.path(lib, pkg, "DESCRIPTION"), "Version")
 packageStartupMessage(paste(pkg, ver))
 msg <- paste("\n This package, \"foo\" is now",
  " deprecated.  Users",
  "\n should install and use its",
  " successor  \"bar\".\n")
 packageStartupMessage(msg) }


* submit both "bar" and "foo" to CRAN



	  Years ago, I had package "RSiteSearch".  I asked some R list what 
might be a better name for that.  "sos" was suggested, and Duncan 
Murdoch contributed code for an enhancement.  Then I added something 
like ".onAttach" to "RSiteSearch" and kept it on CRAN for a couple of 
years after introducing "sos".  That allowed people to use the old 
package for a couple of years without forcing them to switch immediately.



  I think that worked quite well.


  Hope this helps.
  Spencer Graves



cheers,

Rolf Turner



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

[R-pkg-devel] GitHub Action not triggered by a commit to a fork

[Spencer Graves]

Hello:


	  Can someone help me understand why a commit to 
"https://github.com/sbgraves237/KFAS"; does not trigger the GitHub 
Actions specified in ".github/workflows/check-standard.yaml"?



  Thanks,
  Spencer Graves


p.s.  This is a branch of helske/KFAS:master.  That may have something 
to do with the problem.


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

Re: [R-pkg-devel] GitHub Action not triggered by a commit to a fork

[Spencer Graves]

Hi, Diego:


  Thanks for the reply.


On 7/5/23 4:50 PM, Diego Hernangómez Herrero wrote:

Hi,

GH actions are disabled by default on forks, have you checked 
<https://github.com/sbgraves237/KFAS/actions 
<https://github.com/sbgraves237/KFAS/actions>> and clicked on the green 
button?



  Got it.  I pushed another change, and that triggered GitHub Action.


  Thanks again, Spencer Graves



Best

El mié, 5 jul 2023 a las 23:45, Spencer Graves 
(<mailto:spencer.gra...@effectivedefense.org>>) escribió:


Hello:


           Can someone help me understand why a commit to
"https://github.com/sbgraves237/KFAS
<https://github.com/sbgraves237/KFAS>" does not trigger the GitHub
Actions specified in ".github/workflows/check-standard.yaml"?


           Thanks,
           Spencer Graves


p.s.  This is a branch of helske/KFAS:master.  That may have something
to do with the problem.

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



--



Have a nice day!


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

[R-pkg-devel] gfortran: command not found

[Spencer Graves]

Hello:


  "R CMD build KFAS" under macOS 11.7.8 stopped with:


using C compiler: ‘Apple clang version 12.0.5 (clang-1205.0.22.9)’
sh: gfortran: command not found
using SDK: ‘MacOSX11.3.sdk’
gfortran -arch x86_64  -fPIC  -Wall -g -O2  -c  approx.f90 -o approx.o
make: gfortran: No such file or directory
make: *** [approx.o] Error 1
ERROR: compilation failed for package ‘KFAS'


	  My web search suggests several different ways to fix this problem, 
but I don't know which to try.




  Suggestions?
  Thanks,
  Spencer Graves


p.s.  I have both "brew" and "port" installed.  I recently used "port" 
to upgrade another software package.  A web search suggested the 
following:



sudo port install gcc48
sudo port select -set gcc mp-gcc48


	  However, this comment was posted roughly 9 years ago.  Below please 
find sessionInfo().



sessionInfo()
R version 4.3.1 (2023-06-16)
Platform: x86_64-apple-darwin20 (64-bit)
Running under: macOS Big Sur 11.7.8

Matrix products: default
BLAS: 
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 

LAPACK: 
/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib; 
 LAPACK version 3.11.0


locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Chicago
tzcode source: internal

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

loaded via a namespace (and not attached):
 [1] compiler_4.3.1  R6_2.5.1magrittr_2.0.3  cli_3.6.1
 [5] tools_4.3.1 glue_1.6.2  rstudioapi_0.14 roxygen2_7.2.3
 [9] xml2_1.3.4  vctrs_0.6.2 stringi_1.7.12  knitr_1.42
[13] xfun_0.39   stringr_1.5.0   lifecycle_1.0.3 rlang_1.1.1
[17] purrr_1.0.1

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

Re: [R-pkg-devel] URL syntax causes R CMD build failure - a fix

[Spencer Graves]

I've encountered similar issues. However, it has been long enough ago 
that I don't remember enough details to say more without trying to 
update my CRAN packages to see what messages I get and maybe researching 
my notes from previous problems of this nature. Spencer Graves



On 9/2/23 4:23 PM, Greg Hunt wrote:

The percent encoded characters appear to be valid in that URL, suggesting
that rejecting them is an error. That kind of error could occur when the
software processing them converts them back to a non-unicode character set.

On Sun, 3 Sep 2023 at 4:34 am, J C Nash  wrote:


I'm posting this in case it helps some other developers getting build
failure.

Recently package nlsr that I maintain got a message that it failed to
build on
some platforms. The exact source of the problem is still to be illuminated,
but seems to be in knitr::render and/or pandoc or an unfortunate
interaction.
An update to pandoc triggered a failure to process a vignette that had been
happily processed for several years. The error messages are unhelpful, at
least
to me,

 Error at "nlsr-devdoc.knit.md" (line 5419, column 1):
 unexpected end of input
 Error: pandoc document conversion failed with error 64
 Execution halted

Unfortunately, adding "keep_md: TRUE" (you need upper case TRUE to save it
when
there is no error of this type), did not save the intermediate file in this
case. However, searching for "pandoc error 64" presented one web page
where the author
used brute force search of his document by removing / replacing sections
to find
the line(s) that caused trouble. This is a little tedious, but effective.
In my
case, the offending line turned out to be a copied and pasted URL

https://en.wikipedia.org/wiki/Levenberg%E2%80%93Marquardt_algorithm

The coded characters can be replaced by a hyphen, to give,

https://en.wikipedia.org/wiki/Levenberg-Marquardt_algorithm

and this, when pasted in Mozilla Firefox at least, will go to the
appropriate
wikipedia page.

I'd be interested in hearing from others who have had similar
difficulties. I
suspect this is relatively rare, and causing some sort of infelicity in the
output of knitr::render that then trips up some versions of pandoc, that
may,
for instance, be now applying stricter rules to URL syntax.

Best,

John Nash

__
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] Too many cores used in examples (not caused by data.table)

[Spencer Graves]

	  Chapter 15 in Wickham and Bryan, R Packages, discuss "Advanced 
Testing Techniques". Their current section "15.4.1 Skip a test" includes 
the following:



test_that("some long-running thing works", {
  skip_on_cran()
  # test code that can potentially take "a while" to run
})


	  Have you tried writing directly to Jennifer Bryan 
? She and Hadley might be able to get help from the 
CRAN maintainers in getting help with this particular problem AND 
getting more documentation on this in their book ;-)



  hope this helps.
  spencer graves


On 10/24/23 6:03 AM, Greg Hunt wrote:

In my case recently, after an hour or so’s messing about I disabled some
tests and example executions to get rid of the offending times. I doubt
that i am the only one to do that.

On Tue, 24 Oct 2023 at 9:38 pm, Helske, Jouni  wrote:


Thanks for the help, I now tried resubmitting with
Sys.setenv("OMP_THREAD_LIMIT" = 2) at the top of the exchange example, but
I still get the same note:

Examples with CPU time > 2.5 times elapsed time
   user system elapsed ratio
exchange 1.196   0.04   0.159 7.774

Not sure what to try next.

Best,
Jouni

From: Ivan Krylov 
Sent: Friday, October 20, 2023 16:54
To: Helske, Jouni 
Cc: r-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] Too many cores used in examples (not caused by
data.table)

В Thu, 19 Oct 2023 05:57:54 +
"Helske, Jouni"  пишет:


But I just realised that bssm uses Armadillo via RcppArmadillo, which
uses OpenMP by default for some elementwise operations. So, I wonder
if that could be the culprit?


I wasn't able to reproduce the NOTE either, despite manually setting
the environment variable
_R_CHECK_EXAMPLE_TIMING_CPU_TO_ELAPSED_THRESHOLD=2 before running R CMD
check, but I think I can see the code using OpenMP. Here's what I did:

0. Temporarily lower the system protections against capturing
performance traces of potentially sensitive parts:

echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid

(Set it back to 3 after you're done.)

1. Run the following command with the development version of the
package installed:

env OPENBLAS_NUM_THREADS=1 \
  perf record --call-graph drawf,4096 \
  R -e 'library(bssm); system.time(replicate(100, example(exchange)))'

OPENBLAS_NUM_THREADS=1 will prevent OpenBLAS from spawning worker
threads if you have it installed. (A different BLAS may need different
environment variables.)

2. Run `perf report` and browse collected call stack information.

The call stacks are hard to navigate, but I think they are not pointing
towards Armadillo. At least, setting ARMA_OPENMP_THREADS=1 doesn't
help, but setting OMP_THREAD_LIMIT=1 does.

--
Best regards,
Ivan

 [[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] Package bioOED has been removed from CRAN just for personal reasons

[Spencer Graves]

On 11/2/23 2:52 PM, Rolf Turner wrote:


On Wed, 1 Nov 2023 16:10:34 +
David Hugh-Jones  wrote:


Aside from the package question, surely the other issue here is that
Prof Ripley’s email is extraordinarily rude. Any paid employee would
be sacked for that. I appreciate R and CRAN are volunteer-run
organisations, but I don’t think that should be an excuse for this
level of, frankly, toxicity. Why is he allowed to get away with it?

David


I've just had a look at the initial posting in this thread

https://stat.ethz.ch/pipermail/r-package-devel/2023q4/009810.html

and can see nothing rude or offensive in the email from Prof. Ripley
that was copied and pasted into that posting.

I find *your* email far more offensive than anything that Prof. Ripley
has ever written.  Get a life.

cheers,

Rolf Turner

P.S.  See fortunes::fortune(88).

R. T.



Hi, David:


	  You do, of course, know that "Ripley" is a verb? People on this list 
take pride in how many times they've been Ripleyed ;-)



	  I've been in the military, and I've learned to ignore the tone and 
look for the value in comments I receive. I've learned a lot from 
Professor Ripley, and others. When the tone seemed less supportive or 
even insulting, I'm very glad the person took the time to comment and 
didn't decide not to reply for fear of offending me. I'm more productive 
and a better human for all the help I've gotten from this and other 
R-related lists.



fortunes::fortune('Spencer Graves')


  sg




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

[R-pkg-devel] Vignette error: "there is no package called 'markdown'"

[Spencer Graves]

Hello, All:


	  I'm getting, "Error: processing vignette 'sos.Rmd' failed with 
diagnostics: there is no package called 'markdown'":



https://github.com/sbgraves237/sos/actions/runs/9721300082/job/26833793243


  This is in:


https://github.com/sbgraves237/sos/blob/master/vignettes/sos.Rmd


	  This package has been on CRAN with a vignette since 2009. To isolate 
a new bug, I tried to translate the vignette from Sweave to RMarkdown. 
I've cut the vignette to almost nothing and still cannot see what's wrong.



  Suggestions?
  Thanks,
  Spencer Graves

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

Re: [R-pkg-devel] Vignette error: "there is no package called 'markdown'"

[Spencer Graves]

  That was it. Thanks very much.


	  Now I can go back to working on the "[.findFn" problem that you 
helped me identify. (I translated the Sweave vignette to RMarkdown to 
isolate that. Progress, with your help.)



  Spencer


On 6/29/24 04:47, Ivan Krylov wrote:

В Fri, 28 Jun 2024 22:55:23 -0500
Spencer Graves  пишет:


  I'm getting, "Error: processing vignette 'sos.Rmd' failed
with diagnostics: there is no package called 'markdown'":


https://github.com/sbgraves237/sos/actions/runs/9721300082/job/26833793243


  This is in:


https://github.com/sbgraves237/sos/blob/master/vignettes/sos.Rmd


This is an rmarkdown vignette, but you're setting
\VignetteBuilder{knitr::knitr}. Does the error go away if you set
\VignetteBuilder{knitr::rmarkdown}?

Also, it's best to put both knitr and rmarkdown in the VignetteBuilder
field of the DESCRIPTION, because both packages are required to process
the vignette successfully.



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

Re: [R-pkg-devel] Help needed with CRAN check error under MacOS and old-rel

[Spencer Graves]

Hello, Pedro et al.:


	  Your package is on GitHub with GitHub Actions.[1] If whoever manages 
GitHub actions feels inclined to add macos-latest (oldrel-1), this would 
be one argument for doing that, though this kind of problem may be too 
rare to justify the expense. That's particularly true since it's with 
oldrel.



	  However, the fact that your ggpp package is available on GitHub would 
make it easy with a Mac user with oldrel installed to run that for you. 
If you don't the problem fixed from help on this list, you could try 
R-SIG-MAC.



	  I just noticed that the error is in a vignette. I don't know if 
vignettes are run by GitHub Actions. I recently had a latent bug in a 
vignette reported to me by another user who updated a package that 
depended on mine. It was apparently reported to him by 
revdepcheck::revdep_check. I found the bug in the vignette and added a 
small test cases to add to the examples of the problem function. Then I 
fixed the problem (with help from Ivan Krylov on this list).



  hope this helps.
  spencer graves


[1]


https://github.com/aphalo/ggpp


On 6/30/24 04:17, Aphalo, Pedro J wrote:

Hello,
A few days ago I submitted to CRAN an updated version of package 'ggpp', it 
passed checks during submission and version 0.5.8 is now on CRAN. However I see 
errors for old-rel only for MacOS at 
https://cran.r-project.org/web/checks/check_results_ggpp.html and I am stuck as 
I do not have where to rerun this test.

The error itself is surprising as it seems to be caused by not finding df1, 
which is just a data frame defined in a code chunk in the same vignette, which 
uses 'pkgdown'. This error is limited to MacOS R old-rel but affects both arm64 
and x86_64. (For either of these, I could not find a working setup for GitHub 
integration or at https://mac.r-project.org/macbuilder/submit.html).

The offending code is in nudge-examples.Rmd starting at line 250. This file was 
last modified six-months' ago, i.e., it is the same as in the previous CRAN 
version of 'ggpp'.

(I would rather track the origin of the problem than disable all three possibly 
affected code examples.)

Thanks in advance for any help,

Pedro.


Pedro J. Aphalo
Senior University Lecturer, Principal Investigator
(Room 5605, Biocenter 3, Viikinkaari 1, Helsinki)
Organismal and Evolutionary Biology

P.O. Box 65
00014 University of Helsinki
Finland

e-mail: pedro.aph...@helsinki.fi<mailto:pedro.aph...@helsinki.fi>
Tel. (mobile) +358 50 4150623
Tel. (office) +358 2941 57897


Web sites and blogs
Web site (research group): http://blogs.helsinki.fi/senpep-blog/
Web site (using R in photobiology): http://www.r4photobiology.info/

Societies
UV4Plants<http://www.uv4plants.org/> (member), PSB<http://www.plantbehavior.org/> (member), 
ESP<http://www.photobiology.eu/> (member) SEB<http://www.sebiology.org/> (member), 
BES<http://www.britishecologicalsociety.org/> (member), SPPS<http://www.spps.fi/> (member), 
SMS<http://www.metsatieteellinenseura.fi/english> (member), TUG<http://tug.org/> (member), 
FOAS<http://www.foastat.org/> (member).



[[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] library dlstats -> cran_stats()

[Spencer Graves]

On 2018-03-16 06:53, Mark van der Loo wrote:

Knut

AFAIR the download statistics are limited to downloads from RStudio's cloud
service, so none of the other CRAN mirrors are included. I think there is
no separation between updates, re-installs, or installs done automatically
by CI-services, for example.



  That's what it says in the DESCRIPTION file of the "dlstats" 
package, available at 
"http://finzi.psych.upenn.edu/R/library/dlstats/DESCRIPTION";.



  Spencer Graves


-Mark



Op vr 16 mrt. 2018 om 12:30 schreef Knut Krueger :


Dear all,

Does anybody know whether the statistics are counting also  updates?
And if yes is it possible to get only the count of new installations?

Kind regards Knut


I

__
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] Avoid reprocessing Rmd vignette

[Spencer Graves]

On 2018-03-20 06:17, Johannes Ranke wrote:

...


The idea exposed by Dirk is the same: requireNamespace will find the
package on CRAN and will set eval=TRUE. What you want though is to
avoid running a chunk on CRAN, even if the package is available. So
you need to set eval=FALSE *unconditionally*.

Or conditional on the package version (as Dirk proposed regarding tests) or on
an environment variable NOT_CRAN which you can set to true on the machine
where you do want to run the code (as used by devtools).



  The function "fda::CRAN" allows package developers to run tests 
themselves that should not run on CRAN or with "R CMD check –as-cran".  
Several of my packages have code in "\examples" that include something 
like the following:



if(!fda::CRAN()){
    #Code I do not want run if a certain parameter is in Sys.getenv()
}


  I have not tried this, but I think you could set a parameter, 
e.g., '-no-vignette' via either Sys.setenv('-no-vignette'=1) or "R CMD 
check -no-vignette", then bracket code snippets in the vignette with 
"if(!fda::CRAN('-no-vignette', '-no-vignette')){...}".



  This will NOT turn off compiling the vignette, but it will allow 
you to suppress running code snippets in the vignette that take time.



  Hope this helps.
      Spencer


p.s.  I just tested "Sys.setenv('-no-vignette'=1);  tst2 <- 
CRAN('-no-vignette', '-no-vignette')" and got TRUE, when CRAN() returned 
FALSE.  When I tried print(tst2) I got:



 [1] TRUE
attr(,"Sys.getenv")
Error in formatDL(x, ...) : unused argument (digits = 7)


  I do not understand this error message, but it does not seem to 
be a problem I have to fix right now, so I won't.



Johannes

__
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] some notes

[Spencer Graves]

On 2018-04-24 09:50, Duncan Murdoch wrote:

On 24/04/2018 10:29 AM, Xubo Yue wrote:

Hey

I just got feedback from CRAN auto-checking and here are some notes I
cannot resolve:

* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Jian Kang '

New submission

Possibly mis-spelled words in DESCRIPTION:
   Kang (7:196)

I am not sure how to solve this.



You can ignore those.


Also, here are some running time notes:

** running examples for arch 'i386' ... [250s] NOTE
Examples with CPU or elapsed time > 10s
   user system elapsed
multipleRegion_plot 190.35   1.92  205.61
summary_kcca  1.40   0.17   14.79
permkCCA_multipleRegion   1.19   0.11   14.51
nii2RData 0.40   0.20   13.84
** running examples for arch 'x64' ... [79s] NOTE
Examples with CPU or elapsed time > 10s
  user system elapsed
multipleRegion_plot 18.36   2.06   33.66
permkCCA_multipleRegion  1.47   0.20   14.88
summary_kcca 1.48   0.16   14.85
nii2RData    0.62   0.23   14.09
* checking PDF version of manual ... OK
* DONE
Status: 3 NOTEs

My total running time is less than 10 minutes. I am wondering is it 
ok to

ignore these two NOTEs?


You shouldn't ignore those.  Your package will be tested many, many 
times, and it will take more than 3 minutes for just one example.  (It 
will be tested whenever any package you depend on is changed, to make 
sure the change doesn't break yours.)


Use a smaller dataset, do less, or whatever you can to get the 
multipleRegion_plot example down to a time similar to the other ones, 
i.e. well below 10s in user+system time.



  If it becomes infeasible to find smaller datasets, etc., you can 
cut out certain tests with a construct like the following:



if(!fda::CRAN()){
# ... tests to run on other computers but to skip on CRAN.  ...
}


  Obviously, you'll need fda::CRAN.  I found it infeasible to meet 
that requirement and so disabled the tests that violated CRAN's rule on 
this.



  I've been told that this is a suboptimal solution and should be 
avoided.  I agree.



  Hope this helps.
  Spencer Graves



You don't have a lot of control of elapsed time because it will depend 
on what else is happening on the test machine, but if the other times 
are short, usually elapsed time will also be short.


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] some notes

[Spencer Graves]

On 2018-04-24 12:01, Duncan Murdoch wrote:

On 24/04/2018 12:48 PM, Uwe Ligges wrote:



On 24.04.2018 18:45, Spencer Graves wrote:

[... deleting irrelevant stuff...]



    If it becomes infeasible to find smaller datasets, etc., you 
can

cut out certain tests with a construct like the following:


if(!fda::CRAN()){
# ... tests to run on other computers but to skip on CRAN. ...
}


Ummm, how should fda::CRAN() now that it runs on CRAN?

CRAN prefers to ship a set of examples/tests etc. that meet our
requirements. If you want to ru addtional tests and/or examples, then
run them conditionally on something that is true for your local machine,
e.g. some defined environment variable.



  The fda::CRAN() function tests a "defined environmental 
variable", as you suggest:  It is TRUE with "R CMD check –as-cran" and 
FALSE if "-as-cran" (or something like that) is not set.  It has been 
several years since I wrote that code, and I'm not prepared at the 
moment to defend exactly how it works.  It was how I resolved a conflict 
between Jim Ramsay, the maintainer and lead author of "fda", CRAN 
maintainers like Uwe, and other contributors to "fda", especially Giles 
Hooker and me:  It allowed us to keep examples in "fda" help files 
without excessive work trying to find examples that would illustrate the 
same points with less compute time.




For Xubo Yue, who may not be aware of all of the players:

Uwe Ligges is one of the individuals who runs CRAN.  When you submit a 
package to CRAN, you are asking Uwe and others to distribute your 
work. You should listen to what he says.


Spencer Graves and I are not involved in running CRAN.  We will give 
you advice that we think is good advice, but if it conflicts with 
Uwe's, follow his.


Duncan Murdoch



  Moreover, Duncan's contributions to the R Project vastly exceed 
mine.  If any of my suggestions seem to conflict with Duncan's comments, 
follow his (unless they conflict with someone like Uwe, as Duncan noted).



  Spencer Graves

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

Re: [R-pkg-devel] some notes

[Spencer Graves]

On 2018-04-24 12:23, Uwe Ligges wrote:
>
>
> On 24.04.2018 19:15, Spencer Graves wrote:
>>
>>
>> On 2018-04-24 12:01, Duncan Murdoch wrote:
>>> On 24/04/2018 12:48 PM, Uwe Ligges wrote:
>>>>
>>>>
>>>> On 24.04.2018 18:45, Spencer Graves wrote:
>>> [... deleting irrelevant stuff...]
>>>>>
>>>>>
>>>>>     If it becomes infeasible to find smaller datasets, etc., 
>>>>> you can
>>>>> cut out certain tests with a construct like the following:
>>>>>
>>>>>
>>>>> if(!fda::CRAN()){
>>>>> # ... tests to run on other computers but to skip on CRAN. ...
>>>>> }
>>>>
>>>> Ummm, how should fda::CRAN() now that it runs on CRAN?
>>>>
>>>> CRAN prefers to ship a set of examples/tests etc. that meet our
>>>> requirements. If you want to ru addtional tests and/or examples, then
>>>> run them conditionally on something that is true for your local 
>>>> machine,
>>>> e.g. some defined environment variable.
>>
>>
>>    The fda::CRAN() function tests a "defined environmental 
>> variable", as you suggest:  It is TRUE with "R CMD check –as-cran" 
>> and FALSE if "-as-cran" (or something like that)
>
>
> The something like that is rather relevant. For example, I never use 
> --as-cran on my machine, and most CRAN machines do only on incoming 
> check but not the regular daily checks ...


   I very much appreciate your time and effort in maintaining CRAN.  
The precise code used is as follows:


CRAN <- function (CRAN_pattern, n_R_CHECK4CRAN){
     gete <- Sys.getenv()
     ngete <- names(gete)
     i <- seq(along = gete)
     if (missing(CRAN_pattern)) {
     if ("_CRAN_pattern_" %in% ngete) {
     CRAN_pattern <- gete["_CRAN_pattern_"]
     }
     else CRAN_pattern <- "^_R_"
     }
     if (missing(n_R_CHECK4CRAN)) {
     if ("_n_R_CHECK4CRAN_" %in% ngete) {
     n_R_CHECK4CRAN <- as.numeric(gete["_n_R_CHECK4CRAN_"])
     }
     else n_R_CHECK4CRAN <- 5
     }
     for (pati in CRAN_pattern) i <- i[grep(pati, ngete[i])]
     cran. <- (length(i) >= n_R_CHECK4CRAN)
     attr(cran., "Sys.getenv") <- gete
     attr(cran., "matches") <- i
     cran.
}


   This seems to do what I think we both wanted:  not run the longer 
examples on CRAN but still allow them to be run elsewhere. If you want 
something different here, Uwe, please tell me what you want.  If it's 
reasonably easy to implement, I will.


   FYI, I just checked the "CRAN Package Check Results for Package 
fda":  It returned "OK" on 8 of the 12 "flavors", but returned "ERROR" 
on the other four.  NONE of those errors were for excess time.  Instead, 
they were for <>.   The NAMESPACE file for "fda" includes both 
"export(knots.fd)" and "S3method(knots, fd)".


   What should I do about this intermittent error?


   Thanks,
   Spencer

>
> Best,
> Uwe
>  is not set.  It has been
>> several years since I wrote that code, and I'm not prepared at the 
>> moment to defend exactly how it works. It was how I resolved a 
>> conflict between Jim Ramsay, the maintainer and lead author of "fda", 
>> CRAN maintainers like Uwe, and other contributors to "fda", 
>> especially Giles Hooker and me:  It allowed us to keep examples in 
>> "fda" help files without excessive work trying to find examples that 
>> would illustrate the same points with less compute time.
>>
>>>
>>> For Xubo Yue, who may not be aware of all of the players:
>>>
>>> Uwe Ligges is one of the individuals who runs CRAN.  When you submit 
>>> a package to CRAN, you are asking Uwe and others to distribute your 
>>> work. You should listen to what he says.
>>>
>>> Spencer Graves and I are not involved in running CRAN.  We will give 
>>> you advice that we think is good advice, but if it conflicts with 
>>> Uwe's, follow his.
>>>
>>> Duncan Murdoch
>>
>>
>>    Moreover, Duncan's contributions to the R Project vastly 
>> exceed mine.  If any of my suggestions seem to conflict with Duncan's 
>> comments, follow his (unless they conflict with someone like Uwe, as 
>> Duncan noted).
>>
>>
>>    Spencer Graves
>>
>>


[[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 write example results to a tempdir()?

[Spencer Graves]

On 2018-04-26 07:11, Jose A Guijarro wrote:

El 25/04/18 a las 20:21, Duncan Murdoch escribió:

On 25/04/2018 1:32 PM, Sarah Goslee wrote:

Don't change the working directory! That has all kinds of unpleasant
side effects for the unsuspecting user, possibly even more so than
writing to a file.

Instead, write the file to the temp directory, and read it from 
there, with e.g.


wd <- tempdir()
write(dat, file.path(wd, 'Ttest_1981-2000.dat'))

Using file.path() means that the appropriate path delimiter for that
OS will be used.


That's one good way to do it.  But it is possible to change directory 
and change back at the end of the example.  For example,


wd <- tempdir()
savedir <- setwd(wd)

... # the original code that writes and reads in the current dir

setwd(savedir)

There's a worry that an error in the middle of the code will leave 
the user in the wrong place.  If that's really unlikely to happen, 
then this code is a little simpler than Sarah's suggestion.


If it is likely, you can use tryCatch(..., finally = setwd(savedir)), 
but I think Sarah's solution would be preferable in most cases:  many 
users will not understand what tryCatch() does.



Hi, Duncan, et al.:


  Under what circumstances should one also use "on.exit":


wd <- tempdir()
savedir <- setwd(wd)
on.exit(setwd(savedir))?


  Even senior R programmers may miss a failure mode.  In a 
function, this works well:  I don't need to remember to "setwd(savedir)" 
later in the code, which could be a problem if I have multiple exit 
points.  I don't know how it would work in a vignette or the examples 
section of a *.Rd file.  tryCatch(..., finally = setwd(savedir)) 
condenses this into one line ... and is too terse for me in many cases.



  Spencer Graves



Duncan Murdoch


Many thanks for the suggestion! In this way I only need to apply 
slight changes in the examples and can avoid modifying all read/writes 
along the package. I will try this approach and see if it passes the 
CRAN checks.


Jose





Sarah


On Wed, Apr 25, 2018 at 12:30 PM, Jose A Guijarro 
 wrote:

Dear all,

I am struggling to update my package climatol from version 3.0 to 3.1.
The old version had all examples under a "dontrun" section because 
they

needed files created by other examples that the user had to run first.

As this is not acceptable anymore, I made the examples runnable and
prepared small ad-hoc datasets, but then writing files to the user 
space

is against the CRAN policy rules, and I was suggested to run them on a
temporal directory. Therefore I changed all my examples to read/write
files to a tempdir(), as in:

\examples{
#Set a temporal working directory and write input files:
wd <- tempdir()
setwd(wd)
data(Ttest) #(This loads matrix 'dat' and data.frame 'est.c')
write(dat,'Ttest_1981-2000.dat')
write.table(est.c,'Ttest_1981-2000.est',row.names=FALSE,col.names=FALSE) 


rm(dat,est.c) #remove loaded data from memory space
#Now run the example:
dd2m('Ttest',1981,2000)
#Input and output files can be found in directory:
print(wd)
}

But now CRAN checks return this warning ten times (one for every 
example

in the package):

Warning: working directory was changed to ‘/tmp/RtmpWSRK2F’, resetting

Any hint on how to solve the problem will be highly appreciated...

Jose








__
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] Submission to CRAN when package needs personal data (API key)

[Spencer Graves]

The fda package disables some tests on CRAN using:


if(!fda::CRAN()){
    test you don't want run on CRAN
}


  I've used this in other contexts with tests that are too long to 
run on CRAN but that I want to run otherwise during "R CMD check".



  Spencer Graves


On 2018-09-05 12:13, Peter Meissner wrote:

Hey,

Maybe webmockr (or something alike) can help:
https://cran.r-project.org/web/packages/webmockr/index.html

Best, Peter

Rainer M Krug  schrieb am Mi., 5. Sep. 2018, 15:38:


OK - thanks. I will than disable the checks for CRAN.

Thanks,

Rainer



On 5 Sep 2018, at 15:37, Uwe Ligges 

wrote:

You should not run on CRAN. Note that the checks are done almost daily

oin several platforms, hence the API key is used for about 10 check runs a
day.

Best,
Uwe Ligges



On 05.09.2018 09:28, Rainer Krug wrote:

Hi
I have a package at GitHub (https://github.com/rkrug/ROriginStamp)

which I am pre[paring for CRAN.

It creates a trusted timestamp using the API fro OriginStamp (

https://originstamp.org/home) which requires an API key. Now this API
should not be made public, as to much traffic through one API key will lead
to it’s blocking.

I have stored the key encrypted in the travis.yml, and the package

passes all tests.

But if I send it to CRAN, it would fail the tests, as the api key is

not in the package itself.

I could disable all tests for CRAN which need the API key, but I think

it would be better tu run the tests there as well (as an additional check
to travis).

My question:
Is there a way of storing the API key encrypted, so that only the CRAN

test servers can decrypt it, or is there another way can steal with this?

Thanks,
Rainer
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation

Biology, UCT), Dipl. Phys. (Germany)

University of Zürich
Cell:   +41 (0)78 630 66 57
email:  rai...@krugs.de
Skype:  RMkrug
PGP: 0x0F52F982
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

University of Zürich

Cell:   +41 (0)78 630 66 57
email:  rai...@krugs.de
Skype:  RMkrug

PGP: 0x0F52F982



__
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] Submission to CRAN when package needs personal data (API key)

[Spencer Graves]

On 2018-09-05 12:52, Gábor Csárdi wrote:

On Wed, Sep 5, 2018 at 6:34 PM Spencer Graves
 wrote:

The fda package disables some tests on CRAN using:


if(!fda::CRAN()){
  test you don't want run on CRAN
}

Seemingly this just checks for a couple of (5 by default) environment
variables that match "^_R_":
https://github.com/cran/fda/blob/0549e6a86aa144d8c2aade2d8704a269fb8a94ed/R/CRAN.R#L14

I am not sure if this is a good indication of the machine being a CRAN
machine, I do set  some of these
occasionally on my machine.  It would be great if CRAN machines could
set a specific environment
variable globally, e.g. ON_CRAN, or _R_ON_CRAN_, so people could skip
these tests and examples
easily.



Agreed.  Before I wrote that function, I asked this list for 
suggestions.  The suggestion I got was, "Don't do it."  I felt that was 
not acceptable so wrote what I did.  I think we need a better solution.  
Spencer


Gabor



I've used this in other contexts with tests that are too long to
run on CRAN but that I want to run otherwise during "R CMD check".


Spencer Graves


On 2018-09-05 12:13, Peter Meissner wrote:

Hey,

Maybe webmockr (or something alike) can help:
https://cran.r-project.org/web/packages/webmockr/index.html

Best, Peter

Rainer M Krug  schrieb am Mi., 5. Sep. 2018, 15:38:


OK - thanks. I will than disable the checks for CRAN.

Thanks,

Rainer



On 5 Sep 2018, at 15:37, Uwe Ligges 

wrote:

You should not run on CRAN. Note that the checks are done almost daily

oin several platforms, hence the API key is used for about 10 check runs a
day.

Best,
Uwe Ligges



On 05.09.2018 09:28, Rainer Krug wrote:

Hi
I have a package at GitHub (https://github.com/rkrug/ROriginStamp)

which I am pre[paring for CRAN.

It creates a trusted timestamp using the API fro OriginStamp (

https://originstamp.org/home) which requires an API key. Now this API
should not be made public, as to much traffic through one API key will lead
to it’s blocking.

I have stored the key encrypted in the travis.yml, and the package

passes all tests.

But if I send it to CRAN, it would fail the tests, as the api key is

not in the package itself.

I could disable all tests for CRAN which need the API key, but I think

it would be better tu run the tests there as well (as an additional check
to travis).

My question:
Is there a way of storing the API key encrypted, so that only the CRAN

test servers can decrypt it, or is there another way can steal with this?

Thanks,
Rainer
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation

Biology, UCT), Dipl. Phys. (Germany)

University of Zürich
Cell:   +41 (0)78 630 66 57
email:  rai...@krugs.de
Skype:  RMkrug
PGP: 0x0F52F982
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

University of Zürich

Cell:   +41 (0)78 630 66 57
email:  rai...@krugs.de
Skype:  RMkrug

PGP: 0x0F52F982



__
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


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

Re: [R-pkg-devel] Submission to CRAN when package needs personal data (API key)

[Spencer Graves]

On 2018-09-07 01:18, David Hugh-Jones wrote:

On Fri, 7 Sep 2018 at 01:16, Duncan Murdoch 
wrote:



When packages delete tests just for CRAN, the quality of the repository
suffers.  Users should be able to check an install by running the tests
that passed on CRAN and seeing them pass on their system as well.


In my limited experience there are usually tests that can't run on CRAN
  because they take too long, rely on external software or configuration
that is absent, or just fail on CRAN only (which is naturally hard to
debug). This seems normal, and having the ability to turn off some tests is
useful. The fact that multiple workarounds have evolved to do this suggests
that the need is widespread.



  Almost a decade ago I was told that certain tests in the fda 
package took too much time on CRAN.  I was NOT going to hammer on my 
co-authors to make those tests shorter.  I was happy I got those tests 
at all!  So I wrote fda::CRAN() and for those tests that took too long, 
I wrapped them in



if(!CRAN()){
  (tests that took too long to run on CRAN)
}


  I did it after being told repeatedly, (a) you cannot run those 
tests on CRAN, and (b) you should not use that function "CRAN()"! Since 
then, I've had other occasions to use it.



  Spencer Graves



--

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] Submission to CRAN when package needs personal data (API key)

[Spencer Graves]

On 2018-09-07 12:10, Duncan Murdoch wrote:


...


I would guess because it can’t. If there would be a standardised way 
of identifying that the test is run on CRAN, I would use this 
immediately.


Then your package would fail when I ran the tests, because I don't 
have an API key, and I am not CRAN.  It makes more sense to me to 
treat CRAN the same as any other user who is not the author.



RAINER:  Have you considered writing your time stamp code so it takes it 
from originstamp if it's available, and if not switches to some other 
external source if there is an Internet connection, and then from date() 
otherwise -- with an appropriate warning if it doesn't come from 
originstamp?  You can have an option that the user can set if s/he wants 
an error rather than a warning if originstamp is not available.  Then 
people can use your package without worrying about getting an API key:  
That's optional.



  Spencer Graves



Duncan Murdoch



Cheers,

Rainer




Duncan Murdoch

__
R-package-devel@r-project.org 
<mailto:R-package-devel@r-project.org>mailing list

https://stat.ethz.ch/mailman/listinfo/r-package-devel


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


University of Zürich

Cell:       +41 (0)78 630 66 57
email:      rai...@krugs.de <mailto: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] Submission to CRAN when package needs personal data (API key)

[Spencer Graves]

On 2018-09-08 14:02, Joshua Ulrich wrote:

Hi Rainer,

On Wed, Sep 5, 2018 at 2:28 AM, Rainer Krug  wrote:

Hi

I have a package at GitHub (https://github.com/rkrug/ROriginStamp) which I am
pre[paring for CRAN.

It creates a trusted timestamp using the API fro OriginStamp
(https://originstamp.org/home) which requires an API key. Now this API should
not be made public, as to much traffic through one API key will lead to it’s
blocking.

I have stored the key encrypted in the travis.yml, and the package passes all
tests.

But if I send it to CRAN, it would fail the tests, as the api key is not in
the package itself.

I could disable all tests for CRAN which need the API key, but I think it
would be better tu run the tests there as well (as an additional check to
travis).

My question:

Is there a way of storing the API key encrypted, so that only the CRAN test
servers can decrypt it, or is there another way can steal with this?


I have a similar issue with quantmod.  I need API keys to test some
functionality and I would like the tests run regularly, so I can know
when something breaks without having to wait for a user to report the
change.

I store the API keys in encrypted environment variable in TravisCI,
and I check for those environment variables before running the tests
that require them.

Then I added a cron job on TravisCI to run the build if there hasn't
been a build in the past 24 hours.  That solves the problem adequately
for my purposes without adding any burden to CRAN.  Hopefully it works
for your purposes too.



  So those tests don't run if the required environment variables 
are not there?



  Rainer's problem was getting a secure time stamp.  For his case, 
rather than skip the tests if the API keys were not there, one might 
take the time stamp from someplace else, perhaps with a note of the 
source of the time stamp.



  Spencer


Best,
Josh


Thanks,

Rainer



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

University of Zürich

Cell:   +41 (0)78 630 66 57
email:  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] Package Etiquette

[Spencer Graves]

On 2018-09-09 09:30, Dirk Eddelbuettel wrote:

Hi Joseph,

On 8 September 2018 at 21:11, Joseph Wood wrote:
| I’m a new developer and this is my first post. I have a question regarding
| package development with regards to duplication of functionality. I read
| the posting guide (https://www.r-project.org/posting-guide.html) and didn’t
| see anything addressing this.



  I wrote and use sos::findFn to find other packages and functions 
that seem to do the same or similar things.  A search for software and 
books on splines led to an invitation to help maintain and improve the 
"fda" package, and then to another invitation to collaborate on a book 
on "Functional data analysis with R and Matlab".  Another search got me 
named the maintainer of the "Ecdat" package, in which I've since fixed 
bugs while adding my own material.



  Other searches led to functions in other packages I use in the 
FinTS package.  For that, I use, cite, and compare similar functions in 
other packages.  My philosophy, like Dirk's I think, is that if someone 
else has a function that seems to do what I want, I'd rather let them 
maintain it.  I will copy it only if I really need something different 
that they don't provide and don't want to provide.  If I copied 
something otherwise, the two copies would likely eventually get out of 
sync.  Then other users (and I myself) would have trouble determining 
which version to use.  What a mess. I'll let an existing package author 
worry about maintaining what s/he has already written and maintained.  I 
can worry about other things.



  Hope this helps.
  Spencer Graves


I sense that by actually asking the question (good move!) you already have an
inkling about the answer.  So indeed, _ex ante_ and with the caveat about
missing details and not knowing more: it is generally a bad thing.

Every now and then we manage to avoid it.  Eg I once had an (incomplete and
tentative but functional) package to have R interface the (awesome !!)
MessagePack binary serialization format (using C++ via Rcpp).  Then I spotted
a new package by Travers doing very similar things (in broader scope) via
R. So I suggested we joing forces, we did and the resulting package is much
better. So much so that we wrote a (not yet complete) paper about it too.

But it is a complex topic, and sometimes we need different approaches. And
the best person to ask may be the maintainer of the package you aim to
extend.

The best answer may be in the _Writing R Extensions_ manual that came with
your copy of R.  It is the only "official" manual for package development.

| Is this the right place to ask?

Quite possibly, as it is the list about package development. Some more
pertinent detail may help, and as mentioned, maybe first talking to the
maintainer may not be a bad idea.

But to close: it is not formally forbidden, and duplication _happens_.  Good
judgement always helps, sometimes good judgement is informed by observing
best (prior) practice. And/or by asking here.

Hope this helps, Dirk



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

[R-pkg-devel] DLL 'Matrix' not found: maybe not installed for this architecture?

[Spencer Graves]

Hello:


 � "00check.log" produced by R-devel winbuilder (link below) 
includes the following:


** checking whether the package can be loaded ... ERROR
Loading this package had a fatal error status code 1
Loading log:
Error: package or namespace load failed for 'Ecfun' in 
library.dynam(lib, package, package.lib):
 �DLL 'Matrix' not found: maybe not installed for this architecture?
In addition: Warning message:
S3 methods 'print.sparseSummary', 'print.diagSummary', 'c.abIndex', 
'c.sparseVector', 'as.array.Matrix', 'as.array.sparseVector', 
'as.matrix.Matrix', 'as.matrix.sparseVector', 'as.vector.Matrix', 
'as.vector.sparseVector' were declared in NAMESPACE but not found
Execution halted


 � Is this problem with R-devel winbuilder or me?


 � This is for Ecfun on R-Forge that passed their standard tests 
plus on R 3.5.2 on macOS Mojave 10.14.3.


 � Thanks,
 � Spencer Graves


 Forwarded Message 
Subject:winbuilder: Package Ecfun_0.2-0.tar.gz has been checked and 
built
Date:   Mon, 25 Feb 2019 04:08:22 +0100
From:   lig...@statistik.tu-dortmund.de
To: spencer.gra...@effectivedefense.org
CC: lig...@statistik.tu-dortmund.de



Dear package maintainer,
this notification has been generated automatically.
Your package Ecfun_0.2-0.tar.gz has been built (if working) and checked 
for Windows.
Please check the log files and (if working) the binary package at:
https://win-builder.r-project.org/a5a1hg7XRQIO
The files will be removed after roughly 72 hours.
Installation time in seconds: 23
Check time in seconds: 56
Status: 1 ERROR
R Under development (unstable) (2019-02-24 r76155)
All the best,
Uwe Ligges
(CRAN maintainer of binary packages for Windows)



[[alternative HTML version deleted]]

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

[R-pkg-devel] clang: error: unsupported option '-fopenmp'

[Spencer Graves]

Hello, All:


  I'm getting "clang: error: unsupported option '-fopenmp'" when 
trying to build "https://github.com/helske/bssm"; under macOS 10.14.14 
with R 3.6.0;  see below.



  What do you suggest?


  Thanks,
  Spencer Graves


p.s.  I assume I have to install compiler(s).  However, I've so far been 
unable to find instructions that are sufficiently current to convince me 
I might not do more harm than good following them.



> R CMD build bssm
* checking for file ‘bssm/DESCRIPTION’ ... OK
* preparing ‘bssm’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
  ---
* installing *source* package ‘bssm’ ...
** using staged installation
** libs
clang++ -std=gnu++11 
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG 
-I"/Library/Frameworks/R.framework/Versions/3.6/Resources/library/BH/include" 
-I"/Library/Frameworks/R.framework/Versions/3.6/Resources/library/Rcpp/include" 
-I"/Library/Frameworks/R.framework/Versions/3.6/Resources/library/RcppArmadillo/include" 
-I"/Library/Frameworks/R.framework/Versions/3.6/Resources/library/ramcmc/include" 
-I"/Library/Frameworks/R.framework/Versions/3.6/Resources/library/sitmo/include" 
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk 
-I/usr/local/include -fopenmp -fPIC  -Wall -g -O2  -c R_approx.cpp -o 
R_approx.o

clang: error: unsupported option '-fopenmp'
make: *** [R_approx.o] Error 1
ERROR: compilation failed for package ‘bssm’
* removing 
‘/private/var/folders/mh/mrm_14nx19g13lsnj9zmvwjrgn/T/RtmppA2gBg/Rinst24427c5cbfeb/bssm’

  ---
ERROR: package installation failed

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

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

[Spencer Graves]

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

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

[Spencer Graves]

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

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

[Spencer Graves]

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

[Spencer Graves]

  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

[R-pkg-devel] unable to run 'make clean' in 'src'

[Spencer Graves]

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

Re: [R-pkg-devel] unable to run 'make clean' in 'src'

[Spencer Graves]

Hi, Georgi et al.:


  Thanks to Georgi, I changed my path.  That led me to a different 
error.  A search for the new error led me to:



https://thecoatlessprofessor.com/programming/cpp/installing-rtools-for-compiled-code-via-rcpp/


That recommended:


install.packages("installr")
library("installr")
install.Rtools()


  I uninstalled Rtools, then installed them using this, and that 
problem disappeared.  Now I'm dealing with '"pdflatex" not found". I'll 
discuss that in a new thread.



  Thanks,
  Spencer Graves


On 2019-09-18 06:30, Georgi Boshnakov wrote:

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

[R-pkg-devel] Warning in system2(..., stdout = FALSE, stderr = FALSE) :, '"pdflatex"' not found

[Spencer Graves]

Hello, All:


   What's the recommended way to get pdflatex installed on Windows 
10 to run "R CMD"?


   I ask, because "R CMD build bssm" under Windows 10 produced 
'Warning in system2(..., stdout = FALSE, stderr = FALSE) : '"pdflatex"' 
not found'.


   This was after installing Rtools using the following (recommended 
by 
"https://thecoatlessprofessor.com/programming/cpp/installing-rtools-for-compiled-code-via-rcpp/";):
 



install.packages("installr")
library("installr")
install.Rtools()


   Below please find the output in a commands window including 
"sessionInfo()".


       Thanks,
       Spencer Graves


 >R CMD build bssm
* checking for file 'bssm/DESCRIPTION' ... OK
* preparing 'bssm':
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
* creating vignettes ... ERROR
--- re-building 'bssm.Rmd' using rmarkdown
[WARNING] Note with key '1' defined at line 318 column 1 but not used.
Warning in system2(..., stdout = FALSE, stderr = FALSE) :
   '"pdflatex"' not found
Error: processing vignette 'bssm.Rmd' failed with diagnostics:
Failed to compile bssm.tex. See https://yihui.name/tinytex/r/#debugging 
for debugging tips.
--- failed re-building 'bssm.Rmd'

--- re-building 'growth_model.Rmd' using rmarkdown
Warning in system2(..., stdout = FALSE, stderr = FALSE) :
   '"pdflatex"' not found
Error: processing vignette 'growth_model.Rmd' failed with diagnostics:
Failed to compile growth_model.tex. See 
https://yihui.name/tinytex/r/#debugging for debugging tips.
--- failed re-building 'growth_model.Rmd'

SUMMARY: processing the following files failed:
   'bssm.Rmd' 'growth_model.Rmd'

Error: Vignette re-building failed.
Execution halted

C:\Users\spenc\Documents\R\bssm\bssm>
C:\Users\spenc\Documents\R\bssm\bssm>pdflatex
'pdflatex' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\spenc\Documents\R\bssm\bssm>r

R version 3.6.1 (2019-07-05) -- "Action of the Toes"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

   Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

 > sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18362)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

loaded via a namespace (and not attached):
[1] compiler_3.6.1

[[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 in system2(..., stdout = FALSE, stderr = FALSE) :, '"pdflatex"' not found

[Spencer Graves]

Update:  A web search for 'installing pdflatex for "R CMD" on Windows 
10?' suggested I install MiKTeX.  I did that from miktex.org, and it got 
me past that error.  Spencer



On 2019-09-19 01:50, Spencer Graves wrote:

Hello, All:


  What's the recommended way to get pdflatex installed on Windows
10 to run "R CMD"?


  I ask, because "R CMD build bssm" under Windows 10 produced
'Warning in system2(..., stdout = FALSE, stderr = FALSE) : '"pdflatex"'
not found'.


  This was after installing Rtools using the following (recommended
by
"https://thecoatlessprofessor.com/programming/cpp/installing-rtools-for-compiled-code-via-rcpp/";):



install.packages("installr")
library("installr")
install.Rtools()


  Below please find the output in a commands window including
"sessionInfo()".


      Thanks,
      Spencer Graves


>R CMD build bssm
* checking for file 'bssm/DESCRIPTION' ... OK
* preparing 'bssm':
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
* creating vignettes ... ERROR
--- re-building 'bssm.Rmd' using rmarkdown
[WARNING] Note with key '1' defined at line 318 column 1 but not used.
Warning in system2(..., stdout = FALSE, stderr = FALSE) :
  '"pdflatex"' not found
Error: processing vignette 'bssm.Rmd' failed with diagnostics:
Failed to compile bssm.tex. See https://yihui.name/tinytex/r/#debugging
for debugging tips.
--- failed re-building 'bssm.Rmd'

--- re-building 'growth_model.Rmd' using rmarkdown
Warning in system2(..., stdout = FALSE, stderr = FALSE) :
  '"pdflatex"' not found
Error: processing vignette 'growth_model.Rmd' failed with diagnostics:
Failed to compile growth_model.tex. See
https://yihui.name/tinytex/r/#debugging for debugging tips.
--- failed re-building 'growth_model.Rmd'

SUMMARY: processing the following files failed:
  'bssm.Rmd' 'growth_model.Rmd'

Error: Vignette re-building failed.
Execution halted

C:\Users\spenc\Documents\R\bssm\bssm>
C:\Users\spenc\Documents\R\bssm\bssm>pdflatex
'pdflatex' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\spenc\Documents\R\bssm\bssm>r

R version 3.6.1 (2019-07-05) -- "Action of the Toes"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18362)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

loaded via a namespace (and not attached):
[1] compiler_3.6.1

[[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] Warning in system2(..., stdout = FALSE, stderr = FALSE) :, '"pdflatex"' not found

[Spencer Graves]

On 2019-09-19 12:19, Tomas Kalibera wrote:

On 9/19/19 6:29 AM, Spencer Graves wrote:
Update: A web search for 'installing pdflatex for "R CMD" on Windows 
10?' suggested I install MiKTeX.  I did that from miktex.org, and it 
got me past that error.  Spencer


Please note these things are documented in R Installation and 
Administration Manual (see Appendix D)



  Thanks for documenting this.  It's important to have that as part 
of this thread.



  I perhaps should have thought to look there, but I didn't. And 
the web searches I tried didn't lead me there.   Spencer




Best
Tomas



On 2019-09-19 01:50, Spencer Graves wrote:

Hello, All:


  What's the recommended way to get pdflatex installed on Windows
10 to run "R CMD"?


  I ask, because "R CMD build bssm" under Windows 10 produced
'Warning in system2(..., stdout = FALSE, stderr = FALSE) : '"pdflatex"'
not found'.


  This was after installing Rtools using the following (recommended
by
"https://thecoatlessprofessor.com/programming/cpp/installing-rtools-for-compiled-code-via-rcpp/";): 





install.packages("installr")
library("installr")
install.Rtools()


  Below please find the output in a commands window including
"sessionInfo()".


      Thanks,
      Spencer Graves


>R CMD build bssm
* checking for file 'bssm/DESCRIPTION' ... OK
* preparing 'bssm':
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
* creating vignettes ... ERROR
--- re-building 'bssm.Rmd' using rmarkdown
[WARNING] Note with key '1' defined at line 318 column 1 but not used.
Warning in system2(..., stdout = FALSE, stderr = FALSE) :
  '"pdflatex"' not found
Error: processing vignette 'bssm.Rmd' failed with diagnostics:
Failed to compile bssm.tex. See https://yihui.name/tinytex/r/#debugging
for debugging tips.
--- failed re-building 'bssm.Rmd'

--- re-building 'growth_model.Rmd' using rmarkdown
Warning in system2(..., stdout = FALSE, stderr = FALSE) :
  '"pdflatex"' not found
Error: processing vignette 'growth_model.Rmd' failed with diagnostics:
Failed to compile growth_model.tex. See
https://yihui.name/tinytex/r/#debugging for debugging tips.
--- failed re-building 'growth_model.Rmd'

SUMMARY: processing the following files failed:
  'bssm.Rmd' 'growth_model.Rmd'

Error: Vignette re-building failed.
Execution halted

C:\Users\spenc\Documents\R\bssm\bssm>
C:\Users\spenc\Documents\R\bssm\bssm>pdflatex
'pdflatex' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\spenc\Documents\R\bssm\bssm>r

R version 3.6.1 (2019-07-05) -- "Action of the Toes"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18362)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

loaded via a namespace (and not attached):
[1] compiler_3.6.1

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

[R-pkg-devel] incomplete final line found on 'growth_model.log'

[Spencer Graves]

   "R CMD build bssm" on a Windows 10 machine ends by complaining, 
"  incomplete final line found on 'growth_model.log'". This problem was 
not fixed by adding a couple of blank lines to 'growth_model.Rmd'.


   Suggestions?
   Thanks,
   Spencer Graves


p.s.  The same command worked fine on a Windows 7 computer.  The "bssm" 
package used here was cloned from 
""https://github.com/sbgraves237/bssm":  This is not identical to 
helski/bssm, but close.


*EXCERPT FROM CMD: *


...
* creating vignettes ... ERROR
--- re-building 'bssm.Rmd' using rmarkdown
[WARNING] Note with key '1' defined at line 318 column 1 but not used.
--- finished re-building 'bssm.Rmd'

--- re-building 'growth_model.Rmd' using rmarkdown
Warning in readLines(log) :
   incomplete final line found on 'growth_model.log'
Error: processing vignette 'growth_model.Rmd' failed with diagnostics:
Failed to compile growth_model.tex. See 
https://yihui.name/tinytex/r/#debugging for debugging tips.
--- failed re-building 'growth_model.Rmd'

SUMMARY: processing the following file failed:
   'growth_model.Rmd'

Error: Vignette re-building failed.
Execution halted


*PLFLATEX.LOG


*2019-09-19 08:11:08,435-0500 INFO  pdflatex - starting with command 
line: C:\PROGRA~1\MIKTEX~1.9\miktex\bin\x64\pdflatex.exe -halt-on-error 
-interaction=batchmode bssm.tex
2019-09-19 08:11:08,435-0500 WARN  pdflatex - running with administrator 
privileges
2019-09-19 08:11:08,450-0500 INFO  pdflatex - running 'initexmf' to 
refresh the file name database
2019-09-19 08:11:13,734-0500 INFO  pdflatex - running 'initexmf' to 
create font map files
2019-09-19 08:11:22,735-0500 INFO  pdflatex - allowing known shell commands
2019-09-19 08:11:22,735-0500 INFO  pdflatex - enabling input (output) 
from (to) processes
2019-09-19 08:11:22,798-0500 INFO  pdflatex - going to create file: 
pdflatex.fmt
2019-09-19 08:11:31,033-0500 FATAL pdflatex - GUI framework cannot be 
initialized.
2019-09-19 08:11:31,033-0500 FATAL pdflatex - Info:
2019-09-19 08:11:31,033-0500 FATAL pdflatex - Source: 
Libraries\MiKTeX\UI\Qt\mikuiqt.cpp
2019-09-19 08:11:31,033-0500 FATAL pdflatex - Line: 77
2019-09-19 08:11:31,033-0500 INFO  pdflatex - finishing with exit code 1
2019-09-19 08:12:53,079-0500 INFO  pdflatex - starting with command 
line: C:\PROGRA~1\MIKTEX~1.9\miktex\bin\x64\pdflatex.exe -halt-on-error 
-interaction=batchmode growth_model.tex
2019-09-19 08:12:53,079-0500 WARN  pdflatex - running with administrator 
privileges
2019-09-19 08:12:53,079-0500 INFO  pdflatex - allowing known shell commands
2019-09-19 08:12:53,079-0500 INFO  pdflatex - enabling input (output) 
from (to) processes
2019-09-19 08:12:53,392-0500 FATAL pdflatex - GUI framework cannot be 
initialized.
2019-09-19 08:12:53,392-0500 FATAL pdflatex - Info:
2019-09-19 08:12:53,392-0500 FATAL pdflatex - Source: 
Libraries\MiKTeX\UI\Qt\mikuiqt.cpp
2019-09-19 08:12:53,392-0500 FATAL pdflatex - Line: 77
2019-09-19 08:12:53,392-0500 INFO  pdflatex - finishing with exit code 1
2019-09-19 13:15:45,812-0500 INFO  pdflatex - starting with command 
line: C:\PROGRA~1\MIKTEX~1.9\miktex\bin\x64\pdflatex.exe -halt-on-error 
-interaction=batchmode growth_model.tex
2019-09-19 13:15:45,815-0500 WARN  pdflatex - running with administrator 
privileges
2019-09-19 13:15:45,819-0500 INFO  pdflatex - allowing known shell commands
2019-09-19 13:15:45,819-0500 INFO  pdflatex - enabling input (output) 
from (to) processes
2019-09-19 13:15:46,231-0500 FATAL pdflatex - GUI framework cannot be 
initialized.
2019-09-19 13:15:46,231-0500 FATAL pdflatex - Info:
2019-09-19 13:15:46,231-0500 FATAL pdflatex - Source: 
Libraries\MiKTeX\UI\Qt\mikuiqt.cpp
2019-09-19 13:15:46,231-0500 FATAL pdflatex - Line: 77
2019-09-19 13:15:46,231-0500 INFO  pdflatex - finishing with exit code 1
2019-09-19 13:22:55,302-0500 INFO  pdflatex - starting with command 
line: C:\PROGRA~1\MIKTEX~1.9\miktex\bin\x64\pdflatex.exe -halt-on-error 
-interaction=batchmode growth_model.tex
2019-09-19 13:22:55,302-0500 WARN  pdflatex - running with administrator 
privileges
2019-09-19 13:22:55,302-0500 INFO  pdflatex - allowing known shell commands
2019-09-19 13:22:55,302-0500 INFO  pdflatex - enabling input (output) 
from (to) processes
2019-09-19 13:22:55,640-0500 FATAL pdflatex - GUI framework cannot be 
initialized.
2019-09-19 13:22:55,640-0500 FATAL pdflatex - Info:
2019-09-19 13:22:55,640-0500 FATAL pdflatex - Source: 
Libraries\MiKTeX\UI\Qt\mikuiqt.cpp
2019-09-19 13:22:55,640-0500 FATAL pdflatex - Line: 77
2019-09-19 13:22:55,641-0500 INFO  pdflatex - finishing with exit code 1
2019-09-19 13:22:56,136-0500 INFO  pdflatex - starting with command 
line: C:\PROGRA~1\MIKTEX~1.9\miktex\bin\x64\pdflatex.exe -halt-on-error 
-interaction=batchmode growth_model.tex
2019-09-19 13:22:56,139-0500 WARN  pdflatex - running wi

[R-pkg-devel] How to submit to CRAN from GitHub?

[Spencer Graves]

Hello:


   Two questions:


HOW TO SUBMIT TO CRAN FROM GITHUB:  Is there a standard method for 
submitting to CRAN from GitHub?  (There's a simple protocol for 
submitting to CRAN from R-Forge, but I've experienced insurmountable 
problems using R-Forge recently.)


PACKAGE STILL FAILING TRAVIS CI:  The latest report from 
bui...@travis-ci.org on my Ecdat package for R on GitHub ends with 
"Found warnings, treating as errors (as requested)."  The word "warning" 
appears in that report over 100 times.  I didn't see anything there that 
suggested to me anything I understand how to change.


NOTE:  "R CMD build Ecdat --resave-data" followed by "R CMD check 
Ecdat_0.3.3-tar.gz" completed with no errors, warnings or notes under 
macOS 10.14.6 and Windows 7 and 10.


   Thanks,
   Spencer Graves


 Forwarded Message 
Subject:Still Failing: sbgraves237/Ecdat#9 (master - c680f08)
Date:   Sun, 22 Sep 2019 15:21:08 +
From:   Travis CI 
To: spencer.gra...@effectivedefense.org



sbgraves237

/

Ecdat

<https://travis-ci.org/sbgraves237/Ecdat?utm_medium=notification&utm_source=email>
 


branch iconmaster <https://github.com/sbgraves237/Ecdat/tree/master>

build has failed
Build #9 is still failing 
<https://travis-ci.org/sbgraves237/Ecdat/builds/588124072?utm_medium=notification&utm_source=email>
arrow to build time
clock icon5 mins and 8 secs

sbgraves237 avatarsbgraves237

c680f08 CHANGESET → 
<https://github.com/sbgraves237/Ecdat/compare/cd2bdef45642...c680f08d04b8>

roll date

Want to know about upcoming build environment updates?

Would you like to stay up-to-date with the upcoming Travis CI build 
environment updates? We set up a mailing list for you!

SIGN UP HERE <http://eepurl.com/9OCsP>

book icon

Documentation <https://docs.travis-ci.com/> about Travis CI

Have any questions? We're here to help. <mailto:supp...@travis-ci.com>
Unsubscribe 
<https://travis-ci.org/account/preferences/unsubscribe?repository=25157200&utm_medium=notification&utm_source=email>
 
from build emails from the sbgraves237/Ecdat repository.
To unsubscribe from *all* build emails, please update your settings 
<https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email>.
 

black and white travis ci logo <https://travis-ci.com>

Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy 
Jacops | Contact: cont...@travis-ci.com <mailto:cont...@travis-ci.com> | 
Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß 
§27 a Umsatzsteuergesetz: DE282002648


[[alternative HTML version deleted]]

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

[R-pkg-devel] devtools::build_win()?

[Spencer Graves]

Hello:


  Hadley Wickham's otherwise wonderful "R packages" book recommends 
using "devtools::build_win()" in the "Test environments" section of his 
chapter on "Releasing a package".  However, devtools 2.2.1, which seems 
to be the current version, contains no such "build_win" function.



  This section of "R packages" also says, says that 
"devtools::revdep_check()" "Runs R CMD check on each [reverse 
dependency] and Summarises the results in a single file."  However, the 
current version of "devtools::revdep_check()" seems only to identify the 
reverse dependencies without testing them.



  That do you suggest?
  Thanks,
  Spencer Graves

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

Re: [R-pkg-devel] compression of vignettes

[Spencer Graves]

  I encountered this or a similar problem with 
"https://github.com/sbgraves237/Ecfun/blob/master/vignettes/time2nextNuclearWeaponState.Rmd";. 
I tried both "R CMD build Ecfun" and R CMD build Ecfun 
--compact-vignettes".  With both, "R CMD check Ecfun_0.2-2.tar.gz" 
included the following:



* checking installed package size ... NOTE
  installed size is  7.2Mb
  sub-directories of 1Mb or more:
    doc   6.6Mb


  Suggestions?
  Thanks,
  Spencer Graves


On 2019-11-21 11:43, Dirk Eddelbuettel wrote:

On 21 November 2019 at 16:43, Joris Meys wrote:
| The workflow as described in the manual :
| 
https://cran.r-project.org/doc/manuals/R-exts.html#Checking-and-building-packages

|
| is as follows :
|
| R CMD build pkg --compact-vignettes
| R CMD check pkg_x.y.z.tar.gz --as-cran
|
| In a basic Travis script this can be used as:
|
| script:
| - R CMD build . --compact-vignettes=gs+qpdf
| - R CMD check *tar.gz --as-cran
|
| You find more information here : 
https://towardsdatascience.com/travis-ci-for-r-advanced-guide-719cb2d9e0e5


You can also call the base R helper functions directly.

I like having simple command-line wrapper, so I added one to `littler` 
which

I can call as `compactpdf.r`. All it does (besides argument checking) is
loop over either the given pdf files (or those found in the current
directory) to then call

tools::compactPDF(f, gs_quality="ebook")

for each of them. That way you can simply compare 'before' and 'after'.

Similarly, I made compacting an option to the rendering script 
`render.r` I

often call directly from my editor when working on markdown files.

Dirk



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

[R-pkg-devel] default col.names from data.frame not the same as as.data.frame

[Spencer Graves]

Hello, All:


  What names should be given a matrix or data.frame that does not 
have names for use in "glm.fit"?



  I ask for two reasons:


        * "base" R is inconsistent:  "data.frame(matrix(1:2, 1))" 
defaults to "X1", "X2" but "as.data.frame(matrix(1:2, 1))" defaults to 
"V1", "V2".



        * I want to use a toy example like this in the 
documentation for "BMA:::bic.glm.matrix" and "BMA:::bic.glm.data.frame", 
and since "base" R is inconsistent, I felt a need to ask a group like 
this for their preferences.



  Thanks,
  Spencer Graves

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

[R-pkg-devel] How to create a new project on GitHub?

[Spencer Graves]

Hello, All:


  How can I create a new project within my GitHub account 
(https://github.com/sbgraves237/)?



  I'm trying to follow "http://r-pkgs.had.co.nz/git.html":


...
Synchronising with GitHub
...

    Open a shell, then follow the instructions on the new repo page. 
They’ll look something like this:


    git remote add origin g...@github.com:hadley/r-pkgs.git
    git push -u origin master

I tried:

...$ git remote add origin g...@github.com:sbgraves237/fda.git
...$ git push -u origin master
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


*** That didn't work, so I tried


...$ git remote add origin https://[my ssh code]@github.com/sbgraves237/fda
fatal: remote origin already exists.
...$ git push -u origin master
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


  *** What do I need to do to fix the mess I seem to have created 
and get what I want?



  *** Thanks, Spencer Graves


p.s.  If you know the fda package, you know that James Ramsay is the 
primary author, and I'm one of his long-time collaborators.  He has a 
new version he wants to clean up and submit to CRAN, and I'm trying to 
help him.  Thanks.  sg


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

Re: [R-pkg-devel] How to create a new project on GitHub?

[Spencer Graves]

On 2020-01-15 17:18, Gábor Csárdi wrote:

Seems like you skipped step 1?

"1. Create a new repo on GitHub: https://github.com/new. Give it the
same name as your package, and include the package title as the repo
description. Leave all the other options as is, then click Submit."

Gabor



  Thanks.  I now have "https://github.com/sbgraves237/fda";. Then I 
did "git push --set-upstream origin master", and it seemed to work.



  Thanks again.
  Spencer


On Wed, Jan 15, 2020 at 11:15 PM Spencer Graves
 wrote:

Hello, All:


How can I create a new project within my GitHub account
(https://github.com/sbgraves237/)?


I'm trying to follow "http://r-pkgs.had.co.nz/git.html":


...
Synchronising with GitHub
...

  Open a shell, then follow the instructions on the new repo page.
They’ll look something like this:

  git remote add origin g...@github.com:hadley/r-pkgs.git
  git push -u origin master

I tried:

...$ git remote add origin g...@github.com:sbgraves237/fda.git
...$ git push -u origin master
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


*** That didn't work, so I tried


...$ git remote add origin https://[my ssh code]@github.com/sbgraves237/fda
fatal: remote origin already exists.
...$ git push -u origin master
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


*** What do I need to do to fix the mess I seem to have created
and get what I want?


*** Thanks, Spencer Graves


p.s.  If you know the fda package, you know that James Ramsay is the
primary author, and I'm one of his long-time collaborators.  He has a
new version he wants to clean up and submit to CRAN, and I'm trying to
help him.  Thanks.  sg

__
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 rules re. web scraping?

[Spencer Graves]

Hello, All:


GOOD NEWS AND BAD NEWS:


   * First the good news:  I heard from Brian Ripley;  see below.  
His web site says, "He retired in August 2014 on grounds of ill health." 
(http://www.stats.ox.ac.uk/~ripley/)  I was pleased to see that he seems 
to be well enough to send me the email below.


   * BAD NEWS:  My Ecfun package is violating current CRAN rules 
regarding "not writing anywhere in the file space".  (See below.)


QUESTION:


   How do you suggest I respond to this?


   It's hard for me to fix, because I cannot replicate the error and 
I don't understand the rules Prof. Ripley is trying to enforce. The 
"CRAN Package Check Results for" this package show an error on 1 
platform (r-devel-linux-x86_64-fedora-gcc), NOTEs on 3 platforms 
(Fedora-clang and Debian), and "OK" on 9 others.  I can program selected 
tests not to run on CRAN, e.g., with (!fda::CRAN()).


   However, I suspect I should be able to do better than that.


   Suggestions?


   Thanks,
   Spencer Graves


p.s.  The development version of this package is available at 
"https://github.com/sbgraves237/Ecfun";.


https://cloud.r-project.org/web/checks/check_results_Ecfun.html


 Forwarded Message 
Subject:CRAN package Ecfun
Date:   Tue, 21 Jan 2020 21:26:02 +0000
From:   Prof Brian Ripley 
Reply-To:   CRAN 
To: Spencer Graves 
CC: CRAN 



This has been intermittently failing its checks for a week: different 
check runs failed (in the 24h prior to) the 14th, 15th, 17th and today. 
The current failure is

Check: examples
Result: ERROR
Running examples in ‘Ecfun-Ex.R’ failed
The error most likely occurred in:

 > ### Name: read.testURLs
 > ### Title: Read a file produced by testURLs
 > ### Aliases: read.testURLs
 > ### Keywords: IO
 >
 > ### ** Examples
 >
 > # Test only 2 web sites, not the default 4,
 > # and test only twice, not the default 10 times:
 > tst <- testURLs(c(
+ PVI="http://en.wikipedia.org/wiki/Cook_Partisan_Voting_Index";,
+ house="http://house.gov/representatives";),
+ n=2, maxFail=2)
1
1579634784, PVI, TRUE 0.828
1579634785, house, FALSE 0.051
1579634785, house, FALSE 0.048
2
1579634785, PVI, TRUE 0.043
1579634785, house, FALSE 0.11
1579634785, house, FALSE 0.035
 >
 > # The above should have created a file 'testURLresults.csv'
 > # in the working directory. Read it.
 >
 > dat <- read.testURLs()
Error in read.table(file = file, header = header, sep = sep, quote = 
quote, :
more columns than column names
Calls: read.testURLs -> read.csv -> read.table

That does not conform to the policy on Internet access, not least as no 
attempt is made to check if the file was created, let alone that it has 
the expected layout. Nor does it conform to the policy on not writing 
anywhere in the file space (and that shows on its CRAN results page too).

Please correct ASAP and before Feb 4 to safely retain the package on CRAN.

-- 
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford


[[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] CRAN rules re. web scraping?

[Spencer Graves]

  Thanks very much to Iñaki Ucar, Adam H Sparks, and Roy 
Mendelssohn for their replies that helped me understand what I needed to 
do to fix problems identified in the CRAN Checks.  I believe that those 
problems are not fixed in the development version of Ecfun available at 
"https://github.com/sbgraves237/Ecfun".  The package still needs more 
work, but I will make Prof. Ripley's Feb. 4 deadline.



  Thanks again,
  Spencer Graves


On 2020-01-23 01:55, Iñaki Ucar wrote:

On Thu, 23 Jan 2020 at 02:49, Spencer Graves
 wrote:

Hello, All:


GOOD NEWS AND BAD NEWS:


* First the good news:  I heard from Brian Ripley;  see below.
His web site says, "He retired in August 2014 on grounds of ill health."
(http://www.stats.ox.ac.uk/~ripley/)  I was pleased to see that he seems
to be well enough to send me the email below.


* BAD NEWS:  My Ecfun package is violating current CRAN rules
regarding "not writing anywhere in the file space".  (See below.)


QUESTION:


How do you suggest I respond to this?


It's hard for me to fix, because I cannot replicate the error and
I don't understand the rules Prof. Ripley is trying to enforce. The
"CRAN Package Check Results for" this package show an error on 1
platform (r-devel-linux-x86_64-fedora-gcc), NOTEs on 3 platforms
(Fedora-clang and Debian), and "OK" on 9 others.  I can program selected
tests not to run on CRAN, e.g., with (!fda::CRAN()).


However, I suspect I should be able to do better than that.


Suggestions?

The message from Prof. Ripley is crystal-clear, and exposes two issues
(Internet access, writing files) that have been discussed many times
in this list. A quick scan of the CRAN policy [1] yields:

- Packages which use Internet resources should fail gracefully with an
informative message if the resource is not available (and not give a
check warning nor error).

- Packages should not write in the user’s home filespace (including
clipboards), nor anywhere else on the file system apart from the R
session’s temporary directory.

[1] https://cran.r-project.org/web/packages/policies.html

Iñaki


Thanks,
Spencer Graves


p.s.  The development version of this package is available at
"https://github.com/sbgraves237/Ecfun";.


https://cloud.r-project.org/web/checks/check_results_Ecfun.html


 Forwarded Message 
Subject:CRAN package Ecfun
Date:   Tue, 21 Jan 2020 21:26:02 +0000
From:   Prof Brian Ripley 
Reply-To:   CRAN 
To: Spencer Graves 
CC: CRAN 



This has been intermittently failing its checks for a week: different
check runs failed (in the 24h prior to) the 14th, 15th, 17th and today.
The current failure is

Check: examples
Result: ERROR
Running examples in ‘Ecfun-Ex.R’ failed
The error most likely occurred in:

  > ### Name: read.testURLs
  > ### Title: Read a file produced by testURLs
  > ### Aliases: read.testURLs
  > ### Keywords: IO
  >
  > ### ** Examples
  >
  > # Test only 2 web sites, not the default 4,
  > # and test only twice, not the default 10 times:
  > tst <- testURLs(c(
+ PVI="http://en.wikipedia.org/wiki/Cook_Partisan_Voting_Index";,
+ house="http://house.gov/representatives";),
+ n=2, maxFail=2)
1
1579634784, PVI, TRUE 0.828
1579634785, house, FALSE 0.051
1579634785, house, FALSE 0.048
2
1579634785, PVI, TRUE 0.043
1579634785, house, FALSE 0.11
1579634785, house, FALSE 0.035
  >
  > # The above should have created a file 'testURLresults.csv'
  > # in the working directory. Read it.
  >
  > dat <- read.testURLs()
Error in read.table(file = file, header = header, sep = sep, quote =
quote, :
more columns than column names
Calls: read.testURLs -> read.csv -> read.table

That does not conform to the policy on Internet access, not least as no
attempt is made to check if the file was created, let alone that it has
the expected layout. Nor does it conform to the policy on not writing
anywhere in the file space (and that shows on its CRAN results page too).

Please correct ASAP and before Feb 4 to safely retain the package on CRAN.

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford


 [[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] "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC

[Spencer Graves]

Hello, All:


   devtools::check_rhub failed to trap an error wrapped in "try", 
per the email below.  This came from running 
devtools::check_rhub(Ecfun_dir), where Ecfun_dir = the path to a copy of 
"https://github.com/sbgraves237/Ecfun";.


   This is the development version of Ecfun, which I want to submit 
to CRAN as soon as I can do so without offending the sensibilities of 
the overworked CRAN maintainers.


   Suggestions?
   Thanks,
   Spencer Graves


 Forwarded Message 
Subject:Ecfun 0.2-2: ERROR
Date:   Sun, 02 Feb 2020 23:27:10 +
From:   R-hub builder 
To: spencer.gra...@effectivedefense.org



Ecfun 0.2-2: ERROR


Ecfun 0.2-2: ERROR
*Build ID:* |Ecfun_0.2-2.tar.gz-a5518fc2c19c4cd191a5d67b55c45603|
*Platform:* Ubuntu Linux 16.04 LTS, R-release, GCC
*Submitted:*1 hour 55 minutes 18.7 seconds ago
*Build time:*   1 hour 49 minutes 23.6 seconds


  ERRORS:

* checking examples ... ERROR
Running examples in ‘Ecfun-Ex.R’ failed
The error most likely occurred in:

> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: interpPairs
> ### Title: interpolate between pairs of vectors in a list
> ### Aliases: interpPairs interpPairs.call interpPairs.function
> ###   interpPairs.list
> ### Keywords: manip
> 
> ### ** Examples
> 
> ###
> ###
> ### 1.  interpPairs.function
> ###
> ###
> 
> ##
> ## 1.1.  simple 
> ##
> plot0 <- quote(plot(0))
> plot0. <- interpPairs(plot0)
> # check 
> ## Don't show: 
> stopifnot(
+ ## End(Don't show)
+ all.equal(plot0, plot0.)
+ ## Don't show:
+ )
> ## End(Don't show)
> 
> ##
> ## 1.2.  no op 
> ##
> noop <- interpPairs(plot0, iFrame=-1)
> # check
> ## Don't show: 
> stopifnot(
+ ## End(Don't show)
+ all.equal(noop, enquote(NULL))
+ ## Don't show:
+ )
> ## End(Don't show)
> 
> ##
> ## 1.3.  a more typical example
> ## example function for interpPairs 
> tstPlot <- function(){
+   plot(1:2, 1:2, type='n')
+   lines(firstFrame=1:3,
+ lastFrame=4,
+ x.1=seq(1, 2, .5),
+ y.1=x,
+ z.0=0, z.1=1,
+ txt.1=c('CRAN is', 'good', '...'),
+ col='red')
+ }
> tstbo <- body(tstPlot)
> iPlot <- interpPairs(tstbo[[2]])
> # check 
> iP <- quote(plot(1:2, 1:2, type='n'))
> ## Don't show: 
> stopifnot(
+ ## End(Don't show)
+ all.equal(iPlot, iP)
+ ## Don't show:
+ )
> ## End(Don't show)
> 
> iLines <- interpPairs(tstbo[[3]], nFrames=5, iFrame=2)
> # check:  
> # .proportion = (iFrame-firstFrame)/(lastFrame-firstFrame)
> #  = c(1/3, 0, -1/3)
> # if x.0 = 0 and y.0 = 0 by default:  
> iL <- quote(linex(x=c(1/3, 0), y=c(1/9, 0), z=c(1/3, 0), 
+tst=c('CR', '')))
> ##
> ## This example seems to give the wrong answer
> ## 2014-06-03:  Ignore for the moment 
> ##   
> #all.equal(iLines, iL)
> 
> ##
> ## 1.4.  Don't throw a cryptic error with NULL 
> ##
> ip0 <- interpPairs(quote(text(labels.1=NULL)))
>   
>   
> ###
> ###
> ### 2.  interpPairs.list
> ###
> ###
> 
> ##
> ## 2.1.  (x.0, y.0, x.1, y.1) -> (x,y)
> ##
> tstList <- list(x.0=1:5, y.0=5:9, y.1=9:5, x.1=9,
+ ignore=letters, col=1:5)
> xy <- interpPairs(tstList, 0.1)
> # check 
> xy. <- list(ignore=letters, col=1:5, 
+ x=1:5 + 0.1*(9-1:5),
+ y=5:9 + 0.1*(9:5-5:9) )
> # New columns, 'x' and 'y', come after 
> # columns 'col' and 'ignore' already in tstList 
> ## Don't show: 
> stopifnot(
+ ## End(Don't show)
+ all.equal(xy, xy.)
+ ## Don't show:
+ )
> ## End(Don't show)
> 
> ##
> ## 2.2.  Select the middle 2:  
> ##  x=(1-(0,1))*3:4+0:1*0=(3,0)
> ##
> xy0 <- interpPairs(tstList[-4], c(-Inf, -1, 0, 1, 2) )
> # check 
> xy0. <- list(ignore=letters, col=3:4, x=c(3,0), y=7:6)
> 
> ## Don't show: 
> stopifnot(
+ ## End(Don't show)
+ all.equal(xy0, xy0.)
+ ## Don't show:
+ )
> ## End(Don't show)
> ##
> ## 2.3.  Null interpolation because of absence of y.1 and x.0  
> ##
> xy02 <- interpPairs(tstList[c(2, 4)], 0.1)
> # check 
>  NOT the current default answer;  revisit later.  
> xy02. <- list(y=5:9, x=9)
> 
> # NOTE:  length(x) = 1 = length(x.1) in testList
> #all.equal(xy02, xy02.)
> 
> ##
> ## 2.4.  Select an empty list (make sure this works)
> ##
> x0 <- interpPairs(list(), 0:1)
Warning message:
In checkNames(object, avoid = pairs[c(1, 4, 2, 5)]) :
   object:  names = NULL; returning make.names(charact

Re: [R-pkg-devel] "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC

[Spencer Graves]

Hi, Dirk:


  The short answer is that's part of what's on "rhub".


  When I run devtools::check_rhub, I get emails with test results 
from three platforms:  (1) Windows Server 2008 R2 SP1, R-devel, 32/64 
bit.  (2) Ubuntu Linux 16.04 LTS, R-release, GCC. And (3) Fedora Linux, 
R-devel, clang, gfortran.  I've been getting a NOTE of "Packages 
unavailable to check Rd xrefs: ‘EnvStats’, ‘drc’, ‘zoo’, ‘prodlim’, 
‘TRAMPR’" from the Windows and Fedora tests and the "try" malfunction 
that I reported from Ubuntu 16.04 LTS.



  I don't know who maintains rhub, but I would naively think that's 
a separate issue from the "try" malfunction that I reported.



  Spencer


On 2020-02-02 23:27, Dirk Eddelbuettel wrote:

On 2 February 2020 at 21:47, Ben Bolker wrote:
|   Maybe an Rhub glitch.  I just ran R CMD check with a recent r-devel
| (2019-12-03 r77509) on Ubuntu 16.04 with no problems.

Is there a reason that keeps _both_ of you on Ubuntu 16.04 which has been
replaced _nearly two years ago_ by the subsequent LTS release 18.04 ?

Michael works hard to provide _an awesome_ experience using the current LTS
release_ 18.04 that I am really hard-pressed to see why 16.04 would matter.

Dirk



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

[R-pkg-devel] finding "logo.jpg" [was: "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC]

[Spencer Graves]

  Thanks to Iñaki Ucar for identifying a second error that 
explained why I still got an error after wrapping one in "try".



  That still leaves a question of how to find a file like 
"logo.jpg" in a platform independant way.



      The following had worked for several years and now broke on rhub 
"Ubuntu Linux 16.04 LTS, R-release, GCC" but not on several other 
computers I tried:



        logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg", sep 
= .Platform$file.sep)



  On that Ubuntu platform, "readJPEG(logo.jpg)" stopped with "Error 
in readJPEG(logo.jpg) : unable to open /usr/lib/R/doc/html/logo.jpg".



  I replaced the above "paste" with the following:


RdocDir <- dir(R.home(), pattern='^doc$', full.names = TRUE)
RhtmlDir <- dir(RdocDir, pattern='^html$', full.names=TRUE)
JPGs <- dir(RhtmlDir, pattern='.jpg$', full.names=TRUE)
if(length(JPGs)>1){
  logoJPG <- paste0(.Platform$file.sep, 'logo.jpg$')
  logo.jpg <- grep(logoJPG, JPGs, value=TRUE)
  if(length(logo.jpg)>1)logo.jpg <- logo.jpg[1]
  if(length(logo.jpg)<1)logo.jpg <- JPGs[1]
} else logo.jpg <- JPGs
if(length(logo.jpg)<1){
  cat('logo.jpg not found.\n')
  print(R.home())
  print(dir(RdocDir))
  print(dir(RhtmlDir))
  if(!fda::CRAN())stop('logo.jpg not found')
} else {
# length(logo.jpg)==1 so continue:
  if(require(jpeg)){
##
## 1.  Shrink as required
##
    Rlogo <- readJPEG(logo.jpg)

...


      This gave me no error message, which I believe means that either 
length(logo.jpg) == 1 or fda::CRAN() returns TRUE.  Sadly, I could not 
find the standard test file to see which of these is the case.



  I should proceed to submit the current Ecfun package to CRAN. 
Then I might modify this test sequence to force an error, so I can see 
more what is happening.



  Suggestions?
  Thanks,
  Spencer


On 2020-02-03 03:06, Iñaki Ucar wrote:

On Mon, 3 Feb 2020 at 03:16, Spencer Graves
 wrote:

Hello, All:


devtools::check_rhub failed to trap an error wrapped in "try",
per the email below.  This came from running
devtools::check_rhub(Ecfun_dir), where Ecfun_dir = the path to a copy of
"https://github.com/sbgraves237/Ecfun";.

That's improbable.


    This is the development version of Ecfun, which I want to submit
to CRAN as soon as I can do so without offending the sensibilities of
the overworked CRAN maintainers.


Suggestions?
Thanks,
Spencer Graves


 Forwarded Message 
Subject:Ecfun 0.2-2: ERROR
Date:   Sun, 02 Feb 2020 23:27:10 +
From:   R-hub builder 
To: spencer.gra...@effectivedefense.org





## 2.9.  A more complicated example with elements to eval
##
logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg",

+   sep = .Platform$file.sep)

if(require(jpeg)){

+   Rlogo <- try(readJPEG(logo.jpg))
+   if(!inherits(Rlogo, 'try-error')){
+ # argument list for a call to rasterImage or rasterImageAdj
+ RlogoLoc <- list(image=Rlogo,
+   xleft.0 = c(NZ=176.5,CH=172,US=171,
+   CN=177,RU= 9.5,UK= 8),
+   xleft.1 = c(NZ=176.5,CH=  9,US=-73.5,
+   CN=125,RU= 37, UK= 2),
+   ybottom.0=c(NZ=-37,  CH=-34,US=-34,
+   CN=-33,RU= 48, UK=47),
+   ybottom.1=c(NZ=-37,  CH= 47,US= 46,
+   CN= 32,RU=55.6,UK=55),
+   xright=quote(xleft+xinch(0.6)),
+   ytop = quote(ybottom+yinch(0.6)),
+   angle.0 =0,
+   angle.1 =c(NZ=0,CH=3*360,US=5*360,
+  CN=2*360,RU=360,UK=360)
+ )
+
+ RlogoInterp <- interpPairs(RlogoLoc,
+ .proportion=rep(c(0, -1), c(2, 4)) )
+ # check
+ ## Don't show:
+ stopifnot(
+ ## End(Don't show)
+ all.equal(names(RlogoInterp),
+c('image', 'xright', 'ytop', 'xleft', 'ybottom', 'angle'))
+ ## Don't show:
+ )
+ ## End(Don't show)
+ }
+ # NOTE:  'xleft', and 'ybottom' were created in interpPairs,
+ # and therefore come after 'xright' and 'ytop', which were
+ # already there.
+
+ ##
+ ## 2.10.  using envir
+ ##
+   RlogoDiag <- list(x0=quote(Rlogo.$xleft),
+   y0=quote(Rlogo.$ybottom),
+   x1=quote(Rlogo.$xright),
+   y1=quote(Rlogo.$ytop) )
+
+   RlogoD <- interpPairs(RlogoDiag, .p=1,
+ envir=list(Rlogo.=RlogoInterp) )
+ ## Don't show:
+ stopifnot(
+ ## End(Don't show)
+ all.equal(RlogoD, RlogoDiag)
+ ## Don't show:
+ )
+ ## End(Don't show)
+ }
Loading required package: jpeg
Error in readJPEG(logo.jpg) : unable to open /usr/lib/R/doc/html/logo.jpg
Error in interpPairs.list(RlogoDiag, .p = 

[R-pkg-devel] revdepcheck::revdep_check interpretation problem

[Spencer Graves]

Hello, All:


  I just ran "revdepcheck::revdep_check" on my development version 
of "https://github.com/sbgraves237/Ecdat";  copied below. It ended with 
"OK: 16, BROKEN: 0".  That sounds good, except that it also says 
"gamclass 0.58:  E: 1", so I'm confused.



  Two questions:


        1.  What does the "E: 1" for "gamclass" mean?  It sounds 
like an error to me, but that contradicts the final message,

"OK: 16, BROKEN: 0".


        2.  How can I even find gamclass?  It's not available on 
CRAN.  There, Ecdat only has 15 reverse dependencies, not 16.  I tried 
install.packages('gamclass');  it said, "package ‘gamclass’ is not 
available".  I tried githubinstall::githubinstall('gamclass'). It said:



Select a number or, hit 0 to cancel.

1: pik-piam/magclass    Tools for managing classroom organizations
2: tscheypidi/magclass  Tools for managing classroom organizations
3: rundel/ghclass   Tools for managing classroom organizations


  ** None of that sounds like "gamclass".


  What do you suggest?


  I should probably ignore this?
  Thanks,
  Spencer Graves


 revdepcheck::revdep_check(Ecdat_dir)
Registered S3 method overwritten by 'revdepcheck':
  method    from
  print.maintainers devtools
── INIT  Computing revdeps ──
── INSTALL  2 versions ──
Installing CRAN version of Ecdat
Installing DEV version of Ecdat
── CHECK ─ 16 packages ──
✓ catdata 1.2.2  ── E: 0 | W: 0 | N: 0
✓ DCchoice 0.0.15    ── E: 0 | W: 0 | N: 0
✓ discSurv 1.4.1 ── E: 0 | W: 0 | N: 0
✓ DStree 1.0 ── E: 0 | W: 0 | N: 1
✓ DWreg 2.0  ── E: 0 | W: 0 | N: 0
✓ Ecfun 0.2-2    ── E: 0 | W: 0 | N: 0
✓ flexmix 2.3-15 ── E: 0 | W: 0 | N: 0
✓ gamclass 0.58  ── E: 1 | W: 0 | N: 0
✓ gk 0.5.1   ── E: 0 | W: 0 | N: 0
✓ micEcon 0.6-14 ── E: 0 | W: 1 | N: 0
✓ micEconIndex 0.1-6 ── E: 0 | W: 0 | N: 0
✓ miscTools 0.6-26   ── E: 0 | W: 0 | N: 0
✓ mssm 0.1.3 ── E: 0 | W: 0 | N: 0
✓ plm 2.2-0  ── E: 0 | W: 0 | N: 0
✓ sampleSelection 1.2-6  ── E: 0 | W: 0 | N: 0
✓ SeleMix 1.0.1  ── E: 0 | W: 0 | N: 0
OK: 16
BROKEN: 0
Total time: 36 min

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

[R-pkg-devel] Error: Symbol \textasciigrave not provided by (textcomp)

[Spencer Graves]

Hello, All:


  "R CMD check Ecfun_0.2-4.tar.gz" ends with 8 repetitions of the 
following:



! Package textcomp Error: Symbol \textasciigrave not provided by
(textcomp)    font family zi4 in TS1 encoding.
(textcomp)    Default family used instead.

See the textcomp package documentation for explanation.
* checking PDF version of manual without hyperrefs or index ... ERROR
* DONE


  This is using R 3.6.2 under macOS 10.15.3 applied to the current 
development version of "https://github.com/sbgraves237/Ecfun".  Travis 
CI reported that the build passed;  see 
"https://travis-ci.org/sbgraves237/Ecfun/builds/650505913?utm_medium=notification&utm_source=email";. 




  This looks to me like it's complaining about the use of the back 
tick character ("`", below "~" on the top left key on a standard 
American English keyboard), which I assume is equivalent to 
"\textasciigrave" in certain contexts.



  Six out of those 8 repetitions occur in the examples sections of 
files "grepNonStandardCharacters.Rd", "subNonStandardCharacters.Rd", and 
"subNonStandardNames.Rd".  Those functions were written to fix parsing 
errors with names like "Raúl" that had been mangled by different 
software before I could get it into R.



  After a day's work failed to produce a work around, I decided to 
ask this group.



  What do you suggest?
  Thanks,
  Spencer Graves

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

[R-pkg-devel] MiKTex v. TeX Live?

[Spencer Graves]

Hello, All:  Two related questions:


SHORT QUESTION:  Which version of LaTeX does the R Project prefer and 
why?  I'm having trouble with MiKTeX, and one source suggested I switch 
to TeX Live.  (e.g., "https://latex.org/forum/viewtopic.php?t=29034";)



PRESENTING PROBLEM:


   "R CMD build sos" under Windows 7 on a clone from 
"https://github.com/sbgraves237/sos"; ended with, 'The required file 
tex\latex\pgf\frontendlayer\tikz.sty" is missing.'  I clicked "Install" 
and got "MiKTeX Update Wizard:  The operation could not be completed for 
the following reason:  No data.  Details:  get host by name failed in 
tcp_connect()".



  I get the same error when I try to run MiKTeX 2.9 Update and 
"Update (Admin)".  (I got the "tikz.sty is missing" message only after I 
had turned off everything I could find to turn off in "Bitdefender Total 
Security".)  I think I saw a suggestion to manually delete "C:Program 
Files (x86)\MiKTeX 2.9" and manually remove the reference from the path, 
then reinstall into a different directory that the operating system and 
anti-virus would not by default identify as part of the operating system.



  Suggestions?
  Thanks,
  Spencer Graves


p.s.  This is using R 2.6.2 immediately after running "update.packages()".

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