Re: [R-pkg-devel] download.file and https
Hi Paul,
On Thu, Jul 2, 2015 at 9:46 PM, Paul Gilbert wrote:
> (This problem with download.file() affects quantmod, and possibly several
> other packages. e.g. getSymbols('M2',src='FRED') fails.)
>
Thanks for the note. I'm aware of this, and actually wanted to ask
this list what the "best practice" was for downloading files from
https URLs.
> I think the St Louis Fed has moved to using https for connections, and I
> believe all the US government web sites are doing this. An http request is
> automatically switched to https. The default download.file method does not
> seem to handle this, but method="wget" does:
>
IIUC, only if your system has wget installed and it is on the search
path. Another user has suggested setting method="curl", but that has
the same limitations. I could use RCurl to access these files from
FRED, but I'd prefer a solution that doesn't require an additional
package dependency, if possible.
I don't have a lot of experience with downloading from https URLs in R
(especially on Windows) so I would really appreciate some pointers on
how best to handle this.
>> tmp <- tempfile()
>>
>> download.file("http://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv";,
>> destfile = tmp)
> trying URL
> 'http://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv'
> Error in
> download.file("http://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv";,
> :
> cannot open URL
> 'http://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv'
>>
>>
>>
>> download.file("http://research.stlouisfed.org/fred2/series/M2/downloaddata/M2.csv";,
>> destfile = tmp, method="wget")
> [34519]
>
> Paul
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] "Imports" for seemingly "base" functions/libraries
On Fri, Jul 10, 2015 at 4:23 PM, Wayne Taylor wrote: > Good afternoon, > > I received results from a package development check. On some platforms, I > receive numerous errors such as: > > [my own function]: no visible global function definition for ‘boxplot’ > [my own function]: no visible binding for global variable ‘quantile’ > [my own function]: no visible global function definition for ‘bxp’ > > To be clear, some of my functions call boxplot, quantile, and bxp - I am > not rewriting these functions. To correct these errors, should I adding > "graphics" and "stats" to the "Imports:" statement in the DESCRIPTION file > (the libraries associated with these functions)? I am a bit surprised that > we would also need to add these common "base" libraries to the Imports > statement, but I wanted to double check with the experts. I noticed these > errors occur only on the "developer" versions of the platforms, so it seems > that they are running a more stringent test. Thanks, > Yes, this is expected. See: http://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2015/06/29#n2015-06-29 And an earlier email on this list: https://stat.ethz.ch/pipermail/r-package-devel/2015q2/000171.html > Wayne > > -- > Wayne Taylor > PhD Candidate in Marketing > UCLA Anderson School of Management > wayne.taylo...@anderson.ucla.edu > > [[alternative HTML version deleted]] > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Working with connections
On Sun, Aug 9, 2015 at 8:59 AM, Glenn Schultz wrote:
> Hi All,
>
> I use connections to open and close data folders needed by my package.
> After each function closes I get the following warnings (depending on the
> connection that has been opened).
>
> 10: closing unused connection 3
> (/Library/Frameworks/R.framework/Versions/3.2/Resources/library/BondLab/BondData/bondlabMBS4.rds)
>
> Below is the connection function that is related to the above warning:
>
> #
> #' A connection function to BondData calling MBS cusps
> #'
> #' Opens a connection to the BondData folder to call MBS cusip data
> #' @param MBS.id A character string the MBS.id or cusip number current
> MBS.id is supported
> #' @export
> MBS <- function(MBS.id = "character"){
> MBS.Conn <- gzfile(description = paste(system.file(package
> = "BondLab"),
> "/BondData/", MBS.id, ".rds", sep = ""), open
> = "rb")
> MBS <- readRDS(MBS.Conn)
> return(MBS)
> close.connection(MBS.Conn)
> }
>
> I have googled this warning and it seems to be triggered when a function
> terminates and the connection is open. But, I think the connection function
> closes the connection once the object is returned. What am I doing wrong?
>
Your call to return() exits the function, so the close.connection()
call is never evaluated. Considering using on.exit() to close the
connection, since it will close the connection regardless of how the
function exits (e.g. because of an error).
> -Glenn
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Working with connections - What is correct?
On Mon, Aug 10, 2015 at 10:18 PM, Glenn Schultz wrote:
> Hi Dirk,
> Thanks for your response, I get the point on return(). For me, it is a
> security blanket - I just need to let that go rather than justify keeping
> it. I will refactor the connections and just get comfortable without
> return().
>
I'm not sure you get Dirk's point about return(). He did not suggest
that you avoid using return(). He provided a simple example to
illustrate that code in a function body that occurs after a call to
return() is not evaluated. There is nothing inherently wrong with
using return(). The only thing that was wrong was how you used it.
> Thanks,
> Glenn
>
>
> On Aug 10, 2015, at 09:59 PM, Dirk Eddelbuettel wrote:
>
>
> On 11 August 2015 at 02:09, Glenn Schultz wrote:
> | All,
> | Is my function just plain wrong or is it just programming style? I use
> connections because SODA (software for data analysis) recommends using
> connections when working with serialized files.
>
> Nothing wrong with connections. Many of us use them.
>
> | First, after researching the use of return() - following Joshua's comment
> and others I found a post on SO regarding return().
> http://stackoverflow.com/questions/11738823/explicitly-calling-return-in-a-function-or-not
>
> Let's try once more. The function foo()
>
> foo <- function() {
> x <- 2
> return(x)
> x <- 3
> }
>
> will return what value? Ie what does 'print(foo())' show?
>
> | Second, Hadley's point regarding the use of RDS in gz function being a
> little strange. Following the help files the function is fashioned after the
> following which I found in R help files:
>
> IIRC what Hadley was trying to say what you do _not_ need to compress before
> inserting into a rds file as the rds file format compresses by default.
>
> In other words compression comes for free, and effortlessly so.
>
> Hth, Dirk
>
> | ## Less convenient ways to restore the object
> | ## which demonstrate compatibility with unserialize()
> | con <- gzfile("women.rds", "rb")
> | identical(unserialize(con), women)
> | close(con)
> | con <- gzfile("women.rds", "rb")
> | wm <- readBin(con, "raw", n = 1e4) # size is a guess
> | close(con)
> | identical(unserialize(wm), women)
> | | With respect to the first, I understand why my function would be
> considered "buggy" - that can be fixed. It is the case, generally speaking,
> one does not need return() when programming in R; it is a functional
> language. However, some use return() and one finds return(value) in the R
> help files. Is it a strict no-no to use return()?
> | | With respect to the second, The function can be refactored and reduced
> to readRDS(). My question, is using gz file overkill or just plain wrong?
> | What is considered "best practice"?
> | | -Glenn
> | | | On Aug 09, 2015, at 09:04 AM, Joshua Ulrich
> wrote:
> | | On Sun, Aug 9, 2015 at 8:59 AM, Glenn Schultz
> wrote:
> | Hi All,
> | | I use connections to open and close data folders needed by my package.
> | After each function closes I get the following warnings (depending on the
> | connection that has been opened).
> | | 10: closing unused connection 3
> |
> (/Library/Frameworks/R.framework/Versions/3.2/Resources/library/BondLab/BondData/bondlabMBS4.rds)
> | | Below is the connection function that is related to the above warning:
> | |
> #
> | #' A connection function to BondData calling MBS cusps
> | #'
> | #' Opens a connection to the BondData folder to call MBS cusip data
> | #' @param MBS.id A character string the MBS.id or cusip number current
> | MBS.id is supported
> | #' @export
> | MBS <- function(MBS.id = "character"){
> | MBS.Conn <- gzfile(description = paste(system.file(package
> | = "BondLab"),
> | "/BondData/", MBS.id, ".rds", sep = ""), open
> | = "rb")
> | MBS <- readRDS(MBS.Conn)
> | return(MBS)
> | close.connection(MBS.Conn)
> | }
> | | I have googled this warning and it seems to be triggered when a function
> | terminates and the connection is open. But, I think the connection
> function
> | closes the connection once the object is returned. What am I doing wrong?
> | | Your call to return() exits the function, so the close.connection()
> | call is never evaluated. Considering using on.exit() to close the
> | connection, since it will close the connection regardless of how the
> | function exits (e.g. because of an error).
> | | -Glenn
> | _
Re: [R-pkg-devel] Class with functions as slots
On Wed, Nov 18, 2015 at 7:35 PM, Glenn Schultz wrote:
> All,
>
> I have the following class with slots as functions. For the analysis of MBS
> this is good set-up as it allows for a very clean and modular way of
> handling things. My question is really geared to understanding what is
> happening in R.
>
> Below is the function without sato = NULL R CMD throws a warning global
> variable not defined. With SATO = NULL I do not get the warning. Why only
> sato and not two and ten which are also inputs?
>
You use sato in the yr15 function even though it is not an argument to
the function. Did you forget to add it as an argument to the yr15
function?
> Glenn
>
> # Bond Lab is a software application for the analysis of # fixed income
> securities it provides a suite of applications
> # in addition to standard fixed income analysis bond lab provides # for the
> specific analysis of structured products residential mortgage backed
> securities, # asset backed securities, and commerical mortgage backed
> securities
> # License GPL3 + File License
> # Copyright (C) 2014 Glenn M Schultz, CFA
>
> #' An S4 class whose slots are functions used to propogate
> #' the mortgage rate used to motivate the prepayment model
> #' @slot yr30 A function defining the 30-year mortgage rate as a function
> #' of the 2- and 10-year swap rate
> #' @slot yr15 A function defining the 15-year mortgage rate as a function
> #' of the 2- and 10-year swap rate #' @export MortgageRate
>
> setClass("MortgageRate",
> representation(
> yr30 = "function",
> yr15 = "function"))
>
> #' A constructor function for the class Mortgage Rate
> MortgageRate <- function(){
> sato = NULL
> new("MortgageRate",
> yr30 = function(two = numeric(), ten = numeric(), sato = numeric()) {
> 2.25 + (.06 * two) + (.75 * ten) + sato},
>
> yr15 = function(two = numeric(), ten = numeric()){
> 1.75 + (.06 * two) + (.75 * ten) + sato}
> )}
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Is it possible to reverse engineer a package from the installed library directory ?
On Wed, Mar 23, 2016 at 9:25 PM, Ben Bolker wrote:
>
> You could take your old install and do this:
>
> library("your_package")
> funs <- ls(pos="package:your_package")
> dump(funs,"your_package.R")
>
> that wouldn't recreate documentation, NAMESPACE files, etc., but it would
> be a start.
>
You might be able to recreate the Rd files using the answers to this
StackOverflow question: http://stackoverflow.com/q/7493843/271616
Using the example in my answer as a starting point:
sink(file="survey.Rd")
utils:::.getHelpFile(as.character(help(survey,package="MASS")))
sink()
It might still need some formatting clean-up, but hopefully that gets
you 80-90% of the solution.
>
> On 16-03-23 04:43 PM, Paul Hurley wrote:
>>
>> Several years ago I assembled some of my own most used code into a
>> package,
>> and had that installed on my machine. Since then I have lost the source
>> files, but still have the package installed in an old v2.x R installation.
>>
>> I now need to use the package in my current R install, which is v3.1, and
>> won't let me just copy the directory across, as it complains it was build
>> pre v3. Is it possible to reverse engineer a package back to R source
>> files so I can then rebuild it in a new package ?
>>
>> Thanks
>>
>> Paul.
>>
>> --http://www.paulhurley.co.uk
>>
>> [[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
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2016 | www.rinfinance.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [R-SIG-Finance] [VC++ calling R] How to create a real-time interactive ticking time-series chart using dygraph via RInside?
Please choose *one* _relevant_ mailing list. Spamming 5 (!)
mailing lists fragments the conversation and makes things difficult
for everyone involved.
On Mon, Apr 11, 2016 at 10:03 AM, Mike Deanza wrote:
> Hi all,
>
>
> I am trying to figure out how to do this in R and I need your help.
>
>
> My journey started from something like the following:
>
>
> http://stackoverflow.com/questions/11365857/real-time-auto-updating-incremental-plot-in-r/1#1
>
>
> n=1000
> df=data.frame(time=1:n,y=runif(n))
> window=100
> for(i in 1:(n©\window)) {
> flush.console()
> plot(df$time,df$y,type='l',xlim=c(i,i+window))
> Sys.sleep(.09)
> }
>
>
> Then I wanted to make it nicer looking so I went to dygraph.
>
>
> And then, I would like to be able to live send tick data from within Visual
> C++ so I started to investigate RInside.
>
>
> Following the example code here:
>
>
> http://dirk.eddelbuettel.com/papers/useR2009RcppRInside.pdf
>
>
> I can open an RInside object in VC++, and then send some data to it, and then
> execute some command in it, and then get data back.
>
>
> It is really great.
>
>
> However, is there a way to have the real-time updating ticking plots to be
> drawn on dygraph inside RInside?
>
>
> It turns out the dygraph package tends to draw onto a browser. That makes the
> real-time updating pretty slow.
>
>
> Is there a way to set the dygraph to plot to a GUI window in VC++? For
> example, a QT or MFC GUI window?
>
>
> My working environment is Win7 64bit ,with VS 2013 and VS2015, QT 5.3 32bit.
>
>
> Could anybody please shed some lights on me?
>
>
> Thanks a lot!
>
>
>
>
>
>
>
> [[alternative HTML version deleted]]
>
>
> ___
> r-sig-fina...@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> -- Subscriber-posting only. If you want to post, subscribe first.
> -- Also note that this is not the r-help list where general R questions
> should go.
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2016 | www.rinfinance.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Handling Not-Always-Needed Dependencies?
On Tue, Aug 2, 2016 at 11:26 AM, Thomas J. Leeper wrote:
> I have a fairly open-ended question about the handling of package
> dependencies that is inspired by the precise distinction between
> "Depends", "Imports", and "Suggests" listed in DESCRIPTION.
>
> Some background, as I understand it: Prior to requiring package
> namespaces, we listed package dependencies in "Depends" because the
> required package had to be (1) installed and (2) on the search path in
> order to access its functions. After introducing and requiring
> namespaces, there are very few circumstances in which "Depends" is
> needed because functions from the required package can either be
> imported (via "Imports" and NAMESPACE) and/or referred to using the
> `pkg::fun()` style. "Suggests" packages are maybe needed for examples,
> vignettes, etc. but are not installed by default via
> `install.packages()`, so are not guaranteed to be available.
>
> Some observations:
>
> 1. "Depends" seems to be less useful than before, except in rare cases
> where a package needs to be (a) installed, (b) loaded, and (c) on the
> search path. Imports covers most package dependency use cases.
>
> 2. There is a gap in functionality between "Imports" and "Suggests".
> Sometimes there is a need for functions that should be available
> (i.e., installed) but do not need to be loaded or imported because
> they are rarely used (e.g., graphing functions). Importing the
> functions adds bloat but only putting their package in "Suggests" does
> not guarantee availability when, for example, calling
> `requireNamespace()` or `require()`.
>
Maybe I'm missing something, but isn't that the point of calling
requireNamespace()? For example:
if (requireNamespace("suggestedPackage"))
stop("suggestedPackage required but not installed")
That doesn't seem like a heavy burden for package writers when writing
infrequently used functions in their package. You could even add the
install.packages command to the error message to instruct users to
install the required package.
> Suggestion:
>
> Might it be useful to have a category between "Imports" and "Suggests"
> that covers packages that should be installed but not imported?
>
> This could be done by changing `install.packages()` to cover
> "Suggests" by default, changing the meaning of "Depends" and
> "Imports", or adding a new category to DESCRIPTION.
>
I personally would not want install.packages() to install packages I'm
unlikely to actually use.
It's also not clear to me how importing rarely used functions causes
bloat, but installing all packages for all rarely-used functions does
not cause bloat.
> I am interested in hearing your thoughts on this issue.
>
> Best,
> -Thomas
>
> Thomas J. Leeper
> http://www.thomasleeper.com
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2016 | www.rinfinance.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] robust download function in R (similar to wget)?
Try downloader: https://cran.r-project.org/package=downloader On Thu, Aug 25, 2016 at 7:47 AM, Lucas Ferreira Mation wrote: > I am creating this package <https://github.com/lucasmation/microdadosBrasil> > that has to download data from some sources that are a bit > unstable/unreliable. The problem is described in this issue > <https://github.com/lucasmation/microdadosBrasil/issues/56>. > > Is there a more "robust" download fucntion in R? > Something similar to wget, that would: > > - where there are errors, repeat the download a few times before giving up, > preferably, using partial data on a file being downloaded from previous > attempts > - check the integrity of the downloaded file > > As this has to be embedded in an R package, the solution needs to be OS > independent and require no installation of external software by the user. > > regards > Lucas > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2016 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Need to call strptime() with specific LC_TIME
Hi,
I'm looking for any guidance/best-practices about how to deal with an
issue a quantmod user ran into an issue when calling
getSymbols.google():
https://github.com/joshuaulrich/quantmod/issues/140
Google provides a CSV where the dates are specified using English
month abbreviations. Converting the characters to Date does not work
in any locale that doesn't use those abbreviations.
So I need to call strptime() in a locale that uses English month
abbreviations. Is there a better solution than this?
lc_time <- Sys.getlocale("LC_TIME")
Sys.setlocale(category = "LC_TIME", locale = "C")
on.exit(Sys.setlocale(category = "LC_TIME", locale = lc_time)
Thanks!
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2017 | www.rinfinance.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Errors in Package Check Results due to package in Suggestions
Hi Daniel, See section 1.1.3.1 of Writing R Extensions: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Suggested-packages On Tue, Sep 19, 2017 at 2:53 AM, Daniel Lüdecke wrote: > Hi, > > I have a package on CRAN where most check results are OK except two with > errors (one of those two I'm already addressing). > > However, the one of the errors > (https://www.r-project.org/nosvn/R.check/r-release-osx-x86_64/sjstats-00chec > k.html) is because I use the package "rstanarm" for one of the examples, and > running this example fails. What would be an appropriate way to deal with > this issue? My package does not depend on rstanarm, it's "just" a suggestion > because I needed it for the examples. I'm a bit unsure about the status of > these check results. When submitting a package, the maintainer is asked to > address issues from these checks, so I'd like to fix this error. I could, of > course, wrap the example into a "don't run"-section, but this seems to me > like a sloppy hack rather than a proper solution... > > Best > Daniel > > > -- > > _ > > Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; > Gerichtsstand: Hamburg | www.uke.de > Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr. Dr. > Uwe Koch-Gromus, Joachim Prölß, Martina Saurin (komm.) > _ > > SAVE PAPER - THINK BEFORE PRINTING > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2017 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] loadMethod() not available with Rscript
Hi Thierry, On Wed, Sep 20, 2017 at 7:45 AM, Thierry Onkelinx wrote: > Dear all, > > Could someone explain this to me? I have a simple script (see below). > my_function() is an S4 method. The package imports all functions from > methods that it uses. > > When I run the script in a vanilla R session it works. When using > Rscript I get the error: Error in loadMethod(function (x, ...) : > could not find function "loadMethod" > > loadMethod() is NOT used in mypackage and not imported. > Rscript does not load/attach the "methods" package like is done in an interactive R session. Perhaps your package uses a package that needs methods::loadMethod(), but does not import it correctly? > library(mypackage) > my_function() > > Best regards, > > ir. Thierry Onkelinx > Statisticus/ Statiscian > > Vlaamse Overheid / Government of Flanders > INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE > AND FOREST > Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance > thierry.onkel...@inbo.be > Kliniekstraat 25, B-1070 Brussel > www.inbo.be > > /// > To call in the statistician after the experiment is done may be no > more than asking him to perform a post-mortem examination: he may be > able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher > The plural of anecdote is not data. ~ Roger Brinner > The combination of some data and an aching desire for an answer does > not ensure that a reasonable answer can be extracted from a given body > of data. ~ John Tukey > /// > > > Van 14 tot en met 19 december 2017 verhuizen we uit onze vestiging in > Brussel naar het Herman Teirlinckgebouw op de site Thurn & Taxis. > Vanaf dan ben je welkom op het nieuwe adres: Havenlaan 88 bus 73, 1000 > Brussel. > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2017 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Storing Data Used in an Example
On Wed, Sep 20, 2017 at 11:32 AM, Roy Mendelssohn - NOAA Federal wrote: > Hi All: > > I have a package whose main function is to download environmental data using > a service. I have added some plot routines, As it is, my examples of just > the downloads push the CRAN limits on time, so I want the plot examples to > use data that has already been downloaded and stored as part of the package. > > Questions: > > 1. Most appropriate place to store the example data (they will be .RData > files). > https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Data-in-packages > 2. What size of data set is considered to be getting too large to be > appropriate to include in a package. > The CRAN Repository Policy says: "As a general rule, neither data nor documentation should exceed 5MB (which covers several books). A CRAN package is not an appropriate way to distribute course notes, and authors will be asked to trim their documentation to a maximum of 5MB." > 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 -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2017 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] spurious rchk warning
On Mon, Nov 20, 2017 at 8:34 PM, Patrick Perry wrote: > One of my packages has what I believe to be spurious rchk warnings: > > From > https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/utf8.out > > Package utf8 version 1.1.0 > Package built using 73757/R 3.5.0; x86_64-pc-linux-gnu; 2017-11-20 22:02:23 > UTC; unix > Checked with rchk version 63f79d910f5835174fcaa5a0a7d2409348f7d2ac > More information at > https://github.com/kalibera/cran-checks/blob/master/rchk/PROTECT.md > > Function rutf8_as_utf8 > [UP] unprotected variable ans while calling allocating function > R_CheckUserInterrupt utf8/src/as_utf8.c:68 > [UP] unprotected variable ans while calling allocating function > rutf8_translate_utf8 utf8/src/as_utf8.c:83 > [UP] unprotected variable ans while calling allocating function > Rf_mkCharLenCE utf8/src/as_utf8.c:117 > > The offending function is at > https://github.com/patperry/r-utf8/blob/master/src/as_utf8.c#L46 > > I tried to fix the warning in line 64 with > > PROTECT(ans = sx); nprot++; > > This did not work. Any suggestions? > My hypothesis is that your PROTECT and UNPROTECT calls inside the for loop are leaving 'ans' unprotected at some point. Consider using PROTECT_WITH_INDEX() and REPROTECT() instead. > Thanks, > > > Patrick > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2017 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Installing Tests with R Build
On Wed, Nov 22, 2017 at 4:21 PM, Bill Denney wrote: > Hi, > > I have a package that I'm trying to make a validation vignette for. The > validation vignette is intended to assist users with documentation that the > tests work. > > When running R BUILD now (via Travis CI), I get an error that the build > failed trying to build the vignettes. For R CMD install, I can add > --install-tests. Is there a way to control R BUILD so that the installation > includes test installation? > Put the tests you want to install into a directory inside the inst/ directory (e.g. inst/tests/). That directory will be copied to the top-level of the installed package directory. > Thanks, > > Bill > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2017 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Installing Tests with R Build
On Thu, Nov 23, 2017 at 10:05 AM, Bill Denney wrote:
> Hi Joshua and Dirk,
>
>> On Nov 23, 2017, at 10:17, Dirk Eddelbuettel wrote:
>>
>>
>> On 23 November 2017 at 08:07, Joshua Ulrich wrote:
>> | On Wed, Nov 22, 2017 at 4:21 PM, Bill Denney wrote:
>> | > When running R BUILD now (via Travis CI), I get an error that the build
>> failed trying to build the vignettes. For R CMD install, I can add
>> --install-tests. Is there a way to control R BUILD so that the installation
>> includes test installation?
>> | >
>> | Put the tests you want to install into a directory inside the inst/
>> | directory (e.g. inst/tests/).
>>
>> Which happens to be the default mode of operations with RUnit.
>>
>> And it is a feature that I happen to _like_ a great deal because it permits
>> testing of the _installed_ package which is something you need in real life
>> when eg some of you system libraries may have change.
>
> Putting the tests there seems like a very reasonable solution to the
> immediate issue. It contravenes the options to install (or not install)
> tests ("R CMD INSTALL --install-tests" loses meaning). I'm going to update
> the structure of my vignette so that it detects if the tests are there and
> builds the vignette based on the existence of the tests (making it say
> "Please install the tests following these instructions...").
>
> I'm immediately ok with reworking the directory structure and tests, but I
> think it would be preferable long run to:
> Have R CMD BUILD gain an --install-args option so that installation arguments
> can be controlled (for situations like this and I'm sure others).
>
I just took a closer look at this, and I don't understand why any
change is necessary. With a package created by package.skeleton():
josh@thinkpad: ~/git
> R CMD build anRpackage
* checking for file 'anRpackage/DESCRIPTION' ... OK
* preparing 'anRpackage':
* checking DESCRIPTION meta-information ... OK
* installing the package to process help pages
* saving partial Rd database
* creating vignettes ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building 'anRpackage_1.0.tar.gz'
josh@thinkpad: ~/git
> tar -ztf anRpackage_1.0.tar.gz
anRpackage/DESCRIPTION
anRpackage/NAMESPACE
anRpackage/R/
anRpackage/R/file.R
anRpackage/build/
anRpackage/build/partial.rdb
anRpackage/build/vignette.rds
anRpackage/inst/
anRpackage/inst/doc/
anRpackage/inst/doc/file.Rnw
anRpackage/inst/doc/file.pdf
anRpackage/man/
anRpackage/man/anRpackage-package.Rd
anRpackage/tests/
anRpackage/tests/unittests.R
anRpackage/vignettes/
anRpackage/vignettes/file.Rnw
The package builds successfully, and the tests are still in their
tests/ directory. Now if I install without the --install-tests flag:
josh@thinkpad: ~/git
> R CMD INSTALL anRpackage_1.0.tar.gz 2>/dev/null
josh@thinkpad: ~/git
> ls -l ~/R/library/anRpackage/
total 32
-rw-r--r-- 1 josh josh 420 Nov 25 08:16 DESCRIPTION
drwxr-xr-x 2 josh josh 4096 Nov 25 08:16 doc
drwxr-xr-x 2 josh josh 4096 Nov 25 08:16 help
drwxr-xr-x 2 josh josh 4096 Nov 25 08:16 html
-rw-r--r-- 1 josh josh 59 Nov 25 08:16 INDEX
drwxr-xr-x 2 josh josh 4096 Nov 25 08:16 Meta
-rw-r--r-- 1 josh josh 72 Nov 25 08:16 NAMESPACE
drwxr-xr-x 2 josh josh 4096 Nov 25 08:16 R
You can see there's no tests/ directory. Now with the --install-tests flag:
josh@thinkpad: ~/git
> R CMD INSTALL anRpackage_1.0.tar.gz --install-tests 2>/dev/null
josh@thinkpad: ~/git
> ls -l ~/R/library/anRpackage/
total 36
-rw-r--r-- 1 josh josh 420 Nov 25 08:17 DESCRIPTION
drwxr-xr-x 2 josh josh 4096 Nov 25 08:17 doc
drwxr-xr-x 2 josh josh 4096 Nov 25 08:17 help
drwxr-xr-x 2 josh josh 4096 Nov 25 08:17 html
-rw-r--r-- 1 josh josh 59 Nov 25 08:17 INDEX
drwxr-xr-x 2 josh josh 4096 Nov 25 08:17 Meta
-rw-r--r-- 1 josh josh 72 Nov 25 08:17 NAMESPACE
drwxr-xr-x 2 josh josh 4096 Nov 25 08:17 R
drwxr-xr-x 2 josh josh 4096 Nov 25 08:17 tests
The tests/ directory is present, and I can run the tests:
josh@thinkpad: ~/git
> Rscript -e 'tools::testInstalledPackage("anRpackage")'
Testing examples for package 'anRpackage'
Running specific tests for package 'anRpackage'
Running 'unittests.R'
Running vignettes for package 'anRpackage'
Running 'file.Rnw'
Someone could probably give you specific advice if you share a link to
the code and/or TravisCI log(s).
> Thank you (and Happy Thanksgiving to those celebrating it),
>
> Bill
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2017 | www.rinfinance.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Conditionally register method with generic in other package
I have a feeling I know the answer to this question, but I'm asking with the hope that I learn something new. Package A defines a S3 generic function, "foo()". Package B defines a S3 class "bar", and a foo.bar() method. This method is not strictly necessary for the package to function, and package A has many dependencies. To avoid excessive dependencies, I would like to only register foo.bar() if package A is installed at the time package B is installed. If package A is installed after package B, then warn the user when package B is loaded and/or attached, so they can re-install A and have foo.bar() registered correctly. I could figure out a way to do this manually, but doubt it would be CRAN-approved. What is the recommended way to handle this situation? I've received one suggestion to split B into 2 packages: one without the method, and one with. Are there other alternatives? Thanks, Josh -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2018 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Conditionally register method with generic in other package
Bill, Duncan,
Thanks for the replies.
On Wed, Dec 6, 2017 at 12:51 PM, Duncan Murdoch
wrote:
> On 06/12/2017 8:44 AM, Bill Denney wrote:
>>
>>
>>> On Dec 6, 2017, at 07:45, Joshua Ulrich wrote:
>>>
>>> To avoid excessive dependencies, I would like to only register
>>> foo.bar() if package A is installed at the time package B is
>>> installed. If package A is installed after package B, then warn the
>>> user when package B is loaded and/or attached, so they can re-install
>>> A and have foo.bar() registered correctly.
>>
>>
>> One simple solution would be to wrap the instantiation of foo.bar in a
>> require test:
>>
>> if (require(A)) {
>>foo.bar <- function(...) {
>> print("To be or not to be")
>>}
>> } else {
>>message("To use the foo.bar function, please install package A.")
>> }
>>
>
> It's usually better to use requireNamespace("A") instead of require("A")
> (and the quotes are needed in requireNamespace(), but optional in
> require()). That tries to load the package, but doesn't mess with the search
> list.
>
> But that'll likely cause warnings, unless the same condition is used in the
> NAMESPACE file where there should be an entry
>
> S3method(foo, bar)
>
> The thing is, I'm not sure if
>
> if (requireNamespace("A"))
> S3method(foo, bar)
>
> is legal in a NAMESPACE file.
>
While perhaps not technically illegal, that doesn't work because you need
if (requireNamespace("A", quietly = TRUE)) {
importFrom(A, foo)
S3method(foo, bar)
}
to prevent an error about being able to find object 'foo' when loading
B's namespace. But the importFrom() causes R CMD check to expect a
hard dependency on package A (and all its dependencies), which is what
I'm trying to avoid...
> Duncan Murdoch
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2018 | www.rinfinance.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Searching examples in source code
Hi Ben, On Sat, May 7, 2022 at 4:24 PM Ben Engbers wrote: > > Hi, > > My package (RBaseX) is written entirely in R. The performance is not bad > but to further improve the performance I want to investigate to what > extent use of C++ makes sense. Problem is that I have little experience > with C++ and none with Rcpp. So I am looking for examples. > On my (linux) system I installed several packages that needed to be > compiled. So it is likely that I already have examples on my system. > I strongly recommend you profile your code to determine where there are performance bottlenecks before writing any new code. Especially before adding compiled code to your package. The infamous Knuth quote: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified." Best, Josh > My first question is if there is a useful linux command to search all > the source code of installed packages on my system. > The second question is if there is a command to search all packages at > https://cran.r-project.org/web/packages/available_packages_by_name.html? > > This question is not only relevant to C++ examples. It would also be > nice if you could search for occurrences of commands in R code. > > Ben > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Rd cross-references to Suggested package
Hi all,
I'd like to link to a help page of a package in my package's Suggests.
WRE, section 2.5 says,
"Historically (before R version 4.1.0), links of the form
\link[pkg]{foo} and \link[pkg:bar]{foo} used to be interpreted as
links to files foo.html and bar.html in package pkg, respectively. For
this reason, the HTML help system looks for file foo.html in package
pkg if it does not find topic foo, and then searches for the topic in
other installed packages. To test that links work both with both old
and new systems, the pre-4.1.0 behaviour can be restored by setting
the environment variable _R_HELP_LINKS_TO_TOPICS_=false.
"Packages referred to by these ‘other forms’ should be declared in the
DESCRIPTION file, in the ‘Depends’, ‘Im
ports’, ‘Suggests’ or ‘Enhances’ fields."
This seems to imply that it's possible... though I don't understand
when I need to set _R_HELP_LINKS_TO_TOPICS_=false in order to test
that the link is done correctly. I'm using \link[pkg]{foo} in R 4.2.1.
I ran R CMD build/INSTALL/check with and without that env var set to
false. Both times the suggested package was not installed on my
library path, so I had to set _R_CHECK_FORCE_SUGGESTS_=false for R CMD
check --as-cran.
I didn't notice a difference in output from R CMD check. Both runs had:
* checking Rd cross-references ... NOTE
Package unavailable to check Rd xrefs: ‘timeSeries’
I'd appreciate any thoughts and/or pointers to other documentation.
Best,
Josh
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Tools for reducing dependencies?
Hi Duncan, On Sun, Mar 12, 2023 at 6:34 AM Duncan Murdoch wrote: > > The rgl package has a really large number of dependencies, especially if > I include soft (Suggested) dependencies. It would be nice to reduce > that number. > > To do that, I can imagine a tool that gives the following information: > > - For each export from rgl, which dependencies are needed? > > - For each dependency, which exports are supported? > > - Are there other ways to get the same support with fewer > dependencies? E.g. if rgl used devtools::install_github, it could be > replaced with remotes::install_github. > > Does a tool already exist that addresses these questions? > I've never used it, but there's some relevant functionality in https://github.com/r-lib/itdepends Best, Josh > Duncan Murdoch > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Replacing dplyr by stats functions
On Wed, Apr 19, 2023 at 9:19 AM A. Kucharski wrote: > > Hi, > > I am developing my own package. I have a problem with its new version. > Checking on the CRAN server gives 2 warnings like this (critpath is my > package): > Warning: replacing previous import 'dplyr::lag' by 'stats::lag' when loading > 'critpath' > Warning: replacing previous import 'dplyr::filter' by 'stats::filter' when > loading 'critpath' > > On my machine these warnings show up during Check but before Build starts so > at the end I get a message that the number of warnings is 0. I don't use lag > or filter at all in my package although I use both of these packages. > Reordering the dplyr and stats package names in the Depends of the > Description file didn't help. Is it a problem with my code or a conflict > between those two packages? Please help me remove these warnings. > It's a conflict between stats and dplyr. The dplyr lag() function masks the base R stats lag() generic, which breaks S3 method dispatch for every package that has a lag() method when dplyr is attached. You should use Imports instead of Depends unless you need the package attached, which is a rare case. The latest version of critpath on CRAN uses `import()` in the NAMESPACE file. That imports every function in the entire package. Use `importFrom()` to import only the functions you use from the package. That should help avoid these types of conflicts. > Best regards > > Adam > > Wysłane z aplikacji Poczta dla systemu Windows > > > [[alternative HTML version deleted]] > > ______ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Segmentation Fault cause 'memory not mapped' on Debian only
Hi David, In addition to running under valgrind as Dirk suggests below, you should also run under UBSAN and ASAN. You can do all 3 (and more) using Winston Cheng's docker images: https://github.com/wch/r-debug/ That should help you narrow down the problematic code. Best, Josh On Fri, Apr 21, 2023 at 2:33 PM Dirk Eddelbuettel wrote: > > > Hi David, > > On 21 April 2023 at 19:17, D Z wrote: > | Hi all, > | I wanted to publish my RITCH package (https://github.com/DavZim/RITCH) to > CRAN, which has Rcpp code. > > That would be great! > > | It has, in it’s CICD Pipeline, Tests for Macos, Windows, and Ubuntu (devel, > release,, and oldrel-1), which all succeed on Github Actions. > | When I submitted the package to CRAN, I was notified, that I got the > following error on Debian (the tests on Windows throw no such bug, neither do > the Github Actions tests): > | > | > |*** caught segfault *** > | > | address 0x55939b7ca000, cause 'memory not mapped' > | > | Segmentation fault > | > | The full Report is currently available here: > https://win-builder.r-project.org/incoming_pretest/RITCH_0.1.14_20230420_223157/Debian/00check.log > (note the error happens in the test_filter_itch.R unit tests). > | > | I looked for the error online but couldn’t find anything useful, and as I > am not able to reproduce the segfault locally, cannot debug it. > | Do you have any ideas or hunches what might cause this and how to resolve > it? > > "Absence of error" on one platform does proove correctness on all, the hint > from the segfault should be taken seriously. I just updated my older > checkout of your repo, built a current tarball and simply invoked > >R CMD check --use-valgrind RITCH_0.1.14.tar.gz > > which you could do on CI too (I can help as needed, I would also pull the CI > runners forward from Ubuntu 20.04 to 22.04). When we do the above, the > examples output file RITCH-Ex.Rout ends in > > ==2269271== LEAK SUMMARY: > ==2269271==definitely lost: 1,363,969 bytes in 5,473 blocks > ==2269271==indirectly lost: 177,235 bytes in 1,281 blocks > ==2269271== possibly lost: 101,924,267 bytes in 148 blocks > ==2269271==still reachable: 89,572,890 bytes in 17,950 blocks > ==2269271== suppressed: 0 bytes in 0 blocks > ==2269271== Reachable blocks (those to which a pointer was found) are not > shown. > ==2269271== To see them, rerun with: --leak-check=full --show-leak-kinds=all > ==2269271== > ==2269271== ERROR SUMMARY: 30 errors from 30 contexts (suppressed: 0 from 0) > > and the tests end in > > ==2273761== LEAK SUMMARY: > ==2273761==definitely lost: 5,223,981 bytes in 141,151 blocks > ==2273761==indirectly lost: 2,241,700 bytes in 2,767 blocks > ==2273761== possibly lost: 1,201,493,644 bytes in 270 blocks > ==2273761==still reachable: 133,909,136 bytes in 19,110 blocks > ==2273761== suppressed: 0 bytes in 0 blocks > ==2273761== Reachable blocks (those to which a pointer was found) are not > shown. > ==2273761== To see them, rerun with: --leak-check=full --show-leak-kinds=all > ==2273761== > ==2273761== ERROR SUMMARY: 43 errors from 39 contexts (suppressed: 0 from 0) > > That probably warrants a few more close looks. > > Hth, Dirk > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] LICENSE file in an R package for CRAN submission
On Wed, Aug 16, 2023 at 11:41 AM Vincent Goulet wrote: > > Although late to the party, I thought I might chime in with a different take > on the question. > > Most answers seem to pertain to the actual license used for the package. For > my part, I read the question as: "GitHub wants me to have a LICENSE file at > the root of the repository, but R CMD check complains about it. What should I > do?" > > If you need to use the LICENSE file in your package, Ben Bolker already > pointed you at the correct way to do it. > > If the file is just there to please GitHub (and in any case), here's what I > tend to do: put the source code of your package in a subdirectory (say 'src') > of the repository. You may then put the GitHub files (README.md, LICENSE, > whatever else) at the top level without interfering with R CMD build/check. > The added benefit is that you will then build the package in the directory of > the project (say 'mypkg') with 'R CMD build src' and end up with a file > .../mypkg/mypkg_x.y-z.tar.gz, rather than in the parent directory of 'mypkg'. > Another alternative is put everything you don't want to be included in your package in the .Rbuildignore file. For example: https://github.com/joshuaulrich/xts/blob/main/.Rbuildignore > (Mind you, I build my packages manually. The tidyverse tools may very well > take care of this sort of things automatically and I wouldn't know.) > I also build my packages manually (with a makefile) and have my own personal preferences, so the patterns in my file may need to be changed for others' packages. > Hope this helps, > > v. > > Vincent Goulet > Professeur titulaire > École d'actuariat, Université Laval > > > Le 9 août 2023 à 11:06, Emanuele Cordano a > > écrit : > > > > Dear list, > > > > is there a way to put the LICENSE file within an R package like in Github, > > I have an R package on Github with a a LICENSE file compliant to Github and > > containing the text of the licence citing in the DESCRIPION file. But when > > I check the package , I obatained the following output: > > > > * checking top-level files ... NOTE > > File > > LICENSE > > > > is not mentioned in the DESCRIPTION file. > > > > How can I solve this? > > Thank you > > best > > Emanuele Cordano > > -- > > Emanuele Cordano, PhD > > Environmental Engineer / Ingegnere per l' Ambiente e il territorio nr. > > 3587 (Albo A - Provincia di Trento) > > cell: +39 3282818564 > > email: emanuele.cord...@gmail.com,emanuele.cord...@rendena100.eu, > > emanuele.cord...@eurac.edu > > PEC: emanuele.cord...@ingpec.eu > > URL: www.rendena100.eu > > LinkedIn: https://www.linkedin.com/in/emanuele-cordano-31995333 > > GitHub: https://github.com/ecor > > > > [[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 -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Changing package maintainers
The process is described in the 6th bullet of the "Source Packages"
section of the CRAN Policies:
https://cran.r-project.org/web/packages/policies.html
"When a new maintainer wishes to take over a package, this should be
accompanied by the written agreement of the previous maintainer
(unless the package has been formally orphaned)."
So the current maintainer needs to send CRAN an email with the name
and email address of the new maintainer.
Best,
Josh
On Thu, Feb 8, 2024 at 10:38 AM Josiah Parry wrote:
>
> I intend to change the maintainer of my package {sfdep}
> https://cran.r-project.org/package=sfdep.
> Is the process as simple as submitting a new release where the DESCRIPTION
> file changes who has the role of `aut`?
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [External] RcmdrPlugin.HH_1.1-48.tar.gz
On Wed, Mar 6, 2024 at 1:03 AM Richard M. Heiberger wrote:
>
> Thank you Duncan, Jeff, Ivan.
>
> I did all that Duncan and Jeff suggested, plus a bit more that appeared to be
> necessary.
> All of what I did is documented in the RcmdrPlugin.HH/NEWS file.
>
> Ivan's comments were received after I sent 1.1-50 to CRAN and it was accepted.
>
I recommend you revert all the changes you made that are documented in
the package NEWS, and at minimum follow Ivan's advice to use
exportPattern("^[^\\.]") instead of exportPattern("."). It would be
even better to follow the advice in Writing R Extensions and list each
exported object individually.
> I suggest that my notes in the NEWS file, perhaps augmented with Ivan's
> comments,
> might be added to utils/man/globalVariables.Rd and to the
> "
> section ‘Package
> structure’ in the ‘Writing R Extensions’ manual.
> "
>
That section of Writing R Extensions specifically says not to do what you did.
Beware of patterns which include names starting with a period: some
of these are internal-only variables and should never be exported,
e.g. ‘.__S3MethodsTable__.’ (and loading excludes known cases).
Duncan pointed out that '.__global__' is an internal-only variable
created by globalVariables(), which means it should never be exported
by a package. Imagine the number of conflicts there would be if every
package that used globalVariables() exported the '.__global__'
object... there would probably be thousands, yikes!
It's possible that future versions of 'R CMD check' will error if
there are any incorrectly exported internal variables (like
'.__global__'), which would cause your package to fail.
Best,
Josh
>
> > On Mar 6, 2024, at 01:38, Ivan Krylov wrote:
> >
> > В Tue, 5 Mar 2024 22:41:32 +
> > "Richard M. Heiberger" пишет:
> >
> >> Undocumented code objects:
> >> '.__global__'
> >> All user-level objects in a package should have documentation
> >> entries. See chapter 'Writing R documentation files' in the 'Writing R
> >> Extensions' manual.
> >
> > This object is not here for the user of the package. If you don't
> > export it, there will be no WARNING about it being undocumented. This
> > variable is exported because of exportPattern(".") in the file
> > NAMESPACE. The lone dot is a regular expression that matches any name
> > of an R object.
> >
> > If you don't want to manually list your exports in the NAMESPACE file
> > (which can get tedious) or generate it (which takes additional
> > dependencies and build steps), you can use exportPattern('^[^\\.]') to
> > export everything except objects with a name starting with a period:
> > https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports
> >
> > --
> > Best regards,
> > Ivan
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Conditionally register method with generic in other package
For posterity, the solution I employed did not register the method as a formal S3 method. Functionality in package B was unchanged as long as package B was loaded and attached... which was good enough for my purposes. On Wed, Dec 6, 2017 at 6:45 AM, Joshua Ulrich wrote: > I have a feeling I know the answer to this question, but I'm asking > with the hope that I learn something new. > > Package A defines a S3 generic function, "foo()". Package B defines a > S3 class "bar", and a foo.bar() method. This method is not strictly > necessary for the package to function, and package A has many > dependencies. > > To avoid excessive dependencies, I would like to only register > foo.bar() if package A is installed at the time package B is > installed. If package A is installed after package B, then warn the > user when package B is loaded and/or attached, so they can re-install > A and have foo.bar() registered correctly. > > I could figure out a way to do this manually, but doubt it would be > CRAN-approved. What is the recommended way to handle this situation? > I've received one suggestion to split B into 2 packages: one without > the method, and one with. Are there other alternatives? > > Thanks, > Josh > > -- > Joshua Ulrich | about.me/joshuaulrich > FOSS Trading | www.fosstrading.com > R/Finance 2018 | www.rinfinance.com -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2018 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Help with correcting error in package
On Sat, Feb 3, 2018 at 11:44 AM, Dev Chakraborty wrote:
> Dear All,
>
> I tried unsuccessfully to upload a package named RJafroc to CRAN. On my OSX
> machine it passes R CMD Check with no errors, warnings or notes. However, I
> get the following output from CRAN, from which I cannot tell which function
> is causing the error (I am truncating the intermediate lines, which appear
> to be the opening screen upon starting R, with ellipses; the full output
> produced by the CRAN pre-test is attached):
>
Submit your package to http://win-builder.r-project.org. That will
provide you access to all the output in the Rcheck.RJafroc directory.
Also note that the "Confirmation" step of the submission process
suggests, "You could [run R CMD check] using the win-builder service
at http://win-builder.r-project.org";. And the CRAN Repository Policy
says, "It should be normal for those without Windows machines of their
own to use the winbuilder service to check a package before
submission." You could also use https://builder.r-hub.io/. Both are
great resources for the community.
>
>
> *** running examples for arch 'x64' ... ERROR*
>
>
> *Running examples in 'RJafroc-Ex.R' failed*
>
>
> *The error occurred in:*
>
>
> *R Under development (unstable) (2018-02-01 r74194) -- "Unsuffered
> Consequences"*
>
> *Copyright (C) 2018 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 'q()' to quit R.*
>
>
> *> pkgname <- "RJafroc"*
>
> *> source(file.path(R.home("share"), "R", "examples-header.R"))*
>
>
> Thanking you in advance for any help rendered,
>
> Sincerely,
>
> Dev
>
> --
> Dev Chakraborty, PhD
> Professor of Radiology, retired
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2018 | www.rinfinance.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Help with CRAN error
On Sun, Feb 4, 2018 at 12:47 PM, Dev Chakraborty wrote: > Dear All, > > I get the following message on running R CMD check -- as - cran: > > Package has a VignetteBuilder field but no prebuilt vignette index. > > I do not know how to fix this. Any help will be appreciated. > I don't know how to fix it either. That said, often a great first step is to search for the error. A Google search for, "Package has a VignetteBuilder field but no prebuilt vignette index.", which points to: https://stackoverflow.com/q/30976308. And a Google search "VignetteBuilder" has several promising "how to" results, and there is a "Non-Sweave Vignettes" section of Writing R Extensions: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Non_002dSweave-vignettes. It will be easier for others to help you if you can do some investigation on your own and come back with more specifics. > Sincerely, > > Dev > > > -- > Dev Chakraborty, PhD > Professor of Radiology retired > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2018 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Warnings and error message in CRAN Package Check Results
On Sat, Mar 24, 2018 at 6:42 PM, Wenchao Ma wrote:
> Dear Duncan,
>
> Thank you. I really appreciate your help!
>
> Yes, the Fedora warning is self explanatory, but I'm still quite confused.
> Below are part of my Mstep.cpp file (both functions are in the same file).
> The fedora warned me that, among others,
> Mstep.cpp:62:69: warning: explicitly assigning value of variable of type
> 'int' to itself [-Wself-assign]
> arma::vec Pj = Calc_Pj(par = par, designMj = designMj, linkfunc =
> linkfunc, boundary = boundary, eps = eps);
> ^
>
>
> So, basically, I called Calc_Pj function from Calc_Pj_jac function, but not
> sure why this is not allowed.
>
The compiler isn't complaining about the function call. It's warning
about all the assignments you make in the function call.
Like Duncan said, the compiler thinks you have something like "i = i"
in your code. Which you do, for every argument to the function.
You seem to confuse calling functions in R with calling functions in
C++. C++ function arguments do not have names. They are matched by
position. Note that none of the other function calls in the file use
"named arguments".
>
>
> // [[Rcpp::depends(RcppArmadillo)]]
> #include
> using namespace Rcpp;
> using namespace arma;
> // [[Rcpp::export]]
> arma::vec Calc_Pj(const arma::vec par, const arma::mat designMj,
> const int & linkfunc,int boundary = 0,const double eps = 1e-16){
> arma::vec Pj;
> if(linkfunc==1){ //identity
> Pj = designMj*par;
> }else if(linkfunc==2){//logit
> Pj = exp(designMj*par)/(1 + exp(designMj*par));
> }else if(linkfunc==3){//log
> Pj = exp(designMj*par);
> }
> if(boundary==1){
> Pj.elem(find(Pj Pj.elem(find(Pj>1-eps)).fill(1-eps);
> }
> return Pj;
> }
>
> // [[Rcpp::export]]
> arma::mat Calc_Pj_jac(arma::vec par,
> arma::mat designMj,
> int & linkfunc,
> int boundary = 0,
> double eps = 1e-16){
> arma::mat ret = designMj;
> if(linkfunc>1){
> arma::vec Pj = Calc_Pj(par = par, designMj = designMj, linkfunc =
> linkfunc, boundary = boundary, eps = eps);
> if(linkfunc==2){//logit
> ret.each_col() %= Pj%(1-Pj);
> }else if(linkfunc==3){//log
> ret.each_col() %= Pj;
> }
> }
> return ret;
>
> }
>
> On 3/24/2018 6:18 PM, Duncan Murdoch wrote:
>>
>> On 24/03/2018 9:28 AM, Wenchao Ma wrote:
>>>
>>> Dear all,
>>>
>>> I just submitted a package to CRAN. It went well on my computer and
>>> winbuilder, but produced warning and error messages on some linux and
>>> solaris systems, as shown here:
>>> https://cran.r-project.org/web/checks/check_results_GDINA.html
>>>
>>> Does anyone know what is going on here?
>>
>>
>> The compilers on those systems are set up to be more sensitive to coding
>> problems than yours.
>>
>> The Solaris error comes from your code
>>
>> arma::umat B = arma::ones(K,pow(2,K)-K-1);
>>
>> The library you're using has no function definition for pow() that takes 2
>> integers. If a float or double result is okay, you could use pow(2.0, K).
>> If you really need an int in that argument, you'll need to typecast or write
>> your own pow() function.
>>
>> The Fedora warning seems self explanatory:
>>
>> Mstep.cpp:62:69: warning: explicitly assigning value of variable of type
>> 'int' to itself [-Wself-assign]
>>
>> Take a look at that line (and the other similar ones) and see why the
>> compiler thinks you've got something like
>>
>> i = i;
>>
>> in your code.
>>
>> Duncan Murdoch
>
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2018 | www.rinfinance.com
__
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)
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. 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 > -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2018 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] nativeRoutines error when using roxygen2 in RStudio
devtools::check() gives me: > > >>> > > >>> Updating secsse documentation Loading secsse Registered S3 method > > >>> overwritten by 'dplyr': method from as.data.frame.tbl_df tibble > > >>> Registered S3 method overwritten by 'geiger': method from > > >>> unique.multiPhylo ape Error in nativeRoutines[[lib]] <- routines : > > >>> object 'nativeRoutines' not found > > >> > > >> Do you get that error if you run "R CMD check" on the tarball > > of your > > >> package? > > >> > > >> If so, how comfortable are you with debugging R code? I can > > tell you > > >> how to debug the check process, but it's a little tricky. > > >> > > >> Duncan Murdoch > > >> > > >>> > > >>> > > >>> Any other suggestions? > > >>> > > >>> Cheers, Rampal > > >>> > > >>> On 02-Nov-18 08:33, Georgi Boshnakov wrote: > > >>>> Try installing the latest development version of roxygen2, if you > > >>>> are not using it already. > > >>>> There was a bug in the released version preventing > > installation in > > >>>> some cases. > > >>>> If you don't want to use development version of roxygen2, > > >>>> try putting all filenames in the Collate field in DESCRIPTION > > on one > > >>>> line and make sure that there is a single space > > >>>> between them. This should work if your problem is what I think. > > >>>> > > >>>> By the way, in such cases you will get more informative > > messages if > > >>>> you run devtools::check(). > > >>>> > > >>>> -- > > >>>> Georgi Boshnakov > > >>>> > > >>>> > > >>>> > > >>>> From: R-package-devel [r-package-devel-boun...@r-project.org > > <mailto:r-package-devel-boun...@r-project.org>] on > > >>>> behalf of Rampal Etienne [rampaletie...@gmail.com > > <mailto:rampaletie...@gmail.com>] > > >>>> Sent: 01 November 2018 22:40 > > >>>> To: r-package-devel@r-project.org > > <mailto:r-package-devel@r-project.org> > > >>>> Subject: [R-pkg-devel] nativeRoutines error when using > > roxygen2 in > > >>>> RStudio > > >>>> > > >>>> Since a few weeks (after updating R-devel and Rtools) I get the > > >>>> following error when trying to build a package or document > > it, when > > >>>> using roxygen2 in RStudio: > > >>>> > > >>>> In R CMD INSTALL Error in nativeRoutines[[lib]] <- routines : > > object > > >>>> 'nativeRoutines' not found Calls: > > suppressPackageStartupMessages ... > > >>>> withCallingHandlers -> -> load_all -> load_dll > > Execution > > >>>> halted > > >>>> > > >>>> When I disable roxygen2, I do not get this error, but of > > course the > > >>>> documentation is not created. > > >>>> > > >>>> I have installed the latest versions of RStudio, Rtools, R-devel, > > >>>> roxygen2, pkgload, but the problem persists. > > >>>> > > >>>> Does anybody have a clue what is causing this? I am using > > Windows 10, > > >>>> and the package contains Fortran code. > > >>>> > > >>>> Kind regards, > > >>>> Rampal Etienne > > >>>> > > >>>>[[alternative HTML version deleted]] > > >>>> > > >>>> __ > > >>>> R-package-devel@r-project.org > > <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 > > <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> > > >>> > > >> > > > > > > > __ > > 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 -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2018 | www.rinfinance.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NOTE for a suggested package
You can remove the `library("doParallel")`. Your call to
requireNamespace() plus calling all doParallel functions with `::` is
sufficient. That should resolve the NOTE.
On Sat, Feb 23, 2019 at 5:49 PM Mohammad Ali Nilforooshan
wrote:
>
> I'm struggling to stop receiving a NOTE about a suggested package, and it
> seems to be the problem for many people. Your help is really appreciated.
>
> In the function, I have:
>
> if(requireNamespace("doParallel", quietly=TRUE))
> {
>library("doParallel")
>cl = parallel::makeCluster(ncl)
>doParallel::registerDoParallel(cl)
>Q = foreach(i=ggID, .combine='cbind') %dopar% ## do something
> } else {
>## do something else
> }
>
> In DESCRIPTION, I have:
>
> Suggests:
>doParallel (>= 1.0.14)
>
> This is the NOTE that I receive:
>
> 'library' or 'require' call to 'doParallel' in package code.
> Please use :: or requireNamespace() instead.
> See section 'Suggested packages' in the 'Writing R Extensions' manual.
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
R/Finance 2018 | www.rinfinance.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] help troubleshooting travis-ci issues?
On Sun, Aug 4, 2019 at 4:54 PM Ben Bolker wrote: > > On 2019-08-04 5:43 p.m., Iñaki Ucar wrote: > > On Sun, 4 Aug 2019 at 23:26, Ben Bolker wrote: > >> > >> > >> I'm having some trouble with travis builds of a package (local checks > >> work fine) and hoping if I can get suggestions for diagnosis & > >> troubleshooting ... > >> > >> The package is 'broom.mixed'; I hadn't changed it in a while, but > >> recently got a minor pull request which seemed reasonable. I believe the > >> problems I'm having now are dependency and/or caching problems, not > >> actually related to the changes in the package. > >> > >> The failing build is here > >> > >> https://travis-ci.org/bbolker/broom.mixed/builds/567597217 > > > > I see various "package x was installed by an R version with different > > internals; it needs to be reinstalled for use with this R version". > > > > Top of the page, right side, you should see More options > Caches. Try > > removing them and restart the build. > > > > Iñaki > > I tried that already, thanks. That's why I'm now suspecting it's some > kind of mismatch between the Rutter PPAs and the default (?) repos that > Travis uses. It would be a little painful, but I could edit out the > rstan dependency and try the builds with and without Rutter's PPA to > test that hypothesis ... > Try changing: sudo add-apt-repository -y "ppa:marutter/rrutter" sudo add-apt-repository -y "ppa:marutter/c2d4u" to: sudo add-apt-repository -y "ppa:marutter/rrutter3.5" sudo add-apt-repository -y "ppa:marutter/c2d4u3.5" The R C API changed between R-3.4.x and R-3.5.x, which created incompatibility in packages installed using different versions. Any R > 3.6.x should use the "ppa:*3.5" PPAs. > cheers > Ben Bolker > > > > > > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Etiquette for package submissions that do not automatically pass checks?
On Fri, Aug 14, 2020 at 2:54 PM Duncan Murdoch wrote:
>
> On 14/08/2020 3:08 p.m., Cesko Voeten wrote:
> > A while ago, I submitted an update to my package 'buildmer' that does not
> > pass R CMD check. This is deliberate. The package contains functionality to
> > run on cluster nodes that were set up by the user and needs to access its
> > own internal functions from there. In previous versions of the package, I
> > had maintained a list of those functions and clusterExport()ed them, but
> > that had the side effect of overwriting any same-named user objects on the
> > user-provided cluster nodes, which I thought was poor form. The update
> > therefore accesses these functions using ':::', which triggers a check
> > warning.
> >
> > I thought the etiquette was to explain this in the 'Comments' box when
> > submitting, but this gave me the same automated message that the package
> > does not pass checks and that I should fix it or reply-all and explain.
> > This led me to believe that I should not have used the 'Comments' box for
> > this purpose, hence I resubmitted the package leaving the comments box
> > empty, and I replied-all to the subsequent e-mail I got with an explanation
> > similar to the above.
>
> It seems to me that what you should have done is "reply-all and
> explain", as the automated message said.
>
> > It has now been a while since I sent that e-mail (ten days), and I have yet
> > to hear back. I was wondering if the message had gotten lost, if they
> > simply haven't gotten around to it yet (I have no idea how much mail they
> > receive on a daily basis, but I'd think it's a lot more than I do), or if I
> > should have handled this differently. Only CRAN can answer the first two
> > questions, but before I bother them: was this the correct procedure, or
> > should I simply have done something differently?
> >
>
> You can see the state of your submission using the foghorn package.
> cran_incoming("buildmer") currently shows your package is in the
> "archive", which means "package rejected: it does not pass the checks
> cleanly and the problems are unlikely to be false positives".
>
> I only see version 1.7 there, which may indicate that you resubmitted
> exactly the same package (down to the version number). As the
> instructions at
> https://cran.r-project.org/web/packages/policies.html#Re_002dsubmission
> say, "Increasing the version number at each submission reduces confusion
> so is preferred even when a previous submission was not accepted."
>
> What I'd suggest now is that you do nothing more for a day or two,
> because CRAN members who aren't on holiday might read and respond to
> your message. If you don't hear anything, then I'd start over again,
> with a new version number, and an explanation in the comments, and
> likely a followup reply-all.
>
You have more than a few days. As it says on CRAN:
"CRAN submission is offline from Aug 14 to Aug 24, 2020 (CRAN team
vacation and maintainance work)"
> Alternatively, you could export those troublesome functions from your
> package but document them as for internal use only. Renaming them with
> a name starting with "." will make them harder for users to stumble
> upon, but you can still access them using buildmer::.something, you
> shouldn't need clusterExport(). Then you will meet the technical
> requirement and not need any explanation.
>
> Duncan Murdoch
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] url checks not working for me
; http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533 > > > (moved to > > > > > https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533) > > > From: inst/CITATION Status: 200 Message: OK URL: https://geneactiv.org/ > > > (moved to https://www.activinsights.com/) From: inst/doc/GGIR.html > > Status: > > > 200 Message: OK URL: https://www.accelting.com/ (moved to > > > https://accelting.com/) From: inst/doc/GGIR.html Status: 200 Message: OK > > > URL: https://www.physiology.org/doi/10.1152/japplphysiol.00421.2014 > > (moved > > > to https://journals.physiology.org/doi/10.1152/japplphysiol.00421.2014) > > > From: inst/CITATION Status: 200 Message: OK > > > > > > [[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 -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] visible binding for '<<-' assignment
On Thu, Sep 3, 2020 at 4:36 PM Ben Bolker wrote:
>
> Is there a reason that this slightly more explicit version wouldn't work?
>
> pali_string_fix <- function() {
> assign("pali_alphabet", stringi::stri_unescape_unicode(pali_alphabet),
> .GlobalEnv)
> }
>
Using assign will also cause R CMD check to throw a NOTE that you will
need to explain upon pkg submission to CRAN.
>
> On 9/3/20 5:25 PM, Dan Zigmond wrote:
> > Thanks, Gabor. I want these to be easily available to package users though
> > – that's why they are in the package. So I would rather not "hide" them in
> > a local environment. This is fundamentally a data package, so access to
> > this data is the primary point of installing it.
> >
> > Is there any other solution?
> >
> > Dan
> >
> > .
> > --
> > Dan Zigmond
> > d...@shmonk.com
> >
> >
> >
> > On Thu, Sep 3, 2020 at 1:40 PM Gábor Csárdi wrote:
> >
> >> Store the cached data in an environment within the package:
> >>
> >> pali_data <- new.env(parent = emptyenv())
> >>
> >> pali_string_fix <- function() {
> >>pali_data$alphabet <-
> >> stringi::stri_unescape_unicode(pali_alphabet)
> >> ...
> >> }
> >>
> >> Gabor
> >>
> >> On Thu, Sep 3, 2020 at 9:33 PM Dan Zigmond wrote:
> >>>
> >>> Hi, all. I am developing a package that includes some global variables.
> >>> Because these are non-ASCII, I have escaped them. But then because these
> >>> are difficult to read, I want to provide an easy way for users to
> >> unescape
> >>> all of them up front. Thus I have code like to create and save the data
> >> in
> >>> global variables in one file:
> >>>
> >>> pali_vowels <-
> >>>c("a", "\u0101", "i", "\u012b", "u", "\u016b", "e", "o")
> >>> pali_consonants <-
> >>>c("k", "kh", "g", "gh", "\u1e45",
> >>> "c", "ch", "j", "jh", "\u00f1",
> >>> "\u1e6d", "\u1e6dh", "\u1e0d", "\u1e0dh", "\u1e47",
> >>> "t", "th", "d", "dh", "n",
> >>> "p", "ph", "b", "bh", "m",
> >>> "y", "r", "l", "v", "s", "h", "\u1e37", "\u1e43")
> >>> pali_alphabet <-c(pali_vowels, pali_consonants)
> >>> use_data(pali_alphabet, overwrite = TRUE)
> >>>
> >>> and then I try to export a function like this in another file:
> >>>
> >>> pali_string_fix <- function() {
> >>>pali_alphabet <<-
> >>> stringi::stri_unescape_unicode(pali_alphabet)
> >>># Several more of these...
> >>>}
> >>>
> >>> The idea is that users can run pali_string_fix() once when they load the
> >>> package and then they won't need to deal with all the Unicode escape
> >>> sequences after that.
> >>>
> >>> However, this is getting rejected by the CRAN checks with the message:
> >>>
> >>> * checking R code for possible problems ... [4s] NOTE
> >>> pali_string_fix: no visible binding for '<<-' assignment to
> >>>'pali_alphabet'
> >>>
> >>> I'm guessing this is because the data and the function are defined in
> >>> different files, so even though those globals are defined by my package,
> >>> that isn't obvious when the check is run on this code.
> >>>
> >>> Does anyone have advice for how to fix this?
> >>>
> >>> Dan
> >>>
> >>> .
> >>> -
> >>> Dan Zigmond
> >>> d...@shmonk.com
> >>>
> >>> [[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
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN, API packages, Keys and tests
Hi Rainer, You could set an environment variable with the API key, and only run the tests if the variable is set. Here's an example that I use: https://github.com/joshuaulrich/quantmod/blob/master/tests/test_getSymbols.R#L4 Best, Josh On Fri, Sep 4, 2020 at 3:25 AM Rainer M Krug wrote: > > I know this has been asked a few times - but I can’t find anything which > might help me. > > I have a package (https://github.com/rkrug/ROriginStamp) which wraps around > API calls to OriginStamp (https://originstamp.com) to obtain trusted time > stamps. > > The package works, but the tests are the problem on remote machines. > > My question is: > > 1) I have disabled all tests and all examples if there is no environmental > variable set with the API Key - is this OK for CRAN? > 2) If not, how can I make this CRAN compliant? > > Thanks, > > Rainer > > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > UCT), Dipl. Phys. (Germany) > > Orcid ID: -0002-7490-0066 > > Department of Evolutionary Biology and Environmental Studies > University of Zürich > Office Y34-J-74 > Winterthurerstrasse 190 > 8075 Zürich > Switzerland > > Office: +41 (0)44 635 47 64 > Cell: +41 (0)78 630 66 57 > email: rainer.k...@uzh.ch > rai...@krugs.de > Skype: RMkrug > > PGP: 0x0F52F982 > > > > > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > UCT), Dipl. Phys. (Germany) > > Orcid ID: -0002-7490-0066 > > Department of Evolutionary Biology and Environmental Studies > University of Zürich > Office Y34-J-74 > Winterthurerstrasse 190 > 8075 Zürich > Switzerland > > Office: +41 (0)44 635 47 64 > Cell: +41 (0)78 630 66 57 > email: rainer.k...@uzh.ch > rai...@krugs.de > Skype: RMkrug > > PGP: 0x0F52F982 > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN, API packages, Keys and tests
On Fri, Sep 4, 2020 at 9:20 AM Joshua Ulrich wrote: > > Hi Rainer, > > You could set an environment variable with the API key, and only run > the tests if the variable is set. > Sorry, I missed that you're already doing this. I confirm that it works for CRAN. I also set my API key as a private/secure variable on TravisCI, so the tests will run there. IIRC, testthat does something similar. You could look at that pattern, since it works on CRAN for many packages. > Here's an example that I use: > https://github.com/joshuaulrich/quantmod/blob/master/tests/test_getSymbols.R#L4 > > Best, > Josh > > On Fri, Sep 4, 2020 at 3:25 AM Rainer M Krug wrote: > > > > I know this has been asked a few times - but I can’t find anything which > > might help me. > > > > I have a package (https://github.com/rkrug/ROriginStamp) which wraps around > > API calls to OriginStamp (https://originstamp.com) to obtain trusted time > > stamps. > > > > The package works, but the tests are the problem on remote machines. > > > > My question is: > > > > 1) I have disabled all tests and all examples if there is no environmental > > variable set with the API Key - is this OK for CRAN? > > 2) If not, how can I make this CRAN compliant? > > > > Thanks, > > > > Rainer > > > > > > -- > > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > > UCT), Dipl. Phys. (Germany) > > > > Orcid ID: -0002-7490-0066 > > > > Department of Evolutionary Biology and Environmental Studies > > University of Zürich > > Office Y34-J-74 > > Winterthurerstrasse 190 > > 8075 Zürich > > Switzerland > > > > Office: +41 (0)44 635 47 64 > > Cell: +41 (0)78 630 66 57 > > email: rainer.k...@uzh.ch > > rai...@krugs.de > > Skype: RMkrug > > > > PGP: 0x0F52F982 > > > > > > > > > > > > -- > > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > > UCT), Dipl. Phys. (Germany) > > > > Orcid ID: -0002-7490-0066 > > > > Department of Evolutionary Biology and Environmental Studies > > University of Zürich > > Office Y34-J-74 > > Winterthurerstrasse 190 > > 8075 Zürich > > Switzerland > > > > Office: +41 (0)44 635 47 64 > > Cell: +41 (0)78 630 66 57 > > email: rainer.k...@uzh.ch > > rai...@krugs.de > > Skype: RMkrug > > > > PGP: 0x0F52F982 > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > -- > Joshua Ulrich | about.me/joshuaulrich > FOSS Trading | www.fosstrading.com -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster
On Sun, Sep 13, 2020 at 3:19 PM Duncan Murdoch wrote:
>
> On 13/09/2020 3:51 p.m., David Kepplinger wrote:
> > Dear list members,
> >
> > I submitted an update for my package and got automatically rejected by the
> > incoming checks (as expected from my own checks) for using `:::` calls to
> > access the package's namespace.
> > "There are ::: calls to the package's namespace in its code. A package
> > *almost* never needs to use ::: for its own objects:…" (emphasis mine)
> >
> > This was a conscious decision on my part as the package runs code on a
> > user-supplied parallel cluster and I consider cluster-exporting the
> > required functions a no-go as it would potentially overwrite objects in the
> > clusters R sessions. The package code does not own the cluster and hence
> > the R sessions. Therefore overwriting objects could potentially lead to
> > unintended behaviour which is opaque to the user and difficult to debug.
> >
> > Another solution to circumvent the R CMD check note is to export the
> > functions to the public namespace but mark them as internal. This was also
> > suggested in another thread on this mailing list (c.f. "Etiquette for
> > package submissions that do not automatically pass checks?"). I do not
> > agree with this work-around as the methods are indeed internal and should
> > never be used by users. Exporting truly internal functions for the sake of
> > satisfying R CMD check is a bad argument, in particular if there is a
> > clean, well-documented, solution by using `:::`
>
> Who is calling this function: package code or user code? I assume it's
> a bit of a mix: your package writes a script that calls the function
> when it runs in user space. (It would help if you gave an explicit
> example of when you need to use this technique.)
>
> If my assumption is correct, there are other simple workarounds besides
> exporting the functions. Instead of putting
>
> pkg:::foo(args)
>
> into your script, put
>
> pkg::callInternal("foo", args)
>
> where pkg::callInternal is an exported function that can look up
> unexported functions in the namespace.
>
Another possibility is what quantmod::newTA() does.
https://github.com/joshuaulrich/quantmod/blob/a8e9cb87825c0997a8468f5105db6c507b26ac5d/R/newTA.
It's a function that creates a user-facing function. The created
function needs to access unexported objects from the quantmod
namespace. newTA() accomplishes that by setting the environment of
the function it returns to the quantmod namespace.
https://github.com/joshuaulrich/quantmod/blob/a8e9cb87825c0997a8468f5105db6c507b26ac5d/R/newTA.R#L98
That gives the user's new function access to the unexported charting
objects it needs to work.
Hope that helps.
Best,
Josh
> You may argue that you prefer pkg:::foo for some reason: to which I'd
> respond that you are being rude to the CRAN volunteers. I've offered
> two options (one in the previous thread, a different one here), and
> there was a third one in that thread offered by Ivan Krylov. Surely one
> of these is good enough for your needs, and you shouldn't force CRAN to
> handle you specially.
>
> Duncan
>
> >
> > I argue `:::` is the only clean solution to this problem and no dirty
> > work-arounds are necessary. This is a prime example of where `:::` is
> > actually useful and needed inside a package. If the R community disagrees,
> > I think R CMD check should at least emit a WARNING instead of a NOTE and
> > elaborate on the problem and accepted work-arounds in "Writing R
> > extensions". Or keep emitting a NOTE but listing those nebulous reasons
> > where `:::` would be tolerated inside a package. Having more transparent
> > criteria for submitting to CRAN would be really helpful to the entire R
> > community and probably also reduce the traffic on this mailing list.
> >
> > Best,
> > David
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Dependency needs to be loaded manually even its specified in the package
On Fri, Sep 18, 2020 at 11:56 AM Dirk Eddelbuettel wrote: > > > On 18 September 2020 at 18:38, Nuria Perez-Zanon wrote: > | I am maintaining a package call CSTools which is aimed for > | post-processing climate simulations. > [...] > | library(CSTools) > | library(qmap) > > You never use library() in a package. Rather, you declare dependency > relationsships via DESCRIPTION (and likely NAMESPACE). See "Writing R > Extensions" for all the details. > And here's the relevant section: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Registering-S3-methods Best, Josh > > Dirk > > -- > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to remove rJava from Ecfun when it's not called directly or indirectly
On Sat, Oct 10, 2020 at 10:57 PM Spencer Graves
wrote:
>
> Hello, All:
>
>
> "R CMD check Ecfun_0.2-4.tar.gz" fails under Windows 10 with "Error:
> package or namespace load failed for 'Ecfun': .onLoad failed in
> loadNamespace() for 'rJava'".
>
>
> However, I cannot find where Ecfun calls rJava. This is in:
>
>
> https://github.com/sbgraves237/Ecfun
>
>
> I get nothing from "grep 'rJava'" in the DESCRIPTION and NAMESPACE
> files plus in the man and R subdirectories. I ran
> tools:package_dependencies recursively starting with Ecfun until I got
> all NULLs and could not find rJava anywhere.
>
You need to include suggested package dependencies in your search.
tools::package_dependencies("Ecfun",
which = c("Depends", "Imports", "LinkingTo", "Suggests"),
recursive = TRUE)
You will find rJava in that list of ~1650 dependencies.
>
> Thanks,
> Spencer Graves
>
>
> 00install.out
>
>
> * installing *source* package 'Ecfun' ...
> ** using staged installation
> ** R
> ** inst
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** installing vignettes
> ** testing if installed package can be loaded from temporary location
> *** arch - i386
> Error: package or namespace load failed for 'Ecfun':
> .onLoad failed in loadNamespace() for 'rJava', details:
>call: inDL(x, as.logical(local), as.logical(now), ...)
>error: unable to load shared object 'C:/Program
> Files/R/R-4.0.2/library/rJava/libs/i386/rJava.dll':
>LoadLibrary failure: %1 is not a valid Win32 application.
>
> Error: loading failed
> Execution halted
> *** arch - x64
> ERROR: loading failed for 'i386'
> * removing 'C:/Users/spenc/Documents/R/Ecfun/Ecfun.Rcheck/Ecfun'
>
>
> 00check.log
>
>
> * using log directory 'C:/Users/spenc/Documents/R/Ecfun/Ecfun.Rcheck'
> * using R version 4.0.2 (2020-06-22)
> * using platform: x86_64-w64-mingw32 (64-bit)
> * using session charset: ISO8859-1
> * checking for file 'Ecfun/DESCRIPTION' ... OK
> * this is package 'Ecfun' version '0.2-4'
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking if there is a namespace ... OK
> * checking for executable files ... OK
> * checking for hidden files and directories ... OK
> * checking for portable file names ... OK
> * checking whether package 'Ecfun' can be installed ... ERROR
> Installation failed.
> See 'C:/Users/spenc/Documents/R/Ecfun/Ecfun.Rcheck/00install.out' for
> details.
> * DONE
> Status: 1 ERROR
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] unexpected CRAN pretest failure
On Thu, Dec 17, 2020 at 7:25 AM Rossum, Bart-Jan van wrote: > > Dear Uwe, > > Thanks for your reaction. > I installed the latest available R-devel version (2020-12-15 r79633) on my > own windows pc, but even then the checks pas cleanly. > So, unfortunately I'm not able to reproduce the issue. > > To be sure, I also retried on Winbuilder, which has a slightly different > version (r79643), but there the issue is still present. > > Could there be something else I need to do to be able to reproduce this > locally? > I assume you used the pre-compiled version here: https://cran.r-project.org/bin/windows/base/rdevel.html That version probably lags behind the subversion repo for about a day. So you need to build the latest R-devel from the latest source in the subversion repo. It always has the latest version. Rocker and r-hub help make this much easier than setting everything up locally on your machine. That said, it looks like the pre-compiled version is at r79643 now, so you should be able to use it to reproduce the issue. Best, Josh > Regards, > Bart-Jan > > -Original Message- > From: Uwe Ligges > Sent: Thursday, December 17, 2020 13:29 > To: Rossum, Bart-Jan van ; > r-package-devel@r-project.org > Subject: Re: [R-pkg-devel] unexpected CRAN pretest failure > > This is form a change in R-devel. > Use a more recent R-devel to reproduce the issue. > > Best, > Uwe Ligges > > On 14.12.2020 15:02, Rossum, Bart-Jan van wrote: > > Dear community, > > > > When trying to update my CRAN > > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcran.r-project.org%2Fweb%2Fpackages%2FstatgenGxE%2Findex.html&data=04%7C01%7Cbart-jan.vanrossum%40wur.nl%7C7cee644adb0a4aebb06008d8a28746e3%7C27d137e5761f4dc1af88d26430abb18f%7C0%7C0%7C637438049192516675%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XsyDDtwJk%2FXlDxxWxx2ylcx9RX%2BVOb9XWSZruwo42HY%3D&reserved=0) > > package in ran into unexpected error on Windows. > > I had tested before submission on R-hub, which went fine, but CRAN > > complained, and this was confirmed on Winbuilder. > > I noticed a slight difference in R-version used on CRAN/Winbuilder and > > R-hub. > > However, the error itself seems to come from an lme4 function. > > I'm quite clueless on how to debug/fix this. > > > > CRAN and Winbuilder: > > R Under development (unstable) (2020-12-13 r79623) > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwin-builder.r-project.org%2FnK0OMOQ378SI&data=04%7C01%7Cbart-jan.vanrossum%40wur.nl%7C7cee644adb0a4aebb06008d8a28746e3%7C27d137e5761f4dc1af88d26430abb18f%7C0%7C0%7C637438049192516675%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WpzlD%2B7%2BsggCPKJUrjvV4ZchNF12tXAXfrVMjRlh10c%3D&reserved=0 > > > > R-hub: > > R Under development (unstable) (2020-11-30 r79529) > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuilder.r-hub.io%2Fstatus%2FstatgenGxE_1.0.4.tar.gz-fcc1e205a5fb4fd09559d301ee3502c9&data=04%7C01%7Cbart-jan.vanrossum%40wur.nl%7C7cee644adb0a4aebb06008d8a28746e3%7C27d137e5761f4dc1af88d26430abb18f%7C0%7C0%7C637438049192516675%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aWev8qrAGU5yO%2FP%2FGqqb3EVqdYYkGq%2FYrUf0b2ZqrDw%3D&reserved=0 > > > > Any pointers are appreciated, > > Bart-Jan > > > > __ > > R-package-devel@r-project.org mailing list > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=04%7C01%7Cbart-jan.vanrossum%40wur.nl%7C7cee644adb0a4aebb06008d8a28746e3%7C27d137e5761f4dc1af88d26430abb18f%7C0%7C0%7C637438049192516675%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VA%2BpMcbmLDsLsjeZj5ucESwPHfgylxG59HHYkr9MOiw%3D&reserved=0 > > > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Advice on R-forge to Github migration
On Sun, Jan 31, 2021 at 12:10 PM Duncan Murdoch wrote: > > rgl has been on R-forge for a long time, but I am now planning on > migrating it to Github. I really dislike git, but Github offers enough > benefits, and nowadays I'm familiar enough with them, that I think I'd > be better off there. > > The easiest way to do this would be to do almost nothing: just declare > the the dmurdoch/rgl fork of r-forge/rgl is now where all new changes > will be committed. > > Can anyone else who has done this migration tell me if there there any > disadvantages to this that I don't know about? What I know: > > - I'll lose the bug reports and forum discussions that were sent to > R-forge. > - I'll need to do a bit of work to change dmurdoch/rgl to a more > standard R package layout, but this should be quite easy: basically > just moving the files in pkg/rgl to the top level. I assume "git mv" > will keep their history if I do this. > I've moved history and issues from R-Forge to GitHub for half a dozen R packages. I might be able to do this rgl. At minimum, I could help you do it. Yes, git mv will retain the file history. > Duncan Murdoch > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Advice on R-forge to Github migration
On Sun, Jan 31, 2021 at 2:17 PM Duncan Murdoch wrote: > > Thanks to everyone who commented. A few replies inline: > > On 31/01/2021 1:21 p.m., Joshua Ulrich wrote: > > I've moved history and issues from R-Forge to GitHub for half a dozen > > R packages. I might be able to do this rgl. At minimum, I could help > > you do it. > > Thanks for the offer (and the more detailed one offline, where you > recommend cloning the repository rather than forking it). Just for > future reference, could you tell me the benefits of cloning over forking? > We can discuss more offline, but at a high level: - if you fork my repo, mine is the head of the network graph - if you clone it and then push it to a repo in your account, yours is the head of the network graph Basically, I don't want your repo to be a fork of mine. That would confuse users about where issues/PRs should be. I plan to delete my repo once you've loaded the copy to your account. > Duncan Murdoch > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] DESCRIPTION file corrections for accepted package
`R CMD check` uses the `package_version()` function to check that the
submitted package version is > the version on CRAN. You can use it to
check Duncan's hypothesis:
R$ # current update with 3-part version
R$ package_version("1.1.1") > package_version("1.1")
[1] TRUE
R$ # next update with only a 2-part version
R$ package_version("1.2") > package_version("1.1.1")
[1] TRUE
On Sun, Oct 27, 2024 at 8:16 AM Duncan Murdoch wrote:
>
> I don't think R will enforce a 3 part version just because you used it
> once. You might have other reasons to try to maintain versioning
> consistency.
>
> Duncan Murdoch
>
> On 2024-10-27 7:48 a.m., Gianmarco Alberti wrote:
> > Dear Duncan,
> >
> > Thank you for the straightforward guidance.
> >
> > My initial query stemmed from a concern about versioning consistency - I
> > thought that once using three digits (1.1.1), I would need to maintain
> > that format (e.g., 1.2.0) in future updates. Your suggestion clarified
> > that I can use 1.1.1 for these formatting changes and still use 1.2 for
> > future substantial updates.
> >
> > Best regards,
> >
> > Gm
> >
> >
> > Il giorno dom 27 ott 2024 alle ore 11:49 Duncan Murdoch
> > mailto:murdoch.dun...@gmail.com>> ha scritto:
> >
> > On 2024-10-27 6:03 a.m., Gianmarco Alberti wrote:
> > > Dear R Package Developers,
> > > I am seeking guidance regarding a situation with my package
> > 'chisquare'
> > > (version 1.1) on CRAN.
> > >
> > > Current situation:
> > >
> > > 1. The package was submitted and (automatically) accepted to CRAN
> > (version
> > > 1.1) after thorough local testing and complete devtools checks
> > > (check_win_oldrelease(), check_win_release(), check_win_devel())
> > >
> > > 2. After acceptance, I received a request to make formatting
> > changes to the
> > > DESCRIPTION file by November 2, 2024:
> > > -Remove version specifications for graphics and stats in Imports
> > > -Update R version dependency format from R (>= 4.0.0) to R (>= 4.0)
> > >
> > > 3. Upon attempting to submit these formatting changes, I received
> > a warning
> > > about "Insufficient package version (submitted: 1.1, existing:
> > 1.1)". I am
> > > well aware that this warning typically indicates the need to
> > increment the
> > > version number for new submissions of existing packages, as per CRAN
> > > policies.
> > >
> > > This creates a procedural challenge:
> > > -I need to make the requested DESCRIPTION file changes to retain
> > the package
> > > -The changes are purely formatting-related, not functional (all
> > checks pass)
> > > -I cannot submit without changing the version number
> > > -However, incrementing the version number seems disproportionate for
> > > formatting changes.
> > >
> > > I would greatly appreciate guidance on the proper way to handle this
> > > situation.
> > > What is the recommended approach for submitting DESCRIPTION file
> > formatting
> > > corrections for an already-accepted package, given that
> > incrementing the
> > > version number might seem a bit disproportionate?
> > >
> > > Thank you for your time and assistance.
> >
> > The simplest thing is to just update the version. Use 1.1.1 if you
> > don't want to go to 1.2.
> >
> > Duncan Murdoch
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
