Error in read_feats

[mgabriell1]

Hi @thackl, Thanks for the great package! The example plots look great. I'm having some issue loading data (either mine or the example one) as you can see below (the error is exactly the same whether I load the example data and my gff3 or gbff files):

read_feats(ex("emales/emales.gff"))
Reading 'gff3' with `read_gff3()`:
* file_id: emales [/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library/gggenomes/extdata/emales/emales.gff]
Error in `map2()`:                                                                                                                                                                                                                                         
ℹ In index: 1.
ℹ With name: emales.
Caused by error in `map()`:
ℹ In index: 1.
Caused by error in `is.na(r) || str_length(r) == 0`:
! 'length = 3' in coercion to 'logical(1)'

I think it might be related to https://github.com/thackl/gggenomes/issues/96, but even if I load first the S4Vectors package and then gggenomes the error persists. I was still able to read the sequence files using read_seqs("data.gbff") obtaning a table with contigs lengths. Below you can find my sessionInfo() details. How is this solvable? Thanks for the support!

> sessionInfo()
R version 4.3.0 (2023-04-21)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Ventura 13.3.1

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.11.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: Europe/Zurich
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] gggenomes_0.9.9.9000 snakecase_0.11.0     jsonlite_1.8.4       tibble_3.2.1         thacklr_0.0.0.9000   tidyr_1.3.0          stringr_1.5.0        readr_2.1.4          purrr_1.0.1          gggenes_0.5.0       
[11] vctrs_0.6.2          ggplot2_3.4.2        dplyr_1.1.2         

loaded via a namespace (and not attached):
 [1] bit_4.0.5        gtable_0.3.3     compiler_4.3.0   crayon_1.5.2     tidyselect_1.2.0 parallel_4.3.0   scales_1.2.1     ggfittext_0.10.0 R6_2.5.1         generics_0.1.3   munsell_0.5.0    pillar_1.9.0    
[13] tzdb_0.4.0       rlang_1.1.1      utf8_1.2.3       stringi_1.7.12   bit64_4.0.5      cli_3.6.1        withr_2.5.0      magrittr_2.0.3   grid_4.3.0       vroom_1.6.3      rstudioapi_0.14  hms_1.1.3       
[25] lifecycle_1.0.3  glue_1.6.2       fansi_1.0.4      colorspace_2.1-0 tools_4.3.0      pkgconfig_2.0.3 

[austinreidmanny]

I encountered the same problem earlier today. I thought it was due to a poorly formatted file on my end. When I tried with a small viral GFF3 from NCBI, the problem persisted. And when I finally tried the example data, I got the same error as you.

I am hoping there is a quick answer to this.

[iimog]

tl;dr I think I fixed the issue. You can try the fix immediately by installing via

devtools::install_github("thackl/gggenomes@fix-156")

I was able to reproduce this error in R version 4.3.1 (it did not occur in R version 4.1). Relevant changes have been introduced in version 4.2.0 and 4.3.0 (see changelog)

• Calling && or || with either argument of length greater than one now gives a warning (which it is intended will become an error).
• Calling if() or while() with a condition of length greater than one gives an error rather than a warning. Consequently, environment variable _R_CHECK_LENGTH_1CONDITION no longer has any effect. and

• Calling && or || with LHS or (if evaluated) RHS of length greater than one is now always an error, with a report of the form

  'length = 4' in coercion to 'logical(1)'

  Environment variable _R_CHECK_LENGTH_1LOGIC2 no longer has any effect.

[austinreidmanny]

Installing the patch, restarting R, loading ggtree and then loading gggenomes worked. Thanks!

[mgabriell1]

Sorry for the late reply. Yes, this now works. Thanks for the quick fix!