Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tables() from data.table #456

Closed
jaredlander opened this issue Jan 9, 2013 · 6 comments
Closed

tables() from data.table #456

jaredlander opened this issue Jan 9, 2013 · 6 comments
Labels
bug Bugs
Milestone

Comments

@jaredlander
Copy link
Contributor

I've noticed some issues in other posts about data.table and environments and stumbled upon an one of my own. The tables() argument depends on the environment and works fine if it is in the same chunk as where the data.table was created, but if it is in its own chunk it will not work. This has something to do with caching as setting cache=FALSE takes care of the issue. It does not, however, affect just accessing the tables. A reproducible example is below.

data.table issue

opts_chunk$set(cache=TRUE,cache.path="dtCache/")

If we call tables() in the same chunk where the tables were created it works, if we call it in its own chunk it does not work.

require(data.table)
theDT <- data.table(A=1:10, B=letters[1:10], C=LETTERS[11:20])
theDT
nrow(theDT)
carsDT <- data.table(cars)
head(carsDT)
nrow(carsDT)
tables()

Now we look at the tables command in its own chunk.

tables()

Here tables will only recognize the tables from this chunk and not the previous ones.

secondDT <- data.table(First=10:1, Second=1:10)
secondDT
tables()

We can still access all the previous data.tables though.

theDT
secondDT
head(carsDT)

If you turn off caching, everything works fine.

Sorry that GitHub is incorrectly interpreting the code but pasting all of it into a Rmd file should make things clear.

@yihui yihui closed this as completed in 778df73 Jan 10, 2013
@yihui
Copy link
Owner

yihui commented Jan 10, 2013

tables() has an env argument, and you can pass knitr's environment to it; with the current devel version, you can tables(env = knit_global())

@jaredlander
Copy link
Contributor Author

Perfect, I knew it was be an environment issue, didn't realize there was a special knitr environment. Is there a way to set that globally so that I can hide the env from the reader and not have it each time?

@yihui
Copy link
Owner

yihui commented Jan 10, 2013

This is actually a very tricky problem. I need to use the special (empty) environment in order to know which objects are created in a chunk. At best I can say tables(env = globalenv()) which looks less confusing.

The fundamental fix requires the author of data.table to make a change in tables():

> tables
function (mb = TRUE, order.col = "NAME", width = 80, env = parent.frame(), 
    silent = FALSE) 
{
    tt = objects(envir = env, all.names = TRUE)
....

For tt, it can also take object names from the enclosing environment: c(objects(envir = env, all.names = TRUE), objects(envir = parent.env(env), all.names = TRUE))

The other way is to add an argument to allow users to specify the object names.

function (mb = TRUE, order.col = "NAME", width = 80, env = parent.frame(), 
    silent = FALSE, objects = ls(env, all.names = TRUE)) 

and you can call data.tables(objects = c('carsDT', ...))

@jaredlander
Copy link
Contributor Author

This is a perfect excuse to allow me to eval according to line (#383).

Right now to get around this and not confuse the user by specifying the environment I am doing

# show tables
tables()
# show tables
tables(env=knit_global())

It would be so much better to do

# show tables
tables()
tables(env=knit_global())

yihui added a commit that referenced this issue Apr 7, 2013
…nks, and users can set cache.vars as the variable names to be saved

this is an ultimate fix to #456 and also solves the problem http://stackoverflow.com/q/15810976/559676
@yihui
Copy link
Owner

yihui commented Apr 7, 2013

The problem should be gone now.

@github-actions
Copy link

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Bugs
Projects
None yet
Development

No branches or pull requests

2 participants