-
-
Notifications
You must be signed in to change notification settings - Fork 213
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
Comments
Paging @jjallaire -- there was a reason for this but it escapes me now what that was. |
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. |
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. |
Is this a 'hot' or needed item for the profiler you are working on? |
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? |
Gaa. Replied in the wrong place. Release is pretty much ready and I could ship nowishly. |
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). |
Yeah, next release is better even though I have a feeling that this may end up being totally iinocuous. |
For me, using |
Do you remember which particular issues are worked around this way? |
Sure
If you put eval(bquote(function()(.(quote(.Call))(.(sym), PACKAGE=.(pkg))))); Which directly uses |
Hm are you talking by chance about
There are helpers for the registration issue; |
Ah. I was confused. Thanks for the clarification. I only thought that was the reason. |
Generate .Call(...) instead of .Primitive(.Call)(...) for cppFunction
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()
?The text was updated successfully, but these errors were encountered: