ob-R, about :results value verbatim drawer

ob-R, about :results value verbatim drawer

[Feng Shu]

When I run follow code, it just work:

       #+begin_comment
       
       #+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
       
       #+RESULTS:
       :RESULTS:
       [[./test1.org]]
       [[./test2.org]]
       [[./test3.org]]
       :END:
       


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

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

[Aaron Ecay]

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.

-- 
Aaron Ecay

Header Arguments of Code Blocks - problems and challenges

[Rainer M Krug]

[-- Attachment #1.1: Type: text/plain, Size: 3645 bytes --]


Hi

Based on several previous posts, it seems that the use of header
arguments, particularly

- different ways of setting these (from the manual)
,----
|  - System-wide header arguments::  Set global default values
|  - Language-specific header arguments::  Set default values by language
|  - Header arguments in Org mode properties::  Set default values for a buffer or heading
|  - Language-specific header arguments in Org mode properties::  Set language-specific default values for a buffer or heading
|  - Code block specific header arguments::  The most common way to set values
|  - Header arguments in function calls::  The most specific level
`----
- Inheritance of these
- how they interact

I now these as a problem of R, but I guess it is general for all
languages suported in org?

To make the usage of these header arguments easier, a proper outline
and description is needed how header arguments for source blocks can
be set and how these interact (inheritance, header-args versus
header-args+ at one and on different levels, 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 likethis, 
- not working,
- let's try out what is working,
- repeat from the beginning for the next change

But this is far from ideal and leads to spaghetti-code type property
setting which is quite fragile.

I don't think is it only me who has these problems.

So what could be done to remedy this?  I think a few aspects should be
tackeled (in no particular order):

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. I don't
   think this should go only into worg.
2) A set of simple and easily to understand examples which build on
   each other are needed. 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 sugfgest to 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. 

To make this happen, I would suggest to get a discussion going to

1) get a few interested users who are willing to activly participate
   in this (There is alread one: Thanks Grant!)
2) discuss how this can be tackled
3) and then, from there, get it going.

Before I end, I must thank the org developers for their hard work they
have put into org - and I am sure that the header arguments framework
has received quite a bit of attention. But (and please correct me if I
am wrong), there is a relatively small overlap between main org
developers and regular org babel users.

And this is where the babel user can contributing to org, even if
their elisp knowledge is not the best.

OK - I hope we can geth this going and make a usefull contribution to
org babel,

Rainer

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

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

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

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

[Rainer M Krug]

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

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

[Grant Rettke]

On Wed, Sep 24, 2014 at 2:52 AM, Rainer M Krug <Rainer@krugs.de> wrote:
> would there be interest in pursuing this?

Yes.

I'm interested in working with other serious babel users to pool our
efforts, provide a meaningful contribution, and do it in a way that
works best for the maintainers.

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

[Rainer M Krug]

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

Grant Rettke <gcr@wisdomandwonder.com> writes:

> On Wed, Sep 24, 2014 at 2:52 AM, Rainer M Krug <Rainer@krugs.de> wrote:
>> would there be interest in pursuing this?
>
> Yes.
>
> I'm interested in working with other serious babel users to pool our
> efforts, provide a meaningful contribution, and do it in a way that
> works best for the maintainers.

OK - I will then repost the previous email under a different header and
ask for interested babel users who would like to participate and suggest
a way forward to make this happen.

Thanks for your thumbs up,

Rainer

>
>

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

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

Header Arguments of Code Blocks - problems and challenges

[Rainer M Krug]

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


Hi

Based on several previous posts, it seems that the use of header
arguments, particularly

- different ways of setting these (from the manual)
,----
|  - System-wide header arguments::  Set global default values
|  - Language-specific header arguments::  Set default values by language
|  - Header arguments in Org mode properties::  Set default values for a buffer or heading
|  - Language-specific header arguments in Org mode properties::  Set language-specific default values for a buffer or heading
|  - Code block specific header arguments::  The most common way to set values
|  - Header arguments in function calls::  The most specific level
`----
- Inheritance of these
- how they interact

I now these as a problem of R, but I guess it is general for all
languages suported in org?

To make the usage of these header arguments easier, a proper outline
and description is needed how header arguments for source blocks can
be set and how these interact (inheritance, header-args versus
header-args+ at one and on different levels, 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,
- repeat from the beginning for the next change

But this is far from ideal and leads to spaghetti-code type property
setting which is quite fragile.

I don't think is it only me who has these problems.

So what could be done to remedy this?  I think a few aspects should be
tackeled (in no particular order):

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. I don't
   think this should go only into worg.
2) A set of simple and easily to understand examples which build on
   each other are needed. 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 sugfgest to 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. 

To make this happen, I would suggest to get a discussion going to

1) get a few interested users who are willing to activly participate
   in this (There is alread one: Thanks Grant!)
2) discuss how this can be tackled
3) and then, from there, get it going.

Before I end, I must thank the org developers for their hard work they
have put into org - and I am sure that the header arguments framework
has received quite a bit of attention. But (and please correct me if I
am wrong), there is a relatively small overlap between main org
developers and regular org babel users.

And this is where the babel user can contributing to org, even if
their elisp knowledge is not the best.

OK - I hope we can geth this going and make a usefull contribution to
org babel,

Rainer

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

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

Re: Header Arguments of Code Blocks - problems and challenges

[Grant Rettke]

On Fri, Sep 26, 2014 at 3:20 AM, Rainer M Krug <Rainer@krugs.de> wrote:
> OK - I hope we can geth this going and make a usefull contribution to
> org babel,

Three ideas for ways work on this:
• Purely technically driven
  • Learn the current test framework
  • Identify property permutations
  • Verify tests and documentation
• Purely scenario driven
  • Identify common development scenarios
  • Define the desired results and actual
  • Create vignette's for other users to pull from
• Combination of both
  • Allows for more focus on coding of desired
  • Allows for more focus on using if desired
  • We all are curious about and have invested in both already