removing packages from the workspace - is this ok?
1
0
Entering edit mode
@jdelasherasedacuk-1189
Last seen 9.3 years ago
United Kingdom
This is more of a general R question, but it concerns in this case genomic annotation packages (BSgenome) and I would like to be sure I'm using this correctly and not mudling things up inadvertently. As part of certain checks I'm running, using various IDs and coordinates from different genomic builds, I want to extract sequences from two different human genomic builds. Sometimes HG18, sometimes HG19. This sometimes requires removing the annotation package from one build and loading the other. What I do is, for instance: library(BSgenome.Hsapiens.UCSC.hg18) seq1<-subseq(Hsapiens$chr1, 11323785, 11323785+20) as.character(seq1) [1] "ACACACACCTGGAGAGCCCCA" # ok, I got those 20 nucleotides. # now I want to check a sequence in the HG19 build # to remove HG18, I use detach("package:BSgenome.Hsapiens.UCSC.hg18", unload=T) # then I load HG19, and do whatever I want to do with it: library(BSgenome.Hsapiens.UCSC.hg19) seq2<-subseq(Hsapiens$chr1, 11401198, 11401198+20) as.character(seq2) [1] "ACACACACCTGGAGAGCCCCA" # the same sequence, good, I verified the coordinates match. # and now I remove it like I did for HG18: detach("package:BSgenome.Hsapiens.UCSC.hg19", unload=T) and I may want to repeat this process a few times, depending on what I get. my sessionInfo() indicates the packages have been removed that way. My only concern is whether there's anything 'invisible' to me that is not removed that way, and that when I query one build, I may inadvertenty query the wrong one... I just want to be sure that this is the correct/safe way to remove a package from the current workspace... and if it's not the right way, what is it? thank you for your help, Jose -- Dr. Jose I. de las Heras Email: J.delasHeras at ed.ac.uk The Wellcome Trust Centre for Cell Biology Phone: +44 (0)131 6507090 Institute for Cell & Molecular Biology Fax: +44 (0)131 6507360 Swann Building, Mayfield Road University of Edinburgh Edinburgh EH9 3JR UK -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Annotation PROcess Annotation PROcess • 1.8k views
ADD COMMENT
0
Entering edit mode
@steve-lianoglou-2771
Last seen 21 months ago
United States
Hi, On Tue, Jun 7, 2011 at 11:40 AM, <j.delasheras at="" ed.ac.uk=""> wrote: > > This is more of a general R question, but it concerns in this case genomic > annotation packages (BSgenome) and I would like to be sure I'm using this > correctly and not mudling things up inadvertently. > > As part of certain checks I'm running, using various IDs and coordinates > from different genomic builds, I want to extract sequences from two > different human genomic builds. Sometimes HG18, sometimes HG19. > > This sometimes requires removing the annotation package from one build and > loading the other. I'm not sure what the best way of doing what you want is, but I'd just reassign the BSgenome objects to their own variables and not try to juggle packages into/out-of the workspace, eg: R> library(BSgenome.Hsapiens.UCSC.hg19) R> hg19 <- Hsapiens R> library(BSgenome.Hsapiens.UCSC.hg18) R> hg18 <- Hsapiens You'll get the same results as you do now: > library(BSgenome.Hsapiens.UCSC.hg18) > seq1<-subseq(Hsapiens$chr1, 11323785, 11323785+20) > as.character(seq1) > [1] "ACACACACCTGGAGAGCCCCA" > > # ok, I got those 20 nucleotides. > # now I want to check a sequence in the HG19 build > # to remove HG18, I use > detach("package:BSgenome.Hsapiens.UCSC.hg18", unload=T) > > # then I load HG19, and do whatever I want to do with it: > library(BSgenome.Hsapiens.UCSC.hg19) > seq2<-subseq(Hsapiens$chr1, 11401198, 11401198+20) > as.character(seq2) > [1] "ACACACACCTGGAGAGCCCCA" > > # the same sequence, good, I verified the coordinates match. > # and now I remove it like I did for HG18: > detach("package:BSgenome.Hsapiens.UCSC.hg19", unload=T) R> subseq(hg18$chr1, 11323785, 11323785+20) 21-letter "MaskedDNAString" instance (# for masking) seq: ACACACACCTGGAGAGCCCCA R> subseq(hg19$chr1, 11401198, 11401198+20) 21-letter "MaskedDNAString" instance (# for masking) seq: ACACACACCTGGAGAGCCCCA It seems your way works fine, but maybe it could be a bit easier to name the genome objects explicitly so you don't have to wonder which build your Hsapiens object points to at any given time ... My 2 cents ... -steve -- Steve Lianoglou Graduate Student: Computational Systems Biology ?| Memorial Sloan-Kettering Cancer Center ?| Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact
ADD COMMENT
0
Entering edit mode
One solution to the issue of managing packages in your R namespace/environment is Hadley Wickham's devtools package<https: github.com="" hadley="" devtools#readme="">. I am surprised more people don't use it for this On Tue, Jun 7, 2011 at 9:04 AM, Steve Lianoglou < mailinglist.honeypot@gmail.com> wrote: > Hi, > > On Tue, Jun 7, 2011 at 11:40 AM, <j.delasheras@ed.ac.uk> wrote: > > > > This is more of a general R question, but it concerns in this case > genomic > > annotation packages (BSgenome) and I would like to be sure I'm using this > > correctly and not mudling things up inadvertently. > > > > As part of certain checks I'm running, using various IDs and coordinates > > from different genomic builds, I want to extract sequences from two > > different human genomic builds. Sometimes HG18, sometimes HG19. > > > > This sometimes requires removing the annotation package from one build > and > > loading the other. > > I'm not sure what the best way of doing what you want is, but I'd just > reassign the BSgenome objects to their own variables and not try to > juggle packages into/out-of the workspace, eg: > > R> library(BSgenome.Hsapiens.UCSC.hg19) > R> hg19 <- Hsapiens > R> library(BSgenome.Hsapiens.UCSC.hg18) > R> hg18 <- Hsapiens > > You'll get the same results as you do now: > > > library(BSgenome.Hsapiens.UCSC.hg18) > > seq1<-subseq(Hsapiens$chr1, 11323785, 11323785+20) > > as.character(seq1) > > [1] "ACACACACCTGGAGAGCCCCA" > > > > # ok, I got those 20 nucleotides. > > # now I want to check a sequence in the HG19 build > > # to remove HG18, I use > > detach("package:BSgenome.Hsapiens.UCSC.hg18", unload=T) > > > > # then I load HG19, and do whatever I want to do with it: > > library(BSgenome.Hsapiens.UCSC.hg19) > > seq2<-subseq(Hsapiens$chr1, 11401198, 11401198+20) > > as.character(seq2) > > [1] "ACACACACCTGGAGAGCCCCA" > > > > # the same sequence, good, I verified the coordinates match. > > # and now I remove it like I did for HG18: > > detach("package:BSgenome.Hsapiens.UCSC.hg19", unload=T) > > R> subseq(hg18$chr1, 11323785, 11323785+20) > 21-letter "MaskedDNAString" instance (# for masking) > seq: ACACACACCTGGAGAGCCCCA > > R> subseq(hg19$chr1, 11401198, 11401198+20) > 21-letter "MaskedDNAString" instance (# for masking) > seq: ACACACACCTGGAGAGCCCCA > > It seems your way works fine, but maybe it could be a bit easier to > name the genome objects explicitly so you don't have to wonder which > build your Hsapiens object points to at any given time ... > > My 2 cents ... > > -steve > > -- > Steve Lianoglou > Graduate Student: Computational Systems Biology > | Memorial Sloan-Kettering Cancer Center > | Weill Medical College of Cornell University > Contact Info: http://cbio.mskcc.org/~lianos/contact > > _______________________________________________ > Bioconductor mailing list > Bioconductor@r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: > http://news.gmane.org/gmane.science.biology.informatics.conductor > -- If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is. John von Neumann<http: www-groups.dcs.st-="" and.ac.uk="" ~history="" biographies="" von_neumann.html=""> [[alternative HTML version deleted]]
ADD REPLY
0
Entering edit mode
Hi, On Tue, Jun 7, 2011 at 2:34 PM, Tim Triche, Jr. <tim.triche at="" gmail.com=""> wrote: > One solution to the issue of managing packages in your R > namespace/environment is Hadley Wickham's devtools > package<https: github.com="" hadley="" devtools#readme="">. > ?I am surprised more people don't use it for this I actually tried using that a while ago in order to help make package development easier, but: (1) Isn't that more for being able to work with "source" packages w/o having to install them; and (2) as an aside, back then it had some problems with S4-isms (which may have been fixed by now) As with most all of Hadley's work -- I think devtools is (will be) great, but I don't quite see how that's the right tool for this job, though ... ? -steve -- Steve Lianoglou Graduate Student: Computational Systems Biology ?| Memorial Sloan-Kettering Cancer Center ?| Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact
ADD REPLY
0
Entering edit mode
you're right, it's more of a general solution. I end up with multiple versions of annotation packages, multiple namespaces' worth of S4 generics, etc. floating around and it is a nice swiss army chainsaw (like many of Hadley's packages) with some remaining rough edges. The ability to just "find a bigger hammer" appeals to me, but a purposeful solution is probably better for the problem at hand. On Tue, Jun 7, 2011 at 12:53 PM, Steve Lianoglou < mailinglist.honeypot@gmail.com> wrote: > Hi, > > On Tue, Jun 7, 2011 at 2:34 PM, Tim Triche, Jr. <tim.triche@gmail.com> > wrote: > > One solution to the issue of managing packages in your R > > namespace/environment is Hadley Wickham's devtools > > package<https: github.com="" hadley="" devtools#readme="">. > > I am surprised more people don't use it for this > > I actually tried using that a while ago in order to help make package > development easier, but: > > (1) Isn't that more for being able to work with "source" packages w/o > having to install them; and > (2) as an aside, back then it had some problems with S4-isms (which > may have been fixed by now) > > As with most all of Hadley's work -- I think devtools is (will be) > great, but I don't quite see how that's the right tool for this job, > though ... ? > > -steve > > -- > Steve Lianoglou > Graduate Student: Computational Systems Biology > | Memorial Sloan-Kettering Cancer Center > | Weill Medical College of Cornell University > Contact Info: http://cbio.mskcc.org/~lianos/contact > -- Watch your words, for they become actions. Watch your actions, for they become habits. Watch your habits, for they become your character. Watch your character, for it becomes your destiny. [[alternative HTML version deleted]]
ADD REPLY
0
Entering edit mode
Hi Jose, Steve, Tim, It seems to me that the more general question Jose is asking is how to unambiguously refer to an object when several objects with the same name are defined in several packages. One solution is to use the "fully qualified name" of the object i.e. to use a <pkgname>:: prefix. For example: BSgenome.Hsapiens.UCSC.hg18::Hsapiens BSgenome.Hsapiens.UCSC.hg19::Hsapiens For convenience, this can be combined with Steve's suggested reassignment to shorter names: hg18 <- BSgenome.Hsapiens.UCSC.hg18::Hsapiens hg19 <- BSgenome.Hsapiens.UCSC.hg19::Hsapiens By using the "fully qualified name", the result of this reassignment doesn't depend on the order the packages were loaded anymore. Cheers, H. On 11-06-07 02:06 PM, Tim Triche, Jr. wrote: > you're right, it's more of a general solution. I end up with multiple > versions of annotation packages, multiple namespaces' worth of S4 generics, > etc. floating around and it is a nice swiss army chainsaw (like many of > Hadley's packages) with some remaining rough edges. The ability to just > "find a bigger hammer" appeals to me, but a purposeful solution is probably > better for the problem at hand. > > > On Tue, Jun 7, 2011 at 12:53 PM, Steve Lianoglou< > mailinglist.honeypot at gmail.com> wrote: > >> Hi, >> >> On Tue, Jun 7, 2011 at 2:34 PM, Tim Triche, Jr.<tim.triche at="" gmail.com=""> >> wrote: >>> One solution to the issue of managing packages in your R >>> namespace/environment is Hadley Wickham's devtools >>> package<https: github.com="" hadley="" devtools#readme="">. >>> I am surprised more people don't use it for this >> >> I actually tried using that a while ago in order to help make package >> development easier, but: >> >> (1) Isn't that more for being able to work with "source" packages w/o >> having to install them; and >> (2) as an aside, back then it had some problems with S4-isms (which >> may have been fixed by now) >> >> As with most all of Hadley's work -- I think devtools is (will be) >> great, but I don't quite see how that's the right tool for this job, >> though ... ? >> >> -steve >> >> -- >> Steve Lianoglou >> Graduate Student: Computational Systems Biology >> | Memorial Sloan-Kettering Cancer Center >> | Weill Medical College of Cornell University >> Contact Info: http://cbio.mskcc.org/~lianos/contact >> > > > -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fhcrc.org Phone: (206) 667-5791 Fax: (206) 667-1319
ADD REPLY
0
Entering edit mode
Hi Herve, this indeed was the issue I had, which works perfectly well by following Steve's suggestion: simply explicitly renaming objects to ensure one deals with the correct one. The idea of explicitly indicating the package using the double semicolon had escaped me too, so thank you for bringing it up. Another related matter would be: what happens when two packages use two different functions that are however named identically? I can't think of any right now, but I remember having come across this at some point. I imagine that using the same approach (double semicolon to explicitly indicate which package teh function is in) will work. Is there a simple way to check a function name and return which of the loaded packages have a function with that name? And a list of functions included in a given package? This seems to be somewhat basic, but I don't think I've found *one* place to refer to all these issues. If someone can suggest a good place to find this information and better understand all the package/namespace/reference (double semicolon qualifier) nomenclature & structure, I'd be very grateful. Thank you everyone for their suggestions. Jose Quoting Hervé Pagès <hpages at="" fhcrc.org=""> on Wed, 08 Jun 2011 12:55:20 -0700: > Hi Jose, Steve, Tim, > > It seems to me that the more general question Jose is asking is how > to unambiguously refer to an object when several objects with the same > name are defined in several packages. > > One solution is to use the "fully qualified name" of the object i.e. > to use a <pkgname>:: prefix. For example: > > BSgenome.Hsapiens.UCSC.hg18::Hsapiens > BSgenome.Hsapiens.UCSC.hg19::Hsapiens > > For convenience, this can be combined with Steve's suggested > reassignment to shorter names: > > hg18 <- BSgenome.Hsapiens.UCSC.hg18::Hsapiens > hg19 <- BSgenome.Hsapiens.UCSC.hg19::Hsapiens > > By using the "fully qualified name", the result of this reassignment > doesn't depend on the order the packages were loaded anymore. > > Cheers, > H. > > > On 11-06-07 02:06 PM, Tim Triche, Jr. wrote: >> you're right, it's more of a general solution. I end up with multiple >> versions of annotation packages, multiple namespaces' worth of S4 generics, >> etc. floating around and it is a nice swiss army chainsaw (like many of >> Hadley's packages) with some remaining rough edges. The ability to just >> "find a bigger hammer" appeals to me, but a purposeful solution is probably >> better for the problem at hand. >> >> >> On Tue, Jun 7, 2011 at 12:53 PM, Steve Lianoglou< >> mailinglist.honeypot at gmail.com> wrote: >> >>> Hi, >>> >>> On Tue, Jun 7, 2011 at 2:34 PM, Tim Triche, Jr.<tim.triche at="" gmail.com=""> >>> wrote: >>>> One solution to the issue of managing packages in your R >>>> namespace/environment is Hadley Wickham's devtools >>>> package<https: github.com="" hadley="" devtools#readme="">. >>>> I am surprised more people don't use it for this >>> >>> I actually tried using that a while ago in order to help make package >>> development easier, but: >>> >>> (1) Isn't that more for being able to work with "source" packages w/o >>> having to install them; and >>> (2) as an aside, back then it had some problems with S4-isms (which >>> may have been fixed by now) >>> >>> As with most all of Hadley's work -- I think devtools is (will be) >>> great, but I don't quite see how that's the right tool for this job, >>> though ... ? >>> >>> -steve >>> >>> -- >>> Steve Lianoglou >>> Graduate Student: Computational Systems Biology >>> | Memorial Sloan-Kettering Cancer Center >>> | Weill Medical College of Cornell University >>> Contact Info: http://cbio.mskcc.org/~lianos/contact >>> >> >> >> > > > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpages at fhcrc.org > Phone: (206) 667-5791 > Fax: (206) 667-1319 > > -- Dr. Jose I. de las Heras Email: J.delasHeras at ed.ac.uk The Wellcome Trust Centre for Cell Biology Phone: +44 (0)131 6507090 Institute for Cell & Molecular Biology Fax: +44 (0)131 6507360 Swann Building, Mayfield Road University of Edinburgh Edinburgh EH9 3JR UK -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
ADD REPLY
0
Entering edit mode
This will get you started, but it's probably not the full answer. ? getAnywhere ? ls For example, ls(2), but note that this contains more than just functions, e.g. letters in base or IUPAC_CODE_MAP in Biostrings. On Jun 9, 2011, at 8:12 AM, J.delasHeras at ed.ac.uk wrote: > > Hi Herve, > > this indeed was the issue I had, which works perfectly well by > following Steve's suggestion: simply explicitly renaming objects to > ensure one deals with the correct one. The idea of explicitly > indicating the package using the double semicolon had escaped me > too, so thank you for bringing it up. > > Another related matter would be: what happens when two packages use > two different functions that are however named identically? I can't > think of any right now, but I remember having come across this at > some point. > I imagine that using the same approach (double semicolon to > explicitly indicate which package teh function is in) will work. > > Is there a simple way to check a function name and return which of > the loaded packages have a function with that name? And a list of > functions included in a given package? > This seems to be somewhat basic, but I don't think I've found *one* > place to refer to all these issues. If someone can suggest a good > place to find this information and better understand all the > package/namespace/reference (double semicolon qualifier) > nomenclature & structure, I'd be very grateful. > > Thank you everyone for their suggestions. > > Jose > > > Quoting Hervé Pagès <hpages at="" fhcrc.org=""> on Wed, 08 Jun 2011 12:55:20 > -0700: > >> Hi Jose, Steve, Tim, >> >> It seems to me that the more general question Jose is asking is how >> to unambiguously refer to an object when several objects with the >> same >> name are defined in several packages. >> >> One solution is to use the "fully qualified name" of the object i.e. >> to use a <pkgname>:: prefix. For example: >> >> BSgenome.Hsapiens.UCSC.hg18::Hsapiens >> BSgenome.Hsapiens.UCSC.hg19::Hsapiens >> >> For convenience, this can be combined with Steve's suggested >> reassignment to shorter names: >> >> hg18 <- BSgenome.Hsapiens.UCSC.hg18::Hsapiens >> hg19 <- BSgenome.Hsapiens.UCSC.hg19::Hsapiens >> >> By using the "fully qualified name", the result of this reassignment >> doesn't depend on the order the packages were loaded anymore. >> >> Cheers, >> H. >> >> >> On 11-06-07 02:06 PM, Tim Triche, Jr. wrote: >>> you're right, it's more of a general solution. I end up with >>> multiple >>> versions of annotation packages, multiple namespaces' worth of S4 >>> generics, >>> etc. floating around and it is a nice swiss army chainsaw (like >>> many of >>> Hadley's packages) with some remaining rough edges. The ability >>> to just >>> "find a bigger hammer" appeals to me, but a purposeful solution >>> is probably >>> better for the problem at hand. >>> >>> >>> On Tue, Jun 7, 2011 at 12:53 PM, Steve Lianoglou< >>> mailinglist.honeypot at gmail.com> wrote: >>> >>>> Hi, >>>> >>>> On Tue, Jun 7, 2011 at 2:34 PM, Tim Triche, >>>> Jr.<tim.triche at="" gmail.com=""> >>>> wrote: >>>>> One solution to the issue of managing packages in your R >>>>> namespace/environment is Hadley Wickham's devtools >>>>> package<https: github.com="" hadley="" devtools#readme="">. >>>>> I am surprised more people don't use it for this >>>> >>>> I actually tried using that a while ago in order to help make >>>> package >>>> development easier, but: >>>> >>>> (1) Isn't that more for being able to work with "source" >>>> packages w/o >>>> having to install them; and >>>> (2) as an aside, back then it had some problems with S4-isms (which >>>> may have been fixed by now) >>>> >>>> As with most all of Hadley's work -- I think devtools is (will be) >>>> great, but I don't quite see how that's the right tool for this >>>> job, >>>> though ... ? >>>> >>>> -steve >>>> >>>> -- >>>> Steve Lianoglou >>>> Graduate Student: Computational Systems Biology >>>> | Memorial Sloan-Kettering Cancer Center >>>> | Weill Medical College of Cornell University >>>> Contact Info: http://cbio.mskcc.org/~lianos/contact >>>> >>> >>> >>> >> >> >> -- >> Hervé Pagès >> >> Program in Computational Biology >> Division of Public Health Sciences >> Fred Hutchinson Cancer Research Center >> 1100 Fairview Ave. N, M1-B514 >> P.O. Box 19024 >> Seattle, WA 98109-1024 >> >> E-mail: hpages at fhcrc.org >> Phone: (206) 667-5791 >> Fax: (206) 667-1319 >> >> > > > > -- > Dr. Jose I. de las Heras Email: > J.delasHeras at ed.ac.uk > The Wellcome Trust Centre for Cell Biology Phone: +44 (0)131 > 6507090 > Institute for Cell & Molecular Biology Fax: +44 (0)131 > 6507360 > Swann Building, Mayfield Road > University of Edinburgh > Edinburgh EH9 3JR > UK > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/ > gmane.science.biology.informatics.conductor
ADD REPLY
0
Entering edit mode
thank you, I was not aware of ls() being able to return these data. Jose Quoting "Harris A. Jaffee" <hj at="" jhu.edu=""> on Thu, 9 Jun 2011 09:15:22 -0400: > This will get you started, but it's probably not the full answer. > > ? getAnywhere > ? ls > > For example, ls(2), but note that this contains more than just > functions, e.g. letters in base or IUPAC_CODE_MAP in Biostrings. > > On Jun 9, 2011, at 8:12 AM, J.delasHeras at ed.ac.uk wrote: > >> >> Hi Herve, >> >> this indeed was the issue I had, which works perfectly well by >> following Steve's suggestion: simply explicitly renaming objects to >> ensure one deals with the correct one. The idea of explicitly >> indicating the package using the double semicolon had escaped me >> too, so thank you for bringing it up. >> >> Another related matter would be: what happens when two packages use >> two different functions that are however named identically? I can't >> think of any right now, but I remember having come across this at >> some point. >> I imagine that using the same approach (double semicolon to >> explicitly indicate which package teh function is in) will work. >> >> Is there a simple way to check a function name and return which of >> the loaded packages have a function with that name? And a list of >> functions included in a given package? >> This seems to be somewhat basic, but I don't think I've found *one* >> place to refer to all these issues. If someone can suggest a good >> place to find this information and better understand all the >> package/namespace/reference (double semicolon qualifier) >> nomenclature & structure, I'd be very grateful. >> >> Thank you everyone for their suggestions. >> >> Jose >> >> >> Quoting Hervé Pagès <hpages at="" fhcrc.org=""> on Wed, 08 Jun 2011 12:55:20 -0700: >> >>> Hi Jose, Steve, Tim, >>> >>> It seems to me that the more general question Jose is asking is how >>> to unambiguously refer to an object when several objects with the same >>> name are defined in several packages. >>> >>> One solution is to use the "fully qualified name" of the object i.e. >>> to use a <pkgname>:: prefix. For example: >>> >>> BSgenome.Hsapiens.UCSC.hg18::Hsapiens >>> BSgenome.Hsapiens.UCSC.hg19::Hsapiens >>> >>> For convenience, this can be combined with Steve's suggested >>> reassignment to shorter names: >>> >>> hg18 <- BSgenome.Hsapiens.UCSC.hg18::Hsapiens >>> hg19 <- BSgenome.Hsapiens.UCSC.hg19::Hsapiens >>> >>> By using the "fully qualified name", the result of this reassignment >>> doesn't depend on the order the packages were loaded anymore. >>> >>> Cheers, >>> H. >>> >>> >>> On 11-06-07 02:06 PM, Tim Triche, Jr. wrote: >>>> you're right, it's more of a general solution. I end up with multiple >>>> versions of annotation packages, multiple namespaces' worth of S4 >>>> generics, >>>> etc. floating around and it is a nice swiss army chainsaw (like many of >>>> Hadley's packages) with some remaining rough edges. The ability to just >>>> "find a bigger hammer" appeals to me, but a purposeful solution >>>> is probably >>>> better for the problem at hand. >>>> >>>> >>>> On Tue, Jun 7, 2011 at 12:53 PM, Steve Lianoglou< >>>> mailinglist.honeypot at gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Tue, Jun 7, 2011 at 2:34 PM, Tim Triche, Jr.<tim.triche at="" gmail.com=""> >>>>> wrote: >>>>>> One solution to the issue of managing packages in your R >>>>>> namespace/environment is Hadley Wickham's devtools >>>>>> package<https: github.com="" hadley="" devtools#readme="">. >>>>>> I am surprised more people don't use it for this >>>>> >>>>> I actually tried using that a while ago in order to help make package >>>>> development easier, but: >>>>> >>>>> (1) Isn't that more for being able to work with "source" packages w/o >>>>> having to install them; and >>>>> (2) as an aside, back then it had some problems with S4-isms (which >>>>> may have been fixed by now) >>>>> >>>>> As with most all of Hadley's work -- I think devtools is (will be) >>>>> great, but I don't quite see how that's the right tool for this job, >>>>> though ... ? >>>>> >>>>> -steve >>>>> >>>>> -- >>>>> Steve Lianoglou >>>>> Graduate Student: Computational Systems Biology >>>>> | Memorial Sloan-Kettering Cancer Center >>>>> | Weill Medical College of Cornell University >>>>> Contact Info: http://cbio.mskcc.org/~lianos/contact >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Hervé Pagès >>> >>> Program in Computational Biology >>> Division of Public Health Sciences >>> Fred Hutchinson Cancer Research Center >>> 1100 Fairview Ave. N, M1-B514 >>> P.O. Box 19024 >>> Seattle, WA 98109-1024 >>> >>> E-mail: hpages at fhcrc.org >>> Phone: (206) 667-5791 >>> Fax: (206) 667-1319 >>> >>> >> >> >> >> -- >> Dr. Jose I. de las Heras Email: J.delasHeras at ed.ac.uk >> The Wellcome Trust Centre for Cell Biology Phone: +44 (0)131 6507090 >> Institute for Cell & Molecular Biology Fax: +44 (0)131 6507360 >> Swann Building, Mayfield Road >> University of Edinburgh >> Edinburgh EH9 3JR >> UK >> >> >> -- >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> _______________________________________________ >> Bioconductor mailing list >> Bioconductor at r-project.org >> https://stat.ethz.ch/mailman/listinfo/bioconductor >> Search the archives: >> http://news.gmane.org/gmane.science.biology.informatics.conductor > > > -- Dr. Jose I. de las Heras Email: J.delasHeras at ed.ac.uk The Wellcome Trust Centre for Cell Biology Phone: +44 (0)131 6507090 Institute for Cell & Molecular Biology Fax: +44 (0)131 6507360 Swann Building, Mayfield Road University of Edinburgh Edinburgh EH9 3JR UK -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
ADD REPLY
0
Entering edit mode
Herve and Steve have been doing this longer than I have, so I add this only for reference: Some functions live in a private namespace accessible via the triple semicolon, eg. library(crlmm) crlmm:::readIDAT something which is handy to know when such a function turns up in a debug trace. detach(package:crlmm, unload=TRUE, force=TRUE) is a brute force way to unload anything that got dragged in with a package, regardless of the fallout. Turning around and calling library(crlmm) would then, if you had reinstalled the package in the meanwhile, load everything anew. Just a couple funfacts about package namespaces, from personal experience... --t On Thu, Jun 9, 2011 at 9:00 AM, <j.delasheras@ed.ac.uk> wrote: > > thank you, I was not aware of ls() being able to return these data. > > Jose > > > > Quoting "Harris A. Jaffee" <hj@jhu.edu> on Thu, 9 Jun 2011 09:15:22 -0400: > > This will get you started, but it's probably not the full answer. >> >> ? getAnywhere >> ? ls >> >> For example, ls(2), but note that this contains more than just >> functions, e.g. letters in base or IUPAC_CODE_MAP in Biostrings. >> >> On Jun 9, 2011, at 8:12 AM, J.delasHeras@ed.ac.uk wrote: >> >> >>> Hi Herve, >>> >>> this indeed was the issue I had, which works perfectly well by following >>> Steve's suggestion: simply explicitly renaming objects to ensure one deals >>> with the correct one. The idea of explicitly indicating the package using >>> the double semicolon had escaped me too, so thank you for bringing it up. >>> >>> Another related matter would be: what happens when two packages use two >>> different functions that are however named identically? I can't think of any >>> right now, but I remember having come across this at some point. >>> I imagine that using the same approach (double semicolon to explicitly >>> indicate which package teh function is in) will work. >>> >>> Is there a simple way to check a function name and return which of the >>> loaded packages have a function with that name? And a list of functions >>> included in a given package? >>> This seems to be somewhat basic, but I don't think I've found *one* place >>> to refer to all these issues. If someone can suggest a good place to find >>> this information and better understand all the package/namespace/reference >>> (double semicolon qualifier) nomenclature & structure, I'd be very grateful. >>> >>> Thank you everyone for their suggestions. >>> >>> Jose >>> >>> >>> Quoting Hervé Pagès <hpages@fhcrc.org> on Wed, 08 Jun 2011 12:55:20 >>> -0700: >>> >>> Hi Jose, Steve, Tim, >>>> >>>> It seems to me that the more general question Jose is asking is how >>>> to unambiguously refer to an object when several objects with the same >>>> name are defined in several packages. >>>> >>>> One solution is to use the "fully qualified name" of the object i.e. >>>> to use a <pkgname>:: prefix. For example: >>>> >>>> BSgenome.Hsapiens.UCSC.hg18::Hsapiens >>>> BSgenome.Hsapiens.UCSC.hg19::Hsapiens >>>> >>>> For convenience, this can be combined with Steve's suggested >>>> reassignment to shorter names: >>>> >>>> hg18 <- BSgenome.Hsapiens.UCSC.hg18::Hsapiens >>>> hg19 <- BSgenome.Hsapiens.UCSC.hg19::Hsapiens >>>> >>>> By using the "fully qualified name", the result of this reassignment >>>> doesn't depend on the order the packages were loaded anymore. >>>> >>>> Cheers, >>>> H. >>>> >>>> >>>> On 11-06-07 02:06 PM, Tim Triche, Jr. wrote: >>>> >>>>> you're right, it's more of a general solution. I end up with multiple >>>>> versions of annotation packages, multiple namespaces' worth of S4 >>>>> generics, >>>>> etc. floating around and it is a nice swiss army chainsaw (like many of >>>>> Hadley's packages) with some remaining rough edges. The ability to >>>>> just >>>>> "find a bigger hammer" appeals to me, but a purposeful solution is >>>>> probably >>>>> better for the problem at hand. >>>>> >>>>> >>>>> On Tue, Jun 7, 2011 at 12:53 PM, Steve Lianoglou< >>>>> mailinglist.honeypot@gmail.com> wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> On Tue, Jun 7, 2011 at 2:34 PM, Tim Triche, Jr.<tim.triche@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> One solution to the issue of managing packages in your R >>>>>>> namespace/environment is Hadley Wickham's devtools >>>>>>> package<https: github.com="" hadley="" devtools#readme="">. >>>>>>> I am surprised more people don't use it for this >>>>>>> >>>>>> >>>>>> I actually tried using that a while ago in order to help make package >>>>>> development easier, but: >>>>>> >>>>>> (1) Isn't that more for being able to work with "source" packages w/o >>>>>> having to install them; and >>>>>> (2) as an aside, back then it had some problems with S4-isms (which >>>>>> may have been fixed by now) >>>>>> >>>>>> As with most all of Hadley's work -- I think devtools is (will be) >>>>>> great, but I don't quite see how that's the right tool for this job, >>>>>> though ... ? >>>>>> >>>>>> -steve >>>>>> >>>>>> -- >>>>>> Steve Lianoglou >>>>>> Graduate Student: Computational Systems Biology >>>>>> | Memorial Sloan-Kettering Cancer Center >>>>>> | Weill Medical College of Cornell University >>>>>> Contact Info: http://cbio.mskcc.org/~lianos/contact >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Hervé Pagès >>>> >>>> Program in Computational Biology >>>> Division of Public Health Sciences >>>> Fred Hutchinson Cancer Research Center >>>> 1100 Fairview Ave. N, M1-B514 >>>> P.O. Box 19024 >>>> Seattle, WA 98109-1024 >>>> >>>> E-mail: hpages@fhcrc.org >>>> Phone: (206) 667-5791 >>>> Fax: (206) 667-1319 >>>> >>>> >>>> >>> >>> >>> -- >>> Dr. Jose I. de las Heras Email: >>> J.delasHeras@ed.ac.uk >>> The Wellcome Trust Centre for Cell Biology Phone: +44 (0)131 6507090 >>> Institute for Cell & Molecular Biology Fax: +44 (0)131 6507360 >>> Swann Building, Mayfield Road >>> University of Edinburgh >>> Edinburgh EH9 3JR >>> UK >>> >>> >>> -- >>> The University of Edinburgh is a charitable body, registered in >>> Scotland, with registration number SC005336. >>> >>> _______________________________________________ >>> Bioconductor mailing list >>> Bioconductor@r-project.org >>> https://stat.ethz.ch/mailman/listinfo/bioconductor >>> Search the archives: >>> http://news.gmane.org/gmane.science.biology.informatics.conductor >>> >> >> >> >> > > > -- > Dr. Jose I. de las Heras Email: J.delasHeras@ed.ac.uk > The Wellcome Trust Centre for Cell Biology Phone: +44 (0)131 6507090 > Institute for Cell & Molecular Biology Fax: +44 (0)131 6507360 > Swann Building, Mayfield Road > University of Edinburgh > Edinburgh EH9 3JR > UK > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > Bioconductor mailing list > Bioconductor@r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: > http://news.gmane.org/gmane.science.biology.informatics.conductor > -- If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is. John von Neumann<http: www-groups.dcs.st-="" and.ac.uk="" ~history="" biographies="" von_neumann.html=""> [[alternative HTML version deleted]]
ADD REPLY

Login before adding your answer.

Traffic: 448 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