Re: [Matplotlib-users] Build script(s) not finding correct libraries
On Wed, Jul 9, 2008 at 1:55 PM, Michael Muratet [EMAIL PROTECTED] wrote: I am running on a Mac OS X 10.5 system and even though I set the CFLAGS and LDFLAGS I can't seem to point the build to the correct tree. Note: I am a newbie relative to python on a Mac. Can anyone point out an error I've made or offer troubleshooting suggestions? My OS X build notes are at http://ipython.scipy.org/moin/Py4Science/InstallationOSX and Charlie's (who does the binary mpl builds) are at http://ipython.scipy.org/moin/MatplotlibOSXBuildNotes. From the output you posted, it looks like it the freetype and png headers are not found, which means either you haven't installed x-code package, pkgconfig is not installed or the PKG_CONFIG_PATH is not set. Also, the error complains about the architecture ppc not being included in the libpng build The following may help prevent the compiler from trying to build/link the ppc libraries CFLAGS=-Os -arch i386 LDFLAGS=-Os -arch i386 python setup.py build Charlie includes notes on how to properly build universal png and freetype libs. JDH - 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Can't find current numpy 1.1 dependency
On Jul 8, 2008, at 4:47 PM, Michael Muratet wrote: Greetings I am trying to install matplotlib 0.98.1 on python 2.5.1 on Mac OS X 10.5.3. The install breaks at the required dependancy numpy 1.1 because it thinks it has v 1.0.1. I have, in fact, installed numpy 1.1 and I can't figure out why the matplotlib installer is not seeing it. I am not entirely familiar with installing python tools on Macs. Can anyone point out a build parameter or a common newbie error or any other info so I can resolve the dependancy? This is happening because Leopard comes with an older version of numpy already installed in: /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ python I'm pretty sure that this searched in before the path where your numpy install is. This issue has come up before in many places, here's one: http://mail.python.org/pipermail/pythonmac-sig/2008-January/019596.html I'm not sure what the current best practice is thought to be. You should be able to change your PYTHONPATH environment variable to load the correct directory first. Some suggest to install your own (newer) version of python from python.org for your own use and leave the system python for Apple's use. You can then easily install the numpy/scipy/matplotlib/ipython tools with the Scipy superpack installer: http://macinscience.org/?page_id=6 An easier route might be to use the enthought distribution (if their licensing is OK with you): http://enthought.com/products/epddownload.php It installs its on Python framework in: /Library/Frameworks/Python.framework/Versions/2.5.2001 And numpy,scipy,ipython,matplotlib all just work out of the box. -steve - 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Fwd: Re: Autonomous display of image/plot/figure
James K. Gruetzner wrote: I don't really need any live interaction or a live data display; I just want the thang to stop running (i.e., the process to terminate) when the figure window is closed. Unfortunately, the dynamic_image_gtkagg.py example has the same problem. It's final line is show(). When run as a background process, everything displays well --- but when the window is closed (click on X), the process fails to terminate. So . . . the root cause is that show() does not return when the shown image is closed. If you *need* it to wait for user interaction before continuing, there might be a little bit more work, but I don't think it'd be much. You could probably instead look at some of the Matplotlib UI widgets, like in the buttons.py example. I really don't need user interaction per se, I may have to go that route an establish some sort of close window and exit event. Hmmm: another learning opportunity . . . . :-) The show() function is defined in .../matplotlib/backends/backend_gtk.py and looks to be calling gtk.main(), which, according to .../gtk-2.0/gtk/__init__.py appears to be deprecated in favor of mainloop(). And that's as far as I can go in this: I'm not graphics whiz, and, in fact, having reached somewhat beyond my skill level, can't even figure out how to trace the mainloop call back further. I would think that the gtk mainloop would terminate when the window closes (which termination should propagate back up the stack), but apparently that doesn't happen. I'm not sure I'm following you at the moment. Are you calling show() once and closing the figure doesn't cause it to return? or are you trying to call show() multiple times from a single script and subsequent calls to show() fail to return? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] plotting with marker 'o' but not filled
On Jul 12, 2008, at 1:50 PM, Alan wrote:
Hi List,
I use Fink for Mac OSX, tiger 10.4.11.
So with MPL 0.90.1, this script works fine:
from matplotlib.pylab import *
import matplotlib, numpy
print matplotlib.__version, numpy.__version__
att1 = {'color': 'black', 'markerfacecolor': 'red', 'markersize':
80.0, 'markeredgewidth': 1.0, 'alpha': 1.0, 'marker': 's',
'markeredgecolor': 'blue'}
att2 = {'color': 'black', 'markerfacecolor': None, 'markersize': 8.0,
'markeredgewidth': 1.0, 'alpha': 1.0, 'marker': 'o',
'markeredgecolor': 'blue'}
plot([0],[0], **att1)
plot([0],[0], **att2)
show()
I got just a blue circle line (not filled) over a red square. However,
trying the same script with updated MPL 0.91.3, I got:
[snip]
File /sw/lib/python2.5/site-packages/matplotlib/colors.py, line
279, in to_rgb
raise ValueError('to_rgb: Invalid rgb arg %s\n%s' % (str(arg),
exc))
ValueError: to_rgb: Invalid rgb arg None
cannot convert argument to rgb sequence
Bottom line, version 0.91.3 simply doesn't like 'markerfacecolor':
None anymore.
Could you try setting 'markerfacecolor' to 'none' (Note that this is
the string, not the keyword). I'm on version 0.98.2, but I think this
worked when I was using 0.91.3. I'm not sure why this change was made,
though.
Best,
-Tony
So, is it a bug, or there's another way of getting a simple circle
not filled?
Many thanks in advance,
Alan
--
Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate
Department of Biochemistry, University of Cambridge.
80 Tennis Court Road, Cambridge CB2 1GA, UK.
http://www.bio.cam.ac.uk/~awd28
-
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-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-
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-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Cocoa backend for embedding in Cocoa application
Work is currently going in the wrong direction for me to be able to implement toolbars etc. in a timely manner. Would you be willing to add the rc parameter you discussed so that backend could be defined in a separate package? This would allow me to continue working on (and deploying internally) the Cocoa native backend. As soon as it meets the requirements, I will be happy to resubmit it for inclusion with the matplotlib distribution (including supporting it going forward). Barry On Thu, Jul 3, 2008 at 12:14 PM, Barry Wark [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 8:41 AM, John Hunter [EMAIL PROTECTED] wrote: On Wed, Jul 2, 2008 at 3:41 PM, Barry Wark [EMAIL PROTECTED] wrote: I've written the start of a Cocoa-native backend for matplotlib and would like to submit feedback on the code and on the possibility of including it in the standard matplotlib distribution. The backend Hey Barry, This is great and it is something we are interested in. I haven't had a chance to test it and will be away next week but I can give you some initial thoughts. In general, we want to pare down the number of backends but OS X is an important platform and there are certainly some advantages to doing native rendering. For us to accept a new backend, we need to meet the following criteria: - someone volunteers to support it. This is a multi-year commitment. Presumably this would be you. Yes. - feature complete - images, mathtext, rotated text, etc... It sounds like the only part you are unsure about is mathtext so perhaps Michael can advise. I don't think it will be too hard since Michael has designed this to work with unicode fonts if requested. Using unicode fonts should make it easy. - gui backends: toolbar support Currently not implemented, but not a problem. If you think these are doable, that would be great. If not, I think we can rework the backend infrastructure a bit to support external backend, eg an rc backend setting which points to a file that contains the backend implementation. This latter is worth doing in any case, so if you want to have a look at it This would be _very_ useful, whether or not you decide to include a Cocoa native backend in the distribution. Perhaps also making it possible to delegate to an other package instead of just a file so that backends could be installed as separate eggs would be useuful (e.g. delegate the backend to my.package.backend). implementation is not complete (image rendering and mathtext rendering are currently no implemented, nor are the print_* methods of the FigureCanvas). Image rendering is trivial once I figure out how to get the pixel data out of a matplotlib image (I just haven't investigated the API yet). The print_* methods are also trivial (see point 1 below). I'm not sure how to handle mathtext yet. This backend has two major feature differences from CocoaAgg: 2. The reason I wrote the backend was so that matplotlib could be used seemlesslly from within a Cocoa application. Thus this backend *will not work* without an existing NSRunLoop. It won't work from the terminal or an IPython session. It will work from the in-progress Cocoa frontend for IPython or from any other Cocoa application. Again there are tradeoffs. On the positive side, figure windows are treated like any other application window, selectable from the Window menu etc. and matplotlib becomes a seemless part of the application. Existing backends designed to create their own runloop (e.g. CocoaAgg or TkAgg) cause menubar and run loop problems when used from within an existing application. It would be possible to merge the CocoaAgg and Cocoa backends in this regard to use the existing run loop if present. I know nothing about cocoa apps, but from the way you describe this I think there may be some confusion in how the backends should work. I will speak in terms of gtk since this is the toolkit I know best. The FigureCanvas should be a widget which is embeddable in an app (in a container or window, etc) -- the gtk figure canvas is such a widget and can be used in a gtk app and mpl knows nothing about the application or mainloop -- that part is up to the application developer. The FigureManager is basically a pylab helper class and is not meant to be used by the application developer, though I think some backends may have been designed differently (eg wx). The FigureManager creates a canvas, a toolbar and a window, and puts all the pieces together. show is a pylab construct that raises the active windows and starts the mainloop. No, in fact you've done a very good job of communicating the architecture and it appears that it was my mistake in explaining my work that's led to confusion. backend_cocoa.FigureCanvasView (a FigureCanvas subclass) is an NSView subclass that can be embedded in a Cocoa application to render matplotlib figures. We have a special use case in mind for the
Re: [Matplotlib-users] Cocoa backend for embedding in Cocoa application
On Sat, Jul 12, 2008 at 3:09 PM, Barry Wark [EMAIL PROTECTED] wrote:
Work is currently going in the wrong direction for me to be able to
implement toolbars etc. in a timely manner. Would you be willing to
add the rc parameter you discussed so that backend could be defined in
a separate package? This would allow me to continue working on (and
deploying internally) the Cocoa native backend. As soon as it meets
the requirements, I will be happy to resubmit it for inclusion with
the matplotlib distribution (including supporting it going forward).
I just committed some changes to svn to support the syntax
module://some_backend to load the backend from a module in the
pythonpath. Give it a test drive and see if it works in your use
cases. The matplotlibrc file, the use directive and the -d argument
to pylab will all respect this syntax, eg
matplotlib.use('module://backend_cocoa')
or
python simple_plot.py -dmodule://my_backend
but backend_cocoa doesn't currently work with pylab...
Outside of of pylab, it doesn't matter much because you could already
import directly from your own modules if you are building apps, but at
least the backend validation machinery won't complain if it sees
something starting with 'module://'
Let me know if you had something different in mind
JDH
-
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-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Cocoa backend for embedding in Cocoa application
On Sat, Jul 12, 2008 at 2:35 PM, John Hunter [EMAIL PROTECTED] wrote:
On Sat, Jul 12, 2008 at 3:09 PM, Barry Wark [EMAIL PROTECTED] wrote:
Work is currently going in the wrong direction for me to be able to
implement toolbars etc. in a timely manner. Would you be willing to
add the rc parameter you discussed so that backend could be defined in
a separate package? This would allow me to continue working on (and
deploying internally) the Cocoa native backend. As soon as it meets
the requirements, I will be happy to resubmit it for inclusion with
the matplotlib distribution (including supporting it going forward).
I just committed some changes to svn to support the syntax
module://some_backend to load the backend from a module in the
pythonpath. Give it a test drive and see if it works in your use
cases. The matplotlibrc file, the use directive and the -d argument
to pylab will all respect this syntax, eg
matplotlib.use('module://backend_cocoa')
or
python simple_plot.py -dmodule://my_backend
but backend_cocoa doesn't currently work with pylab...
Outside of of pylab, it doesn't matter much because you could already
import directly from your own modules if you are building apps, but at
least the backend validation machinery won't complain if it sees
something starting with 'module://'
Let me know if you had something different in mind
This looks like exactly what I had in mind. Thanks! A quick test seems
to work and I will ping you if I find issues upon digging deeper.
Thanks!
Barry
-
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-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Fwd: Re: Autonomous display of image/plot/figure
On Fri, Jul 11, 2008 at 11:55 AM, James K. Gruetzner [EMAIL PROTECTED] wrote: And that's as far as I can go in this: I'm not graphics whiz, and, in fact, having reached somewhat beyond my skill level, can't even figure out how to trace the mainloop call back further. To make sure I capture all the events that can close the window, I usually connect to the delete-event and the destroy-event. Eg:: win.connect(delete_event, gtk.mainquit) win.connect(destroy_event, gtk.mainquit) where win is your gtk window. JDH - 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
