Skip to content
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

Extract intermediates into a list instead of printing? #72

Open
nischalshrestha opened this issue Mar 16, 2022 · 2 comments
Open

Extract intermediates into a list instead of printing? #72

nischalshrestha opened this issue Mar 16, 2022 · 2 comments

Comments

@nischalshrestha
Copy link

nischalshrestha commented Mar 16, 2022

Hello! I would like to just say package is very cool and closely aligned with the vision I had for Unravel---to provide easy access/exploration of intermediates for tidyverse code. I would love to one day do it for any call (base or tidyverse) as you have done.

Let me know if I've missed it, but is there any way to gain access to list of intermediates instead of printing? It seems like boom() is meant to be used for printing only since storing it in a variable doesn't work. I had this same dilemma with Unravel and decided to have a public function that would give you the list via get_chain_outputs().

The reason for this might be because sometimes you want to do more with the intermediates and printing can sometimes be hard to follow or noisy with the icons when there are a ton of nested calls.

@moodymudskipper
Copy link
Owner

Hi Nishal and thanks.
One reason why boom doesn't return the printed data is that a common use case will be that the call fails, and we still want to print something.
The calls are printed as the code is executed, which is nice for long operations too, no need to wait to see output.
However your request makes sense and I believe I can implement something close enough by feeding a structure stored in a global variable as the code is executed. We could then access it with something like last_boom().

@nischalshrestha
Copy link
Author

Makes sense! But, I do think that if a call fails in the steps that's also informative, it's just tricky how you want that to be represented. I faced the same type of challenge before. Something I've seen recently is purrr:safely but that is an extra dependency which isn't needed. A similar concept like that would be cool though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants