BEGIN_RCPP uses the variables it defines #671
Conversation
|
This one looks, quite frankly, suspicious. Or maybe I need my 2nd cup of coffee for the morning. Under a certain conditions you add an opening brace as well as |
|
This is just a stripped-down version of |
|
Ack. The name sucks. Maybe And what did your mother tell you about opening issues tickets before PRs? I know you don;t believe me yet that "Suggests ! Depend" (but you will ;-) ) but also PR != Issue. ;-) |
Codecov Report
@@ Coverage Diff @@
## master #671 +/- ##
==========================================
+ Coverage 92.91% 93.19% +0.27%
==========================================
Files 65 65
Lines 3303 3466 +163
==========================================
+ Hits 3069 3230 +161
- Misses 234 236 +2
Continue to review full report at Codecov.
|
|
And of course, this one is basically untestable by reverse-depends But it seems fine on the merits. |
|
The Testing it involves using it in a package; maybe a bunch of acceptance/integration tests in Rcpp that just compile an Rcpp package will be helpful? Gábor has created a few utility packages that will make this a pleasant exercise. A patch is worth a thousand words (and is faster to write, too). |
|
Looks good to me! |
|
LGTM as well. |
|
Yes, this one is simple enough. I clearly misread when I just got up. I think I'd still like to rename it. |
|
I think it's most clear with the current name as it will provide a
symmetrical macro name, so we'd have
BEGIN_RCPP
END_CPP
or
BEGIN_RCPP_NO_RETURN
END_RCPP_NO_RETURN
To me this seems pretty clear.
…On Thu, Apr 13, 2017 at 3:35 PM, Dirk Eddelbuettel ***@***.*** > wrote:
Yes, this one is simple enough. I clearly misread when I just got up.
I think I'd still like to rename it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#671 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAGXx1yyaiSSXV0i7-b3Kxwymgmzshitks5rvnkOgaJpZM4M8l2G>
.
|
|
Sorry,
BEGIN_RCPP_RETURN_ERROR
END_RCPP_RETURN_ERROR
…On Thu, Apr 13, 2017 at 3:35 PM, Dirk Eddelbuettel ***@***.*** > wrote:
Yes, this one is simple enough. I clearly misread when I just got up.
I think I'd still like to rename it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#671 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAGXx1yyaiSSXV0i7-b3Kxwymgmzshitks5rvnkOgaJpZM4M8l2G>
.
|
|
But it does nothing w.r.t. to error handlers or triggers. Which is why I find putting 'ERROR' in there a bit weird. Otherwise of course on board re the symmetry. |
|
The second macro does though (it returns an error rather than throwing one to workaround the win32 can't throw exceptions across modules when static linking to gcc runtime issue). So "RETURN_ERROR" really just means "this code will return an error rather than throwing one". I know you are already aware of all that, just trying to elaborate on why I think the macro name is acceptable as an enclosing "concept" rather than literally what the individual macro does. |
|
One thing I haven't considered: packages that are using the new macro won't work with an older Rcpp version. What's the best way to ensure this? Should we patch |
|
No, we will not overwrite every user's DESCRIPTION file. We're not roxygen2 or devtools or other rude packages. The new macro is one of a large number of entirely optional features within the package, and when maintainers Alice or Bob use it, they are expected to edit their DESCRIPTION files accordingly. So a simple comment next to the definition (ie Or concretely, if an when you use it in dplyr, just change its DESCRIPTION file at that point. |
|
Creating a situation where a new version of Rcpp is required just so we can
avoid an unused variable warning seems like a bad trade to me.
Could we just add a pragma to get around the warning or just live with it?
…On Thu, Apr 13, 2017 at 3:52 PM, Kirill Müller ***@***.***> wrote:
One thing I haven't considered: packages that are using the new macro
won't work with an older Rcpp version. What's the best way to ensure this?
Should we patch DESCRIPTION?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#671 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAGXx5XshKws5yWVK1eWVMtNFtcZsTSIks5rvn0AgaJpZM4M8l2G>
.
|
|
The last commit might work better (doesn't require changes in generated code), but I need to verify that it's actually helpful. |
krlmlr
changed the title
|
Confirmed that the proposed solution actually clears the "unused variable" warnings. |
|
Reverse-depends check worked just fine, so merging this. Proposed change is also nice and shorter. Good. |
|
Awesome, thanks! Are you planning to release mid-May? |
|
Yes, I see no reason to depart from the bi-monthly schedule (apart from having a very busy May myself, but we'll cope). Any plans/concerns regarding the timeline? I did of course skip one your packages in testing, but we've been down that road before ;-) Also just added ChangeLog and NEWS. Alter as needed in next PR and keep in mind that Contributing.md suggests having them in the PR in the first place. |
|
Doh. I guess it would help for dplyr 0.6.0? |
|
Don't worry, locally I have |
|
Thanks for editing the ChangeLog, I wasn't sure to which PR to add the change, and I sure didn't want to add three changes in three PRs... Is there a nice established way to generate change logs from GitHub commit messages? |
|
The single best support is in Emacs -- hitting C-x 4 a in any source file adds a stanza for that file. All git2changelog converters that I have seen are deficient in the sense that you generally want to condense the entry a little (and then once more for NEWS). So I think of this more as a human-edited file. The machine readable log is indeed in git. I just keep complaining and adding them by hand where missing. Worked for 10+ years. ;-) |
Will be used instead of
BEGIN_RCPPfor generated wrappers for C++ interfaces ([[Rcpp::interfaces(cpp)]]).