Hi Reed,
Unfortunately I don't think there is any other strategy here -- I
would agree that your best bet is to just enable exceptions in the
bundled library.
Best,
Kevin
On Fri, Apr 4, 2025 at 5:59 PM Reed A. Cartwright
wrote:
>
> I have updated my package, rbedrock [1-2], to remove a bundled
Hi Murray,
(repeating some of the conversation we had off-list)
Sorry for the trouble -- I was just in the process of submitting
RcppParallel to CRAN, and the first submission I made had this same
issue. That should now be fixed up with RcppParallel 5.1.10, which is
now on CRAN. Hopefully your ne
Hi Josiah,
Indeed, the right thing to do is to declare the library in the
SystemRequirements file. However, other than some specific documented
usages which affect how R builds the package (e.g. C++ standards and
GNU make), I believe the field is meant more just to inform users of
the external dep
It may also be useful to use:
options(internet.info = 1)
to get more information on the web requests R is making. (See the
documentation in ?options for more details.)
Looking at the source code in available.packages, R does iterate
through the repositories in the same order they're provided
Would libSegFault be useful here?
https://lemire.me/blog/2023/05/01/under-linux-libsegfault-and-addr2line-are-underrated/
On Sun, Mar 3, 2024, 5:15 PM Rolf Turner wrote:
> On Sun, 3 Mar 2024 11:14:44 +0300
> Ivan Krylov via R-package-devel wrote:
>
> > Hello,
> >
> > This may be of interest to
FWIW, as far as I can tell, Sys.readlink() still doesn't handle
symlinks (or junction points) on Windows. Were you thinking of
normalizePath()? That does now resolve both symlinks and junction
points on Windows (courtesy of a lot of work from Tomas), although I
don't recall the exact versions in wh
Package authors could use 'cargo vendor' to include Rust crate sources
directly in their source R packages. Would that be acceptable?
Presumedly, the vendored sources would be built using the versions
specified in an accompanying Cargo.lock as well.
https://doc.rust-lang.org/cargo/commands/cargo-
Hi Jonathan,
I'm not certain if this is the issue you're encountering, but I've
noticed that different versions of R may write to different locations
in the registry.
Right now, on my machine, I see entries for R 4.1.3 installed at:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\R-core\R
That shouldn't be happening, at least not by default. However, RcppParallel
does ship with tbbmalloc_proxy, which is a library that, when loaded, will
overload the default allocators to use TBB's allocators instead. The
intention is normally that these libraries would be loaded via e.g.
LD_PRELOAD
On Fri, Aug 6, 2021 at 3:47 PM Tim Keitt wrote:
>
> As configure is not run on windows, but according to the writing extensions
> docs you can run commands in Makevars, is that not preferable for simple
> cases?
IMHO it's ultimately up to you. Do what makes your life easier as a
package maintaine
Based on this output:
** libs
Warning: this package has a non-empty 'configure.win' file,
so building only the main architecture
Does adding Biarch: TRUE to your package DESCRIPTION file help?
Best,
Kevin
On Sun, May 16, 2021 at 2:47 PM David Cortes
wrote:
>
> I recently tried adding a configu
I suspect the cause is this:
https://github.com/bradleyjeck/epanet2toolkit/blob/aa698568ab85db133f8634928e8cfe661b41ed57/src/epanet2.h#L42-L61
Usually, you only need to explicitly use __declspec if you're
compiling with MSVC -- it shouldn't be necessary when using a MinGW
toolchain (as R's toolch
>From https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-ASAN/rTLS/00check.log,
you can see errors of the form:
==3566104==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7fffc2651f80 at pc 0x7f7ba5b635de bp 0x7fffc2651eb0 sp
0x7fffc2651ea0
< ... >
The slides here explain what that means
I think this is the pertinent error:
> make: cargo: Command not found
That is, make is assuming that the cargo utility is installed and
available on the PATH, but that doesn't appear to be true on the CRAN
winbuilder machine.
The salso package (https://cran.r-project.org/package=salso)
explicitl
My understanding is that many Linux OSes package the clang compiler, the
libc++ standard library, and the headers used by the libc++ standard
library separately. To install those headers, you likely need (e.g. on
Ubuntu):
sudo apt install libc++-dev libc++abi-dev
to be able to build and compi
Note that by calling py_module_available() in your .onLoad(), as done here:
https://github.com/r-cas/caracas/blob/418b3a552de0203c3d2f960f0e4235f7891db71d/R/init.R#L51
you are forcing reticulate to initialize the Python session eagerly
when your package is loaded (so before the user might've had
m/LTLA/basilisk/issues/2
Best,
Kevin
On Wed, Jan 8, 2020 at 8:34 AM Kevin Ushey wrote:
>
> On Tue, Jan 7, 2020 at 10:42 PM Sokol Serguei wrote:
> >
> > Thanks for this hint.
> >
> > Le 07/01/2020 à 20:47, Kevin Ushey a écrit :
> > > The newest version of retic
On Tue, Jan 7, 2020 at 10:42 PM Sokol Serguei wrote:
>
> Thanks for this hint.
>
> Le 07/01/2020 à 20:47, Kevin Ushey a écrit :
> > The newest version of reticulate does something very similar: R
> > packages can declare their Python package dependencies in the
> >
The newest version of reticulate does something very similar: R
packages can declare their Python package dependencies in the
Config/reticulate field of a DESCRIPTION file, and reticulate can read
and use those dependencies to provision a Python environment for the
user when requested (currently us
It would help if you shared your source code, so we know what you've tried.
Presumably, you need to either export the variables you're setting, or
just pass them along when invoking CMake. For example:
ENVVAR=1
export ENVVAR
cmake <...>
or
ENVVAR=1 cmake <...>
Best,
Kevin
On T
The 'long long' type does not exist in the C++98 standard, so you need to
explicitly request C++11 or C++14 (the former which is now fairly broadly
supported across compilers on different systems).
For more detail, see in the R extensions manual:
https://cran.r-project.org/doc/manuals/r-release/R
It would be easiest for others to diagnose if you could make your
package sources available (e.g. on GitHub) so that others might try to
download your package and reproduce the issue if possible on their own
machines.
Best,
Kevin
On Thu, Nov 8, 2018 at 12:24 AM Rampal S. Etienne
wrote:
>
> Yeste
Using this line of code as an example:
SEXP hdf5r_ns = PROTECT(eval(lang2(install("getNamespace"),
mkString("hdf5r")), R_GlobalEnv));
The issue is fairly nuanced. There are a few main things to note
before we can understand the issue:
1. The order of evaluation of arguments in C is unspe
Hi Erin,
The R extensions manual should be helpful here -- in particular, see the
sections on the 'src/Makevars' file and configuration of the Fortran
compiler:
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Makevars
In particular, in your 'src/Makevars' file, you'll likely w
Note that your attachment was lost, so we don't know what your package code
looks like. It's helpful to host your package sources somewhere publicly
accessible (e.g. GitHub) to make it easier for others to access sources
quickly from a web browser.
My best guess is that your 'init.c' is missing th
The UBSAN error:
cvode.cpp:58:11: runtime error: call to function
cv_Roberts_dns(double, Rcpp::Vector<14, Rcpp::PreserveStorage>)
through pointer to incorrect function type 'Rcpp::Vector<14,
PreserveStorage> (*)(double, Rcpp::Vector<14, PreserveStorage>)'
/tmp/RtmplnLW4G/sourceCpp-x86_64-pc-linux-
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++ so
Hi,
Glancing at the R CMD check errors, available at:
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/RJafroc-00install.html)
It seems like the issues relate to ambiguous calls to 'sqrt()'. This
particular issue is discussed in R-exts, at:
https://cran.r-project.org/doc/manuals/r-
ld handle
these warnings emitted myself from TBB would still be appreciated (for
myself and other package authors who might want to embed 3rd party
code in their packages).
Thanks,
Kevin
On Thu, Jan 18, 2018 at 11:19 AM, Kevin Ushey wrote:
>
> Hi,
>
> This is mostly a question for the CRAN
Hi,
This is mostly a question for the CRAN team, but I figured posting here
would be best since other package maintainers could see the responses as
well.
I'm currently in the process of preparing a submission of RcppParallel to
CRAN. RcppParallel bundles Intel's Threading Building Blocks (https:
You can try placing this in your src/Makevars[.win] file:
CXXFLAGS = -DBOOST_NO_LONG_LONG
The dplyr package does this (and more) to avoid 'long long' leaking in
from Boost headers. See e.g.
https://github.com/tidyverse/dplyr/blob/ff719f53f88f2f03a298fa0ea489b902527ee2f1/src/Makevars#L2
The
Most importantly, this _is_ a recent-ish change in R CMD check. Previously,
R CMD check did not warn about missing imports from 'base' R packages (that
is, R packages distributed with R, having priority 'base'); now it
correctly does. While packages with priority 'base' are loaded by default
in mos
On Wed, Aug 3, 2016 at 3:09 PM, MTurgeon wrote:
> Hi Ege,
>
> For writing to standard output/error, you can use Rcout or Rcerr (defined by
> Rcpp; they even have a vignette showing how to use it in the Rcpp gallery).
> Alternatively, if you're using C code, you can replace printf by Rprintf
> (thi
It looks like most of these usages of std::cout, std::cerr and abort
are coming from the logging infrastructure:
https://github.com/micolous/s2-geometry-library/blob/master/geometry/base/logging.h
If you wanted to make this work on CRAN, you could patch these files
in a number of ways:
You could
You could abuse the LinkingTo: field of the DESCRIPTION file, to
specify 'packages you want installed alongside your package that you
won't necessarily use at runtime'. (It's possible that 'R CMD check'
might warn about strange usages of LinkingTo:, but I'm not sure)
You could also just place thes
ere may be some conflict. For now, it is just a warning soI will keep
> looking for the problem and if I can solve it post back here as it must be
> quite subtle given all else is working fine.
>
> Glenn
>
>
>> On Jul 24, 2016, at 3:27 PM, Kevin Ushey wrote:
>>
>&
Did you call `devtools::document()` before building and checking your
package? Everything looks fine to me with your test example. You
should also double-check that you have up-to-date versions of the
devtools and roxygen2 packages.
It's also worth knowing that nowadays you can generally just use
Hi Guillaume,
I have a script that does this (for OS X) here, taking advantage of
the new '--batch' argument to lldb:
https://github.com/kevinushey/etc/blob/master/lang/r/mac/bin/r-lldb
Note that, on recent versions of OS X due to system integrity
protection, this may not work with the syste
Is it possible that `getwd()` is reporting something on the CRAN build
servers that your `decompose_path()` doesn't handle? For example, your
tests fail for me if I run them while in the root directory (on OS X).
Kevin
On Thu, May 12, 2016 at 12:37 AM, Richard Cotton wrote:
> Thanks Bob,
>
> I'd
FWIW, it's a very _very_ bad idea to add methods to S3 generics for
classes you don't 'own'. Some code might be written with the
expectation that `plot(df)` actually does dispatch to `plot.default`.
This implies that simply loading your package would break code in
surprising ways.
I would strongly
I'm not sure if that's correct -- from what I see, in the generated Rd
documentation:
- The 'usage' is drawn from the S4 generic,
- The 'arguments' are drawn from the function.
I think R CMD check is correctly warning about that.
On Fri, Jul 31, 2015 at 2:56 PM, Hadley Wickham wrote:
>>> It see
I've posted an MRE at https://github.com/klutometis/roxygen/issues/362.
The issue occurs when a function and an S4 generic have the same name;
I imagine this is fairly uncommon? Wouldn't the function be masked by
the S4 generic and effectively be invisible after the package was
loaded?
On Thu, Ju
Hi Uwe,
It seems like this is quite a major change; I imagine it will affect many
packages (since lots of packages implicitly assume other 'base' packages,
like 'utils', will always be available in an R session). IIUC, in the
latest versions of R-devel, only the 'base' package can be assumed
avail
The GitHub search feature is also quite useful for seeing how other package
authors have constructed Makevars (or Makevars.win) when compiling with
custom targets. For example, a quick search of how some authors manipulate
OBJECTS in Makevars.win:
https://github.com/search?utf8=%E2%9C%93&q=OBJECT
44 matches
Mail list logo
