Re: ob-R, about :results value verbatim drawer

[Rainer M Krug <Rainer@krugs.de>]

[-- Attachment #1: Type: text/plain, Size: 3266 bytes --]

Aaron Ecay <aaronecay@gmail.com> writes:

> Hi Feng,
>
> 2014ko irailak 23an, Feng Shu-ek idatzi zuen:
>> but when I add a #+PROPERTY, it show error like below, how to deal with
>> it ?  thanks ...
>> 
>>       #+PROPERTY: header-args:R :colnames yes :rownames no :exports both
>>       #+BEGIN_SRC R :results value verbatim drawer
>>       data <- list(a="[[./test1.org]]",b="[[./test2.org]]",c="[[./test3.org]]")
>>       c(data$a,data$b,data$c)
>>       #+END_SRC
>> 
>> 
>>       executing R code block...
>>       Wrote /tmp/babel-1984743i/ob-input-198472lB
>>       org-babel-R-evaluate-external-process: Wrong type argument: listp, "x
>>       [[./test1.org]]
>>       [[./test2.org]]
>>       [[./test3.org]]
>>       "
>
> The simple answer is don’t add the #+property line.  In particular, the
> :colnames yes setting doesn’t play well with your code block.  If you
> must have the #+property line for other reasons, override the global
> setting of :colnames yes with :colnames no on the source block.

And another problem with different ways of setting header arguments.

Is this only a problem of R, or is this general (it does not seem to be
only me...) in org?

The more I think, a proper outline and description is needed how header
arguments for source blocks (probably in general, but I use org mainy
for literate programming and data analysis therefore always including
source code blocks) can be set and how these interact (inheritance, the
+, different ways of setting header arguments as above, ...). These
header arguments are a *very* powerful tool and you can do many things -
but you can also break things very easily.

In many cases, I resort to trial and error: This is working, now I want
to have that behaviour for this code block, normally I would do it like
this, not working, let's try out what is working. But this is far from
ideal and leads to spaghetti-code type property setting which is quite
fragile.

Again: is it only me? I don't think (hope?) so.

So what could be done to remedy this?  I think a few aspects should be
tackeled:

1) a lot of information is in the manual - but spread out in many
   different locations / sections. The first would be to bring these
   sections together and to consolidate them into one section.
2) We need a set of simple and easily to understand examples which
   build on each other. So starting with simple examples and expand
   these to complex examples.
3) These examples should be uaed as tests (maybe there are tests for
   this, but I am not at all familiar with the test framework of org).
4) based on these, the org code should be checked for
   - bugs (obviously)
   - inconsistencies in the approach used for header argument setting
     and inheritance and
   - possibly deprecate certain aspects to simplify it (but keep the
     flexibility which is there at the moment!
5) the property inheritance and hierarchy of different ways of setting
   these should be documented in a structured way. 

So is there anything in this direction? I guess this would be quite a
big task - would there be interest in pursuing this?

Rainer

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]