[Rcpp-devel] RcppOctave on Windows: testing needed

Tue, Oct 8, 2013 8:30 AM

Le 08/10/13 17:12, Dominick Samperi a ?crit :

Sure. There is always the issue of linking against R, etc ... but this 
would eliminate the need for linking against Rcpp.

As for placing the client package in headers, not everything has to go 
there, I have e.g. some functions in Rcpp11 that are only defined in 
Rcpp11's .cpp file.

For example:

const char * type2name__impl(int sexp_type);

What I've done is making it so that Rcpp11's headers calls this one 
instead:

inline const char* type2name(int sexp_type){
	GET_CALLABLE(type2name__impl, sexp_type)
}

and all the magic is in the GET_CALLABLE macro:

#if defined(COMPILING_RCPP11)
#define GET_CALLABLE(__FUN__, ...) return __FUN__( __VA_ARGS__ ) ;
#else
#define GET_CALLABLE(__FUN__, ...)                          \
typedef decltype(__FUN__)* Fun ;                            \
static Fun fun = (Fun)R_GetCCallable( "Rcpp11", #__FUN__) ; \
return fun(__VA_ARGS__) ;
#endif

So if we are compiling Rcpp11 (which is true only for .cpp files in 
Rcpp11), then type2name would directly call type2name__impl, otherwise 
we first get the function pointer with :

static Fun fun = (Fun)R_GetCCallable( "Rcpp11", "type2name__impl" ) ;

and then call fun.

Writing this, I do realize that this in fact uses some C++11 features: 
variadic macros and decltype. It does not mean we could not do it in 
Rcpp, but it would be harder and would involve macro bloat (we would 
need something like GET_CALLABLE_0, GET_CALLABLE_1, GET_CALLABLE_2, ...

Then, when Rcpp11 dynamic library is loaded by R, the __impl function is 
registered:

#define REGISTER(__FUN__) R_RegisterCCallable( "Rcpp11", #__FUN__ 
"__impl", (DL_FUNC)__FUN__ ## __impl );

     REGISTER(type2name)

This allows me to have all in headers and use R's mechanism for 
"linking". Not really linking as it just involves resolving the function 
pointer.

I find this more maintainable than depending on each platform's linker.

Anyway, just saying a client package could use something similar so that 
it does not have to actually link.

Romain

On Tue, Oct 8, 2013 at 9:58 AM, Romain Francois
<romain at r-enthusiasts.com <mailto:romain at r-enthusiasts.com>> wrote:

    Hello,

    I've only been following that thread from a distance. There is
    always so much I can do when it comes to windows.

    Anyway, in Rcpp11 I'm experimenting with completely letting go of
    the whole linking against the Rcpp library and all the issues it has
    brought to the table over the years (should it be static linking,
    how to call Rcpp:::LdFlags, need for a Makevars and a Makevars.win,
    ...).

    With Rcpp11, the only thing you'll ever need will be: LinkingTo: Rcpp11

    This was made possible by moving quite a big chunk of code into
    headers, and for the rest using the R mechanism (R_GetCCallable,
    R_RegisterCCallable) as described in WRE.

    Now, I have no idea yet if Rcpp11 works on windows. Right now I'm
    fearcely developping it, so I don't have time for playing games with
    windows. But that time will come.

    None of the techniques I'm using for that are depending on C++11,
    which would make it possible to use the same strategy for Rcpp too.
    But I fear that because too many depend on the current setting
    (Makevars, Makevars.win, making a library and non portably link
    against it) it is not likely to happen.

    Romain

    Le 08/10/13 15:47, Dominick Samperi a ?crit :

        I just installed the binary with Rtools not on my path (but with
        R in PATH)
        and the first time I tried to load/unload RcppOctave I got the
        obscure
        Windows load error (app terminated "in an unusual way"), but now I
        cannot reproduce it! If you are linking to the static Rcpp lib there
        should be no problems.

        I guess the source distribution is not in sync with the binary?


        On Tue, Oct 8, 2013 at 2:11 AM, Renaud <getoxxx at gmail.com
        <mailto:getoxxx at gmail.com>
        <mailto:getoxxx at gmail.com <mailto:getoxxx at gmail.com>>> wrote:

             Good. Still wondering why path to Rcpp.dll is needed when
        installing
             the binary package since RcppOctave.dll is linked static to
        Rcpp.a
             with full path specified. Most users will use the binary
        and not
             build it from source (which requires Rtools and possibly
        more config.

             Did you try installing the binary directly from the repo
        (with only
             octave bin/ in the path, not Rtools nor R)?

             Renaud


             On Monday, October 7, 2013, Dominick Samperi wrote:

                 I don't think you need to worry about linking against
        the .dll
                 files, as the
                 import libraries (.dll.a files) contain all of the
        information
                 that the linker needs,
                 and you PATH will tell Windows where to find the
        corresponding
                 dll's.
                 It is possible to link against the dll's without using
        import libs,
                 but then various tricks have to be used to specify what is
                 exported from each dll.

                 I downloaded the source for 0.10.1 and it seems to
        build and install
                 ok provided I place Rcpp.dll on PATH. It would save the
        user some
                 trouble if PATH could be updated automatically, but it is
                 probably not
                 a good idea to have R package installation or startup
        update the
                 users
                 environment...



                 On Mon, Oct 7, 2013 at 10:52 AM, Renaud Gaujoux
                 <renaud at mancala.cbio.uct.ac.za
        <mailto:renaud at mancala.cbio.uct.ac.za>__> wrote:

                     Thanks for the details Dominick.
                     I think I got it working now, by ad Octave bin
        directory to
                     the path prior loading RcppOctave library.
                     I tested it by renaming the Octave root directory into
                     something different than at building time.

                     I added the option to specify Octave path via option
                     octave.path (e.g., see ?OctaveInit), so that the
        package
                     loads fine even if Octave is not installed/found.
        The user
                     can also define this option in the .Rprofile if
        Octave is
                     not installed in the path by default.

                     Please let me know if it works for you:

                     install.packages('RcppOctave', repos =
        c(getOption('repos'),
                     'http://web.cbio.uct.ac.za/~__renaud/CRAN'
        <http://web.cbio.uct.ac.za/~renaud/CRAN'>))
                     library(RcppOctave)
                     .O$rand()

                     Note that this version (0.10.1) was linked against the
                     .dll.a files, but will load the .dll files... I
        will try
                     later to link against the .dll files as you suggested.

                     Bests,
                     Renaud



                     On 7 October 2013 16:24, Dominick Samperi
                     <djsamperi at gmail.com <mailto:djsamperi at gmail.com>>
        wrote:

                         Yes, I placed Octave bin on my path. This is
        required to
                         find its dll's for the same reason
                         that Rcpp libs (directory containing Rcpp.dll)
        needs to
                         be on PATH. If you enable clients
                         of RcppOctave.dll to link against functions
        provided by
                         RcppOctave, then these clients
                         will have to add the RcppOctave libs directory
        to their
                         PATH.

                         The Octave dll's must be in its bin directory
        due to
                         another Windows dll search rule:
                         when you run an executable (like octave.exe) that
                         depends on dll's, Windows will
                         resolve the dependencies when the dll's are in
        the same
                         directory as the executable.

                         You should be able to link to liboctave-1.dll using
                         '-loctave-1', provided the bin
                         directory is on your PATH. The gcc '.dll.a'
        suffix means
                         the file is an import library,
                         not a static lib or a shared lib. Import libs tell
                         Windows how to resolve references
                         in the corresponding dll. Windows uses the
        '.lib' suffix
                         for import libs. For your
                         purposes you should link against the dll's, not
        the dll.a's.



                         On Mon, Oct 7, 2013 at 4:59 AM, Renaud Gaujoux
                         <renaud at mancala.cbio.uct.ac.za
        <mailto:renaud at mancala.cbio.uct.ac.za>__> wrote:

                             Dominick, just to be sure: did you have
        Octave bin
                             directory in your PATH when you tested the
        package?
                             Because Octave dlls are also in that directory.

                             I am getting confused on which path/dll is
        to be
                             used where. Currently I build
        RcppOctave.dll linking
                             against the dll.a files found in

        "C:\Octave\Octave3.6.4_gcc4.6.__2\lib\octave\3.6.4".
                             But there are .dll files (although named
                             liboctave-1.dll and not liboctave.dll as I
        would
                             expect) in
        ""C:\Octave\Octave3.6.4_gcc4.__6.2\bin"
                             where octave.exe. and octave-config.exe
        also live.
                             I had tried loading the .dll.a files with
        dyn.load
                             in R but got errors. The -1.dll files load
        fine, and
                             might be the ones I could load manually in
        .onLoad.

                             Now, should I also link using the bin/ path
        and the
                             -1.dll files?

                             Renaud

Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

[Rcpp-devel] RcppOctave on Windows: testing needed

Thread (21 messages)