Re: [Rcpp-devel] RcppOctave on Windows: testing needed

2013-10-10 Thread Dominick Samperi
A few additional close out notes: 1. It turns out that Apple (and Homebrew) no longer support Fortran, so I had to specify an external Fortran compiler and options: $ export F77="/usr/local/bin/gfortran -arch x86_64" $ brew install octave --default-fortran-flags "-O2" 2. The fortran compiler ca

Re: [Rcpp-devel] RcppOctave on Windows: testing needed

2013-10-10 Thread Steve Lianoglou
Just to close this out (for posterity again). Dominick had pointed out to me off list that the octave formula isn't in the default homebrew install, and to get it you've got to "tap" their science repository by following the instructions here: https://github.com/Homebrew/homebrew-science I had f

Re: [Rcpp-devel] RcppOctave on Windows: testing needed

2013-10-10 Thread Steve Lianoglou
Hi, On Thu, Oct 10, 2013 at 12:26 PM, Dominick Samperi wrote: > The problem here is that Mac Ports installs a very old version of Octave. > Installing the latest version (3.6.4) from source seems to resolve the > issue. At least .O$version() works! > > Installing Octave from source under MacOS ta

Re: [Rcpp-devel] [Rcppoctave-user] RcppOctave on Windows: testing needed

2013-10-10 Thread Dirk Eddelbuettel
On 10 October 2013 at 15:26, Dominick Samperi wrote: | The problem here is that Mac Ports installs a very old version of Octave. | Installing the latest version (3.6.4) from source seems to resolve the | issue. At least .O$version() works! Nice one! Thanks a bunch for doing all the work to confi

Re: [Rcpp-devel] RcppOctave on Windows: testing needed

2013-10-10 Thread Dominick Samperi
The problem here is that Mac Ports installs a very old version of Octave. Installing the latest version (3.6.4) from source seems to resolve the issue. At least .O$version() works! Installing Octave from source under MacOS takes some work due to many dependencies, and the need for work-arounds for

Re: [Rcpp-devel] [Summary] (Was: question re: LdFlags, RcppLdFlags

2013-10-10 Thread Romain Francois
Le 10/10/13 19:00, Dirk Eddelbuettel a écrit : On 10 October 2013 at 18:30, Romain Francois wrote: | Rcpp::register attribute so that compileAttributes would also generate | the registration code. So I don't need to use nm anyway. At that point you can register the 'extern "C"' interfaces at th

Re: [Rcpp-devel] [Summary] (Was: question re: LdFlags, RcppLdFlags

2013-10-10 Thread Dirk Eddelbuettel
On 10 October 2013 at 18:30, Romain Francois wrote: | Rcpp::register attribute so that compileAttributes would also generate | the registration code. So I don't need to use nm anyway. At that point you can register the 'extern "C"' interfaces at the C level. AFAICT that is the only portable choi

Re: [Rcpp-devel] [Summary] (Was: question re: LdFlags, RcppLdFlags

2013-10-10 Thread Romain Francois
Le 10/10/13 18:16, Dirk Eddelbuettel a écrit : On 10 October 2013 at 18:02, Romain Francois wrote: | To give some context, I'm taking about using R's linking mechanism. I'm | talking about generating automatically the code that: | - registers a function with R_RegisterCCallable | - grabs the fun

Re: [Rcpp-devel] [Summary] (Was: question re: LdFlags, RcppLdFlags

2013-10-10 Thread Dirk Eddelbuettel
On 10 October 2013 at 18:02, Romain Francois wrote: | To give some context, I'm taking about using R's linking mechanism. I'm | talking about generating automatically the code that: | - registers a function with R_RegisterCCallable | - grabs the function with R_GetCCallable [...] | The name as

Re: [Rcpp-devel] [Summary] (Was: question re: LdFlags, RcppLdFlags

2013-10-10 Thread Romain Francois
Le 10/10/13 17:36, Dirk Eddelbuettel a écrit : On 10 October 2013 at 17:15, Romain Francois wrote: | They are quite useful for debugging too: | | #if RCPP_DEBUG_LEVEL > 0 | #define RCPP_DEBUG( fmt, ... ) Rprintf( "%20s:%4d " fmt "\n" | , short_file_name(__FILE__), __LINE__, ##__VA_AR

Re: [Rcpp-devel] [Summary] (Was: question re: LdFlags, RcppLdFlags

2013-10-10 Thread Dirk Eddelbuettel
On 10 October 2013 at 17:15, Romain Francois wrote: | They are quite useful for debugging too: | | #if RCPP_DEBUG_LEVEL > 0 | #define RCPP_DEBUG( fmt, ... ) Rprintf( "%20s:%4d " fmt "\n" | , short_file_name(__FILE__), __LINE__, ##__VA_ARGS__ ) ; | #else | #define RCPP_DEBUG( MSG, ...

Re: [Rcpp-devel] [Summary] (Was: question re: LdFlags, RcppLdFlags

2013-10-10 Thread Romain Francois
Le 10/10/13 16:51, Dirk Eddelbuettel a écrit : To bring a bit of closure to this endless thread: It appear from his commit logs that Romain made the change in his dplyRcpp project we are now supposed to make per R Core: Demote packages from Depends: to Imports:, and import what is needed. That,

Re: [Rcpp-devel] [Summary] (Was: question re: LdFlags, RcppLdFlags

2013-10-10 Thread Dirk Eddelbuettel
To bring a bit of closure to this endless thread: It appear from his commit logs that Romain made the change in his dplyRcpp project we are now supposed to make per R Core: Demote packages from Depends: to Imports:, and import what is needed. That, as best as I can tell, seems to be the way to

Re: [Rcpp-devel] RcppOctave on Windows: testing needed

2013-10-10 Thread Renaud Gaujoux
Can you try with this modified version of the file? I wrapped the const char* strings into std::string, maybe this will make Mac happier. Let's communicate on this Mac issue off Rcpp-devel list for now on, since it is not directly related to Rcpp, but keep rcppoctave-user (where we are currently a