PERL, org-mode and literal document input.

PERL, org-mode and literal document input.

[Allen S. Rout]

Greetings. 

I've got a YAML config file and some processing I'm doing to it.  I'd
love to have both the bits inside the maintenance document I'm writing
to manage a service.  This seems a perfect use for code blocks and their
evaluation.  However, I get behavior out of my attempt to do this which
I find strange.

I include a minimal, failing example below.

The problem "appears" to be somewhere in the :var reference designed to
introduce the other code block.  There are two problems, one pretty
egregious, the other somewhat subtle.

Egregious first:  

For some reason, whatever process sucks up config_yml and inserts it
into '$config' in mogrify_pl just elides the first two lines. 

Additionally, the contents of the variable are very strangely
formatted.   The contents of most of the first YAML document (less the
first two lines) are each on a separate line.  

However, the last of the first doc and all of the second doc are  in a
single line.


Subtle:

The last few newlines are also elided.  This might not seem to be a big
deal, but YAML really wants to end with a trailing newline.  I figure I
should be able to express that in the doc, and not tag one on in my
code. 

... 

If I add a #+begin_src line to config_yml, and then build a results
section by hand, and copy the identical document there, then the
variable is imported more or less as I'd expect: $config is one large
scalar value, with the contents of config_yml inserted.  The trailing
newlines are still stripped, but this is better at least.


I've been searching for something like "Echo this" to put in my
begin_src; it would seem a little silly but not awful to define a
process to just copy the contents of the source block to the result, and
go from there.   But it's inelegant, to say the least. 

... 

So: Is there a conventional way I should get org to treat the source
block 'the same way' it treats the results block?  Failing that, is
there a common idiom to run a source block to get the result "Echo me
verbatim into the results block" ? 

I see profligate use of org-babel-trim in the code.  Does that mean that
permitting leading or trailing whitespace is a regular source of
problems?  I didn't want to start dinking with it casually. 

... 


Any pointers would be deeply appreciated. 


*** YAML transform. 

#+srcname: config_yml
---
erpalpha:
   - alpha-rac-1.erp.ufl.edu
   - alpha-rac-2.erp.ufl.edu
erpbeta:
   - beta-rac-1.erp.ufl.edu
   - beta-rac-2.erp.ufl.edu
---
erpalpha:
  FS: /export/alpha
  nodes:
    erpalpha: ''
    erpbeta: RO

erpbeta:
  FS: /export/beta
  nodes:
    erpalpha: RO
    erpbeta: 


#+end_src


#+srcname: mogrify_pl
#+begin_src perl :results output :var config=config_yml()
  use YAML();
  use Data::Dumper;

  # $stream = join("",<$foo>);

print "===$config===\n";

print $#config,"\n";
  
foreach $line (@{$config})
{ print "[$line]\n"; }

print Dumper($config);


# ($nodegroups,$filespaces) = YAML::Load($config);
#  print YAML::Dump($nodegroups,$filespaces);
  
#+end_src

#+results: mogrify_pl
#+begin_example
===ARRAY(0x853b818)===
-1
[alpha-rac-1.erp.ufl.edu]
[alpha-rac-2.erp.ufl.edu
erpbeta:]
[beta-rac-1.erp.ufl.edu]
[beta-rac-2.erp.ufl.edu
---
erpalpha:
  FS: /export/alpha
  nodes:
    erpalpha: ''
    erpbeta: RO

erpbeta:
  FS: /export/beta
  nodes:
    erpalpha: RO
    erpbeta:]
$VAR1 = [
          'alpha-rac-1.erp.ufl.edu',
          'alpha-rac-2.erp.ufl.edu
erpbeta:',
          'beta-rac-1.erp.ufl.edu',
          'beta-rac-2.erp.ufl.edu
---
erpalpha:
  FS: /export/alpha
  nodes:
    erpalpha: \'\'
    erpbeta: RO

erpbeta:
  FS: /export/beta
  nodes:
    erpalpha: RO
    erpbeta:'
        ];
#+end_example


- Allen S. Rout

Re: PERL, org-mode and literal document input.

[Eric Schulte]

Hi Allen,

Judging from your example org-mode text below I would suggest the
following...

First, the block of yaml is miss-formed, you have a "#+source:" line, and
a "#end_src" line, but you are missing a required "#+begin_src yaml".

Second, if you will be referencing the contents of a yaml code block you
will need to define an `org-babel-execute:yaml' function.  For the
simple case of returning the contents of the code block the following
will work.

  (defun org-babel-execute:yaml (body params) body)

alternately you could just include your yaml as an example block

#+results: yaml-config
: erpalpha:...

I hope some of the above works for you.  Please let me know if either of
these solutions are appropriate.

Best -- Eric

asr@ufl.edu (Allen S. Rout) writes:

> Greetings. 
>
> I've got a YAML config file and some processing I'm doing to it.  I'd
> love to have both the bits inside the maintenance document I'm writing
> to manage a service.  This seems a perfect use for code blocks and their
> evaluation.  However, I get behavior out of my attempt to do this which
> I find strange.
>
> I include a minimal, failing example below.
>
> The problem "appears" to be somewhere in the :var reference designed to
> introduce the other code block.  There are two problems, one pretty
> egregious, the other somewhat subtle.
>
> Egregious first:  
>
> For some reason, whatever process sucks up config_yml and inserts it
> into '$config' in mogrify_pl just elides the first two lines. 
>
> Additionally, the contents of the variable are very strangely
> formatted.   The contents of most of the first YAML document (less the
> first two lines) are each on a separate line.  
>
> However, the last of the first doc and all of the second doc are  in a
> single line.
>
>
> Subtle:
>
> The last few newlines are also elided.  This might not seem to be a big
> deal, but YAML really wants to end with a trailing newline.  I figure I
> should be able to express that in the doc, and not tag one on in my
> code. 
>
> ... 
>
> If I add a #+begin_src line to config_yml, and then build a results
> section by hand, and copy the identical document there, then the
> variable is imported more or less as I'd expect: $config is one large
> scalar value, with the contents of config_yml inserted.  The trailing
> newlines are still stripped, but this is better at least.
>
>
> I've been searching for something like "Echo this" to put in my
> begin_src; it would seem a little silly but not awful to define a
> process to just copy the contents of the source block to the result, and
> go from there.   But it's inelegant, to say the least. 
>
> ... 
>
> So: Is there a conventional way I should get org to treat the source
> block 'the same way' it treats the results block?  Failing that, is
> there a common idiom to run a source block to get the result "Echo me
> verbatim into the results block" ? 
>
> I see profligate use of org-babel-trim in the code.  Does that mean that
> permitting leading or trailing whitespace is a regular source of
> problems?  I didn't want to start dinking with it casually. 
>
> ... 
>
>
> Any pointers would be deeply appreciated. 
>
>
> *** YAML transform. 
>
> #+srcname: config_yml
> ---
> erpalpha:
>    - alpha-rac-1.erp.ufl.edu
>    - alpha-rac-2.erp.ufl.edu
> erpbeta:
>    - beta-rac-1.erp.ufl.edu
>    - beta-rac-2.erp.ufl.edu
> ---
> erpalpha:
>   FS: /export/alpha
>   nodes:
>     erpalpha: ''
>     erpbeta: RO
>
> erpbeta:
>   FS: /export/beta
>   nodes:
>     erpalpha: RO
>     erpbeta: 
>
>
> #+end_src
>
>
> #+srcname: mogrify_pl
> #+begin_src perl :results output :var config=config_yml()
>   use YAML();
>   use Data::Dumper;
>
>   # $stream = join("",<$foo>);
>
> print "===$config===\n";
>
> print $#config,"\n";
>   
> foreach $line (@{$config})
> { print "[$line]\n"; }
>
> print Dumper($config);
>
>
> # ($nodegroups,$filespaces) = YAML::Load($config);
> #  print YAML::Dump($nodegroups,$filespaces);
>   
> #+end_src
>
> #+results: mogrify_pl
> #+begin_example
> ===ARRAY(0x853b818)===
> -1
> [alpha-rac-1.erp.ufl.edu]
> [alpha-rac-2.erp.ufl.edu
> erpbeta:]
> [beta-rac-1.erp.ufl.edu]
> [beta-rac-2.erp.ufl.edu
> ---
> erpalpha:
>   FS: /export/alpha
>   nodes:
>     erpalpha: ''
>     erpbeta: RO
>
> erpbeta:
>   FS: /export/beta
>   nodes:
>     erpalpha: RO
>     erpbeta:]
> $VAR1 = [
>           'alpha-rac-1.erp.ufl.edu',
>           'alpha-rac-2.erp.ufl.edu
> erpbeta:',
>           'beta-rac-1.erp.ufl.edu',
>           'beta-rac-2.erp.ufl.edu
> ---
> erpalpha:
>   FS: /export/alpha
>   nodes:
>     erpalpha: \'\'
>     erpbeta: RO
>
> erpbeta:
>   FS: /export/beta
>   nodes:
>     erpalpha: RO
>     erpbeta:'
>         ];
> #+end_example
>
>
> - Allen S. Rout
>
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: PERL, org-mode and literal document input.

[Allen S. Rout]

"Eric Schulte" <schulte.eric@gmail.com> writes:

> alternately you could just include your yaml as an example block
>
> #+results: yaml-config
> : erpalpha:...

This is what I've eventually done.  It feels dirty; I'm asserting the
"results" block of a nonexistent src, and saying "edit this".  But
perhaps I should just deal with it.

Am I silly to want to be able to label it 'srcname' instead of
'results'?  My elisp-fu is not good enough to let me define 

:var-but-read-the-src-block 

- Allen S. Rout

Re: PERL, org-mode and literal document input.

[Eric Schulte]

asr@ufl.edu (Allen S. Rout) writes:

> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> alternately you could just include your yaml as an example block
>>
>> #+results: yaml-config
>> : erpalpha:...
>
> This is what I've eventually done.  It feels dirty; I'm asserting the
> "results" block of a nonexistent src, and saying "edit this".  But
> perhaps I should just deal with it.
>
> Am I silly to want to be able to label it 'srcname' instead of
> 'results'?  My elisp-fu is not good enough to let me define 
>
> :var-but-read-the-src-block 
>

These are just labels, and more than that they are just the labels that
first occurred to Dan and I.  Semantically they are used to name data,
and I can understand your "dirty" feeling of having results without a
related code block, but rest assured, Babel does not assume that there
should exist such a code block and this sort of usage is both supported
and intended.

To emphasize this point, I've just pushed up a change so that you can
now label such inline data with

#+data: my-named-data
: 3

and more importantly you can add your own labels by customizing the new
`org-babel-data-names' variable.

Cheers -- Eric
n
Note: if you update the `org-babel-data-names' variable you might want
to later run the following code...

(setq org-babel-result-regexp
  (concat "^[ \t]*#\\+"
	  (regexp-opt org-babel-data-names)
	  "\\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*"))

>
> - Allen S. Rout
>
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/