Discussion:
Error in a package that imports data.table
(too old to reply)
Victor Kryukov
2013-03-03 22:25:52 UTC
Permalink
Hello,

I'm developing an R package which will be used internally at my company, and I have troubles using data.table. I'm very new to package development and I'm not really sure whether the errors I see are related to data.table or not, but here it is anyway.

I have a function that imports data from .csv files and cleans the data (subsets, converting fields to numeric etc.). As the end of the function definition, I convert the resulting data.frame to data.table and return the result:

ProcessData <- function(…) {
...
df <- data.table(df)
df
}

When I use this function standalone, after

library(data.package)

everything works as expected. However, when I'm defining this function as a part of a package and later call it, I'm getting the following error:

Error in rbind(deparse.level, ...) :
could not find function ".rbind.data.table"

Please note that in the package .R files, I'm not importing data.table directly with library(data.package) but rather have `import(data.table)` statement in my NAMESPACE, as recommended here https://github.com/hadley/devtools/wiki/Namespaces.

When I import data.table directly with library(data.table) after importing my package, everything works as expected.

I suspect there may be something going wrong with namespaces in data.table.

My environment: I'm using R 2.15.3 on Mac and have tested the above on both data.table 1.8.6 and 1.8.7. Please let me know if I need to provide more info. Any help will be much appreciated!

Regards,
Victor
Matthew Dowle
2013-03-03 23:26:30 UTC
Permalink
Hi,

Did you include data.table in either the Imports or Depends field of
your package's DESCRIPTION file?

I've just improved data.table FAQ 6.9 to make that clearer.

If it still doesn't work, does your package fully pass "R CMD check"?

Matthew
Post by Victor Kryukov
Hello,
I'm developing an R package which will be used internally at my
company, and I have troubles using data.table. I'm very new to
package
development and I'm not really sure whether the errors I see are
related to data.table or not, but here it is anyway.
I have a function that imports data from .csv files and cleans the
data (subsets, converting fields to numeric etc.). As the end of the
function definition, I convert the resulting data.frame to data.table
ProcessData <- function(…) {
...
df <- data.table(df)
df
}
When I use this function standalone, after
library(data.package)
everything works as expected. However, when I'm defining this
function as a part of a package and later call it, I'm getting the
could not find function ".rbind.data.table"
Please note that in the package .R files, I'm not importing
data.table directly with library(data.package) but rather have
`import(data.table)` statement in my NAMESPACE, as recommended here
https://github.com/hadley/devtools/wiki/Namespaces.
When I import data.table directly with library(data.table) after
importing my package, everything works as expected.
I suspect there may be something going wrong with namespaces in data.table.
My environment: I'm using R 2.15.3 on Mac and have tested the above
on both data.table 1.8.6 and 1.8.7. Please let me know if I need to
provide more info. Any help will be much appreciated!
Regards,
Victor
_______________________________________________
datatable-help mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
Victor Kryukov
2013-03-04 06:32:36 UTC
Permalink
Hi Matthew,

my DESCRIPTION file has the following section:

Imports:
data.table,
lubridate

and my (generated) NAMESPACE contains

export(ProcessTransactionSurvey)
import(data.table)
import(lubridate)

My R CMD CHECK (run with check() from devtools) mostly runs OK but fails at the end with the following error, which is expected since I haven't created any documentation yet. I'm not sure yet have to fix this LaTeX warning (I do have latex installed on my machine).

* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
LaTeX errors found:
* checking PDF version of manual without hyperrefs or index ... ERROR
Error: Command failed (1)

Anything else I should check?

Victor
Hi,
Did you include data.table in either the Imports or Depends field of your package's DESCRIPTION file?
I've just improved data.table FAQ 6.9 to make that clearer.
If it still doesn't work, does your package fully pass "R CMD check"?
Matthew
Post by Victor Kryukov
Hello,
I'm developing an R package which will be used internally at my
company, and I have troubles using data.table. I'm very new to package
development and I'm not really sure whether the errors I see are
related to data.table or not, but here it is anyway.
I have a function that imports data from .csv files and cleans the
data (subsets, converting fields to numeric etc.). As the end of the
function definition, I convert the resulting data.frame to data.table
ProcessData <- function(…) {
...
df <- data.table(df)
df
}
When I use this function standalone, after
library(data.package)
everything works as expected. However, when I'm defining this
function as a part of a package and later call it, I'm getting the
could not find function ".rbind.data.table"
Please note that in the package .R files, I'm not importing
data.table directly with library(data.package) but rather have
`import(data.table)` statement in my NAMESPACE, as recommended here
https://github.com/hadley/devtools/wiki/Namespaces.
When I import data.table directly with library(data.table) after
importing my package, everything works as expected.
I suspect there may be something going wrong with namespaces in data.table.
My environment: I'm using R 2.15.3 on Mac and have tested the above
on both data.table 1.8.6 and 1.8.7. Please let me know if I need to
provide more info. Any help will be much appreciated!
Regards,
Victor
_______________________________________________
datatable-help mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
Matthew Dowle
2013-03-04 07:35:15 UTC
Permalink
Hi,

I don't see what's wrong then.

Can you whittle the package down to the essential code such that you
can attach it and we can reproduce?

Thanks,
Matthew
Post by Victor Kryukov
Hi Matthew,
data.table,
lubridate
and my (generated) NAMESPACE contains
export(ProcessTransactionSurvey)
import(data.table)
import(lubridate)
My R CMD CHECK (run with check() from devtools) mostly runs OK but
fails at the end with the following error, which is expected since I
haven't created any documentation yet. I'm not sure yet have to fix
this LaTeX warning (I do have latex installed on my machine).
* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
* checking PDF version of manual without hyperrefs or index ... ERROR
Error: Command failed (1)
Anything else I should check?
Victor
Post by Matthew Dowle
Hi,
Did you include data.table in either the Imports or Depends field of
your package's DESCRIPTION file?
I've just improved data.table FAQ 6.9 to make that clearer.
If it still doesn't work, does your package fully pass "R CMD
check"?
Matthew
Post by Victor Kryukov
Hello,
I'm developing an R package which will be used internally at my
company, and I have troubles using data.table. I'm very new to package
development and I'm not really sure whether the errors I see are
related to data.table or not, but here it is anyway.
I have a function that imports data from .csv files and cleans the
data (subsets, converting fields to numeric etc.). As the end of the
function definition, I convert the resulting data.frame to
data.table
ProcessData <- function(…) {
...
df <- data.table(df)
df
}
When I use this function standalone, after
library(data.package)
everything works as expected. However, when I'm defining this
function as a part of a package and later call it, I'm getting the
could not find function ".rbind.data.table"
Please note that in the package .R files, I'm not importing
data.table directly with library(data.package) but rather have
`import(data.table)` statement in my NAMESPACE, as recommended here
https://github.com/hadley/devtools/wiki/Namespaces.
When I import data.table directly with library(data.table) after
importing my package, everything works as expected.
I suspect there may be something going wrong with namespaces in data.table.
My environment: I'm using R 2.15.3 on Mac and have tested the above
on both data.table 1.8.6 and 1.8.7. Please let me know if I need to
provide more info. Any help will be much appreciated!
Regards,
Victor
_______________________________________________
datatable-help mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
_______________________________________________
datatable-help mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
Steve Lianoglou
2013-03-04 21:39:22 UTC
Permalink
I'm not sure if order matters in the NAMESPACE, but maybe you could
try to write it manually and put the import statements up top?

I haven't come across this problem, and I've got several packages that
use data.table via importing it as you show here ...
Post by Matthew Dowle
Hi,
I don't see what's wrong then.
Can you whittle the package down to the essential code such that you can
attach it and we can reproduce?
Thanks,
Matthew
Post by Victor Kryukov
Hi Matthew,
data.table,
lubridate
and my (generated) NAMESPACE contains
export(ProcessTransactionSurvey)
import(data.table)
import(lubridate)
My R CMD CHECK (run with check() from devtools) mostly runs OK but
fails at the end with the following error, which is expected since I
haven't created any documentation yet. I'm not sure yet have to fix
this LaTeX warning (I do have latex installed on my machine).
* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
* checking PDF version of manual without hyperrefs or index ... ERROR
Error: Command failed (1)
Anything else I should check?
Victor
Hi,
Did you include data.table in either the Imports or Depends field of your
package's DESCRIPTION file?
I've just improved data.table FAQ 6.9 to make that clearer.
If it still doesn't work, does your package fully pass "R CMD check"?
Matthew
Post by Victor Kryukov
Hello,
I'm developing an R package which will be used internally at my
company, and I have troubles using data.table. I'm very new to package
development and I'm not really sure whether the errors I see are
related to data.table or not, but here it is anyway.
I have a function that imports data from .csv files and cleans the
data (subsets, converting fields to numeric etc.). As the end of the
function definition, I convert the resulting data.frame to data.table
ProcessData <- function(…) {
...
df <- data.table(df)
df
}
When I use this function standalone, after
library(data.package)
everything works as expected. However, when I'm defining this
function as a part of a package and later call it, I'm getting the
could not find function ".rbind.data.table"
Please note that in the package .R files, I'm not importing
data.table directly with library(data.package) but rather have
`import(data.table)` statement in my NAMESPACE, as recommended here
https://github.com/hadley/devtools/wiki/Namespaces.
When I import data.table directly with library(data.table) after
importing my package, everything works as expected.
I suspect there may be something going wrong with namespaces in data.table.
My environment: I'm using R 2.15.3 on Mac and have tested the above
on both data.table 1.8.6 and 1.8.7. Please let me know if I need to
provide more info. Any help will be much appreciated!
Regards,
Victor
_______________________________________________
datatable-help mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
_______________________________________________
datatable-help mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
_______________________________________________
datatable-help mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
--
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
Victor Kryukov
2013-03-07 03:47:18 UTC
Permalink
Hello everyone, and thanks for your replys.

It looks like the problem was in my use of lubridate with datatable.
Removing lubridate from imports fixes it.

Every time I import *both* of these packages in R session, I get the
library(lubridate)
library(data.table)
data.table 1.8.8 For help type: help("data.table")

Attaching package: ‘data.table’

The following object(s) are masked from ‘package:lubridate’:

hour, mday, month, quarter, wday, week, yday, year

I haven't really paid attention to it, but now that I started
investigating, I noticed that data.table also defines all this function as
helpers to work with IDateTime. So there should be a name conflict
somewhere.

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. 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.

Regards,
Victor

Yours Sincerely,
Victor Kryukov

US cell: +1-650-733-6510


On Mon, Mar 4, 2013 at 1:39 PM, Steve Lianoglou <
I'm not sure if order matters in the NAMESPACE, but maybe you could
try to write it manually and put the import statements up top?
I haven't come across this problem, and I've got several packages that
use data.table via importing it as you show here ...
Post by Matthew Dowle
Hi,
I don't see what's wrong then.
Can you whittle the package down to the essential code such that you can
attach it and we can reproduce?
Thanks,
Matthew
Post by Victor Kryukov
Hi Matthew,
data.table,
lubridate
and my (generated) NAMESPACE contains
export(ProcessTransactionSurvey)
import(data.table)
import(lubridate)
My R CMD CHECK (run with check() from devtools) mostly runs OK but
fails at the end with the following error, which is expected since I
haven't created any documentation yet. I'm not sure yet have to fix
this LaTeX warning (I do have latex installed on my machine).
* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
* checking PDF version of manual without hyperrefs or index ... ERROR
Error: Command failed (1)
Anything else I should check?
Victor
Post by Matthew Dowle
Hi,
Did you include data.table in either the Imports or Depends field of
your
Post by Matthew Dowle
Post by Victor Kryukov
Post by Matthew Dowle
package's DESCRIPTION file?
I've just improved data.table FAQ 6.9 to make that clearer.
If it still doesn't work, does your package fully pass "R CMD check"?
Matthew
Post by Victor Kryukov
Hello,
I'm developing an R package which will be used internally at my
company, and I have troubles using data.table. I'm very new to package
development and I'm not really sure whether the errors I see are
related to data.table or not, but here it is anyway.
I have a function that imports data from .csv files and cleans the
data (subsets, converting fields to numeric etc.). As the end of the
function definition, I convert the resulting data.frame to data.table
ProcessData <- function(…) {
...
df <- data.table(df)
df
}
When I use this function standalone, after
library(data.package)
everything works as expected. However, when I'm defining this
function as a part of a package and later call it, I'm getting the
could not find function ".rbind.data.table"
Please note that in the package .R files, I'm not importing
data.table directly with library(data.package) but rather have
`import(data.table)` statement in my NAMESPACE, as recommended here
https://github.com/hadley/devtools/wiki/Namespaces.
When I import data.table directly with library(data.table) after
importing my package, everything works as expected.
I suspect there may be something going wrong with namespaces in data.table.
My environment: I'm using R 2.15.3 on Mac and have tested the above
on both data.table 1.8.6 and 1.8.7. Please let me know if I need to
provide more info. Any help will be much appreciated!
Regards,
Victor
_______________________________________________
datatable-help mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
Post by Matthew Dowle
Post by Victor Kryukov
_______________________________________________
datatable-help mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
Post by Matthew Dowle
_______________________________________________
datatable-help mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
--
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
Steve Lianoglou
2013-03-07 04:09:29 UTC
Permalink
Hi,

On Wed, Mar 6, 2013 at 10:47 PM, Victor Kryukov
<***@gmail.com> wrote:
[snip]
Post by Victor Kryukov
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 ...
Post by Victor Kryukov
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
Victor Kryukov
2013-03-07 04:16:33 UTC
Permalink
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 <
Post by Steve Lianoglou
Hi,
On Wed, Mar 6, 2013 at 10:47 PM, Victor Kryukov
[snip]
Post by Victor Kryukov
I'm puzzled about why data table would include this function/classes
(isn't
Post by Victor Kryukov
it better to leave data handling to specialized classes?), but I
understand
Post by Victor Kryukov
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 ...
Post by Victor Kryukov
Unfortunately, my code is using
lubridate heavily (it's just too good...), which leaves me in a tough
spot -
Post by Victor Kryukov
I would like to use both. If I had to choose, I would be forced to
replace
Post by Victor Kryukov
all lubridate code with standard R, which is not fun, but I guess I have
to
Post by Victor Kryukov
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.
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
Victor Kryukov
2013-03-07 05:22:08 UTC
Permalink
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 :).
Post by Victor Kryukov
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
# http://github.com/hadley/lubridate
# lubridate routines do not return integer values.
###################################################################
On Wed, Mar 6, 2013 at 8:09 PM, Steve Lianoglou <
Post by Steve Lianoglou
Hi,
On Wed, Mar 6, 2013 at 10:47 PM, Victor Kryukov
[snip]
Post by Victor Kryukov
I'm puzzled about why data table would include this function/classes
(isn't
Post by Victor Kryukov
it better to leave data handling to specialized classes?), but I
understand
Post by Victor Kryukov
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 ...
Post by Victor Kryukov
Unfortunately, my code is using
lubridate heavily (it's just too good...), which leaves me in a tough
spot -
Post by Victor Kryukov
I would like to use both. If I had to choose, I would be forced to
replace
Post by Victor Kryukov
all lubridate code with standard R, which is not fun, but I guess I
have to
Post by Victor Kryukov
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.
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
Steve Lianoglou
2013-03-07 05:40:11 UTC
Permalink
Hi,

On Thu, Mar 7, 2013 at 12:22 AM, Victor Kryukov
Post by 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 :).
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
--
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
Matthew Dowle
2013-03-07 08:55:25 UTC
Permalink
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(...)
})
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
Hi,
On Thu, Mar 7, 2013 at 12:22 AM, Victor Kryukov
Post by 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 :).
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
statquant3
2013-03-07 12:49:51 UTC
Permalink
Hello,
I do not think lubridate is fast, It just acts as a syntax sweetener.

Here is the description of the package by its author :
Quote:
Lubridate makes it easier to work with dates and times by
providing functions to identify and parse date-time data,extract and modify
components of a datetime
(years, months,days, hours, minutes, and seconds), perform accurate math on
date-times, handle time zones and Daylight Savings Time.
Lubridate has a consistent, memorable syntax, that makes
working with dates fun instead of frustrating.

As far as I know no package provide a quickest datetime handle, even if
data.table proposes IDate, ITime... that stores integer for fast sorting.
(Problem is for me that it does not support sub-second but we spoke about it
already)

If any package provides a faster implementation for datetimes I'll be glag
to hear about it.



--
View this message in context: http://r.789695.n4.nabble.com/Error-in-a-package-that-imports-data-table-tp4660173p4660598.html
Sent from the datatable-help mailing list archive at Nabble.com.
Victor Kryukov
2013-03-07 17:25:31 UTC
Permalink
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
Post by Matthew Dowle
Victor,
As Steve says you shouldn't need to do that.
suppressPackageStartupMessages**({
library(...)
library(...)
})
install.packages("lubdridate")
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
Post by Steve Lianoglou
Hi,
On Thu, Mar 7, 2013 at 12:22 AM, Victor Kryukov
Post by 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 :).
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
Matthew Dowle
2013-03-07 17:57:55 UTC
Permalink
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
Post by Victor Kryukov
OK, I think I
have solved it. The problem seemed to be related to FAQ 2.23.
Post by Victor Kryukov
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.
Post by Victor Kryukov
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.
Post by Victor Kryukov
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,
Post by Victor Kryukov
Victor
On Thu, Mar 7, 2013 at 12:55 AM, Matthew Dowle
Post by Matthew Dowle
Victor,
As Steve says
you shouldn't need to do that.
Post by Victor Kryukov
Post by Matthew Dowle
If it's just the mask warnings
you're trying to suppress have you tried :
suppressPackageStartupMessages({
Post by Victor Kryukov
Post by Matthew Dowle
library(...)
library(...)
})
install.packages("lubdridate")
Post by Victor Kryukov
Post by Matthew Dowle
package
'lubdridate' is not available (for R version 2.15.3)
Post by Victor Kryukov
Post by Matthew Dowle
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.
Post by Victor Kryukov
Post by Matthew Dowle
Matthew
On 07.03.2013 05:40,
Post by Steve Lianoglou
Hi,
On Thu, Mar 7, 2013 at 12:22
AM, Victor Kryukov
Update: it looks the order in NAMESPACE doesn't matter for that
particular
Post by Victor Kryukov
Post by Matthew Dowle
Post by Steve Lianoglou
Post by Victor Kryukov
problem. I can confirm that when I change it the order
of package loading
Post by Victor Kryukov
Post by Matthew Dowle
Post by Steve Lianoglou
Post by Victor Kryukov
changes, as it's either data.table or lubridate
that warns about
Post by Victor Kryukov
Post by Matthew Dowle
Post by Steve Lianoglou
Post by Victor Kryukov
overwritting each other's functions, but the
problem exists in either case.
Post by Victor Kryukov
Post by Matthew Dowle
Post by Steve Lianoglou
Post by Victor Kryukov
I think my next steps will be
to perform a surgery on data.table by removing
Post by Victor Kryukov
Post by Matthew Dowle
Post by Steve Lianoglou
Post by Victor Kryukov
all IDateTime from
my local copy - will see if it helps :).
Post by Victor Kryukov
Post by Matthew Dowle
Post by Steve Lianoglou
It's your prerogative
to do what you like, but I feel like the other
Post by Victor Kryukov
Post by Matthew Dowle
Post by Steve Lianoglou
two alternatives I
gave are a bit less intense than what you are
Post by Victor Kryukov
Post by Matthew Dowle
Post by Steve Lianoglou
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.
Post by Victor Kryukov
Post by Matthew Dowle
Post by Steve Lianoglou
-steve
Links:
------
[1]
mailto:***@gmail.com
[2] mailto:***@mdowle.plus.com
[3]
https://r-forge.r-project.org/scm/viewvc.php/?root=datatable

Continue reading on narkive:
Loading...