Error when running getSGFeatureCounts
1
1
Entering edit mode
jpromero ▴ 10
@jpromero-12231
Last seen 6.1 years ago

 

Hello!

Im currently developing an R package which depends on SGSeq. 

In the current devel version for SGSeq, there seems to be a bug or error in the function getSGFeatureCounts. Here is the error that appears when running the example for this function:

> path <- system.file("extdata", package = "SGSeq")
>  si$file_bam <- file.path(path, "bams", si$file_bam)
>  sgfc <- getSGFeatureCounts(si, sgf_pred)
N1 complete.
N2 complete.
N3 complete.
N4 complete.
T1 complete.
T2 complete.
T3 complete.
T4 complete.
Error in checkSlotAssignment(object, name, value) : 
  assignment of an object of class “NULL” is not valid for slot ‘NAMES’ in an object of class “SGFeatureCounts”; is(value, "characterORNULL") is not TRUE
>

Which is the same error that appears int the BioC build.

Thanks in Advance.

- J.P Romero
 

> sessionInfo()
R Under development (unstable) (2017-02-05 r72121)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

locale:
[1] LC_COLLATE=Spanish_Spain.1252  LC_CTYPE=Spanish_Spain.1252    LC_MONETARY=Spanish_Spain.1252
[4] LC_NUMERIC=C                   LC_TIME=Spanish_Spain.1252    

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

other attached packages:
 [1] GenomicFeatures_1.27.6     AnnotationDbi_1.37.2       EventPointer_0.99.15      
 [4] Matrix_1.2-8               SGSeq_1.9.1                SummarizedExperiment_1.5.4
 [7] Biobase_2.35.0             Rsamtools_1.27.12          Biostrings_2.43.4         
[10] XVector_0.15.2             GenomicRanges_1.27.22      GenomeInfoDb_1.11.6       
[13] IRanges_2.9.18             S4Vectors_0.13.13          graph_1.53.0              
[16] BiocGenerics_0.21.3        BiocInstaller_1.25.3      

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.9              compiler_3.4.0           iterators_1.0.8         
 [4] bitops_1.0-6             tools_3.4.0              zlibbioc_1.21.0         
 [7] biomaRt_2.31.4           digest_0.6.12            RSQLite_1.1-2           
[10] memoise_1.0.0            lattice_0.20-34          foreach_1.4.3           
[13] igraph_1.0.1             DBI_0.5-1                prodlim_1.5.9           
[16] stringr_1.1.0            rtracklayer_1.35.5       affxparser_1.47.0       
[19] grid_3.4.0               survival_2.40-1          XML_3.98-1.5            
[22] RBGL_1.51.0              BiocParallel_1.9.5       lava_1.4.7              
[25] limma_3.31.11            magrittr_1.5             splines_3.4.0           
[28] nnls_1.4                 matrixStats_0.51.0       codetools_0.2-15        
[31] GenomicAlignments_1.11.9 MASS_7.3-45              RUnit_0.4.31            
[34] stringi_1.1.2            RCurl_1.95-4.8           doParallel_1.0.10  

 

 

 

 

 

 

SGSeq software error • 1.8k views
ADD COMMENT
0
Entering edit mode
@leonard-goldstein-6845
Last seen 5 months ago
Australia

Hi, 

Thanks for reporting this. I can reproduce the error for the development version. It must be due to a recent change in a package that SGSeq depends on. I'll try to address this shortly. 

Thanks, 
Leonard

ADD COMMENT
0
Entering edit mode

Hi Leonard,


Thanks for looking at the error. I've already seen the issue in the devel mailing list and I'll be checking to know when it is solved.

Thanks.

- J.P Romero

ADD REPLY
0
Entering edit mode

I believe a fix will be for jpromero to re-install several packages, as indicated in https://stat.ethz.ch/pipermail/bioc-devel/2017-February/010463.html

ADD REPLY
0
Entering edit mode

Yes! I did see the e-mail on the BioC level mailing list. This could help to solve the problem locally but, of the build is run in  the BioC servers im guessing that it will still appear until the same roundabout is applied. For the servers, would I just have to wait or another solution is possible?

 

ADD REPLY
0
Entering edit mode

My guess is that the problem is only for existing installations.

You'd have to 'wait' until the build servers produced packages that triggered an update, i.e., a version bump followed by successful build and propagation. I doubt that bumping the version of 600+ packages is the right thing to do in this case, where the problem is on the 'devel' branch and where 'devel' users are able to take appropriate action locally.

The correct forum to ask about devel packages is on the bioc-devel mailing list.

ADD REPLY

Login before adding your answer.

Traffic: 793 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6