* babel header arguments tutorial?
@ 2015-09-26 18:39 Lawrence Bottorff
2015-09-26 21:39 ` Charles C. Berry
2015-09-26 22:09 ` babel header arguments tutorial? Nick Dokos
0 siblings, 2 replies; 12+ messages in thread
From: Lawrence Bottorff @ 2015-09-26 18:39 UTC (permalink / raw)
To: emacs-orgmode Mailinglist
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: babel header arguments tutorial? 2015-09-26 18:39 babel header arguments tutorial? Lawrence Bottorff @ 2015-09-26 21:39 ` Charles C. Berry 2015-09-27 8:22 ` Modification dates in Worg (was: babel header arguments tutorial?) Michael Strey 2015-09-26 22:09 ` babel header arguments tutorial? Nick Dokos 1 sibling, 1 reply; 12+ messages in thread From: Charles C. Berry @ 2015-09-26 21:39 UTC (permalink / raw) To: Lawrence Bottorff; +Cc: emacs-orgmode Mailinglist 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Modification dates in Worg (was: babel header arguments tutorial?) 2015-09-26 21:39 ` Charles C. Berry @ 2015-09-27 8:22 ` Michael Strey 2015-09-28 15:04 ` Ista Zahn 0 siblings, 1 reply; 12+ messages in thread From: Michael Strey @ 2015-09-27 8:22 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Modification dates in Worg (was: babel header arguments tutorial?) 2015-09-27 8:22 ` Modification dates in Worg (was: babel header arguments tutorial?) Michael Strey @ 2015-09-28 15:04 ` Ista Zahn 2015-09-29 8:06 ` Modification dates in Worg Michael Strey 0 siblings, 1 reply; 12+ messages in thread From: Ista Zahn @ 2015-09-28 15:04 UTC (permalink / raw) To: Michael Strey; +Cc: emacs-orgmode Mailinglist 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 > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Modification dates in Worg 2015-09-28 15:04 ` Ista Zahn @ 2015-09-29 8:06 ` Michael Strey 2015-09-29 14:38 ` Ista Zahn 0 siblings, 1 reply; 12+ messages in thread From: Michael Strey @ 2015-09-29 8:06 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Modification dates in Worg 2015-09-29 8:06 ` Modification dates in Worg Michael Strey @ 2015-09-29 14:38 ` Ista Zahn 0 siblings, 0 replies; 12+ messages in thread From: Ista Zahn @ 2015-09-29 14:38 UTC (permalink / raw) To: Michael Strey; +Cc: emacs-orgmode Mailinglist 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 > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: babel header arguments tutorial? 2015-09-26 18:39 babel header arguments tutorial? Lawrence Bottorff 2015-09-26 21:39 ` Charles C. Berry @ 2015-09-26 22:09 ` Nick Dokos 2015-09-26 22:43 ` Thomas S. Dye 1 sibling, 1 reply; 12+ messages in thread From: Nick Dokos @ 2015-09-26 22:09 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: babel header arguments tutorial? 2015-09-26 22:09 ` babel header arguments tutorial? Nick Dokos @ 2015-09-26 22:43 ` Thomas S. Dye 2015-09-27 2:41 ` Nick Dokos 0 siblings, 1 reply; 12+ messages in thread From: Thomas S. Dye @ 2015-09-26 22:43 UTC (permalink / raw) To: Nick Dokos; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: babel header arguments tutorial? 2015-09-26 22:43 ` Thomas S. Dye @ 2015-09-27 2:41 ` Nick Dokos 2015-09-27 16:28 ` Lawrence Bottorff 2015-09-27 16:47 ` Thomas S. Dye 0 siblings, 2 replies; 12+ messages in thread From: Nick Dokos @ 2015-09-27 2:41 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: babel header arguments tutorial? 2015-09-27 2:41 ` Nick Dokos @ 2015-09-27 16:28 ` Lawrence Bottorff 2015-09-27 19:51 ` Nick Dokos 2015-09-27 16:47 ` Thomas S. Dye 1 sibling, 1 reply; 12+ messages in thread From: Lawrence Bottorff @ 2015-09-27 16:28 UTC (permalink / raw) To: emacs-orgmode Mailinglist [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: babel header arguments tutorial? 2015-09-27 16:28 ` Lawrence Bottorff @ 2015-09-27 19:51 ` Nick Dokos 0 siblings, 0 replies; 12+ messages in thread From: Nick Dokos @ 2015-09-27 19:51 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: babel header arguments tutorial? 2015-09-27 2:41 ` Nick Dokos 2015-09-27 16:28 ` Lawrence Bottorff @ 2015-09-27 16:47 ` Thomas S. Dye 1 sibling, 0 replies; 12+ messages in thread From: Thomas S. Dye @ 2015-09-27 16:47 UTC (permalink / raw) To: Nick Dokos; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-09-29 14:39 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-09-26 18:39 babel header arguments tutorial? Lawrence Bottorff 2015-09-26 21:39 ` Charles C. Berry 2015-09-27 8:22 ` Modification dates in Worg (was: babel header arguments tutorial?) Michael Strey 2015-09-28 15:04 ` Ista Zahn 2015-09-29 8:06 ` Modification dates in Worg Michael Strey 2015-09-29 14:38 ` Ista Zahn 2015-09-26 22:09 ` babel header arguments tutorial? Nick Dokos 2015-09-26 22:43 ` Thomas S. Dye 2015-09-27 2:41 ` Nick Dokos 2015-09-27 16:28 ` Lawrence Bottorff 2015-09-27 19:51 ` Nick Dokos 2015-09-27 16:47 ` Thomas S. Dye
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).