emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: dmg <dmg@uvic.ca>
To: emacs-orgmode@gnu.org
Subject: Re: evaluation of perl in babel
Date: Sun, 24 Feb 2013 13:25:58 -0800	[thread overview]
Message-ID: <CAEBXXD-tQz2Ke2VZcdLx68HmF2xoqHpegNmit=hxstKm8pW59Q@mail.gmail.com> (raw)
In-Reply-To: <87hal1whbc.fsf@mn.cs.uvic.ca>

Mm, I didn't include :results value

I think that :results value should do what it does now: return the
value of the last expression.

--dmg

On Sun, Feb 24, 2013 at 1:08 PM, D M German <dmg@uvic.ca> wrote:
>
> Hi Everybody,
>
> I looked a bit more onto the way that perl is evaluated. I know the
> support of perl is minor. I understand that, so please, don't see this
> message as a complaint, so this is more for discussion and potential
> improvements of the Perl support in Babel.
>
> One of the things I have noticed is that the way that Babel handles the
> results coming from the code is not the best.
>
> Let me elaborate:
>
> At the bottom you will find a set of test that stress the different
> :results types.
>
> There are some bugs. For example, the interpretation of :results table,
> vector and list.
>
> But I think the main problem comes from the way that Babel expects the
> result. In Babel, and except for :results output, the last expression in
> perl is considered the input to the results. This is implementing by
> saving the last expression into a variable, and printing each value
> separated by a "\n" (including the last). So basically, org takes the
> last expression, and outputs them to the babel input file one per line.
>
> This places some constraints. First, it is not currently capable of
> dealing with two dimensional arrays. Second, it makes it hard to create
> complex output (such as HTML or LaTeX), and third, it is hard to debug
> without first printing the value of the array (this output would be lost
> during the evaluation, so it would have be debugged outside org).
>
> I feel that a better approach is to use std output as the default input
> to any of these :results types, and then try to parse them into the
> corresponding :results types. This will allow the creation of HTML and
> LaTeX from perl (which the current implementation does not allow).
>
> So recapitulating, my suggestion is that perl should use STDOUT as the
> output of the snippet in any :results type, rather than the result of
> the last expression.
>
> I know this will break backwards compatibility. One solution is to keep
> the current src perl and add a new perl_stdout mode (or something like
> that) that implements this.
>
> --dmg
>
>
>
> ----------------------------------------------------------------------
> #+begin_src perl :results output
> print "Test\n";
> (1, 2)
> #+end_src
>
> #+RESULTS:
> : Test
>
> #+name: t_output_raw
> #+begin_src perl :results raw
> print "Test\n";
> (1, 2)
> #+end_src
>
> #+RESULTS: t_output_raw
> 1
> 2
>
> #+name: t_output_table
> #+begin_src perl :results table
> print "Test\n";
> (1, 2)
> #+end_src
>
> #+RESULTS: t_output_table
> | 1\n2\n |
>
> #+name: t_output_vector
> #+begin_src perl :results vector
> print "Test\n";
> (1, 2)
> #+end_src
>
> #+RESULTS: t_output_vector
> | 1\n2\n |
>
>
> #+name: t_output_list
> #+begin_src perl :results list
> print "Test\n";
> (1, 2)
> #+end_src
>
> #+RESULTS: t_output_list
> #+begin_example
> - 1
> 2
> #+end_example
>
> #+name: t_output_org
> #+begin_src perl :results org
> print "Test\n";
> (1, 2)
> #+end_src
>
> #+RESULTS: t_output_org
> #+BEGIN_SRC org
> 1
> 2
> #+END_SRC
>
> #+name: t_output_html
> #+begin_src perl :results html
> print "Test\n";
> (1, 2)
> #+end_src
>
> #+RESULTS: t_output_html
> #+BEGIN_HTML
> 1
> 2
> #+END_HTML
>
> #+name: t_output_latex
> #+begin_src perl :results latex
> print "Test\n";
> (1, 2)
> #+end_src
>
> #+RESULTS: t_output_latex
> #+BEGIN_LaTeX
> 1
> 2
> #+END_LaTeX
> ----------------------------------------------------------------------
>
>
> --
> Daniel M. German                  "I see no good reason why the
>                                    views given in this volume
>                                    should shock the religious
>    Charles Darwin ->               feelings of anyone."
> http://turingmachine.org/
> http://silvernegative.com/
> dmg (at) uvic (dot) ca
> replace (at) with @ and (dot) with .
>
>



-- 
--dmg

---
Daniel M. German
http://turingmachine.org

  reply	other threads:[~2013-02-24 21:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-24 21:08 evaluation of perl in babel D M German
2013-02-24 21:25 ` dmg [this message]
2013-02-24 22:09 ` Achim Gratz
2013-02-25  9:54   ` D M German
2013-02-25  9:57     ` dmg
2013-02-25 14:11       ` Eric Schulte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEBXXD-tQz2Ke2VZcdLx68HmF2xoqHpegNmit=hxstKm8pW59Q@mail.gmail.com' \
    --to=dmg@uvic.ca \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).