|
From: | Charles C. Berry |
Subject: | Re: [O] [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change |
Date: | Tue, 7 Oct 2014 13:51:55 -0700 |
User-agent: | Alpine 2.00 (OSX 1167 2008-08-23) |
On Mon, 6 Oct 2014, Rainer M Krug wrote:
Hi The variable transfer of tables from org to R caused sometimes 'could not find function "read.table"' errors (e.g. when the file was tangled into a ./data directory which was loaded by the function devtools::load_all("./")). This can easily be fixed by adding the package name to the call in R, i.e. replacing =read.table()= with =utils::read.table()= which is done in this patch.
It does fix that one case. But I wonder if that is the best way.The heart of the matter is that load_all eventually calls sys.source, which can be persnickety about finding objects on the search path. See ?sys.source.
If the src block you tangle to ./data/ has any code that uses any other objects from utils, stats, datasets or whatever, you will be in the same pickle.
Arguably, this is a bug in devtools::load_data. And maybe it would be better to beg the maintainer for a fix or an extension that accomodates your case.
In R the calls read.table and utils::read.table are interchangeable (the second one is actually preferred) so no negative effects can be expected.
What if the user has intentionally masked read.table or the eventual package provides its own read.table?
HTH, Chuck
[Prev in Thread] | Current Thread | [Next in Thread] |