From: Roland Donat <roland.donat@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)]
Date: Thu, 9 May 2013 14:33:06 +0000 (UTC) [thread overview]
Message-ID: <loom.20130509T155325-442@post.gmane.org> (raw)
In-Reply-To: 518B65ED.6070908@easy-emacs.de
Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
>
> Am 08.05.2013 22:50, schrieb Roland Donat:
> >>> Yes, you're right Andreas. It "fails" to show the accented characters
if
> > you
> >>> try to print the entire tuple.
> >>> It fails too if you evaluate a[0][0] in your interpreter. You should
see
> > :
> >>>>>> a[0][0]
> >>> '\xc3\xa9'
> >>> But print a[0][0] gives the expected answer 'é'
> >>>
> >>> So, based on your successful experience consisting in returning a[0]
[0]
> > in
> >>> the orgmode source block, we can assume that org-babel use the python
> > print
> >>> function to display results in org buffer, aren't we?
> >>>
> >>> Another strange behaviour, when you evaluate the src_block test given
in
> >>> example, you get :
> >>> | \303\251 | a |
> >>> | a | \303\240 |
> >>>
> >>> Whereas I was expecting to get the same code than in the python
> > interpreter,
> >>> that is :
> >>> | \xc3\xa9 | a |
> >>> | a | '\xc3\xa0' |
> >>>
> >>> In addition, when I try to save my buffer, Emacs doesn't recognize the
> >>> encoding of characters \303\251 and \303\240 and asks me to choose an
> >>> encoding. Then, I enter utf-8 and nothing happens BUT when I quit and
> > reopen
> >>> my file : the characters are printed correctly.... Too strange for
> > me....
> >>>
> >>> Cheers,
> >>>
> >>> Roland.
> >>
> >> so what about that:
> >>
> >> a = ( ( "é", "a" ), ( "a", "à" ) )
> >> for i, j in a:
> >> print i, j
> >>
> >> BTW previous post was sent prematurely..
> >>
> >> Andreas
> >>
> >>
> >
> > Yep, using a couple of for loops will work but the result won't return
as a
> > table which is a requirement for me.
> >
> > To precise the context a littre more, I have basically 2 source blocks :
> > 1) the famous python block which must return a table
> > 2) a R block used to post-process the previous table
> >
> > Well, thanks for your help.
> > I think I spent too much time on this so I'm thinking about changing my
> > approach. For example, put the result of the first step into a file and
then
> > process the file in step 2.
> >
> > Best regards,
> >
> > Roland.
>
> Just playing a little bit with your example, what about this:
>
> #+begin_src python :results output :preamble # -*- coding: utf-8 -*-
> a = ( ( "é", "a" ), ( "a", "à" ) )
> for i, j in a:
> print("|%s | %s|" % (i, j))
> #+end_src
>
>
Yes Andreas! It works just fine for the python block. But when the python
result arrives as input of my R post
processing code, R receives the following string "| é | a |\n| a | à |\n"
whereas a data.frame is
expected. Indeed, theoretically, when a org-table is used as input of a R
source block, the
org-table is automatically converted into a data.frame which is very
convenient to handle data.
Here is my buffer :
#+name: pytab
#+begin_src python :results output raw :preamble # -*- coding: utf-8 -*-
a = ( ( "é", "a" ), ( "a", "à" ) )
for i, j in a:
print "| {0} | {1} |".format( i, j )
#+end_src
#+TBLNAME: pytab
| é | a |
| a | à |
#+name: Rpostproc
#+begin_src R :results output :session :preamble # -*- coding: utf-8 -*-
:var tab=pytab
print( tab )
#+end_src
#+RESULTS: Rpostproc
: [1] "| é | a |\n| a | à |\n"
In fact, converting the results of my python block into a string looking
like an org-table is what I
used to do before I had to use a R block to post process results.
I assume that org-babel asks for a re-evaluation of "pytab" source block
when "pytab" is used as argument of another source block.
The problem stems from the fact that it's the direct evaluation of "pytab"
(a string) which is used and
not the org-table converted result as shown in the buffer.
Well, I could just convert the R string into a data.frame but it's very
complete with my real data
(non trivial separator problems).
A solution to this problem could be to force org-babel to take as argument
of the R code what is
really shown in the buffer and not the direct result of the python block.
Another solution could be
to stop the re-evaluation of the R arguments.
Anyway, thanks to spend time on this Andreas!
next prev parent reply other threads:[~2013-05-09 14:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-08 6:47 Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)] Andreas Röhler
2013-05-08 7:12 ` Andreas Röhler
2013-05-08 7:58 ` Andreas Röhler
2013-05-08 12:40 ` Eric Schulte
2013-05-08 13:04 ` Andreas Röhler
2013-05-08 13:20 ` Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)] Roland Donat
2013-05-08 13:37 ` Andreas Röhler
2013-05-08 14:02 ` Roland Donat
2013-05-08 14:28 ` Andreas Röhler
2013-05-08 16:11 ` Andreas Röhler
2013-05-08 20:50 ` Roland Donat
2013-05-09 9:01 ` Andreas Röhler
2013-05-09 14:33 ` Roland Donat [this message]
2013-05-09 14:45 ` Andreas Röhler
2013-05-09 19:20 ` Roland Donat
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=loom.20130509T155325-442@post.gmane.org \
--to=roland.donat@gmail.com \
--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).