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

2011-05-06 Thread Eric Schulte
a...@ufl.edu (Allen S. Rout) writes:

> "Eric Schulte"  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/



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

2011-05-06 Thread Allen S. Rout
"Eric Schulte"  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: [O] PERL, org-mode and literal document input.

2011-05-05 Thread 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

a...@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/