Chore/extendr 0.7.0 support #1187
Conversation
ju6ge
force-pushed
the
chore/extendr-0.7.0-support
branch
from
ad9358b
to
1f2abd2
Compare
There was a problem hiding this comment.
@ju6ge Many thanks for your efforts here and in #1154, they are really appreciated.
My main issue with this PR is that it can degrade some error messages, can you take a look at that?
Also, as you say in #1154 (comment):
Though I am still unsure that the changes are sufficient. There might me be more parts of the code that use the previous behavior and expect to return the error to R. So there might be more cases where users can run into segfaults that are not tested for already!
At the very least I would like a better way to check if the converesion will work before attempting it. Checking against a string is very unergonomic!
so I'm not too confident this should be merged as-is. @CGMossa I know you already answered to some of that in #1154, but it would help if you could just skim through the changes in Rust code.
I'd also like @eitsupi to check that
| @@ -20,7 +20,6 @@ use polars::prelude as pl; | |||
| use polars::prelude::{ExprEvalExtension, NestedType, SortOptions}; | |||
| use std::any::Any; | |||
| use std::ops::{Add, Div, Mul, Rem, Sub}; | |||
| use std::result::Result; | |||
There was a problem hiding this comment.
Why this change? Isn't it cleaner to keep this rather than putting std::result:: everywhere?
| if rv != "ExternalPtr.set_class([\"RPolarsDataType\"]" { | ||
| return Err(RPolarsErr::new().bad_val(rv).mistyped(tn::<RPolarsDataType>().to_string()).into()); | ||
| } |
There was a problem hiding this comment.
As you said in #1154 (comment), checking on this string looks very fragile
| pl$DataFrame(x = 1, schema = list(x = "foo")), | ||
| "expected RPolarsDataType" | ||
| ) | ||
| expect_grepl_error(pl$DataFrame(x = 1, schema = list(x = "foo"))) |
There was a problem hiding this comment.
This change (and others below) make the test pass but they degrade the error messages. For example, instead of
expected RPolarsDataType we now have Expected ExternalPtr got Strings which is quite cryptic. Is there a way to not modify those error messages?
| expect_grepl_error(pl$n_unique(pl$all())) | ||
| expect_grepl_error(pl$n_unique(1)) | ||
| expect_error(pl$n_unique(pl$all())) | ||
| expect_error(pl$n_unique(1)) |
There was a problem hiding this comment.
expect_grepl_error() is different from expect_error() because it can catch polars errors that have a weird structure in R.
If we don't check the pattern of the message, then expect_error() can be used indeed, but can you rather keep expect_grepl_error() and add some pattern matching?
|
Sure thing, I will gladly update this MR to address the concerns about the tests. Though I will have to see if I find time for this next week. I am coming more from the rust side of things, and the |
There was a problem hiding this comment.
@ju6ge Thanks for working on this!
It would be great to see the R CMD check error resolved.
I am wondering if you are overlooking #1152.
I mean, we may abandon our entire current codebase in the near future, and since we will be switching from extendr to savvy in the future, I don't see much value in spending time on an extendr-only hack.
If you are willing to work on developing r-polars, it would be great if you could check out the next branch.
Normally, using Therefore, we made a custom |
|
@eitsupi I have added my thoughts to #1152 @etiennebacher thanks for the explanation, i will take a look at it and see what i come up with. |
This MR builds upon #1154 and updates the test suite and rust code to work as expected.