logrx v0.3.0

[bms63]

Thank you for your Pull Request!

We have developed a Pull Request template to aid you and our reviewers. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the logrx codebase remains robust and consistent.

The spirit of logrx

While many packages to facilitate the logging of code already exist in the R ecosystem, it is hard to find a solution that works well for clinical programming applications. Many logging implementations are more implicit and rely on user input to create the log for the execution of a script. While this is useful for logging specific events of an application, in clinical programming a log has a set purpose.

logrx is built around the concept of creating a log for the execution of an R script that provides an overview of what happened as well as the environment that it happened in. We set out to create a flexible logging utility that could provide the necessary information to anyone reviewing the code execution so they can recreate the execution environment and run the code for themselves. Please make sure your Pull Request meets this spirit of logrx.

Please check off each taskbox as an acknowledgment that you completed the task. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the dev branch until you have checked off each task.

• The spirit of logrx is met in your Pull Request
• Check that your Pull Request is targeting the dev branch, Pull Requests to master should use the Release Pull Request Template
• Code is formatted according to the tidyverse style guide
• Updated relevant unit tests or have written new unit tests. Remember to remove any configured log objects at the end of every test using log_remove().
• Creation/updates to relevant roxygen headers and examples.
• Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
• Run pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
• Update NEWS.md if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
• Address any updates needed for vignettes and/or templates
• Run R CMD check locally and address all errors and warnings - devtools::check()
• Link the issue so that it closes after successful merging.
• Address all merge conflicts and resolve appropriately
• Pat yourself on the back for a job well done! Much love to your accomplishment!

[parmsam-pfizer]

Just tried this and it looks like read_log_file() needs to be exported. It's currently still internal. Should be able to fix that by adding @export in the roxygen2 header for the function. Might need to redocument the function. Sorry about that. I'll do that here soon.

[parmsam-pfizer]

Doesn't look like I can update the dev branch directly. @bms63

[bms63]

@parmsam-pfizer I gave you admin privileges so you can make changes in dev branch.

[parmsam-pfizer]

Running into an error when I try to check examples and tests for the package check. However, it looks like the check passed in CI. Can someone else run the dev branch on their system and confirm?

[parmsam-pfizer]

Okay, ran into a weird read_log_file() error only on my big work monitor. Experimented and found something interesting about how sessioninfo::session_info() prints content into our logfiles. Turns out that the number of dashes in the session info section titles of our logfiles can vary based on the RStudio IDE console width. This is because session info extends the number of dashes based on the console width when it prints the info. You can see this by running either running sessioninfo::session_info() or axecute() (on an R script) with a small RStudio IDE console window vs a large console sized window. The variation only applies to the session_info() part of the log but can affect our log file. It was in my case b/c after a certain number of dashes it jumps to next line which was causing the log file parsing to fail. We might need to thing about how we are handling that part of the log now to regain consistent logfiles. This I think explains why it passes with no problems via CI but fails on my work computer connected to my large monitor when the console pane is wide.

Update: looks like the encoding for dashes on MacOS is also weird and can cause errors with reading logs. It leads to different characters for dashes via cli::symbol$line in the session_info() section of log files (source code here). We might need to add a CI for Mac is that is available. I'll need to look into this further for a solution.

Update 2: Added temporary solution to this ASCII vs UTF8 problem by just converting UTF8 double line or line characters to ASCII in the parser code. Doesn't solve the wrapping problem though. That's a case we might need to handle later.