I think it would be quite useful to have some community repository of code
snippets dealing with such situations. R-exts gives advice and pieces of code
which are useful, but they are not complete solutions and situations like
Dirk's example are not that uncommon. (E.g., I recall some of the spa
Hi Reed,
On 11 May 2023 at 11:15, Reed A. Cartwright wrote:
| I'm curious why you chose to call cmake from make instead of from configure.
| I've always seen cmake as part of the configure step of package building.
Great question! Couple of small answers: i) This started as a 'proof of
concept'
I want to thank Bill and everyone that reached out to me individually. It
looks like Bill's solution is the right one, as he was able to replicate
and fix the problem. I am still a bit confused on why this would occur on
some OSs and not others (probably due to different compilers), but I think
the
I see the problem when I compile the C++ code on Ubuntu 20.04 and the
latest R-devel with
C++ compiler: ‘g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
If I change all the unadorned 'abs' calls in src/nn_matchC_vec.cpp with the
prefix 'std::' the problem goes away.
-Bill
On Thu, May 11, 2023 at 11:
Dirk,
I'm curious why you chose to call cmake from make instead of from
configure. I've always seen cmake as part of the configure step of package
building.
Thanks,
Reed
On Thu, May 11, 2023, 04:17 Dirk Eddelbuettel wrote:
>
> On 11 May 2023 at 09:02, Martin Maechler wrote:
> | I've been told
Hello,
I'm the mainter of the package *MatchIt*, which uses *Rcpp* to implement
nearest neighbor matching. One way to customize nearest neighbor
matching is to add a caliper, which is the largest distance two units can
be from each other before they are not allowed to be matched. I've had some
use
On 11 May 2023 at 09:02, Martin Maechler wrote:
| I've been told in private that the above "be happy if"
| may *not* be a good idea,
| or rather even close to impossible as cmake seems to not fit
| well, at all, with the quite sophisticated
| autoconf -> configure -> make
| setup we have w
The problem is that there's no way to declare that an internal function
should or shouldn't be treated as an S3 method, other than by declaring
it as one in NAMESPACE and exporting it. If you read the thread
"Unfortunate function name generic.something" that started last week,
you'll see the
> Martin Maechler
> on Wed, 10 May 2023 21:31:29 +0200 writes:
> Dirk Eddelbuettel
> on Wed, 10 May 2023 07:01:37 -0500 writes:
>> Simon,
>> Explicitly declaring
>> SystemRequirements: cmake
>> appears to be insufficient to get a bu
