moodymudskipper / boom Goto Github PK

The proof of concept is easy enough :

But this will fail if there are calls to sys.call, match.arg, missing ...

Exceptions need to be added for all of those, and rlang functions like enquo, enquos, ensym.

I don't know if we can really have something robust enough.

Maybe there's a way without wrapping into a boom() call, make the boobytrapped function's environment a child of the original function's environment, where we store the modified functions. No idea if it will make the exceptions easier to deal with, but the code will look the same.

Works locally already

Maybe it's a bit too crazy, but I'm thinking we might plot those.

We could have a line chart :

• x axis would be number of calls
• y axis would be total ellapsed time
• start of each segment would be labelled with call, using heuristics if there is too much to plot, maybe plotting just 10 longer times for instance

And/or a bar chart

• calls on x
• time on y

now do we use base plot, some interactive charts...

The times also might be slightly overestimated as we're clocking modified functions, but to spot the calls that are problematic I believe the approach is valid.

There's CRAN package named Boom, with a capital B. Too late to change this new must-have package to boomer, which is still available?

We have 2 main use cases I think :

• I want to print the str or glimpse (or anything else) instead of printing the whole thing
• I want to shorten what is printed (long lists, long tables)

long tables can be handled by {tibbleprint}, but it's not a fully satisfying solution.

boom() could have a ... arg, which could be named or not.

Only one unnamed ... arg would be allowed, this arg would be a function or a list :

• we would print the output of the function used on the output of the step, e.g., boom(transform(iris, a = 1), head) would show the head of each intermediate step
• a list such as list(head, 4) would be the same as doing function(x) head(x, 4), not 100% sure we need it, esp if we support lambda notation

named arguments would work the same but will be applied on outputs of the class given by the name only. e.g. boom(transform(iris, a = 1), data.frame = head)

Another option would be to manipulate it through options, it would be a shame if we couldn't use the addin just because it prints too long lists for instance.

Maybe it should be a unique list argument that defaults to options, instead of ..., print = getOption("boom.print"), if it's formula or a function, use it on all outputs, if it's a named list, use it if we inherit from the class, one element of this list can be unnamed and be the default/fallback.