babel header arguments tutorial?

babel header arguments tutorial?

[Lawrence Bottorff]

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

I see this <http://orgmode.org/worg/org-contrib/babel/header-args.html> and
find the bottom section ("Setting language and file specific default header
argument value") intriguing, however too cryptic. Can someone explain
what's going on here and how to use it?

LB

[-- Attachment #2: Type: text/html, Size: 340 bytes --]

Re: babel header arguments tutorial?

[Charles C. Berry]

On Sat, 26 Sep 2015, Lawrence Bottorff wrote:

> I see this <http://orgmode.org/worg/org-contrib/babel/header-args.html> and
> find the bottom section ("Setting language and file specific default header
> argument value") intriguing, however too cryptic. Can someone explain
> what's going on here and how to use it?


I'd say "don't use it". The source is several years old and filed under 
the FIXME worg directory.

header-arg handling has improved lately.

See (info "(org) Header arguments in Org mode properties") for a good 
appproach that uses this one line

 	#+PROPERTY: header-args:python  :session foo

to do what is in the example you cite.

HTH,

Chuck

Modification dates in Worg (was: babel header arguments tutorial?)

[Michael Strey]

On Sa, 2015-09-26 at 23:39, Charles C. Berry wrote:

[...]

> The source is several years old and filed under the FIXME worg
> directory.

Both things are not visible on the page.  In general there seems to be a
lot of outdated stuff on Worg.  It would be helpful to have at least the
date of last modification on the pages.

-- 
Michael Strey
http://www.strey.biz * https://twitter.com/michaelstrey

Re: Modification dates in Worg (was: babel header arguments tutorial?)

[Ista Zahn]

I've created a worg mirror on github at
https://github.com/izahn/worg-mirror/, so you can see the modification
dates via git-blame. For example,
https://github.com/izahn/worg-mirror/blame/master/org-contrib/babel/languages.org
shows modification of the babel languages page.

Best,
Ista

On Sun, Sep 27, 2015 at 4:22 AM, Michael Strey <mstrey@strey.biz> wrote:
> On Sa, 2015-09-26 at 23:39, Charles C. Berry wrote:
>
> [...]
>
>> The source is several years old and filed under the FIXME worg
>> directory.
>
> Both things are not visible on the page.  In general there seems to be a
> lot of outdated stuff on Worg.  It would be helpful to have at least the
> date of last modification on the pages.
>
> --
> Michael Strey
> http://www.strey.biz * https://twitter.com/michaelstrey
>
>

Re: Modification dates in Worg

[Michael Strey]

On Mo, 2015-09-28 at 17:04, Ista Zahn wrote:
> I've created a worg mirror on github at
> https://github.com/izahn/worg-mirror/, so you can see the modification
> dates via git-blame. 

Thank you.  That will help me and maybe some other people who follow this
thread.  Unfortunately it does not solve the general problem.  Most
people access Worg via HTML.

-- 
Michael Strey
http://www.strey.biz * https://twitter.com/michaelstrey

Re: Modification dates in Worg

[Ista Zahn]

Hi Machael,

Well, you're welcome to add modification dates to the worg files. IMO
this won't help much, since some sections of the same file may be up
to date while other sections may be out of date. Something like
git-blame is needed I think in order to get a sense of how up-to-date
a particular section might be.

Best,
Ista

On Tue, Sep 29, 2015 at 4:06 AM, Michael Strey <mstrey@strey.biz> wrote:
> On Mo, 2015-09-28 at 17:04, Ista Zahn wrote:
>> I've created a worg mirror on github at
>> https://github.com/izahn/worg-mirror/, so you can see the modification
>> dates via git-blame.
>
> Thank you.  That will help me and maybe some other people who follow this
> thread.  Unfortunately it does not solve the general problem.  Most
> people access Worg via HTML.
>
> --
> Michael Strey
> http://www.strey.biz * https://twitter.com/michaelstrey
>
>

Re: babel header arguments tutorial?

[Nick Dokos]

Lawrence Bottorff <borgauf@gmail.com> writes:

> I see this and find the bottom section ("Setting language and file
> specific default header argument value") intriguing, however too
> cryptic. Can someone explain what's going on here and how to use it?
>

Each language defines a variable where you can set header args that will
apply to *all* code block for that language (and there is a
language-independent variable too: org-babel-default-header-args). What
the document you linked to suggests is that you can set such variables
as local file variables (i.e. they are set as part of opening the file
and they are set for that file only).

The mechanism is bog-standard emacs: see (info "(emacs) file variables")
for the details.

The implementation on the page you linked contains a typo (capital P
instead of lower-case p in python) and is much more prolix than it needs
to be. You can get the same effect with

# Local Variables:
# org-babel-default-header-args:python: ((:session . "foo")))
# End:

This form should be preferred for just setting variables. The eval
mechanism should be used only when absolutely necessary.

HTH
-- 
Nick

Re: babel header arguments tutorial?

[Thomas S. Dye]

Aloha Nick,

Nick Dokos <ndokos@gmail.com> writes:

> The implementation on the page you linked contains a typo (capital P
> instead of lower-case p in python) and is much more prolix than it needs
> to be. You can get the same effect with
>
> # Local Variables:
> # org-babel-default-header-args:python: ((:session . "foo")))
> # End:
>
> This form should be preferred for just setting variables. The eval
> mechanism should be used only when absolutely necessary.

Can you elaborate why the eval mechanism should be used only when
absolutely necessary?  You've mentioned that a few times but I haven't
run across similar warnings elsewhere.

Thanks,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: babel header arguments tutorial?

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> writes:

> Aloha Nick,
>
> Nick Dokos <ndokos@gmail.com> writes:
>
>> The implementation on the page you linked contains a typo (capital P
>> instead of lower-case p in python) and is much more prolix than it needs
>> to be. You can get the same effect with
>>
>> # Local Variables:
>> # org-babel-default-header-args:python: ((:session . "foo")))
>> # End:
>>
>> This form should be preferred for just setting variables. The eval
>> mechanism should be used only when absolutely necessary.
>
> Can you elaborate why the eval mechanism should be used only when
> absolutely necessary?  You've mentioned that a few times but I haven't
> run across similar warnings elsewhere.
>

It's a matter of safety: eval allows you to evaluate arbitrary lisp
code. Doing that in a local-variables block which is run when you
open the file can lead to all kinds of damage. If you get a file
with an eval in the local variables section, you'd better be very
sure before opening the file in emacs.

Here's one warning:

http://www.gnu.org/software/emacs/manual/html_node/emacs/Safe-File-Variables.html

-- 
Nick

Re: babel header arguments tutorial?

[Lawrence Bottorff]

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

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
<https://github.com/tj64/org-dp>) . 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?

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?

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.

[-- Attachment #2: Type: text/html, Size: 2521 bytes --]

Re: babel header arguments tutorial?

[Nick Dokos]

Lawrence Bottorff <borgauf@gmail.com> 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

Re: babel header arguments tutorial?

[Thomas S. Dye]

Aloha Nick,

Nick Dokos <ndokos@gmail.com> writes:

> Thomas S. Dye <tsd@tsdye.com> writes:
>
>> Aloha Nick,
>>
>> Nick Dokos <ndokos@gmail.com> writes:
>>
>>> The implementation on the page you linked contains a typo (capital P
>>> instead of lower-case p in python) and is much more prolix than it needs
>>> to be. You can get the same effect with
>>>
>>> # Local Variables:
>>> # org-babel-default-header-args:python: ((:session . "foo")))
>>> # End:
>>>
>>> This form should be preferred for just setting variables. The eval
>>> mechanism should be used only when absolutely necessary.
>>
>> Can you elaborate why the eval mechanism should be used only when
>> absolutely necessary?  You've mentioned that a few times but I haven't
>> run across similar warnings elsewhere.
>>
>
> It's a matter of safety: eval allows you to evaluate arbitrary lisp
> code. Doing that in a local-variables block which is run when you
> open the file can lead to all kinds of damage. If you get a file
> with an eval in the local variables section, you'd better be very
> sure before opening the file in emacs.
>
> Here's one warning:
>
> http://www.gnu.org/software/emacs/manual/html_node/emacs/Safe-File-Variables.html

Thanks for the clarification.  Emacs' built-in paranoia seems
appropriate, I guess.  I get asked if I want to evaluate local variables
that might not be safe and one of my choices is to say no, in which case
the file is opened without evaluating them.  At that point I can look at
the code they propose to run and convince myself there is no mischief.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com