[BioC] parseGEO stack at first.entity <- findFirstEntity(con)

Sean Davis sdavis2 at mail.nih.gov
Sat Sep 23 17:27:52 CEST 2006


rcaloger wrote:
> Hi,
> I am using quite a lot the GEOquery libray.
> Recently I found out that the link to the GSE repository changed on GEO 
> therefore the getGEOfile function fails to download the file.Since there 
> is not the possibility to change the download path in the getGEOfile it 
> will be nice if the mantainers of GEOquery could add a parameter to the 
> function to allow it.
>
>   
Raf,

I'm glad to hear that you find GEOquery useful.  I should probably add a 
URL parameter at some point, yes.  However, in the short term, simply 
updating to the version 1.7.3 of GEOquery fixes the GEO URL issue. 

> Therefore, actually I am downloading locally the GSEXXX_family.soft.gz
> and I use the parseGEO function to reformat the GSE data.
> Yesterday, I tryed to parse the GSE3294_family.soft.gz:
> library(GEOquery)
> gse3294<-parseGEO("GSE3294_family.soft.gz")
>   
parseGEO doesn't take a filename, but instead takes a connection.  
However, parseGEO probably isn't the best way to go about this if you 
have the .tar.gz file stored locally.  getGEO() has a filename 
parameter, so you can simply do:

gse3294 <- getGEO(filename='GSE3294_family.soft.gz')

> since after few hours nothing came out. I debugged the function and find out that  
> the function freeze at the first line. first.entity <- findFirstEntity(con)
>
>   

This isn't a bug.  As I mentioned above, parseGEO doesn't work this way 
and really isn't meant to be called by the end user (as mentioned in the 
help).
> The problem was encoutered with GEOquery 1.6.0, running Bioconductor 1.8 on 
> windowXP centrino 2GHz, 1.5GB RAM on the GSE3294
>   
Thanks for including the GEOquery version and BioC version.  Yes, you 
should upgrade your GEOquery package--biocLite() will do the trick.

Let me know if you have more questions or if upgrading doesn't fix the 
problem.

Sean



More information about the Bioconductor mailing list