Konrad Rudolph

@nvelden I’m not happy with the current state of affairs myself. However, I don’t think providing a bunch of custom functions that replace the base R debugging utilities is the...

Context: [Reddit discussion](https://www.reddit.com/r/rstats/comments/y31m7k/managing_large_codebases_in_r_webinar_oct_6_2022/isuqa50/?context=3); to wit: > >> You’ve accurately described ‘box’ semantics here. > > > > No, I accurately described how S3 methods are handled in R. > >...

I *don’t think* it’s related, since S3 classes in packages should just work with ‘box’. And the issue you’re linking to is related to S4 at any rate, not S3....

Do you have a more concrete use-case in mind where this would be worthwhile? At the moment I am having a hard time justifying the complexity this would add (both...

Hi, Rcpp requires a fairly complicated additional setup when invoking the C++ compiler. Unfortunately Rcpp does not (or at least used to not) export the required functions1, so we need...

For a *single* C++ source file without dependencies, `sourceCpp` is the way to go, yes. However, that no longer works for more complex projects with multiple source files and/or third-party...

If I understand correctly such a function is only really necessary because the environment variable `R_BOX_PATH` completely overrides `getOption('box.path')`, am I seeing that right? Because otherwise you could just write...

I’ve reopened the issue since I am still looking into ways of consolidating the environment variable and R option, rather than have one override the other. Regarding your solution: I...

> thus `box::file()` would just print your current working directory. That’s right (in this case). But isn’t the working directory precisely what you want? After all, a project-specific `.Rprofile` file...

This is a thoughtful feature request but it is at odds with the current, intentional design. There are two classes of problems with this design, which I’ll explain in the...