Re: [matplotlib-devel] any git clones of the MPL svn repo out there?

2008-12-02 Thread Ondrej Certik 
On Sun, Nov 30, 2008 at 9:42 PM, Andrew Straw <[EMAIL PROTECTED]> wrote:
> I used rsync to mirror the entire SVN repo locally and then using "git
> svn clone" to import it (which took about 12 hours on a 2.5 GHz Core 2
> machine, even with the local SVN mirror).
>
> I haven't been able to clone the new git repo such that the 2nd git copy
> would not need to do "git svn fetch" on the entire repository. Thus, it
> seems that putting my git svn mirror in a publicly accessible location
> isn't actually going to save anyone the pain of letting git call
> subversion a bazillion times to import all history. (At least not
> without me understanding things like
> http://utsl.gen.nz/talks/git-svn/intro.html#howto-track-rebuildmeta )

I always use this blog post to do exactly that:

http://subtlegradient.com/articles/2008/04/22/cloning-a-git-svn-clone

and it works very nicely. So please publish your repository somewhere,
so that others don't have to reclone the whole svn repo.

Thanks,
Ondrej

P.S. Michael, you should learn git. :)

P.P.S. Sorry I still didn't have time to port our 3D plotting from
sympy to matplotlib. Seems like a lot of people would welcome that,
but someone just needs to do it.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Debian + mpl 0.98.5 - Can we reduce the size of generated doc?

2008-12-16 Thread Ondrej Certik 
On Tue, Dec 16, 2008 at 10:57 PM, Sandro Tosi  wrote:
> Hello Darren,
>
> On Tue, Dec 16, 2008 at 16:03, Darren Dale  wrote:
>> It seems like the documentation should be a separately installable package
>> as far as package managers are concerned.
>
> We already have separate the doc from other mpl parts, to be precise
> we have these pkgs:
>
> python-matplotlib - the real module - 2.3M
> python-matplotlib-data - data pkg - 1.1M
> python-matplotlib-dbg - debug symbols - 11M
> python-matplotlib-doc - documentation - 87M
>
> So reducing -doc package is something I'd like to archive, before
> upload the package into Debian archive.

Thanks Sandro for working on it. Btw, having some form of the gallery
as a Debian package would be useful, I was missing this recently, when
I was hacking without an internet connection.

Ondrej

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] histogram(x, bin): x-axis range should be based on bin.min() and bin.max() when bin is a sequence

2008-12-19 Thread Ondrej Certik 
On Fri, Dec 19, 2008 at 6:50 PM, Sandro Tosi  wrote:
> On Fri, Dec 19, 2008 at 18:47, Ondrej Certik  wrote:
>> On Fri, Dec 19, 2008 at 6:34 PM, Sandro Tosi  wrote:
>>> This is fixed in the latest release (0.98.4 or in 0.98.5); I'm working
>>> on uploading it Debian, together with John and Michael (and all dev
>>> team), to have a feasable release.
>>
>> Ah, I didn't know you are on the mpl dev team as well. That's great.
>
> Oh no no: I bother them for something, and they (to force me to
> silence) release a fix :D

Ah I see. The next level is that they'll force you to fix it yourself. :)

Ondrej

--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [sage-devel] Re: upgrading matplotlib and ignoring sage's matplotlibrc

2009-01-30 Thread Ondrej Certik 
On Thu, Jan 29, 2009 at 5:49 PM, William Stein  wrote:
>
> On Wed, Jan 28, 2009 at 10:07 PM, Jason Grout
>  wrote:
>>
>> I just finished upgrading the matplotlib spkg to the newest version.
>> See http://trac.sagemath.org/sage_trac/ticket/4774
>>
>> This version of matplotlib deprecates some of the constructs found in
>> Sage's matplotlibrc (which is located in $SAGE_ROOT and automatically
>> copied to $DOT_SAGE if needed every time sage starts up).  The result is
>> a bunch of deprecation warnings every time Sage starts up (when
>> matplotlib loads Sage's matplotlibrc file).  In trying to figure out
>> what to do about this with several other developers, one option that
>> came up was just throwing away/ignoring the special Sage matplotlibrc
>> and using the normal, standard defaults for matplotlibrc (including the
>> standard location for a customized matplotlibrc).
>>
>> In investigating things more deeply, there were only a few real changes
>> we made to the default behavior of matplotlib.  IIRC, a few font choices
>> were reordered, legends were changed to display a bit more of the
>> function, and the dpi of saved images was bumped up from 80 dpi to 100
>> dpi (but this should be set when Sage saves an image anyway, so I don't
>> know that this changes anything).
>>
>> So here's a proposal: Should Sage stop distributing a custom
>> matplotlibrc, and ignore matplotlibrc files that already exist in the
>> $DOT_SAGE directories?
>>
>> Note that if people really want to customize the matplotlib settings,
>> they can always use the standard location for matplotlibrc (i.e.,
>> ~/.matplotlib/matplotlibrc, I think).  This will clean code out of the
>> bin repository and reduce startup time for sage as well.  Patches which
>> do this are posted to #4774.
>>
>> I vote yes, provided some sort of note is made in the release notes
>> about the ignored matplotlibrc file.
>
> I vote no, since I created the $DOT_SAGE/matplotlib directory
> *precisely* because of problems that happen if you were to do what you
> describe above.  For starters, people often also used a system-wide
> Python with their own version of matplotlib -- then end result was
> that if they tried to switch back and forth between sage and
> python/ipython/matplotlib, they would get tons of deprecation
> warnings, since the systemwide version of matplotlib is often
> different than the sage version.
>
> Second, how will what you suggest solve any problems?  All you do is
> move the problem from $DOT_SAGE/matplotlib/matplotlibc to
> $HOME/.matplotlibrc.  It's exactly the same problem.   You just
> temporarily put it off for a while.
>
> I *wish* matplotlib would replace their stupid deprecation warnings by
> something that just updates the matplotlibrc file, and say makes a
> copy of the old one.  Is there any way we could catch the warnings and
> if they occur move $DOT_SAGE/matplotlib/matplotlibrc to another file,
> then put a new matplotlibrc in place and print a message that this
> just happened?  You could do that by making slightly patching
> matplotlib as well.  I think matplotlib's behavior of emitting
> warnings but doing nothing helpful to resolve them is just obnoxious.

Maybe matplotlib developers would accept a patch fixing this.

Ondrej

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.

2009-03-04 Thread Ondrej Certik 
Hi,

On Wed, Mar 4, 2009 at 11:38 AM, Jonathan Taylor
 wrote:
> Great.  I applied your patch and pushed it to the web repository.
>
> I agree, that some more serious refactoring might be good.  I have
> been leaving comments throughout the code with my thoughts on this.

John just pointed me to this thread, so I just wanted to mention that
we have 3d plots in sympy, that are pure python and use pyglet, here
are some examples and docs:

http://wiki.sympy.org/wiki/Plotting_Module

http://docs.sympy.org/modules/plotting.html

and if anyone would be interested in taking the code and use it for
some of the 3D stuff that you want to do, I would fully support it.
Ideally, if any of you would take it and maintain it, so that we don't
have to, it'd be really awesome. We would like to just concentrate on
symbolic manipulation with sympy and leave all the plotting to
matplotlib, or other packages, if needed.

Let me know if you are interested, we can help with integrating it.

Ondrej

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.

2009-03-05 Thread Ondrej Certik 
On Thu, Mar 5, 2009 at 10:02 AM, Rob Clewley  wrote:
> On Thu, Mar 5, 2009 at 5:14 AM, Johann Cohen-Tanugi
>  wrote:
>> wouaouh. if I had known that sumpy had this functionality, I would
>> have downloaded it ages ago. This is a good example of justified
>> 'taylorisation', IMHO.
>> Big +1 on seing this moved from sympy to matplotlib. I am not expert at
>> coding guis et al, but if you need reviewers/testers or doc writers, I
>> will be happy to give a hand (even two).
>> best,
>> Johann
>
> Yes, I didn't know that either. But it's not clear if I can plot
> discrete data using this interface - at least the examples on the wiki

I am not sure if I understand your question, but It only plots
discrete data --- it takes some sympy expression, evaluates it on a
discrete grid and plots it. So you would just take the plotting stuff.

> make it look that way. I'm also +1 on seeing it moved into mpl, but I
> don't know if the APIs and dependencies are too dissimilar to make it
> work.

There are no dependencies besides pyglet (e.g.  it does not depend on
sympy, or if it does, it can be trivially fixed).

As to the API, just look into sympy/plotting. And play with the 3D
plots in sympy to see how it looks like and how fast/slow it is (I
think it's pretty fast). Then you will have to decide, if it's easier
for you to implement something from scratch, or take our stuff.

As I said, I would love if mpl has similar capability, so that we can
get rid of this from sympy. If you decide to go this way, I (and other
sympy developers) will be at hand to help you integrate it.

Ondrej

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.

2009-03-05 Thread Ondrej Certik 
On Thu, Mar 5, 2009 at 10:15 AM, Rob Clewley  wrote:
>>> Yes, I didn't know that either. But it's not clear if I can plot
>>> discrete data using this interface - at least the examples on the wiki
>>
>> I am not sure if I understand your question, but It only plots
>> discrete data --- it takes some sympy expression, evaluates it on a
>> discrete grid and plots it. So you would just take the plotting stuff.
>
> OK, but it wasn't clear from the example that I could plot a 3D array
> of arbitrary data points. The way that you put together the demo plots

As I understand it, it plots triangles and/or wireframe in the end.
Currently I think our plotting mainly works with surfaces. How can you
plot a 3D array of arbitrary data points? You need to convert it to
some triangles first, e.g. do you want to plot contours (isosurfaces)?
Or do you want to cut a plane in your 3D data points and plot that
plane?

> involved a symbolic function that would be called to generate the
> points. Maybe you could add an example that plots some arbitrary data
> that has been imported from a text file?
>
>>> make it look that way. I'm also +1 on seeing it moved into mpl, but I
>>> don't know if the APIs and dependencies are too dissimilar to make it
>>> work.
>>
>> There are no dependencies besides pyglet (e.g.  it does not depend on
>> sympy, or if it does, it can be trivially fixed).
>
> Well, I meant more like is there a design dependency that is
> incompatible with mpl. I'll shut up now because I know zilch about
> mpl's internals!

The best thing is to just look into our sources, it's pretty well documented.

Ondrej

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.

2009-03-05 Thread Ondrej Certik 
On Thu, Mar 5, 2009 at 11:44 AM, Rob Clewley  wrote:
> On Thu, Mar 5, 2009 at 10:39 AM, Ondrej Certik  wrote:
>
>>> OK, but it wasn't clear from the example that I could plot a 3D array
>>> of arbitrary data points. The way that you put together the demo plots
>>
>> As I understand it, it plots triangles and/or wireframe in the end.
>> Currently I think our plotting mainly works with surfaces. How can you
>> plot a 3D array of arbitrary data points?
>
> E.g., by plotting a dot at the coordinate (x,y,z).

I guess more like a small ball in opengl. I think this can be done
directly in pyglet.

>
>> You need to convert it to
>> some triangles first, e.g. do you want to plot contours (isosurfaces)?
>> Or do you want to cut a plane in your 3D data points and plot that
>> plane?
>>
>
> If I have a set of scalar sample data on a rectangular 2D mesh that I
> want to plot in the 3D I'd want a simple wireframe rectangular surface
> plot. Can it do that?

Yes, that can be done. I can post a simple example, but right now I am
urgently working on getting mayavi2 working in the offline mode in the
Sage notebook for my presentation on Friday, so I'll get back to this
later.

Ondrej

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.

2009-03-08 Thread Ondrej Certik 
On Sun, Mar 8, 2009 at 7:45 PM, Jonathan Taylor
 wrote:
> Hi Reinier,
>
> Awesome.  Those plots are making me smile! I also agree with your
> refactoring and have applied your patch to my git repository.
>
> I agree with you concerning the sympy plotting routines.  I think what
> we have here is quite flexible and does a very good job of replicating
> the equivalent functionality of MATLAB.  I think it would be a huge
> effort trying to make 2D plots and 3D plots look consistent if another
> approach was taken.  Indeed, this is a desirable characteristic.  In
> addition, the code is actually very short and easy to maintain.  Given
> that matplotlib has had trouble maintaining 3D code in the past, it
> might not be a good idea to switch to a more complicated codebase.
>
> You should grab some of my more recent changes as I have added a few
> more fixes.  Most importantly, if you reuse the same figure, the old
> event handlers will still attached preventing Axes objects from dieing
> and causing interactive manipulation of the plots to be very sluggish.
>  Also, in terms of performance, I have found that switching to TkAgg
> from GTKAgg was helpful.
>
> Also, I think the original code from John Porter was under a BSD
> license.  I am thinking of adding our names and the BSD license to the
> top of each file to protect it while its not officially part of
> matplotlib.  What do you think?

A trivial patch is attached to make proj3d.py work.

I tried the examples and it looks great. However, it's pretty slow, at
least on my machine. The plotting in sympy is much faster. Is there
some way to make the mplot3d faster?

Ondrej
From b1a7c0b9c61257d3cbeda78d8aaffedae80396d4 Mon Sep 17 00:00:00 2001
From: Ondrej Certik 
Date: Sun, 8 Mar 2009 20:33:44 -0700
Subject: [PATCH] Make proj3d.py work by importing pylab

---
 proj3d.py |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/proj3d.py b/proj3d.py
index 4b39f10..e124e63 100644
--- a/proj3d.py
+++ b/proj3d.py
@@ -9,6 +9,7 @@ from matplotlib.collections import LineCollection
 from matplotlib.patches import Circle
 import numpy as np
 import numpy.linalg as linalg
+import pylab
 
 def _hide_cross(a,b):
 """
-- 
1.6.2

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.

2009-03-08 Thread Ondrej Certik 
On Sun, Mar 8, 2009 at 9:01 PM, Jonathan Taylor
 wrote:
> Hi,
>
> Thanks for the patch.  How slow is it for you?  I find it slow but

Well, when I use mouse to rotate the image, I can see that it lags behind.

> quite usable.  The main problem, I imagine, is that sympy is using
> OpenGL and thus your graphics card performs all the 3d -> 2d rendering
> whereas we do much of this in python/numpy.  When I get a chance I am
> going to see if I can somewhat speed some of it up by adding an
> optional module to perform a few of these operations in C.

Why not to use OpenGL as well?

Ondrej

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.

2009-03-09 Thread Ondrej Certik 
I posted only to you by a mistake -- can I reply to the list?

On Mon, Mar 9, 2009 at 2:20 PM, Jonathan Taylor
 wrote:
> I think that it would be a little bit more complicated than that.  I
> believe that the current backends act as a canvas that you paint onto.
>  I do not think an OpenGL "canvas" would give us a big speed
> improvement.  In order to get the speed improvement, the "canvas"
> would have to be 3D and the M3D code would paint into this 3D space
> and let OpenGL (and your video card) worry about rendering it.  I
> think that it would be hard to make what came out of this process look
> like what we have now.  Perhaps it would be possible using
> orthographic projection.
>
> Again, for simplicity, I am interested to see how much mileage we can
> get out of our current implementation, perhaps by rewriting a few of
> the algebraic routines in cython.

Ok, I think I understand now and your approach seems reasonable to me.
I can use mayavi if I need some fast and fancy stuff and one can use
mpl if one just wants some regular 3d stuff.

So what do you think we should do with our 3d plots in sympy? It's too
simple for mayavi, too complex for mpl,... Well. :)

Ondrje

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.

2009-03-09 Thread Ondrej Certik 
On Mon, Mar 9, 2009 at 2:34 PM, Ondrej Certik  wrote:
> I posted only to you by a mistake -- can I reply to the list?

Oops, I posted to the list by mistake too -- sorry about it. Anyway,
here is the email that I sent to Jonathan only by a mistake:

On Sun, Mar 8, 2009 at 9:44 PM, Jonathan Taylor
 wrote:
> Just because we are using all the 2D drawing code to make the plots,
> which is why the 3d code is so small, maintainable and is visually
> consistent with 2D matplotlib.  I believe that moving to OpenGL would
> require a substantial effort.

Ok, now I understand the motivation. So if one wanted to go the OpenGL
route, it would have to be created as a matplotlib backend? Then the
3D plots would be fast enough.

Ondrej



and he replied in my previous email, that I just wanted to ask if I
can post to the list.

Ondrej

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Updating MPlot3D to a more recent matplotlib.

2009-03-09 Thread Ondrej Certik 
On Mon, Mar 9, 2009 at 2:39 PM, Jonathan Taylor
 wrote:
> Sure, I thought it was going to the list too ;)  So no problem.
>
> I am not sure what you can do with that module.  It seems a shame to
> waste.  Perhaps it should be split out into a seperate 3d only
> plotting library that cares less about being matplotlib'ish than
> something packaged with MPL would.  What do you think?

Yes, we could do that. The problem is that I don't have time to
maintain plotting stuff, so I need to find ways to attract someone
else to take over it. :) So maybe creating some optional addon to
matplotlib, as you say, could attract people's attantion.

Ondrej

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

2009-07-16 Thread Ondrej Certik 
On Thu, Jul 16, 2009 at 4:42 PM, Robert Kern wrote:
> On Thu, Jul 16, 2009 at 17:26, Brian Granger wrote:
>> Hi,
>>
>> I am attaching a working ctypes based prototype of a module that allows wx
>> to be used interactively from *both* python and ipython.  It uses
>> PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X
>> (python 2.5).
>>
>> It can be used with an existing wx install and all versions of ipython, but
>> ***don't use the -pylab or -wthread flag***.  At this point, I need help
>> testing the heck out of this (window and linux users esp).  I have run most
>> matplotlib pylab_examples and they work fine.  I also need people to try out
>> things like ETS/Mayavi.  The current plan is to replace the existing
>> threaded shells in IPython with this (much simpler) code.
>
> Works for me with wx 2.8.8.1 on OS X 10.5 and Chaco. Pan and zoom
> interactions are substantially chunky, though. I do not see such
> chunkiness with -wthread. It would be worth exploring a Cython
> alternative to see if it is just ctypes and general Python overhead to
> blame.

Works for me on Ubuntu 9.04 with default packages (wx 2.8.9.1), I
tried this example:

In [1]: import inputhook

In [2]: inputhook.set_inputhook_wx()

In [3]: app = wx.App(redirect=False, clearSigInt=False)
---
NameError Traceback (most recent call last)

/home/ondrej/Desktop/ in ()

NameError: name 'wx' is not defined

In [4]: import wx

In [5]: app = wx.App(redirect=False, clearSigInt=False)

In [6]: from matplotlib import pyplot as plt

In [7]: plt.interactive(True)

In [8]: plt.plot(range(10))
Out[8]: []


(maybe you want to add "import wx" into that example docstring)


Pan is perfectly smooth, zoom is a bit chunky, but not much, it's
definitely usable.

Ondrej

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

2009-07-16 Thread Ondrej Certik 
On Thu, Jul 16, 2009 at 11:11 PM, Ondrej Certik wrote:
> On Thu, Jul 16, 2009 at 4:42 PM, Robert Kern wrote:
>> On Thu, Jul 16, 2009 at 17:26, Brian Granger wrote:
>>> Hi,
>>>
>>> I am attaching a working ctypes based prototype of a module that allows wx
>>> to be used interactively from *both* python and ipython.  It uses
>>> PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X
>>> (python 2.5).
>>>
>>> It can be used with an existing wx install and all versions of ipython, but
>>> ***don't use the -pylab or -wthread flag***.  At this point, I need help
>>> testing the heck out of this (window and linux users esp).  I have run most
>>> matplotlib pylab_examples and they work fine.  I also need people to try out
>>> things like ETS/Mayavi.  The current plan is to replace the existing
>>> threaded shells in IPython with this (much simpler) code.
>>
>> Works for me with wx 2.8.8.1 on OS X 10.5 and Chaco. Pan and zoom
>> interactions are substantially chunky, though. I do not see such
>> chunkiness with -wthread. It would be worth exploring a Cython
>> alternative to see if it is just ctypes and general Python overhead to
>> blame.
>
> Works for me on Ubuntu 9.04 with default packages (wx 2.8.9.1), I
> tried this example:
>
> In [1]: import inputhook
>
> In [2]: inputhook.set_inputhook_wx()
>
> In [3]: app = wx.App(redirect=False, clearSigInt=False)
> ---
> NameError                                 Traceback (most recent call last)
>
> /home/ondrej/Desktop/ in ()
>
> NameError: name 'wx' is not defined
>
> In [4]: import wx
>
> In [5]: app = wx.App(redirect=False, clearSigInt=False)
>
> In [6]: from matplotlib import pyplot as plt
>
> In [7]: plt.interactive(True)
>
> In [8]: plt.plot(range(10))
> Out[8]: []
>
>
> (maybe you want to add "import wx" into that example docstring)
>
>
> Pan is perfectly smooth, zoom is a bit chunky, but not much, it's
> definitely usable.

I also tested mayavi, this demo:

http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/mlab.html#a-demo

and I didn't notice any speed difference --- e.g. it's as slow as
regular mayavi with ipython -wthread. :)

Ondrej

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

2009-07-17 Thread Ondrej Certik 
On Fri, Jul 17, 2009 at 1:57 PM, Robert Kern wrote:
> On Fri, Jul 17, 2009 at 14:48, Brian Granger wrote:
>> Michiel,
>>
>> Thanks for the ideas.  I have implemented both of the approaches you
>> describe and I am attaching a file that has all 3 approaches.  At this
>> point, all 3 approaches work on OS X, Python 2.5 with wx 2.8/2.9.  What I
>> most need to to find strenuous test cases that can probe which of these has
>> the best performance?  Robert, could you run the Chaco test again with
>> approaches 2 and 3 and try tuning the parameters (see the docstrings)?
>
> #2 was pretty good out-of-box. #3 was slightly better than #1 but
> still noticeably chunky. Reducing the sleep down to 0.01 instead of
> 0.05 made things appreciably smooth. I thought I noticed a tiny bit of
> chunkiness, but I certainly didn't do a double-blind trial.

Exactly the same observation on Linux. E.g. #1 the slowest, #3 quite
good, #2 perfect. However:

with #2, if I did copy and paste of some command into the python
terminal, I could see how ipython was putting the command letter by
letter on the prompt, e.g. by pasting "inputhook.remove_inputhook()" I
could literally see:

i
in
inp
inpu
...

(everything on one line, e.g. like if there was sleep(0.05) between each letter)

with #1 and #3, pasting was immediate.

Ondrej

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

2009-07-17 Thread Ondrej Certik 
On Fri, Jul 17, 2009 at 2:07 PM, Ondrej Certik wrote:
> On Fri, Jul 17, 2009 at 1:57 PM, Robert Kern wrote:
>> On Fri, Jul 17, 2009 at 14:48, Brian Granger wrote:
>>> Michiel,
>>>
>>> Thanks for the ideas.  I have implemented both of the approaches you
>>> describe and I am attaching a file that has all 3 approaches.  At this
>>> point, all 3 approaches work on OS X, Python 2.5 with wx 2.8/2.9.  What I
>>> most need to to find strenuous test cases that can probe which of these has
>>> the best performance?  Robert, could you run the Chaco test again with
>>> approaches 2 and 3 and try tuning the parameters (see the docstrings)?
>>
>> #2 was pretty good out-of-box. #3 was slightly better than #1 but
>> still noticeably chunky. Reducing the sleep down to 0.01 instead of
>> 0.05 made things appreciably smooth. I thought I noticed a tiny bit of
>> chunkiness, but I certainly didn't do a double-blind trial.
>
> Exactly the same observation on Linux. E.g. #1 the slowest, #3 quite
> good, #2 perfect. However:
>
> with #2, if I did copy and paste of some command into the python
> terminal, I could see how ipython was putting the command letter by
> letter on the prompt, e.g. by pasting "inputhook.remove_inputhook()" I
> could literally see:
>
> i
> in
> inp
> inpu
> ...
>
> (everything on one line, e.g. like if there was sleep(0.05) between each 
> letter)
>
> with #1 and #3, pasting was immediate.

so I also reduced the sleep in #3 from 0.05 to 0.01 and then #3 is
absolutely smooth for me and also pasting to ipython is immediate e.g.
this looks like a perfect solution to me.

Ondrej

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9

2009-07-17 Thread Ondrej Certik 
On Fri, Jul 17, 2009 at 3:57 PM, Ville M. Vainio wrote:
> On Sat, Jul 18, 2009 at 12:54 AM, Brian Granger 
> wrote:
>
>> best.  Bottom line = we are into a position of compromise because of wx.
>> The good news is that I think we can offer users a very flexible way of
>> tuning all these things.
>
> Perhaps adaptive autotuning algorithm could help your case; if stdin
> came in rapidly, poll again very soon, otherwise adjust the delay.

The following patch implements this in the #3 approach:

$ diff -Naur /home/ondrej/Desktop/inputhook.py inputhook.py
--- /home/ondrej/Desktop/inputhook.py   2009-07-17 14:09:34.0 -0600
+++ inputhook.py2009-07-17 17:12:37.0 -0600
@@ -110,17 +110,26 @@
 This sleep time should be tuned though for best performance.
 """
 import wx
+from timeit import default_timer as clock
 app = wx.GetApp()
 if app is not None:
 assert wx.Thread_IsMain()

 evtloop = wx.EventLoop()
 ea = wx.EventLoopActivator(evtloop)
+t = clock()
 while not stdin_ready():
 while evtloop.Pending():
+t = clock()
 evtloop.Dispatch()
 app.ProcessIdle()
-time.sleep(0.01) # Change this to tune performance
+if clock() - t > 0.1:
+# no input is happening, we can sleep as much as we want
+time.sleep(0.05)
+else:
+# input is happening, either wx (e.g. mouse) or keyboard, so
+# sleep only very little
+time.sleep(0.001)
 del ea
 return 0



Now if no input is happening, the "sleep(0.05)" version is running,
thus it has very low CPU usage. If however some input is happening
(either matplotlib, or ipython), then we just sleep(0.001), maybe we
don't have to sleep at all, I am not sure about this.

In any case, this should fix Gael's objection.

Ondrej

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [sage-devel] Re: OS X 10.6 port

2010-04-12 Thread Ondrej Certik 
On Mon, Sep 28, 2009 at 9:37 AM, William Stein  wrote:
>
> On Mon, Sep 28, 2009 at 9:35 AM, John Hunter  wrote:
>> On Mon, Sep 28, 2009 at 11:14 AM, John Hunter  wrote:
>>
>>> But even simple tests are failing with::
>>>
>>> jdh2...@bsd:~> LD_LIBRARY_PATH=~/devtest/lib/
>>> PYTHONPATH=~/devtest/lib/python2.6/site-packages/ /usr/bin/python -c
>>> 'import matplotlib; matplotlib.use("Agg"); from matplotlib.pyplot
>>> import *; plot([1,2,3]); savefig("test")'
>>> Traceback (most recent call last):
>>>  File "", line 1, in 
>>>  File 
>>> "/Users/jdh2358/devtest//lib/python2.6/site-packages/matplotlib/pyplot.py",
>>> line 7, in 
>>>    from matplotlib.figure import Figure, figaspect
>>>  File 
>>> "/Users/jdh2358/devtest//lib/python2.6/site-packages/matplotlib/figure.py",
>>> line 16, in 
>>>    import artist
>>>  File 
>>> "/Users/jdh2358/devtest//lib/python2.6/site-packages/matplotlib/artist.py",
>>> line 6, in 
>>>    from transforms import Bbox, IdentityTransform, TransformedBbox,
>>> TransformedPath
>>>  File 
>>> "/Users/jdh2358/devtest//lib/python2.6/site-packages/matplotlib/transforms.py",
>>> line 34, in 
>>>    from matplotlib._path import affine_transform
>>> ImportError: 
>>> /Users/jdh2358/devtest/lib/python2.6/site-packages/matplotlib/_path.so:
>>> no appropriate 64-bit architecture (see "man python" for running in
>>> 32-bit mode)
>>>
>>> I'm attaching my build output in case anyone sees anything that might
>>> be triggering this 32bit/64bit problem (see attached for full output).
>>>  I did not rebuild numpy and this may be the problem since the failure
>>> is in the _path module.  I'll give that a try next
>>
>>
>> Same issue with numpy HEAD
>
> One thing to keep in mind is that the default for GCC on OS X 10.6 is
> to build 64-bit binaries.   With OS X 10.5 the default for GCC was to
> make 32-bit binaries.  (To get 64-bit you used to have to do "-m64",
> but that is now the default.)   So you really have to start from
> scratch.

I am now getting the exact same problem with pylab and FEMhub and Mac.
I used http://sagemath.org/packages/standard/matplotlib-0.99.1.p4.spkg:

ond...@bsd:~/repos/femhub-0.9.9.beta3-mac(master)$ ./femhub
--
| FEMhub Version 0.9.9.beta2, Release Date: 2010-04-02   |
| Type lab() for the GUI.|
--
In [1]: import pylab
/Users/ondrej/repos/femhub-0.9.9.beta3-mac/local/lib/python2.6/site-packages/matplotlib/rcsetup.py:117:
UserWarning: rcParams key "numerix" is obsolete and has no effect;
 please delete it from your matplotlibrc file
  warnings.warn('rcParams key "numerix" is obsolete and has no effect;\n'
/Users/ondrej/repos/femhub-0.9.9.beta3-mac/local/bin/sage-sage: line
203: 28516 Abort trap  sage-ipython "$@" -i



It's using the "bsd" Mac machine from William, I guess the same as
John was using above.


Has anybody figured out a solution? Apparently Sage must work on the
Mac, so it must be something different than just matplotlib? Some
other package, that we have in femhub, but not in Sage, or some
different version of something. Here is a list of packages that I have
installed:

ond...@bsd:~/repos/femhub-0.9.9.beta3-mac(master)$ ./femhub -i
Currently installed packages:
blas-20070724
bzip2-1.0.5
cmake-2.6.2.p1
configobj-4.5.3
cython-0.12.1
dir-0.1
docutils-0.5.p0
femhub-lab-97141eb
fipy-2.1-eb4aacf
fortran-20071120.p8
freetype-2.3.5.p2
gnutls-2.2.1.p3
hermes2d-9bbfd39
ipython-bzr1174
jinja-1.2.p0
judy-1.0.5.p1
lapack-20071123.p1
libfemhub-78c07cb
libgcrypt-1.4.3.p2
libgpg_error-1.6.p2
libpng-1.2.35.p0
matplotlib-0.99.1.p4
mayavi-3.3.1.p2
mesa-7.4.4.p3
numpy-1.3.0.p2
pexpect-2.0.p3
prereq-0.3
pygments-0.11.1.p0
pyparsing-1.5.2
pysparse-1.1-6301cea
python-2.6.4.p7
python_gnutls-1.1.4.p7
readline-6.0
sage_scripts-3.4.2
scipy-0.7.p4
setuptools-0.6c9.p0
sfepy-2009.3
sphinx-0.6.3.p4
swig-1.3.36
sympy-5d78c29
termcap-1.3.1.p1
twisted-9.0.p2
vtk-cvs-20090316-minimal.p6
zlib-1.2.3.p5


Let me know if you have any hints what to try.

Ondrej

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] web gui

2010-06-16 Thread Ondrej Certik 
Hi,

could someone please point me to the latest status of the web gui?

I am now in LLNL and I don't have a root access to my computer
(running rhel5), and there is no Tk, nor Tkinter Python modules. I
have installed femhub, so I have the whole python stack, but I don't
have any gui. Mpl can save figures to a file, so at least something.
But I am missing the zoom feature.

I found the following cool libraries:

http://www.sencha.com/
http://raphaeljs.com/
http://g.raphaeljs.com/

that work perfectly in my browser (FF3). So I wondered how hard it
would be to use them as an mpl backend? All I need, I think, is just
simple plotting, and zoom (+pan).

I could adapt for example:

lib/matplotlib/backends/backend_tkagg.py

but it seems quite involved. Is there some simple thing, that would
"just work" for me, that I could start adapting for the web gui? I
would imagine that show() would launch a web server and tell the user
to go to localhost:8080 or something and then the gui would be in the
browser. The browser can even be opened automatically.

Ondrej

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] web gui

2010-06-16 Thread Ondrej Certik 
Hi William,

On Wed, Jun 16, 2010 at 4:33 PM, william ratcliff
 wrote:
> I have a student here trying to make a webapp for data reduction.  To add
> interactivity, we've been using the FLOT package, and may later consider
> protovis.  We had thought about making a javascript backend for MPL, but to
> just get something running, we went with FLOT for the time being...We're
> using EXTJS as the web framework (it's a bit heavy, but has a rich widget
> toolkit and documentation).  We use Django on the backend and Orbited to
> deal with some communications between the browser and the server (for
> example if we get new data from an instrument and want to update it on the
> server and update plots that are viewing that data..).  Over the next couple
> of weeks (with the arrival of another student), we will be working more with
> the plotting aspect of the project (adding legends, zooming, etc).   Also,
> for other parts of the app, we're just using the HTML5 canvas...I'd be happy
> to work on making the plotting addons as generic as possible so they can be
> used outside of our problem domain.  What I'm not sure is whether one wants
> to truly use MPL as a backend, or rather to use the MPL philosophy of a
> javascript package.

That would be exactly what I could reuse. Is the code available as
opensource somewhere?

Ondrej

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] web gui

2010-06-16 Thread Ondrej Certik 
On Wed, Jun 16, 2010 at 5:13 PM, william ratcliff
 wrote:
> Do you want the whole code base?

Well, if you can send me something to start from, that'd be awesome. I
have put my initial code here:

http://github.com/certik/jsplot

it uses django + raphael. Now I need to write a simple MPL like api,
and also implement zoom somehow.
I think I'll make it work for my purposes soon hopefully.

Ondrej

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] web gui

2010-06-16 Thread Ondrej Certik 
On Wed, Jun 16, 2010 at 6:01 PM, Ondrej Certik  wrote:
> On Wed, Jun 16, 2010 at 5:13 PM, william ratcliff
>  wrote:
>> Do you want the whole code base?
>
> Well, if you can send me something to start from, that'd be awesome. I
> have put my initial code here:
>
> http://github.com/certik/jsplot
>
> it uses django + raphael. Now I need to write a simple MPL like api,
> and also implement zoom somehow.
> I think I'll make it work for my purposes soon hopefully.

These guys already implemented zoom in the flotr library:

http://phenxdesign.net/projects/flotr/examples/prototype/mouse-zoom-preview.html

So maybe I'll just use that. In FF3 it's terribly slow though...

Ondrej

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] web gui

2010-06-17 Thread Ondrej Certik 
On Thu, Jun 17, 2010 at 6:57 AM, Ludwig Schwardt
 wrote:
> Hi,
>
> Simon Ratcliffe (the other Ratcliff :-)) and myself are working on an
> MPL backend that uses the HTML5 Canvas element. It is nearly done and
> soon to be released, once we get permission from our employer to
> release it under an open-source license. It does zooming and pretty
> good animation as well. It also has no additional dependencies except
> for Matplotlib and currently runs on the latest HTML5-compliant
> browsers (Chrome 4+, Safari 5, IE9 when released, Firefox nightlies).
>
> Some idea of its functionality can be seen at
> http://genotrak.webfactional.com/mplh5canvas/.
>
> We will keep the list updated on its progress.

That would be exactly what I need. Do you have any time frame for the
release? The problem is that I need it right now. So I'll try to
finish my own stuff today, so that I can at least work and then later
improve it or switch to your stuff.

Ondrej

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] web gui

2010-06-17 Thread Ondrej Certik 
Hi Andrew!

On Wed, Jun 16, 2010 at 3:45 PM, Andrew Straw  wrote:
> Hi Ondrej,
>
> If I was in your shoes, the first thing I'd do is emit your data to plot
> as a json object and then plot that data using javascript with one of
> the libraries you've listed. Then, after gaining some familiarity with

Thanks for the encouraging email. So I have code up a simple
prototype, using exactly the approach you suggested. Examples +
screenshot available at:

http://github.com/certik/jsplot

(just scroll down with your browser, github nicely renders the README.rst).

> Python->json->javascript I'd think about how such an MPL backend might
> work. A usecase I could imagine is some Django app that uses MPL to plot
> stuff into a javascript canvas element complete with zooming and so on.

Yes, I use django and instead of mpl, I use the flotr library, that
does zooming+plotting automatically.

>
> I think there are a lot of open questions in this domain... For example,
> presumably one doesn't want the server involved when the client browser
> zooms. But then if you implement something that allows the client
> browser to zoom without the server MPL process, you're no longer using
> the normal MPL callback system. So, interactivity would probably be

Yes, in fact, I am not using MPL at all.

> different than in the traditional backends.
>
> You could also start with the svg backend, as browsers do render svg.

I wonder what to do now. I think I'll just emulate the MPL api, that's
easy. Anyway, I can work finally.

Thanks for the help!

Ondrej

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] HTML5 Matplotlib Backend

2010-07-06 Thread Ondrej Certik 
On Mon, Jun 21, 2010 at 7:51 AM, william ratcliff
 wrote:
> I just tested it and it's very cool!  It works fairly quickly locally.  It
> seems to work for Safari 5 and Chrome beta.  Firefox 3.6.3 is a no show.  I
> haven't tried Opera.   What I'm really curious about is what is the latency
> like over the actual internet, or under higher server loads (given the round
> tripping).  For us, I'd have to try to get it to work for firefox (I think
> as a cross platform browser, it's fairly common, especially on linux systems
> like Fedora, it's what the user is most likely to have.).  Thanks for
> sharing this!
>
> William
>
> On Mon, Jun 21, 2010 at 9:19 AM, Simon Ratcliffe 
> wrote:
>>
>> Hello,
>>
>> Our HTML5 based matplotlib backend is now available at:
>>
>> http://code.google.com/p/mplh5canvas/
>>
>> There are some basic installation instructions and included examples
>> to get going. Keep in mind that the weakest link at this stage is
>> browser support.
>>
>> We recommend Chrome for the most hassle free experience.
>>
>> This is very much a beta release and has not seen action outside of
>> our internal testing, so we expect some teething troubles :)
>>
>> Please let us know what works for you, and what doesn't, and we will
>> try and fix things as they come up.

This looks very exciting. I don't know how to install chrome on my
rhel5 without root access (I didn't find any binary and the source
build fails due to some missing dependencies) and I have FF3.6.6, but
I'll try to download some development binary of FF, so that it works.

Ondrej

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

2010-08-31 Thread Ondrej Certik 
On Mon, Aug 30, 2010 at 9:59 PM, Fernando Perez  wrote:
> On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root  wrote:
>> Dude, that just blew my mind!
>>
>
> Glad you like it :)
>
> And needless to say, once the dust settles and someone is willing, the
> obvious thing to do is to put a zeromq-http bridge and make a web
> browser-based client, so you can use ipython/matplotlib from your
> android/iphone/netbook/whatever.
>
> We've been scrupulously careful not to introduce any python
> assumptions client-side, so that in principle frontends can be written
> in any language or toolkit (e.g. html/javascript), the entire system
> is specified by its messaging protocol:
>
> http://ipython.scipy.org/doc/nightly/html/development/messaging.html

That'd be great. I think I either want to use regular terminal, or a
worksheet in the browser.

Ondrej

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI

2010-08-31 Thread Ondrej Certik 
On Tue, Aug 31, 2010 at 1:25 PM, Fernando Perez  wrote:
> On Tue, Aug 31, 2010 at 1:21 PM, Ondrej Certik  wrote:
>>
>> That'd be great. I think I either want to use regular terminal, or a
>> worksheet in the browser.
>
> You may change your mind when you start playing with the new Qt
> terminal :)  It feels very much like a terminal, except with a ton of
> little useful touches that make it very effective.  It still has a lot
> of rough edges, but Evan has done a phenomenal job there.  I'm now
> using it as my regular ipython instead of the normal one, dogfooding
> enough that we hit all the key usability quirks quickly, and act on
> them.

Ok, I'll give it a shot then.

Ondrej

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] merging sympy plotting stuff with matplotlib

2007-12-30 Thread Ondrej Certik 
Hi matplotlib developers,

we are developing a symbolic manipulation library in pure Python:

http://code.google.com/p/sympy/

and we wanted to do 3D plotting. To make a long story short, here is a
tutorial for our 3D plotting stuff:

http://code.google.com/p/sympy/wiki/PlottingModule

here is a reasoning behind all of this:

http://code.google.com/p/sympy/wiki/PlottingReport

especially this:

http://straightupcoding.blogspot.com/2007/05/case-for-dropping-matplotlib.html


We should have gotten involved more in matplotlib development earlier,
but at least now. I think there should be just one 3D plotting
library in Python and imho matplotlib should do it. However, we need:

* it should be pure python
* fast and interactive 3D stuff
* needs to work out of the box on linux, mac os x, windows (without compilation)

you can read all details above, but we simply use pyglet
(http://pyglet.org/), that is like pygame, but better (pure python,
works out of the box on all platforms etc).

Are you interested in getting our 3D stuff into matplotlib?

If yes, is there a way to make matplotlib pure python?

Looking at matplotlib sources, the only things done in C++ are agg
backend, and then the src/* directory, which I am not sure what
exactly it's doing, but I don't see a reason why the kernel of
matplotlib cannot be in pure Python (calling python gtk etc.).
Optionally, there can be the C++ modules.

If such a division is possible, then we could just include matplotlib
in sympy sources, the license of matplotlib seems quite permissive:

http://matplotlib.sourceforge.net/license.html

so it should allow this (sympy and pyglet is BSD). In distributions,
like Debian, sympy will just depend on matplotlib in debian. But the
sympy tarball should be self-contained.

The sympy plotting is quite nice, especially that you just download
the tarball and it works (even on windows, or macosx) without
compilation, however it's missing a lot of features that matplotlib
has, so the best thing to do is to integrate it in matplotlib.

Another cool stuff in matplotlib is the pure python latex renderer
(/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for
more info:

http://code.google.com/p/sympy/issues/detail?id=506

we want to use it in our preview capability (currently only in our hg repo):

$ hg clone http://hg.sympy.org/sympy/
$ cd sympy
$ bin/isympy
[...]
In [1]: from sympy.abc import *

In [2]: pngview(Integral(exp(-(tau-mu)**2/2/sigma**2), (tau, -oo, oo))/
   ...: sigma/sqrt(2*pi))

And a window will popup (using pyglet) showing a nice latex printed
expression. Currently, you need to have latex installed (and
python-pexpect)
for it to be working. (if you use sympy hg right now, you need
python-pexpect, but we'll fix this before we release soon:
http://code.google.com/p/sympy/issues/detail?id=520, any sympy tarball
only needs pure Python 2.4 or newer and it will just work, otherwise
it's a bug)

So it'd be cool to you your pure python reimplementation of the tex
engine. Maybe let's create a new (standalone) project just for this
feature? I am sure
it will benefit to a lot of people. And sympy and matplotlib will just
include it in the sources.

If you have any other ideas regarding these issues, we are interested.

Looking for collaboration,
Ondrej

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] merging sympy plotting stuff with matplotlib

2007-12-30 Thread Ondrej Certik 
Resending, the first try doesn't seem to make it to the list.


-- Forwarded message --
From: Ondrej Certik <[EMAIL PROTECTED]>
Date: Dec 30, 2007 7:33 PM
Subject: merging sympy plotting stuff with matplotlib
To: [email protected]


Hi matplotlib developers,

we are developing a symbolic manipulation library in pure Python:

http://code.google.com/p/sympy/

and we wanted to do 3D plotting. To make a long story short, here is a
tutorial for our 3D plotting stuff:

http://code.google.com/p/sympy/wiki/PlottingModule

here is a reasoning behind all of this:

http://code.google.com/p/sympy/wiki/PlottingReport

especially this:

http://straightupcoding.blogspot.com/2007/05/case-for-dropping-matplotlib.html


We should have gotten involved more in matplotlib development earlier,
but at least now. I think there should be just one 3D plotting
library in Python and imho matplotlib should do it. However, we need:

* it should be pure python
* fast and interactive 3D stuff
* needs to work out of the box on linux, mac os x, windows (without compilation)

you can read all details above, but we simply use pyglet
(http://pyglet.org/), that is like pygame, but better (pure python,
works out of the box on all platforms etc).

Are you interested in getting our 3D stuff into matplotlib?

If yes, is there a way to make matplotlib pure python?

Looking at matplotlib sources, the only things done in C++ are agg
backend, and then the src/* directory, which I am not sure what
exactly it's doing, but I don't see a reason why the kernel of
matplotlib cannot be in pure Python (calling python gtk etc.).
Optionally, there can be the C++ modules.

If such a division is possible, then we could just include matplotlib
in sympy sources, the license of matplotlib seems quite permissive:

http://matplotlib.sourceforge.net/license.html

so it should allow this (sympy and pyglet is BSD). In distributions,
like Debian, sympy will just depend on matplotlib in debian. But the
sympy tarball should be self-contained.

The sympy plotting is quite nice, especially that you just download
the tarball and it works (even on windows, or macosx) without
compilation, however it's missing a lot of features that matplotlib
has, so the best thing to do is to integrate it in matplotlib.

Another cool stuff in matplotlib is the pure python latex renderer
(/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for
more info:

http://code.google.com/p/sympy/issues/detail?id=506

we want to use it in our preview capability (currently only in our hg repo):

$ hg clone http://hg.sympy.org/sympy/
$ cd sympy
$ bin/isympy
[...]
In [1]: from sympy.abc import *

In [2]: pngview(Integral(exp(-(tau-mu)**2/2/sigma**2), (tau, -oo, oo))/
   ...: sigma/sqrt(2*pi))

And a window will popup (using pyglet) showing a nice latex printed
expression. Currently, you need to have latex installed (and
python-pexpect)
for it to be working. (if you use sympy hg right now, you need
python-pexpect, but we'll fix this before we release soon:
http://code.google.com/p/sympy/issues/detail?id=520, any sympy tarball
only needs pure Python 2.4 or newer and it will just work, otherwise
it's a bug)

So it'd be cool to you your pure python reimplementation of the tex
engine. Maybe let's create a new (standalone) project just for this
feature? I am sure
it will benefit to a lot of people. And sympy and matplotlib will just
include it in the sources.

If you have any other ideas regarding these issues, we are interested.

Looking for collaboration,
Ondrej

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] merging sympy plotting stuff with matplotlib

2008-01-04 Thread Ondrej Certik 
Hi Michael, John and Gael,

sorry for the later reply (holidays and stuff...)

On Jan 1, 2008 4:51 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> I'm off with family for the holidays, so my response will have to be somewhat
> brief.
>
> I'm excited about the ideas you bring up...  I first heard about sympy at 
> SciPy
> and was very impressed.  Let's try to collaborate in any way possible.  I know
> that "3D in matplotlib" already has some history of which I'm not aware, so 
> I'll
> leave that for others to comment on.
>
> As for the C++ dependencies, Agg is a pretty strong one.  Yes, it is possible 
> to
> do rendering with Gtk or Wx alone, but it's not very pretty (no-aa).  
> Gtk/Cairo is
> a good high-quality combination, but it (at least currently) leaves out all 
> the
> other GUI frameworks, and is not BSD-like licensed.  The other important
> C/C++ requirement is matplotlib's interface to freetype (FT2Font).  That would
> be really painful to reimplement in pure Python -- freetype is a complex and
> mature piece of software.  In the trunk, there is a required framework for
> transformations, and in the "transforms branch" there is a framework for
> polycurve manipulations, both of which are required to do any plotting.  Those
> would have a major performance penalty going to Python, and even
> notwithstanding, are non-trivial bits of code to reimplement.  Beyond that, 
> there
> are utilities for contours and images etc., which are reasonably optional but
> people use all the time.  In short, there's a not of C/C++ in the core of
> matplotlib -- maybe the time would be better spent resolving any build issues
> that make portability difficult...?  I'm not sure it's realistic to expect 
> matplotlib to
> be pure Python at this point without losing a lot of features, but I agree it 
> would
> be nice...

I'll reply to this below.

> As for the mathtext Python math rendering engine, it isn't *really* pure 
> Python.
> It relies on matplotlib's interface to Freetype.  Ideally, it would be nice 
> to have a
> general-purpose Python interface to freetype (I know the PyCairo folks are
> wanting such a thing), and then the mathtext engine could use that.
> Unfortunately, the existing freetype wrapper in matplotlib is very incomplete
> and pretty tied to matplotlib-specific ways of doing things.  IMHO, you 
> wouldn't
> really gain much by releasing FT2Font as a separate project unless it were
> generalized.  I've sort of gone into a holding pattern, hoping someone else 
> will
> release a Python freetype wrapper that matplotlib could use...  
> Alternatively, the
> dependency on freetype could be removed by extracting and hardcoding all the
> font metrics from the math fonts into Python dictionaries etc. -- but then of
> course it would only work with a fixed set of fonts.  This is what jsMath, (a
> pure-Javascript math rendering engine) does, for instance.
>
> With the exception of that issue, removing the mathtext engine from matplotlib
> should be possible, and I think it's a great idea.  There are some matplotlib-
> specific bits mixed in there, but they should be reasonably straightforward to
> factor out.  It already has support for rendering math to an in-memory image
> bitmap, which has been used for displaying math on GUI widgets, for example.
>
> Anyway -- cool ideas.  Let's keep up the discussion.
>
> Cheers,
> Mike
>



On Jan 1, 2008 3:51 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Dec 30, 2007 12:33 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
> > We should have gotten involved more in matplotlib development earlier,
> > but at least now. I think there should be just one 3D plotting
> > library in Python and imho matplotlib should do it. However, we need:
>
> Hi Ondrej,
>
> Sorry for the delay getting back to you.  I've been on holiday so have
> only limited email access.
>
> > * it should be pure python
> > * fast and interactive 3D stuff
> > * needs to work out of the box on linux, mac os x, windows (without 
> > compilation)
>
> We have long wanted limited 3D capability in matplotlib, and as you
> know we have some functionality in the axes3d classes but it has
> proven to be extremely slow, and somewhat buggy, and the original
> author has moved on to other things so it is mostly unsupported.  We
> would be very excited if there was some way to incorporate your work
> using pyglet, which is very nice.
>
> matplotlib started out life as pure python, and for several release
> cycles remained that way.  A that time, there were two backends, GTK
> and PS, so th

Re: [matplotlib-devel] merging sympy plotting stuff with matplotlib

2008-01-04 Thread Ondrej Certik 
On Jan 4, 2008 7:41 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> Ondrej Certik wrote:
> > * freetype (this could be rewritten using ctypes)
>
> I see that pyglet already has a freetype wrapper using ctypes -- it
> would be interesting to see if that could be used as a starting point.
> That could be used as a starting point.  (Of course, ctypes is an
> external dependency before Python-2.5, which adds a dependency to
> matplotlib).

That is correct. I forgot about that. We do support python2.4 and it's
true that in order
for plotting to work, you need to install python-ctypes.
But python2.4 will hopefully get old soon, in favor of python2.5.

> I generally don't like ctypes-based wrappers since changes in the
> dependency can mean segfaults at runtime.  I'm having a problem getting
> pyglet to work on my particular version of OpenGL, for instance.  But
> perhaps freetype is stable enough for that not to be a problem.

Could you please report it to http://groups.google.com/group/pyglet-users ?

Alex (the author of pyglet) is really responsive. My own experience is
that it works out of the box.

> > * Agg (this could be optional)
>
> On the transforms branch, Agg is used for bezier curve realisation,
> whether the Agg renderer is being used or not.  This is used for things
> like hit-testing and range-setting of path collections etc.  This was
> not fast enough in my earlier numpy-based implementation, since to take
> advantage of numpy, you generally have to allocate lots of memory to
> store the results in.  In this particular case, each value can be
> immediately thrown away, so all that extra work was unnecessary.

So it's needed for path collections - what is that? When I want to do
regular plots,
like plotting some set of points, is that needed too? If not, it
should be optional imho.

> > Compiling really sucks.
>
> Agreed.  But there is a spectrum of suckage here.  It also sucks to be
> unable to check that a call to some library that you don't provide
> (freetype) will succeed.

That sucks too. But I think there are mechanisms to check the exact version
of the library, aren't there?

> >>> Another cool stuff in matplotlib is the pure python latex renderer
> >>> (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for
> >>> more info:
> >> Yes, the mathtext support in matplotlib is very nice, and Michael
> >> deserves the credit for taking from a package that
> >> works but has warts, to an extremely nice math layout engine using the
> >> Knuth algorithms.  I'm sure others would like to use it without having
> >> to pull in all of matplotlib.  With a ctypes freetype wrapper, it
> >> should be possible to build a free-standing mathtext.
> >
> > And this is really cool. I would like to have that. :)
> >
> > We'll try to help with that one.
>
> Great!  I'll start by looking at pyglet's freetype wrapper and see how
> far I get.

Awesome. Please ask on the list above, as I said, Alex is quite guru, so he
will answer any technical questions.

Ondrej

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] merging sympy plotting stuff with matplotlib

2008-01-04 Thread Ondrej Certik 
On Jan 4, 2008 8:19 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> On Jan 4, 2008 11:55 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
> > > > * Agg (this could be optional)
> > >
> > > On the transforms branch, Agg is used for bezier curve realisation,
> > > whether the Agg renderer is being used or not.  This is used for things
> > > like hit-testing and range-setting of path collections etc.  This was
> > > not fast enough in my earlier numpy-based implementation, since to take
> > > advantage of numpy, you generally have to allocate lots of memory to
> > > store the results in.  In this particular case, each value can be
> > > immediately thrown away, so all that extra work was unnecessary.
> >
> > So it's needed for path collections - what is that? When I want to do
> > regular plots,
> > like plotting some set of points, is that needed too? If not, it
> > should be optional imho.
>
> It's probably worth mentioning that one of the reasons John chose Agg
> is because of image *quality* concerns.  If I'm not mistaken (John and
> A. Straw will correct me as needed), the OpenGL anti-aliasing quality
> is positively horrible when you compare it to the quality of Agg.
> Keep in mind that OpenGL is typically focused on keeping high
> frame-rates for moving images, so pixel-perfect antialiasing is much
> less of a concern for them, since your eye is a lot less likely to
> notice such fine details (as long as there is *some* antialiasing).
> For a static image, you tend to be a lot pickier, and Agg goes to
> great lengths to ensure the best possible antialiasing quality.  This
> is part of the reason why normal television, at abysmally low
> resolutions is still acceptable for viewing, while nobody would
> consider a 400-line-image an acceptable photograph for most uses.  You
> 'stare' at the moving image only for 1/30 s or so, while you look at
> the static one for much longer.
>
> Just look at some of their examples to get an idea of what I'm talking about:
>
> http://www.antigrain.com/screenshots/index.html
>
> I've never seen any opengl-based antialiasing be of that quality.  But
> there may be ways of achieving the same thing in OpenGL, I don't know
> (and to do so efficiently and portably, without requiring specific
> video cards).
>
> The other issue I recall is that the quality of openGL antialiasing is
> highly dependent on the video card and/or driver.  While that may be
> OK for gamers, it's completely unacceptable IMO for scientific
> publication.
>
> > > > Compiling really sucks.
>
> Keep in mind that while python+cleverness can get you a lot of speed,
> there are operations that are *inescapably* slow in python's fully
> dynamic model today (without JIT-type tricks a la psyco that avoid
> dynamic dispatch in loops).  Running a tight loop over a million
> elements of anything to do some repetitive operation will incur in
> Python's runtime check costs on every pass of the loop.  In a plotting
> library, this type of computation is very frequent, and while some of
> it can be rolled into numpy-type array operations, that's not always
> possible.  There's simply no way out (today) from compiled code for
> certain things in python, I'm afraid.  Keep in mind that there are
> still people who regularly complain about MPL being *too slow* for
> their purposes, which involve interactive data exploration of enormous
> datasets.  I'm sure that loss of speed would not be considered a
> desirable feature for a new MPL release by many :)
>
> I'm certainly hoping you guys can find some mechanism to join forces
> on this front, which I would absolutely love to see.  But I just want
> to provide a bit of context as to why MPL uses extensions like Agg and
> relies on compiled code, which is I think a fairly critical need of
> the project.
>
> Having said all this, I'd be thrilled to be proven 100% wrong in all
> of the above, and to see a pure-python MPL that is as fast as today's
> and maintains the image quality we have today.
>
> One approach that has been thrown around in the past was to have an
> opengl based render while working interactively, that would force a
> re-render of the same entire scene via Agg for image saving. I don't
> know enough about the MPL internals to say how feasible this would be.

Hi Fernando!

what you said are valid points for matplotlib using Agg as a backend.
And as I said,
the default matplotlib installation should include it, no doubt about that.

On the other hand, I (and I think many other users) only need the super quality
only when saving the final plot. Of

Re: [matplotlib-devel] merging sympy plotting stuff with matplotlib

2008-01-04 Thread Ondrej Certik 
On Jan 4, 2008 8:44 PM, Darren Dale <[EMAIL PROTECTED]> wrote:
>
> On Friday 04 January 2008 02:36:06 pm Ondrej Certik wrote:
> > On Jan 4, 2008 8:19 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> > > On Jan 4, 2008 11:55 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> > > > > > * Agg (this could be optional)
> > > > >
> > > > > On the transforms branch, Agg is used for bezier curve realisation,
> > > > > whether the Agg renderer is being used or not.  This is used for
> > > > > things like hit-testing and range-setting of path collections etc.
> > > > > This was not fast enough in my earlier numpy-based implementation,
> > > > > since to take advantage of numpy, you generally have to allocate lots
> > > > > of memory to store the results in.  In this particular case, each
> > > > > value can be immediately thrown away, so all that extra work was
> > > > > unnecessary.
> > > >
> > > > So it's needed for path collections - what is that? When I want to do
> > > > regular plots,
> > > > like plotting some set of points, is that needed too? If not, it
> > > > should be optional imho.
> > >
> > > It's probably worth mentioning that one of the reasons John chose Agg
> > > is because of image *quality* concerns.  If I'm not mistaken (John and
> > > A. Straw will correct me as needed), the OpenGL anti-aliasing quality
> > > is positively horrible when you compare it to the quality of Agg.
> > > Keep in mind that OpenGL is typically focused on keeping high
> > > frame-rates for moving images, so pixel-perfect antialiasing is much
> > > less of a concern for them, since your eye is a lot less likely to
> > > notice such fine details (as long as there is *some* antialiasing).
> > > For a static image, you tend to be a lot pickier, and Agg goes to
> > > great lengths to ensure the best possible antialiasing quality.  This
> > > is part of the reason why normal television, at abysmally low
> > > resolutions is still acceptable for viewing, while nobody would
> > > consider a 400-line-image an acceptable photograph for most uses.  You
> > > 'stare' at the moving image only for 1/30 s or so, while you look at
> > > the static one for much longer.
> > >
> > > Just look at some of their examples to get an idea of what I'm talking
> > > about:
> > >
> > > http://www.antigrain.com/screenshots/index.html
> > >
> > > I've never seen any opengl-based antialiasing be of that quality.  But
> > > there may be ways of achieving the same thing in OpenGL, I don't know
> > > (and to do so efficiently and portably, without requiring specific
> > > video cards).
> > >
> > > The other issue I recall is that the quality of openGL antialiasing is
> > > highly dependent on the video card and/or driver.  While that may be
> > > OK for gamers, it's completely unacceptable IMO for scientific
> > > publication.
> > >
> > > > > > Compiling really sucks.
> > >
> > > Keep in mind that while python+cleverness can get you a lot of speed,
> > > there are operations that are *inescapably* slow in python's fully
> > > dynamic model today (without JIT-type tricks a la psyco that avoid
> > > dynamic dispatch in loops).  Running a tight loop over a million
> > > elements of anything to do some repetitive operation will incur in
> > > Python's runtime check costs on every pass of the loop.  In a plotting
> > > library, this type of computation is very frequent, and while some of
> > > it can be rolled into numpy-type array operations, that's not always
> > > possible.  There's simply no way out (today) from compiled code for
> > > certain things in python, I'm afraid.  Keep in mind that there are
> > > still people who regularly complain about MPL being *too slow* for
> > > their purposes, which involve interactive data exploration of enormous
> > > datasets.  I'm sure that loss of speed would not be considered a
> > > desirable feature for a new MPL release by many :)
> > >
> > > I'm certainly hoping you guys can find some mechanism to join forces
> > > on this front, which I would absolutely love to see.  But I just want
> > > to provide a bit of context as to why MPL uses extensions like Agg and
> > > relies on compiled code, which is I think a fai

Re: [matplotlib-devel] merging sympy plotting stuff with matplotlib

2008-01-04 Thread Ondrej Certik 
> Agreed.  I know there are still some matplotlib users on python2.3, but
> they'll have to move on eventually... ;)

Yes, we decided to drop support for python2.3, because we use
decorators. But I am not going to drop support for 2.4, because
Debian (my distribution) still uses it by default. :)

> >> I generally don't like ctypes-based wrappers since changes in the
> >> dependency can mean segfaults at runtime.  I'm having a problem getting
> >> pyglet to work on my particular version of OpenGL, for instance.  But
> >> perhaps freetype is stable enough for that not to be a problem.
> >
> > Could you please report it to http://groups.google.com/group/pyglet-users ?
>
> Sorry -- I should have mentioned I already did.

Ah, so mdboom is you? I saw the headline, but I didn't look further.
Nice bug report!

> > So it's needed for path collections - what is that?
>
> A collection of a large number of paths (or polygons) that need to be
> rendered quickly.
>
> > When I want to do
> > regular plots,
> > like plotting some set of points, is that needed too? If not, it
> > should be optional imho.
>
> That's actually a tough one.  On the transforms branch, by the time it
> hits the rendering level, everything is a polycurve path.  Determining
> if something contains curves or not (which in the current implementation
> would require running through the entire path, which may be quite large)
> would probably be too slow.

I see. In this case, it's probably not worthy to create pure python kernel.
We do have some 2D plotting already, it's fast enough. But it
doesn't contain so many nice features of matplotlib.

> There are.  But the multiple versions of the library must be
> individually tested to have a hope of working -- whereas with the
> compiled model, sometimes the changes between library versions will be
> seamless, other times the compile will fail, both of which are
> preferable to segfaulting at runtime (which admittedly is still possible
> even when compiling.)

I got it now. That's right.

> >> Great!  I'll start by looking at pyglet's freetype wrapper and see how
> >> far I get.
> >
> > Awesome. Please ask on the list above, as I said, Alex is quite guru, so he
> > will answer any technical questions.
>
> Thanks,

Since you already asked, let's wait. :)

> > Granted, this page is getting a little dated, but here's what you get
> > with OpenGL: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html
>
> Thanks, that's the link I was basically quoting from memory, which I'd
> read when you posted it a while ago.  Great reference on this topic.

That's nice enough for me. Don't forget, that I am comparing no
plotting, to some plotting.

Well, definitely, we try to support good interaction with external
packages, like numpy
and matplotlib. But builtin is builtin. :)

Ondrej

Ondrej

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plotting a series of 3D points and, picker=True and 3D

2008-02-05 Thread Ondrej Certik 
On Jan 31, 2008 11:35 PM, Johann Cohen-Tanugi <[EMAIL PROTECTED]> wrote:
> Actually, it seems that the following thread is also relevant to this
> issue : [matplotlib-devel] merging sympy plotting stuff with matplotlib
> 

Yes, but the conclusion is that someone needs to sit down and
implement the 3D stuff, but we seem quite busy, certainly I am.

I am also very interested in extracting the latex rendering engine
into a separate (pure python) package, but also don't have time for
this anytime soon.

Ondrej

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] pure python TeX math engine

2008-03-28 Thread Ondrej Certik 
Hi,

was there any new progress for the TeX engine since our last conversation?

We got a GSoC application for SymPy, that (among other things) would
try to disentangle the TeX engine from matplotlib, so that it can be
easily used from other projects as well.

What are your intentions with the engine - do you still hack on it, or
do you consider it more or less complete for your needs? I don't want
to have 2 incompatible engines in python - but if you are not going to
hack on it (much), then I think it makes sense to create a new project
for this and you can just include it. Because I think it's an
extremely cool and useful thing.

And we want to have this in sympy too, because we have quite nice
ascii art printing, so having nice graphics printing is just a next
step.

Ondrej

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pure python TeX math engine

2008-03-28 Thread Ondrej Certik 
Hi Michael!

Thanks a lot for a thourough reply. I've CCed Saroj, the GSoC
applicant. I hope he'll succeed.

If you could mentor, that'd be great. Do you want to mentor officially
or unofficially? If officially, you need to be a PSF mentor (let me
know, I'll help
you do the administration). If unofficially, I can be the mentor and
you can help Saroj with the TeX part of his app.

Actually, if it's not a problem for you, I'd prefer the official way,
for example you can be a backup mentor. Also you'll get a google GSoC
t-shirt. :)

Ondrej

On Fri, Mar 28, 2008 at 2:22 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> Well, that work has gone from a "paid to work on it" to a "hobby
>  project", so it's harder to find the time.
>
>  In terms of "math rendering" features, it's pretty complete.  It's not
>  100% of TeX, and it never will be, but it's able to do most of the
>  really common things.
>
>  I would like to see this as an independent Python package.  The pieces
>  that are missing to do this are:
>
>  Freetype wrappers: One could just extract the existing freetype wrappers
>  in mpl.  But that duplicates that code in two places, and those wrappers
>  were built on a sort of "as needed" basis, and wouldn't be considered
>  complete for any other purpose.  (Maybe not a bad thing, though).  The
>  ctypes-based wrapper in pyglet is a candidate, but last time I looked,
>  it's missing some features to extract the glyph metadata that mathtext
>  needs.  Plus, there always seem to be version mismatch problems with
>  ctypes-based stuff, at least for me.  I'd still love to see a proper C
>  freetype wrapper as an independent project.  PIL has a very basic one,
>  that doesn't even come close to what we need -- but perhaps it's a
>  starting point that could be extended.
>
>  A basic bitmap rendering engine: It needs to be able to take the glyph
>  buffers from freetype and blend them onto an image, as well as draw
>  filled rectangles.  So it doesn't need to be anything as full-blown as
>  Agg, and could probably be built on top of numpy or PIL, or as a C
>  extension, but pure Python ain't gonna cut it.  This should then
>  integrate with PILand/or pyglet to save PNG, JPEG files etc.
>
>  Non-bitmap backends: These would be subsets of the matplotlib backends,
>  but we would probably want the basic ability to write out PS, PDF and
>  SVG etc.  This is probably the biggest part of matplotlib that would
>  need to be "pulled out", and the trickiest.  It would still be useful to
>  just have the "generic" vector description of the equations from
>  mathtext and consider these backends as a secondary feature for later.
>  An HTML backend that does glyph placement with CSS and Canvas would
>  probably also be very useful for webpage output.
>
>  So, that's a lot of work there, but it's all doable and should be fairly
>  unsurprising.  I'd be happy to unofficially help mentor someone doing a
>  GSoC project on this, but I don't think I'll have time to do all of the
>  work myself in the near future.
>
>  Cheers,
>  Mike
>
>
>
>  Ondrej Certik wrote:
>  > Hi,
>  >
>  > was there any new progress for the TeX engine since our last conversation?
>  >
>  > We got a GSoC application for SymPy, that (among other things) would
>  > try to disentangle the TeX engine from matplotlib, so that it can be
>  > easily used from other projects as well.
>  >
>  > What are your intentions with the engine - do you still hack on it, or
>  > do you consider it more or less complete for your needs? I don't want
>  > to have 2 incompatible engines in python - but if you are not going to
>  > hack on it (much), then I think it makes sense to create a new project
>  > for this and you can just include it. Because I think it's an
>  > extremely cool and useful thing.
>  >
>  > And we want to have this in sympy too, because we have quite nice
>  > ascii art printing, so having nice graphics printing is just a next
>  > step.
>  >
>  > Ondrej
>  >
>  > -
>  > Check out the new SourceForge.net Marketplace.
>  > It's the best place to buy or sell services for
>  > just about anything Open Source.
>  > 
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>  > ___
>  > Matplotlib-devel mailing list
>  > [email protected]

[matplotlib-devel] figures look nice

2008-07-08 Thread Ondrej Certik 
Hi,

I just wanted to say that I like the current matplotlib's (0.98.1)
line thickness and colors.

I don't know what exactly has changed since before, but the figures
now look really great. It's a pleasure to look at it. Thanks!

Ondrej

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] questions regarding mathtext

2008-07-09 Thread Ondrej Certik 
Hi,

I have a question regarding the pure python latex rendering engine. If
I look here:

http://matplotlib.sourceforge.net/doc/html/users/mathtext.html#fonts

was this generated using it? If so, it seems to me it doesn't look
exactly as TeX output, for example in the sqrt(2), the upper line is
slightly over the edge of the \/ line in the sqrt.

Or in the s(t) = Asin(wt)

the "A" and "sin" is too much close to each other. Or if you scroll to
the very bottom of the page, the Sum and x_i are also too much close
to each other.

Is it a font problem? If yes, how could this be fixed? If not, would
it be difficult to find the problem in the algorithm and fix it? I
haven't studied the TeX algorithm deeply,
so I cannot judge if it's a trivial fix, or something very difficult.

Otherwise it looks good. We were thinking with Stefan that when we get
to Austin together on around August 8, we'll polish it and get it to
sphinx by default, so that any other project, like numpy or sympy
could use it as well easily.

Thanks a lot,
Ondrej

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel