Re: [R-pkg-devel] Confusion about what should be in Imports for a package with a shiny app
Duncan, As always, your answer is helpful. What you wrote agrees with my original understanding. I was somehow mislead by my interpretation of earlier tesing output and got on the wrong track. You are correct that the intent of the package is to enable more skilled users to use the package interactively or in their own scripts and applications. I will modify the DESCRIPTION file accordingly. Mark R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com > On Mar 24, 2021, at 2:31 AM, Duncan Murdoch wrote: > > On 24/03/2021 12:16 a.m., R. Mark Sharp wrote: >> I have a package (nprcgenekeepr) in which some packages listed in the >> DESCRIPTION file are used only within the shiny app scripts. For my prior >> CRAN submission (successful), I placed such packages in the Suggests section >> of the DESCRIPTION file. This time testing sites seemed to have directed me >> to place them in the Imports section and I now have multiple test >> environments (3 R-hub builder, 3 winbuilder, and 3 Travis-ci) that are >> showing no errors, warnings, or notes with that placement. However, the >> package check page >> https://cran.rstudio.com//web/checks/check_results_nprcgenekeepr.html site >> is showing the wrong package version (1.0.3 instead of 1.0.5) and some >> environments with a note of "Namespace in Imports field not imported from: >> ‘shinyBS’ All declared Imports should be used.” >> I changed the function call from `popify` to `shinyBS::popify` and get the >> same results >> I moved shinyBS to Suggests and I get the same note. >> I also have shinyWidgets used within the same UI script and listed in the >> Imports section and it does not generate a note. >> It appears that I have a basic misunderstanding of the message in the note >> and of where the `shinyBS` package should be listed within the DESCRIPTION >> file. >> Help will be appreciated. > > The check code won't examine R code in your inst/application directory where > the Shiny app code is kept, so that's why you get the "All declared Imports > should be used" message. > > Your README says > > "The goal of nprcgenekeepr is to implement Genetic Tools for Colony > Management. It was initially conceived and developed as a Shiny web > application at the Oregon National Primate Research Center (ONPRC) to > facilitate some of the analyses they perform regularly. It has been enhanced > to have more capability as a Shiny application and to expose the functions so > they can be used either interactively or in R scripts." > > This indicates that you expect some users aren't going to use the Shiny > script, so they won't need shinyBS. That means it should be in Suggests, not > Imports, and your Shiny app should check whether it is available before > trying to run it. > > If you think *most* users will want the Shiny app, then you could force it to > be installed and loaded by putting it in Imports. Then you'll have to make > use of it somewhere in your main code to silence the message. But it's > probably better to leave it in Suggests. > > As to the "wrong package version" issue: CRAN isn't showing 1.0.5 anywhere. > You may have submitted it, but it hasn't been accepted. It's not in the CRAN > queues, so you'll need to submit again if you want it on CRAN. > > Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Confusion about what should be in Imports for a package with a shiny app
I have a package (nprcgenekeepr) in which some packages listed in the DESCRIPTION file are used only within the shiny app scripts. For my prior CRAN submission (successful), I placed such packages in the Suggests section of the DESCRIPTION file. This time testing sites seemed to have directed me to place them in the Imports section and I now have multiple test environments (3 R-hub builder, 3 winbuilder, and 3 Travis-ci) that are showing no errors, warnings, or notes with that placement. However, the package check page https://cran.rstudio.com//web/checks/check_results_nprcgenekeepr.html site is showing the wrong package version (1.0.3 instead of 1.0.5) and some environments with a note of "Namespace in Imports field not imported from: ‘shinyBS’ All declared Imports should be used.” I changed the function call from `popify` to `shinyBS::popify` and get the same results I moved shinyBS to Suggests and I get the same note. I also have shinyWidgets used within the same UI script and listed in the Imports section and it does not generate a note. It appears that I have a basic misunderstanding of the message in the note and of where the `shinyBS` package should be listed within the DESCRIPTION file. Help will be appreciated. Mark R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [R] a question of etiquette
Spencer, I apologize for my obvious (in hindsight) error in bringing up the topic. I will bring up one example, because of your request. Google has listed GPL-1, 2, and 3 as one of several licenses that are restricted and cannot be used by a Google product delivered to outside customers. This include downloadable client software and software such as insdie the Google Search Appliance. This includes having scripts that load packages dynamically as with “library()” and “require()”. Please see https://opensource.google/docs/thirdparty/licenses/#restricted for their wording. I am not defending their position and disagree with it. However, it is their position based on what I think is a conservative or overly cautious legal interpretation. I am not a lawyer, however, so my opinions are of no import. Mark R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com > On Jun 2, 2020, at 10:22 AM, Spencer Graves > wrote: > > Can Dr. Sharp kindly provide a credible reference, discussing the > alleged ambiguities in GPL-2 and GPL-3 that convince some companies to avoid > them? > > > I like Wikimedia Foundation projects like Wikipedia, where almost > anyone can change almost anything, and what stays tends to be written from a > neutral point of view, citing credible sources. I get several emails a day > notifying me of changes in articles I'm "watching". FUD, vandalism, etc., > are generally reverted fairly quickly or moved to the "Talk" page associated > with each article, where the world is invited to provide credible source(s). > > > Spencer Graves > > > On 2020-06-02 10:12, Dirk Eddelbuettel wrote: >> On 2 June 2020 at 10:06, R. Mark Sharp wrote: >> | The GPL-2 and GPL-3 licenses are apparently sufficiently ambiguous in the >> legal community that some companies avoid them. >> >> Wittgenstein: 'That whereof we cannot speak, thereof we must remain silent' >> >> This is a mailing list of the R project. R is a GNU Project. R is licensed >> under the GPL, version two or later. That has not stopped large corporations >> from using R, adopting R, or starting or acquiring R related businesses. >> >> If you have a strong urge to spread FUD about the GPL and R, could you have >> the >> modicum of etiquette to not do it on a mailing list of the R Project? >> >> Dirk >> > > __ > 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> [[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] [R] a question of etiquette
Adelchi,
Actually, the person recognized wrote the original code for the algorithm and
he has had other contributors over time that have made several improvements.
The code I have is not verbatim from his package as it has been adapted for our
purposes, but he is still the originator of the approach and I am certain he
and others would recognize the code as being clearly deriviative. I have
retained some of the same function names or near derivatives of those names. My
coding style is different but that has not changed the basic logic.
With regard to licensing, we both use MIT, which I strongly prefer. The GPL-2
and GPL-3 licenses are apparently sufficiently ambiguous in the legal community
that some companies avoid them.
Mark
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
> On Jun 2, 2020, at 1:32 AM, Adelchi Azzalini wrote:
>
> Thanks for this information, Mark.
>
> Given the phrase "small but important function my package uses", it seems
> that you included in your package some code, reproducing it verbatim.
> Do I understand correctly?
> In my case, the code which I am actually using is the R porting of code
> originally written in another language, namely Matlab.
>
> Best wishes,
>
> Adelchi
>
>
>> On 1 Jun 2020, at 23:37, R. Mark Sharp wrote:
>>
>> Adelchi,
>>
>> I have a similar situation where I had made all of the typical academic
>> references within the code and documentation for a small but important
>> function my package uses. I was asked by the CRAN reviewers to add the
>> author of that function to the DESCRIPTION Authors@R section. I added the
>> following:
>> person("Terry", "Therneau", role = c("aut”))
>>
>> Mark
>> R. Mark Sharp, Ph.D.
>> Data Scientist and Biomedical Statistical Consultant
>> 7526 Meadow Green St.
>> San Antonio, TX 78251
>> mobile: 210-218-2868
>> rmsh...@me.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Begin forwarded message:
>>>
>>> From: Adelchi Azzalini
>>> Subject: [R] a question of etiquette
>>> Date: June 1, 2020 at 11:34:00 AM CDT
>>> To: r-h...@r-project.org
>>>
>>> The new version of a package which I maintain will include a new function
>>> which I have ported to R from Matlab.
>>> The documentation of this R function indicates the authors of the original
>>> Matlab code, reference to their paper, URL of the source code.
>>>
>>> Question: is this adequate, or should I include them as co-authors of the
>>> package, or as contributors, or what else?
>>> Is there a general policy about this matter?
>>>
>>> Adelchi Azzalini
>>> http://azzalini.stat.unipd.it/
>>>
>>> __
>>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
>>
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Fwd: [R] a question of etiquette
Adelchi,
I have a similar situation where I had made all of the typical academic
references within the code and documentation for a small but important function
my package uses. I was asked by the CRAN reviewers to add the author of that
function to the DESCRIPTION Authors@R section. I added the following:
person("Terry", "Therneau", role = c("aut”))
Mark
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
> Begin forwarded message:
>
> From: Adelchi Azzalini
> Subject: [R] a question of etiquette
> Date: June 1, 2020 at 11:34:00 AM CDT
> To: r-h...@r-project.org
>
> The new version of a package which I maintain will include a new function
> which I have ported to R from Matlab.
> The documentation of this R function indicates the authors of the original
> Matlab code, reference to their paper, URL of the source code.
>
> Question: is this adequate, or should I include them as co-authors of the
> package, or as contributors, or what else?
> Is there a general policy about this matter?
>
> Adelchi Azzalini
> http://azzalini.stat.unipd.it/
>
> __
> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Examples for functions called by Shiny server
I have been asked to provide examples within the Rd files of my package (github.com/rmsharp/nprcgenekeepr <http://github.com/rmsharp/nprcgenekeepr>) by the CRAN package reviewer. I have to export those functions called by the server.R script (or use ::: notation), which in turn generates an Rd file that is to have the example. I cannot think of a meaningful example for a function that creates the content of a new Shiny tabpanel when an error is detected. Suggestions are eagerly sought. Mark R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] compression of vignettes
I have been unsuccessful with all of the following attempts to have compression
of dynamically generated vignettes during the build on travis-ci and within
RStudio. Help is appreciated.
I have tried the following travis-ci YAML to have vignettes compressed.
script:
- R -e 'r <- rcmdcheck::rcmdcheck(".", args = c('--no-manual'), build_args =
c('--compact-vignettes=both'); devtools::test(); quit(save = "no", status = if
(length(c(r$errors, r$warnings)) > 0) { 1 } else { 0 }, runLast = FALSE)'
script:
- R -e 'r <- rcmdcheck::rcmdcheck(".", args = c('--no-manual',
'--compact-vignettes=gs+qpdf'); devtools::test(); quit(save = "no", status = if
(length(c(r$errors, r$warnings)) > 0) { 1 } else { 0 }, runLast = FALSE)'
script:
- R -e 'r <- rcmdcheck::rcmdcheck(".", args = c('--no-manual',
'--compact-vignettes="gs+qpdf"'); devtools::test(); quit(save = "no", status =
if (length(c(r$errors, r$warnings)) > 0) { 1 } else { 0 }, runLast = FALSE)'
I have tried the following build arguments in RStudio
--as-cran --compact-vignettes=gs+qpdf
--as-cran --compact-vignettes=both
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R-hub PREPERROR on Ubuntu Linux 16.04 LTS, R-release, GCC not on other platforms
Should I ignore this problem with regard to going forward with a submission to CRAN? It looks like some CRAN packages that I am dependent on are not available on the Ubuntu Linux 16.04 LTS platform. #> Failed with error: ‘there is no package called ‘shiny’’ #> ERROR: dependency ‘openssl’ is not available for package ‘httr’ #> ERROR: dependency ‘httr’ is not available for package ‘covr’ #> ERROR: dependency ‘httr’ is not available for package ‘Rlabkey’ #> ERROR: dependencies ‘httr’, ‘openssl’ are not available for package ‘pkgdown’ #> ERROR: dependency ‘Rlabkey’ is not available for package ‘nprcmanager’ The following platforms have no errors or warnings and have only the “New submission” note. Windows Server 2008 R2 SP1, R-devel, 32/64 bit Fedora Linux, R-devel, clang, gfortran Mark R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] checking CRAN incoming feasibility NOTE
Roy, Thank you for your guidance and advice. I ran usethis::use_cran_comments() shown below. > usethis::use_cran_comments() ✔ Setting active project to '/Users/msharp/Documents/Development/R/r_workspace/library/nprcmanager' ✔ Writing 'cran-comments.md' ✔ Adding '^cran-comments\\.md$' to '.Rbuildignore' ● Modify 'cran-comments.md’ The text of “cran-comments.md” follows and also makes me think it was a clean inspection: ## Test environments * local OS X install, R 3.6.1 * ubuntu 14.04 (on travis-ci), R 3.6.1 * win-builder (devel and release) ## R CMD check results 0 errors | 0 warnings | 1 note * This is a new release. R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com > On Oct 5, 2019, at 5:10 PM, Roy Mendelssohn - NOAA Federal > wrote: > > use this::use_cran_comments() > > There is a place to put that it is a new submission > > I would recommend also testing using: > > devtools::check_win_release() > devtools::check_win_devel() > > You should only have the one note that it is a new submission. When you > submit, you may or may not get a note that it was rejected by the automatic > checker. Sit tight, someone from CRAN will see that it is a new submission. > A new submission is given a much more thorough review, so it can take a > coupe days or more for CRAN to get back to you. You can check the status of > CRAN submissions at: > > https://cransays.itsalocke.com/articles/dashboard.html > > HTH, > > -Roy > > >> On Oct 5, 2019, at 2:52 PM, R. Mark Sharp wrote: >> >> I getting ready to submit a package to CRAN for the first time. I have run >> cran_prep <- check_for_cran() using the rhub package. I understand that as a >> new package it will generate a NOTE. As a novice, I do not know what is to >> be expected within that NOTE and want to make sure the NOTEs I have received >> are satisfactory. I have not found an example of a minimal first submission >> NOTE. Below is what I am getting from the above test on rhub. I have three >> test environments but only two NOTEs. Do these results indicate a problem to >> be addressed? >> >>> cran_prep$cran_summary() >> For a CRAN submission we recommend that you fix all NOTEs, WARNINGs and >> ERRORs. >> ## Test environments >> - R-hub windows-x86_64-devel (r-devel) >> - R-hub ubuntu-gcc-release (r-release) >> - R-hub fedora-clang-devel (r-devel) >> >> ## R CMD check results >> ❯ On windows-x86_64-devel (r-devel), ubuntu-gcc-release (r-release) >> checking CRAN incoming feasibility ... NOTE >> Maintainer: 'R. Mark Sharp ' >> >> New submission >> >> License components with restrictions and base license permitting such: >> MIT + file LICENSE >> File 'LICENSE': >> Copyright 2017-2019 R. Mark Sharp >> >> Permission is hereby granted, free of charge, to any person obtaining a >> copy of this software and associated documentation files (the "Software"), >> to deal in the Software without restriction, including without limitation >> the rights to use, copy, modify, merge, publish, distribute, sublicense, >> and/or sell copies of the Software, and to permit persons to whom the >> Software is furnished to do so, subject to the following conditions: >> >> The above copyright notice and this permission notice shall be included in >> all copies or substantial portions of the Software. >> >> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR >> IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, >> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE >> AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER >> LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING >> FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS >> IN THE SOFTWARE. >> >> ❯ On fedora-clang-devel (r-devel) >> checking CRAN incoming feasibility ...NB: need Internet access to use CRAN >> incoming checks >> NOTE >> Maintainer: ‘R. Mark Sharp ’ >> >> License components with restrictions and base license permitting such: >> MIT + file LICENSE >> File 'LICENSE': >> Copyright 2017-2019 R. Mark Sharp >> >> Permission is hereby granted, free of charge, to any person obtaining a >> copy of this software and associated documentation files (the "Software"), >> to deal in the Software without restriction, including without li
Re: [R-pkg-devel] Change in normal random numbers between R 3.5.3 and R 3.6.0
Ulrike,
RNGkind() worked on 3.4.1 and 3.6.0 but generated a warning on R 3.5.3. The
message follows:
checking whether package ‘nprcmanager’ can be installed ... WARNING
Found the following significant warnings:
Note: possible error in 'RNGkind(sample.kind = "Rounding")': unused argument
(sample.kind = "Rounding")
See ‘/tmp/RtmpA4S3Ki/file32b81c218ac8/nprcmanager.Rcheck/00install.out’ for
details.
Information on the location(s) of code generating the ‘Note’s can be
obtained by re-running with environment variable R_KEEP_PKG_SOURCE set
to ‘yes’.
Mark
R. Mark Sharp
rmsh...@me.com
> On May 9, 2019, at 11:39 PM, Ulrike Grömping
> wrote:
>
> Mark,
>
> I used
>
> if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
>
> And that works. Actually, using rnorm afterwards also yields the same random
> numbers.
> My question arose from the fact that I confused myself about the noLD output
> I was supposed to reproduce. Therefore, my problem should be entirely
> explained by Duncan Murdoch's initial explanation: the sample() change does
> not only lead to different results in discrete sampling but also to different
> results from random number calls for other functions (like rnorm).
>
> Best, Ulrike
>
> Am 10.05.2019 um 04:58 schrieb R. Mark Sharp:
>> I was dealing with a similar issue but in the context of getting the same
>> unit test code to work on multiple versions of R in a Travis-CI build. It
>> seems RNGkind(sample.kind="Rounding”) does not work prior to version 3.6 so
>> I resorted to using version dependent construction of the argument list to
>> set.seed() in do.call().
>>
>> I better solution will be greatly appreciated.
>>
>> #' Work around for unit tests using sample()
>> #'
>> #' @param seed argument to \code{set.seed}
>> set_seed <- function(seed = 1) {
>> version <- as.integer(R.Version()$major) + (as.numeric(R.Version()$minor)
>> / 10.0)
>> if (version >= 3.6) {
>> args <- list(seed, sample.kind = "Rounding")
>> } else {
>> args <- list(seed)
>> }
>> suppressWarnings(do.call(set.seed, args))
>> }
>>
>> Mark
>>
>> R. Mark Sharp, Ph.D.
>> Data Scientist and Biomedical Statistical Consultant
>> 7526 Meadow Green St.
>> San Antonio, TX 78251
>> mobile: 210-218-2868
>> rmsh...@me.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On May 9, 2019, at 12:45 PM, Duncan Murdoch
>>> wrote:
>>>
>>> On 09/05/2019 12:43 p.m., Ulrike Grömping wrote:
>>>> Hmmmh, but does that also apply if the sample.kind has been set to the
>>>> old version? I.e., would
>>>> if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
>>>> val <- 10
>>>> set.seed(val)
>>>> discard <- sample(1000, 100)
>>>> rnorm(36)
>>>> produce the same normal random numbers in 3.5.3 and 3.6.0? I would have
>>>> expected it to, but it seems to produce the same normal random numbers
>>>> as R version 3.6.0 in the previous version of the test code without the
>>>> RNGkind call.
>>> I'm not seeing that, but I'm not using the exact versions you tested. If I
>>> run your code in "R version 3.5.2 (2018-12-20)" and "R Under development
>>> (unstable) (2019-05-02 r76454)" I get this output from both:
>>>
>>>> if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
>>>> val <- 10
>>>> set.seed(val)
>>>> discard <- sample(1000, 100)
>>>> rnorm(36)
>>> [1] -0.4006375 -0.3345566 1.3679540 2.1377671 0.5058193 0.7863424
>>> -0.9022119 0.5328970 -0.6458943 0.2909875 -1.2375945
>>> [12] -0.4561763 -0.8303227 0.3401156 1.0663764 1.2161258 0.7356907
>>> -0.4812086 0.5627448 -1.2463197 0.3809222 -1.4304273
>>> [23] -1.0484455 -0.2185036 -1.4899362 1.1727063 -1.4798270 -0.4303878
>>> -1.0516386 1.5225863 0.5928281 -0.2226615 0.7128943
>>> [34] 0.7166008 0.4402419 0.1588306
>>>
>>> Okay, I just installed 3.6.0, and I get the same values there. I don't see
>>> a Mac binary for 3.5.3, so I can't test that one.
>>>
>>> Duncan Murdoch
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
> --
> ##
> ## Prof. Ulrike Groemping
> ## FB II
> ## Beuth University of Applied Sciences Berlin
> ##
> ## prof.beuth-hochschule.de/groemping
> ## Phone: +49(0)30 4504 5127
> ## Fax: +49(0)30 4504 66 5127
> ## Home office: +49(0)30 394 04 863
> ##
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Change in normal random numbers between R 3.5.3 and R 3.6.0
I was dealing with a similar issue but in the context of getting the same unit
test code to work on multiple versions of R in a Travis-CI build. It seems
RNGkind(sample.kind="Rounding”) does not work prior to version 3.6 so I
resorted to using version dependent construction of the argument list to
set.seed() in do.call().
I better solution will be greatly appreciated.
#' Work around for unit tests using sample()
#'
#' @param seed argument to \code{set.seed}
set_seed <- function(seed = 1) {
version <- as.integer(R.Version()$major) + (as.numeric(R.Version()$minor) /
10.0)
if (version >= 3.6) {
args <- list(seed, sample.kind = "Rounding")
} else {
args <- list(seed)
}
suppressWarnings(do.call(set.seed, args))
}
Mark
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
> On May 9, 2019, at 12:45 PM, Duncan Murdoch wrote:
>
> On 09/05/2019 12:43 p.m., Ulrike Grömping wrote:
>> Hmmmh, but does that also apply if the sample.kind has been set to the
>> old version? I.e., would
>> if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
>> val <- 10
>> set.seed(val)
>> discard <- sample(1000, 100)
>> rnorm(36)
>> produce the same normal random numbers in 3.5.3 and 3.6.0? I would have
>> expected it to, but it seems to produce the same normal random numbers
>> as R version 3.6.0 in the previous version of the test code without the
>> RNGkind call.
>
> I'm not seeing that, but I'm not using the exact versions you tested. If I
> run your code in "R version 3.5.2 (2018-12-20)" and "R Under development
> (unstable) (2019-05-02 r76454)" I get this output from both:
>
> > if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
> > val <- 10
> > set.seed(val)
> > discard <- sample(1000, 100)
> > rnorm(36)
> [1] -0.4006375 -0.3345566 1.3679540 2.1377671 0.5058193 0.7863424
> -0.9022119 0.5328970 -0.6458943 0.2909875 -1.2375945
> [12] -0.4561763 -0.8303227 0.3401156 1.0663764 1.2161258 0.7356907
> -0.4812086 0.5627448 -1.2463197 0.3809222 -1.4304273
> [23] -1.0484455 -0.2185036 -1.4899362 1.1727063 -1.4798270 -0.4303878
> -1.0516386 1.5225863 0.5928281 -0.2226615 0.7128943
> [34] 0.7166008 0.4402419 0.1588306
>
> Okay, I just installed 3.6.0, and I get the same values there. I don't see a
> Mac binary for 3.5.3, so I can't test that one.
>
> 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] Getting error: Installation failed: Unknown username with my package
Gabor,
You were exactly right. I do not think I would have caught that at all.
I had been going down the wrong path of thinking “Unknown username” was
referring to the way I was referring to my own package.
I am very grateful, but I must add that I got more enjoyment out of Duncan’s
quip.
Mark
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
> On Jul 13, 2018, at 7:17 PM, Gábor Csárdi wrote:
>
> Hi Mark,
>
> seems like you have "Remotes: covr" in the DESCRIPTION file, which is
> not a valid remote specification:
> https://github.com/rmsharp/nprcmanager/blob/f93e4e8056a8602654a94fc8685d9ed722c74db1/DESCRIPTION#L31-L32
>
> If you need the CRAN version of covr, remove the Remotes entry. If you
> need the GH version, use r-lib/covr
>
> Gabor
> On Fri, Jul 13, 2018 at 9:41 PM R. Mark Sharp wrote:
>>
>> I had a few week development hiatus with github.com/rmsharp/nprcmanager and
>> when I tried to get a Travis build to work it failed. All of my local builds
>> are working without errors or warnings, but the
>> devtools::install_github(“rmsharp/nprcmanager”) fails with this error message
>>
>>
>>> library(devtools)
>>> install_github("rmsharp/nprcmanager")
>> Downloading GitHub repo rmsharp/nprcmanager@master
>> from URL https://api.github.com/repos/rmsharp/nprcmanager/zipball/master
>> Installing nprcmanager
>> Installation failed: Unknown username.
>>
>> Two other packages of mine, one private rmsharp/renameSurgerySheets, and one
>> public rmsharp/rmsutilityr both install fine.
>>
>> Does anyone know what I may have broken or how?
>>
>> Mark
>> R. Mark Sharp, Ph.D.
>> Data Scientist and Biomedical Statistical Consultant
>> 7526 Meadow Green St.
>> San Antonio, TX 78251
>> mobile: 210-218-2868
>> rmsh...@me.com
>>
>> __
>> 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] Getting error: Installation failed: Unknown username with my package
I had a few week development hiatus with github.com/rmsharp/nprcmanager and
when I tried to get a Travis build to work it failed. All of my local builds
are working without errors or warnings, but the
devtools::install_github(“rmsharp/nprcmanager”) fails with this error message
> library(devtools)
> install_github("rmsharp/nprcmanager")
Downloading GitHub repo rmsharp/nprcmanager@master
from URL https://api.github.com/repos/rmsharp/nprcmanager/zipball/master
Installing nprcmanager
Installation failed: Unknown username.
Two other packages of mine, one private rmsharp/renameSurgerySheets, and one
public rmsharp/rmsutilityr both install fine.
Does anyone know what I may have broken or how?
Mark
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
