org-babel feature request

org-babel feature request

[Maurizio Vitale]

Thanks for the work on org-babel.

I'm not sure the following is even mature enough in my mind to qualify
it as a feature request. Maybe in the end it might be replaced by some
other functionality that subsume it.

But here's the scenario: I'd like to use org-babel for documenting the
configuration and setup of my computing infrastructure. Up to now I've
done it w/ plain org-mode, but having the documents being executable
would be very nice.

As a manner of example, let's take a fragment from my backup
infrastructure:

#+srcname: amanda_config_info
#+begin_src sh
for v in CLIENT_LOGIN CONFIG_DIR AMANDA_DBGDIR libexecdir listed_incr_dir; do
echo -n $v
sudo -u backup /usr/local/amanda/sbin/amadmin xx version|perl -ne "s,^.*\b$v=\"([^\"]+)\".*$, \1,g && print"
done
#+end_src

#+resname: amanda_config_info
| "CLIENT_LOGIN"    | "backup"                                    |
| "CONFIG_DIR"      | "/usr/local/amanda/etc/amanda"              |
| "AMANDA_DBGDIR"   | "/tmp/amanda"                               |
| "libexecdir"      | "/usr/local/amanda/libexec"                 |
| "listed_incr_dir" | "/usr/local/amanda/var/amanda/gnutar-lists" |

It would be nice if it was possible to have multiple result
sections. This way I could embed in the document the result that was
obtained when writing the documentation, while still allowing the person
following the recipe to evaluate again the shell script and get the
results on his machine.

The first section should be read-only (not necessarily physically
read-only, but skipped by C-c C-c). The others may be re-evaluated over
and over until the end user has a valid configuration.

I'm not sure whether there's something more general than this, like
attaching tags (that could be even elisp function) to result sections
that do different things, one of which being enabling the section to
receive results.

Ok, I'm just bouncing ideas in case others see something useful. I've
just started using org-babel and maybe I'll see different ways for
achieving this.

Thanks again for org-babel,

       Maurizio

Re: org-babel feature request

[Dan Davison]

Maurizio Vitale
<mav@cuma.i-did-not-set--mail-host-address--so-tickle-me> writes:

[...]

> It would be nice if it was possible to have multiple result
> sections. This way I could embed in the document the result that was
> obtained when writing the documentation, while still allowing the person
> following the recipe to evaluate again the shell script and get the
> results on his machine.
>
> The first section should be read-only (not necessarily physically
> read-only, but skipped by C-c C-c). The others may be re-evaluated over
> and over until the end user has a valid configuration.

Hi Maurizio,

Once I've obtained the results that I want to "freeze", I would manually
alter (or even delete) the #+resname tag, so that the source block no
longer overwrites it. Is that simple solution appropriate? I'm not yet
seeing the advantage of the more complex possibilities.

Dan


>
> I'm not sure whether there's something more general than this, like
> attaching tags (that could be even elisp function) to result sections
> that do different things, one of which being enabling the section to
> receive results.
>
> Ok, I'm just bouncing ideas in case others see something useful. I've
> just started using org-babel and maybe I'll see different ways for
> achieving this.
>
> Thanks again for org-babel,
>
>        Maurizio
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: org-babel feature request

[Maurizio Vitale]

>>>>> "Dan" == Dan Davison <davison@stats.ox.ac.uk> writes:

    Dan> Maurizio Vitale
    Dan> <mav@cuma.i-did-not-set--mail-host-address--so-tickle-me>
    Dan> writes:

    Dan> [...]

    >> It would be nice if it was possible to have multiple result
    >> sections. This way I could embed in the document the result that
    >> was obtained when writing the documentation, while still allowing
    >> the person following the recipe to evaluate again the shell
    >> script and get the results on his machine.
    >> 
    >> The first section should be read-only (not necessarily physically
    >> read-only, but skipped by C-c C-c). The others may be
    >> re-evaluated over and over until the end user has a valid
    >> configuration.

    Dan> Hi Maurizio,

    Dan> Once I've obtained the results that I want to "freeze", I would
    Dan> manually alter (or even delete) the #+resname tag, so that the
    Dan> source block no longer overwrites it. Is that simple solution
    Dan> appropriate? I'm not yet seeing the advantage of the more
    Dan> complex possibilities.

That is the obvious possibility, but at times you may want to
re-evaluate those: either the configuration has changed, or the software
you're documenting has changed or the script you're using is buggy.

Yes you could reintroduce the #+resname tag when needed, but I'm hoping
to get more automation than M-x shell-command-on-region.

I've just started using org-babel in this way, so I'm not sure at all of
what features I'll feel in the end needed. This seems one right now.

Best regards,

     Maurizio

-- 

Re: org-babel feature request

[Dan Davison]

Maurizio Vitale <maurizio.vitale@polymath-solutions.com> writes:

>>>>>> "Dan" == Dan Davison <davison@stats.ox.ac.uk> writes:
>
>     Dan> Maurizio Vitale
>     Dan> <mav@cuma.i-did-not-set--mail-host-address--so-tickle-me>
>     Dan> writes:
>
>     Dan> [...]
>
>     >> It would be nice if it was possible to have multiple result
>     >> sections. This way I could embed in the document the result that
>     >> was obtained when writing the documentation, while still allowing
>     >> the person following the recipe to evaluate again the shell
>     >> script and get the results on his machine.
>     >> 
>     >> The first section should be read-only (not necessarily physically
>     >> read-only, but skipped by C-c C-c). The others may be
>     >> re-evaluated over and over until the end user has a valid
>     >> configuration.
>
>     Dan> Hi Maurizio,
>
>     Dan> Once I've obtained the results that I want to "freeze", I would
>     Dan> manually alter (or even delete) the #+resname tag, so that the
>     Dan> source block no longer overwrites it. Is that simple solution
>     Dan> appropriate? I'm not yet seeing the advantage of the more
>     Dan> complex possibilities.
>
> That is the obvious possibility, but at times you may want to
> re-evaluate those: either the configuration has changed, or the software
> you're documenting has changed or the script you're using is buggy.
>
> Yes you could reintroduce the #+resname tag when needed, but I'm hoping
> to get more automation than M-x shell-command-on-region.

The other, perhaps nicer, thing you can do is change the #+srcname of
the block which has the effect of changing the results block. You can do
that now. But maybe we could allow the user to over-ride the default way
in which the #+resname tag is set? E.g. by adding a :resname header
argument.

Something like this:

--8<---------------cut here---------------start------------->8---
#+srcname: test2
#+begin_src sh :resname test2-redirected
  expr 2 + 3
#+end_src

#+resname: test2
: 4

#+resname: test2-redirected
: 5
--8<---------------cut here---------------end--------------->8---

Do you think that would be worthwhile?

Dan



>
> I've just started using org-babel in this way, so I'm not sure at all of
> what features I'll feel in the end needed. This seems one right now.
>
> Best regards,
>
>      Maurizio

Re: org-babel feature request

[Maurizio Vitale]

>>>>> "Dan" == Dan Davison <davison@stats.ox.ac.uk> writes:

    Dan> Maurizio Vitale <maurizio.vitale@polymath-solutions.com>
    Dan> writes:
    >>>>>>> "Dan" == Dan Davison <davison@stats.ox.ac.uk> writes:
    >> 
    Dan> Maurizio Vitale
    Dan> <mav@cuma.i-did-not-set--mail-host-address--so-tickle-me>
    Dan> writes:
    >> 
    Dan> [...]
    >> 
    >> >> It would be nice if it was possible to have multiple result >>
    >> sections. This way I could embed in the document the result that
    >> >> was obtained when writing the documentation, while still
    >> allowing >> the person following the recipe to evaluate again the
    >> shell >> script and get the results on his machine.
    >> >> 
    >> >> The first section should be read-only (not necessarily
    >> physically >> read-only, but skipped by C-c C-c). The others may
    >> be >> re-evaluated over and over until the end user has a valid
    >> >> configuration.
    >> 
    Dan> Hi Maurizio,
    >> 
    Dan> Once I've obtained the results that I want to "freeze", I would
    Dan> manually alter (or even delete) the #+resname tag, so that the
    Dan> source block no longer overwrites it. Is that simple solution
    Dan> appropriate? I'm not yet seeing the advantage of the more
    Dan> complex possibilities.
    >> 
    >> That is the obvious possibility, but at times you may want to
    >> re-evaluate those: either the configuration has changed, or the
    >> software you're documenting has changed or the script you're
    >> using is buggy.
    >> 
    >> Yes you could reintroduce the #+resname tag when needed, but I'm
    >> hoping to get more automation than M-x shell-command-on-region.

    Dan> The other, perhaps nicer, thing you can do is change the
    Dan> #+srcname of the block which has the effect of changing the
    Dan> results block. You can do that now. But maybe we could allow
    Dan> the user to over-ride the default way in which the #+resname
    Dan> tag is set? E.g. by adding a :resname header argument.

    Dan> Something like this:

    Dan> #+srcname: test2 #+begin_src sh :resname test2-redirected expr
    Dan> 2 + 3 #+end_src

    Dan> #+resname: test2 : 4

    Dan> #+resname: test2-redirected : 5

    Dan> Do you think that would be worthwhile?

Too early for me to say. First reaction is that I don't see particular
advantages in the :resname method over the changing the src name to
justify the additional implementation effort.

What I think would be useful is a way to switch all results/srcnames in
a file by adding a prefix/suffix. So:
#+srcname test
would cause results to go to #+resname: test if
org-mode-babel-source-prefix is nil, but would go to
#+resname: example-test if
org-mode-babel-source-prefix is "example-"
and then org-mode-babel-source-prefix could be set somewhere in the
headers.
Maybe the #+resname which is updated could be marked with a '*' so that
if somebody does C-c C-c and doesn't see an update he's reminded that
the result block is not active because of a prefix.

Thanks for the suggestion of changing the source block name: it goes a
long way towards what I need.


    >> 
    >> I've just started using org-babel in this way, so I'm not sure at
    >> all of what features I'll feel in the end needed. This seems one
    >> right now.
    >> 
    >> Best regards,
    >> 
    >> Maurizio


--