matplotlib-users Mailing List for matplotlib (Page 18)

 Hello all,
I really need a help to solve this problem below ..., so let's go ...
I have a Python script( plus Tkinter, Pmw and PmwContribD, matplotlib ) 
with more than 5.000 lines and when I have included a matplot Button 
code ( look excerpt of may code below ) appears this error message after 
I use /on_clicked( self.button_12Click )/ to quit of that figure and 
ask to Tkinter run it again ...
Error: 1
<class '_tkinter.TclError'> Exception in Tk callback
 Function: <function callit at 0x00000000073B2C88> (type: <type 
'function'>)
 Args: ()
Traceback (innermost last):
 File "C:\Python26\lib\site-packages\Pmw\Pmw_1_3\lib\PmwBase.py", line 
1747, in __call__
 return apply(self.func, args)
 File "C:\Python26\lib\lib-tk\Tkinter.py", line 495, in callit
 func(*args)
 File 
"C:\Python26\lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 273, in idle_draw
 self.draw()
 File 
"C:\Python26\lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 259, in draw
 tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
 File "C:\Python26\lib\site-packages\matplotlib\backends\tkagg.py", 
line 19, in blit
 tk.call("PyAggImagePhoto", photoimage, id(aggimage), colormode, 
id(bbox_array))
<class '_tkinter.TclError'>: this isn't a Tk application
Apparently the problem is in /tkagg.py module/ , so how can I solved 
this ???
Excerpt of my code .:
def graphic_1( self ):
 fig = pyplot.figure( figsize = ( 7.5, 4.5 ), dpi = 100 )
 Several code here ....
 widgets.Button( pyplot.axes( [ .91, .1, .08, .06 ] ), 
self.textName[ 19 ],
 color = self.cor[ 403 ][ 1 ], 
hovercolor = self.cor[ 46 ][ 1 ] ).\
 on_clicked( self.button_12Click )
 Several code here ....
 pyplot.show()
def button_12Click( self, e = None ): pyplot.close( "all" )
I have tried to use this /self.Master.update_idletasks()/ with no 
sucess. Please aid me to find a solution.
Thank you very much.
-- 
Ademir Francisco da Silva

Hi,
I downloaded the files from the site, but when i type "import 
matplotlib" in python, it responds with "ImportError: No module named 
matplotlib"
Does anyone mind going through the download steps for me? I probably 
forgot something simple.
Thanks,
Shir

In article <4C2...@no...>,
 Christopher Barker <Chr...@no...> wrote:
> Russell E. Owen wrote:
> > However, at present I don't know if there is a Python 2.6 that is both 
> > compatible with older versions of Mac OS X and is built with 64-bit 
> > support.
> 
> FWIW, I think the official 2.7 builds will be Intel32+Intel64+PPC32
> 
> I don't know if Ronald is going to back=port any of that for 2.6, but I 
> kind of doubt it.
> 
> -Chris
That sounds useful. Can bdist_mpkg handle Intel64?
-- Russell

On Jul 2, 2010, at 2:15 PM, Nicolas Bigaouette wrote:
> Hi all,
>
> I don't really know where to ask, so here it is.
>
> I was able to vectorize the normalization calculation in quantum 
> mechanics: <phi|phi>. Basically it's a volume integral of a scalar 
> field. Using:
> norm = 0.0
> for i in numpy.arange(len(dx)-1):
> for j in numpy.arange(len(dy)-1):
> for k in numpy.arange(len(dz)-1):
> norm += psi[k,j,i]**2 * dx[i] * dy[j] * dz[k]
> if dead slow. I replaced that with:
> norm = (psi**2 * dx*dy[:,numpy.newaxis]*dz 
> [:,numpy.newaxis,numpy.newaxis]).sum()
> which is almost instantanious.
>
> I want to do the same for the calculation of the kinetic energy: 
> <phi|p^2|phi>/2m. There is a laplacian in the volume integral which 
> complicates things:
> K = 0.0
> for i in numpy.arange(len(dx)-1):
> for j in numpy.arange(len(dy)-1):
> for k in numpy.arange(len(dz)-1):
> K += -0.5 * m * phi[k,j,i] * (
> (phi[k,j,i-1] - 2.0*phi[k,j,i] + phi[k,j,i+1]) / 
> dx[i]**2
> + (phi[k,j-1,i] - 2.0*phi[k,j,i] + phi[k,j+1,i]) / 
> dy[j]**2
> + (phi[k-1,j,i] - 2.0*phi[k,j,i] + phi[k+1,j,i]) / 
> dz[k]**2
> )
>
> My question is, how would I vectorize such loops? I don't know how 
> I would manage the "numpy.newaxis" code-foo with neighbours 
> dependency... Any idea?
>
I would first create a 3d array of the integrand, probably using 
scipy.signal.convolve to convolve phi with a kernel such as
[[[0,0,0],[0,1,0],[0,0,0]],
 [[0,1,0],[1,-6,1],[0,1,0]],
 [[0,0,0],[0,1,0],[0,0,0]]]
Then just multiply by whatever factors of dx, dy, dz, and m, and sum 
the 3d integrand. If dx,dy,dz are non-uniform, it is a harder problem...
Hope that helps,
-Jeff
P.S. Careful, the code you wrote will multiply by the mass instead of 
dividing by it.

Hi all,
I don't really know where to ask, so here it is.
I was able to vectorize the normalization calculation in quantum mechanics:
<phi|phi>. Basically it's a volume integral of a scalar field. Using:
> norm = 0.0
> for i in numpy.arange(len(dx)-1):
> for j in numpy.arange(len(dy)-1):
> for k in numpy.arange(len(dz)-1):
> norm += psi[k,j,i]**2 * dx[i] * dy[j] * dz[k]
>
if dead slow. I replaced that with:
> norm = (psi**2 *
> dx*dy[:,numpy.newaxis]*dz[:,numpy.newaxis,numpy.newaxis]).sum()
>
which is almost instantanious.
I want to do the same for the calculation of the kinetic energy:
<phi|p^2|phi>/2m. There is a laplacian in the volume integral which
complicates things:
> K = 0.0
> for i in numpy.arange(len(dx)-1):
> for j in numpy.arange(len(dy)-1):
> for k in numpy.arange(len(dz)-1):
> K += -0.5 * m * phi[k,j,i] * (
> (phi[k,j,i-1] - 2.0*phi[k,j,i] + phi[k,j,i+1]) / dx[i]**2
> + (phi[k,j-1,i] - 2.0*phi[k,j,i] + phi[k,j+1,i]) / dy[j]**2
> + (phi[k-1,j,i] - 2.0*phi[k,j,i] + phi[k+1,j,i]) / dz[k]**2
> )
>
My question is, how would I vectorize such loops? I don't know how I would
manage the "numpy.newaxis" code-foo with neighbours dependency... Any idea?
Thanx!

On Tue, Jun 29, 2010 at 8:25 AM, John Hunter <jd...@gm...> wrote:
> This issue is new and not related to the issue on the cookbook, I'm
> pretty sure. I have the same problem on my box at work, and it was
> introduced when I upgraded to CXX6. I have spent some time on it but
> haven't found the fix yet. I guess it's my bug :-(
>
> I've added it to the tracker:
>
> https://sourceforge.net/tracker/?func=detail&aid=3022815&group_id=80706&atid=560720
>
I have a fix in that appears to work. Comments from the tracker
below. If anyone sees a problem with my fix, let me know::
The CXX/WrapPython.h header has the following code to deal with the swab
issue
// Prevent multiple conflicting definitions of swab from stdlib.h and
unistd.h
#if defined(__sun) || defined(sun)
#if defined(_XPG4)
#undef _XPG4
#endif
#endif
See
http://cxx.svn.sourceforge.net/viewvc/cxx/trunk/CXX/CXX/WrapPython.h?revision=198&content-type=text%2Fplain
The header of stdlib.h on the sage tracker and on my solaris system say
this:
/*
* swab() has historically been in <stdlib.h> as delivered from AT&T
* and continues to be visible in the default compilation environment.
* As of Issue 4 of the X/Open Portability Guides, swab() was declared
* in <unistd.h>. As a result, with respect to X/Open namespace the
* swab() declaration in this header is only visible for the XPG3
* environment.
*/
Ie, the swab declaration is visible for the XPG3 environment but
WrapperPython.h is only unsetting XPG$. The proposed fix is to also unset
XPG3 in this environment. I don't pfully understand all these macros, but
this seems consistent with the comments in stdlib and with what WrapPython
is trying to do, and it works (mpl compiles and passes tests).
So I am committing the following change to mpl's CXX (this should also be
pushed upstream into CXX where we might get better feedback on whether this
change is indeed correct).
// Prevent multiple conflicting definitions of swab from stdlib.h and
unistd.h
#if defined(__sun) || defined(sun)
#if defined(_XPG4)
#undef _XPG4
#endif
#if defined(_XPG3)
#undef _XPG3
#endif
#endif
JDH

On Fri, Jul 2, 2010 at 12:10 PM, Christoph Gohlke <cg...@uc...> wrote:
> The second enhancement, a quick fix for placing images of extreme aspect
> ratio, is to allow 'panchor' and 'fraction' arguments in colorbar().
> http://sourceforge.net/tracker/?func=detail&aid=3016948&group_id=80706&atid=560723
I assigned this patch to me -- my only request is that you also update
the appropriate docstrings so it is clear that these keywords can be
passed in and what they mean.

On Fri, Jul 2, 2010 at 12:10 PM, Christoph Gohlke <cg...@uc...> wrote:
> Hello,
>
> may I suggest two enhancements for the upcoming matplotlib 1.0 release.
>
> The first is related to bug #3011650 and fix r8379.
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revision&revision=8379
>
> Texmanager.py, which is imported during the import of matplotlib, does call
> subprocess.Popen('dvipng'...) on every import. This can significantly add to
> the startup time of scripts. Given that most scripts don't use TeX, can the
> Popen() call be deferred to runtime? On my system (Python 2.6 for Windows,
> mpl 1.0rc1, MiKTeX 2.8) the 'backend_driver.py agg' tests are run about 8%
> (20s) faster with the following patch.
>
> Index: lib/matplotlib/texmanager.py
> ===================================================================
> --- lib/matplotlib/texmanager.py    (revision 8481)
> +++ lib/matplotlib/texmanager.py    (working copy)
> @@ -91,7 +91,7 @@
>   if not os.path.exists(texcache):
>     os.mkdir(texcache)
>
> -  _dvipng_hack_alpha = dvipng_hack_alpha()
> +  _dvipng_hack_alpha = None
>
>   # mappable cache of
>   rgba_arrayd = {}
> @@ -516,6 +516,8 @@
>       if rcParams['text.dvipnghack'] is not None:
>         hack = rcParams['text.dvipnghack']
>       else:
> +        if self._dvipng_hack_alpha is None:
> +          self._dvipng_hack_alpha = dvipng_hack_alpha()
>         hack = self._dvipng_hack_alpha
>
>       if hack:
>
patch 1 is entirely reasonable and harmless so I committed it to trunk
JDH

Hello,
may I suggest two enhancements for the upcoming matplotlib 1.0 release.
The first is related to bug #3011650 and fix r8379.
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revision&revision=8379
Texmanager.py, which is imported during the import of matplotlib, does 
call subprocess.Popen('dvipng'...) on every import. This can 
significantly add to the startup time of scripts. Given that most 
scripts don't use TeX, can the Popen() call be deferred to runtime? On 
my system (Python 2.6 for Windows, mpl 1.0rc1, MiKTeX 2.8) the 
'backend_driver.py agg' tests are run about 8% (20s) faster with the 
following patch.
Index: lib/matplotlib/texmanager.py
===================================================================
--- lib/matplotlib/texmanager.py (revision 8481)
+++ lib/matplotlib/texmanager.py (working copy)
@@ -91,7 +91,7 @@
 if not os.path.exists(texcache):
 os.mkdir(texcache)
- _dvipng_hack_alpha = dvipng_hack_alpha()
+ _dvipng_hack_alpha = None
 # mappable cache of
 rgba_arrayd = {}
@@ -516,6 +516,8 @@
 if rcParams['text.dvipnghack'] is not None:
 hack = rcParams['text.dvipnghack']
 else:
+ if self._dvipng_hack_alpha is None:
+ self._dvipng_hack_alpha = dvipng_hack_alpha()
 hack = self._dvipng_hack_alpha
 if hack:
The second enhancement, a quick fix for placing images of extreme aspect 
ratio, is to allow 'panchor' and 'fraction' arguments in colorbar().
http://sourceforge.net/tracker/?func=detail&aid=3016948&group_id=80706&atid=560723
Thanks,
Christoph

On Jul 2, 2010, at 7:43 AM, John Hunter wrote:
> On Thu, Jul 1, 2010 at 6:17 PM, Russell E. Owen <ro...@uw...> wrote:
> 
>> matplotlib-0.99.3-Apple-py2.6-macosx10.6.dmg
>> for your existing binary, and
>> matplotlib-0.99.3-python-py2.5-macosx10.4.dmg
>> matplotlib-0.99.3-python-py2.6-macosx10.4.dmg
> 
> OK, this is done. Thanks for the builds and naming suggestions. Do
> you think we should replace the eggs on the site with your builds and
> names as well, and importantly, if so, are you able to build them? My
> OSX builds were initially curtailed when my powerbook died. William
> Stein and the sage project gave me remote access to one of their OSX
> build boxes and that was working for a while but then they upgraded to
> 10.6 64bit and that broke the build environment again for a while and
> I don't have an easy way to configure that machine with the various
> builds of python and associated tools that I need. In short, I am not
> the best person to do the OSX builds and am wondering if you would be
> interested in doing the OSX binaries for upcoming releases. We are
> working to get 1.0 out ASAP -- possibly over the weekend or early next
> week depending on our efforts to quash a couple of remaining bugs.
> Would you be able to do the OSX binary builds for 1.0 too?
> 
> Thanks,
> JDH
I would be happy to make the Mac binary builds for matplotlib (at least the ones I know how to make -- for python.org 32-bit).
I personally suggest not building Mac eggs -- at least until easy_install gets really cleaned up. Right now it tends to try to download stuff it has no business downloading and it doesn't check for compatibility. The binary installer is much safer. But if you insist and have easy instructions I will do it.
I suspect I didn't fully answer your question, but I'm not sure what else you want to know so I'll ask you to rephrase any remaining issues.
I'm a bit worried about what will happen when I eventually upgrade my work computer to 10.6 (it's our last remaining 10.5 machine at the moment). But since I have ready access to 10.6 computers I should see if I can do a working build on 10.6 with the binaries I already created on 10.5. (That is likely to work, and may save a lot of trouble -- at least until those versions of libfreetype, etc. get old enough to need upgrading). I don't see myself going to 64-bit for a long time since I have to keep my work machine as compatible as possible.
It is very exciting to hear that matplotlib 1.0 is so close.
Regards,
-- Russell

On Fri, Jul 2, 2010 at 10:34 AM, Russell Owen <ro...@uw...> wrote:
> I would be happy to make the Mac binary builds for matplotlib (at least the ones I know how to make -- for python.org 32-bit).
>
> I personally suggest not building Mac eggs -- at least until easy_install gets really cleaned up. Right now it tends to try to download stuff it has no business downloading and it doesn't check for compatibility. The binary installer is much safer. But if you insist and have easy instructions I will do it.
>
I won't insist -- I have personally found eggs are more trouble than
their worth. Others may ask for them, so we can deal with this on as
as needed basis.
> I suspect I didn't fully answer your question, but I'm not sure what else you want to know so I'll ask you to rephrase any remaining issues.
>
You answered my two questions: should we build eggs (no) and will you
do the builds (yes). Perfect.
> I'm a bit worried about what will happen when I eventually upgrade my work computer to 10.6 (it's our last remaining 10.5 machine at the moment). But since I have ready access to 10.6 computers I should see if I can do a working build on 10.6 with the binaries I already created on 10.5. (That is likely to work, and may save a lot of trouble -- at least until those versions of libfreetype, etc. get old enough to need upgrading). I don't see myself going to 64-bit for a long time since I have to keep my work machine as compatible as possible.
>
If need be, perhaps I can do the 10.6 64 bit binaries on the sage
machine. I just need to figure out the apple python vs python.org
python problem on that platform.
> It is very exciting to hear that matplotlib 1.0 is so close.
Yep -- long time coming :-)
Thanks for your help,
JDH

On Fri, Jul 2, 2010 at 6:20 AM, ninjasmith <hen...@gm...> wrote:
> ok made some prgoress with this so thought I'd update
>
> the following script works on widnows
>
> '''
> Created on Jul 1, 2010
>
> @author: henrylindsaysmith
> '''
> # $Id: $
>
> #test interactive matplotlib plotting
>
> import threading
> import numpy as np
> import sys
> import matplotlib
> matplotlib.use('TkAgg')
> import matplotlib.pylab as pyp
>
>
> class MyThread(threading.Thread):
>
>  def __init__ (self, data, label):
>    self.data = data
>    self.label = label
>    threading.Thread.__init__ ( self )
>
>  def run(self):
>    pyp.plot(self.data)
>    pyp.xlabel('%s' % self.label)
>    pyp.show()
>
> a = np.array([0, 4, 5, 5, 3, 4, 5])
> MyThread(a,'first x label').start()
> print ("please input x label")
> input = sys.stdin.readline()
> MyThread(a,input).start()
>
>
> so basically abandoning interactive mode and running in a thread works. the
> first show shows the plot which I can then interact with. After I input
> from the keyboard the second plot updates the figure.
>
> BUT
>
> on mac I get the following errors
>
> 1) the figure window appears but has no content
> 2) after the keyboard input the xlabel updates and the figure content
> displays and I get the following error
>
> Exception in thread Thread-2:
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py",
> line 525, in __bootstrap_inner
>  self.run()
> File "threadedMatplotLIb.py", line 28, in run
>  pyp.show()
> File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/backends/backend_tkagg.py",
> line 79, in show
>  Tk.mainloop()
> File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk/Tkinter.py",
> line 325, in mainloop
>  _default_root.tk.mainloop(n)
> RuntimeError: Calling Tcl from different appartment
>
> I tried the backend macosx and the results were worse!! I'd rather use mac
> if I can due to scikits.audiolab not installing in windows.
>
> anyone shed any lights on the thread problem?
A lot of GUI toolkits don't permit multi-threaded access to their
event loops. What you really want is to integrate your interaction
into that loop itself, so that the GUI handles things for you. Try
looking at the examples here:
http://matplotlib.sourceforge.net/examples/event_handling/
Specifically:
http://matplotlib.sourceforge.net/examples/event_handling/keypress_demo.html
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Jul 1, 2010 at 6:17 PM, Russell E. Owen <ro...@uw...> wrote:
> matplotlib-0.99.3-Apple-py2.6-macosx10.6.dmg
> for your existing binary, and
> matplotlib-0.99.3-python-py2.5-macosx10.4.dmg
> matplotlib-0.99.3-python-py2.6-macosx10.4.dmg
OK, this is done. Thanks for the builds and naming suggestions. Do
you think we should replace the eggs on the site with your builds and
names as well, and importantly, if so, are you able to build them? My
OSX builds were initially curtailed when my powerbook died. William
Stein and the sage project gave me remote access to one of their OSX
build boxes and that was working for a while but then they upgraded to
10.6 64bit and that broke the build environment again for a while and
I don't have an easy way to configure that machine with the various
builds of python and associated tools that I need. In short, I am not
the best person to do the OSX builds and am wondering if you would be
interested in doing the OSX binaries for upcoming releases. We are
working to get 1.0 out ASAP -- possibly over the weekend or early next
week depending on our efforts to quash a couple of remaining bugs.
Would you be able to do the OSX binary builds for 1.0 too?
Thanks,
JDH

Hello
I am trying to change the font of the ticklabels, this does not work the
'normal' rc-way, so what I did was (example):
import matplotlib.pyplot as pl
ffont={'family' : 'sans-serif', 'sans-serif' : ['Arial'], 'size' : 15,
'weight' : 'bold'}
fig = pl.figure(1)
ax = fig.add_subplot(111)
ax.set_xticklabels(ax.get_xticks(),ffont)
ax.plot([1,2,3])
pl.show()
pl.draw()
when I run this and in the figure pan/zoom the plot the ticklabels does not
change (?), the ticks move, but the labels jump to be in the same place.
What am I doing wrong?
Cheers,
Magnus
-- 
View this message in context: http://old.nabble.com/Formatted-ticklabels-going-haywire--tp29056856p29056856.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

> ipython does this, I believe, when you call it with the -pylab option, but
I have never tried it with a script.
Ben Root
ok made some prgoress with this so thought I'd update
the following script works on widnows
'''
Created on Jul 1, 2010
@author: henrylindsaysmith
'''
# $Id: $
#test interactive matplotlib plotting
import threading
import numpy as np
import sys
import matplotlib
matplotlib.use('TkAgg')
import matplotlib.pylab as pyp
class MyThread(threading.Thread):
 
 def __init__ (self, data, label):
 self.data = data
 self.label = label
 threading.Thread.__init__ ( self )
 
 def run(self):
 pyp.plot(self.data)
 pyp.xlabel('%s' % self.label)
	pyp.show()
a = np.array([0, 4, 5, 5, 3, 4, 5])
MyThread(a,'first x label').start()
print ("please input x label")
input = sys.stdin.readline()
MyThread(a,input).start()
so basically abandoning interactive mode and running in a thread works. the
first show shows the plot which I can then interact with. After I input
from the keyboard the second plot updates the figure.
BUT
on mac I get the following errors
1) the figure window appears but has no content
2) after the keyboard input the xlabel updates and the figure content
displays and I get the following error
Exception in thread Thread-2:
Traceback (most recent call last):
 File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py",
line 525, in __bootstrap_inner
 self.run()
 File "threadedMatplotLIb.py", line 28, in run
 pyp.show()
 File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/backends/backend_tkagg.py",
line 79, in show
 Tk.mainloop()
 File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk/Tkinter.py",
line 325, in mainloop
 _default_root.tk.mainloop(n)
RuntimeError: Calling Tcl from different appartment
I tried the backend macosx and the results were worse!! I'd rather use mac
if I can due to scikits.audiolab not installing in windows.
anyone shed any lights on the thread problem?
 
 
-- 
View this message in context: http://old.nabble.com/matplotlib-in-interactive-mode-from-a-script-tp29023641p29055179.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi all,
On Tue, Jun 29, 2010 at 22:36, John Hunter <jd...@gm...> wrote:
> We have uploaded a tarball and Windows and OSX binaries of
> matplotlib-1.0rc for testing
>
> http://drop.io/xortel1#
I just prepared the Debian package for 1.0rc1 and it went quite
smoothly. I gave it a fast test rebuilding all the images of my book,
and they all renders good (also, the conturf() problem that colored
zones with a bit of overlapping is finally gone).
The package still needs a bit of work, and probably I'll upload next
week to our "experimental" branch (so, at least for now, it won't be
targetting the next Debian stable release).
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Yadin Bocuma Rivas te ha dejado un mensaje...
El mensaje y la persona que lo envió solo te será mostrado a ti y borrarlo en cualquier momento. Puedes responder a través del sistema de intercambio de mensajes. Para descubrir quién te escribió, sigue el siguiente link:
http://eu1.badoo.com/0175921239/in/rsb1Fn-PxvA/?lang_id=7
Más gente que también te está esperando:
Mike (Larnaca, Chipre)
Nena (Malabo, Guinea Ecuatorial)
Manolin (Malabo, Guinea Ecuatorial)
http://eu1.badoo.com/0175921239/in/rsb1Fn-PxvA/?lang_id=7
Si al pulsar el enlace de este mensaje no funciona, copia y pégalo en la barra de tu navegador.
Este email es parte del procedimiento del sistema para el envío de mensajes enviados por Yadin Bocuma Rivas. Si has recibido este mensaje por error, ignora este email. Tras un corto periodo de tiempo, será eliminado del sistema.
¡Divértete!
El equipo de Badoo
Has recibido este email porque un usuario de Badoo te ha dejado un mensaje en Badoo. Este mensaje es automático. Las respuestas a este mensaje no estan controladas y no serán contestadas. Si no quieres recibir más mensajes de Badoo, háznoslo saber:
http://eu1.badoo.com/impersonation.phtml?lang_id=7&mail_code=21&email=matplotlib-users%40lists.sourceforge.net&secret=&invite_id=473679&user_id=175921239 

On Thu, Jul 1, 2010 at 10:42 AM, ninjasmith <hen...@gm...>wrote:
>
>
>
> >
> > Hi,
> >
> > I think what you are after is the interactive mode of matplotlib. You can
> > turn
> > is on by "ion" and redraw the current figure using "draw". In ipythons
> > "pylab"
> > mode this is done implicit. I attached some example lines which guide you
> > to
> > the right direction. I'm not sure why I need two draws in my attached
> > script,
> > but at least it seems to do the job.
> > For more infos you may visit:
> >
> http://matplotlib.sourceforge.net/users/shell.html#controlling-interactive-
> > updating
> >
> > Kind regards,
> > Matthias
> >
> >
> > import numpy as np
> > import sys
> > import matplotlib.pylab as pyp
> >
> > a = np.array([0, 4, 5, 5, 3, 4, 5])
> > pyp.ion()
> > pyp.figure()
> > pyp.plot(a)
> > pyp.draw()
> > pyp.draw()
> >
> > input = sys.stdin.readline()
> > print "input 1 : %s " % (input)
> > pyp.xlabel('my xlabel %s' % input)
> > pyp.draw()
> > pyp.draw()
> >
> > input = sys.stdin.readline()
> > print "input 2 : %s " % (input)
> >
> > pyp.ioff()
> > pyp.show()
> >
> >
> ------------------------------------------------------------------------------
> > 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-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
>
> that almost fixes it. I can now plot and re draw during the execution of
> my
> script. However I cannot interact with the plots. i.e. I can't zoom in on
> an area. when the script gets to the point where pyp.show() is called then
> I'm able to do this. I'm thinking there may be no way round this?
>
> or is there some way to run matplot lib plot in a different thread?
>
>
> ipython does this, I believe, when you call it with the -pylab option, but
I have never tried it with a script.
Ben Root

In article <row...@ne...>,
 "Russell E. Owen" <ro...@uw...> wrote:
> My binaries are presently named:
> matplotlib-0.99.3-py2.5-macosx10.4-2010年06月30日.dmg
> matplotlib-0.99.3-py2.6-macosx10.4-2010年06月30日.dmg
> 
> The easy thing is to simply remove the date; the name then matches the 
> scheme used by numpy and scipy so it will probably be clear to most 
> users.
I guess I'm blind. Here is the naming scheme used by numpy and scipy:
scipy-0.7.2-py2.6-python.org.dmg
numpy-1.4.1-py2.6-python.org.dmg
One option is to simply adopt that (replacing python.org with Apple for 
your binary). But I really don't like omitting the minimum version of 
Mac OS X it works with (not to mention omitting "mac" altogether!), so I 
recommend the following, where I moved the python source before the 
version of python because otherwise the Apple in 
"py2.6-Apple-macosx10.6" might seem to refer to macosx instead of python:
matplotlib-0.99.3-Apple-py2.6-macosx10.6.dmg
for your existing binary, and
matplotlib-0.99.3-python-py2.5-macosx10.4.dmg
matplotlib-0.99.3-python-py2.6-macosx10.4.dmg
for mine.
-- Russell

Russell E. Owen wrote:
> However, at present I don't know if there is a Python 2.6 that is both 
> compatible with older versions of Mac OS X and is built with 64-bit 
> support.
FWIW, I think the official 2.7 builds will be Intel32+Intel64+PPC32
I don't know if Ronald is going to back=port any of that for 2.6, but I 
kind of doubt it.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

In article 
<AAN...@ma...>,
 John Hunter <jd...@gm...> wrote:
> On Thu, Jul 1, 2010 at 12:56 PM, Christopher Barker
> <Chr...@no...> wrote:
> > Russell E. Owen wrote:
> >> I made binaries (on Mac OS X 10.5) using my instructions:
> >> <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
> >> l>
> >>
> >> They are available from here, for now:
> >> <http://www.astro.washington.edu/users/rowen/python/>
> >>
> >> please test them.
> >
> > Thanks Russell, this looks great -- it seems to be working on my OS-X
> > 10.5 PPC box.
> >
> >> If they work then I hope the matplotlib folks will
> >> consider serving them as official "for 3rd-party Python" binaries
> >> (as opposed to the current ones they are serving, which are for Apple's
> >> Python).
> >
> > +1 -- these really should be the official ones (nothing wring with
> > serving up the 10.6 ones too, if they are well labeled)
> 
> I'm happy to upload them, how do you suggest they should all be named?
Great!
I suggest that the current file named:
 matplotlib-0.99.3-py2.6-macosx-10.6-universal.egg
be renamed to something like:
 matplotlib-0.99.3-ApplePython2.6-macosx-10.6.egg
This is based on two things:
- It needs a clear indicator that it requires Apple's python 2.6. Note 
that this is very unusual (I know of no other binaries built like this) 
so the name really needs to emphasize this
- I'm not sure what universal meant (clearly it's not Intel+PPC, which 
is the old meaning of the term). I suggest removing it or replacing it 
with something clearer. If you mean it has both 32-bit and 64-bit 
version then perhaps you could say i32-i64.
My binaries are presently named:
matplotlib-0.99.3-py2.5-macosx10.4-2010年06月30日.dmg
matplotlib-0.99.3-py2.6-macosx10.4-2010年06月30日.dmg
The easy thing is to simply remove the date; the name then matches the 
scheme used by numpy and scipy so it will probably be clear to most 
users. However, I do realize it may be a bit ambiguous since you also 
serve the other version, so you could indicate python.org python in some 
way, e.g.:
...-python_org_python26
You might consider whether you are planning to continue building 
binaries that work with Apple's python. Personally I am never in favor 
of using Apple's python for several reasons:
- Apple Python is part of the operating system, so it's safer to treat 
it as "do not touch".
- It makes packaging an application impossible; the application cannot 
include Python and so will not run on a variety of versions of Mac OS X
- Some packages cannot be upgraded (for instance Twisted) because Apple 
already provides a version.
- Apple never seems to update Python, so you don't get bug fixes.
However, at present I don't know if there is a Python 2.6 that is both 
compatible with older versions of Mac OS X and is built with 64-bit 
support. If there is not, then we'll need for two binary installers 
anyway (though I'd prefer both were for 3rd party versions of Python if 
possible).
-- Russell

On Thu, Jul 1, 2010 at 12:56 PM, Christopher Barker
<Chr...@no...> wrote:
> Russell E. Owen wrote:
>> I made binaries (on Mac OS X 10.5) using my instructions:
>> <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
>> l>
>>
>> They are available from here, for now:
>> <http://www.astro.washington.edu/users/rowen/python/>
>>
>> please test them.
>
> Thanks Russell, this looks great -- it seems to be working on my OS-X
> 10.5 PPC box.
>
>> If they work then I hope the matplotlib folks will
>> consider serving them as official "for 3rd-party Python" binaries
>> (as opposed to the current ones they are serving, which are for Apple's
>> Python).
>
> +1 -- these really should be the official ones (nothing wring with
> serving up the 10.6 ones too, if they are well labeled)
I'm happy to upload them, how do you suggest they should all be named?
JDH

Russell E. Owen wrote:
> I made binaries (on Mac OS X 10.5) using my instructions:
> <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
> l>
> 
> They are available from here, for now:
> <http://www.astro.washington.edu/users/rowen/python/>
> 
> please test them.
Thanks Russell, this looks great -- it seems to be working on my OS-X 
10.5 PPC box.
> If they work then I hope the matplotlib folks will 
> consider serving them as official "for 3rd-party Python" binaries
> (as opposed to the current ones they are serving, which are for Apple's 
> Python).
+1 -- these really should be the official ones (nothing wring with 
serving up the 10.6 ones too, if they are well labeled)
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Thu, Jul 1, 2010 at 1:50 PM, Forest Yang <yzi...@gm...> wrote:
> Hi All,
>
> Is there any way to show the legend but without the box ? it is
> blocking the figures. Although I can set the alpha to make the legend
> transparent, still remove the box and make it transparent would be
> better.
Just as you can set the transparency of the box with
 leg.get_frame().set_alpha(0.5)
you can turn off visibility (as you can with all mpl artists)
 leg.get_frame().set_visible(False)
JDH

Hi All,
 Is there any way to show the legend but without the box ? it is
blocking the figures. Although I can set the alpha to make the legend
transparent, still remove the box and make it transparent would be
better.
Thanks.
Forest.