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
GH-37208: [R] Use currrently running R binary to compile test program (nix install) #37225
Conversation
|
r/tools/nixlibs.R
Outdated
@@ -197,7 +197,9 @@ compile_test_program <- function(code) { | |||
# Note: if we wanted to check for openssl on macOS, we'd have to set the brew | |||
# path as a -I directory. But since we (currently) only run this code to | |||
# determine whether we can download a Linux binary, it's not relevant. | |||
runner <- "`R CMD config CXX17` `R CMD config CPPFLAGS` `R CMD config CXX17FLAGS` `R CMD config CXX17STD` -E -xc++" | |||
r_exec <- paste(R.home(component = "bin"), "R CMD config", sep="/") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use R_CMD_config()
here?
Lines 380 to 382 in 43c05c5
R_CMD_config <- function(var) { | |
tools::Rcmd(paste("config", var), stdout = TRUE) | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original author did not use it.
Maybe because all 4 commands need to run at the same time?
I would not know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nealrichardson Can we use R_CMD_config()
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why not, and I dug through the PR from last year when this was added and don't see any reason why it has to be this way.
Could you use our PR template instead of removing it entirely? |
@github-actions crossbow submit -g r |
Revision: bd296ce Submitted crossbow builds: ursacomputing/crossbow @ actions-b2e2361c9a |
…#37236) ### Rationale for this change To simplify the implementation of `Time32Type`, `Time64Type`, `Date32Type`, and `Date64Type`, it would be helpful to create an abstract `arrow.type.TemporalType` class that the date and time types can inherit from. As a first step, we can modify the implementation of `TimestampType` to inherit from `TemporalType`. This mimics the class inheritance hierarchy from the C++ libraries. ### What changes are included in this PR? 1. Added a new MATLAB class called `arrow.type.TemporalType`. It inherits from `arrow.type.FixedWidthType` and defines one read-only property: `TimeUnit`. 2. Modified the MATLAB class `arrow.type.TimestampType` to inherit from `arrow.type.TemporalType` instead of `arrow.type.FixedWidthType`. 3. Renamed the C++ `proxy::TimestampType` methods `timeUnit()` and `timeZone()` to `getTimeUnit()` and `getTimeZone()`. ### Are these changes tested? Yes. The existing tests in `tTimetampType.m` cover these changes. ### Are there any user-facing changes? No. ### Future Directions 1. Add `arrow.type.Time32Type` (#37231) 2. Add `arrow.type.Time64Type` (#37225) 3. Add `arrow.type.Date32Type` (#37229), 4. Add `arrow.type.Time64Type` (#37230). 5. Add `arrow.array.Time32Array` 6. Add `arrow.array.Time64Array` 7. Add `arrow.array.Date32Array` 8. Add `arrow.array.Date64Array` * Closes: #37234 Lead-authored-by: Sarah Gilmore <sgilmore@mathworks.com> Co-authored-by: Kevin Gurney <kgurney@mathworks.com> Signed-off-by: Kevin Gurney <kgurney@mathworks.com>
Co-authored-by: Neal Richardson <neal.p.richardson@gmail.com>
@github-actions crossbow submit -g r |
Revision: ced8973 Submitted crossbow builds: ursacomputing/crossbow @ actions-bf7a320d75 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit f27dc02. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them. |
… class (apache#37236) ### Rationale for this change To simplify the implementation of `Time32Type`, `Time64Type`, `Date32Type`, and `Date64Type`, it would be helpful to create an abstract `arrow.type.TemporalType` class that the date and time types can inherit from. As a first step, we can modify the implementation of `TimestampType` to inherit from `TemporalType`. This mimics the class inheritance hierarchy from the C++ libraries. ### What changes are included in this PR? 1. Added a new MATLAB class called `arrow.type.TemporalType`. It inherits from `arrow.type.FixedWidthType` and defines one read-only property: `TimeUnit`. 2. Modified the MATLAB class `arrow.type.TimestampType` to inherit from `arrow.type.TemporalType` instead of `arrow.type.FixedWidthType`. 3. Renamed the C++ `proxy::TimestampType` methods `timeUnit()` and `timeZone()` to `getTimeUnit()` and `getTimeZone()`. ### Are these changes tested? Yes. The existing tests in `tTimetampType.m` cover these changes. ### Are there any user-facing changes? No. ### Future Directions 1. Add `arrow.type.Time32Type` (apache#37231) 2. Add `arrow.type.Time64Type` (apache#37225) 3. Add `arrow.type.Date32Type` (apache#37229), 4. Add `arrow.type.Time64Type` (apache#37230). 5. Add `arrow.array.Time32Array` 6. Add `arrow.array.Time64Array` 7. Add `arrow.array.Date32Array` 8. Add `arrow.array.Date64Array` * Closes: apache#37234 Lead-authored-by: Sarah Gilmore <sgilmore@mathworks.com> Co-authored-by: Kevin Gurney <kgurney@mathworks.com> Signed-off-by: Kevin Gurney <kgurney@mathworks.com>
…rogram (nix install) (apache#37225) ### Rationale for this change See apache#37208. ### What changes are included in this PR? Use the currrently running R binary to compile test program (nix install). ### Are these changes tested? No. Installation. ### Are there any user-facing changes? No * Closes: apache#37208 Lead-authored-by: Bruno Tremblay <bruno@boostao.ca> Co-authored-by: Sutou Kouhei <kou@cozmixng.org> Co-authored-by: Neal Richardson <neal.p.richardson@gmail.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>
Rationale for this change
See #37208.
What changes are included in this PR?
Use the currrently running R binary to compile test program (nix install).
Are these changes tested?
No. Installation.
Are there any user-facing changes?
No