GENEActiv_testfile - should this be able to be read?

I was using GENEActiv_testfile.bin to do some testing, but it seems like readGENEActiv doesn't read it correctly?  Should this file be able to be read?
file = system.file("testfiles", "GENEActiv_testfile.bin", package = "GGIR")

res = GGIRread::readGENEActiv(file)
#> WARNING: numBlocksTotal read in from header is negative, file corrupted?

print(res)
#> $header
#> $header$serial_number
#> [1] NA
#>
#> $header$firmware
#> [1] NA
#>
#> $header$tzone
#> [1] NA
#>
#> $header$ReadOK
#> [1] 1
#>
#> $header$SampleRate
#> [1] -1
#>
#> $header$ReadErrors
#> [1] 0
#>
#> $header$numBlocksTotal
#> [1] 1.844674e+19
#>
#> $header$StarTime
#> [1] NA
#>
#> $header$Handedness
#> [1] NA
#>
#> $header$RecordingID
#> [1] NA
#>
#> $header$DeviceLocation
#> [1] NA
#>
#> $header$DeviceModel
#> [1] NA
#>
#>
#> $data.out
#> [1] time        x           y           z           light       temperature
#> <0 rows> (or 0-length row.names)

Created on 2024-06-06 with reprex v2.1.0

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.4.0 (2024-04-24)
#>  os       macOS Sonoma 14.4.1
#>  system   x86_64, darwin20
#>  ui       X11
#>  language (EN)
#>  collate  en_US.UTF-8
#>  ctype    en_US.UTF-8
#>  tz       America/New_York
#>  date     2024-06-06
#>  pandoc   <IP_ADDRESS> @ /usr/local/bin/ (via rmarkdown)
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  cli           3.6.2   2023-12-11 [1] CRAN (R 4.4.0)
#>  digest        0.6.35  2024-03-11 [1] CRAN (R 4.4.0)
#>  evaluate      0.23    2023-11-01 [1] CRAN (R 4.4.0)
#>  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.4.0)
#>  fs            1.6.4   2024-04-25 [1] CRAN (R 4.4.0)
#>  GGIRread      1.0.1   2024-06-03 [1] Github (wadpac/GGIRread@fc0bf08)
#>  glue          1.7.0   2024-01-09 [1] CRAN (R 4.4.0)
#>  htmltools     <IP_ADDRESS> 2024-04-04 [1] CRAN (R 4.4.0)
#>  knitr         1.46    2024-04-06 [1] CRAN (R 4.4.0)
#>  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.4.0)
#>  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.4.0)
#>  purrr         1.0.2   2023-08-10 [1] CRAN (R 4.4.0)
#>  R.cache       0.16.0  2022-07-21 [1] CRAN (R 4.4.0)
#>  R.methodsS3   1.8.2   2022-06-13 [1] CRAN (R 4.4.0)
#>  R.oo          1.26.0  2024-01-24 [1] CRAN (R 4.4.0)
#>  R.utils       2.12.3  2023-11-18 [1] CRAN (R 4.4.0)
#>  Rcpp          1.0.12  2024-01-09 [1] CRAN (R 4.4.0)
#>  reprex        2.1.0   2024-01-11 [1] CRAN (R 4.4.0)
#>  rlang         1.1.3   2024-01-10 [1] CRAN (R 4.4.0)
#>  rmarkdown     2.27    2024-05-17 [1] CRAN (R 4.4.0)
#>  rstudioapi    0.16.0  2024-03-24 [1] CRAN (R 4.4.0)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.4.0)
#>  styler        1.10.3  2024-04-07 [1] CRAN (R 4.4.0)
#>  vctrs         0.6.5   2023-12-01 [1] CRAN (R 4.4.0)
#>  withr         3.0.0   2024-01-16 [1] CRAN (R 4.4.0)
#>  xfun          0.44    2024-05-15 [1] CRAN (R 4.4.0)
#>  yaml          2.3.8   2023-12-11 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library
#>
#> ──────────────────────────────────────────────────────────────────────────────

Sorry, the file is not an actual complete recording. It is a .bin file where I deleted all data after page 16. I did this to make the file small enough to fit inside the package and still useful for testing read functionality of the first couple of pages.
Ok, I think this needs to be better communicated:

This issue will hopefully be findable by anyone who encounters the same problem.
Additionally, I could rename the file into "GENEActiv_testfile_modified_only_for_specific_unittest.bin"?

Ahh that's interesting, it reads the data if an endpoint is specified (other than Inf), but doesn't give any data if it encounters an error?

Nvm - it turns out this may be due to
file = system.file("testfiles", "GENEActiv_testfile.bin", package = "GGIR")

should be
file = system.file("testfiles", "GENEActiv_testfile.bin", package = "GGIRread")

My overall issue is that the reader had changed significantly similar to https://github.com/wadpac/GGIRread/issues/67.  I'll track down the version differences similar to that issue.

Looks same as now as 0.3.1
# remotes::install_version("GGIRread", version = "0.3.1")
sessioninfo::package_info("GGIRread")
#>  package  * version date (UTC) lib source
#>  bitops     1.0-7   2021-04-24 [1] CRAN (R 4.4.0)
#>  GGIRread   0.3.1   2023-10-11 [1] CRAN (R 4.4.0)
#>  matlab     1.0.4   2022-06-01 [1] CRAN (R 4.4.0)
#>  Rcpp       1.0.12  2024-01-09 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

file = system.file("testfiles", "GENEActiv_testfile.bin", package = "GGIR")

res = GGIRread::readGENEActiv(file)
#> WARNING: numBlocksTotal read in from header is negative, file corrupted?

new_res = readr::read_rds("~/Dropbox/Packages/SummarizedActigraphy/GENEActiv_testfile_bin.rds")
all.equal(res, new_res)
#> [1] TRUE

Created on 2024-06-06 with reprex v2.1.0

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.4.0 (2024-04-24)
#>  os       macOS Sonoma 14.4.1
#>  system   x86_64, darwin20
#>  ui       X11
#>  language (EN)
#>  collate  en_US.UTF-8
#>  ctype    en_US.UTF-8
#>  tz       America/New_York
#>  date     2024-06-06
#>  pandoc   <IP_ADDRESS> @ /usr/local/bin/ (via rmarkdown)
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  cli           3.6.2   2023-12-11 [1] CRAN (R 4.4.0)
#>  digest        0.6.35  2024-03-11 [1] CRAN (R 4.4.0)
#>  evaluate      0.23    2023-11-01 [1] CRAN (R 4.4.0)
#>  fansi         1.0.6   2023-12-08 [1] CRAN (R 4.4.0)
#>  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.4.0)
#>  fs            1.6.4   2024-04-25 [1] CRAN (R 4.4.0)
#>  GGIRread      0.3.1   2023-10-11 [1] CRAN (R 4.4.0)
#>  glue          1.7.0   2024-01-09 [1] CRAN (R 4.4.0)
#>  hms           1.1.3   2023-03-21 [1] CRAN (R 4.4.0)
#>  htmltools     <IP_ADDRESS> 2024-04-04 [1] CRAN (R 4.4.0)
#>  knitr         1.46    2024-04-06 [1] CRAN (R 4.4.0)
#>  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.4.0)
#>  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.4.0)
#>  pillar        1.9.0   2023-03-22 [1] CRAN (R 4.4.0)
#>  pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.4.0)
#>  purrr         1.0.2   2023-08-10 [1] CRAN (R 4.4.0)
#>  R.cache       0.16.0  2022-07-21 [1] CRAN (R 4.4.0)
#>  R.methodsS3   1.8.2   2022-06-13 [1] CRAN (R 4.4.0)
#>  R.oo          1.26.0  2024-01-24 [1] CRAN (R 4.4.0)
#>  R.utils       2.12.3  2023-11-18 [1] CRAN (R 4.4.0)
#>  R6            2.5.1   2021-08-19 [1] CRAN (R 4.4.0)
#>  Rcpp          1.0.12  2024-01-09 [1] CRAN (R 4.4.0)
#>  readr         2.1.5   2024-01-10 [1] CRAN (R 4.4.0)
#>  reprex        2.1.0   2024-01-11 [1] CRAN (R 4.4.0)
#>  rlang         1.1.3   2024-01-10 [1] CRAN (R 4.4.0)
#>  rmarkdown     2.27    2024-05-17 [1] CRAN (R 4.4.0)
#>  rstudioapi    0.16.0  2024-03-24 [1] CRAN (R 4.4.0)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.4.0)
#>  styler        1.10.3  2024-04-07 [1] CRAN (R 4.4.0)
#>  tibble        3.2.1   2023-03-20 [1] CRAN (R 4.4.0)
#>  tzdb          0.4.0   2023-05-12 [1] CRAN (R 4.4.0)
#>  utf8          1.2.4   2023-10-22 [1] CRAN (R 4.4.0)
#>  vctrs         0.6.5   2023-12-01 [1] CRAN (R 4.4.0)
#>  withr         3.0.0   2024-01-16 [1] CRAN (R 4.4.0)
#>  xfun          0.44    2024-05-15 [1] CRAN (R 4.4.0)
#>  yaml          2.3.8   2023-12-11 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library
#>
#> ──────────────────────────────────────────────────────────────────────────────

OK - I figured out how to show the difference.
Current version of reading (3.1-1)
fname = "GENEActiv_testfile.bin"
# remotes::install_version("GGIR", "2.0-0")
file = system.file("testfiles", fname,
                     package = "GGIRread")
sessioninfo::package_info("GGIRread", dependencies = FALSE)
#>  package  * version date (UTC) lib source
#>  GGIRread   1.0.1   2024-06-03 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

sessioninfo::package_info("GGIR", dependencies = FALSE)
#>  package * version date (UTC) lib source
#>  GGIR      3.1-1   2024-06-04 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

inspectfileobject = GGIR::g.inspectfile(file)
out = GGIR::g.readaccfile(
  file, inspectfileobject = inspectfileobject,
  blocksize = 2, blocknumber = 1, ws = 3,
  desiredtz = "UTC",
  filequality = list(filecorrupt = FALSE, filetooshort = FALSE)
)
mean(out$P$data$x)
#> [1] 0.09041546

readr::write_rds(out, "~/Desktop/new_out.rds")

Created on 2024-06-06 with reprex v2.1.0

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.4.0 (2024-04-24)
#>  os       macOS Sonoma 14.4.1
#>  system   x86_64, darwin20
#>  ui       X11
#>  language (EN)
#>  collate  en_US.UTF-8
#>  ctype    en_US.UTF-8
#>  tz       America/New_York
#>  date     2024-06-06
#>  pandoc   <IP_ADDRESS> @ /usr/local/bin/ (via rmarkdown)
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  cli           3.6.2   2023-12-11 [1] CRAN (R 4.4.0)
#>  data.table    1.15.4  2024-03-30 [1] CRAN (R 4.4.0)
#>  digest        0.6.35  2024-03-11 [1] CRAN (R 4.4.0)
#>  evaluate      0.23    2023-11-01 [1] CRAN (R 4.4.0)
#>  fansi         1.0.6   2023-12-08 [1] CRAN (R 4.4.0)
#>  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.4.0)
#>  fs            1.6.4   2024-04-25 [1] CRAN (R 4.4.0)
#>  GGIR          3.1-1   2024-06-04 [1] CRAN (R 4.4.0)
#>  GGIRread      1.0.1   2024-06-03 [1] CRAN (R 4.4.0)
#>  glue          1.7.0   2024-01-09 [1] CRAN (R 4.4.0)
#>  hms           1.1.3   2023-03-21 [1] CRAN (R 4.4.0)
#>  htmltools     <IP_ADDRESS> 2024-04-04 [1] CRAN (R 4.4.0)
#>  knitr         1.46    2024-04-06 [1] CRAN (R 4.4.0)
#>  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.4.0)
#>  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.4.0)
#>  pillar        1.9.0   2023-03-22 [1] CRAN (R 4.4.0)
#>  pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.4.0)
#>  purrr         1.0.2   2023-08-10 [1] CRAN (R 4.4.0)
#>  R.cache       0.16.0  2022-07-21 [1] CRAN (R 4.4.0)
#>  R.methodsS3   1.8.2   2022-06-13 [1] CRAN (R 4.4.0)
#>  R.oo          1.26.0  2024-01-24 [1] CRAN (R 4.4.0)
#>  R.utils       2.12.3  2023-11-18 [1] CRAN (R 4.4.0)
#>  R6            2.5.1   2021-08-19 [1] CRAN (R 4.4.0)
#>  Rcpp          1.0.12  2024-01-09 [1] CRAN (R 4.4.0)
#>  readr         2.1.5   2024-01-10 [1] CRAN (R 4.4.0)
#>  reprex        2.1.0   2024-01-11 [1] CRAN (R 4.4.0)
#>  rlang         1.1.3   2024-01-10 [1] CRAN (R 4.4.0)
#>  rmarkdown     2.27    2024-05-17 [1] CRAN (R 4.4.0)
#>  rstudioapi    0.16.0  2024-03-24 [1] CRAN (R 4.4.0)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.4.0)
#>  styler        1.10.3  2024-04-07 [1] CRAN (R 4.4.0)
#>  tibble        3.2.1   2023-03-20 [1] CRAN (R 4.4.0)
#>  tzdb          0.4.0   2023-05-12 [1] CRAN (R 4.4.0)
#>  utf8          1.2.4   2023-10-22 [1] CRAN (R 4.4.0)
#>  vctrs         0.6.5   2023-12-01 [1] CRAN (R 4.4.0)
#>  withr         3.0.0   2024-01-16 [1] CRAN (R 4.4.0)
#>  xfun          0.44    2024-05-15 [1] CRAN (R 4.4.0)
#>  yaml          2.3.8   2023-12-11 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library
#>
#> ──────────────────────────────────────────────────────────────────────────────

From GGIR 2.0-0
fname = "GENEActiv_testfile.bin"
file = system.file("testfiles", fname,
                   package = "GGIRread")
sessioninfo::package_info("GGIRread", dependencies = FALSE)
#>  package  * version date (UTC) lib source
#>  GGIRread   1.0.1   2024-06-03 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

sessioninfo::package_info("GGIR", dependencies = FALSE)
#>  package * version date (UTC) lib source
#>  GGIR      2.0-0   2020-05-01 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

inspectfileobject = GGIR::g.inspectfile(file)
out = GGIR::g.readaccfile(
  file, inspectfileobject = inspectfileobject,
  blocksize = 2, blocknumber = 1, ws = 3,
  desiredtz = "UTC",
  filequality = list(filecorrupt = FALSE, filetooshort = FALSE)
)
#> Number of pages in binary file: 222048
#> Warning in readLines(fc2, n = headlines): line 26 appears to contain an
#> embedded nul
#> Warning in readLines(fc2, n = headlines): line 27 appears to contain an
#> embedded nul
#> Warning in readLines(fc2, n = headlines): line 28 appears to contain an
#> embedded nul
#> Warning in readLines(fc2, n = headlines): line 29 appears to contain an
#> embedded nul
#> Warning in readLines(fc2, n = headlines): line 39 appears to contain an
#> embedded nul
#> Warning in readLines(fc2, n = headlines): line 45 appears to contain an
#> embedded nul
#> Processing...
#> ================================================================================
#> Processing took: 0.003 secs .
#> Loaded 900 records (Approx  0 MB of RAM)
#> 13-05-30 10:12:54.500 (Thu)  to  13-05-30 10:13:04.990 (Thu)

mean(out$P$data.out[, "x"])
#> [1] -0.1942759

new_out = readr::read_rds("~/Desktop/new_out.rds")
all.equal(out, new_out)
#>  [1] "Names: 1 string mismatch"
#>  [2] "Length mismatch: comparison on first 4 components"
#>  [3] "Component \"P\": Names: 2 string mismatches"
#>  [4] "Component \"P\": Attributes: < names for target but not for current >"
#>  [5] "Component \"P\": Attributes: < Length mismatch: comparison on first 0 components >"
#>  [6] "Component \"P\": Length mismatch: comparison on first 2 components"
#>  [7] "Component \"P\": Component 1: Modes: numeric, list"
#>  [8] "Component \"P\": Component 1: Lengths: 6300, 12"
#>  [9] "Component \"P\": Component 1: names for current but not for target"
#> [10] "Component \"P\": Component 1: Attributes: < names for target but not for current >"
#> [11] "Component \"P\": Component 1: Attributes: < Length mismatch: comparison on first 0 components >"
#> [12] "Component \"P\": Component 1: target is matrix, current is list"
#> [13] "Component \"P\": Component 2: 'current' is not a POSIXt"
#> [14] "Component 3: Modes: numeric, logical"
#> [15] "Component 3: target is numeric, current is logical"
#> [16] "Component \"endpage\": Mean relative difference: 0.3333333"

Created on 2024-06-06 with reprex v2.1.0

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.4.0 (2024-04-24)
#>  os       macOS Sonoma 14.4.1
#>  system   x86_64, darwin20
#>  ui       X11
#>  language (EN)
#>  collate  en_US.UTF-8
#>  ctype    en_US.UTF-8
#>  tz       America/New_York
#>  date     2024-06-06
#>  pandoc   <IP_ADDRESS> @ /usr/local/bin/ (via rmarkdown)
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  bitops        1.0-7   2021-04-24 [1] CRAN (R 4.4.0)
#>  cli           3.6.2   2023-12-11 [1] CRAN (R 4.4.0)
#>  data.table    1.15.4  2024-03-30 [1] CRAN (R 4.4.0)
#>  digest        0.6.35  2024-03-11 [1] CRAN (R 4.4.0)
#>  evaluate      0.23    2023-11-01 [1] CRAN (R 4.4.0)
#>  fansi         1.0.6   2023-12-08 [1] CRAN (R 4.4.0)
#>  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.4.0)
#>  fs            1.6.4   2024-04-25 [1] CRAN (R 4.4.0)
#>  GENEAread     2.0.10  2024-03-06 [1] CRAN (R 4.4.0)
#>  GGIR          2.0-0   2020-05-01 [1] CRAN (R 4.4.0)
#>  glue          1.7.0   2024-01-09 [1] CRAN (R 4.4.0)
#>  hms           1.1.3   2023-03-21 [1] CRAN (R 4.4.0)
#>  htmltools     <IP_ADDRESS> 2024-04-04 [1] CRAN (R 4.4.0)
#>  knitr         1.46    2024-04-06 [1] CRAN (R 4.4.0)
#>  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.4.0)
#>  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.4.0)
#>  mmap          0.6-22  2023-12-08 [1] CRAN (R 4.4.0)
#>  pillar        1.9.0   2023-03-22 [1] CRAN (R 4.4.0)
#>  pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.4.0)
#>  purrr         1.0.2   2023-08-10 [1] CRAN (R 4.4.0)
#>  R.cache       0.16.0  2022-07-21 [1] CRAN (R 4.4.0)
#>  R.methodsS3   1.8.2   2022-06-13 [1] CRAN (R 4.4.0)
#>  R.oo          1.26.0  2024-01-24 [1] CRAN (R 4.4.0)
#>  R.utils       2.12.3  2023-11-18 [1] CRAN (R 4.4.0)
#>  R6            2.5.1   2021-08-19 [1] CRAN (R 4.4.0)
#>  Rcpp          1.0.12  2024-01-09 [1] CRAN (R 4.4.0)
#>  readr         2.1.5   2024-01-10 [1] CRAN (R 4.4.0)
#>  reprex        2.1.0   2024-01-11 [1] CRAN (R 4.4.0)
#>  rlang         1.1.3   2024-01-10 [1] CRAN (R 4.4.0)
#>  rmarkdown     2.27    2024-05-17 [1] CRAN (R 4.4.0)
#>  rstudioapi    0.16.0  2024-03-24 [1] CRAN (R 4.4.0)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.4.0)
#>  styler        1.10.3  2024-04-07 [1] CRAN (R 4.4.0)
#>  tibble        3.2.1   2023-03-20 [1] CRAN (R 4.4.0)
#>  tzdb          0.4.0   2023-05-12 [1] CRAN (R 4.4.0)
#>  utf8          1.2.4   2023-10-22 [1] CRAN (R 4.4.0)
#>  vctrs         0.6.5   2023-12-01 [1] CRAN (R 4.4.0)
#>  withr         3.0.0   2024-01-16 [1] CRAN (R 4.4.0)
#>  xfun          0.44    2024-05-15 [1] CRAN (R 4.4.0)
#>  yaml          2.3.8   2023-12-11 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library
#>
#> ──────────────────────────────────────────────────────────────────────────────

Version 2.10-1
fname = "GENEActiv_testfile.bin"
file = system.file("testfiles", fname,
                   package = "GGIRread")
sessioninfo::package_info("GGIRread", dependencies = FALSE)
#>  package  * version date (UTC) lib source
#>  GGIRread   1.0.1   2024-06-03 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

sessioninfo::package_info("GGIR", dependencies = FALSE)
#>  package * version date (UTC) lib source
#>  GGIR      2.10-1  2023-08-10 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

inspectfileobject = GGIR::g.inspectfile(file)
out = GGIR::g.readaccfile(
  file, inspectfileobject = inspectfileobject,
  blocksize = 2, blocknumber = 1, ws = 3,
  desiredtz = "UTC",
  filequality = list(filecorrupt = FALSE, filetooshort = FALSE)
)
mean(out$P$data.out[, "x"])
#> [1] -0.1942759

new_out = readr::read_rds("~/Desktop/new_out.rds")
mean(new_out$P$data[, "x"])
#> [1] 0.09041546

all.equal(out, new_out)
#>  [1] "Names: 1 string mismatch"
#>  [2] "Component \"P\": Names: 1 string mismatch"
#>  [3] "Component \"P\": Component 2: Attributes: < Component \"row.names\": Numeric: lengths (900, 600) differ >"
#>  [4] "Component \"P\": Component 2: Component \"time\": Numeric: lengths (900, 600) differ"
#>  [5] "Component \"P\": Component 2: Component \"x\": Numeric: lengths (900, 600) differ"
#>  [6] "Component \"P\": Component 2: Component \"y\": Numeric: lengths (900, 600) differ"
#>  [7] "Component \"P\": Component 2: Component \"z\": Numeric: lengths (900, 600) differ"
#>  [8] "Component \"P\": Component 2: Component \"light\": Numeric: lengths (900, 600) differ"
#>  [9] "Component \"P\": Component 2: Component \"temperature\": Numeric: lengths (900, 600) differ"
#> [10] "Component 3: Modes: numeric, logical"
#> [11] "Component 3: target is numeric, current is logical"
#> [12] "Component \"endpage\": Mean relative difference: 0.3333333"

Created on 2024-06-06 with reprex v2.1.0

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.4.0 (2024-04-24)
#>  os       macOS Sonoma 14.4.1
#>  system   x86_64, darwin20
#>  ui       X11
#>  language (EN)
#>  collate  en_US.UTF-8
#>  ctype    en_US.UTF-8
#>  tz       America/New_York
#>  date     2024-06-06
#>  pandoc   <IP_ADDRESS> @ /usr/local/bin/ (via rmarkdown)
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  cli           3.6.2   2023-12-11 [1] CRAN (R 4.4.0)
#>  data.table    1.15.4  2024-03-30 [1] CRAN (R 4.4.0)
#>  digest        0.6.35  2024-03-11 [1] CRAN (R 4.4.0)
#>  evaluate      0.23    2023-11-01 [1] CRAN (R 4.4.0)
#>  fansi         1.0.6   2023-12-08 [1] CRAN (R 4.4.0)
#>  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.4.0)
#>  fs            1.6.4   2024-04-25 [1] CRAN (R 4.4.0)
#>  GGIR          2.10-1  2023-08-10 [1] CRAN (R 4.4.0)
#>  GGIRread      1.0.1   2024-06-03 [1] CRAN (R 4.4.0)
#>  glue          1.7.0   2024-01-09 [1] CRAN (R 4.4.0)
#>  hms           1.1.3   2023-03-21 [1] CRAN (R 4.4.0)
#>  htmltools     <IP_ADDRESS> 2024-04-04 [1] CRAN (R 4.4.0)
#>  knitr         1.46    2024-04-06 [1] CRAN (R 4.4.0)
#>  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.4.0)
#>  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.4.0)
#>  pillar        1.9.0   2023-03-22 [1] CRAN (R 4.4.0)
#>  pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.4.0)
#>  purrr         1.0.2   2023-08-10 [1] CRAN (R 4.4.0)
#>  R.cache       0.16.0  2022-07-21 [1] CRAN (R 4.4.0)
#>  R.methodsS3   1.8.2   2022-06-13 [1] CRAN (R 4.4.0)
#>  R.oo          1.26.0  2024-01-24 [1] CRAN (R 4.4.0)
#>  R.utils       2.12.3  2023-11-18 [1] CRAN (R 4.4.0)
#>  R6            2.5.1   2021-08-19 [1] CRAN (R 4.4.0)
#>  Rcpp          1.0.12  2024-01-09 [1] CRAN (R 4.4.0)
#>  readr         2.1.5   2024-01-10 [1] CRAN (R 4.4.0)
#>  reprex        2.1.0   2024-01-11 [1] CRAN (R 4.4.0)
#>  rlang         1.1.3   2024-01-10 [1] CRAN (R 4.4.0)
#>  rmarkdown     2.27    2024-05-17 [1] CRAN (R 4.4.0)
#>  rstudioapi    0.16.0  2024-03-24 [1] CRAN (R 4.4.0)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.4.0)
#>  styler        1.10.3  2024-04-07 [1] CRAN (R 4.4.0)
#>  tibble        3.2.1   2023-03-20 [1] CRAN (R 4.4.0)
#>  tzdb          0.4.0   2023-05-12 [1] CRAN (R 4.4.0)
#>  utf8          1.2.4   2023-10-22 [1] CRAN (R 4.4.0)
#>  vctrs         0.6.5   2023-12-01 [1] CRAN (R 4.4.0)
#>  withr         3.0.0   2024-01-16 [1] CRAN (R 4.4.0)
#>  xfun          0.44    2024-05-15 [1] CRAN (R 4.4.0)
#>  yaml          2.3.8   2023-12-11 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library
#>
#> ──────────────────────────────────────────────────────────────────────────────

Version 3.0-0
fname = "GENEActiv_testfile.bin"
file = system.file("testfiles", fname,
                   package = "GGIRread")
sessioninfo::package_info("GGIRread", dependencies = FALSE)
#>  package  * version date (UTC) lib source
#>  GGIRread   1.0.1   2024-06-03 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

sessioninfo::package_info("GGIR", dependencies = FALSE)
#>  package * version date (UTC) lib source
#>  GGIR      3.0-0   2023-10-16 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

inspectfileobject = GGIR::g.inspectfile(file)
out = GGIR::g.readaccfile(
  file, inspectfileobject = inspectfileobject,
  blocksize = 2, blocknumber = 1, ws = 3,
  desiredtz = "UTC",
  filequality = list(filecorrupt = FALSE, filetooshort = FALSE)
)
mean(out$P$data.out[, "x"])
#> [1] -0.1942759

new_out = readr::read_rds("~/Desktop/new_out.rds")
mean(new_out$P$data[, "x"])
#> [1] 0.09041546

all.equal(out, new_out)
#>  [1] "Names: 1 string mismatch"
#>  [2] "Component \"P\": Names: 1 string mismatch"
#>  [3] "Component \"P\": Component 2: Attributes: < Component \"row.names\": Numeric: lengths (900, 600) differ >"
#>  [4] "Component \"P\": Component 2: Component \"time\": Numeric: lengths (900, 600) differ"
#>  [5] "Component \"P\": Component 2: Component \"x\": Numeric: lengths (900, 600) differ"
#>  [6] "Component \"P\": Component 2: Component \"y\": Numeric: lengths (900, 600) differ"
#>  [7] "Component \"P\": Component 2: Component \"z\": Numeric: lengths (900, 600) differ"
#>  [8] "Component \"P\": Component 2: Component \"light\": Numeric: lengths (900, 600) differ"
#>  [9] "Component \"P\": Component 2: Component \"temperature\": Numeric: lengths (900, 600) differ"
#> [10] "Component 3: Modes: numeric, logical"
#> [11] "Component 3: target is numeric, current is logical"
#> [12] "Component \"endpage\": Mean relative difference: 0.3333333"

Created on 2024-06-06 with reprex v2.1.0

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.4.0 (2024-04-24)
#>  os       macOS Sonoma 14.4.1
#>  system   x86_64, darwin20
#>  ui       X11
#>  language (EN)
#>  collate  en_US.UTF-8
#>  ctype    en_US.UTF-8
#>  tz       America/New_York
#>  date     2024-06-06
#>  pandoc   <IP_ADDRESS> @ /usr/local/bin/ (via rmarkdown)
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  cli           3.6.2   2023-12-11 [1] CRAN (R 4.4.0)
#>  data.table    1.15.4  2024-03-30 [1] CRAN (R 4.4.0)
#>  digest        0.6.35  2024-03-11 [1] CRAN (R 4.4.0)
#>  evaluate      0.23    2023-11-01 [1] CRAN (R 4.4.0)
#>  fansi         1.0.6   2023-12-08 [1] CRAN (R 4.4.0)
#>  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.4.0)
#>  fs            1.6.4   2024-04-25 [1] CRAN (R 4.4.0)
#>  GGIR          3.0-0   2023-10-16 [1] CRAN (R 4.4.0)
#>  GGIRread      1.0.1   2024-06-03 [1] CRAN (R 4.4.0)
#>  glue          1.7.0   2024-01-09 [1] CRAN (R 4.4.0)
#>  hms           1.1.3   2023-03-21 [1] CRAN (R 4.4.0)
#>  htmltools     <IP_ADDRESS> 2024-04-04 [1] CRAN (R 4.4.0)
#>  knitr         1.46    2024-04-06 [1] CRAN (R 4.4.0)
#>  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.4.0)
#>  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.4.0)
#>  pillar        1.9.0   2023-03-22 [1] CRAN (R 4.4.0)
#>  pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.4.0)
#>  purrr         1.0.2   2023-08-10 [1] CRAN (R 4.4.0)
#>  R.cache       0.16.0  2022-07-21 [1] CRAN (R 4.4.0)
#>  R.methodsS3   1.8.2   2022-06-13 [1] CRAN (R 4.4.0)
#>  R.oo          1.26.0  2024-01-24 [1] CRAN (R 4.4.0)
#>  R.utils       2.12.3  2023-11-18 [1] CRAN (R 4.4.0)
#>  R6            2.5.1   2021-08-19 [1] CRAN (R 4.4.0)
#>  Rcpp          1.0.12  2024-01-09 [1] CRAN (R 4.4.0)
#>  readr         2.1.5   2024-01-10 [1] CRAN (R 4.4.0)
#>  reprex        2.1.0   2024-01-11 [1] CRAN (R 4.4.0)
#>  rlang         1.1.3   2024-01-10 [1] CRAN (R 4.4.0)
#>  rmarkdown     2.27    2024-05-17 [1] CRAN (R 4.4.0)
#>  rstudioapi    0.16.0  2024-03-24 [1] CRAN (R 4.4.0)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.4.0)
#>  styler        1.10.3  2024-04-07 [1] CRAN (R 4.4.0)
#>  tibble        3.2.1   2023-03-20 [1] CRAN (R 4.4.0)
#>  tzdb          0.4.0   2023-05-12 [1] CRAN (R 4.4.0)
#>  utf8          1.2.4   2023-10-22 [1] CRAN (R 4.4.0)
#>  vctrs         0.6.5   2023-12-01 [1] CRAN (R 4.4.0)
#>  withr         3.0.0   2024-01-16 [1] CRAN (R 4.4.0)
#>  xfun          0.44    2024-05-15 [1] CRAN (R 4.4.0)
#>  yaml          2.3.8   2023-12-11 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library
#>
#> ──────────────────────────────────────────────────────────────────────────────

3.0-3
fname = "GENEActiv_testfile.bin"
file = system.file("testfiles", fname,
                   package = "GGIRread")
sessioninfo::package_info("GGIRread", dependencies = FALSE)
#>  package  * version date (UTC) lib source
#>  GGIRread   1.0.1   2024-06-03 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

sessioninfo::package_info("GGIR", dependencies = FALSE)
#>  package * version date (UTC) lib source
#>  GGIR      3.0-3   2024-01-11 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

inspectfileobject = GGIR::g.inspectfile(file)
out = GGIR::g.readaccfile(
  file, inspectfileobject = inspectfileobject,
  blocksize = 2, blocknumber = 1, ws = 3,
  desiredtz = "UTC",
  filequality = list(filecorrupt = FALSE, filetooshort = FALSE)
)
mean(out$P$data.out[, "x"])
#> [1] -0.1942759

new_out = readr::read_rds("~/Desktop/new_out.rds")
mean(new_out$P$data[, "x"])
#> [1] 0.09041546

all.equal(out, new_out)
#>  [1] "Names: 1 string mismatch"
#>  [2] "Component \"P\": Names: 1 string mismatch"
#>  [3] "Component \"P\": Component 2: Attributes: < Component \"row.names\": Numeric: lengths (900, 600) differ >"
#>  [4] "Component \"P\": Component 2: Component \"time\": Numeric: lengths (900, 600) differ"
#>  [5] "Component \"P\": Component 2: Component \"x\": Numeric: lengths (900, 600) differ"
#>  [6] "Component \"P\": Component 2: Component \"y\": Numeric: lengths (900, 600) differ"
#>  [7] "Component \"P\": Component 2: Component \"z\": Numeric: lengths (900, 600) differ"
#>  [8] "Component \"P\": Component 2: Component \"light\": Numeric: lengths (900, 600) differ"
#>  [9] "Component \"P\": Component 2: Component \"temperature\": Numeric: lengths (900, 600) differ"
#> [10] "Component 3: Modes: numeric, logical"
#> [11] "Component 3: target is numeric, current is logical"
#> [12] "Component \"endpage\": Mean relative difference: 0.3333333"

Created on 2024-06-06 with reprex v2.1.0

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.4.0 (2024-04-24)
#>  os       macOS Sonoma 14.4.1
#>  system   x86_64, darwin20
#>  ui       X11
#>  language (EN)
#>  collate  en_US.UTF-8
#>  ctype    en_US.UTF-8
#>  tz       America/New_York
#>  date     2024-06-06
#>  pandoc   <IP_ADDRESS> @ /usr/local/bin/ (via rmarkdown)
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  cli           3.6.2   2023-12-11 [1] CRAN (R 4.4.0)
#>  data.table    1.15.4  2024-03-30 [1] CRAN (R 4.4.0)
#>  digest        0.6.35  2024-03-11 [1] CRAN (R 4.4.0)
#>  evaluate      0.23    2023-11-01 [1] CRAN (R 4.4.0)
#>  fansi         1.0.6   2023-12-08 [1] CRAN (R 4.4.0)
#>  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.4.0)
#>  fs            1.6.4   2024-04-25 [1] CRAN (R 4.4.0)
#>  GGIR          3.0-3   2024-01-11 [1] CRAN (R 4.4.0)
#>  GGIRread      1.0.1   2024-06-03 [1] CRAN (R 4.4.0)
#>  glue          1.7.0   2024-01-09 [1] CRAN (R 4.4.0)
#>  hms           1.1.3   2023-03-21 [1] CRAN (R 4.4.0)
#>  htmltools     <IP_ADDRESS> 2024-04-04 [1] CRAN (R 4.4.0)
#>  knitr         1.46    2024-04-06 [1] CRAN (R 4.4.0)
#>  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.4.0)
#>  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.4.0)
#>  pillar        1.9.0   2023-03-22 [1] CRAN (R 4.4.0)
#>  pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.4.0)
#>  purrr         1.0.2   2023-08-10 [1] CRAN (R 4.4.0)
#>  R.cache       0.16.0  2022-07-21 [1] CRAN (R 4.4.0)
#>  R.methodsS3   1.8.2   2022-06-13 [1] CRAN (R 4.4.0)
#>  R.oo          1.26.0  2024-01-24 [1] CRAN (R 4.4.0)
#>  R.utils       2.12.3  2023-11-18 [1] CRAN (R 4.4.0)
#>  R6            2.5.1   2021-08-19 [1] CRAN (R 4.4.0)
#>  Rcpp          1.0.12  2024-01-09 [1] CRAN (R 4.4.0)
#>  readr         2.1.5   2024-01-10 [1] CRAN (R 4.4.0)
#>  reprex        2.1.0   2024-01-11 [1] CRAN (R 4.4.0)
#>  rlang         1.1.3   2024-01-10 [1] CRAN (R 4.4.0)
#>  rmarkdown     2.27    2024-05-17 [1] CRAN (R 4.4.0)
#>  rstudioapi    0.16.0  2024-03-24 [1] CRAN (R 4.4.0)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.4.0)
#>  styler        1.10.3  2024-04-07 [1] CRAN (R 4.4.0)
#>  tibble        3.2.1   2023-03-20 [1] CRAN (R 4.4.0)
#>  tzdb          0.4.0   2023-05-12 [1] CRAN (R 4.4.0)
#>  utf8          1.2.4   2023-10-22 [1] CRAN (R 4.4.0)
#>  vctrs         0.6.5   2023-12-01 [1] CRAN (R 4.4.0)
#>  withr         3.0.0   2024-01-16 [1] CRAN (R 4.4.0)
#>  xfun          0.44    2024-05-15 [1] CRAN (R 4.4.0)
#>  yaml          2.3.8   2023-12-11 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library
#>
#> ──────────────────────────────────────────────────────────────────────────────

3.0-5
fname = "GENEActiv_testfile.bin"
file = system.file("testfiles", fname,
                   package = "GGIRread")
sessioninfo::package_info("GGIRread", dependencies = FALSE)
#>  package  * version date (UTC) lib source
#>  GGIRread   1.0.1   2024-06-03 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

sessioninfo::package_info("GGIR", dependencies = FALSE)
#>  package * version date (UTC) lib source
#>  GGIR      3.0-5   2024-02-02 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library

inspectfileobject = GGIR::g.inspectfile(file)
out = GGIR::g.readaccfile(
  file, inspectfileobject = inspectfileobject,
  blocksize = 2, blocknumber = 1, ws = 3,
  desiredtz = "UTC",
  filequality = list(filecorrupt = FALSE, filetooshort = FALSE)
)
mean(out$P$data[, "x"])
#> [1] -0.1942759

new_out = readr::read_rds("~/Desktop/new_out.rds")
mean(new_out$P$data[, "x"])
#> [1] 0.09041546

all.equal(out, new_out)
#>  [1] "Names: 1 string mismatch"
#>  [2] "Component \"P\": Names: 1 string mismatch"
#>  [3] "Component \"P\": Component 2: Attributes: < Component \"row.names\": Numeric: lengths (900, 600) differ >"
#>  [4] "Component \"P\": Component 2: Component \"time\": Numeric: lengths (900, 600) differ"
#>  [5] "Component \"P\": Component 2: Component \"x\": Numeric: lengths (900, 600) differ"
#>  [6] "Component \"P\": Component 2: Component \"y\": Numeric: lengths (900, 600) differ"
#>  [7] "Component \"P\": Component 2: Component \"z\": Numeric: lengths (900, 600) differ"
#>  [8] "Component \"P\": Component 2: Component \"light\": Numeric: lengths (900, 600) differ"
#>  [9] "Component \"P\": Component 2: Component \"temperature\": Numeric: lengths (900, 600) differ"
#> [10] "Component 3: Modes: numeric, logical"
#> [11] "Component 3: target is numeric, current is logical"
#> [12] "Component \"endpage\": Mean relative difference: 0.3333333"

Created on 2024-06-06 with reprex v2.1.0

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.4.0 (2024-04-24)
#>  os       macOS Sonoma 14.4.1
#>  system   x86_64, darwin20
#>  ui       X11
#>  language (EN)
#>  collate  en_US.UTF-8
#>  ctype    en_US.UTF-8
#>  tz       America/New_York
#>  date     2024-06-06
#>  pandoc   <IP_ADDRESS> @ /usr/local/bin/ (via rmarkdown)
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  cli           3.6.2   2023-12-11 [1] CRAN (R 4.4.0)
#>  data.table    1.15.4  2024-03-30 [1] CRAN (R 4.4.0)
#>  digest        0.6.35  2024-03-11 [1] CRAN (R 4.4.0)
#>  evaluate      0.23    2023-11-01 [1] CRAN (R 4.4.0)
#>  fansi         1.0.6   2023-12-08 [1] CRAN (R 4.4.0)
#>  fastmap       1.2.0   2024-05-15 [1] CRAN (R 4.4.0)
#>  fs            1.6.4   2024-04-25 [1] CRAN (R 4.4.0)
#>  GGIR          3.0-5   2024-02-02 [1] CRAN (R 4.4.0)
#>  GGIRread      1.0.1   2024-06-03 [1] CRAN (R 4.4.0)
#>  glue          1.7.0   2024-01-09 [1] CRAN (R 4.4.0)
#>  hms           1.1.3   2023-03-21 [1] CRAN (R 4.4.0)
#>  htmltools     <IP_ADDRESS> 2024-04-04 [1] CRAN (R 4.4.0)
#>  knitr         1.46    2024-04-06 [1] CRAN (R 4.4.0)
#>  lifecycle     1.0.4   2023-11-07 [1] CRAN (R 4.4.0)
#>  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.4.0)
#>  pillar        1.9.0   2023-03-22 [1] CRAN (R 4.4.0)
#>  pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.4.0)
#>  purrr         1.0.2   2023-08-10 [1] CRAN (R 4.4.0)
#>  R.cache       0.16.0  2022-07-21 [1] CRAN (R 4.4.0)
#>  R.methodsS3   1.8.2   2022-06-13 [1] CRAN (R 4.4.0)
#>  R.oo          1.26.0  2024-01-24 [1] CRAN (R 4.4.0)
#>  R.utils       2.12.3  2023-11-18 [1] CRAN (R 4.4.0)
#>  R6            2.5.1   2021-08-19 [1] CRAN (R 4.4.0)
#>  Rcpp          1.0.12  2024-01-09 [1] CRAN (R 4.4.0)
#>  readr         2.1.5   2024-01-10 [1] CRAN (R 4.4.0)
#>  reprex        2.1.0   2024-01-11 [1] CRAN (R 4.4.0)
#>  rlang         1.1.3   2024-01-10 [1] CRAN (R 4.4.0)
#>  rmarkdown     2.27    2024-05-17 [1] CRAN (R 4.4.0)
#>  rstudioapi    0.16.0  2024-03-24 [1] CRAN (R 4.4.0)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.4.0)
#>  styler        1.10.3  2024-04-07 [1] CRAN (R 4.4.0)
#>  tibble        3.2.1   2023-03-20 [1] CRAN (R 4.4.0)
#>  tzdb          0.4.0   2023-05-12 [1] CRAN (R 4.4.0)
#>  utf8          1.2.4   2023-10-22 [1] CRAN (R 4.4.0)
#>  vctrs         0.6.5   2023-12-01 [1] CRAN (R 4.4.0)
#>  withr         3.0.0   2024-01-16 [1] CRAN (R 4.4.0)
#>  xfun          0.44    2024-05-15 [1] CRAN (R 4.4.0)
#>  yaml          2.3.8   2023-12-11 [1] CRAN (R 4.4.0)
#>
#>  [1] /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library
#>
#> ──────────────────────────────────────────────────────────────────────────────

This is likely a GGIR issue not a GGIRread issue, but the output is still quite troubling.

Looks like this change happened between 3.0-6 and 3.0-9

GGIR function g.part1 and all its underlying functions, including g.readaccfile, went through a major review and tidy-up by Lena in 2023/2024. A few of these updates were implemented in 3.0-3 but most were merged in GGIR 3.0-6. In 3.0-3 there was even a bug fix that would only be visible in R >=4.3.0 which explains why we never spotted it before.
For details see: https://cran.r-project.org/web/packages/GGIR/news/news.html
I know the version number increments are not intuitive, but I hope the changelog will clarify where consistency breaking changes can be expected. I usually clarify which part of GGIR the change happend which should help to assess whether it was reading related (part 1) or otherwise.
For your information: I am currently doing a major revision of the GGIR vignettes where I migrate and restructure a lot of the text to the gh-pages. Next big project would be to review and tidy-up other parts of GGIR code, and where necessary migrate parts to their own package. The ultimate goal would be to make it all more accessible for users and code contributors. However, without structural funding it is a slow process depending on voluntary efforts.

file = system.file("testfiles", "GENEActiv_testfile.bin", package = "GGIRread")

Yes, I moved the test file from GGIR to GGIRread to concentrate all read-related functions and unit testing there. I may have replaced the file, not sure now.

Got it - I think most users don't regularly peruse the change log, which can make it hard to see these, but there's not much better solutions from what I can tell.  Looking over the change log, it's not clear which record would have indicated this type of change.  Can you point to which part of the change log indicates this?

From 3.0-6 in https://cran.r-project.org/web/packages/GGIR/news/news.html:

Part 1:

Improved readability and maintainability of the code #1027
Improved processing speed for Axivity .cwa, GENEActiv .bin, and Movisens files
Made sure that g.readaccfile() reads timestamps in the correct timezone, configtz, for all monitor types
Note: there will be small differences in both metalong and metashort metrics calculated by this GGIR version, compared to prior versions. This is due to small improvements in the management of timestamps, calibration coefficients, and input data block boundaries.
Fix handling of ad hoc csv file header in g.inspectfile() #1057
Improved g.calibrate to better handle scenario when no non-movement periods are found in the entire recording #1032
Improved documentation for the need to specify rmc.firstrow.acc when working with ad-hoc csv file format and read.myacc.csv now produces an error when used directly while user forgets to specify rmc.firstrow.acc #1034.

Most of which was part of https://github.com/wadpac/GGIR/pull/1027
but basically all the PRs by l-k- in the past year are related to improving the code.
I hope this helps.

I see the note about increased processing speed, but I don’t see anything
in there that would indicate breaking changes.  The meta data indicates
it’d be changed, but this isn’t a metadata change.  The changes “

Made sure that g.readaccfile() reads timestamps in the correct
timezone, configtz, for all monitor types

is about timestamps but not rows of the data.  I’m not trying to be labor
the point too much but I just want to get an understanding of when I can
upgrade GGIR and be confident the results can be reproduced in the future
versions of code and how stable it is for use in research.
Best,
John
On Fri, Jun 7, 2024 at 10:47 AM Vincent van Hees @.***>
wrote:

From 3.0-6 in https://cran.r-project.org/web/packages/GGIR/news/news.html:
Part 1:

Improved readability and maintainability of the code #1027
Improved processing speed for Axivity .cwa, GENEActiv .bin, and
Movisens files
Made sure that g.readaccfile() reads timestamps in the correct
timezone, configtz, for all monitor types
Note: there will be small differences in both metalong and metashort
metrics calculated by this GGIR version, compared to prior versions. This
is due to small improvements in the management of timestamps, calibration
coefficients, and input data block boundaries.
Fix handling of ad hoc csv file header in g.inspectfile() #1057
Improved g.calibrate to better handle scenario when no non-movement
periods are found in the entire recording #1032
Improved documentation for the need to specify rmc.firstrow.acc when
working with ad-hoc csv file format and read.myacc.csv now produces an
error when used directly while user forgets to specify rmc.firstrow.acc
#1034.

Most of which was part of wadpac/GGIR#1027
https://github.com/wadpac/GGIR/pull/1027
but basically all the PRs by l-k- in the past year are related to
improving the code.
I hope this helps.
—
Reply to this email directly, view it on GitHub
https://github.com/wadpac/GGIRread/issues/66#issuecomment-2154999311,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIGPLVGYPUOPTAEGIDKSLDZGHBZXAVCNFSM6AAAAABI4WZTQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJUHE4TSMZRGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

I remember that for GENEActiv recordings we discussed that they can start half way a second. Previously the code missed / rounded the time to the nearest second. So, probably if you time shift the code by half a second you will see that the values match again. I am afraid I do not have time to dive deep into this. Happy to do so if someone would pay me for it.

when I can upgrade GGIR and be confident the results can be reproduced in the future
versions of code and how stable it is for use in research.

I am afraid this is an unrealistic expectation. See also my recent post in the GGIR google group: https://groups.google.com/g/RpackageGGIR/c/nvI-gZQ2LzI/m/8sL750TVBwAJ
If this is a problem then the researchers you work with, and others, have three options:

Never change version and continue to use the incorrect old version.
Help me improve and guard the quality of the code and code documentation by dedicating people time or funding. I sometimes get the impression that people think that I am running a free research service. All I do is being available to help improve open-source research software, it is my time I sell not the software. Reproducibility of research is not my responsibility, that is the responsibility of the user. If the user wants me to take that responsibility then I would need a lot more funding and people to do the work and we would need to start working with paid licenses for carefully audited copies of the GGIR code.
Find or develop another piece of software that better meets expectations.

@muschellij2 prior to https://github.com/wadpac/GGIR/pull/1027, for GENEActiv .bin files, g.readaccfile((...,blocksize, ...) was actually reading blocksize+1 number of blocks, not blocksize number of blocks as one would expect. So  in GGIR versions before 3.0-6, your call
out = GGIR::g.readaccfile(
  file, inspectfileobject = inspectfileobject,
  blocksize = 2, blocknumber = 1, ws = 3,
  desiredtz = "UTC",
  filequality = list(filecorrupt = FALSE, filetooshort = FALSE)
)

is actually getting you 3 blocks worth of data, not 2. With GGIR 3.0-6 and later, you get 2 blocks.
This happened because in the call to GGIRread::readGENEActiv(..., start, end, ...), page selection is defined from start to end including end -- but we were treating this call as if the end was excluded.
Here's the relevant commit, and this change was identified in the PR description ("for monitor types for which the file is read till endpage including the endpage, we used to read (blocksize + 1) samples at a time, instead of blocksize samples as was requested.")
This is one of the changes that were collectively referred to as "improvements in the management of <...> input data block boundaries" in 3.0-6 release notes. I didn't think many GGIR users have a need to call g.readaccfile() directly, so the concern was that describing the exact changes to this module would have buried users in too much detail and discouraged them from reading release notes. If one runs GGIR on a whole file, the effect of this change on GGIR output is minor.


Fix for font colours on RAW16 Images

Allows greyscale colours to be used on RAW16 images. The normal colour settings are used but only the B & G values. The R value MUST be 0.
So white would be 255 255 0 and a lighter grey 255 128 0
Also needs a change making to the UI to amend the help text for the camera config?

Thanks Alex. I have updated the help text. It will show up on a GUI re-install.


Order of packets in queue in case of tx failure

Open question :
having the frame queued in front in case of paquet router transmission failure could not be the most efficient solution. It will delay more the new frame arriving.
If i understand well all the pending paquets are re-processed during 60 seconds before being killed. When service will be restored the packets will be dequeued starting by the older one. Most of them will be unexpected, in particular the one with ack / downlink req.
the life time of a packet with ack or downlink could be reduced to a 200ms time windows.
Uplink could be longer but i assume better loosing a packet than having a repeat that will be paid and rejected by LNS.
i think the best would be to have 2 queues, one for new packets and one for retry with a priority on the new packets.

Interesting.. and when would you retry under new packet load?  The retry policy will have some complexity since retry packets will get starved out almost all the time?

In addition to starving the old queue if you have two queues you would also end up getting packets out of order.

@disk91 in case you didn't see this

My main point is to not have fresh new packets to not wait. In a device perspective packets may not be in wrong order for short delay. LNS will ignore packet in wrong order for a single device when long delay as counter will be in the past. Standard device rate is more about an hour than 30s. Order will be wrong from different devices but this don’t care.
The proposal of priorty is to always get packet in the fresh queue first, then takes the retry queue. Can be something like:
While (true) {
while ( priority queue not empty) {
PeekOne()
If ( ! pushIt() ) enqueueInRetryQueue()
}
If ( RetryQueue not empty ) {
PeekOne()
If ( ! pushIt() ) enqueueInRetryQueue()
}
}
If incoming traffic goes to fast we can be blocked in the internal while. We could imagine to have something like on every X frame we exit like replacing it by:
frameProccessed = 0
while ( priority queue not empty && frameProccessed < X ) {
FrameProcessed++
PeekOne();
…

@disk91 my point is that that gets packet out of order right?

There is no order in between different devices.
the order only matter at a device level.
let’s take an exemple:
Original order

device A packet 1
Device B packet 1
Device A packet 2

Imagine we have B1, then A1, then A2 - no impact at all
imagine B1, A2, A1 the A1 will be dropped but it’s like if it was lost and that’s a normal behavior in lorawan to lost packet.

I do not think this would have a lot of impact as the queue (when a hotspot is not connected) is limited to 20 packets and as soon as the hotspot reconnect it will send all of them down the stream.
FYI: Packets are not individually sent, as the hotspot opens a stream (and keeps it open at all time).
Also, if I am not mistaken, old packets will get removed out the queue automatically and the gateway will only keeps the last 20.

If the queue is limited to 20 entries. I agree, all of this does not have a big impact

If the queue is limited to 20 entries. I agree, all of this does not have a big impact

Indeed it is.. I'll close this as answered for now then


New Issue doesn't list downloaded and in progress items.

New Issue doesn't list downloaded and in progress items in a separate tab.
and from the playlist there is no option to stop the unwanted downloads.

Release in version 2.1.1, Pending review on Chrome, Ready on Firefox

FYI: @mohit-thakur-721 chrome just released v2.1.1


added background refresh for email and fixed clicking bugs

Closes #12 #11

It's an incomplete PR so do not merge right now.


Fix 404 text content-type for JSON controllers

Solving #231.
I decided to throw NotFoundError when undefined is returned from an action. This should let error handler decide about formatting the JSON response for JSON controllers and text/plain or html for text responses.
However I think we should place the info about the route where the undefined has been returned. @pleerock @NoNameProvided do you have any idea about what info and how formated the error message should be? 😕

I have read the code only but it seems ok to me.

However I think we should place the info about the route where the undefined has been returned.

I really think we should add debugger package and do logging with proper namespacing. Both Koa and express uses debugger as default logger so it wont add dependency overhead, but will make easier to understand to see what happening inside routing-controllers. Some ideas:

adding routes / middlewares
returning undefined
errors

Others? I wanted to draft a PR for this quite a while.

I was thinking about message Error property - currently we only have stack and name NotFoundError. We should send the info like Cannot ${action.method} on ${action.url}. or sth like this. Pure express final handler do sth like this 😉

I was thinking about message Error property - currently we only have stack and name NotFoundError.

I dont know how the default errors look like. The first thing was to swap them for custom errors and add an error middleware. :D But yes a message property is definitely needed.

hmm why node: stable failed?

@pleerock See https://github.com/pleerock/routing-controllers/issues/243

Im afraid of these changes TBH. You changed the most fragile part of code. Are you sure about your changes? Have you tested everything?

@pleerock It's just a refactor of this part. The only change in behavior is throwing NotFoundError when response in undefined to let the error handler format the error info to JSON or text (or custom error handler).

But yes a message property is definitely needed.

@NoNameProvided
Do you have any proposal of the error message or we should implement the:
Cannot ${action.method.toUpperCase()} ${action.url}
like the finalhandler in express:
 msg = 'Cannot ' + req.method + ' ' + encodeUrl(parseUrl.original(req).pathname)
? 😉

Do you ask about the 404 error? We should create error message to every error type.
I would go with some more general one like The requested resource doesn't exist.. I dont see any value adding the url and method to the response, as it is known to the user because he/she made it.

We should create error message to every error type.

Do you mean the default error message for every bulit-in http error subclass? It could be nice 😉 However I always prefer custom messages like:
const playlistItem = await this.playlistItemRepository.findByIdAndOwner(itemId, user);
if (!playlistItem) {
    throw new NotFoundError(`Playlist item with ID '${itemId}' doesn't exist!`);
}

But the default message The requested resource doesn't exist. for 404 error is a good idea. So I think we should leave this PR as it is with no params in constructor - the error message would be the default one added later.
So, @NoNameProvided please review this PR, and we will wait for pleerock's acceptation as he is "afraid of these changes TBH" 😉

Do you mean the default error message for every bulit-in http error subclass?

Yes

So I think we should leave this PR as it is with no params in constructor - the error message would be the default one added later.

Yes, its a good idea. It's own my todolist to make error handling swappable / extendable in routing-controllers. I just dont have time to do it.

@NoNameProvided please review this PR,

With just reading the code it looks good to me.

With just reading the code it looks good to me.

So please click that damn button! 😆

@NoNameProvided looks like @pleerock is gone - if you are not afraid of this potentially dangerous changes, please merge this PR 😉

It looks like this PR broke the ability to write directly to the response:
https://github.com/pleerock/routing-controllers#using-request-and-response-objects

@fabiob
There are some problems with manually handling the response. You have to wait for this:
https://github.com/pleerock/routing-controllers/issues/117#issuecomment-327232988
There's now a race between routing-controllers action result handling and user's action code. We will fix this soon.


how to install r2lang? getting have_rlang=False

https://github.com/radareorg/r2ai/blob/86a5c2bebfe52f877c1d5767d95f1e07df59a9e1/main.py#L42 it tries to import r2lang but it failed,
for r2pipe it was fixed with pip install r2pipe, but I didn't found any way to install r2lang

r2lang is provided by r2pm -ci rlang-python

got it, when i run r2, it was imported there.
but when we load r2ai repl with #!pipe python3 main.py
in repl.py it was not importing the r2lang
for debug, I added print logs

and one more thing, I was not able to run r2 commands in r2ai repl with :

https://github.com/radareorg/r2ai/blob/d80451e8a3fefdfcfdf80a1dc9ff1e21c71d7c7c/r2ai/repl.py#L306
r2 set to None and not updated
https://github.com/radareorg/r2ai/blob/d80451e8a3fefdfcfdf80a1dc9ff1e21c71d7c7c/r2ai/repl.py#L18

fixed in master :) please confirm and thanks for reporting!

Awesome, the issue is fixed.

Ok to close now?


[BugFix] fix short read eos flag error on multi be

Fixbug:
eos of RowBatch in FE  for short circuit read was not set correctly. The original processing of eos is always true. it will cause query result's records can't be fully return to query client for existing multi be . because that it think data  stream already end.
so this pr will set eos based on whether is the last response
What I'm doing:
Fixes #issue
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

[ ] This is a backport pr

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

@mergify backport branch-3.2


shouldPrefetch, shouldPreload, regression - missing file names

Version
v2.1.0
Reproduction link
[not necessary](not necessary)
Steps to reproduce
add to nuxt.config.js:
render: {
    bundleRenderer: {
      shouldPrefetch: (file, type) => {
        console.log('shouldPrefetch', file, type)
        return true
      },
      shouldPreload: (file, type) => {
        console.log('shouldPreload', file, type)
        return true
      }
    }
  },

What is expected ?
Expected filenames, like in version 1.4
What is actually happening?
Instead of filenames we get hashcodes. It is not possible to decide what to prefetch/preload.

This bug report is available on Nuxt community (#c7953)

This is related to the change to webpack4. You can use build.splitChunks.name to re-enable names. (nuxt-docs, webpack-docs)
Also, the file name structure has been changed a little (docs). You can adapt it as well to your needs.


TypeError: 'ByteCodeInst' object is not iterable

Reporting a bug

[x] I am using the latest released version of Numba (most recent is visible in
the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
[x] I have included below a minimal working reproducer (if you are unsure how
to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

First time trying Numba. Got this error when I decorated my function with jit (both with and without nopython). It's a function that treats values found on a CSV file.
@jit
def treat_value_csv(cell, locale=None):
    try:
        is_nan = math.isnan(cell)
    except:
        is_nan = False

    if is_nan or isinstance(cell, NaTType):
        return ''
    # -----------------------------

    elif isinstance(cell, Timestamp) or isinstance(cell, datetime.time):
        if isinstance(cell, Timestamp):
            # Case the cell is timestamp python object parse it to string
            datetime_obj = datetime.datetime(
                year=cell.year, month=cell.month, day=cell.day, second=cell.second, microsecond=cell.microsecond
            )
            return convert_to_docs_timestamp(datetime_obj)
        else:
            return str(cell)
    elif isinstance(cell, datetime.datetime) or isinstance(cell, datetime.date):
        # Get the timestamp from datetime object
        if isinstance(cell, datetime.datetime):
            datetime_obj = cell
        else:
            datetime_obj = datetime.datetime.combine(cell, datetime.datetime.min.time())
        return convert_to_docs_timestamp(datetime_obj)
    elif isinstance(cell, int) or isinstance(cell, float):
        return cell
    else:
        try:
            # Case the cell is string representing an integer, parse it to integer so it won't try to parse it
            # timestamp
            int_val = int(cell)
            if len(cell) > 0 and cell[0] == '0':
                return cell
            else:
                return int_val
        except:
            try:
                # Case the cell is string representing a float, parse it to float so it won't try to parse
                # it to timestamp

                scientific_notation_matches = []
                if isinstance(cell, str) or isinstance(cell, unicode):
                    # Check if the string represents scientific number to prevent it from being parsed to float
                    match_rule = re.compile('[+\-]?[^A-Za-z]?(?:0|[1-9]\d*)(?:\.\d*)?(?:[eE][+\-]?\d+)')
                    scientific_notation_matches = re.findall(match_rule, cell)

                if cell.lower() == 'nan' or cell.lower() == 'infinity' or cell.lower() == 'inf' \
                        or scientific_notation_matches:
                    # avoid 'nan', 'infinity' or 'scientific number' string from being converted to float
                    return cell
                else:
                    return float(cell)
                    # if len(cell) > 0 and cell[0] == '0':
                    #     out_row.append(cell)
                    # else:
                    #     out_row.append(float(cell))
            except:
                # Prevents trying to convert every string to date
                if looks_like_datetime(cell):
                    try:
                        # Try to parse the string to timestamp
                        if locale and locale.get('date_format'):
                            datetime_obj = try_parsing_date(cell, date_format=locale.get('date_format'))
                        else:
                            try:
                                datetime_obj = try_parsing_date(cell, date_format="month/day/year")
                            except:
                                try:
                                    datetime_obj = try_parsing_date(cell, date_format="year/month/day")
                                except:
                                    datetime_obj = try_parsing_date(cell, date_format="day/month/year")

                        return convert_to_docs_timestamp(datetime_obj)
                    except:
                        return cell
                else:
                    return cell

Numba is designed for numerical code, and does not support many of the data types and functions in your example.  Here is the list of supported Python features:
http://numba.pydata.org/numba-doc/latest/reference/pysupported.html

If you are new to Numba, perhaps take a look at the 5 minute guide first and/or click one of the Try Now buttons here http://numba.pydata.org/ to open up an interactive Numba demo in your browser, this one demonstrates the basics.

This:
from numba import jit
import datetime
import math
from pandas import Timestamp, NaT
import re

def try_parsing_date(a, date_format):
    pass

def convert_to_docs_timestamp(obj):
    pass

def looks_like_datetime(obj):
    pass

NaTType = type(NaT)

@jit
def treat_value_csv(cell, locale=None):
    try:
        is_nan = math.isnan(cell)
    except:
        is_nan = False

    if is_nan or isinstance(cell, NaTType):
        return ''
    # -----------------------------

    elif isinstance(cell, Timestamp) or isinstance(cell, datetime.time):
        if isinstance(cell, Timestamp):
            # Case the cell is timestamp python object parse it to string
            datetime_obj = datetime.datetime(
                year=cell.year, month=cell.month, day=cell.day, second=cell.second, microsecond=cell.microsecond
            )
            return convert_to_docs_timestamp(datetime_obj)
        else:
            return str(cell)
    elif isinstance(cell, datetime.datetime) or isinstance(cell, datetime.date):
        # Get the timestamp from datetime object
        if isinstance(cell, datetime.datetime):
            datetime_obj = cell
        else:
            datetime_obj = datetime.datetime.combine(cell, datetime.datetime.min.time())
        return convert_to_docs_timestamp(datetime_obj)
    elif isinstance(cell, int) or isinstance(cell, float):
        return cell
    else:
        try:
            # Case the cell is string representing an integer, parse it to integer so it won't try to parse it
            # timestamp
            int_val = int(cell)
            if len(cell) > 0 and cell[0] == '0':
                return cell
            else:
                return int_val
        except:
            try:
                # Case the cell is string representing a float, parse it to float so it won't try to parse
                # it to timestamp

                scientific_notation_matches = []
                if isinstance(cell, str) or isinstance(cell, unicode):
                    # Check if the string represents scientific number to prevent it from being parsed to float
                    match_rule = re.compile('[+\-]?[^A-Za-z]?(?:0|[1-9]\d*)(?:\.\d*)?(?:[eE][+\-]?\d+)')
                    scientific_notation_matches = re.findall(match_rule, cell)

                if cell.lower() == 'nan' or cell.lower() == 'infinity' or cell.lower() == 'inf' \
                        or scientific_notation_matches:
                    # avoid 'nan', 'infinity' or 'scientific number' string from being converted to float
                    return cell
                else:
                    return float(cell)
                    # if len(cell) > 0 and cell[0] == '0':
                    #     out_row.append(cell)
                    # else:
                    #     out_row.append(float(cell))
            except:
                # Prevents trying to convert every string to date
                if looks_like_datetime(cell):
                    try:
                        # Try to parse the string to timestamp
                        if locale and locale.get('date_format'):
                            datetime_obj = try_parsing_date(cell, date_format=locale.get('date_format'))
                        else:
                            try:
                                datetime_obj = try_parsing_date(cell, date_format="month/day/year")
                            except:
                                try:
                                    datetime_obj = try_parsing_date(cell, date_format="year/month/day")
                                except:
                                    datetime_obj = try_parsing_date(cell, date_format="day/month/year")

                        return convert_to_docs_timestamp(datetime_obj)
                    except:
                        return cell
                else:
                    return cell

treat_value_csv(None)

produces an assertion error in the control flow of SETUP_EXCEPT, there's clearly more work needed on a few bytecode instructions and also some more work is needed on objectmode CFG.


still get adblocker warning

firefox

Hello,
Have you tried to hard refresh ? (CTRL + Shift + R)
If yes, could you please send a screenshot of the developer's console (F12) HTML Inspector (First tab) centered on the popup window ; the first icon (the one with the cursor over a rectangle) allows you to click on an element to select it.


Revert "GitBook: [master] 15 pages and 2 assets modified"

This reverts commit 12e696eb502a09ba75280873111175eb96322233.
Signed-off-by: Krasi Georgiev<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build 401605702

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 36.271%

Totals

Change from base Build 401602459:
0.0%

Covered Lines:
1523

Relevant Lines:
4199

💛  - Coveralls


Make fcrepo4-labs repository for demo

Initial content from emetsger/apix-docker-test)
Shall contain at least docker-compose.yml launching all necessary image(s) for running the demo

https://github.com/fcrepo4-labs/fcrepo-api-x-demo


[BUG] No documentation.  What does this mod do?

Describe the bug
OK, so your mod shares the same name as the Hermitraft one.  But that's all I know.
To Reproduce
Steps to reproduce the behavior:

Go to the website.  Lack of reading material, so you can't progress.

Expected behavior
A clear and concise description of what the mod does.
Screenshots
If applicable, add screenshots to help explain your problem.
Versions (please complete the following information):

Forge/Fabric Loader Version:
MC Version:
Mod Version:
JEI Version (if present) :
Fabric API Version (if present) :

Log output/error (via. Hastebin)
Get your minecraft log and paste it in the above link and paste the link here.
Additional context
Add any other context about the problem here.

You need javascript enabled for it to work
http://strikerrocker.github.io/vanillatweaks/


BUGFIX: initialize logger with correct name

Prevent error
No handlers could be found for logger "gdctmpcleaner"
And use correct handlers for log messages.

Solved in scope of https://github.com/gooddata/tmpcleaner/pull/10


Type errors in analyze.py, audio.py and config.py at the Verify step in MacOS install

Describe the bug
I'm walking through a CLI re-install in a new directory.  All is fine until I ran the command in the Verify step (" python analyze.py ") at which point I got this response:
(venv-birdnet) ~/Documents/Projects/Birdnet/BirdNET-Analyzer % python analyze.py
Traceback (most recent call last):
File "/Users/mikeoconnor/Documents/Projects/Birdnet/BirdNET-Analyzer/analyze.py", line 15, in  import audio
File "/Users/mikeoconnor/Documents/Projects/Birdnet/BirdNET-Analyzer/audio.py", line 5, in  import config as cfg
File "/Users/mikeoconnor/Documents/Projects/Birdnet/BirdNET-Analyzer/config.py", line 110, in
RESULT_TYPES: set[str] | list[str] = {"table"}
TypeError: unsupported operand type(s) for |: 'types.GenericAlias' and 'types.GenericAlias'
To Reproduce
Steps to reproduce the behavior:
For the GUI:

Go to '...'
Click on '....'
Scroll down to '....'
See error
For the CLI provide us with the arguments used.

See above
Expected behavior
A clear and concise description of what you expected to happen.
I wasn't expecting to see errors -- don't know what the proper response would have been
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. MacOS, Win10]
Version [e.g. 1.0.2]

MacOS Ventura 13.9.7 on an M1 Ultra
Additional context
Add any other context about the problem here.

UPDATE:  Here's a Dropbox link to a terminal session where I start from an empty directory and replicate the error (having restarted the Mac)
https://www.dropbox.com/scl/fi/kg8qkkjhbuqjkua268v5g/CLI-install-session.txt?rlkey=plgx9obj9lw4d353v2f61v3kk&dl=0

The Analyzer repository requires Python 3.10.
Please check your used Python version (python --version).
I'll make a note in the readme.

Hi Josef,
Ah, you're right - I have Python 3.9 on this machine.  Interestingly the first time I installed Birdnet (a couple days before the one that failed) it ran fine.  Did something change recently that might have caused the 2-or-3-day-later install to fail?
Second question -- can I take your comment to mean "3.10 or later," or "3.10 only"?
Thanks for your help!

Here's an update -- upgrading to 3.10 cured the error.  Thanks!
but 3.10 is old enough the Python site is discouraging people from installing it for security reasons.  Locating a Mac installer is tricky because the way Python.org lays out the "looking for a specific release?" page points to files that aren't an installer.  The highest Mac-installer release is 3.10.11 (which is located here).
The Python site really wants Mac users to install the current release -- 3.12.5.  Would that break stuff in Birdnet?

3.11 should work, that's the one I'm using but as you already discovered tensorflow does not yet officially support Python 3.12


.webp images don't work in iOS

Take the following markdown
![image](https://i.giphy.com/media/NTur7XlVDUdqM/giphy.webp)
This does not work on iOS browsers.  According to this

you can use the <picture> element to show webP images and fallback to PNGs for browsers that don’t support webP

You can't use .webp at all in iOS devices. Safari Webkit doesn't allow that.


Add content-type: application/json to responses

I noticed that responses don't contain the content-type header. This confuses the Swagger UI.
To verify:
curl -X 'POST' \
  'http://localhost:5781/query' \
  -i \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "log_level" : "DEBUG",
  "message": {
    "query_graph": {
  "nodes": {
    "n0": {
      "name": "Ebola hemorrhagic fever",
      "ids": [
        "MONDO:0005737"
      ],
      "categories": [
        "biolink:Disease",
        "biolink:DiseaseOrPhenotypicFeature",
        "biolink:BiologicalEntity",
        "biolink:NamedThing",
        "biolink:Entity"
      ]
    },
    "n1": {
      "name": "ChemicalSubstance",
      "categories": [
        "biolink:ChemicalSubstance"
      ]
    }
  },
  "edges": {
    "e0": {
      "subject": "n0",
      "object": "n1",
      "predicates": [
        "biolink:related_to"
      ]
    }
  }
}
  }
}'

Fixed by #274.


Update configure-email-notifications.md

Added PowerShell example

@doctordns : Thanks for your contribution! The author(s) have been notified to review your proposed change.

any progress?

@doctordns : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

@illfated: I'm sorry - only the author of this article, @JasonGerend, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

Yes, I know. The sign-off comment is in agreement with the MS Docs team.

Any news?
If there is an issue with the proposed changes, please let me know. Otherwise, can someone accept the PR?

@JasonGerend : Any chance you could review this document, or assign someone else to do it instead?

Thanks @doctordns, and sorry for the delay. Nothing left to do but smile, smile, smile.


Add LakshanRukantha's Portfolio

Closes #69

@Kiran1689 Changes added.

Hi @LakshanRukantha
Im planning to change the the preview image in the README file and make it using the template you used in #69
Can you please change it ?

If want to work on that raise the new PR
In the template put the images of live website (Take the screenshots)
In the PR description please provide me screenshot of updated README file.
Thanks :)

@all-contributors please add @LakshanRukantha for code

Hi @LakshanRukantha
Im planning to change the the preview image in the README file and make it using the template you used in #69
Can you please change it ?

@Kiran1689 Sure I can work on it.

If want to work on that raise the new PR
In the template put the images of live website (Take the screenshots)
In the PR description please provide me screenshot of updated README file.
Thanks :)

@Kiran1689 I've made the necessary changes you mentioned. Please check #73


[11596] Update to ROS 2 Galactic

This PR updates the documentation to ROS 2 Galactic.
The spelling error is fixed in #266.
Signed-off-by: JLBuenoLopez-eProsima<EMAIL_ADDRESS>

@richiprosima Please test this


[security][draft] getting rid of a recoverable panic

This should not panic as we can recover from this error: do nothing.
Sure, it might indicate some deeper problem, but we do not need to take down our validator because of this. This way we can continue to vote in subsequent round until the issue is fixed.
draft: I just need to understand how to properly log the error.

These are our rough guidelines:
critical: The process is unlikely to be able to continue operating, most of the time a log at this level should be followed by a crash. Examples: unable to load config at startup, unable to read/write to storage.
error: An unexpected situation has occurred which may prevent the overall system from functioning as intended. These are usually caused by code bugs or system interactions. These should never occur as the result of end user or network interactions.
This sounds like error level to me. We don't have anything outside yet specifically to parse these and act, but just getting the level right is the most important piece right now.

Alright! addressed @dmitri-perelman comment and added an error!("FIXME: ...") log.
It would be good to document a way to prefix errors perhaps?
@opsguy

@bors-libra r=dmitri-perelman

:pushpin: Commit 482035f has been approved by dmitri-perelman

:hourglass: Testing commit 482035f535e314ce1bdea1695cf11b53c90a5f97 with merge e1487fe918fbff132610e05e30858fc07283cc5a...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: dmitri-perelman
Pushing e1487fe918fbff132610e05e30858fc07283cc5a to master...


Issue with deploying via Hex-LLM, TPU serving solution built with XLA, which is being developed by Google Cloud.

Expected Behavior
Model Deployed Successfully
Actual Behavior
I am getting this error -
INFO:google.cloud.aiplatform.models:Creating Endpoint
INFO:google.cloud.aiplatform.models:Create Endpoint backing LRO: projects/81995035742/locations/us-central1/endpoints/6941658909824253952/operations/4744238776585289728
Using model from:  gs://19865_finetuned_models/gemma-keras-lora-train_20240308_200536
INFO:google.cloud.aiplatform.models:Endpoint created. Resource name: projects/81995035742/locations/us-central1/endpoints/6941658909824253952
INFO:google.cloud.aiplatform.models:To use this Endpoint in another session:
INFO:google.cloud.aiplatform.models:endpoint = aiplatform.Endpoint('projects/81995035742/locations/us-central1/endpoints/6941658909824253952')
INFO:google.cloud.aiplatform.models:Creating Model
INFO:google.cloud.aiplatform.models:Create Model backing LRO: projects/81995035742/locations/us-central1/models/6359646723312189440/operations/7818789947195785216
INFO:google.cloud.aiplatform.models:Model created. Resource name: projects/81995035742/locations/us-central1/models/6359646723312189440@1
INFO:google.cloud.aiplatform.models:To use this Model in another session:
INFO:google.cloud.aiplatform.models:model = aiplatform.Model('projects/81995035742/locations/us-central1/models/6359646723312189440@1')
INFO:google.cloud.aiplatform.models:Deploying model to Endpoint : projects/81995035742/locations/us-central1/endpoints/6941658909824253952
InactiveRpcError                         Traceback (most recent call last)
/usr/local/lib/python3.10/dist-packages/google/api_core/grpc_helpers.py in error_remapped_callable(*args, **kwargs)
71         try:
---> 72             return callable(*args, **kwargs)
73         except grpc.RpcError as exc:
11 frames
_InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.INVALID_ARGUMENT
details = "Machine type "ct4p-hightpu-4t" is not supported."
debug_error_string = "UNKNOWN:Error received from peer ipv4:<IP_ADDRESS>:443 {created_time:"2024-03-08T21:11:42.821027279+00:00", grpc_status:3, grpc_message:"Machine type "ct4p-hightpu-4t" is not supported."}"

The above exception was the direct cause of the following exception:
InvalidArgument                           Traceback (most recent call last)
/usr/local/lib/python3.10/dist-packages/google/api_core/grpc_helpers.py in error_remapped_callable(*args, **kwargs)
72             return callable_(*args, **kwargs)
73         except grpc.RpcError as exc:
---> 74             raise exceptions.from_grpc_error(exc) from exc
75
76     return error_remapped_callable
InvalidArgument: 400 Machine type "ct4p-hightpu-4t" is not supported.
Steps to Reproduce the Problem
Run this code - # @title Deploy
@markdown This section uploads the model to Model Registry and deploys it on the Endpoint. It takes 15 minutes to 1 hour to finish.
@markdown Hex-LLM is a High-Efficiency Large Language Model (LLM) TPU serving solution built with XLA, which is being developed by Google Cloud. This notebook uses TPU v5e machines. Click Show code to see more details.
if LOAD_MODEL_FROM != "Kaggle":
print("Skipped: Expect to load model from Kaggle, got", LOAD_MODEL_FROM)
else:
if "2b" in KAGGLE_MODEL_ID:
# Sets ct5lp-hightpu-1t (1 TPU chip) to deploy Gemma 2B models.
machine_type = "ct5lp-hightpu-1t"
else:
# Sets ct5lp-hightpu-4t (4 TPU chips) to deploy Gemma 7B models.
machine_type = "ct4p-hightpu-4t"
# Note that a larger max_num_batched_tokens will require more TPU memory.
max_num_batched_tokens = 11264
# Multiple of tokens for padding alignment. A higher value can reduce
# re-compilation but can also increase the waste in computation.
tokens_pad_multiple = 1024
# Multiple of sequences for padding alignment. A higher value can reduce
# re-compilation but can also increase the waste in computation.
seqs_pad_multiple = 32

print("Using model from: ", output_folder)
model, endpoint = deploy_model_hexllm(
    model_name=get_job_name_with_datetime(prefix="gemma-serve-hexllm"),
    base_model_id=f"google/{KAGGLE_MODEL_ID}",
    model_id=output_folder,
    service_account=SERVICE_ACCOUNT,
    machine_type=machine_type,
    max_num_batched_tokens=max_num_batched_tokens,
    tokens_pad_multiple=tokens_pad_multiple,
    seqs_pad_multiple=seqs_pad_multiple,
)
print("endpoint_name:", endpoint.name)

Specifications

Version:
Platform: colab enterprise

@KCFindstr: can you please take a look at this issue? Thanks.

From the original notebook, the correct machine type is ct5lp-hightpu-4t - You might have accidentally modified the machine type. Please let me know if ct5lp-hightpu-4t works.

I had originally tried with  ct5lp-hightpu-4t It still gives the same error, also  ct5lp-hightpu-1t is giving the same error. I have also tried raising a support request but there is no issue with permissions.

Still getting the sam error

Hi @kathyyu-google , would you please take a look at this hex-llm deployment failure?

Based on the endpoint ID from the logs (projects/81995035742/locations/us-central1/endpoints/6941658909824253952), this endpoint was created in the us-central1 region. TPU deployment is supported only in the us-west1 region. Please update the variable REGION and re-attempt the deployment. Please also verify that there is available TPU quota (see the "Request for TPU quota" section of the notebook for more details).
ct5lp-hightpu-*t is the expected machine type here, such as ct5lp-hightpu-1t and ct5lp-hightpu-4t.

Is Hex-LLM opensource or private and can it be used with Cloud TPU API ?

Is Hex-LLM opensource or private and can it be used with Cloud TPU API ?

Hex-LLM is a closed-source serving solution. It can't be used directly with Cloud TPU; it can be used with deployments on Vertex Online Prediction. Example notebooks include https://github.com/GoogleCloudPlatform/vertex-ai-samples/blob/main/notebooks/community/model_garden/model_garden_gemma2_deployment_on_vertex.ipynb.

Closing this issue as the original question about TPU machine type and region has been answered. Please reopen if needed, thanks!

Closing this issue as the original question about TPU machine type and region has been answered. Please reopen if needed, thanks!

Very good solution , but I think it still doesn't support most models, got error with Deepseek 7b model which is based on LLAMA 2 architecture, also it doesn't support Qwen2 models which are also very good, are you considering adding more models support in the future

Thank you @vanshi3214 for the suggestion! Currently it supports Gemma, Llama, Mistral and Mixtral models. We will take your suggestion into consideration.


Missing app.yaml file in the generated source

docs/mp/guides/02_quickstart.adoc
Environment Details

Helidon Version: 2.0.1
Helidon MP
JDK version: java version "11.0.7" 2020-04-14 LTS
OS: Mac OS Catalina 10.15.5 (19F101)
Docker version (if applicable):

Problem Description
While following the tutorial docs/mp/guides/02_quickstart.adoc , Cannot find the required app.yaml to run the application on kubernetes, is this file to be genreated by the artifact or is it referencing an existing file?
Steps to reproduce
[//]: #  follow docs/mp/guides/02_quickstart.adoc
[//]: # deploy application to k8s section.

Looks like this was dropped this when we switched to our new archetype implementation. As a work-around you can try the file here: https://github.com/oracle/helidon/blob/release-2.0.1/examples/quickstarts/helidon-quickstart-mp/app.yaml

Fixed. See PR #2141


try to use repeater for mapAsyncIterator

Closing in favor of #56 (just forgot I opened this one to start with)


navigateTo doesn't work inside plugins called inside middleware

Environment
Environment
Node Version: v20.15.0
Nuxt Version: ^3.12.3
CLI Version: 3.12.0
Package Manager<EMAIL_ADDRESS>The issue does not depend on OS
Reproduction
Link: https://github.com/WillRy/nuxt3-middleware-issues
Just access the home page with npm run dev
Describe the bug
First of all, thank you very much for the work that the entire team has been doing.
When creating a 'custom fetch' as indicated in the documentation, to automatically redirect when receiving a 401 status code, we will have a problem where navigationTo is ignored in middlewares when we made a API call
This is the custom fetch instance registered as a plugin

export default defineNuxtPlugin(() => {
    const nuxtApp = useNuxtApp();
    const $customFetch = $fetch.create({
      baseURL: '/api',
      headers: {
        Accept: 'application/json',
      },
      async onRequest({ request, options, error }) {
      },
      async onResponse({ response }) {
        if (response.status == 401) {
          await nuxtApp.runWithContext(() => navigateTo('/login?logout=1'));
        }
      },
    });
    // Expose to useNuxtApp().$customFetch
    return {
      provide: {
        customFetch: $customFetch,
      },
    };
  });

This is the custom fetch COMPOSABLE
import type { UseFetchOptions } from "nuxt/app";
export function $serverFetch<T>(
  url: string | (() => string),
  options: UseFetchOptions<T> = {},
) {
  return useFetch(url, {
    ...options,
    $fetch: useNuxtApp().$customFetch,
  });
}

And inside a global middleware, auth.global.ts:

export default defineNuxtRouteMiddleware(async (to, from) => {

  const haveLogoutQueryString = to.fullPath.includes("logout");

  if (haveLogoutQueryString) {
    return;
  }

  const { error } = await $serverFetch("/user");

  console.log(error);
});

The API call made within the middleware will return 401 and according to the 'custom fetch' interceptors, a navigateTo should be made, which is ignored.
Thanks!
Additional context
No response
Logs
No response

+1

navigateTo works for me when called directly in onResponseError except the situation Nuxt receives redirect in SSR context, then the navigateTo is ignored for some reason.

in order for middleware to work, they need to return the call to navigateTo. it's not enough for it to be called (because a navigation is about to take place, once the middleware finishes running).

In my case above, I need to load the authenticated user if it has not been loaded. However, the call to the API may return a 401 error (authentication) and so I need to force the logout, redirecting to the login screen.
Since this is an expected behavior in any type of ajax, regardless of whether it is client side or server side, I put it in the custom instance that I created of "ofetch", so that it is a global behavior.
In fact, the Nuxt documentation guides this way:
https://nuxt.com/docs/guide/recipes/custom-usefetch#custom-fetch
What I did temporarily is to keep the redirect in "onRequestError" and in the middleware, I force a redirect manually if the user does not load.


UI: Sources Missing Layout

UI is missing the layout for the data integration to be plugged into

Closing as duplicate of #58


Splicing an element of an array that is binded to an object in a collection

I'm currently trying to splice an array that is part of an object and am running into an error.
In my angular controller, I used the  $meteor.object call (with the default autoupdate param set to true )to get a cursor to an object that looks like this:
{
'roomID': 1 ,
'users': [a,b,c,d,e,f,g,h,i]
}
now when the scope of this controller dies I want to remove element g from the users array.
the code that I'm using to do this is:
$scope.$on("$destroy", function() {
object.users.splice(7,1);
}
However I'm running into this error:

Any ideas why this is happening or perhaps a workaround?

+1, I have been seeing this as well since rc5.  For me mongo db on server is updating correctly, but minimongo is having issues on client and gives similar error in browser console.

Also running into this. If I push to the array there is no problem saving. It appears to be just when splicing and saving.

OK so we are waiting for the pull request in Meteor to fix that.
Just a question, is downgrading to Meteor 1.1 resolve your problems?

I could not figure out how to downgrade meteor
My meteorpad demonstration of the error does not seem to produce an error anymore
http://meteorpad.com/pad/5r9Xz4ceRFaXfBgLb/Array-Error
It does however still produce the error for me with my local software (on the updated meteor)

Yes it looks like it changed Meteor 1.2.
Have you try to see if the pull request fixes that for you?
On Sat, Sep 26, 2015 at 11:32 PM lanmower<EMAIL_ADDRESS>wrote:

I could not figure out how to downgrade meteor
My meteorpad demonstration of the error does not seem to produce an error
anymore
http://meteorpad.com/pad/5r9Xz4ceRFaXfBgLb/Array-Error
It does however still produce the error for me with my local software (on
the updated meteor)
—
Reply to this email directly or view it on GitHub
https://github.com/Urigo/angular-meteor/issues/689#issuecomment-143492473
.

Do you mean is my angular-meteor updated?
I'm currently running 1.0.0-rc.11

@Cygnx could you please try again, this time with the new Meteor <IP_ADDRESS>?

Didn't spend a bunch of time retesting, but with meteor <IP_ADDRESS> I am getting this "update failed: MongoError: Cannot update 'members.0' and 'members' at the same time undefined". Don't know if that is a my code problem or if this error has renamed itself :P.
I can still add items to the array, still just deleting that is causing the error.
NOTE: I did try creating a brand new object and got the same error.

@thomas-cabral can you please share a reproduction?

Below is what I am using, addMember works fine removeMember does not. I have not tried to change anything since I ran into the first error (I have just been living with it). So there is a chance my remove method is simply not valid. I can mess around with removeMember in the morning and see if I can get somewhere.
$scope.project = $scope.$meteorObject(Projects, $stateParams.id).subscribe('projects');
$scope.addMember = function(user) {
if (!$scope.project.members) {
$scope.project.members = [];
$scope.project.members.push(user)
}
else if ($scope.project.members.indexOf(user) != -1) {
console.log("already added")
}
else {
$scope.project.members.push(user)
}
};
$scope.removeMember = function(user) {
$scope.project.members.splice($scope.project.members.indexOf(user), 1)
};

@jonmc12 has the new version fixed that for you?

Just a quick update, I am still getting the same error. Using "$scope.project.members = [];" in place of the splice gives the same error "update failed: MongoError: Cannot update 'members.0' and 'members' at the same time undefined".

@Urigo I'm on<EMAIL_ADDRESS>and currently I can not reproduce the bug on any of my client-side splice methods, so this is definitely an improvement in my app.  I haven't seen the error: documentMatches... error recently, fortunately.
However, I am still seeing the update failed: MongoError: Cannot update 'member_ids.0' and 'member_ids' at the same time error in a case where I call a server-side method that updates the collection with the following modifier:
{ '$pull': { member_ids: 'nvcuCkRuZFGT5KNzB' }, '$set': { updated_at:<PHONE_NUMBER>945 } }

In the client, when I listen on Meteor.connection._stream this server-side update sends the following message to the client:
{
  collection: "parties",
  fields: Object,
  updated_at:<PHONE_NUMBER>945,
  member_ids: Array[0],
  length: 0,
  __proto__: Array[0],
  __proto__: Object,
  id: "5cbepr4hxjEGr7D5W",
  msg: "changed",
}

And, immediately after, I get the update failed error message above.

Could you please check if the new pull request fixed the problem for you?

For me, yes, appears fixed.  Thx @netanelgilad

Fixed in 1.0.2

this post is a life saver ;) thanks!

Hello, i have meteor angular 1.0.3 package and still have a problem with update. I have a $meteor.object. Then i try to remove an array element with splice. When i do .save() error appears:
update failed: MongoError: Cannot update 'treatments.6' and 'treatments' at the same time. Meteor version is: 1.2.1.

@otporsad can you please test it out with the new 1.0.4 version?

I did not have time for a detailed testing, but so far when i splice array item there is now a null instead of spliced element.
Something like this:
[Item1, Item2,null,null,null]

@otporsad this is strange, I've tested it again and it seems to work.
Can you share a repo with the problem?

Hello, i made a new repo (I am new at this so i replicated, updated to 1.0.4 and adapted this repo: https://github.com/MarkPhillips7/angular-meteor-issue-793) to test this specific issue and now it works fine. Because of that i think my initial problem with null elements is caused by something else. Sorry for the confusion and thank you.

@otporsad so just to make sure - now it's working for you and there is no other problem?

Yes, so far I do not have any problems concerning splice() and save().

Encountered the same problem but with updating to the latest version it's resolved now.


Add resizeMode repeat on Android.

Hey there..
Do you plan to add resizeMode repeat on Android?
It's been a long time that we've only had this for iOS.
Is this on the roadmap?
Thanks.

It's not: https://github.com/facebook/react-native/wiki/Roadmap
Best would be to send a PR. Closing as this is not an issue.

+1. it necessary!!


⚠ Processors has degraded performance

In bf584be, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 301 ms

Resolved: Processors performance has improved in c4d11fd.


[BUG] Serialization Error When Using XRI 3 + Unity 6

Describe the bug
When using MRTK3 in Unity 6, an exception is thrown during serialization because the ToString() method is called, which is not allowed during serialization in Unity. The error originates from the InteractionModeManager MonoBehaviour on the MRTK Interaction Manager game object and involves the MixedReality.Toolkit.SerializableDictionary.
To reproduce
Steps to reproduce the behavior:

Create a new Unity project using version 6000.0.23f1.
Import the XRI3 and MRTK3 packages into the project.
Add the MRTK XR Rig prefab to your scene.
Find the MRTK Interaction Manager GameObject.
In the Inspector - Interactor Group Mappings - Entries, press the Add button at the bottom of the list.
Observe the error in the Unity Console.

Expected behavior
No exception should occur and add a new item in this Entries list.
Screenshots

Your setup (please complete the following information)

Unity Version 6000.0.23f1
MRTK Version or Commit [v4.0]
XRI [v3.0]

Target platform (please complete the following information)

Meta Quest 3
OpenXR

Notes on this issue:

The error stems from the default Inspector behavior of the add (+) button initially duplicating the last entry, and when that is attempted to be deserialized back to the underlying dictionary, it causes a duplicate key exception in the below code within SerializableDictionary.cs, showing up as the "ToString is not allowed..." in the log (which is a bit of a red herring).

        void ISerializationCallbackReceiver.OnAfterDeserialize()
        {
            this.Clear();

            foreach (SerializableDictionaryEntry entry in entries)
            {
                this.Add(entry.Key, entry.Value);   //<--- duplicate key argument exception when clicking + with an existing entry
            }
        }

A simple solution would be to modify the above line to this.TryAdd(entry.Key, entry.Value), however, that has the result of the add (+) button being essentially ignored as no duplicates will be added, so the user won't be able to manually add any entry, only remove.
But this brings up a bigger overall question, is SerializableDictionary fields intended for direct +/- manual modification in the Inspector anyway?  Most other uses of this type of field seem to get initialized either at runtime or in code in some other way, not via Inspector from what I could see.

In the case of InteractionModeManager, one solution would be to draw the serializable dictionary in a custom way, not providing the +/- buttons, just a view of the list, along with the already existing "Init Controllers" button that can initialize it.
Another possible solution is to modify SerializableDictionary.cs to have special handling of the serialized entry list while in Editor during serialization/deserialization to temporarily allow duplicates, with only the first duplicate entry being stored in the underlying dictionary.  I have made an initial attempt at this and it seems to work fine, but the bigger question of intent for manual modification of SerializedDictionary should be answered first I think).  And not sure if this opens a can of worms...

Were you able to tests locally for this change? See https://github.com/MixedRealityToolkit/MixedRealityToolkit-Unity/issues/960

Potential fixes:
[feature/XRI3] branch:  #962


tweak memory layout

place instructions (.text) and constants (.rodata) in ATCM,
static variables (.bss and .data) in BTCM0 and
the (call) stack in BTCM1

bors r+


Add From<&String> for Classes implementation

We used to support using &Strings as classes so adding that functionality back in

bors r+


Plantcv adding spice functionality

Needed to add one more function to the init file to make the demo work and give global access to the "unmix" function to users in the case that they want to use it.

Pull Request Test Coverage Report for Build 37

1 of 4 (25.0%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.05%) to 54.974%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

plantcv/hyperspectral/SPICE/spice_py_demo.py
0
3
0.0%

Files with Coverage Reduction
New Missed Lines
%

plantcv/hyperspectral/SPICE/spice_py_demo.py
1
0.0%

Totals

Change from base Build 36:
-0.05%

Covered Lines:
105

Relevant Lines:
191

💛  - Coveralls


Relating large unions of literal types performs poorly

🕗 Version & Regression Information
All versions.
⏯ Playground Link
Playground link with relevant code
💻 Code
type Digits = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9';
type T9XXXX = `9${Digits}${Digits}${Digits}${Digits}`;
type TXXXXX = `${Exclude<Digits, '0'>}${Digits}${Digits}${Digits}${Digits}`;

let x: Exclude<TXXXXX, T9XXXX> = '88888';

🙁 Actual behavior
The example above takes ~45s to compile on a reasonably fast machine. The underlying issue is that as we relate large unions of primitive types, we have a fast path for matches, but not for mismatches. Because the majority of the constituents of TXXXXX are not present in T9XXXX, we spend a lot of time in the slow path that attempts to find matches by iterating through all constituents.
🙂 Expected behavior
We can do much better by implementing a fast path for mismatches.

The example above takes ~45s to compile on a reasonably fast machine.

So more out of morbid curiosity than anything...
fatcerberus@Bruces-MacBook-Pro temp % time npx tsc wtf.ts
npx tsc wtf.ts  60.97s user 0.17s system 101% cpu 1:00.28 total
fatcerberus@Bruces-MacBook-Pro temp % node -v
v19.7.0

That was with an M2 Pro.