are babel python sessions and inlined images incompatible?

are babel python sessions and inlined images incompatible?

[Rodrigo Amestica]

Hello,

if I use this block

#+BEGIN_SRC python :results file
from pylab import *
plot(rand(10))
savefig('images/test.png')
return 'images/test.png'
#+END_SRC 

then the RESULTS block shows me an inlined version of the plot.

If now I switch to this block

#+BEGIN_SRC python :session test :results file
from pylab import *
plot(rand(10))
savefig('images/test.png')
return 'images/test.png'
#+END_SRC 

then the RESULTS block does not show the inlined plot but this

| <matplotlib.lines.Line2D | object | at | 0x35c0650> |

Using a session is kind of mandatory for me because I need several blocks to
share variables.

Is there something evidently wrong with my approach?

thanks,
 Rodrigo

Re: are babel python sessions and inlined images incompatible?

[Eric Schulte]

Rodrigo Amestica <ramestica@lavabit.com> writes:

> Hello,
>
> if I use this block
>
> #+BEGIN_SRC python :results file
> from pylab import *
> plot(rand(10))
> savefig('images/test.png')
> return 'images/test.png'
> #+END_SRC 
>
> then the RESULTS block shows me an inlined version of the plot.
>
> If now I switch to this block
>
> #+BEGIN_SRC python :session test :results file
> from pylab import *
> plot(rand(10))
> savefig('images/test.png')
> return 'images/test.png'
> #+END_SRC 
>

You don't need to explicitly specify a return when working with a
session.  Either of the following should work.

    #+BEGIN_SRC python :session test :file "images/test.png"
      from pylab import *
      plot(rand(10))
      savefig('images/test.png')
    #+END_SRC

or

    #+BEGIN_SRC python :session test :results file
      from pylab import *
      plot(rand(10))
      savefig('images/test.png')
      'images/test.png'
    #+END_SRC

Hope this helps,

>
> then the RESULTS block does not show the inlined plot but this
>
> | <matplotlib.lines.Line2D | object | at | 0x35c0650> |
>
> Using a session is kind of mandatory for me because I need several blocks to
> share variables.
>
> Is there something evidently wrong with my approach?
>
> thanks,
>  Rodrigo
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: are babel python sessions and inlined images incompatible?

[Rodrigo Amestica]

At Tue, 23 Apr 2013 07:29:50 -0600,
Eric Schulte wrote:
> 
> Rodrigo Amestica <ramestica@lavabit.com> writes:
> 
> > Hello,
> >
> > if I use this block
> >
> > #+BEGIN_SRC python :results file
> > from pylab import *
> > plot(rand(10))
> > savefig('images/test.png')
> > return 'images/test.png'
> > #+END_SRC 
> >
> > then the RESULTS block shows me an inlined version of the plot.
> >
> > If now I switch to this block
> >
> > #+BEGIN_SRC python :session test :results file
> > from pylab import *
> > plot(rand(10))
> > savefig('images/test.png')
> > return 'images/test.png'
> > #+END_SRC 
> >

many thanks for the feed back Eric!

> 
> You don't need to explicitly specify a return when working with a
> session.  Either of the following should work.
> 
>     #+BEGIN_SRC python :session test :file "images/test.png"
>       from pylab import *
>       plot(rand(10))
>       savefig('images/test.png')
>     #+END_SRC
> 

that does not quite work, I get no inlined image but the following line in the
Messages buffer

orgtbl-format-line: Wrong type argument: sequencep, <matplotlib\.lines\.Line2DError during redisplay: (wrong-type-argument arrayp nil)

> or
> 
>     #+BEGIN_SRC python :session test :results file
>       from pylab import *
>       plot(rand(10))
>       savefig('images/test.png')
>       'images/test.png'
>     #+END_SRC

that one works!

many thanks,
 Rodrigo

> 
> Hope this helps,
> 
> >
> > then the RESULTS block does not show the inlined plot but this
> >
> > | <matplotlib.lines.Line2D | object | at | 0x35c0650> |
> >
> > Using a session is kind of mandatory for me because I need several blocks to
> > share variables.
> >
> > Is there something evidently wrong with my approach?
> >
> > thanks,
> >  Rodrigo
> >
> >
> 
> -- 
> Eric Schulte
> http://cs.unm.edu/~eschulte
> 
> ____________________________________________________________________________________
> Your personal email. Anytime, anywhere.
> Ridiculously affordable at $19.95. No contracts.
> http://www.getpeek.com/lavabit.html
> ____________________________________________________________________________________

Re: are babel python sessions and inlined images incompatible?

[Sebastien Vauban]

Hello Rodrigo,

Rodrigo Amestica wrote:
> Eric Schulte wrote:
>> Rodrigo Amestica <ramestica-N9AOi2cAC9ZBDgjK7y7TUQ@public.gmane.org> writes:
>> 
>> > if I use this block
>> >
>> > #+BEGIN_SRC python :results file
>> > from pylab import *
>> > plot(rand(10))
>> > savefig('images/test.png')
>> > return 'images/test.png'
>> > #+END_SRC 
>> >
>> > then the RESULTS block shows me an inlined version of the plot.
>> >
>> > If now I switch to this block
>> >
>> > #+BEGIN_SRC python :session test :results file
>> > from pylab import *
>> > plot(rand(10))
>> > savefig('images/test.png')
>> > return 'images/test.png'
>> > #+END_SRC 
>
> many thanks for the feed back Eric!
>
>> You don't need to explicitly specify a return when working with a
>> session.  Either of the following should work.
>> 
>>     #+BEGIN_SRC python :session test :file "images/test.png"
>>       from pylab import *
>>       plot(rand(10))
>>       savefig('images/test.png')
>>     #+END_SRC
>
> that does not quite work, I get no inlined image but the following line in the
> Messages buffer
>
> orgtbl-format-line: Wrong type argument: sequencep, <matplotlib\.lines\.Line2DError during redisplay: (wrong-type-argument arrayp nil)

Try adding the `:results graphics' header argument...

>>     #+BEGIN_SRC python :session test :results file
>>       from pylab import *
>>       plot(rand(10))
>>       savefig('images/test.png')
>>       'images/test.png'
>>     #+END_SRC
>
> that one works!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: are babel python sessions and inlined images incompatible?

[Rodrigo Amestica]

At Wed, 24 Apr 2013 23:06:30 +0200,
Sebastien Vauban wrote:
> >> You don't need to explicitly specify a return when working with a
> >> session.  Either of the following should work.
> >> 
> >>     #+BEGIN_SRC python :session test :file "images/test.png"
> >>       from pylab import *
> >>       plot(rand(10))
> >>       savefig('images/test.png')
> >>     #+END_SRC
> >
> > that does not quite work, I get no inlined image but the following line in the
> > Messages buffer
> >
> > orgtbl-format-line: Wrong type argument: sequencep, <matplotlib\.lines\.Line2DError during redisplay: (wrong-type-argument arrayp nil)
> 
> Try adding the `:results graphics' header argument...
> 

it does not help. Still same error. I'm using org-7.9.4 from tarball, in ob.el
there is no 'graphics' option defined for :results.

thanks for the hint, though
 Rodrigo

Re: are babel python sessions and inlined images incompatible?

[Sebastien Vauban]

Hi Rodrigo,

Rodrigo Amestica wrote:
> Sebastien Vauban wrote:
>>>> You don't need to explicitly specify a return when working with a
>>>> session. Either of the following should work.
>>>>
>>>>     #+BEGIN_SRC python :session test :file "images/test.png"
>>>>       from pylab import *
>>>>       plot(rand(10))
>>>>       savefig('images/test.png')
>>>>     #+END_SRC
>>>
>>> that does not quite work, I get no inlined image but the following line in
>>> the Messages buffer
>>>
>>> orgtbl-format-line: Wrong type argument: sequencep,
>>> <matplotlib\.lines\.Line2DError during redisplay: (wrong-type-argument
>>> arrayp nil)
>>
>> Try adding the `:results graphics' header argument...
>
> it does not help. Still same error. I'm using org-7.9.4 from tarball, in
> ob.el there is no 'graphics' option defined for :results.

Well, I *now* know it's not described in the Org manual...

  ╭──── http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01181.html
  │
  │ - :results graphics makes the list even longer, yes?  :-) I'm not
  │   sure that every language supports it and I don't believe it's
  │   currently in the manual.
  ╰────

Though, it's described in many different posts on this ML, and in some
tutorials on Worg...

  ╭──── http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html
  │
  │ If a :file filename.ext header argument is provided to an R source block, then
  │ the output from the source block will go to the named file. What that output
  │ is depends on the value of the :results header argument.
  │
  │ If the value is :results graphics then "base" graphics output is captured on
  │ disk, and a link to the graphics file is inserted into the Org Mode buffer (as
  │ is also the case with the graphics-only languages such as gnuplot, ditaa, dot,
  │ and asymptote.)
  ╰────

I thought it was a "core" option value for all general-purpose languages (e.g.
emacs-lisp, python, R, ruby, sh), required when your code block outputs a
graphics.

After checking, I only found it in those files:

--8<---------------cut here---------------start------------->8---
./ob-maxima.el:117:  (and (member "graphics" (cdr (assq :result-params params)))
./ob-octave.el:272:  (and (member "graphics" (cdr (assq :result-params params)))
./ob-R.el:234:  (and (member "graphics" (cdr (assq :result-params params)))
--8<---------------cut here---------------end--------------->8---

Maybe they are the only general-purpose languages able to output graphics? No,
wait, your example shows that python is also able to do so.

Then, I don't understand what that ":results graphics" option is not part of
python. Sorry not to be of more help...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: are babel python sessions and inlined images incompatible?

[Thomas S. Dye]

Aloha Seb,

"Sebastien Vauban"
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:

>
> Well, I *now* know it's not described in the Org manual...
>
>   ╭──── http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01181.html
>   │
>   │ - :results graphics makes the list even longer, yes?  :-) I'm not
>   │   sure that every language supports it and I don't believe it's
>   │   currently in the manual.
>   ╰────
>
> Though, it's described in many different posts on this ML, and in some
> tutorials on Worg...
>
>   ╭──── http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html
>   │
>   │ If a :file filename.ext header argument is provided to an R source
> block, then
>   │ the output from the source block will go to the named file. What that output
>   │ is depends on the value of the :results header argument.
>   │
>   │ If the value is :results graphics then "base" graphics output is captured on
>   │ disk, and a link to the graphics file is inserted into the Org
> Mode buffer (as
>   │ is also the case with the graphics-only languages such as gnuplot,
> ditaa, dot,
>   │ and asymptote.)
>   ╰────
>
> I thought it was a "core" option value for all general-purpose languages (e.g.
> emacs-lisp, python, R, ruby, sh), required when your code block outputs a
> graphics.
>
> After checking, I only found it in those files:
>
> ./ob-maxima.el:117:  (and (member "graphics" (cdr (assq :result-params params)))
> ./ob-octave.el:272:  (and (member "graphics" (cdr (assq :result-params params)))
> ./ob-R.el:234:  (and (member "graphics" (cdr (assq :result-params params)))

The language documentation on Worg, such as
http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html, is
meant to be documentation, rather than tutorial.  It is structured this
way so the manual doesn't need to be updated every time support for a
new language is added, or changes are made to a language-specific file.

The template for this documentation includes a slot for default header
arguments and also one for language-specific header arguments, because
these are often changed by the language-specific modules.

I think the hope and expectation is that the user community take over
the tasks of creating and tending the language-specific code.  If
:results graphics makes good sense for Python, then users should feel
free to add it to ob-python.el.  With the examples you point out, it
shouldn't be too difficult.

hth,
Tom
 
-- 
Thomas S. Dye
http://www.tsdye.com

Re: are babel python sessions and inlined images incompatible?

[Sebastien Vauban]

Hi Thomas,

Thomas S. Dye wrote:
> "Sebastien Vauban" writes:
>> Well, I *now* know it's not described in the Org manual...
>>
>>   ╭──── http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01181.html
>>   │
>>   │ - :results graphics makes the list even longer, yes?  :-) I'm not
>>   │   sure that every language supports it and I don't believe it's
>>   │   currently in the manual.
>>   ╰────
>>
>> Though, it's described in many different posts on this ML, and in some
>> tutorials on Worg...
>>
>>   ╭──── http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html
>>   │
>>   │ If a :file filename.ext header argument is provided to an R source block, then
>>   │ the output from the source block will go to the named file. What that output
>>   │ is depends on the value of the :results header argument.
>>   │
>>   │ If the value is :results graphics then "base" graphics output is captured on
>>   │ disk, and a link to the graphics file is inserted into the Org Mode buffer (as
>>   │ is also the case with the graphics-only languages such as gnuplot, ditaa, dot,
>>   │ and asymptote.)
>>   ╰────
>>
>> I thought it was a "core" option value for all general-purpose languages (e.g.
>> emacs-lisp, python, R, ruby, sh), required when your code block outputs a
>> graphics.
>>
>> After checking, I only found it in those files:
>>
>> ./ob-maxima.el:117:  (and (member "graphics" (cdr (assq :result-params params)))
>> ./ob-octave.el:272:  (and (member "graphics" (cdr (assq :result-params params)))
>> ./ob-R.el:234:  (and (member "graphics" (cdr (assq :result-params params)))
>
> The language documentation on Worg, such as
> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html, is
> meant to be documentation, rather than tutorial.  It is structured this
> way so the manual doesn't need to be updated every time support for a
> new language is added, or changes are made to a language-specific file.
>
> The template for this documentation includes a slot for default header
> arguments and also one for language-specific header arguments, because
> these are often changed by the language-specific modules.
>
> I think the hope and expectation is that the user community take over
> the tasks of creating and tending the language-specific code.  If
> :results graphics makes good sense for Python, then users should feel
> free to add it to ob-python.el.  With the examples you point out, it
> shouldn't be too difficult.

As you say, I guess that one could copy/paste the code from maxima, octave or
R to get the desired results.

Would we want to abstract the above, I guess we should generalize the
languages families as:

- graphics-only languages (ditaa, dot, gnuplot, etc.)

- general-purpose languages with graphical capacities (R, maxima, octave...
  and, at least, python[1] IIUC)

- general-purpose languages without graphical capacities (sql, sh, etc.)

Maybe that would allow to have sets of header arguments (or default values)
mapped onto those families.

Best regards,
  Seb

[1] Never used it.

-- 
Sebastien Vauban

Re: are babel python sessions and inlined images incompatible?

[Rasmus]

"Sebastien Vauban" <sva-news@mygooglest.com>
writes:

> As you say, I guess that one could copy/paste the code from maxima, octave or
> R to get the desired results.
>
> Would we want to abstract the above, I guess we should generalize the
> languages families as:
>
> - Graphics-only languages (ditaa, dot, gnuplot, etc.)
>
> - General-purpose languages with graphical capacities (R, maxima, octave...
>   And, at least, python[1] IIUC)

Python features very sophisticated graphics through matplotlib (at
least on par with R/ggplot2).

> - General-purpose languages without graphical capacities (sql, sh, etc.)

Sounds like a good idea to me.  I don't know whether it would save a
lot of effort though or make it easier to get functions spread out?

–Rasmus

-- 
When in doubt, do it!

Re: are babel python sessions and inlined images incompatible?

[Achim Gratz]

Sebastien Vauban writes:
> Would we want to abstract the above, I guess we should generalize the
> languages families as:
>
> - graphics-only languages (ditaa, dot, gnuplot, etc.)
>
> - general-purpose languages with graphical capacities (R, maxima, octave...
>   and, at least, python[1] IIUC)
>
> - general-purpose languages without graphical capacities (sql, sh, etc.)

This is something of a non-starter as all generalizations are false.

Babels notion of graphics is simply that after execution of the source
block it expects to be able to find a file that looks like it has a
graphics format in it (and its notion of results is that it gets
something from standard output that conforms to certain rules that are
changeable by header arguments).

A "graphics-only" language would be one that could only write files, but
Babel can easily transcend that limitation and pretend it had gotten a
result instead.  It might even filter the result to convert between
formats.  Conversely, a language that cannot write files could have an
implementation where Babel constructs the file to put in the graphics
link in Org from the output of the program.  Existing Babel language
implementations already use both mechanisms.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: are babel python sessions and inlined images incompatible?

[Sebastien Vauban]

Hi Achim,

Achim Gratz wrote:
> Sebastien Vauban writes:
>> Would we want to abstract the above, I guess we should generalize the
>> languages families as:
>>
>> - graphics-only languages (ditaa, dot, gnuplot, etc.)
>>
>> - general-purpose languages with graphical capacities (R, maxima, octave...
>>   and, at least, python[1] IIUC)
>>
>> - general-purpose languages without graphical capacities (sql, sh, etc.)
>
> This is something of a non-starter as all generalizations are false.
>
> Babels notion of graphics is simply that after execution of the source
> block it expects to be able to find a file that looks like it has a
> graphics format in it (and its notion of results is that it gets
> something from standard output that conforms to certain rules that are
> changeable by header arguments).
>
> A "graphics-only" language would be one that could only write files, but
> Babel can easily transcend that limitation and pretend it had gotten a
> result instead.  It might even filter the result to convert between
> formats.  Conversely, a language that cannot write files could have an
> implementation where Babel constructs the file to put in the graphics
> link in Org from the output of the program.  Existing Babel language
> implementations already use both mechanisms.

My idea was simply to ensure that all similar languages share the same set of
header arguments, which is not the case, as of today, with python (no support
for ":results graphics").

But I get your point.

Best regards,
  Seb

-- 
Sebastien Vauban