On Thu, Mar 16, 2017 at 10:12 PM, Pavel Krivitsky wrote:
> On Thu, 2017-03-16 at 21:31 +, Gábor Csárdi wrote:
>> I different extension is fine I think. I use .pmt (poor man's
>> templates) for something very similar.
>
> No, both .pmt and .inc produce an R CMD check warning. (The package
> its
On Thu, 2017-03-16 at 21:31 +, Gábor Csárdi wrote:
> I different extension is fine I think. I use .pmt (poor man's
> templates) for something very similar.
No, both .pmt and .inc produce an R CMD check warning. (The package
itself compiles correctly in either case.)
I different extension is fine I think. I use .pmt (poor man's
templates) for something very similar.
Gabor
On Thu, Mar 16, 2017 at 9:11 PM, Pavel Krivitsky wrote:
> Dear All,
>
> Since some C header files in a package I maintain have identical macro
> definitions (which have a different meanings
Dear All,
Since some C header files in a package I maintain have identical macro
definitions (which have a different meanings, since other macro
definitions differ), I tried to reduce code duplication to split the
common macros into their own files, which don't get #included directly
by any C file
Thanks Duncan,
You say there aren't a lot of people that no how to do that. Do you know
of anyone who would? I assume Dirk would be a likely person given the use
of Rtools with Rcpp. I am happy to try and work at this as I have a vested
interest in getting CUDA packages to become functional on
On 16/03/2017 11:00 AM, Charles Determan wrote:
Greetings,
Not sure if this should be on the Rcpp list but it isn't strictly related
to Rcpp but to package building involving Rcpp so I am posting it here.
I am often working on GPU packages that use either OpenCL or CUDA. OpenCL
is nice because
Greetings,
Not sure if this should be on the Rcpp list but it isn't strictly related
to Rcpp but to package building involving Rcpp so I am posting it here.
I am often working on GPU packages that use either OpenCL or CUDA. OpenCL
is nice because it doesn't require a special additional compiler
FWIW it appears that QEMU has an admittedly slow implementation that supports
some architectures beyond x86/amd64 and that there is recent activity. See
http://wiki.qemu-project.org/Documentation/Platforms/SPARC
An alternative might be to persuade Oracle to provide a Sparc-builder, since
they
a
I completely agree that testing on SPARC Solaris is valuable, however
much of a nuisance it is. But I also agree that it would be great if
we could find a way to provide a publicly accessible SPARC Solaris
testing framework.
On Thu, Mar 16, 2017 at 6:49 AM, Uwe Ligges
wrote:
>
>
> On 15.03.2017
On 15.03.2017 18:30, Ben Bolker wrote:
On 17-03-15 11:09 AM, J C Nash wrote:
Possibly tangential, but has there been any effort to set up a Sparc
testbed? It
seems we could use a network-available (virtual?) machine, since this
platform is
often the unfortunate one. Unless, of course, there'
10 matches
Mail list logo
