Interesting, thanks for update. That's news to me. But then how do the datatable options get set if it's just Imported ? .onLoad sets those options too. Does any other function get run when a package is imported. Is there a .onImport ? That can't be right, otherwise how do datatable options get set for the 3 packages on CRAN that Import data.table? Hm...
Just to check, you know you can poke around the source (updated in real time) online too : https://r-forge.r-project.org/scm/viewvc.php/?root=datatable [3] Not as pretty as github but just checking you know you can browse there. Matthew On 07.03.2013 17:25, Victor Kryukov wrote: > OK, I think I have solved it. The problem seemed to be related to FAQ 2.23. > > When I was *importing* data.table with 'Imports:', I think what was going on is that R was making functions from data.table's namespace available to my package, but the data.table package itself was not loaded. As a consequence, .onLoad was never called and hense FAQ 2.23's magic never happened. > > Now my depends section in DESCRIPTION looks like this: > > Depends: > data.table, > lubridate > > and everything seems to work - no error messages about .rbind.data.table not available, and lubridate's hour, minute etc. mask data.table's, which is what expected. The order does matter in that case. > > Thanks for Matthew and Steve for providing support. At least I had a reason to downloaded data.table and poke around its sources; wish it was available on github... > > Regards, > Victor > > On Thu, Mar 7, 2013 at 12:55 AM, Matthew Dowle <[email protected] [2]> wrote: > >> Victor, >> >> As Steve says you shouldn't need to do that. >> >> If it's just the mask warnings you're trying to suppress have you tried : >> >> suppressPackageStartupMessages({ >> library(...) >> library(...) >> }) >> >> I haven't used lubdridate before. I tried : >> >>> install.packages("lubdridate") >> Warning message: >> package 'lubdridate' is not available (for R version 2.15.3) >> >> Seems odd. Anyway: is lubridate fast? As the code comment you pasted said, it stores Date as numeric (type double) doesn't it, as base R does? Won't that mean sorting won't be as fast on it? That's the reason IDate exists and what the I stands for. >> >> Matthew >> >> On 07.03.2013 05:40, Steve Lianoglou wrote: >> >>> Hi, >>> >>> On Thu, Mar 7, 2013 at 12:22 AM, Victor Kryukov >>> <[email protected] [1]> wrote: >>> >>>> 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 :). >>> >>> It's your prerogative to do what you like, but I feel like the other >>> two alternatives I gave are a bit less intense than what you are >>> proposing, no? >>> >>> It also has the bonus feature of not requiring a non-standard >>> data.table install, which is good if you expect anybody else to use >>> your package. >>> >>> -steve Links: ------ [1] mailto:[email protected] [2] mailto:[email protected] [3] https://r-forge.r-project.org/scm/viewvc.php/?root=datatable
_______________________________________________ datatable-help mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
