Sorry, I meant to send my earlier answer to the mailing list too. Here it is: ---------- Forwarded message ---------- From: Frederic Fournier <frederic.bioinfo@gmail.com> Date: Wed, Dec 19, 2012 at 2:23 PM Hello Steve, Thank you very much for taking the time to look at the package! I agree that data.table is a great little package. The hack that you mention is not necessary to make anything work, but it serves to prevent a note from the R check mechanism. (I guess that I could live with this note, but I would rather have a clean and lean check report, so that real problems can be noticed right away.) The thing that could trigger this note with data.table is that it has a modified [ accessor where, according to their documentation, the argument "is an expression evaluated within the scope of the data.table". So it is possible to do that: DT <- data.table("col1"=c(1:5), "col2"=c(6:10)) DT[,col1] #returns 1 2 3 4 5 Note that the second line uses col1 without any quotes, so the second line use the object/variable col1 even though no value has been explicitly bound to this variable. A check mechanism applied on this code should notice that a variable is used even though it has not been explicitly bound to any value, and warn us about it. This is what R CHECK does. Same thing could happen with other functions that have an evaluation mechanism under the hood (like the 'help' function). I'm not sure how problematic this is, or if it warrants a correction of data.table. What do you think? Do you know a cleaner way of using all the possibilities of the data.table [ accessor without raising r-check's notes? Thanks again for looking at this new package and giving your input! Best, Frederic On Wed, Dec 19, 2012 at 2:23 PM, Frederic Fournier < frederic.bioinfo@gmail.com> wrote: > Hello Steve, > > Thank you very much for taking the time to look at the package! > > I agree that data.table is a great little package. The hack that you > mention is not necessary to make anything work, but it serves to prevent a > note from the R check mechanism. (I guess that I could live with this note, > but I would rather have a clean and lean check report, so that real > problems can be noticed right away.) > > The thing that could trigger this note with data.table is that it has a > modified [ accessor where, according to their documentation, the argument > "is an expression evaluated within the scope of the data.table". > So it is possible to do that: > > DT <- data.table("col1"=c(1:5), "col2"=c(6:10)) > DT[,col1] #returns 1 2 3 4 5 > > Note that the second line uses col1 without any quotes, so the second line > use the object/variable col1 even though no value has been explicitly bound > to this variable. A check mechanism applied on this code should notice that > a variable is used even though it has not been explicitly bound to any > value, and warn us about it. This is what R CHECK does. > > Same thing could happen with other functions that have an evaluation > mechanism under the hood (like the 'help' function). > > I'm not sure how problematic this is, or if it warrants a correction of > data.table. What do you think? > Do you know a cleaner way of using all the possibilities of the data.table > [ accessor without raising r-check's notes? > > Thanks again for looking at this new package and giving your input! > > Best, > > Frederic > > > > > On 12-12-19 11:32 AM, Steve Lianoglou wrote: > >> Hi Frederic, >> >> On Wed, Dec 19, 2012 at 10:36 AM, Frederic Fournier >> <frederic.bioinfo@gmail.com> wrote: >> >>> Dear Bioconductor users, >>> >>> I would like to announce the release of the new package rTANDEM on >>> bioconductor. >>> This package encapsulates the mass spectrometry indentification algorithm >>> X!Tandem in R, making it possible to conduct a full ms-ms analysis in R >>> and >>> to use R datamining capacities to search the results. We hope that >>> rTANDEM >>> can become the center of a viable pipeline for ms-ms proteomics in R. >>> >>> Questions, suggestions, bug-reports, and feedback of any kind is more >>> than >>> welcome. >>> >> Really cool! >> >> Thanks for putting this together ... I checked out the source code to >> skim the package and notice that you use data.table (good choice :-) I >> see, however, that you felt that you needed to resort to some hacks to >> get it to work correctly, for instance in `GetPeptides`, you have: >> >> ## Dummy declaration to prevent "no visible binding" note when using >> data.table subset: >> pep.id=prot.uid=uid=NULL >> rmpep.id, prot.uid, uid) >> ... >> >> But this shouldn't be necessary, so if there's a problem in data.table >> I'd like to fix it. >> >> I'm curious if you list data.table in your "Imports" field in your >> DESCRIPTION file, then `import(data.table)` in your NAMESPACE, is this >> still necessary? >> >> I don't think I've run into this problem before, so I'm hoping these >> small changes should do the trick. >> >> HTH, >> -steve >> > > [[alternative HTML version deleted]]