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 <[email protected]>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 < > [email protected]> wrote: > >> Hi, >> >> On Wed, Mar 6, 2013 at 10:47 PM, Victor Kryukov >> <[email protected]> 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 >> > >
_______________________________________________ datatable-help mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
