[PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[Rainer M Krug]

[-- 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 --]

Re: [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[Charles C. Berry]

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

Re: [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[Rainer M Krug]

[-- 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 --]

Re: [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[Charles C. Berry]

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

Re: [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[Rainer M Krug]

[-- 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 --]

Re: [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[Charles C. Berry]

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

[NEW PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[Rainer M Krug]

[-- 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 --]

Re: [NEW PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[Rainer M Krug]

[-- 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 --]

Re: [NEW PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[Aaron Ecay]

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

Re: [NEW PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[Rainer M Krug]

[-- 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 --]