[datatable-help] Error in a package that imports data.table

[Victor Kryukov]

Update: it looks the order in NAMESPACE doesn't matter for that particular
problem. I can confirm that when I change it the order of package loading
changes, as it's either data.table or lubridate that warns about
overwritting each other's functions, but the problem exists in either case.

I think my next steps will be to perform a surgery on data.table by
removing all IDateTime from my local copy - will see if it helps :).

On Wed, Mar 6, 2013 at 8:16 PM, Victor Kryukov <victor.kryukov at gmail.com>wrote:

> Thanks Steve. That's a good suggestion regarding the order or fully
> specifying lubridate names.
>
> I actually downloaded data.table code and looked through it, and unless
> I'm missing something, IDateTime is totally separate from everything else.
> At least if you search for 'IDate' or 'hour' or 'minute', you don't find
> them mentioned in other .R or .c files besides IDateTime.R
>
> And yes - lubridate IS mentioned in IDateTime.R code :)
>
> ###################################################################
> # Date - time extraction functions
> #   Adapted from Hadley Wickham's routines cited below to ensure
> #   integer results.
> #     http://gist.github.com/10238
> #   See also Hadley's more advanced and complex lubridate package:
> #     http://github.com/hadley/lubridate
> #   lubridate routines do not return integer values.
> ###################################################################
>
>
> On Wed, Mar 6, 2013 at 8:09 PM, Steve Lianoglou <
> mailinglist.honeypot at gmail.com> wrote:
>
>> Hi,
>>
>> On Wed, Mar 6, 2013 at 10:47 PM, Victor Kryukov
>> <victor.kryukov at gmail.com> wrote:
>> [snip]
>> > I'm puzzled about why data table would include this function/classes
>> (isn't
>> > it better to leave data handling to specialized classes?), but I
>> understand
>> > that there may be a good reason for that.
>>
>> I became a data.table user after IDateTime was in there (and I don't
>> ever use it, actually), but my *guess* would be that it's there to use
>> dates as keys for data.table ...
>>
>> > Unfortunately, my code is using
>> > lubridate heavily (it's just too good...), which leaves me in a tough
>> spot -
>> > I would like to use both. If I had to choose, I would be forced to
>> replace
>> > all lubridate code with standard R, which is not fun, but I guess I
>> have to
>> > bite the bullet.
>>
>> You don't have to choose one over the other.
>>
>> I suspect import order could do the trick. Perhaps import()-ing
>> data.table first, then lubridate might be all you have to do.
>>
>> If not, I *think* if you define hour, mday, mont, etc. in your package
>> code as:
>>
>> mday <- lubridate::mday
>> hour <- lubridate::hour
>>
>> And ensure that those functions are loaded first (either by using
>> Collate: and specifying that file first, or putting that in a function
>> called aaa.R or something), perhaps your code will recover "just like
>> that"
>>
>> If that doesn't work either, another option is that  you just prefix
>> every lubridate call in your package code with the lubridate package
>> name, eg. instead of `year(whenever)` you do
>> `lubridate::year(whenever)`.
>>
>> HTH,
>> -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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/datatable-help/attachments/20130306/0cac1c74/attachment.html>