MINOR: [R] Work around test failure in tidyquery revdep by nealrichardson · Pull Request #43498 · apache/arrow

nealrichardson · 2024-07-31T20:24:40Z

Rationale for this change

See #43317 (comment). tidyquery is assembling queries in some way such that when summarize.arrow_dplyr_query() is called, the calling environment isn't a call, so match.call() fails.

What changes are included in this PR?

This PR wraps the match.call() call in a try(). The call is only used to do abandon_ship() on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to collect() yourself.

Are these changes tested?

I couldn't figure out how to reproduce what was going on inside tidyquery to write a reproducer, and I don't think this is worth adding tidyquery to Suggests for. I confirmed locally that tidyquery tests pass with this change, so our revdeps should be clear.

Are there any user-facing changes?

🙅

jonkeane · 2024-07-31T20:28:09Z

 }

 # Else, warn, collect(), and run in regular dplyr
- call <- get("call", envir = env)


I'm a little surprised by this deletion, was this essentially overwritting what was in call when it ran? Or something else?

I just moved it up to L227

AAAAAH I totally missed that. Thanks

jonkeane

Thanks for this!

### Rationale for this change See #43317 (comment). `tidyquery` is assembling queries in some way such that when `summarize.arrow_dplyr_query()` is called, the calling environment isn't a call, so `match.call()` fails. ### What changes are included in this PR? This PR wraps the `match.call()` call in a `try()`. The call is only used to do `abandon_ship()` on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to `collect()` yourself. ### Are these changes tested? I couldn't figure out how to reproduce what was going on inside `tidyquery` to write a reproducer, and I don't think this is worth adding `tidyquery` to Suggests for. I confirmed locally that `tidyquery` tests pass with this change, so our revdeps should be clear. ### Are there any user-facing changes? 🙅 Authored-by: Neal Richardson <neal.p.richardson@gmail.com> Signed-off-by: Jonathan Keane <jkeane@gmail.com>

conbench-apache-arrow · 2024-08-01T05:19:01Z

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 0dec116.

There were 3 benchmark results indicating a performance regression:

Commit Run on test-mac-arm at 2024-07-31 23:30:44Z
- tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-06, scale_factor=1
- tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-11, scale_factor=1
and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about 6 possible false positives for unstable benchmarks that are known to sometimes produce them.

nealrichardson · 2024-07-31T20:24:40Z

Rationale for this change

See #43317 (comment). tidyquery is assembling queries in some way such that when summarize.arrow_dplyr_query() is called, the calling environment isn't a call, so match.call() fails.

What changes are included in this PR?

This PR wraps the match.call() call in a try(). The call is only used to do abandon_ship() on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to collect() yourself.

Are these changes tested?

I couldn't figure out how to reproduce what was going on inside tidyquery to write a reproducer, and I don't think this is worth adding tidyquery to Suggests for. I confirmed locally that tidyquery tests pass with this change, so our revdeps should be clear.

Are there any user-facing changes?

🙅

jonkeane · 2024-07-31T20:28:09Z

 }

 # Else, warn, collect(), and run in regular dplyr
- call <- get("call", envir = env)


I'm a little surprised by this deletion, was this essentially overwritting what was in call when it ran? Or something else?

I just moved it up to L227

AAAAAH I totally missed that. Thanks

jonkeane

Thanks for this!

### Rationale for this change See #43317 (comment). `tidyquery` is assembling queries in some way such that when `summarize.arrow_dplyr_query()` is called, the calling environment isn't a call, so `match.call()` fails. ### What changes are included in this PR? This PR wraps the `match.call()` call in a `try()`. The call is only used to do `abandon_ship()` on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to `collect()` yourself. ### Are these changes tested? I couldn't figure out how to reproduce what was going on inside `tidyquery` to write a reproducer, and I don't think this is worth adding `tidyquery` to Suggests for. I confirmed locally that `tidyquery` tests pass with this change, so our revdeps should be clear. ### Are there any user-facing changes? 🙅 Authored-by: Neal Richardson <neal.p.richardson@gmail.com> Signed-off-by: Jonathan Keane <jkeane@gmail.com>

conbench-apache-arrow · 2024-08-01T05:19:01Z

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 0dec116.

There were 3 benchmark results indicating a performance regression:

Commit Run on test-mac-arm at 2024-07-31 23:30:44Z
- tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-06, scale_factor=1
- tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-11, scale_factor=1
and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about 6 possible false positives for unstable benchmarks that are known to sometimes produce them.

nealrichardson · 2024-07-31T20:24:40Z

Rationale for this change

See #43317 (comment). tidyquery is assembling queries in some way such that when summarize.arrow_dplyr_query() is called, the calling environment isn't a call, so match.call() fails.

What changes are included in this PR?

This PR wraps the match.call() call in a try(). The call is only used to do abandon_ship() on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to collect() yourself.

Are these changes tested?

I couldn't figure out how to reproduce what was going on inside tidyquery to write a reproducer, and I don't think this is worth adding tidyquery to Suggests for. I confirmed locally that tidyquery tests pass with this change, so our revdeps should be clear.

Are there any user-facing changes?

🙅

jonkeane · 2024-07-31T20:28:09Z

 }

 # Else, warn, collect(), and run in regular dplyr
- call <- get("call", envir = env)


I'm a little surprised by this deletion, was this essentially overwritting what was in call when it ran? Or something else?

I just moved it up to L227

AAAAAH I totally missed that. Thanks

jonkeane

Thanks for this!

### Rationale for this change See #43317 (comment). `tidyquery` is assembling queries in some way such that when `summarize.arrow_dplyr_query()` is called, the calling environment isn't a call, so `match.call()` fails. ### What changes are included in this PR? This PR wraps the `match.call()` call in a `try()`. The call is only used to do `abandon_ship()` on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to `collect()` yourself. ### Are these changes tested? I couldn't figure out how to reproduce what was going on inside `tidyquery` to write a reproducer, and I don't think this is worth adding `tidyquery` to Suggests for. I confirmed locally that `tidyquery` tests pass with this change, so our revdeps should be clear. ### Are there any user-facing changes? 🙅 Authored-by: Neal Richardson <neal.p.richardson@gmail.com> Signed-off-by: Jonathan Keane <jkeane@gmail.com>

conbench-apache-arrow · 2024-08-01T05:19:01Z

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 0dec116.

There were 3 benchmark results indicating a performance regression:

Commit Run on test-mac-arm at 2024-07-31 23:30:44Z
- tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-06, scale_factor=1
- tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-11, scale_factor=1
and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about 6 possible false positives for unstable benchmarks that are known to sometimes produce them.

nealrichardson · 2024-07-31T20:24:40Z

Rationale for this change

See #43317 (comment). tidyquery is assembling queries in some way such that when summarize.arrow_dplyr_query() is called, the calling environment isn't a call, so match.call() fails.

What changes are included in this PR?

This PR wraps the match.call() call in a try(). The call is only used to do abandon_ship() on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to collect() yourself.

Are these changes tested?

I couldn't figure out how to reproduce what was going on inside tidyquery to write a reproducer, and I don't think this is worth adding tidyquery to Suggests for. I confirmed locally that tidyquery tests pass with this change, so our revdeps should be clear.

Are there any user-facing changes?

🙅

jonkeane · 2024-07-31T20:28:09Z

 }

 # Else, warn, collect(), and run in regular dplyr
- call <- get("call", envir = env)


I'm a little surprised by this deletion, was this essentially overwritting what was in call when it ran? Or something else?

I just moved it up to L227

AAAAAH I totally missed that. Thanks

jonkeane

Thanks for this!

### Rationale for this change See #43317 (comment). `tidyquery` is assembling queries in some way such that when `summarize.arrow_dplyr_query()` is called, the calling environment isn't a call, so `match.call()` fails. ### What changes are included in this PR? This PR wraps the `match.call()` call in a `try()`. The call is only used to do `abandon_ship()` on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to `collect()` yourself. ### Are these changes tested? I couldn't figure out how to reproduce what was going on inside `tidyquery` to write a reproducer, and I don't think this is worth adding `tidyquery` to Suggests for. I confirmed locally that `tidyquery` tests pass with this change, so our revdeps should be clear. ### Are there any user-facing changes? 🙅 Authored-by: Neal Richardson <neal.p.richardson@gmail.com> Signed-off-by: Jonathan Keane <jkeane@gmail.com>

conbench-apache-arrow · 2024-08-01T05:19:01Z

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 0dec116.

There were 3 benchmark results indicating a performance regression:

Commit Run on test-mac-arm at 2024-07-31 23:30:44Z
- tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-06, scale_factor=1
- tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-11, scale_factor=1
and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about 6 possible false positives for unstable benchmarks that are known to sometimes produce them.

nealrichardson · 2024-07-31T20:24:40Z

Rationale for this change

See #43317 (comment). tidyquery is assembling queries in some way such that when summarize.arrow_dplyr_query() is called, the calling environment isn't a call, so match.call() fails.

What changes are included in this PR?

This PR wraps the match.call() call in a try(). The call is only used to do abandon_ship() on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to collect() yourself.

Are these changes tested?

I couldn't figure out how to reproduce what was going on inside tidyquery to write a reproducer, and I don't think this is worth adding tidyquery to Suggests for. I confirmed locally that tidyquery tests pass with this change, so our revdeps should be clear.

Are there any user-facing changes?

🙅

jonkeane · 2024-07-31T20:28:09Z

 }

 # Else, warn, collect(), and run in regular dplyr
- call <- get("call", envir = env)


I'm a little surprised by this deletion, was this essentially overwritting what was in call when it ran? Or something else?

I just moved it up to L227

AAAAAH I totally missed that. Thanks

jonkeane

Thanks for this!

### Rationale for this change See #43317 (comment). `tidyquery` is assembling queries in some way such that when `summarize.arrow_dplyr_query()` is called, the calling environment isn't a call, so `match.call()` fails. ### What changes are included in this PR? This PR wraps the `match.call()` call in a `try()`. The call is only used to do `abandon_ship()` on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to `collect()` yourself. ### Are these changes tested? I couldn't figure out how to reproduce what was going on inside `tidyquery` to write a reproducer, and I don't think this is worth adding `tidyquery` to Suggests for. I confirmed locally that `tidyquery` tests pass with this change, so our revdeps should be clear. ### Are there any user-facing changes? 🙅 Authored-by: Neal Richardson <neal.p.richardson@gmail.com> Signed-off-by: Jonathan Keane <jkeane@gmail.com>

conbench-apache-arrow · 2024-08-01T05:19:01Z

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 0dec116.

There were 3 benchmark results indicating a performance regression:

Commit Run on test-mac-arm at 2024-07-31 23:30:44Z
- tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-06, scale_factor=1
- tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-11, scale_factor=1
and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about 6 possible false positives for unstable benchmarks that are known to sometimes produce them.

nealrichardson · 2024-07-31T20:24:40Z

Rationale for this change

See #43317 (comment). tidyquery is assembling queries in some way such that when summarize.arrow_dplyr_query() is called, the calling environment isn't a call, so match.call() fails.

What changes are included in this PR?

This PR wraps the match.call() call in a try(). The call is only used to do abandon_ship() on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to collect() yourself.

Are these changes tested?

I couldn't figure out how to reproduce what was going on inside tidyquery to write a reproducer, and I don't think this is worth adding tidyquery to Suggests for. I confirmed locally that tidyquery tests pass with this change, so our revdeps should be clear.

Are there any user-facing changes?

🙅

jonkeane · 2024-07-31T20:28:09Z

 }

 # Else, warn, collect(), and run in regular dplyr
- call <- get("call", envir = env)


I'm a little surprised by this deletion, was this essentially overwritting what was in call when it ran? Or something else?

I just moved it up to L227

AAAAAH I totally missed that. Thanks

jonkeane

Thanks for this!

### Rationale for this change See #43317 (comment). `tidyquery` is assembling queries in some way such that when `summarize.arrow_dplyr_query()` is called, the calling environment isn't a call, so `match.call()` fails. ### What changes are included in this PR? This PR wraps the `match.call()` call in a `try()`. The call is only used to do `abandon_ship()` on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to `collect()` yourself. ### Are these changes tested? I couldn't figure out how to reproduce what was going on inside `tidyquery` to write a reproducer, and I don't think this is worth adding `tidyquery` to Suggests for. I confirmed locally that `tidyquery` tests pass with this change, so our revdeps should be clear. ### Are there any user-facing changes? 🙅 Authored-by: Neal Richardson <neal.p.richardson@gmail.com> Signed-off-by: Jonathan Keane <jkeane@gmail.com>

conbench-apache-arrow · 2024-08-01T05:19:01Z

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 0dec116.

There were 3 benchmark results indicating a performance regression:

Commit Run on test-mac-arm at 2024-07-31 23:30:44Z
- tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-06, scale_factor=1
- tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-11, scale_factor=1
and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about 6 possible false positives for unstable benchmarks that are known to sometimes produce them.

nealrichardson · 2024-07-31T20:24:40Z

Rationale for this change

See #43317 (comment). tidyquery is assembling queries in some way such that when summarize.arrow_dplyr_query() is called, the calling environment isn't a call, so match.call() fails.

What changes are included in this PR?

This PR wraps the match.call() call in a try(). The call is only used to do abandon_ship() on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to collect() yourself.

Are these changes tested?

I couldn't figure out how to reproduce what was going on inside tidyquery to write a reproducer, and I don't think this is worth adding tidyquery to Suggests for. I confirmed locally that tidyquery tests pass with this change, so our revdeps should be clear.

Are there any user-facing changes?

🙅

jonkeane · 2024-07-31T20:28:09Z

 }

 # Else, warn, collect(), and run in regular dplyr
- call <- get("call", envir = env)


I'm a little surprised by this deletion, was this essentially overwritting what was in call when it ran? Or something else?

I just moved it up to L227

AAAAAH I totally missed that. Thanks

jonkeane

Thanks for this!

### Rationale for this change See #43317 (comment). `tidyquery` is assembling queries in some way such that when `summarize.arrow_dplyr_query()` is called, the calling environment isn't a call, so `match.call()` fails. ### What changes are included in this PR? This PR wraps the `match.call()` call in a `try()`. The call is only used to do `abandon_ship()` on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to `collect()` yourself. ### Are these changes tested? I couldn't figure out how to reproduce what was going on inside `tidyquery` to write a reproducer, and I don't think this is worth adding `tidyquery` to Suggests for. I confirmed locally that `tidyquery` tests pass with this change, so our revdeps should be clear. ### Are there any user-facing changes? 🙅 Authored-by: Neal Richardson <neal.p.richardson@gmail.com> Signed-off-by: Jonathan Keane <jkeane@gmail.com>

conbench-apache-arrow · 2024-08-01T05:19:01Z

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 0dec116.

There were 3 benchmark results indicating a performance regression:

Commit Run on test-mac-arm at 2024-07-31 23:30:44Z
- tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-06, scale_factor=1
- tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-11, scale_factor=1
and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about 6 possible false positives for unstable benchmarks that are known to sometimes produce them.

nealrichardson · 2024-07-31T20:24:40Z

Rationale for this change

See #43317 (comment). tidyquery is assembling queries in some way such that when summarize.arrow_dplyr_query() is called, the calling environment isn't a call, so match.call() fails.

What changes are included in this PR?

This PR wraps the match.call() call in a try(). The call is only used to do abandon_ship() on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to collect() yourself.

Are these changes tested?

I couldn't figure out how to reproduce what was going on inside tidyquery to write a reproducer, and I don't think this is worth adding tidyquery to Suggests for. I confirmed locally that tidyquery tests pass with this change, so our revdeps should be clear.

Are there any user-facing changes?

🙅

jonkeane · 2024-07-31T20:28:09Z

 }

 # Else, warn, collect(), and run in regular dplyr
- call <- get("call", envir = env)


I'm a little surprised by this deletion, was this essentially overwritting what was in call when it ran? Or something else?

I just moved it up to L227

AAAAAH I totally missed that. Thanks

jonkeane

Thanks for this!

### Rationale for this change See #43317 (comment). `tidyquery` is assembling queries in some way such that when `summarize.arrow_dplyr_query()` is called, the calling environment isn't a call, so `match.call()` fails. ### What changes are included in this PR? This PR wraps the `match.call()` call in a `try()`. The call is only used to do `abandon_ship()` on in-memory data anyway. So if the call is not available, it treats it like you're making a query on a Dataset and it tells you to `collect()` yourself. ### Are these changes tested? I couldn't figure out how to reproduce what was going on inside `tidyquery` to write a reproducer, and I don't think this is worth adding `tidyquery` to Suggests for. I confirmed locally that `tidyquery` tests pass with this change, so our revdeps should be clear. ### Are there any user-facing changes? 🙅 Authored-by: Neal Richardson <neal.p.richardson@gmail.com> Signed-off-by: Jonathan Keane <jkeane@gmail.com>

conbench-apache-arrow · 2024-08-01T05:19:01Z

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 0dec116.

There were 3 benchmark results indicating a performance regression:

Commit Run on test-mac-arm at 2024-07-31 23:30:44Z
- tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-06, scale_factor=1
- tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-11, scale_factor=1
and 1 more (see the report linked below)

The full Conbench report has more details. It also includes information about 6 possible false positives for unstable benchmarks that are known to sometimes produce them.

MINOR: [R] Work around test failure in tidyquery revdep
efabb86

nealrichardson requested review from jonkeane and thisisnic as code owners July 31, 2024 20:24

github-actionsBot added Component: R awaiting review Awaiting review labels Jul 31, 2024

nealrichardson mentioned this pull request Jul 31, 2024
[R] CRAN packaging checklist for version 17.0.0 #43317
Closed
38 tasks

jonkeane reviewed Jul 31, 2024
View reviewed changes

Comment threadr/R/dplyr-eval.R

github-actionsBot added awaiting changes Awaiting changes and removed awaiting review Awaiting review labels Jul 31, 2024

jonkeane reviewed Jul 31, 2024
View reviewed changes

jonkeane approved these changes Jul 31, 2024
View reviewed changes

github-actionsBot added awaiting merge Awaiting merge awaiting changes Awaiting changes and removed awaiting changes Awaiting changes awaiting merge Awaiting merge labels Jul 31, 2024

jonkeane merged commit 0dec116 into apache:mainJul 31, 2024

jonkeane removed the awaiting changes Awaiting changes label Jul 31, 2024