On Tue, Nov 30, 2010 at 3:13 PM, Tom Short <[email protected]> wrote: > On Tue, Nov 30, 2010 at 2:45 PM, Steve Lianoglou > <[email protected]> wrote: >> Hi, >> >> So I mentioned in my last email that I'm going to get back to this >> later, but I'm a bit OCD when I have what seems like low-hanging-fruit >> so I'm trying to figure this out. >> >> I also mentioned I think the problem I'm seeing has something to do >> with the "cedta" business. While fixing this case will help me move >> the test over, perhaps it will also help to better address the >> side-effects cedta has with other things like Imports, Depends, >> etc.(?) >> >> So, download this simple test file: >> >> http://cbio.mskcc.org/~lianos/files/scratch/datatable-test.R >> >> Note that the first call to sys.source works fine, but I think it >> should work with the second case. >> >> Start an R session, and: >> >> R> library(data.table) >> R> sys.source("/path/to/datatable-test.R", .GlobalEnv) ## this works >> R> sys.source("/path/to/datatable-test.R", new.env(parent=.GlobalEnv)) >> Error in `[.data.frame`(x, i, j) : object 'v' not found >> >> Does it seem reasonable to you that it should work in the second example?
It looks like library() uses sys.source, and topenv() ends up pointing at the environment enclosing the package. If test_that also uses sys.source, I'm not sure cedta work. topenv() can't tell if it's in a package or some other environment. Maybe we could include a hidden variable in the top-level environment that lets cedta know that it's aware of data.tables. - Tom _______________________________________________ datatable-help mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
