[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