* [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change
@ 2014-10-06 12:00 Rainer M Krug
2014-10-07 20:51 ` Charles C. Berry
0 siblings, 1 reply; 10+ messages in thread
From: Rainer M Krug @ 2014-10-06 12:00 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 551 bytes --]
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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: Patch --]
[-- Type: text/x-patch, Size: 1139 bytes --]
From 7e43b724d9fd2557aef7440bb75de0e026a29c88 Mon Sep 17 00:00:00 2001
From: "Rainer M. Krug" <R.M.Krug@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
[-- Attachment #1.3: Type: text/plain, Size: 73 bytes --]
--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982
[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change 2014-10-06 12:00 [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change Rainer M Krug @ 2014-10-07 20:51 ` Charles C. Berry 2014-10-08 9:54 ` Rainer M Krug 0 siblings, 1 reply; 10+ messages in thread From: Charles C. Berry @ 2014-10-07 20:51 UTC (permalink / raw) To: Rainer M Krug; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change 2014-10-07 20:51 ` Charles C. Berry @ 2014-10-08 9:54 ` Rainer M Krug 2014-10-08 15:43 ` Charles C. Berry 0 siblings, 1 reply; 10+ messages in thread From: Rainer M Krug @ 2014-10-08 9:54 UTC (permalink / raw) To: Charles C. Berry; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 2403 bytes --] "Charles C. Berry" <ccberry@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: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change 2014-10-08 9:54 ` Rainer M Krug @ 2014-10-08 15:43 ` Charles C. Berry 2014-10-08 18:39 ` Rainer M Krug 0 siblings, 1 reply; 10+ messages in thread From: Charles C. Berry @ 2014-10-08 15:43 UTC (permalink / raw) To: Rainer M Krug; +Cc: emacs-orgmode On Wed, 8 Oct 2014, Rainer M Krug wrote: > "Charles C. Berry" <ccberry@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change 2014-10-08 15:43 ` Charles C. Berry @ 2014-10-08 18:39 ` Rainer M Krug 2014-10-08 21:34 ` Charles C. Berry 0 siblings, 1 reply; 10+ messages in thread From: Rainer M Krug @ 2014-10-08 18:39 UTC (permalink / raw) To: Charles C. Berry; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1753 bytes --] "Charles C. Berry" <ccberry@ucsd.edu> writes: > On Wed, 8 Oct 2014, Rainer M Krug wrote: > >> "Charles C. Berry" <ccberry@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: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change 2014-10-08 18:39 ` Rainer M Krug @ 2014-10-08 21:34 ` Charles C. Berry 2014-10-09 8:19 ` [NEW PATCH] " Rainer M Krug 0 siblings, 1 reply; 10+ messages in thread From: Charles C. Berry @ 2014-10-08 21:34 UTC (permalink / raw) To: Rainer M Krug; +Cc: emacs-orgmode On Wed, 8 Oct 2014, Rainer M Krug wrote: > "Charles C. Berry" <ccberry@ucsd.edu> writes: > >> On Wed, 8 Oct 2014, Rainer M Krug wrote: >> >>> "Charles C. Berry" <ccberry@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [NEW PATCH] read.table in variable transfer caused sometimes "function not found" error - small change 2014-10-08 21:34 ` Charles C. Berry @ 2014-10-09 8:19 ` Rainer M Krug 2014-10-09 8:25 ` Rainer M Krug 0 siblings, 1 reply; 10+ messages in thread From: Rainer M Krug @ 2014-10-09 8:19 UTC (permalink / raw) To: Charles C. Berry; +Cc: emacs-orgmode [-- Attachment #1.1: Type: text/plain, Size: 2135 bytes --] "Charles C. Berry" <ccberry@ucsd.edu> writes: > On Wed, 8 Oct 2014, Rainer M Krug wrote: > >> "Charles C. Berry" <ccberry@ucsd.edu> writes: >> >>> On Wed, 8 Oct 2014, Rainer M Krug wrote: >>> >>>> "Charles C. Berry" <ccberry@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. OK - done in attached patch. Rainer [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.2: The Patch --] [-- Type: text/x-patch, Size: 1566 bytes --] From 1eadbf6b44b8fc2fa5af29ea483383e9d137d19e Mon Sep 17 00:00:00 2001 From: "Rainer M. Krug" <R.M.Krug@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 | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/lisp/ob-R.el b/lisp/ob-R.el index ea33031..a64b647 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, @@ -112,14 +112,17 @@ this variable.") res })" "R code used to transfer a table defined as a variable from org to R. -This function is used when the table contains a header.") +This function is used when the table contains a header. The usage +of utils::read.table() ensures that the command read.table() can +be found even in circumstances when the utils package is not in +the search path from R.") (defconst ob-R-transfer-variable-table-without-header "%s <- local({ con <- textConnection( %S ) - res <- read.table( + res <- utils::read.table( con, header = %s, row.names = %s, -- 2.1.2 [-- Attachment #1.3: Type: text/plain, Size: 91 bytes --] > > Chuck > > -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [NEW PATCH] read.table in variable transfer caused sometimes "function not found" error - small change 2014-10-09 8:19 ` [NEW PATCH] " Rainer M Krug @ 2014-10-09 8:25 ` Rainer M Krug 2014-10-10 4:21 ` Aaron Ecay 0 siblings, 1 reply; 10+ messages in thread From: Rainer M Krug @ 2014-10-09 8:25 UTC (permalink / raw) To: Charles C. Berry; +Cc: emacs-orgmode [-- Attachment #1.1: Type: text/plain, Size: 136 bytes --] *Please ignore the previous patch* This updated patch contains the correct documentation and commit message Sorry about the mistake, [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.2: The correct patch --] [-- Type: text/x-patch, Size: 2425 bytes --] From 58cb8521d4d4b620b0c5210a9b7232f99f7c720c Mon Sep 17 00:00:00 2001 From: "Rainer M. Krug" <R.M.Krug@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. (ob-R-transfer-variable-table-without-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 | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/lisp/ob-R.el b/lisp/ob-R.el index ea33031..0b24a64 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, @@ -112,14 +112,17 @@ this variable.") res })" "R code used to transfer a table defined as a variable from org to R. -This function is used when the table contains a header.") +This function is used when the table contains a header. The usage +of utils::read.table() ensures that the command read.table() can +be found even in circumstances when the utils package is not in +the search path from R.") (defconst ob-R-transfer-variable-table-without-header "%s <- local({ con <- textConnection( %S ) - res <- read.table( + res <- utils::read.table( con, header = %s, row.names = %s, @@ -132,7 +135,10 @@ This function is used when the table contains a header.") res })" "R code used to transfer a table defined as a variable from org to R. -This function is used when the table does not contain a header.") +This function is used when the table does not contain a +header. The usage of utils::read.table() ensures that the command +read.table() can be found even in circumstances when the utils +package is not in the search path from R.") (defun org-babel-expand-body:R (body params &optional graphics-file) "Expand BODY according to PARAMS, return the expanded body." -- 2.1.2 [-- Attachment #1.3: Type: text/plain, Size: 4076 bytes --] Rainer Rainer M Krug <Rainer@krugs.de> writes: > "Charles C. Berry" <ccberry@ucsd.edu> writes: > >> On Wed, 8 Oct 2014, Rainer M Krug wrote: >> >>> "Charles C. Berry" <ccberry@ucsd.edu> writes: >>> >>>> On Wed, 8 Oct 2014, Rainer M Krug wrote: >>>> >>>>> "Charles C. Berry" <ccberry@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. > > OK - done in attached patch. > > Rainer > From 1eadbf6b44b8fc2fa5af29ea483383e9d137d19e Mon Sep 17 00:00:00 2001 > From: "Rainer M. Krug" <R.M.Krug@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 | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/lisp/ob-R.el b/lisp/ob-R.el > index ea33031..a64b647 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, > @@ -112,14 +112,17 @@ this variable.") > res > })" > "R code used to transfer a table defined as a variable from org to R. > -This function is used when the table contains a header.") > +This function is used when the table contains a header. The usage > +of utils::read.table() ensures that the command read.table() can > +be found even in circumstances when the utils package is not in > +the search path from R.") > > (defconst ob-R-transfer-variable-table-without-header > "%s <- local({ > con <- textConnection( > %S > ) > - res <- read.table( > + res <- utils::read.table( > con, > header = %s, > row.names = %s, > -- > 2.1.2 > > >> >> Chuck >> >> -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [NEW PATCH] read.table in variable transfer caused sometimes "function not found" error - small change 2014-10-09 8:25 ` Rainer M Krug @ 2014-10-10 4:21 ` Aaron Ecay 2014-10-10 7:43 ` Rainer M Krug 0 siblings, 1 reply; 10+ messages in thread From: Aaron Ecay @ 2014-10-10 4:21 UTC (permalink / raw) To: Rainer M Krug, Charles C. Berry; +Cc: emacs-orgmode Hello, Thanks Rainer for this patch, and thanks Chuck for the discussion. It appears that “use utils::read.table” is the official advice from devtools’s maintainer: https://github.com/hadley/devtools/issues/336#issuecomment-23517837. I’ve pushed the patch to the master branch. I reworded the commit message slightly. I also moved the note about utils:: from a docstring to a comment in the ob-R.el file. This is based on a feeling that it’s an implementation detail that is less useful for elisp programmers (primary consumers of docstrings), but necessary for anyone working on ob-R’s internals (who will read the file itself). Thanks again, -- Aaron Ecay ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [NEW PATCH] read.table in variable transfer caused sometimes "function not found" error - small change 2014-10-10 4:21 ` Aaron Ecay @ 2014-10-10 7:43 ` Rainer M Krug 0 siblings, 0 replies; 10+ messages in thread From: Rainer M Krug @ 2014-10-10 7:43 UTC (permalink / raw) To: Charles C. Berry; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1265 bytes --] Aaron Ecay <aaronecay@gmail.com> writes: > Hello, > > Thanks Rainer for this patch, and thanks Chuck for the discussion. It > appears that “use utils::read.table” is the official advice from > devtools’s maintainer: > https://github.com/hadley/devtools/issues/336#issuecomment-23517837. > > I’ve pushed the patch to the master branch. Thanks. > I reworded the commit message slightly. I also moved the note about > utils:: from a docstring to a comment in the ob-R.el file. This is > based on a feeling that it’s an implementation detail that is less > useful for elisp programmers (primary consumers of docstrings), but > necessary for anyone working on ob-R’s internals (who will read the > file itself). I agree with this, but as an R programmer, I would rather read the docstring via C-h v then read in the elisp code (more likely for the elisp programmer). But Anyway - anybody who is likely to modify this variable, likely knows what utils::read.table() means - so no objections. But wait - I think I get your point now. You are right - the source code may be the better place for this comment. Cheers, Rainer > > Thanks again, -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-10-10 7:44 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-10-06 12:00 [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change Rainer M Krug 2014-10-07 20:51 ` Charles C. Berry 2014-10-08 9:54 ` Rainer M Krug 2014-10-08 15:43 ` Charles C. Berry 2014-10-08 18:39 ` Rainer M Krug 2014-10-08 21:34 ` Charles C. Berry 2014-10-09 8:19 ` [NEW PATCH] " Rainer M Krug 2014-10-09 8:25 ` Rainer M Krug 2014-10-10 4:21 ` Aaron Ecay 2014-10-10 7:43 ` Rainer M Krug
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).