emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Re: [BUG] org-babel-perl and formats


From: Dan Davison
Subject: Re: [Orgmode] Re: [BUG] org-babel-perl and formats
Date: Fri, 09 Apr 2010 09:21:34 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Łukasz Stelmach <address@hidden> writes:

> Dan Davison <address@hidden> writes:
>
>> Łukasz Stelmach <address@hidden> writes:
>>> I am not sure I will be able to spend some time on this so I'll share my
>>> observation with you. org-babel-perl can't cope with perl formats, with
>>> their endings to be precise. A format is defined by:
>>>
>>> format FORMAT_NAME = 
>>> body of the format
>>> .
>>>
>>> The problem is that formats *must* and with a single solitary dot or, to
>>> be precise "\n.\n" sequence. org-babel-perl doesn't care about it and
>>> puts "\t" befor the dot.
>>
>> Could you post an example? I don't believe we insert tab
>> characters. I've never used a perl format before, but I just tried it
>> and it seemed to work OK with C-c C-c:
>>
>> #+begin_src perl
>>   format STDOUT =
>>   @<<<<<< @|||||| @>>>>>>
>>   "left", "middle", "right"
>>   .
>>   write ;
>> #+end_src
>>
>> #+results:
>> : left    middle    right
>
> With the very same code i get
>
> Format not terminated at - line 11, at end of line
> syntax error at - line 11, at EOF
> Execution of - aborted due to compilation errors.

Oops. Sorry Łukasz, my mistake.

You are of course right, we were adding indentation to perl code
(apparently I started with a copy of org-babel-python.el when I wrote
org-babel-perl.el). That is fixed now.

We got different results because I had set perl to :results output by
default. For this particular block, you will also want to use
:results output (see below).

You pointed out that

>
> while strace shows the code being wrapped
>
> write(9, "\nsub main {\n\tformat STDOUT =\n\t@<<<<<< @|||||| 
> @>>>>>>\n\t\"left\", \"middle\", \"right\"\n\t.\n\twrite ;address@hidden = 
> main;\nopen(o, \">/tmp/perl-functional-results17170oCG\");\nprint o 
> join(\"\\n\", @r), \"\\n\"", 184) = 184
>
> inside something really odd:
>
>   sub main {
>           format STDOUT =
>           @<<<<<< @|||||| @>>>>>>
>           "left", "middle", "right"
>           .
>           write ;
>   }
>   @r = main;
>   open(o, ">/tmp/perl-functional-results17170oCG");
>   print o join("\n", @r), "\n"

Babel has two basic modes of execution:
:results value  ::  The default, you get the value of the last expression, 
interpreted as a list/table if possible.
:results output ::  You get stdout

The wrapping-in-function-body stuff only happens with :results value.

So by default, with the block above, you will get the counterintuitive outcome:

#+results:
| 1 |
| 1 |

The default outcome here is fairly baffling, and I imagine that perl
users are often going to want the contents of stdout. This can be done
globally with

(setq org-babel-default-header-args:perl '((:results . "output")))

The trouble with that is that perl blocks will not communicate nicely
with other blocks:

#+source: a-number
#+begin_src perl :results value
4
#+end_src

#+begin_src emacs-lisp :var i=a-number()
(+ i 1)
#+end_src

#+results:
: 5

With :results output on the perl block, we get a

   Wrong type argument: number-or-marker-p, ""

because the perl block returns textual output rather than interpreting
the result as numeric.

Dan

>
>> Incidentally, do you know the variable org-src-preserve-indentation?
>> When I first read your email I thought that would be the answer. In fact
>> it doesn't seem to be relevant, but I thought I would mention it anyway.
>
> Unfortunately it doesn't make any difference.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]