From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: ob-R, about :results value verbatim drawer Date: Wed, 24 Sep 2014 09:52:06 +0200 Message-ID: References: <87a95pbuvs.fsf@news.tumashu-localhost.org> <87zjdpn04o.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWhNF-0003Nd-Gl for emacs-orgmode@gnu.org; Wed, 24 Sep 2014 03:52:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWhNA-0004Eh-3A for emacs-orgmode@gnu.org; Wed, 24 Sep 2014 03:52:29 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:48202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWhN9-00049S-R8 for emacs-orgmode@gnu.org; Wed, 24 Sep 2014 03:52:24 -0400 Received: by mail-wi0-f170.google.com with SMTP id fb4so5961498wid.5 for ; Wed, 24 Sep 2014 00:52:17 -0700 (PDT) In-Reply-To: <87zjdpn04o.fsf@gmail.com> (Aaron Ecay's message of "Tue, 23 Sep 2014 23:55:03 -0400") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Feng Shu Cc: orgmode --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Aaron Ecay 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 ... >>=20 >> #+PROPERTY: header-args:R :colnames yes :rownames no :exports both >> #+BEGIN_SRC R :results value verbatim drawer >> data <- list(a=3D"[[./test1.org]]",b=3D"[[./test2.org]]",c=3D"[[./= test3.org]]") >> c(data$a,data$b,data$c) >> #+END_SRC >>=20 >>=20 >> 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=E2=80=99t add the #+property line. In particula= r, the > :colnames yes setting doesn=E2=80=99t 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.=20 So is there anything in this direction? I guess this would be quite a big task - would there be interest in pursuing this? Rainer =2D-=20 Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBAgAGBQJUInguAAoJENvXNx4PUvmCzrQH/jdcLCFjOt0NQS7KWaNeezcg luwDVPYD78GV3JHyZMyZAGpGCVwQDFWOT2HXaQLzFNR8dv6rrVOxqZX53uZNq2b2 LH2jvU49/dLkhyfm8TiJyQl+oIMzuYhclHrMp3vRKX0zg84YIdfWXdbAar6CWONP ONUycrDqz/6O0zQSjQOAGtXchnWcJaEw/HjCXX4KfN4MLeY4GEjOK8ESgQtWdzgA OBn9BPH6eS9W+uTt9sf2jJrak+yrm3D4aRXCNYgxgwBHofh2N3uwKNj+hVnJpw1n fRS7kFaNZstPkzxD4Tzla4e2VzwhU7qCfOKIh1gVocRG4iKT0s8SuhUyqofOnsk= =Symv -----END PGP SIGNATURE----- --=-=-=--