-
Notifications
You must be signed in to change notification settings - Fork 18
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
Adapt schema-print for notebook use #342
Conversation
This pull request has been linked to Shortcut Story #12282: Expand R-UDF validation coverage: make sure essential API calls work. |
95b63f8
to
3acd0b8
Compare
3acd0b8
to
c44fedb
Compare
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 was a little tied up earlier so belated comments but I would like to disentangle the PR into the (simpler, limited scope) UINT32 additions to some switch statements (maybe with unit tests hitting them) and the more fluid-in-motion issue of pretty printing schemas etc which is already in my lap and where the PR helps a little less.
And, if I may, from a purely procedural standpoint, I have over the years added a github PR stanza / form / suggestion in one or two open source projects where I recommend 'issue ticket and discussion first' before entering with PR which (personal view here) can add more friction that needed unless coordinated. I still think that helps a PRs going beyond trivial ones. |
2f8a6d9
to
6119c68
Compare
Thanks @eddelbuettel ! I'm looking forward to scheduling (currently unscheduled) of SC 13272 and 13273 which we had discussed, among other things, at some length. Would you prefer I abandon this PR at this point? |
We can probably throw a few PR together in the blender because I'll do some work on SC 13272 and 13273 which are close in spirit and scope. So we'll see where we end up with. Nothing wrong with adding a few I have this overarching fundamental problem that we have "some many functions" already making it hard at time to find functionality (!!) and the only we seem to be able to offer is more functions still. Tricky issue. |
Thanks @eddelbuettel ! @antalakas and I are of the viewpoint that invisible schema-printing in notebook contexts is a blocker for promoting cloud-R in notebooks. Personally I would prefer to merge these |
Maybe I am not seeing the forest for the trees but is there a reason why you cannot add pretty-printers you need now into the cloud package you are in control of? |
@eddelbuettel our cloud docs show examples of things like printing schemas. Python support for doing this in notebooks exists; R has a gap for notebooks which this PR addresses. While I've done significant work in See for example https://docs.tiledb.com/cloud/tutorials/start-here |
d36f8dd
to
dc073b4
Compare
This PR is good, it gets us almost to the finish line of not relying on core code (to Please see #345 (a new PR into this branch for your review) and have a look with your test arrays, it it is looking ok on the ones I tried. |
Additinal polish on show methods
GitHub Actions for R forces a |
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.
Looks good to me -- but then I also tainted the review by adding some code myself :)
Anybody else?
Problem to solve
Currently the
"show"
generic forArraySchema
-- and its recursive attributes includingDomain
,Dimension
,Attribute
,FilterList
, andFilter
-- rely onlibtiledb_array_schema_dump
et al. In turn, those TileDB core functions print to aFILE*
which isstdout
. This works fine at the R CLI; for notebooks,stdout
is not plumbed to the user so the user sees nothing when doingschema(arr)
.Options
FILE*
. This was attempted on Splitting up #2769 to diagnose CI issues [WIP] TileDB#2773. However, the scoping of that work has other dependencies as narrated by @eric-hughes-tiledb there. While that work is worth doing, it's on a greater scope than the current task.Rcpp::Rcout
(anostream
which is plumbed to the user in both CLI and notebook contexts) and graft it onto core'sFILE*
interface.TileDB-Py
does when presented with the same situation, namely, have__repr__
methods (Python's equivalent of"show"
generics in R) make the relevant API calls.This PR implements option three.
Validation
At the CLI:
This should print the same information as before -- since it's to the CLI's
stdout
.The more compelling test is to make a Jupyter notebook using a local build of this PR's code:
Notes