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++
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 pack
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:
>
Thanks Dirk,
This will cut down the size of my compilation logs dramatically.
On Thu, Jul 19, 2018 at 6:06 AM Iñaki Úcar wrote:
> Great! Many thanks for sharing this, Dirk.
>
> Iñaki
> El jue., 19 jul. 2018 a las 14:37, Dirk Eddelbuettel
> () escribió:
> >
> >
> > As some of you may have
Thanks Dirk. IMO the package is in good shape otherwise. I'll wait hear
from the CRAN maintainers.
S
On Wed, Apr 4, 2018 at 2:53 PM, Dirk Eddelbuettel <e...@debian.org> wrote:
>
> On 4 April 2018 at 14:15, Steven Scott wrote:
> | These appear to be caused by an ill formed
I've been trying to update the Boom package to the next version, and it
hasn't been going so well. Hoping someone can help me figure out what next
steps I should take.
I got the attached mail from auto-check. From what I can tell the new
version of Boom (0.8.0) has two issues. Some long path
Thanks Uwe.
On Sat, Apr 21, 2018 at 3:02 PM, Uwe Ligges <lig...@statistik.tu-dortmund.de
> wrote:
>
>
> On 21.04.2018 20:06, Steven Scott wrote:
>
>> No word from the maintainers.
>>
>
> Only one maintainer is reading this list.
>
>
> I submitted
No word from the maintainers. I submitted a revised version of the package
just now (with an updated date in DESCRIPTION).
If someone could look at it in the next few days I'd appreciate it. Thanks.
On Wed, Apr 4, 2018 at 3:01 PM, Steven Scott <steve.the.bayes...@gmail.com>
wrote:
&g
Also, consider different names. The convention in R is for a probability
distribution foo to have dfoo, pfoo, qfoo, and rfoo. I'm not sure what S,
F and H stand for in your notation, so maybe consider giving them more
descriptive names? If F is for Fisher then dFisherCor or something like
that.
Is anyone on this list using bazel as a build system, and if so have you
found a good BUILD rule for unit tests based on testthat? Thanks.
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
I'd mock the tests you want run on Cran and keep live fire tests that you
can run manually. Just don't include the live fire stuff in the package.
On Tue, Apr 16, 2019, 10:57 AM Will wrote:
> Hello everyone,
>
> I'm sorry to bother you, but I would like some help getting a package (
>
My Boom package makes a C++ library available to package authors (mainly
me). The wrapped library is used outside of R and must comply with
external style rules such as UseLongDescriptiveNames, and files must be
named for the class they contain. From time to time a
LongDescriptiveFileName, when
wrote:
>
> On 18 April 2019 at 10:37, Steven Scott wrote:
> | My Boom package makes a C++ library available to package authors (mainly
> | me). The wrapped library is used outside of R and must comply with
> | external style rules such as UseLongDescriptiveNames, and files mu
Roy, I don't have an answer for you, but I have a similar issue.
Does your code happen to have a C++ component that takes a long time to
compile?
On Tue, Apr 23, 2019 at 5:11 PM Roy Mendelssohn - NOAA Federal via
R-package-devel wrote:
>
>
>
> -- Forwarded message --
> From: Roy
y
> understand CRAN's position. When you have 1000s of package to test on
> different OS, if everything takes too long it would be a disaster. At the
> same time, basically the last three days I have been trying to figure out
> how to get the times down.
>
> -Roy
>
&g
I'm trying to build an ASAN enabled version of my R library to help debug
errors found by CRAN on my last submission. I'm tantalizingly close, but
need some help figuring out what's wrong with my configuration.
I'm using a docker container that I think contains a version of R built
with the
Rolf, I will strive to do better.
Please note that you load a package with library(...). Just sayin'.
On Wed, Mar 25, 2020 at 6:16 PM Rolf Turner wrote:
>
> On 26/03/20 10:17 am, Steven Scott wrote:
>
> > I'm trying to build an ASAN enabled version of my R library
&
The errors are all around std::ostream. My guess is that Eigen is missing
an #include. The missing include was probably included transitively in
earlier versions of clang, but clang11 cleaned up some files that didn't
need that include themselves, and the downstream file got broken as a
result.
One of my packages (bsts) appears to have a memory error identified by ASAN.
I'm trying to build an ASAN-enabled R+bsts so that I can debug the error.
I'm using the rocker image rocker/r-devel-ubsan-clang, loaded and run as
follows:
docker run --cap-add SYS_PTRACE -e PASSWORD= --rm -p 8787:8787
I agree with the consensus that documentation is for humans, while tests
are for computers.
On Thu, Jul 16, 2020, 8:41 PM wrote:
> On Thu, 16 Jul 2020, Ben Bolker wrote:
>
> > FWIW/in defense of the OP, this is a *very* common idiom in the base R
> code
> > base. There may be some false
You can often find this kind of code on netlib.org. Just include it with
the fortran code in your package.
On Tue, Jul 21, 2020 at 11:22 AM Wang, Zhu wrote:
> Sorry for not making myself clear: The Fortran subroutine in an R package
> needs to call incomplete gamma function.
>
> -Original
Charlie,
The folks at CRAN try hard to serve everyone, but sometimes they wind up
making up rules as they go along. I'd add another sentence or two about
the data, perhaps with an eye towards the wide world of "citizen data
scientists" who don't know about Alan's book. Then resubmit the package
One of the basic principles of testing is "test interface, not
implementation." Tests that violate this principle become "change detector
tests" instead of "correctness tests" and essentially prevent any
improvements to the code. In C++ objects have "public" and "private"
methods, and the
I'll let others discuss the technical details of how to set up the licence
files. I want to make sure you know that using AGPL is a good way to
ensure that nobody in tech uses your package. Maybe that's intended, but
when I was at Google the ONLY software we were specifically prohibited from
Compiled code is another source of long names. Some libraries are produced
by companies with style restrictions that demand LongDescriptiveNames for
functions and classes, and which expect file names to match the name of the
class contained within. If you've got
The Boom package builds a library against which other packages link. The
library is built using the Makevars mechanism using the line
${AR} rc $@ $^
A user has asked me to change 'rc' to 'rcs' so that 'ranlib' will be run on
the archive. This is apparently needed for certain flavors of macs.
2023, at 8:42 AM, Dirk Eddelbuettel wrote:
> >
> >
> > On 20 December 2023 at 11:10, Steven Scott wrote:
> > | The Boom package builds a library against which other packages link.
> The
> > | library is built using the Makevars mechanism using the line
> > |
> > |
Greetings everyone, though I expect this message is mainly for Dirk.
CRAN checks of my bsts/Boom package generate an ASAN error that the CRAN
maintainers have asked me to look into. I recall doing this before (this
error has been there for several years now) via a docker image that Dirk
had set
28 matches
Mail list logo
