From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Charles C. Berry" <ccberry@ucsd.edu>
Subject: Re: [PATCH] read.table in variable transfer caused sometimes
 "function not found" error - small change
Date: Tue, 7 Oct 2014 13:51:55 -0700
Message-ID: <alpine.OSX.2.00.1410071313430.858@charles-berrys-macbook.local>
References: <m2ppe55rwt.fsf@krugs.de>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50323)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ccberry@ucsd.edu>) id 1Xbbm3-0002Ie-3D
	for emacs-orgmode@gnu.org; Tue, 07 Oct 2014 16:54:29 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ccberry@ucsd.edu>) id 1Xbblw-0003uX-8C
	for emacs-orgmode@gnu.org; Tue, 07 Oct 2014 16:54:23 -0400
Received: from iport-acv2-out.ucsd.edu ([132.239.0.174]:21720)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ccberry@ucsd.edu>) id 1Xbblv-0003uC-Ub
	for emacs-orgmode@gnu.org; Tue, 07 Oct 2014 16:54:16 -0400
In-Reply-To: <m2ppe55rwt.fsf@krugs.de>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
To: Rainer M Krug <Rainer@krugs.de>
Cc: emacs-orgmode@gnu.org

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