Re: [R-pkg-devel] trying to understand an error
If there's anyone willing to take a look at the build errors I would appreciate it. I'm trying to work a bug report from a downstream user, and I think the OSX build has an issue that I don't understand. Thanks. On Thu, May 31, 2018 at 1:49 PM, Steven Scott wrote: > Looking at the Boom package results page, I see that it has errors on OSX > and two flavors of Linux. > > The OSX install page is here: https://www.r-project. > org/nosvn/R.check/r-release-osx-x86_64/Boom-00install.html . > > I'm trying to understand the nature of the error. The last lines say: > > clang++ -std=gnu++11 -I"/Library/Frameworks/R.framework/Resources/include" > -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes > -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/BH/include" > > -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include" > -I/usr/local/include -fPIC -Wall -g -O2 -c Models/TimeSeries/ArModel.cpp > -o Models/TimeSeries/ArModel.o > clang++ -std=gnu++11 -I"/Library/Frameworks/R.framework/Resources/include" > -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes > -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/BH/include" > > -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include" > -I/usr/local/include -fPIC -Wall -g -O2 -c > Models/TimeSeries/ArmaModel.cpp -o Models/TimeSeries/ArmaModel.o > make: *** [Models/TimeSeries/ArmaModel.o] Interrupt: 2 > ERROR: compilation failed for package ‘Boom’ > * removing > ‘/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/results/3.5/Boom.Rcheck/Boom’ > > > As I read this, it looks like there was no compiler error, but the build > was interrupted for some reason. Do others read it differently? If I'm > reading it right, what needs to happen to re-run the check to clear the OSX > error status? > > Thanks, > > Steve > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Courtesy methods and explosive dependencies
This seems like a nice solution -- the only disadvantages I can think
of are (1) extra hassle (2) it might generate messages about function
masking when the upstream package (e.g. broom) is loaded?
On 2018-05-25 12:00 PM, Neal Fultz wrote:
> In the estimatr package, we provided a shim to support broom without
> transitively depending on the tidyverse:
>
>
> tidy <- function(object, ...) {
> if (requireNamespace("broom", quietly = TRUE)) broom::tidy(object, ...)
> else UseMethod("tidy")
> }
>
> https://github.com/DeclareDesign/estimatr/blob/master/R/S3_tidy.R
>
> It's not ideal but it seems to make our functions work whether or not the
> end user has broom.
>
>
> S4 methods (eg texreg) were more difficult, and we ended up registering the
> generics in .onLoad:
>
>
> .onLoad <- function(libname, pkgname) {
> if (suppressWarnings(requireNamespace("texreg", quietly = TRUE))) {
> setGeneric("extract", function(model, ...) standardGeneric("extract"),
> package = "texreg"
> )
> setMethod("extract",
> signature = className("lm_robust", pkgname),
> definition = extract.lm_robust
> )
> }
> invisible()
> }
>
> https://github.com/DeclareDesign/estimatr/blob/master/R/zzz.R
>
>
> Since this is in .onLoad, it's a little buggy if the user has estimatr and
> then installs texreg, but again seems to mostly work.
>
> We would appreciate any feedback the list may have on these design patterns.
>
>
> -Neal
>
>
>
>
> On Fri, May 25, 2018 at 8:38 AM, Lenth, Russell V
> wrote:
>
>> I agree that most of the package dependencies in multcomp are worth
>> having, but that is not the point. The point is that if a developer wants
>> to write a method for a generic function offered in another non-base
>> package, that creates false dependencies: packages that users are required
>> to have, but that aren't actually used by the method. I certainly wasn't
>> trying to diss multcomp; that was just a concrete illustration.
>>
>> Russ
>>
>> -Original Message-
>> From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
>> Sent: Friday, May 25, 2018 2:13 AM
>> To: Lenth, Russell V
>> Cc: r-package-devel@r-project.org
>> Subject: Re: [R-pkg-devel] Courtesy methods and explosive dependencies
>>
>>> Lenth, Russell V
>>> on Thu, 24 May 2018 23:14:42 + writes:
>>
>> > Package developers, I am trying to severely cut down on
>> > the number of dependencies of my package emmeans. It is
>> > now 48, which is quite a few (but that is down from over
>> > 100 in the preceding version, where I made the unwise
>> > choice of including a particularly greedy package in
>> > Imports). I hate to force users to install dozens of
>> > packages that they don't really need or want, but it seems
>> > very hard to avoid.
>>
>> > Case in point: emmeans provides additional methods for
>> > 'cld' and 'glht' from the multcomp package. Accordingly, I
>> > import their generics, and register my additional
>> > methods. But because I import the generics, I must list
>> > multcomp in Imports, and that results in the addition of
>> > 16 required packages, some of which I never use. More
>> > important, I believe that NONE of those 16 packages are
>> > required for the correct functioning of my courtesy
>> > methods. The only things I really need are the generics.
>>
>> There must be a mistake here -- I think in your perception:
>>
>> 'multcomp' does *not* have excessive dependencies (though I'd say one too
>> much):
>>
>>> tools::package_dependencies("multcomp")
>> $multcomp
>> [1] "stats" "graphics" "mvtnorm" "survival" "TH.data" "sandwich"
>> [7] "codetools"
>>
>>> tools::package_dependencies("multcomp", recursive=TRUE)
>> $multcomp
>> [1] "stats" "graphics" "mvtnorm" "survival" "TH.data"
>> "sandwich"
>> [7] "codetools" "methods" "utils" "zoo" "Matrix"
>> "splines"
>> [13] "MASS" "grDevices" "grid" "lattice"
>>
>>>
>>
>> Apart from "base + recommended" packages (which *everyone* has installed),
>> these are just 4 packages:
>>
>> mvtnorm
>> TH.data
>> sandwich
>> zoo
>>
>> where mvtnorm, sandwich, and zoo really are among the (formally
>> undefined) recommended-level-2 R packages... so I do wonder if you really
>> had needed to install.
>>
>> The 'TH.data' { TH <==> maintainer("multcomp") } package I think should
>> not be in the strict dependencies of 'multcomp' but rather in its
>> "Suggests" something I'd say must be true for all data packages:
>> The whole idea of data packages is that they should be needed for
>> interesting help page examples, vignettes, maybe even tests, but not for
>> package functionality.
>>
>> In sum: I'd strongly advise to not change from keeping multcomp among your
>> imports.
>>
>> Martin Maechler
>> ETH Zurich
>>
>> > On the flip side, emmeans defines some generics of its own
>> > that I invite other package
Re: [R-pkg-devel] trying to understand an error
Please ask the Mac maintainer, Simon Urbanek, in such a case where it is not obvious what is going on. Best, Uwe Ligges On 05.06.2018 18:45, Steven Scott wrote: If there's anyone willing to take a look at the build errors I would appreciate it. I'm trying to work a bug report from a downstream user, and I think the OSX build has an issue that I don't understand. Thanks. On Thu, May 31, 2018 at 1:49 PM, Steven Scott wrote: Looking at the Boom package results page, I see that it has errors on OSX and two flavors of Linux. The OSX install page is here: https://www.r-project. org/nosvn/R.check/r-release-osx-x86_64/Boom-00install.html . I'm trying to understand the nature of the error. The last lines say: clang++ -std=gnu++11 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/BH/include" -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include" -I/usr/local/include -fPIC -Wall -g -O2 -c Models/TimeSeries/ArModel.cpp -o Models/TimeSeries/ArModel.o clang++ -std=gnu++11 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/BH/include" -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include" -I/usr/local/include -fPIC -Wall -g -O2 -c Models/TimeSeries/ArmaModel.cpp -o Models/TimeSeries/ArmaModel.o make: *** [Models/TimeSeries/ArmaModel.o] Interrupt: 2 ERROR: compilation failed for package ‘Boom’ * removing ‘/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-capitan-x86_64/results/3.5/Boom.Rcheck/Boom’ As I read this, it looks like there was no compiler error, but the build was interrupted for some reason. Do others read it differently? If I'm reading it right, what needs to happen to re-run the check to clear the OSX error status? Thanks, Steve [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] trying to understand an error
Thanks Uwe. Will do. On Tue, Jun 5, 2018 at 1:55 PM, Uwe Ligges wrote: > Please ask the Mac maintainer, Simon Urbanek, in such a case where it is > not obvious what is going on. > > Best, > Uwe Ligges > > > > > > On 05.06.2018 18:45, Steven Scott wrote: > >> If there's anyone willing to take a look at the build errors I would >> appreciate it. I'm trying to work a bug report from a downstream user, >> and >> I think the OSX build has an issue that I don't understand. >> Thanks. >> >> On Thu, May 31, 2018 at 1:49 PM, Steven Scott < >> steve.the.bayes...@gmail.com> >> wrote: >> >> Looking at the Boom package results page, I see that it has errors on OSX >>> and two flavors of Linux. >>> >>> The OSX install page is here: https://www.r-project. >>> org/nosvn/R.check/r-release-osx-x86_64/Boom-00install.html . >>> >>> I'm trying to understand the nature of the error. The last lines say: >>> >>> clang++ -std=gnu++11 -I"/Library/Frameworks/R.framework/Resources/include" >>> -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes >>> -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-c >>> apitan-x86_64/Rlib/3.5/BH/include" -I"/Volumes/SSD-Data/Builds/R- >>> dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include" >>> -I/usr/local/include -fPIC -Wall -g -O2 -c Models/TimeSeries/ArModel.cpp >>> -o Models/TimeSeries/ArModel.o >>> clang++ -std=gnu++11 -I"/Library/Frameworks/R.framework/Resources/include" >>> -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes >>> -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-c >>> apitan-x86_64/Rlib/3.5/BH/include" -I"/Volumes/SSD-Data/Builds/R- >>> dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/RcppEigen/include" >>> -I/usr/local/include -fPIC -Wall -g -O2 -c >>> Models/TimeSeries/ArmaModel.cpp >>> -o Models/TimeSeries/ArmaModel.o >>> make: *** [Models/TimeSeries/ArmaModel.o] Interrupt: 2 >>> ERROR: compilation failed for package ‘Boom’ >>> * removing ‘/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-cap >>> itan-x86_64/results/3.5/Boom.Rcheck/Boom’ >>> >>> >>> As I read this, it looks like there was no compiler error, but the build >>> was interrupted for some reason. Do others read it differently? If I'm >>> reading it right, what needs to happen to re-run the check to clear the >>> OSX >>> error status? >>> >>> Thanks, >>> >>> Steve >>> >>> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> >> [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] trying to understand an error
For what it's worth, the package compiles successfully on my own macOS machine but it takes a long time to build just because of how large it is. Perhaps the CRAN build machine is set to interrupt long-running installations, under the assumption that they're hanging / frozen? Given how many C++ source files your package has, it may be prudent to combine some of them into single C++ translation units, so they can be built faster (avoid re-parsing the heavy BH and RcppEigen headers so many times during compilation). A simple way to accomplish this -- suppose you have files A.cpp, B.cpp, C.cpp and wanted to compile them together. You could create a file: #include #include #include and then compile that single file to effectively build those three files all at once. This does of course require that your source files don't have any accidental symbol collisions, but I think it would be worth investigating. Best, Kevin On Tue, Jun 5, 2018 at 2:22 PM, Steven Scott wrote: > Thanks Uwe. Will do. > > On Tue, Jun 5, 2018 at 1:55 PM, Uwe Ligges de> > wrote: > > > Please ask the Mac maintainer, Simon Urbanek, in such a case where it is > > not obvious what is going on. > > > > Best, > > Uwe Ligges > > > > > > > > > > > > On 05.06.2018 18:45, Steven Scott wrote: > > > >> If there's anyone willing to take a look at the build errors I would > >> appreciate it. I'm trying to work a bug report from a downstream user, > >> and > >> I think the OSX build has an issue that I don't understand. > >> Thanks. > >> > >> On Thu, May 31, 2018 at 1:49 PM, Steven Scott < > >> steve.the.bayes...@gmail.com> > >> wrote: > >> > >> Looking at the Boom package results page, I see that it has errors on > OSX > >>> and two flavors of Linux. > >>> > >>> The OSX install page is here: https://www.r-project. > >>> org/nosvn/R.check/r-release-osx-x86_64/Boom-00install.html . > >>> > >>> I'm trying to understand the nature of the error. The last lines say: > >>> > >>> clang++ -std=gnu++11 -I"/Library/Frameworks/R. > framework/Resources/include" > >>> -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes > >>> -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-c > >>> apitan-x86_64/Rlib/3.5/BH/include" -I"/Volumes/SSD-Data/Builds/R- > >>> dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/ > RcppEigen/include" > >>> -I/usr/local/include -fPIC -Wall -g -O2 -c > Models/TimeSeries/ArModel.cpp > >>> -o Models/TimeSeries/ArModel.o > >>> clang++ -std=gnu++11 -I"/Library/Frameworks/R. > framework/Resources/include" > >>> -DNDEBUG -I. -I../inst/include -IBmath -Imath/cephes > >>> -I"/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el-c > >>> apitan-x86_64/Rlib/3.5/BH/include" -I"/Volumes/SSD-Data/Builds/R- > >>> dev-web/QA/Simon/packages/el-capitan-x86_64/Rlib/3.5/ > RcppEigen/include" > >>> -I/usr/local/include -fPIC -Wall -g -O2 -c > Models/TimeSeries/ArmaModel.cpp > >>> -o Models/TimeSeries/ArmaModel.o > >>> make: *** [Models/TimeSeries/ArmaModel.o] Interrupt: 2 > >>> ERROR: compilation failed for package ‘Boom’ > >>> * removing ‘/Volumes/SSD-Data/Builds/R-dev-web/QA/Simon/packages/el- > cap > >>> itan-x86_64/results/3.5/Boom.Rcheck/Boom’ > >>> > >>> > >>> As I read this, it looks like there was no compiler error, but the > build > >>> was interrupted for some reason. Do others read it differently? If > I'm > >>> reading it right, what needs to happen to re-run the check to clear the > >>> OSX > >>> error status? > >>> > >>> Thanks, > >>> > >>> Steve > >>> > >>> > >> [[alternative HTML version deleted]] > >> > >> __ > >> R-package-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > >> > >> > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
