Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cppFuncton() emits .Primitive(".Call") instead of just .Call #795

Closed
krlmlr opened this issue Jan 3, 2018 · 13 comments
Closed

cppFuncton() emits .Primitive(".Call") instead of just .Call #795

krlmlr opened this issue Jan 3, 2018 · 13 comments

Comments

@krlmlr
Copy link
Contributor

krlmlr commented Jan 3, 2018

See example below. This is a problem for joint profiling of R and native code, because I'm looking for .Call entries on the call stack, which are absent if the primitive is invoked directly (r-prof/jointprof#8). Would you accept a PR that swtiches to .Call()?

print(Rcpp::cppFunction("int x() { return 1; }"))
#> function () 
#> .Primitive(".Call")(<pointer: 0x7fd9fb532060>)

Created on 2018-01-03 by the reprex package (v0.1.1.9000).

@eddelbuettel
Copy link
Member

eddelbuettel commented Jan 3, 2018

Paging @jjallaire -- there was a reason for this but it escapes me now what that was.

@jjallaire
Copy link
Member

I believe that I borrowed the implementation approach for native routine dispatching from the inline package (which presumably also does this although I haven't checked). I honestly don't understand the difference (if any) so would yield to any more knowledgeable opinion.

@eddelbuettel
Copy link
Member

Well we can try. Seems like a larger change, but hey I have a new package for parallel reverse depends checks so we can try a PR.

@eddelbuettel
Copy link
Member

Is this a 'hot' or needed item for the profiler you are working on?

@krlmlr
Copy link
Contributor Author

krlmlr commented Jan 10, 2018

Yes. It would be great to have it in the next Rcpp release, by when would you need it so that you can include it?

@eddelbuettel
Copy link
Member

Gaa. Replied in the wrong place. Release is pretty much ready and I could ship nowishly.

@krlmlr
Copy link
Contributor Author

krlmlr commented Jan 10, 2018

I have a workaround for this problem in my code, so I don't mind if this has to wait a bit. Feel free to release (but thanks for the reminder).

@eddelbuettel
Copy link
Member

Yeah, next release is better even though I have a feeling that this may end up being totally iinocuous.

@mattfidler
Copy link

For me, using .Primitive(".Call") was needed to avoid some R CMD Check issues; I just saw this and wanted to point out this issue. I think it is a bit silly and a false positive in this case, but I hade similar problems with dparser

@krlmlr
Copy link
Contributor Author

krlmlr commented Jan 30, 2018

Do you remember which particular issues are worked around this way?

@mattfidler
Copy link

Sure

Registration problem:
  symbol 'sym' in the local frame:
   .Call(sym, PACKAGE = pkg)
See chapter 'System and foreign language interfaces' in the 'Writing R
Extensions' manual.

If you put Primitive(".Call") this goes away. Eventually I settled on

eval(bquote(function()(.(quote(.Call))(.(sym), PACKAGE=.(pkg)))));

Which directly uses .Call and gets around this check issue.

@eddelbuettel
Copy link
Member

eddelbuettel commented Jan 30, 2018

Hm are you talking by chance about R CMD check output? You should never submit cppFunction() generated code (which is what this ticket is about) to R CMD check.

cppFunction() is for creating ad-hoc code at the prompt; such code usually does not go into a package where we use compileAttributes() instead.

There are helpers for the registration issue; compileAttributes() now does this for you.

@mattfidler
Copy link

Ah. I was confused. Thanks for the clarification. I only thought that was the reason.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants