matplotlib-devel Mailing List for matplotlib

Sure, thread about IPython integration to be continued on ipython-dev 
list...
Nicolas
On 3 Apr, 2009, at 19:07 , Fernando Perez wrote:
> On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier
> <Nic...@lo...> wrote:
>>
>>
>> Sorry for that, I coded it on linux and just tested on mac.
>> I fixed the error and upload the new version on the same link. Tell 
>> me if
>> it's ok.
>
> Great!
>
> Would you have any interest in having this be shipped/developed as
> part of IPython itself?
>
> You are using a fair amount of internals of the ipython machinery, and
> we're getting ready for a large cleanup. Having your code shipped
> with ipython itself would give it perhaps more exposure, as well as
> allow it to evolve in sync with the rest of the API, since we could
> test it as the internals change.
>
> I think it would be great to ship this with ipython itself, and I'm
> sure you'd get help and contributions from the rest of the ipython
> team as well...
>
> Best,
>
> f

On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier
<Nic...@lo...> wrote:
>
>
> Sorry for that, I coded it on linux and just tested on mac.
> I fixed the error and upload the new version on the same link. Tell me if
> it's ok.
Great!
Would you have any interest in having this be shipped/developed as
part of IPython itself?
You are using a fair amount of internals of the ipython machinery, and
we're getting ready for a large cleanup. Having your code shipped
with ipython itself would give it perhaps more exposure, as well as
allow it to evolve in sync with the rest of the API, since we could
test it as the internals change.
I think it would be great to ship this with ipython itself, and I'm
sure you'd get help and contributions from the rest of the ipython
team as well...
Best,
f

Sorry for that, I coded it on linux and just tested on mac.
I fixed the error and upload the new version on the same link. Tell me 
if it's ok.
Nicolas
On 3 Apr, 2009, at 18:55 , Fernando Perez wrote:
> On Fri, Apr 3, 2009 at 4:17 AM, Nicolas Rougier
> <Nic...@lo...> wrote:
>>
>> Hello,
>>
>> While looking at possible solutions for a matplotlib OpenGL backend,
>> I've been experimenting with pyglet (that has no dependencies) and 
>> coded
>> a terminal with embedded 2d arrays display.
>>
>> Sources & screenshots are available at:
>> http://www.loria.fr/~rougier/glnumpy.html
>
> Wow, the screenshots look gorgeous!
>
> Unfortunately I tried to run it after installing it in my path and I
> got this (same for glnumpy):
>
> uqbar[bin]> ./glpython
> Traceback (most recent call last):
> File "./glpython", line 70, in <module>
> logo = pyglet.resource.image('logo.png')
> File "/var/lib/python-support/python2.5/pyglet/resource.py", line
> 481, in image
> identity = self._cached_images[name] = self._alloc_image(name)
> File "/var/lib/python-support/python2.5/pyglet/resource.py", line
> 425, in _alloc_image
> file = self.file(name)
> File "/var/lib/python-support/python2.5/pyglet/resource.py", line 
> 383, in file
> raise ResourceNotFoundException(name)
> pyglet.resource.ResourceNotFoundException: Resource "logo.png" was not
> found on the path. Ensure that the filename has the correct
> captialisation.
>
>
> This is on ubuntu 8.10, 64 bit, installed with --prefix=$HOME/usr/opt.
>
> Cheers,
>
> f

On Fri, Apr 3, 2009 at 4:17 AM, Nicolas Rougier
<Nic...@lo...> wrote:
>
> Hello,
>
> While looking at possible solutions for a matplotlib OpenGL backend,
> I've been experimenting with pyglet (that has no dependencies) and coded
> a terminal with embedded 2d arrays display.
>
> Sources & screenshots are available at:
> http://www.loria.fr/~rougier/glnumpy.html
Wow, the screenshots look gorgeous!
Unfortunately I tried to run it after installing it in my path and I
got this (same for glnumpy):
uqbar[bin]> ./glpython
Traceback (most recent call last):
 File "./glpython", line 70, in <module>
 logo = pyglet.resource.image('logo.png')
 File "/var/lib/python-support/python2.5/pyglet/resource.py", line
481, in image
 identity = self._cached_images[name] = self._alloc_image(name)
 File "/var/lib/python-support/python2.5/pyglet/resource.py", line
425, in _alloc_image
 file = self.file(name)
 File "/var/lib/python-support/python2.5/pyglet/resource.py", line 383, in file
 raise ResourceNotFoundException(name)
pyglet.resource.ResourceNotFoundException: Resource "logo.png" was not
found on the path. Ensure that the filename has the correct
captialisation.
This is on ubuntu 8.10, 64 bit, installed with --prefix=$HOME/usr/opt.
Cheers,
f

Hi,
I agree, shell with inline plot is a different issue. I mainly coded 
it as a proof a concept and because I find it useful for my own needs.
The figure call is quite different from the figure call of matplotlib, 
only the name is common.
The idea was to be able to describe a configuration of arrays with a 
minimum amount of code.
figure(Z) -> plot Z
figure([Z1,Z2]) -> plot Z1,Z2 side by side
figure([[Z1,Z2], [Z3,Z4]]) -> plot Z1,Z2 side by side and below, Z3,Z4 
side by side
You can optionally indicate that an array spans several rows or columns:
figure([[Z1,'-'],
	 [Z3,Z4]]) -> plot Z1 on two columns and below, Z3,Z4 side by side
figure([[Z1,Z2],
	 ['|', Z4]]) -> plot Z1 on two rows, then Z2 on first line and 
Z4 on second line.
I looked at the thread you're talking about and it was the reason in 
the first place that I investigated pyglet.
My approach is a bit different since I use a texture and a single quad 
to render it, it makes things quite fast. The mapping from a float 
array to a texture data is pretty efficient using numpy interface and 
it allows me to continuously update texture data (just try modifying 
the array from within the console).
Nicolas
On 3 Apr, 2009, at 17:12 , Eric Bruning wrote:
> The idea of a shell with inline plots is a fascinating one - I like
> the minimalism and directness of being able to plot data like this.
> And the speed of OpenGL is obviously attractive.
>
> Is the figure() call syntax different from the existing syntax for
> figure()? I think there's a usage pattern ingrained in my head that
> says 'figure => new window,' and any change to the call syntax for
> figure would seem to open up a lot of room for confusion.
>
> It seems that the backend and the shell might be separate issues? My
> view of the backends is that they only deal with knowing how to draw
> artists, and are separate from the process of creating those artists
> through an interactive shell.
>
> The following old thread is also relevant, which you may have 
> already seen:
> http://www.nabble.com/opengl-backend-td19192625.html
>
> Thanks,
> Eric B
>
>
> On Fri, Apr 3, 2009 at 7:17 AM, Nicolas Rougier
> <Nic...@lo...> wrote:
>>
>> Hello,
>>
>> While looking at possible solutions for a matplotlib OpenGL backend,
>> I've been experimenting with pyglet (that has no dependencies) and 
>> coded
>> a terminal with embedded 2d arrays display.
>>
>> Sources & screenshots are available at:
>> http://www.loria.fr/~rougier/glnumpy.html
>>
>> Since pyglet seems mature enough, I would like to know if anyone
>> interested in helping writing the OpenGL backend (using pyglet) ?
>>
>>
>> Nicolas
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>

The idea of a shell with inline plots is a fascinating one - I like
the minimalism and directness of being able to plot data like this.
And the speed of OpenGL is obviously attractive.
Is the figure() call syntax different from the existing syntax for
figure()? I think there's a usage pattern ingrained in my head that
says 'figure => new window,' and any change to the call syntax for
figure would seem to open up a lot of room for confusion.
It seems that the backend and the shell might be separate issues? My
view of the backends is that they only deal with knowing how to draw
artists, and are separate from the process of creating those artists
through an interactive shell.
The following old thread is also relevant, which you may have already seen:
http://www.nabble.com/opengl-backend-td19192625.html
Thanks,
Eric B
On Fri, Apr 3, 2009 at 7:17 AM, Nicolas Rougier
<Nic...@lo...> wrote:
>
> Hello,
>
> While looking at possible solutions for a matplotlib OpenGL backend,
> I've been experimenting with pyglet (that has no dependencies) and coded
> a terminal with embedded 2d arrays display.
>
> Sources & screenshots are available at:
> http://www.loria.fr/~rougier/glnumpy.html
>
> Since pyglet seems mature enough, I would like to know if anyone
> interested in helping writing the OpenGL backend (using pyglet) ?
>
>
> Nicolas
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hello,
While looking at possible solutions for a matplotlib OpenGL backend,
I've been experimenting with pyglet (that has no dependencies) and coded
a terminal with embedded 2d arrays display.
Sources & screenshots are available at:
http://www.loria.fr/~rougier/glnumpy.html
Since pyglet seems mature enough, I would like to know if anyone
interested in helping writing the OpenGL backend (using pyglet) ?
Nicolas