* [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).