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'
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
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
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
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
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
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
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
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.)
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
10 matches
Mail list logo
