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

[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_ARGS__ ) ;
> | #else
> | #define RCPP_DEBUG( MSG, ... )
> | #endif
> |
> | So that we can write:
> |
> | RCPP_DEBUG( "bla bla %d", 42 )
> |
> | and leave it there when the code is not debugged.
>
> Thanks for all the details and counts on macros. I was mostly aware of this
> as you may recall that I wrote a few of those variants in Rcpp too, including
> some of the DEBUG ones.

This is not private email. You were rambling about overuse of macros, I 
was just trying to show that :
- sometimes they do something that can't be done
- I'm using less of them in Rcpp11, so I'm definitely concerned about 
macro overuse.

> | > Can you (portably, with all (major) compilers and OS choices) pick out
> | > symbols even when they have attribute_hidden set as R does all over its
> | > sources?
> |
> | No.
> |
> | But since that sort of thing are typically the task of the package
> | maintainer: I don't care.
>
> I don't follow at all.

Nevermind.

> You appeared to be saying you had a solution to the
> linking issue, I point out that hidden symbols are still hidden, and you say
> it doesn't matter?  How so?

Of course hidden symbols are still hidden. what's the point of hiding 
them if you can see them anyway.

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

read_symbols_from_object_file gives me the names of all the objects in a 
package .so file, then I can grep around for some pattern and do some 
code generation.

I'm suggesting that as a possible way to not have to write the code by 
hand as you seem to not want to do that.

We don't really need read_symbols_from_object_file for that, we could 
have something like an [[Rcpp::register]] attribute so that when we 
write this in a package .cpp:

// [[Rcpp::register]]
void foo( Bar boom ){
    // whatever
}

Using something like read_symbols_from_object_file would recognize these 
funcions based on their names, that can be:
- using some known pattern, e.g.

void foo__impl()

- the fact that the function is inside some known namespace, e.g.

namespace Export {
     void foo() ;
}

The name as given by nm definitely contains namespace information.

> | read_symbols_from_object_file is just a convoluted way to call nm.
> |
> |   tools:::read_symbols_from_object_file
> | function (f)
> | {
> |      if (!nzchar(nm <- Sys.which("nm")))
> |          return()
> |      f <- file_path_as_absolute(f)
> |      if (!(file.info(f)$size))
> |          return()
> |      s <- strsplit(system(sprintf("%s -Pg %s", shQuote(nm), shQuote(f)),
> |          intern = TRUE), " +")
> |      n <- length(s)
> |      tab <- matrix("", nrow = n, ncol = 4L)
> |      colnames(tab) <- c("name", "type", "value", "size")
> |      i <- rep.int(seq_len(n), sapply(s, length))
> |      j <- unlist(lapply(s, seq_along))
> |      tab[n * (j - 1L) + i] <- unlist(s)
> |      tab
> | }
>
> That is something different from the linking issue we were discussing. This
> is a pretty printer for (non-stripped) object code using nm(1).

But not unrelated.

> | But again, I don't care. Generating code is the task of the package
> | maintainer, so if I want to use something like that, it just has to work
> | on whatever I use.
>
> I believe we were talking about two somewhat distinct issues here.
>
> Dirk

I see a connection.

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