[matplotlib-devel] Detailed instructions for compiling matplotlib on Windows XP

[Ian Bell]

Hello all,

I finally, after much pain and anguish, succeeded at compiling MPL with
GTKAgg on windows and I thought people might be interested to know how I
managed it.  Of course, your mileage may vary...


   1. Install Python (I used the Python (x,y) distribution of 2.6:
   http://code.google.com/p/pythonxy/wiki/Downloads
   2. Install the GTK bits and pieces.  For some reason using the newest
   ones causes some problems with paths.  I can confirm that this set works on
   at least two computers:
   
Glade3.6.7withGTK+.exe
   (Install this to c:\GTK so that MPL build can find it without playing with
   paths)
   
pygtk-2.12.1-3.win32-py2.6.exe
   
pycairo-1.4.12-2.win32-py2.6.exe
   
pygobject-2.14.2-2.win32-py2.6.exe
   3. Install 
libpngand
   freetype  using
   the installers (also includes the zlib dll).  They will default to install
   to c:\Program Files\GnuWin32 . This is fine, but note the location.
   4. Either checkout the MPL source from subversion, or download a
tarballand
unpack it
   5. Download the win32_static
files,
   and unpack them to the place where your MPL source is, you should then have
   a folder in the MPL source folder called win32_static
   6. Open the file setupext.py in the MPL source folder
   7. Edit line 51 (or so) to read:: 'win32' : ['win32_static','c:\\Program
   Files\\GnuWin32']
   8. Install Visual Studio 2008
Expressif
you do not have a version of Visual Studio 2008 on your computer
   9. Open a console and type:: python setup.py build --compiler=msvc
   bdist_wininst
   10. Wait for it to finish, then:: python setup.py install  to install MPL
   11. If everything worked right, you should be able to open a python shell
   and type
   >> import matplotlib
   >> matplotlib.use('GTKAgg')
   >> import pylab
   >> pylab.plot(0,4,'s')
   >> pylab.show()
   12. And you should see a GTK rendered plot window with a small square in
   the center hopefully

Improvements to this procedure would be greatly appreciated - but this
finally seems to work..

Regards,
Ian

Ian Bell
Graduate Research Assistant
Herrick Labs
Purdue University
email: ib...@purdue.edu
cell: (607)227-7626
--
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev ___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Annotations - negative points and pixels don't wrap

[Jae-Joon Lee]

I believe this was recently introduced when I refactored the annotation code.
Attached is a preliminary fix. So, please test it if you can.
Since the change during the refactoring was rather significant, I'm
not 100% sure if this will restore the old behavior without affecting
the new functionality. The examples I tried (including yours) seem to
work fine. I'll test this myself a few more days, and commit to the
svn.

I personally think it is better to use "offset points" for these cases
which makes the internal logic much simpler.

Regards,

-JJ


On Sat, Dec 11, 2010 at 6:07 AM, Stan West  wrote:
> Hi. The docs for Annotation [1] say that negative coordinates given for [
> figure | axes ] [ points | pixels ] xycoords are to be interpreted relative
> to the top-right corner, but I found that they act relative to the
> bottom-left corner as for positive coordinates. This can be seen in the
> attached script and in the annotation_demo.py example [2], where the string
> "bottom right (points)" bleeds off the left edge of the figure.
>
> [1]
> http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.text.Annotation
>
> [2]
> http://matplotlib.sourceforge.net/examples/pylab_examples/annotation_demo.html
>
> --
> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
> new data types, scalar functions, improved concurrency, built-in packages,
> OCI, SQL*Plus, data movement tools, best practices and more.
> http://p.sf.net/sfu/oracle-sfdev2dev
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>


fix_annotation.diff
Description: Binary data
--
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev ___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plot_surface patch

[Benjamin Root]

On Tue, Nov 30, 2010 at 4:53 PM, Benjamin Root  wrote:

> On Wednesday, November 17, 2010, Benjamin Root  wrote:
> > On Tue, Nov 16, 2010 at 5:20 PM, J P  wrote:
> >
> >
> > Hi all, here's my first patch for matplotlib. Someone noticed at Stack
> Overflow that the plot_surface function in mplot3d wasn't especially fast
> for a lot of points (and small rstrides/cstrides) and using shading and a
> single color. I found some parts of the code that weren't vectorized. These
> are my changes so far.
> >
> > Summary of changes:
> > 1. Changed from double looping over aranges to using xrange
> > 2. Made the normalization of the normals and their dot product with the
> vector [-1,-1,0.5] to find the shading a vectorized operation.
> > 3. Changed a list comprehension which calculated the colors using an
> iterative approach to using the already built-in vectorization of the
> Normalization class and using the np.outer function. The result is a numpy
> array rather than a list which actually speeds up things down the line.
> > 4. removed the corners array from plot_surface which wasn't ever used or
> returned. It didn't really slow things down, but I'm thinking that it is
> cruft.
> >
> > For change number two, I made a separate function that generates the
> shades, but feel free to move that around if you prefer.. or maybe it should
> be a function that begins with a _ because it shouldn't be used externally.
> These changes give varying levels of speed improvement depending on the
> number of points and the rstrides/cstrides arguments. With larger numbers of
> points and small rstrides/cstrides, these changes can more than halve the
> running time. I have found no difference in output after my changes.
> >
> > I know there is more work to be done within the plot_surface function and
> I'll submit more changes soon.
> >
> > Justin
> >
> >
> > Justin,
> >
> > Thank you for your efforts to improve the performance of mplot3d.  I will
> take a look at the patches you have submitted and test them out.  What I am
> probably going to do is break down the patches into smaller pieces and
> incorporate them piece-by-piece.
> >
> > I tried refactoring plot_surface once before to mixed results.  The key
> feature I was trying to gain was compatibility with masked arrays.  I wanted
> to duplicate the behavior of contourf and pcolor where masked out portions
> of the surface would not be created.  I managed to get it to work for that
> particular use-case, but I broke a bunch of other use-cases along the way.
> I am curious to see if your patches make this easier/harder to do.
> >
> > Thank you for your efforts and thank you for using matplotlib!
> >
> > Ben Root
> >
> >
>
> I have looked through the patches, and there are definite
> improvements.  I have broken the work into four separate patches.  The
> first patch is essentially code cleanup and utilization of xrange
> (plot_surface_cleanup.patch).  This patch can be back-ported without
> concern (although it doesn't fix any bug per se).
>
> The second patch does the vectorization of the shades.  The original
> patch that was submitted had some edge cases, but I have found that
> just simply converting that for-loop that creates the shades into a
> list comprehension (and then pass into np.array) yielded almost
> identical speedups without changing the current code path.  (Note: I
> am a minimalist when it comes to patches).  This is in
> plot_surface_vectshading.patch.
>
> The third patch improves the calculation of the normals in
> plot_surface by pre-allocating the arrays for calculating the vectors
> and doing a final call to np.cross rather than appending on a list.  I
> deviated slightly from the original patch by calling "which" as
> "which_pt", adding a couple of comments, and also added an else
> condition to create a "normal" with an empty list.  This last part is
> to keep the code path as similar as it was before.  It was
> theoretically possible to utilize a variable called normal elsewhere
> without all the same conditions holding, so this guarantees that
> normal exists, which was the case before.  This patch is
> plot_surface_vectnorm.patch.
>
> Finally, the fourth patch utilizes numpy array functionality for
> calculating the vertexes.  This patch also forgoes the use of
> transposed arrays. I took the original patch a step further and
> eliminated the array transpose line earlier in the plot_surface
> function.  The array transpose was not being properly utilized here,
> and I saw no speed penalty/speedup either way, so in favor of simpler
> code, I eliminated its use.  This patch is
> plot_surface_vectvertex.patch.
>
> Of the four patches, the speedups are in mostly found in the second
> patch (100% speedup).  The first patch does provide noticeable
> improvements.  There is also a slight improvement with the third
> patch.  I am up in the air regarding speed improvements with the
> fourth patch, but I wonder if there might be some memory improvements
> her

[matplotlib-devel] Sourceforge status

[Benjamin Root]

Does some other setting needs to be made to allow me to change the status of
bug reports in sourceforge?  I can't close reports or assign them to myself.

Thanks,
Ben Root
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

[Russell E. Owen]

I'm afraid your change didn't help (I only applied the patch to 
lib/matplotlib/text.py; the cbook.py change appeared to only affect 
whitespace).

However, the memory leak is smaller using the svn trunk than in 
matplotlib 1.0.0. Also, calling subplot.clear() makes the leak worse in 
matplotlib 1.0.0 but not on the trunk.

Here are my results in detail. Before each run I show a few lines of 
code from:

MemoryLeaker's _updateTimeAxis method. Note that the third column is a 
measure of the leak rate and I hold off measuring the leak rate for few 
seconds to give the application a chance to fully load.

-- Russell

matplotlib 1.0.0

self.subplot.set_xlim(tMin, tMax)
# self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027676   nan
   5.028980   nan
  10.129084  20.6
  15.129172  19.0
  20.129268  19.1
  25.229368  19.3
  30.229464  19.2
  35.229564  19.4
  40.229660  19.3
  45.229764  19.5

self.subplot.set_xlim(tMin, tMax)
self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027696   nan
   5.129012   nan
  10.229152  27.5
  15.229292  27.7
  20.229436  28.0
  25.329580  28.1
  30.429728  28.3
  35.429876  28.5
  40.530024  28.6
  45.530160  28.4
  50.630308  28.5


matplotlib svn trunk rev8836

self.subplot.set_xlim(tMin, tMax)
#self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027664   nan
   5.028864   nan
  10.028880   3.2
  15.128884   2.0
  20.128896   2.1
  25.128908   2.2
  30.128916   2.1
  35.128928   2.1
  40.228940   2.2
  45.228948   2.1

self.subplot.set_xlim(tMin, tMax)
self.subplot.clear()
self.canvas.draw()
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027684   nan
   5.128856   nan
  10.128856   0.0
  15.128856   0.0
  20.128864   0.5
  25.228872   0.8
  30.228880   1.0
  35.228884   0.9
  40.228892   1.0
  45.228900   1.1
  50.228920   1.4
  55.328924   1.4
  60.328932   1.4
  65.328940   1.4

After applying your patch to svn trunk rev8836:
--- lib/matplotlib/text.py (revision 8819)
+++ lib/matplotlib/text.py (working copy)
@@ -143,6 +143,9 @@
Handle storing and drawing of text in window or data coordinates.
"""
zorder = 3
+
+cached = maxdict(50)
+
def __str__(self):
return "Text(%g,%g,%s)"%(self._y,self._y,repr(self._text))

@@ -168,7 +171,6 @@
"""

Artist.__init__(self)
-self.cached = maxdict(5)
self._x, self._y = x, y

if color is None: color = rcParams['text.color']



self.subplot.set_xlim(tMin, tMax)
#self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027656   nan
   5.028852   nan
  10.128864   2.4
  15.128876   2.4
  20.12   2.4
  25.128908   2.8
  30.128916   2.6
  35.128924   2.4
  40.228936   2.4

self.subplot.set_xlim(tMin, tMax)
self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027652   nan
   5.028836   nan
  10.028852   3.2
  15.128852   1.6
  20.128872   2.4
  25.128880   2.2
  30.128900   2.6
  35.128904   2.3
  40.228912   2.2
  45.228920   2.1
  50.328928   2.0


In article <4d028bc7.1000...@stsci.edu>,
 Michael Droettboom  
 wrote:

> I think I'm on to something -- it seems that text layout information has 
> a cyclical reference that prevents the Text object from being freed.
> 
> Can you apply the attached patch and let me know if it solves your issue?
> 
> Mike
> 
> On 12/10/2010 02:19 PM, Russell E. Owen wrote:
> > You may have already seen this in the general mailing list, but I've
> > found what I think is a serious memory leak in matplotlib 1.0.0: it
> > leaks memory every time canvas.draw() is called, at least when using
> > TkAgg on unix and Mac.
> >
> > Admittedly many graphs do not need canvas.draw() to be called repeatedly
> > (which I suspect is how it has survived this long). This came up in the
> > contex

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

[Russell E. Owen]

I also wanted to say:
- Thank you for the patch. I appreciate the chance to try a fix.
- I doubt the issue is related to text because my scripts shows a memory 
leak even if the displayed text is never updated (comment out the line 
that modifies the x axis limits to see what I mean; though I confess I 
did not try that with the trunk matplotlib, only with 1.0.0).

-- Russell

In article <4d028bc7.1000...@stsci.edu>,
 Michael Droettboom  
 wrote:

> I think I'm on to something -- it seems that text layout information has 
> a cyclical reference that prevents the Text object from being freed.
> 
> Can you apply the attached patch and let me know if it solves your issue?
...


--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel