[Rd] Platform dependent native routine registration

2017-03-07 Thread Gábor Csárdi
Dear All, I am trying to convert a package to native routine registration, and not sure how to best solve the problem of C functions that are only used for a single platform, i.e. Windows, Linux (& Unix) or macOS. If I simply provide a different method table for each platform, then the .Call() st

Re: [Rd] Platform dependent native routine registration

2017-03-07 Thread Dirk Eddelbuettel
On 7 March 2017 at 14:13, Gábor Csárdi wrote: | Dear All, | | I am trying to convert a package to native routine registration, and | not sure how to | best solve the problem of C functions that are only used for a single | platform, i.e. | Windows, Linux (& Unix) or macOS. | | If I simply provid

Re: [Rd] Platform dependent native routine registration

2017-03-07 Thread Gábor Csárdi
On Tue, Mar 7, 2017 at 2:45 PM, Dirk Eddelbuettel wrote: [...] > > Could you resort to preprocessor conditioning to only compile the code > relevant for a particular platform while hiding away the inapplicable parts? Yes, I do exactly that. The problem is that the R code still has .Call(c_non_ex

Re: [Rd] Platform dependent native routine registration

2017-03-07 Thread Dirk Eddelbuettel
On 7 March 2017 at 14:47, Gábor Csárdi wrote: | On Tue, Mar 7, 2017 at 2:45 PM, Dirk Eddelbuettel wrote: | [...] | > | > Could you resort to preprocessor conditioning to only compile the code | > relevant for a particular platform while hiding away the inapplicable parts? | | Yes, I do exactly t

Re: [Rd] Platform dependent native routine registration

2017-03-07 Thread Gábor Csárdi
On Tue, Mar 7, 2017 at 2:51 PM, Dirk Eddelbuettel wrote: [...] > | But I just found that using string literals in .Call() works just > | fine. Hopefully > | this will still be allowed in the long run: > | > | .Call("c_non_existent_function_on_this_platform", ...) > > So you are adjusting the liter

Re: [Rd] Platform dependent native routine registration

2017-03-07 Thread Martyn Plummer
On Tue, 2017-03-07 at 14:57 +, Gábor Csárdi wrote: > On Tue, Mar 7, 2017 at 2:51 PM, Dirk Eddelbuettel > wrote: > [...] > > > But I just found that using string literals in .Call() works just > > > fine. Hopefully > > > this will still be allowed in the long run: > > > > > > .Call("c_non_exis

Re: [Rd] Control statements with condition with greater than one should give error (not just warning) [PATCH]

2017-03-07 Thread Karl Millar via R-devel
Is there anything that actually requires R core members to manually do significant amounts of work here? IIUC, you can do a CRAN run to detect the broken packages, and a simple script can collect the emails of the affected maintainers, so you can send a single email to them all. If authors don't

Re: [Rd] Control statements with condition with greater than one should give error (not just warning) [PATCH]

2017-03-07 Thread Gabriel Becker
I'm just throwing this out there, but maybe CRAN (or some other testing machinery) should get a "strict testing" build of R in which suppressWarnings is reassigned to identity... Or maybe suppressWarnings could check for, eg an environment variable and turn itself into a no-op when present, so tha

Re: [Rd] Seeking advice regarding compilation of large libraries using RTools (Windows)

2017-03-07 Thread Ray Donnelly
On Mon, Mar 6, 2017 at 8:21 PM, Richard Beare wrote: > Yep - simpleITK is available at github.com/SimpleITK/SimpleITK. There's > also github.com/SimpleITK/SimpleITKRInstaller - a devtools based installer > for mac and linux. > > CMake has a range of build environments. I experimented with MSYS2 a

Re: [Rd] Seeking advice regarding compilation of large libraries using RTools (Windows)

2017-03-07 Thread Richard Beare
So far I've been using the separate cmake package (direct from kitware), rather than one available via msys2 (as I started without msys2). I'll have a play with the msys2 versions. The problem definitely seems to be with ld - it sits at high load for days at a time, and I haven't seen it complete