This is discussed in the "Writing R Extensions" manual section 5.9.10:
Named objects and copying.
.Call does not copy its arguments and it is not safe to modify them, as
you have found, since multiple symbols may refer to the same object. If
you are going to modify an argument to .Call you should
> Matthew Fowles Kulukundis
> on Tue, 5 Apr 2016 11:17:30 -0400 writes:
> All~
> CHECK_this_length macro expands to multiple statements making it unsafe to
> use in a single line `if` statement (as is happening near line 335). This
> fixes the macro using the standard
Dear Dmitri,
If it's only a small number of functions then move them the relevant
functions for A to B so that B works without A. Then Import these functions
from B in A. Hence A depends on B but B is independent of A.
It is requires to move a lot of functions than you better create a package
C w
> Matthew Fowles Kulukundis
> on Thu, 7 Apr 2016 11:21:56 -0400 writes:
> Martin~
> Sorry about the bad patch. I work on C++ at Google. We built a check for
> clang-tidy that identifies errors of this form and discovered the error
> here as part of our search. I am ju
Hi Thierry,
Thanks for that, the trouble is functions are package specific so moving
from one package to another could be a solution, but I would rather save
that as a last resort.
As mentioned, creating a package C with all the common functions could also
be an option, but this strategy quickly
Hi Dmitri,
I was thinking about something similar for my packages. There might be
other (more clever) ways, but one way is to:
- make package A dependent on package B (so that the namespace of B is
automatically available when loading package A)
- make package B "Suggest" package A (not "Depend" w
At the risk of stating the over-obvious: there's also the option of
creating just a single package containing all functions. None of the
functions that create the interdependencies need to be exported that way.
Btw, his question is probably better at home at the r-package-devel list.
Best,
M
> but this strategy quickly inflates the number of packages on CRAN.
CRAN contains 8210 packages today, so I would not worry about
adding an extra one.
Also, I think several small packages are preferable to one large one
because attaching a big one just to get the one or two functions you
want is
Hi all,
Oh right, I wasn't aware there is an r-package-devel list (probably better
suited for this question).
So I'm getting all sorts of advice, to create a big package and also better
to have multiple smaller ones. Sure, all of those are possible, just less
attractive. Adrian's suggestion might
