-
Notifications
You must be signed in to change notification settings - Fork 94
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
Removing the FrameProxyObject
workaround
#751
Conversation
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.
LGTM, thanks @madsbk !
Actually the failure is legit @madsbk , seems like it's an infinite recursion. |
Yes, that is because rapidsai/cudf#9397 hasn't been merged yet. |
I will work a bit more on this PR, maybe we can remove the need of the |
Codecov Report
@@ Coverage Diff @@
## branch-21.12 #751 +/- ##
===============================================
Coverage ? 62.93%
===============================================
Files ? 21
Lines ? 2898
Branches ? 0
===============================================
Hits ? 1824
Misses ? 1074
Partials ? 0 Continue to review full report at Codecov.
|
Now that cuDF doesn't use the cython implemented Table class, we don't need the specialized FrameProxyObject class anymore. We can simpy use ProxyObject everywhere.
centos7 in queue for over 4 hours. rerun tests |
rerun tests |
1 similar comment
rerun tests |
Seems like the errors are waiting for dask/distributed#5380 to be merged. |
This PR address the asymmetry in the following line in `Frame.copy()`: ```python new_frame = self.__class__.__new__(type(self)) ``` The problem is that `self.__class__` might not equal `type(self)`, which is the case for proxy objects like the one used in Dask-CUDA. Related Dask-CUDA PR: rapidsai/dask-cuda#751 cc. @randerzander Authors: - Mads R. B. Kristensen (https://github.com/madsbk) Approvers: - GALI PREM SAGAR (https://github.com/galipremsagar) URL: #9397
rerun tests |
@gpucibot merge |
Adding testing of cudf dataframe copy, which fails prior to rapidsai/cudf#9397
UPDATE: This PR now handles the jit-unspill failures we have been seeing with cudf v21.12.
Some background, when we introduced
ProxyObject
, cudf was usingcudf._lib.table.Table
as the base class for all frame-like objects (dataframes, series, etc).Table
was implemented in cython so our proxy object had to derive fromTable
in order to support cython functions. The result was to use the classFrameProxyObject
as a workaround:Now that cudf uses
Frame
, a pure Python class, we don't need this workaround anymore. In fact, usingFrameProxyObject
triggers some infinite recursion errors when used together with v21.12+cc. @randerzander