Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef MY-PATH/)]

2013-05-09 Thread Roland Donat

> 
> 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
> 
> 

Ah 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.









Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef MY-PATH/)]

2013-05-09 Thread Andreas Röhler

Am 09.05.2013 16:33, schrieb Roland Donat:

Andreas Röhler  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





Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef MY-PATH/)]

2013-05-09 Thread Roland Donat
Andreas Röhler  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!







Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef MY-PATH/)]

2013-05-09 Thread Andreas Röhler

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




Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef MY-PATH/)]

2013-05-08 Thread 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.







Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef MY-PATH/)]

2013-05-08 Thread Andreas Röhler

Am 08.05.2013 16:02, schrieb Roland Donat:

Andreas Röhler  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





Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef MY-PATH/)]

2013-05-08 Thread Andreas Röhler

Am 08.05.2013 16:02, schrieb Roland Donat:

Andreas Röhler  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



Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef MY-PATH/)]

2013-05-08 Thread Roland Donat
Andreas Röhler  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.









Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef MY-PATH/)]

2013-05-08 Thread Andreas Röhler

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]

?




Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef MY-PATH/)]

2013-05-08 Thread 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.






Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]

2013-05-08 Thread Andreas Röhler

Am 08.05.2013 14:40, schrieb Eric Schulte:

Andreas Röhler  writes:


Am 08.05.2013 09:12, schrieb Andreas Röhler:

org-babel-python-mode

was python3




e, 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



Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]

2013-05-08 Thread Eric Schulte
Andreas Röhler  writes:

> Am 08.05.2013 09:12, schrieb Andreas Röhler:
>> org-babel-python-mode
>>
>> was python3
>>
>>
>
> e, 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



Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]

2013-05-08 Thread Andreas Röhler

Am 08.05.2013 09:12, schrieb Andreas Röhler:

org-babel-python-mode

was python3




e, org-babel-python-command



Re: [O] Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef @ MY-PATH/)]

2013-05-08 Thread Andreas Röhler

org-babel-python-mode

was python3