Re: [O] [PATCH] read.table in variable transfer caused sometimes function not found error - small change
Charles C. Berry ccbe...@ucsd.edu 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 =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. 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. =library()= 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 =utils::read.table()= is preferable to the risky use of only =read.table=, 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 HTH, Chuck -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 pgpFvwcDz40GY.pgp Description: PGP signature
Re: [O] [PATCH] read.table in variable transfer caused sometimes function not found error - small change
On Wed, 8 Oct 2014, Rainer M Krug wrote: Charles C. Berry ccbe...@ucsd.edu 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 =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. Exactly - that is true. But it is the same when putting this in a package (as far as I am aware). Do you mean that putting `x - rnorm(10)' into a data/*.R file will fail when you try to build and check? In fact, `R CMD build' will execute it and save the result as a data/*.rda file. And check will go through. devtools::load_all (calling load_data) fails to do that. Which is why I think this is a devtools issue. Chuck
Re: [O] [PATCH] read.table in variable transfer caused sometimes function not found error - small change
Charles C. Berry ccbe...@ucsd.edu writes: On Wed, 8 Oct 2014, Rainer M Krug wrote: Charles C. Berry ccbe...@ucsd.edu 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 =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. Exactly - that is true. But it is the same when putting this in a package (as far as I am aware). Do you mean that putting `x - rnorm(10)' into a data/*.R file will fail when you try to build and check? In fact, `R CMD build' will execute it and save the result as a data/*.rda file. And check will go through. devtools::load_all (calling load_data) fails to do that. Which is why I think this is a devtools issue. OK - point taken. But I still think that the =utils::read.table()= would not hurt, rather make the variable transfer safer. Rainer Chuck -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 pgpcHdQDfGFOb.pgp Description: PGP signature
Re: [O] [PATCH] read.table in variable transfer caused sometimes function not found error - small change
On Wed, 8 Oct 2014, Rainer M Krug wrote: Charles C. Berry ccbe...@ucsd.edu writes: On Wed, 8 Oct 2014, Rainer M Krug wrote: Charles C. Berry ccbe...@ucsd.edu 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 =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. Exactly - that is true. But it is the same when putting this in a package (as far as I am aware). Do you mean that putting `x - rnorm(10)' into a data/*.R file will fail when you try to build and check? In fact, `R CMD build' will execute it and save the result as a data/*.rda file. And check will go through. devtools::load_all (calling load_data) fails to do that. Which is why I think this is a devtools issue. OK - point taken. But I still think that the =utils::read.table()= would not hurt, rather make the variable transfer safer. What you want to change is in a defconst. So, the user can override with a file-local version. So, making the change really is harmless. Maybe add a note to the docstring to say that using `utils::read.table' assures that `read.table' always can be found just in case anyone ever asks. Chuck
Re: [O] [PATCH] read.table in variable transfer caused sometimes function not found error - small change
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
[O] [PATCH] read.table in variable transfer caused sometimes function not found error - small change
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. 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. Cheers, Rainer From 7e43b724d9fd2557aef7440bb75de0e026a29c88 Mon Sep 17 00:00:00 2001 From: Rainer M. Krug r.m.k...@gmail.com Date: Mon, 6 Oct 2014 13:48:49 +0200 Subject: [PATCH] ob-R.el: Add package name to read.table call * lisp/ob-R.el: (ob-R-transfer-variable-table-with-header): Add package name to call of R function read.table (now utils::read.table). This clarifies the call as well as avoids 'could not find function' error in R under certain conditions. --- lisp/ob-R.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/ob-R.el b/lisp/ob-R.el index ea33031..dd0b0b9 100644 --- a/lisp/ob-R.el +++ b/lisp/ob-R.el @@ -101,7 +101,7 @@ this variable.) con - textConnection( %S ) - res - read.table( + res - utils::read.table( con, header= %s, row.names = %s, @@ -119,7 +119,7 @@ This function is used when the table contains a header.) con - textConnection( %S ) - res - read.table( + res - utils::read.table( con, header= %s, row.names = %s, -- 2.1.2 -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 pgpRe_6szagaQ.pgp Description: PGP signature
