<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body>
<p> </p>
<p>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...</p>
<p>Just to check, you know you can poke around the source (updated in real time) online too :</p>
<p><a href="https://r-forge.r-project.org/scm/viewvc.php/?root=datatable">https://r-forge.r-project.org/scm/viewvc.php/?root=datatable</a></p>
<p> </p>
<p>Not as pretty as github but just checking you know you can browse there.</p>
<p>Matthew</p>
<p> </p>
<p>On 07.03.2013 17:25, Victor Kryukov wrote:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div dir="ltr">
<div>
<div>OK, I think I have solved it. The problem seemed to be related to FAQ 2.23.<br /><br /></div>
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.<br /><br /></div>
Now my depends section in DESCRIPTION looks like this:<br /><br />Depends:<br /> data.table,<br /> lubridate<br /><br />
<div>
<div>
<div>
<div>
<div class="gmail_extra">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.<br /><br /></div>
<div class="gmail_extra">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...<br /><br /></div>
<div class="gmail_extra">Regards,<br />Victor</div>
<div class="gmail_extra"><br />
<div class="gmail_quote">On Thu, Mar 7, 2013 at 12:55 AM, Matthew Dowle <span><<a href="mailto:mdowle@mdowle.plus.com">mdowle@mdowle.plus.com</a>></span> wrote:<br />
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb; padding-left: 1ex;"><br /> Victor,<br /><br /> As Steve says you shouldn't need to do that.<br /><br /> If it's just the mask warnings you're trying to suppress have you tried :<br /><br /> suppressPackageStartupMessages<span style="text-decoration: underline;"></span>({<br /> library(...)<br /> library(...)<br /> })<br /><br /> I haven't used lubdridate before. I tried :<br /><br />
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb; padding-left: 1ex;">install.packages("lubdridate")</blockquote>
Warning message:<br /> package ‘lubdridate’ is not available (for R version 2.15.3)<br /><br /> 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.<span><span style="color: #888888;"><br /><br /> Matthew</span></span>
<div>
<div><br /><br /><br /> On 07.03.2013 05:40, Steve Lianoglou wrote:<br />
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb; padding-left: 1ex;">Hi,<br /><br /> On Thu, Mar 7, 2013 at 12:22 AM, Victor Kryukov<br /> <<a href="mailto:victor.kryukov@gmail.com">victor.kryukov@gmail.com</a>> wrote:<br />
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb; padding-left: 1ex;">Update: it looks the order in NAMESPACE doesn't matter for that particular<br /> problem. I can confirm that when I change it the order of package loading<br /> changes, as it's either data.table or lubridate that warns about<br /> overwritting each other's functions, but the problem exists in either case.<br /><br /> I think my next steps will be to perform a surgery on data.table by removing<br /> all IDateTime from my local copy - will see if it helps :).</blockquote>
<br /> It's your prerogative to do what you like, but I feel like the other<br /> two alternatives I gave are a bit less intense than what you are<br /> proposing, no?<br /><br /> It also has the bonus feature of not requiring a non-standard<br /> data.table install, which is good if you expect anybody else to use<br /> your package.<br /><br /> -steve</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p> </p>
<div> </div>
</body></html>