search

Rdatatable / data.table

R's data.table package extends data.frame:
http://r-datatable.com
Mozilla Public License 2.0
3.62k stars 986 forks source link

Restore linting of .Rraw files #6266

Open MichaelChirico opened 3 months ago

MichaelChirico commented 3 months ago

Lately we've been seeing lots of timeout failures on lint, and when they do succeed, still taking >1hr:

https://github.com/Rdatatable/data.table/actions/workflows/lint.yaml?query=is%3Afailure

This is due to .Rraw and some inefficiency in {lintr}. We can restore linting these files later, they're not top-level importance anyway.

joshhwuu commented 3 months ago

I was investigating what originally introduced the slowdown for the Lint workflow (https://github.com/Rdatatable/data.table/actions?page=7&query=workflow%3ALint), and found that the first occurrence happened here: https://github.com/Rdatatable/data.table/actions/runs/9842149988

This is related to PR #6227, with the addition of this test: 

# integer64 columns print even when bit64 isn't loaded
if (test_bit64) local({
  DT = data.table(a = 'abc', b = as.integer64(1))
  invisible(unloadNamespace("bit64"))
  on.exit(suppressPackageStartupMessages(library(bit64)))
  test(2265, DT, output="abc\\s*1$")
})

I was able to get my local fork of the project to pass the Lint GHA in under 10 minutes with rraw files by removing this test, see:

commit: https://github.com/joshhwuu/data.table/commit/25452b4ff702110c245c8ed8c97fee397f5301ed

lint workflow: https://github.com/joshhwuu/data.table/actions/runs/10326989414/job/28591425912

I wonder why it's this specific test, maybe the call to unloadNameSpace()?