can not use head or kable function on data.table objrcts(data.table 1.9.3)

[badbye]

Since data.table 1.9.2 version run incorrectly in slidify, I install the developed version 1.9.3, but another problem arises when i use kable function from knitr.
Here is my code:

library(knitr)
library(data.table)
DT = data.table(x = 1:5, y =6:10)
kable(DT)

The Error message:

错误于[<-.data.table(*tmp*, , isn, value = c("TRUE", "TRUE")) :
j must be vector of column name or positions

Currently I use kable(as.data.frame(DT)) which works but not elegant.

[stephlocke]

I've just upgraded and get this issue also

sessionInfo()
R version 3.1.1 (2014-07-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_United Kingdom.1252 LC_CTYPE=English_United Kingdom.1252 LC_MONETARY=English_United Kingdom.1252 LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.1252

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] scales_0.2.4 zoo_1.7-11 knitr_1.6 data.table_1.9.4

loaded via a namespace (and not attached):
[1] chron_2.3-45 colorspace_1.2-4 digest_0.6.4 evaluate_0.5.5 formatR_1.0 grid_3.1.1 htmltools_0.2.6 lattice_0.20-29 munsell_0.4.2
[10] plyr_1.8.1 Rcpp_0.11.3 reshape2_1.4 rmarkdown_0.3.3 stringr_0.6.2 tools_3.1.1 yaml_2.1.13

[mattdowle]

Reproduced with knitr v1.6 but v1.7 released to CRAN on 13 Oct seems to fix the issue yihui/knitr@e34c279. That comment appears to have been motivated by dplyr objects though - I don't understand the issue there.
Anyway, leaving open as need to find a more robust solution. Maybe there's a way to whitelist just the eval() of user code, not knitr code itself.

[jangorecki]

That comment appears to have been motivated by dplyr

As you obviously know the dplyr is designed to operate on data.table too, I believe they might have in mind dplyr which operate on data.table but just didn't mention data.table.
If knitr v1.7 is not missing anything in terms of data.table, why do we need more robust solution? it would be another process to support which might be left on the knitr side.

[arunsrinivasan]

There's already #505 on knitr compatibility. I think since this particular issue is resolved, it can be closed. And with a more robust solution, #505 can be closed.

[mattdowle]

@jangorecki

As you obviously know the dplyr is designed to operate on data.table too, I believe they might have in mind dplyr which operate on data.table but just didn't mention data.table.

It doesn't seem to have been to do with data.table. Here's the issue : yihui/knitr#851

So it seems that that fix happened by chance to fix the issue caused by me whitelisting knitr as well. Turns out there was no need to whitelist knitr because it was already working fine (since it evals user code with envir=globalenv()).

If knitr v1.7 is not missing anything in terms of data.table, why do we need more robust solution? it would be another process to support which might be left on the knitr side.

Because we should rely on that as.data.frame() in knitr. It is now in v1.7 and that's a copy and not ideal. The commit just now in data.table just made means that v1.6 now works again. If knitr adds more functions that use data.frame syntax on a data.table (or reverts to the previous version of kable()), then it can now and it will work. If other packages eval'ing user code also want to use data.frame syntax in their own functions as well, then they can now. So this is now more robust. Before, the cedta.override was too blunt in that it made all the code in such packages data.table-aware as well as all we really wanted which was the eval() of user code. New NEWS item is :

knitr::kable() works again without needing to upgrade from knitr v1.6 to v1.7. Packages which evaluate user code and don't wish to import data.table need to be added to data.table:::cedta.pkgEvalsUserCode and now only the eval part is made data.table-aware (the rest of such package's code is left data.table-unaware). data.table:::cedta.override is now empty and will be deprecated if no need for it arises.