[R] Invitation to Try My R Package: bughunter

[Spencer Graves]

Hi, Jiefei:


What have you done to seen input from the tidyverse team[1] and Jenny 
Bryan <jenny using rstudio.com> and / or Hadley Wickham in particular? Also, 
to what's your familiarity with Wickham and Bryan, R Packages?[2]


In particular, I notice that your package does NOT include


* a "tests" directory containing unit tests, which they recommend.


* GitHub actions, which, e.g., run R CMD check on your package on 5 
different platforms ("r release" on Mac, Windows, and Ubuntu plus "r 
devel" and "r oldrel1" on Ubuntu).


I found both of these things to be quite useful, and the R Studio team 
is a leading center of research on things like this.


hope this helps. spencer graves


[1] GitHub: tidyverse


https://github.com/tidyverse


[2] R Packages (2e), Hadley Wickham and Jennifer Bryan


https://r-pkgs.org/


On 10/27/25 04:30, Martin Maechler wrote:
>>>>>> Bert Gunter
>>>>>>      on Sun, 26 Oct 2025 17:34:49 -0700 writes:
> 
>      > I think you should post this on the R-packages mailing list, here
>      > <https://stat.ethz.ch/mailman/listinfo/r-packages> , if you haven't already
>      > done so.
> 
>      > -- Bert
> 
> Indeed.  But the package should have become a CRAN package, too.
> Why should I try packages that don't even fulfill simple QA
> criteria such as those from CRAN  (or - somewhat different ones
> - from Bioconductor).
> 
> Martin
> 
>      > On Sun, Oct 26, 2025 at 4:40 PM Jiefei Wang <szwjf08 using gmail.com> wrote:
> 
>      >> Hi everyone,
>      >>
>      >> I'd like to invite you to try my new R package,
>      >> [bughunter](https://github.com/Jiefei-Wang/bughunter), which I believe
>      >> could be extremely useful for this mailing list.
>      >>
>      >> For a long time, I've noticed that many people struggle to describe
>      >> their bugs clearly when asking for help. One major reason is that we
>      >> lack an easy way to share the full debugging context, typically, only
>      >> the surface-level code can be shared, not the call frames or stack
>      >> information. This makes reproducing someone else's problem quite
>      >> painful.
>      >>
>      >> The idea behind bughunter is to solve this pain point. It
>      >> automatically saves the call frames and code into a single object when
>      >> an error occurs. This object can then be saved and shared with others.
>      >> Moreover, the package provides a user-friendly Shiny interface for
>      >> debugging, designed to look and feel similar to RStudio - there's
>      >> virtually no learning curve.
>      >>
>      >> The package is still in its early development phase, so any feedback
>      >> or suggestions are very welcome. I'm also exploring options for a free
>      >> cloud platform to host and share these R objects so that users won’t
>      >> need to email them manually. If you have any ideas, I'd love to hear
>      >> them.
>      >>
>      >> Best regards,
>      >> Jiefei
>      >>
>      >> ______________________________________________
>      >> R-help using r-project.org mailing list -- To UNSUBSCRIBE and more, see
>      >> https://stat.ethz.ch/mailman/listinfo/r-help
>      >> PLEASE do read the posting guide
>      >> https://www.R-project.org/posting-guide.html
>      >> and provide commented, minimal, self-contained, reproducible code.
>      >>
> 
>      > [[alternative HTML version deleted]]
> 
>      > ______________________________________________
>      > R-help using r-project.org mailing list -- To UNSUBSCRIBE and more, see
>      > https://stat.ethz.ch/mailman/listinfo/r-help
>      > PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
>      > and provide commented, minimal, self-contained, reproducible code.
> 
> ______________________________________________
> R-help using r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.