* Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]
@ 2013-05-08 6:47 Andreas Röhler
2013-05-08 7:12 ` Andreas Röhler
0 siblings, 1 reply; 15+ messages in thread
From: Andreas Röhler @ 2013-05-08 6:47 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2858 bytes --]
Executing the following SRC block via C-c C-c get's a wrong display - see attachment.
Whilst copying it into another buffer --here for report-- fixes it.
Also a column bug.
#+NAME: test
#+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return a
a = ( ( "é", "a" ), ( "a", "à" ) )
#+end_src
#+RESULTS: test
| é | a |
| a | à |
Emacs : GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 2.24.14)
of 2013-03-05
Package: Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)
current state:
==============
(setq
org-export-blocks '((src org-babel-exp-src-block nil) (export-comment org-export-blocks-format-comment t)
(ditaa org-export-blocks-format-ditaa nil) (dot org-export-blocks-format-dot nil))
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe)
org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-select-beamer-code)
org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook)
org-babel-pre-tangle-hook '(save-buffer)
org-occur-hook '(org-first-headline-recenter)
org-export-interblocks '((src org-babel-exp-non-block-elements))
org-metaup-hook '(org-babel-load-in-session-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-export-latex-format-toc-function 'org-export-latex-format-toc-default
org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link-modifiers)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-export-first-hook '(org-beamer-initialize-open-trackers)
org-mode-hook '(#[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-show-block-all append local] 5]
#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc org-beamer-auto-fragile-frames
org-beamer-place-default-actions-for-lists)
org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el"))
org-babel-load-languages '((sh . t) (python . t))
org-confirm-shell-link-function 'yes-or-no-p
)
[-- Attachment #2: tuple-display.png --]
[-- Type: image/png, Size: 41605 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)] 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 0 siblings, 1 reply; 15+ messages in thread From: Andreas Röhler @ 2013-05-08 7:12 UTC (permalink / raw) To: emacs-orgmode org-babel-python-mode was python3 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)] 2013-05-08 7:12 ` Andreas Röhler @ 2013-05-08 7:58 ` Andreas Röhler 2013-05-08 12:40 ` Eric Schulte 0 siblings, 1 reply; 15+ messages in thread From: Andreas Röhler @ 2013-05-08 7:58 UTC (permalink / raw) To: emacs-orgmode Am 08.05.2013 09:12, schrieb Andreas Röhler: > org-babel-python-mode > > was python3 > > errrr, org-babel-python-command ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)] 2013-05-08 7:58 ` Andreas Röhler @ 2013-05-08 12:40 ` Eric Schulte 2013-05-08 13:04 ` Andreas Röhler 0 siblings, 1 reply; 15+ messages in thread From: Eric Schulte @ 2013-05-08 12:40 UTC (permalink / raw) To: Andreas Röhler; +Cc: emacs-orgmode Andreas Röhler <andreas.roehler@easy-emacs.de> writes: > Am 08.05.2013 09:12, schrieb Andreas Röhler: >> org-babel-python-mode >> >> was python3 >> >> > > errrr, org-babel-python-command > I can't reproduce this problem. After evaluating the following (setq org-babel-python-command "python3") The utf-8 example works perfectly for me (and apparently for the other poster in the previous thread as well). Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)] 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 0 siblings, 1 reply; 15+ messages in thread From: Andreas Röhler @ 2013-05-08 13:04 UTC (permalink / raw) To: Eric Schulte; +Cc: emacs-orgmode Am 08.05.2013 14:40, schrieb Eric Schulte: > Andreas Röhler <andreas.roehler@easy-emacs.de> writes: > >> Am 08.05.2013 09:12, schrieb Andreas Röhler: >>> org-babel-python-mode >>> >>> was python3 >>> >>> >> >> errrr, org-babel-python-command >> > > I can't reproduce this problem. After evaluating the following > > (setq org-babel-python-command "python3") > > The utf-8 example works perfectly for me (and apparently for the other > poster in the previous thread as well). > > Cheers, > hmm, indeed, shows up nicely now. Please close, cheers, Andreas ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)] 2013-05-08 13:04 ` Andreas Röhler @ 2013-05-08 13:20 ` Roland Donat 2013-05-08 13:37 ` Andreas Röhler 0 siblings, 1 reply; 15+ messages in thread From: Roland Donat @ 2013-05-08 13:20 UTC (permalink / raw) To: emacs-orgmode > > hmm, indeed, shows up nicely now. > Please close, cheers, > > Andreas > > That's right, it works with python3 but that is not the case with python2... Cheers, Roland. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)] 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 0 siblings, 1 reply; 15+ messages in thread From: Andreas Röhler @ 2013-05-08 13:37 UTC (permalink / raw) To: emacs-orgmode Am 08.05.2013 15:20, schrieb Roland Donat: > >> >> hmm, indeed, shows up nicely now. >> Please close, cheers, >> >> Andreas >> >> > > That's right, it works with python3 but that is not the case with python2... > > Cheers, > > Roland. python2 fails here already with a common shell, independently from Emacs. OTOH that works with python2: #+NAME: test #+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return a[0][0] a = ( ( "é", "a" ), ( "a", "à" ) ) #+end_src #+RESULTS: test : é Maybe there is a work-around from a[0][0] ? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)] 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 0 siblings, 2 replies; 15+ messages in thread From: Roland Donat @ 2013-05-08 14:02 UTC (permalink / raw) To: emacs-orgmode Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes: > > Am 08.05.2013 15:20, schrieb Roland Donat: > > > >> > >> hmm, indeed, shows up nicely now. > >> Please close, cheers, > >> > >> Andreas > >> > >> > > > > That's right, it works with python3 but that is not the case with python2... > > > > Cheers, > > > > Roland. > > python2 fails here already with a common shell, independently from Emacs. > > OTOH that works with python2: > > #+NAME: test > #+begin_src python :results value :preamble # -*- coding: utf-8 -*- :return a[0][0] > a = ( ( "é", "a" ), ( "a", "à" ) ) > #+end_src > > #+RESULTS: test > : é > > Maybe there is a work-around from > a[0][0] > > ? > > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)] 2013-05-08 14:02 ` Roland Donat @ 2013-05-08 14:28 ` Andreas Röhler 2013-05-08 16:11 ` Andreas Röhler 1 sibling, 0 replies; 15+ messages in thread From: Andreas Röhler @ 2013-05-08 14:28 UTC (permalink / raw) To: emacs-orgmode Am 08.05.2013 16:02, schrieb Roland Donat: > Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes: > >> >> Am 08.05.2013 15:20, schrieb Roland Donat: >>> >>>> >>>> hmm, indeed, shows up nicely now. >>>> Please close, cheers, >>>> >>>> Andreas >>>> >>>> >>> >>> That's right, it works with python3 but that is not the case with > python2... >>> >>> Cheers, >>> >>> Roland. >> >> python2 fails here already with a common shell, independently from Emacs. >> >> OTOH that works with python2: >> >> #+NAME: test >> #+begin_src python :results value :preamble # -*- coding: utf-8 -*- > :return a[0][0] >> a = ( ( "é", "a" ), ( "a", "à" ) ) >> #+end_src >> >> #+RESULTS: test >> : é >> >> Maybe there is a work-around from >> a[0][0] >> >> ? >> >> > > 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 Seems utf-8 understands \303\251, which seems the same number as \xc3\xa9, i.e. the numeric character returned is ok. Failings ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)] 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 1 sibling, 1 reply; 15+ messages in thread From: Andreas Röhler @ 2013-05-08 16:11 UTC (permalink / raw) To: emacs-orgmode Am 08.05.2013 16:02, schrieb Roland Donat: > Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes: > >> >> Am 08.05.2013 15:20, schrieb Roland Donat: >>> >>>> >>>> hmm, indeed, shows up nicely now. >>>> Please close, cheers, >>>> >>>> Andreas >>>> >>>> >>> >>> That's right, it works with python3 but that is not the case with > python2... >>> >>> Cheers, >>> >>> Roland. >> >> python2 fails here already with a common shell, independently from Emacs. >> >> OTOH that works with python2: >> >> #+NAME: test >> #+begin_src python :results value :preamble # -*- coding: utf-8 -*- > :return a[0][0] >> a = ( ( "é", "a" ), ( "a", "à" ) ) >> #+end_src >> >> #+RESULTS: test >> : é >> >> Maybe there is a work-around from >> a[0][0] >> >> ? >> >> > > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)] 2013-05-08 16:11 ` Andreas Röhler @ 2013-05-08 20:50 ` Roland Donat 2013-05-09 9:01 ` Andreas Röhler 0 siblings, 1 reply; 15+ messages in thread From: Roland Donat @ 2013-05-08 20:50 UTC (permalink / raw) To: emacs-orgmode > > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)] 2013-05-08 20:50 ` Roland Donat @ 2013-05-09 9:01 ` Andreas Röhler 2013-05-09 14:33 ` Roland Donat 0 siblings, 1 reply; 15+ messages in thread From: Andreas Röhler @ 2013-05-09 9:01 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)] 2013-05-09 9:01 ` Andreas Röhler @ 2013-05-09 14:33 ` Roland Donat 2013-05-09 14:45 ` Andreas Röhler 0 siblings, 1 reply; 15+ messages in thread From: Roland Donat @ 2013-05-09 14:33 UTC (permalink / raw) To: emacs-orgmode 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! ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)] 2013-05-09 14:33 ` Roland Donat @ 2013-05-09 14:45 ` Andreas Röhler 2013-05-09 19:20 ` Roland Donat 0 siblings, 1 reply; 15+ messages in thread From: Andreas Röhler @ 2013-05-09 14:45 UTC (permalink / raw) To: emacs-orgmode Am 09.05.2013 16:33, schrieb Roland Donat: > 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, [ ... ] The bug so far affected the display only, not the data. Feeding R with the result returned from your original form should work. Best, Andreas ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)] 2013-05-09 14:45 ` Andreas Röhler @ 2013-05-09 19:20 ` Roland Donat 0 siblings, 0 replies; 15+ messages in thread From: Roland Donat @ 2013-05-09 19:20 UTC (permalink / raw) To: emacs-orgmode > > The bug so far affected the display only, not the data. > Feeding R with the result returned from your original form should work. > > Best, > > Andreas > > Aaaaah you're right!!!! It's a bit annoying to enter the encoding when Emacs asks for it but it works on the previous example. It's not the case with my real data but it's another problem to solve now ;). Thanks a lot for your help!!!! Best regards Roland. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2013-05-09 19:21 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2013-05-09 14:45 ` Andreas Röhler 2013-05-09 19:20 ` Roland Donat
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).