From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: babel header arguments tutorial? Date: Sun, 27 Sep 2015 15:51:01 -0400 Message-ID: <87mvw7zlne.fsf@pierrot.dokosmarshall.org> References: <87zj08zvcl.fsf@pierrot.dokosmarshall.org> <87vbawziq2.fsf@pierrot.dokosmarshall.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgHyf-00039R-AU for emacs-orgmode@gnu.org; Sun, 27 Sep 2015 15:51:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgHya-0002N1-9v for emacs-orgmode@gnu.org; Sun, 27 Sep 2015 15:51:17 -0400 Received: from plane.gmane.org ([80.91.229.3]:57794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgHya-0002Mv-0M for emacs-orgmode@gnu.org; Sun, 27 Sep 2015 15:51:12 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZgHyY-0006cr-BS for emacs-orgmode@gnu.org; Sun, 27 Sep 2015 21:51:10 +0200 Received: from pool-108-20-41-232.bstnma.fios.verizon.net ([108.20.41.232]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Sep 2015 21:51:10 +0200 Received: from ndokos by pool-108-20-41-232.bstnma.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Sep 2015 21:51:10 +0200 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: emacs-orgmode@gnu.org Lawrence Bottorff writes: > I guess from a purely elisp perspective I'm baffled. How is > > #+begin_src emacs-lisp >   org-babel-default-header-args:Python > #+end_src > > supposed to produce > > #+RESULTS: > | (:session . foo) | > > as it supposedly does in the doc? It doesn't for me. (Where, e.g., would "foo" be coming from?) If it had worked, does it make an addition to some hash table, or an alist somewhere? > But then running this as an elisp code block is cool from a declarative programming standpoint (see this) . So this > > # Local Variables: > # eval: (setq-local org-babel-default-header-args:Python '((:session . "foo"))) > # End: > > is called when you eval-buffer or open the file?  > When you open the file. But see some caveats in my reply. Charles Berry's reply shows the preferred method today, using only what's available in org, but does not shed any light on the local file variables question (which is a more general mechanism, available throughout emacs, not just with org files). Assuming that you want to learn about file variables, we will forget temporarily about Charles's reply. So when you open the file, the local variables section is found and evaluated. Any variable settings are automatically buffer-local. That's what sets the org-babel-default-header-args:python variable to '((:session . "foo")) - in that buffer only. Then when you go evaluate the code block #+begin_src emacs-lisp org-babel-default-header-args:python #+end_src the variable has the give value and produces a result #+RESULTS: : ((:session . foo)) But if you evaluate the same code block in some other buffer, the result will be nil (unless you have initialized in some other way of course, e.g. by adding the initialization to your .emacs). > Ancillary questions: > 1. can babel elisp (or CL) blocks be assigned/associated to a > specifically named session? > That would enable various elisp code blocks to have separate "session > spaces" (as does the geiser/scheme babel). If so, I'm guessing the > block-session communication could also be remote? Again, with babel > geiser/scheme sessions, can they call "cached" things from each > other's different sessions? > Theoretically, maybe (how's that for exactness?), but there are babel implementations that don't support sessions at all and (depending on the underlying interpreter), there may be subtle (or perhaps not so subtle) differences in evaluation semantics. Some experimentation should provide answers, but N.B. that the answers may be accidents of implementation (which some might call "bugs"). I don't think there is a strictly defined session model that applies to all languages: the implementations do the best they can under these circumstances. Now this is more a hunch than anything else: I *think* that's the way things are but I may be wrong, out-of-date, or both. A set of well-designed experiments in as many languages as possible would clarify the situation, and perhaps lead to improvements (they could also be turned into unit tests, which would be very desirable) - I won't volunteer, but maybe you would? > 2. . . . which makes me wonder how code blocks in a buffer can be run besides manually C-c C-c ing them. For example, > > #+name: myexptdouble > #+begin_src emacs-lisp :session > (defun myexptdouble (x y) >   (* (myexpt x y) (myexpt x y))) > #+end_src > > #+RESULTS: myexptdouble > : myexptdouble > > #+name: myexpt > #+begin_src emacs-lisp :session > (defun myexpt (x y) >   (expt x y)) > #+end_src > > #+BEGIN_SRC emacs-lisp :results output raw > (myexptdouble 2 3) > #+END_SRC > > Even if I manually evaluate myexptdouble, running the last block gives an error about not knowing what myexpt is. Is there something in the last block that can be told to evaluate all > the dependent functions? Perhaps if my blocks are named the same as the function name? How tangling and preserving sessions is also an interesting question, IHMO. > That's not answering any of your deeper questions, but the problem here is that the last code block evaluates a function that produces no output: it produces a return value though, so try #+BEGIN_SRC emacs-lisp :results value raw (myexptdouble 2 3) #+END_SRC -- Nick