Entering edit mode
Frederic Fournier
▴
40
@frederic-fournier-5663
Last seen 10.2 years ago
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]]