From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change Date: Wed, 08 Oct 2014 11:54:30 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbnxD-0006gx-GB for emacs-orgmode@gnu.org; Wed, 08 Oct 2014 05:54:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xbnx8-0006BN-Gr for emacs-orgmode@gnu.org; Wed, 08 Oct 2014 05:54:43 -0400 Received: from mail-wg0-f51.google.com ([74.125.82.51]:56642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xbnx8-0006BF-BI for emacs-orgmode@gnu.org; Wed, 08 Oct 2014 05:54:38 -0400 Received: by mail-wg0-f51.google.com with SMTP id b13so11159027wgh.10 for ; Wed, 08 Oct 2014 02:54:37 -0700 (PDT) In-Reply-To: (Charles C. Berry's message of "Tue, 7 Oct 2014 13:51:55 -0700") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: "Charles C. Berry" Cc: emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable "Charles C. Berry" writes: > 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 =3Dread.table()=3D with >> =3Dutils::read.table()=3D 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. Exactly - that is true. But it is the same when putting this in a package (as far as I am aware). > > 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. I don't know - As far as I understand, it is the same behaviour as if it would be loaded from a package - i.e. =3Dlibrary()=3D so it would not be a bug but it emulates the behaviour of library(), which it should. > >> >> 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? I would not go there - I see the variable as a mechanism similar to the call to library() in R, which should behave absolutely equal everywhere, even if functions are re-defined. If one wants to have a non standard behaviour in this step, one could always re-define the way variables are transferred, or, the better approach, do it afterwards. So I think the use of =3Dutils::read.table()=3D is preferable to the risky use of only =3Dread.table=3D, exactly because of the re-definition issue you raise. So I would opt to apply this patch as it makes the variable transfer more stable. Cheers, Rainer=20 > > HTH, > > Chuck > > =2D-=20 Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBAgAGBQJUNQnZAAoJENvXNx4PUvmCQrsH/RqIrkFvBErno08NnVvaLZzs m6pExcFjVWXbq2fpGsHP3dMB/brQDq6VGo/evesSqI5+kSBzGKs3Oznnje4krTrl nkqUblH8pBIu7LG+377qZZQmEIC5BM7aePK3bjXCLpKUsEU+MKrSH5t5h9hZJlMH 5SQjHv+oKP25wK018nkiw9ODVu5e21p9R4TyyIfEASNXQ1LWLUwXU5ZqOUiugZmr 1yBiiOSm6/TEEaL73K7rE8WiVeR2DKlwJvox23IxMxtEcOGX2NOOJMewicgqdE9+ Ps3fKokCUe3e2v59BdlHfKiaWQU4OBIr3IBy33GGsIXy+bePN2N4vqsxRor8gQ8= =fYUl -----END PGP SIGNATURE----- --=-=-=--