[matplotlib-devel] Can we retire numerix?
Hi all, I just ran into an issue with py2exe -- my app failed because various numpy sub-packages weren't included. However, I wasn't using them. But it failed because numerix imports them, and they weren't included because it imports them with __import__ Anyway, I can work around this, but it made me wonder: is it time to retire numerix? We all should be using numpy anyway. note that the docstring is out of date, too: """ 1. The value of numerix in matplotlibrc: either Numeric or numarray 2. If none of the above is done, the default array package is Numeric. Because the matplotlibrc always provides *some* value for numerix (it has it's own system of default values), this default is most likely never used. To summarize: the commandline is examined first, the rc file second, and the default array package is Numeric. """ -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 [email protected] -- 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] wx.AlphaPixelData() is failing on windows server 2003
Michael Droettboom wrote: > Is this bug related to matplotlib? (i.e. does it happen only when > matplotlib is imported?) It looks like you've done a pure-wx test, so it is a wx issue. > If not, you may have more luck on the wxpython > mailing list. yup, that's the place for it -- I suspect that windows server 2003 is old enough that it may not have the newer alpha-supporting drawing stuff -- that may be a dll that you could add, though. You'll get a better answer on the wxpython-users list. -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 [email protected] -- 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
Re: [matplotlib-devel] Contouring unstructured triangular grids
Ian Thomas wrote: > On 15 April, Ian Thomas wrote: >> I've attached the patch for the new triangular grid functionality. > > As nobody has commented on the patch I submitted to add triangular > grid functions, I can only assume that nobody has looked at it. I have NO time to look at it, but I think it's great think to add. -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 [email protected] -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?
> As an additional note, if you are having difficulty compiling for > MacOS X, why not just ask for help with that? yup -- there are some issues with which Tk is used by tkInter, but wx should be easy -- how have you tried to install? -Chris -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mpl1 + chaco
Peter Wang wrote: > On Jul 19, 2007, at 5:31 PM, Christopher Barker wrote: >> OK. I have to ask -- why aren't we all just using Chaco? > Most of ETS is being developed, tested, and run on Windows, Mac, and > Linux every day. Ah, great to know -- that was decidedly not the case the last time I took a good look at Chaco. > Long ago we factored out Chaco's > underlying drawing layer into a package called Kiva. That was there from the beginning if I recall, which is great. > Kiva's PS, PDF, SVG, and GL backends > could all use a little love, but they were functioning at one point > in time. Sorry to play devil's advocate here, but the question remains -- MPL developers (John, primarily, I suppose): Why not dump MPL1, and work on a nice pylab-like front end to Chaco, while giving the "love" to the Kiva PS, PDF, SVG back-ends (and add GTK -- if it's not there)? Most users, like me, just want something that does the job for us. I know I'm going to take a look at Chaco again. Add the skills of the MPL team to Chaco, and it could really shine! -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 [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 + chaco
Darren Dale wrote: > I need to create plots for qt4 projects at my lab, and I > have grown really accustomed to the quality of mpl's eps So we need QT and EPS. > output when usetex is enabled. Ah! and some good math implementation -- What does Chaco do for that? I know I took part in a discussion about it on a Chaco list a few years back -- at the time I argued that you're never going to do as well at TeX. These aren't deal-breakers so far -- it sounds like Kiva has at least rudimentary QT support -- and I imagine a MPL usetex-like approach could be applied to Chaco too (though I'd rather see the DVI parsed and rendered by Kiva...) -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 [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 + chaco
Peter Wang wrote: >> Ah! and some good math implementation -- What does Chaco do for >> that? > We've also had this discussion internally a bit. It usually > concludes with us wishing that someone would just port jsmath to > Python, or implement Knuth's TeX layout rules in Python. :) It looks like jsmath uses the TeX layout rules, so those are the same thing. If you can do it in JS, you sure should be able to do it in Python! > Currently Chaco2 doesn't have a math markup mechanism, but it was > fairly trivial for me to port mpl's mathtext to Chaco1. I didn't > bother moving that to Chaco2 because I really wanted to figure out a > way to do "real" TeX layout that would still fit into the interactive > model. That would be nice. I agree, the Math-as-bitmap approach really isn't the way to go, but it does work OK in the meantime! -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 [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] wx back-end bugs/issues
Hi all,
I usually use MPL embedded in wx, so I haven't noticed these before but
with the pylab window:
1) A couple icons seem to be missing. See screenshot enclosed.
2) The save button doesn't work, as I get a "cannot return std::string
from a Unicode object" error. This is with a unicode build of wxPython.
I've had this same problem with my code. This issue is that the savefig
code can't handle unicode (regular old fopen, I think). Here are two
solutions:
1) use:
filename.encode('ASCII', 'replace')
on the string before using it, so that you'll get an odd name with
non-ascii charactors but at least it will work.
2) Use:
F.savefig(open(path, "w"), dpi=dpi)
Python's open allows unicode filenames, and I was told that recent
versions of MPL can take a file, rather than just aname, without an
unacceptable performance hit, though in my code, without the latest MPL,
I get an invalid PNG.
thanks,
-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
[EMAIL PROTECTED]
<>-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] PNG transparency
Michael Droettboom wrote: > I don't understand why anyone would want the one on the left, > but if you can provide a use case for it, it should be implementable. I know I can't. I think john may be right that it's just not that hard to do by hand. -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 [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Using the Agg renderer by itself
On 11/23/11 10:13 AM, Friedrich Romstedt wrote: > 2011/11/23 Chris.Barker: >> I've got some drawing to do (for a web app). I don't need all the MPL >> machinery, but I do need a high quality, fast, renderer. > > http://www.effbot.org/zone/aggdraw-index.htm I've been wondering about that -- it doesn't look terribly maintained -- no updates for a long time, and I'm concerned about performance 99 if you are drawing something simple, but with lot's of points, all that conversion from numpy types to python type to C types is going to be an issue. > http://www.effbot.org/imagingbook/imagedraw.htm this is definitely slow for what I'm doing. Thanks, -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 [email protected] -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] jsxgraph or flot backend (or interactive viewer for svg backend?)
On 12/5/11 9:49 PM, Jason Grout wrote: > Has anyone ever worked on a backend that generates javascript code for > one of the javascript plotters out there (like jsxgraph or flot)? > Alternatively, I suppose we could generate an svg or html5 plot and then > accompany it with the javascript code to trace the function, etc. Someone has worked on a html5 back-end, It was jsut discussed a bit on the thread "Using the Agg renderer by itself" Here's a cut and paste: On 11/27/11 12:33 PM, Ludwig Schwardt wrote: > > Ben is referring to mplh5canvas, available at > http://code.google.com/p/mplh5canvas/. The main advantage of this > approach is interactive zooming of plots within the browser. If this is > not important to you, it will probably be faster to generate static PNGs > or SVGs. > > The HTML5 backend should be easy to try out, as it is a pure Python > package with no onerous dependencies. > -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 [email protected] -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wxMPL patch
Hi folks, It seems Ken McIvor has more or less disappeared. However, his wxMPL code is still useful and there are a few of us that are interested in maintaining it. What would be the procedure for getting it into a more "official" location -- like maybe a matplotlib toolkit? Or even mixed right in with the code (i.e. import matplotlib.wxmpl)? It's one file -- there really isn't that much to it, but it's nice to have. http://agni.phys.iit.edu/~kmcivor/wxmpl/ (the license looks BSD-ish to me) Thanks, -Chris On Mon, Apr 30, 2012 at 11:16 AM, Chris Barker wrote: > Hi Folks, > > I can't seem to find Ken McIvor -- Ken are you here? > > Anyway, here's a tiny patch of wxMPL to make it work with wxPython 2.9 > -- the only change is here, around line 1126: > > ## the following changed according to Robin Dunn's advice for 2.9 > ## -- but it probably wasn't working right before! > #topwin.Connect(wx.ID_ANY, self.GetId(), wx.wxEVT_ACTIVATE, > self.OnActivate) > topwin.Connect(self.GetId(), wx.ID_ANY, wx.wxEVT_ACTIVATE, > self.OnActivate) > > This change works fine with wxPython2.8, also. > > Attached is the whole file. > > -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 > > [email protected] -- 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 [email protected] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wxMPL patch
On Tue, May 1, 2012 at 9:23 AM, Thomas Kluyver wrote: > On 1 May 2012 17:04, Chris Barker wrote: >> (the license looks BSD-ish to me) > > At a glance, I think it's the X11 license, aka MIT license. Would there be a problem bringing it in to MPL in that case? -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 [email protected] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wxMPL patch
On Tue, May 1, 2012 at 9:31 AM, Benjamin Root > AFAIK, no, it shouldn't be a problem. The question is where. I suspect it > would fit best as a mpl_toolkit. yes -- I figured that was most likely. > P.S. - Of course, you do realize that you are essentially making yourself > the de facto maintainer of it, right? Well, me or Matt or Carlo -- we'll fight over that among ourselves. -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 [email protected] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wxMPL patch
On Thu, Aug 30, 2012 at 9:22 PM, Carlo Segre wrote: > Hi Chris: >> On Tue, May 1, 2012 at 9:31 AM, Benjamin Root >> >>> AFAIK, no, it shouldn't be a problem. The question is where. I suspect >>> it >>> would fit best as a mpl_toolkit. >> >> >> yes -- I figured that was most likely. > Just a followup. Has wxmpl been pulled into the toolkit source yet? > > Carlo I haven't done anything, nor have I heard that anyone else has. Care to take it on? -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 [email protected] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wxMPL patch
On Tue, Sep 4, 2012 at 8:33 PM, Matt Newville wrote: > Sorry for the delay I also haven't done anything about this... yet? I > might be more gung-ho to fold this into my wxmplot, which is fairly similar, > but not exactly 1-to-1, and has some name overlaps with wxmpl. To be > clear, I'm willing to refactor wxmplot to better accommodate most of the > wxmpl interface, Sounds like a great idea. > What interfaces are you actually using from wxmpl? I guess put another way: > what do we want for a wx interface to matplotlib that's higher level than > the standard backend.The PlotPanel and PlotFrames look close enough to > merge. Those are what I use -- actually, only the PlotPanel -- I generally want to customize the Frame. > The wxmpl StripCharter seems a little different from what I do with > wxmplot, but perhaps that and the Channel class are easy enough to emulate. Those are kind of higher-level stuff that's more suited to wxmplot, I think -- as I don't use them, I don't care if you break the API -- but that's just me. > For how / where to host it, I don't much care. Github and pypi seem easy > enough. I think it would be great to put it in the mpl repo as an mpl_toolkit -- which means github, yes? Thanks for taking this on! -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 [email protected] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue
On Wed, Oct 3, 2012 at 2:08 PM, Christoph Gohlke wrote: A bunch of great stuff: +1 all around Another use-case is py2exe, py2app, and friends -- at the moment, you pretty much have to include the whole dang MPL package to get things to work. Cleaning up some of these dependencies could improve that. -Chris > On 10/3/2012 9:20 AM, Michael Droettboom wrote: >> I invite comments for a new MEP about improving the situation with >> respect to our bundling of third-party Python dependencies. >> >> In particular, I'd love feedback from the various stakeholders -- those >> producing binary installers and packages for the various platforms. >> >> https://github.com/matplotlib/matplotlib/wiki/MEP11 >> >> Mike > > Hi, > > could dateutil, pytz, and pyparsing be made optional dependencies? I > just tried, all of my own scripts do work without them being installed > (one line needed to be removed in axes.py > https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes.py#L19). > Only about 10 of matplotlib's examples fail (after some additional > changes). > > Frankly, I would remove/unbundle all 3rd party Python packages from > matplotlib and declare them as dependencies for pip and easy_install, > and of course in the documentation. > > I think that matplotlib, the library, should not attempt to work around > Python's distribution/packaging limitations. Please do not use > post-install or run-time scripts to detect and install missing > dependencies. > > Concerning end user experience, the scipy-stack project seems like a > better place to address this. > > Optionally, for Windows users that won't touch pip or easy_install (like > me), matplotlib could provide separate downloads of installers for > dateutil, pytz, pyparsing, and six. They are trivial to create. > > It is also easy to create EGGs or MSIs for matplotlib, which are > occasionally requested. > > Also consider a separate package for the matplotlib tests, which would > include 35 MB of baseline images that are of little use to end users. > > Christoph > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- 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 [email protected] -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue
On Wed, Oct 3, 2012 at 10:36 PM, Erik Bray wrote: > So as you wrote in the MEP, Numpy will simply have to be installed > separately, I think, if the C++ modules require the Numpy headers. Which is totally fine -- MPL requires a bunch of non-python dependencies (OK, a few) anyway, so no matter how you slice it, you need to get some stuf set up before you can build MPL. Ideally, no on e needs to build MPL that would have trouble with this requirement -- that's what binaries (and nifty linux .deb / .rpm ) are for. I personally prefer that dependencies are well documented, but not necessarily auto-installed -- the auto stuff is just not reliable enough. -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 [email protected] -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] PyGTK vs PyGObject
On Fri, Oct 5, 2012 at 9:51 AM, Michael Droettboom wrote: > We do use pycairo. It certainly would get around the issue, but duplicate a > lot of effort that pycairo already handles for us. A bit OT -- but have you added, and or does pyCairo have, numpy-array awareness? i.e. is there an efficient way to pass a lo tof coordinate parie,s etc to pyCairo? Just wondering, 'cause I'm trying to decide on a rendering lib to use for another project. -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 [email protected] -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] PyGTK vs PyGObject
On Oct 5, 2012, at 12:25 PM, Michael Droettboom wrote: > On 10/05/2012 02:53 PM, Chris Barker wrote: >> The upcoming pycairo version > supports using image buffers (which can be Numpy arrays), but that's not > helpful for drawing lines etc. > Thx-I did see some add-on code for using numpy arrays with pycairo once. Maybe I'll look for that, and/or work on add-on code myself. -Chris -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Interpolation in a triangular mesh (tri.Triangulation)
On Wed, Nov 14, 2012 at 1:50 AM, Ian Thomas wrote: > I think the code used to determine which triangle contains a certain point > should be factored out into its own TriFinder class, +1 -- this is a generally useful feature. In fact, it would be nice if a lot of this were in a pacakge that deals with triangular meshes, apart from MPL altogether (a scikit maybe?) > I have a C++ TriFinder class > that I could modify to work within matplotlib, and it is O(log N) so should > be faster than your version for typical use cases. What algorithm does this use? Is the code open source and/or availabel for other projects? I'm working on a package for working with unstructured grids in general, and also have a use for "what triangle is this point in" code for other purposes -- and I havne't found a fast, robust code for this yet. >> particularly as only a few days ago I committed to writing a triangular grid >> interpolator for quad grids what is a triangular interpolator for quad grids? sounds useful, too. -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 [email protected] -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib user guide
On Fri, Oct 4, 2013 at 1:40 PM, Russell E. Owen wrote: >> Introducing Plotting with Matplotlib >> >> Pyplot tutorial >> Controlling line properties >> Working with multiple figures and axes >> Working with text >> Interactive navigation >> Navigation Keyboard Shortcuts >> Working with text >> Text introduction >> Basic text commands >> Text properties and layout >> Writing mathematical expressions >> Text rendering With LaTeX >> Annotating text > ... > - Would you be willing to include a section on using the class API? (I'm > assuming the above is all based on using pyplot?). +inf Even better, dump pyplot and use primarily the OO API. Asside from folks that dont want to change anything when moving from Matlab, we should all be using teh primarily OO API. is it really that hard to type: ax.plot() rather than plot() ? And when you move away from interactive use (and we all should fi your typing more than 4-5 lines of code) teh OO interface is a much better way to go. (I know, iPython notebooks allow you do do a LOT with esentially an interactive interpreter, but still.) Anyway, I've always thought it was a real shame that most of the tutorials on MPL out there get people started on what I'm convinced is the wrong foot. - just my opinionated $0.02 worth... -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 [email protected] -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Directories for C/C++ extensions
Ian, > I am working on a PR to replace the use of matplotlib.delaunay with the > Qhull library. nice! -- ( though I sure wish Qhull did constrained delaunay...) > Installation will be similar to the existing packages LibAgg > and CXX in that if the system already has a sufficiently recent version of > Qhull installed then matplotlib will use that, otherwise it will build the > required library from the source code shipped with matplotlib. Why bother, why not just always build the internal version? (for that matter, same with agg) Wouldn't it be a lot easier and more robust to be sure that everyone is running the exact same code? What are the odds that folks are using qhull for something else, and even more to the point, what are the odds that the duplication of this lib would matter one wit? This isn't like LAPACK, where folks have a compellling reason to run a particular version. -- just my thoughts on how to keep things simpler. -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 [email protected] -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib user guide
On Fri, Oct 18, 2013 at 11:56 AM, Benjamin Root wrote: > FWIW, I think my "Anatomy of Matplotlib" tutorial I gave at SciPy 2013 > struck a balance between pyplot and the OO interface. Grat, I'll take a look. Does the ipynb linked from the tutorial site have most of the presentation material? As it turns out, I need to give an intro to matplotlib class this week -- I've been looking for some good materials to use -- why re-invent the wheel? I'll be sure to give you any feedback I have. Hmmm.. this may be a time to put together a project of materials designed to teach matplotlib in a classroom setting -- a little different than a tutorial designed to be done on one's own. There is a bunch of stuff scattered among scipy tutorials, bootcamp lectures, etc, but having a central place to develop materials would be nice. -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 [email protected] -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Directories for C/C++ extensions
> To expand slightly, with the current situation the onus is on us to ensure > that mpl builds OK and passes all of our tests with and without each of the > external libraries. If you only have internal libs, then there is less to do -- it only need to work with the version you bundle. And making sure it works with any-old-version-that-may-not-exist-yet is a pretty formidable challenge! > Linux distro packagers will choose to set up qhull as a > required dependency for their mpl package, and once they have done this can > simply delete our directory containing the qhull source code in their mpl > source package, If they are going to insist on doing this, then, yes you should certainly do it this way. > we can all be confident that it will work correctly. only if you've tested against the version (maybe patched) of the external lib they are using... > If we always used our internal version then distro packagers would have to > change our setup scripts to build using the external libraries. This would > be more time-consuming and error prone leading to less timely mpl distro > releases. We need to make their job as easy as possible. it's easiest for them if they don't try to pull out an included dependency -- but maybe you're right that that REALLY want to do that! >The needs of the distro packagers, which are primarily security and > stability, are sometimes at odds with the needs of scientific software, > where the premium is on reproducibility. The output of matplotlib depends > on the versions of some of its dependencies, not the version of matplotlib > alone, and that's problematic for some... exactly -- if we know exactly which version of a lib is in use, we know that it works the way we expect in the use cases we expect to use it in. But I'm not maintaining this code, so have at it in the way that makes sense to you. NOTE: it would be a different story if this were a netwroking protocol lib, or something where security patches would be critical. Maybe I'm naive, but this doesn't seem likely in this case. -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 [email protected] -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OS-X binaries?
On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen wrote: > The last ones I got from you worked very well: just a few test failures > and the current one seems to be doing about the same. worked well for me too (something odd with wx back end re-rendering, but I doubt that's a Mac build issue...) I tok a quick look at your waf scripts and I couldn't tell how you are handling the external compiled dependencies (png, zlib, freetype) -- are these statically linked in? It'll be good to see these posted on the MPL download site. -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 [email protected] -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)
On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom wrote: > Here are the notes with action items from the meeting: thanks for posting that. I see: pylab - should it stay or should it go? Comment from the peanut gallery: Go. But beyond that, matplotlib.pyplot is a big mess of both the matlab-style state-machine current figure, current axis stuff, and what you need to do (at least reasonably on the command line) OO interface. This makes it really hard to teach to newbies -- I just did this last night, and made a point to use tutorials that emphasize the OO interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm sure others that helped put the materials together that I stole from...). However, there were still a number of examples in there that just called "plot()" or whatever, and even if there were not, the namespace is really cluttered with stuff! Anyone like the idea of an matplotlib.ooplot namespace that would have just what you need to use the oo style? -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 [email protected] -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)
On Thu, Oct 24, 2013 at 12:03 PM, Daniele Nicolodi wrote: > PS: Chris, would you mind sharing the material you put together and > links to material from which you stole from? Thanks! I honestly don't think my stuff is any better than the originals: I like these: Ben Root's Scipy Tutorial -- really nice, Ben! https://github.com/WeatherGod/AnatomyOfMatplotlib >From the software carpentry site: https://github.com/swcarpentry/bc/tree/gh-pages/lessons/thw-matplotlib (apparently originally from Katy and Antony) -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 [email protected] -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)
On Fri, Oct 25, 2013 at 6:34 AM, Benjamin Root wrote: > It doesn't feel weird. It feels generalized. > or both ;-) It is the same way to add any number of plots, regardless if it is just > one, or twenty. If you don't want to do it that way, you can just simply do: > > fig = plt.figure() > ax = fig.gca() # "get current axes" automatically creates an axes if one > rally ugly -- the whole point here is to get away from the concept of a "current" anything -- I'm actually surprised that that's a figure method at all... It does: http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_subplot > This is *the* function that does axes creation for a figure, whether it is > one, or many. > > subplots() is a recent addition. > And a nice one -- I've been wanting that for years! (and I first discovered it in your tutorial, Ben!) The trick has always been that plot() actually creates (If not re-using) three objects you might want to work with: figure, axes, and line objects, so an oo interface that lets you do that with one call is tricky -- I think this is a nice compromise. We are in the process of updating our documentation. But add_subplot() is > not going away because it works just fine, and it is very familiar to users > of Matlab and Octave. > I've lost track a bit if there is support for a new OO-only API (namespace), in which case, maybe some of this could be cleaned up as well. I'd kind of like to see a fig.subplots() that has the same API as plt.subplots(), for symmetry's sake, and because add_subplot() has a kind of crufty API. Except it wouldn't return the figure instance (though it could). -Chris > > >> In principle I think the current API violates the "There should be one-- >> and preferably only one --obvious way to do it" rule here, and elsewhere >> :-) >> >> > I feel the way forward should be to create a cleaner API and map the >> current one through a compatibility layer to that. >> >> > This has already been done. We have the GridSpec API that everything else > maps to, for compatibility. But most people still like add_subplot() and > subplots() for some odd reason... I think the primary issue is one of > documentation, and we are currently in the process of upgrading that. We > always welcome contributions to that effort! > > Cheers! > Ben Root > > > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- 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 [email protected] -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)
On Fri, Oct 25, 2013 at 3:32 PM, Todd wrote: > I think one thing that contributes a lot to the API issues is the > inconsistency between pyplot API and the OO API. There isn't any reason > the APIs need to be so different. > indeed. I hadn't even realized how different they were. > So the idea would be to have essentially all of the pyplot functions just > be wrappers for methods from other classes, using the same name and same > call signature (minus "self"). All of the actual functionality would be > implemented in the methods, the pyplot functions should not have any logic > or tests. > + inf However, doing this with full backward compatibility could be a real challenge... This will make it easy to transition between the two, learning to use the > OO interface would just involve learning what object the pyplot function is > targeting (this should be in the pyplot function docstring). > That would help, though a namespace without any non-OO stuff would be still be good, and, of course, docs and tutorials. -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 [email protected] -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Replacing matplotlib.delaunay natural neighbor interpolation
On Tue, Jan 28, 2014 at 12:59 AM, Ian Thomas wrote: > I expect we will add more triangular grid interpolators to matplotlib in > due course and I am happy to receive suggestions on this. However, this > will not include natural neighbour. Natural neighbour interpolation is > specific to delaunay triangulation, and as we also support user-specified > triangulations I am only interested in interpolation that covers all > triangulations. > I appreciate the separation of the triangulation from the interpolation, but I also like natural neighbor. But is it really only usable with delauney triangulations I can see that it may not have very nice properties when applied with a very non-delaunay triangulation, but I can't see why it it wouldn't be computable. Or am I missing something? -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 [email protected] -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unused variables
On Thu, Mar 6, 2014 at 1:23 PM, Skip Montanaro wrote: > Despite our wish that it wasn't so, it is likely that there is far > more undocumented than documented code out in the wild, or behind > firewalls where we can't see it. Well, then you're hosed anyway -- relying on the name of an unused variable using a call for your docs is, shall we say not very robust. In my experience, there's no > real need to be intentionally obscure by not giving a variable a > meaningful, whether or not you intend/expect to use it. Besides, open > source code can serve as a living example of good coding practices. > Might as well do our best in that regard. > then use "unused_meaningful_name" it looks like pylint, anyway, will accept that. Or is the goal here to come to a consensus for MPL style? If so, I'm +1 on "_", and -0 on unused_meaningful_name -Chris > > Just sayin'... > > Skip > > > -- > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and > the > freedom to use Git, Perforce or both. Make the move to Perforce. > > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- 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 [email protected] -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general
On Mon, Jun 2, 2014 at 11:48 AM, Matthew Brett wrote: > I want to rename the matplotlib wheel OSX wheel files on pypi so they > will also install into homebrew, macports and system python. > +1 > > matplotlib-1.3.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl > what is this going to do on OS-X 10.7 and 10.8 systems running homebrew or macports pythons? It seems this list could get pretty long! -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 [email protected] -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general
On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett wrote: > > what is this going to do on OS-X 10.7 and 10.8 systems running homebrew > or > > macports pythons? It seems this list could get pretty long! > Yes, it could, but this list: > > so we would have to add all those if we wanted to support them... > https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion > > very interesting stats! I wonder how representative those are? Makes we think we can drop 32 bit support, too. Maybe the newest 2.7 py.org binaries could be 64 bit only. It would simplify things a bit. > suggests that 10.9 is the majority, and that 10.8 and 10.7 are only > about 14 percent combined. I guess a better case could be made for > 10.6 (still 16 percent), but I wonder how many 10.6 hold-outs are > updating their homebrew / macports numpies regularly. > not many -- it can be a really a pain to do so -- macports and homebrew really expect you to have a recent compiler, which I think is difficult or impossible to install on 10.6... -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 [email protected] -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general
Hi Russell, > > >Makes we > > think we can drop 32 bit support, too. Maybe the newest 2.7 py.org > binaries > > could be 64 bit only. It would simplify things a bit. > > I hope you will not drop 32-bit support yet.. I still use it to > distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk > 8.5 have a nasty crashing bug that I have not found a workaround for, > and old enough versions that don't have the bug need to run in 32-bit > mode on Mavericks. Darn. I guess it's not uncommon that even folks with a 64 bit machine may need a lib or something that is 32 bit only -- so maybe good to keep it. But it really is a pain -- and this example is supposed to be part of Python's stdlib! On Tue, Jun 3, 2014 at 1:44 PM, Matthew Brett wrote: Do you need 32 bit support for the wheels or just for the MacPython > binaries? It's getting harder to build 32 / 64 bit universal > binaries these days... Exactly -- will an Intel Universal Python pick up a 64 bit-only wheel? That would be OK for most folks, I guess, though I'd really prefer it if things were more clear -- you have a 32/64 bit python, you install wheels and it works fine for you, so distribute via py2app, then it crashed when run in 32 bit mode... Oh well. -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 [email protected] -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general
On Wed, Jun 4, 2014 at 2:12 PM, Russell E. Owen wrote: > What I need is a python, numpy, and matplotlib that support 32-bit and > (preferably) 64-bit for MacOS X 10.6 and later. I have been using > python.org python and the standard binary installers until now. > well we (that is, Matthew) have scripts that build those, so no reason not to keep doing it. > Until Mavericks I was using 64-bit mode. Unfortunately 32-bit is > required for older versions of Tcl/Tk to run under Mavericks kind of ironic that the latest OS doesn't end up supporting 64 bit! > I realize I'm in an unusual situation, maybe -- but tkInter is part of the standard library, so we probably do want to support it! If nothing else, various folks that teach Python use the turtle module early on -- and one of the use cases for easy-to-fine-and-install binaries is newbies... > and I'm not the one building the > binaries and trying to deal with the ATLAS headaches. If worst comes to > worst we can stay at the current version of numpy and matplotlib (at > least for now). Long term we should probably switch away from Tcl/TK, > though that would be a huge undertaking, or hire somebody to fix the > Tcl/Tk bug. Is Tcl/Tk that unused that this isn't getting addressed? kind of Sad, though I was never a big fan -- at least once I discovered Python... -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 [email protected] -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Please Build the doc as HtmlHelp
On Wed, Jul 30, 2014 at 11:20 AM, Gary Setter wrote: > Thank you for all the responds concerning Html Help. If someone would > build using *class *sphinx.builders.htmlhelp.HTMLHelpBuilder and upload > the outputs were I can get them, > It would probably be easier to clone the repo, install sphinx, and do that step yourself... But thanks for offering, this would be nice for some folks. -Chris > I have a HTML Help workshop installed on my desktop. I would gladly > setup the project and build the dot chm file. I'll send the results were > ever you wish. > Best regards, > Gary Setter > > > > -- > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- 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 [email protected] -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Anaconda Support] OSX: why not make "python" invoke the framework?
On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing wrote: > but as far as I can see, on OSX, there is no *advantage* to non-framework > python. Is this correct? > > Suggestion for anaconda: > make bin/python a link to ../python.app/Contents/MacOS/python > NOTE: the python.org python build has been doing this (or something like it) for years and many versions -- I had gotten pretty used to it and was pretty annoyed when I discovered Anaconda keeps anon-framework binary as the default. It was annoying enough that I had to explicitly call pythonw (or alter the #! line) for my wxPython scripts, but with ipython it's even worse -- how would I start up ipython with a framework build? NOTE: if the Anaconda folks really think there is a real downside to using the framework executable for the default python, maybe the ipython start up script could use pythonw ? Eric - have you tried recent MPL with the python.org builds to confirm the issue? I'm a bit surprised that it would even semi-work -- when I try wxPython with the regular executable, I get an error message and it wont run at all. > (On 2.7, I think this would also make wxpython applications work, but I > haven't checked recently.) > yup -- it should -- does for me anyway. If there is some reason why this default to a framework is not a good idea, > and/or cannot be implemented very soon in Anaconda, then I think we need to > immediately remove macosx as a default in matplotlib. A situation where a > new Anaconda user fires up ipython and tries to plot, and it fails, is > intolerable. for what it's worth, I get odd os-x errors trying to se default MPL with Anaconda as well -- haven't tried pythonw for that yet. (kludged it by using the Agg back end only) -- 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 [email protected] -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Anaconda Support] OSX: why not make "python" invoke the framework?
On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer wrote: > The only potential issue I can think of for making python=pythonw is > that pythonw is a shell script: > I agree -- that could create issues (though will mostly work, I suppose) But somehow the python.org build has managed to make a pythonw that IS a proper executable: ORRW-M-1275474:bin chris.barker$ pwd /Library/Frameworks/Python.framework/Versions/2.7/bin ORRW-M-1275474:bin chris.barker$ ls -l pythonw lrwxr-xr-x 1 root wheel 8 Jul 16 2013 pythonw -> pythonw2 ORRW-M-1275474:bin chris.barker$ ls -l pythonw2 lrwxr-xr-x 1 root wheel 10 Jul 16 2013 pythonw2 -> pythonw2.7 ORRW-M-1275474:bin chris.barker$ ls -l pythonw2.7 -rwxr-xr-x 1 chris.barker admin 9180 May 13 2013 pythonw2.7 ORRW-M-1275474:bin chris.barker$ file pythonw2.7 pythonw2.7: Mach-O executable i386 (yes, ti works for 64 bit too -- this just happens to be what I have) It would be nice if Anaconda would do it the same way. -Chris > #!/bin/bash > export PYTHONEXECUTABLE=/Users/aaronmeurer/anaconda/bin/python > /Users/aaronmeurer/anaconda/python.app/Contents/MacOS/python $@ > > This is needed because otherwise Python thinks its sys.prefix is > ../../ from the executable, i.e., > /Users/aaronmeurer/anaconda/python.app/Contents/MacOS > > $~/anaconda/python.app/Contents/MacOS/python > Python 3.4.1 |Continuum Analytics, Inc.| (default, Aug 11 2014, 14:17:03) > [GCC 4.2.1 (Apple Inc. build 5577)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> sys.prefix > '/Users/aaronmeurer/anaconda/python.app/Contents' > > I'm not sure what kinds of issues this would cause having python be a > shell script rather than a Mach-O 64-bit x86_64 executable (or a > symlink to a Mach-O 64-bit x86_64 executable). > > I suppose you could do this (replace 3.4 with 2.7 if you use Python 2): > > $mv ~/anaconda/bin/python3.4 ~/anaconda/bin/python3.4-orig > $ln -s ~/anaconda/bin/pythonw /Users/aaronmeurer/anaconda/bin/python3.4 > > and see if anything breaks (or if you don't want to risk breaking your > main Python install, do it in a separate conda environment). > > Aaron Meurer > > On Fri, Aug 15, 2014 at 2:37 PM, Derek Homeier > wrote: > > On 14 Aug 2014, at 11:40 pm, Chris Barker wrote: > > > >> On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing > wrote: > >> but as far as I can see, on OSX, there is no *advantage* to > non-framework python. Is this correct? > >> > >> Suggestion for anaconda: > >> make bin/python a link to ../python.app/Contents/MacOS/python > >> > >> NOTE: the python.org python build has been doing this (or something > like it) for years and many versions -- I had gotten pretty used to it and > was pretty annoyed when I discovered Anaconda keeps anon-framework binary > as the default. > >> > >> It was annoying enough that I had to explicitly call pythonw (or alter > the #! line) for my wxPython scripts, but with ipython it's even worse -- > how would I start up ipython with a framework build? > >> > >> NOTE: if the Anaconda folks really think there is a real downside to > using the framework executable for the default python, maybe the ipython > start up script could use pythonw ? > >> > >> Eric - have you tried recent MPL with the python.org builds to confirm > the issue? I'm a bit surprised that it would even semi-work -- when I try > wxPython with the regular executable, I get an error message and it wont > run at all. > >> > > Just to make sure I understand - this is about whether the MPL macosx > backend would run with non-framework > > Python at all? It certainly should not, as _macosx.m has been enforcing > an error in this case for some versions. > > That put aside, when I disable the error at the end of _macosx.m I found > the OSX backend to still work as it used > > to under OS X 10.9 with the Fink Python installation (which is not built > as a framework, and unfortunately unlikely > > to change in foreseeable time). I.e. the only obvious problem is the > lack of control by the window manager. > > Overall I still find it to perform better than any of the alternative > backends. But having switched to PyQT4 as the > > default backend due to the above Fink troubles, I did notice some > oddities under Mavericks. I have no idea if they > > are related to the problems Eric had originally reported, but they are > clearly Mavericks-specific: > > > > When using MPL with ipython --pylab and the Quartz version of PyQT4, the > interpreter seems to be slow down >
Re: [matplotlib-devel] Purpose of doc/conda-recipes ?
On Thu, Sep 11, 2014 at 1:07 PM, Sandro Tosi wrote: > Hello, > I've noticed in 1.4.0 the presence of doc/conda-recipes dir; from what > I got from the doc it's a build system for Anaconda Continuum systems. > yes conda is that -- but it's also open-source and can be used outside of Anaconda. I think it makes a lot of sense to have a conda recipe in with the package source. May I ask what is the purpose of this directory? if it's for building, > why is it in the doc subtree? > I'm going to guess because it isn't (or wasn't) and "official" way to build MPL. but I think it should probably go in the main source dir, alongside setup.py -- conda is being pretty widely used these days. -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 [email protected] -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] google summer of code student
On Sat, Oct 18, 2014 at 8:50 AM, Thomas Caswell wrote: > We should be a mentoring organization for next summer. > well, maybe. A few years ago Google shifted to preferring fewer, larger, mentoring organizations. So python projects have tended to be handled under the PSF-sponsored organization. Or we could go half-way, and have a numfocus one.. > we need to have a list of viable projects for a > summer student. I suspect that these will have to have a balance > between importance (to justify doing it) and shiny-ness (to get > students to _want_ to do it). > It's a good idea to develop this list regardless of the sponsoring organization structure. -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 [email protected] -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] macosx/cocoagg embedding examples
On Mon, Nov 17, 2014 at 6:52 AM, Benjamin Root wrote: > I notice that our documentation for matplotlib embedding does not include > any examples using macosx or cocoagg. Is this because it is not possible > probably not! > or that no one has put forth any such examples? > probably. > Are there python bindings for the apple gui toolkit? > There is PyObjC -- which gives you a pretty direct binding to the Cocoa. https://pythonhosted.org/pyobjc/ That's what one would use to make a truly native app. Many of us doing OS-X desktop development need cross-platform support, so tk, wx or qt (or even GTK...) But someone made the OS-X native back-ends -- so they must have had a use case -- maybe they could post an example. A post to the pythonmac sig list may yield someone with an example to post as well. -Chris > Sincerely, > Completely clueless with regards to Apple > a.k.a. - Ben Root > > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- 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 [email protected] -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] xkcd doesn't seem to work in MacOSX backend
On Tue, Nov 18, 2014 at 9:55 AM, Phil Elson wrote: > Isn't the XKCD stuff baked into the Agg backend. Is it even possible to > produce XKCD svg or PDFs? > I wouldn't be surprised -- that's some pretty fancy stuff! To the OP -- maybe you can use the cocoaagg back-end... -CHB > On 18 November 2014 17:01, Jens Nielsen wrote: > >> I can reproduce it with the following traceback. Can you please open a >> bug report on Github for this issue? >> >> ``` >> Traceback (most recent call last): >> File "/usr/local/lib/python2.7/site-packages/matplotlib/artist.py", >> line 59, in draw_wrapper >> draw(artist, renderer, *args, **kwargs) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/figure.py", >> line 1079, in draw >> func(*args) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/artist.py", >> line 59, in draw_wrapper >> draw(artist, renderer, *args, **kwargs) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/axes/_base.py", >> line 2092, in draw >> a.draw(renderer) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/artist.py", >> line 59, in draw_wrapper >> draw(artist, renderer, *args, **kwargs) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/lines.py", line >> 712, in draw >> drawFunc(renderer, gc, tpath, affine.frozen()) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/lines.py", line >> 1067, in _draw_lines >> self._lineFunc(renderer, gc, path, trans) >> File "/usr/local/lib/python2.7/site-packages/matplotlib/lines.py", line >> 1107, in _draw_solid >> renderer.draw_path(gc, path, trans) >> File >> "/usr/local/lib/python2.7/site-packages/matplotlib/patheffects.py", line >> 115, in draw_path >> rgbFace) >> File >> "/usr/local/lib/python2.7/site-packages/matplotlib/patheffects.py", line >> 217, in draw_path >> renderer.draw_path(gc, tpath, affine, rgbFace) >> File >> "/usr/local/lib/python2.7/site-packages/matplotlib/backends/backend_macosx.py", >> line 58, in draw_path >> gc.draw_path(path, transform, linewidth, rgbFace) >> AttributeError: GraphicsContextBase instance has no attribute 'draw_path' >> ``` >> >> best >> Jens >> >> On Tue, Nov 18, 2014 at 4:12 PM, Mark Bakker wrote: >> >>> Sorry, forgot to mention that: 1.4.0 >>> >>> On Tue, Nov 18, 2014 at 5:00 PM, Benjamin Root wrote: >>> Which version of matplotlib are you using? On Tue, Nov 18, 2014 at 10:55 AM, Mark Bakker wrote: > Hello list, > > I don't seem to get xkcd to work in the MacOSX backend. When I try to > make a plot I get a nice white figure with nothing on it. Here's what I > did: > > import matplotlib.pyplot as plt > %matplotlib # responds with Using matplotlib backend: MacOSX > plt.plot([1,2,3]) # gives white figure with nothing on it > > When I do a kernel restart and specify the qt backend it works fine > (so I have a workaround), but I presume it should work, right? > > Thanks, > > Mark > > > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and > Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & > more > Get technology previously reserved for billion-dollar corporations, > FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > >>> >>> >>> -- >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>> with Interactivity, Sharing, Native Excel Exports, App Integration & more >>> Get technology previously reserved for billion-dollar corporations, FREE >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk >>> ___ >>> Matplotlib-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >>> >> >> >> -- >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> >> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk >> ___ >> Matplotlib-devel mailing lis
Re: [matplotlib-devel] subtle design difference with Wx backend from others
On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing wrote: > On 2014/11/23, 12:18 PM, Benjamin Root wrote: > > Reading through the backend_wx.py code, I noticed a small deviation from > > the other interactive backends. All other > > new_figure_manager_given_figure() separately creates a canvas and > > manager object (which, in turn, creates the window object) and hooks > > them all up. The manager would handle all window responsibilities such > > as creation/destruction and sizing. However, for the WX backend, this > > function just creates a FigureFrameWx object, which is the window > > widget. This object also becomes responsible for creating the canvas and > > the manager. > > > > This setup seems a bit backwards to me, but I am not entirely sure. It > > is definitely different. Does anybody know if it is merely a remnant of > > older designs (I think WX was the first backend)? What are the > > limitations of this approach, if any? Is there any interest in > > normalizing this backend design with the others (or vice versa)? > > In general, making the backends as similar as possible (and factoring > out as much as possible) is good; but actually messing around with these > things can be time consuming, painful, and hazardous. It's hard to test > with all the different platforms and versions. > Last I looked, and I doubt much has changed, the wx back-end required a fair bit of love -- there was a lot of extra refresh() calls being made in various places, most of which were unnecessary most of the time -- i.e. a bunch of extra refreshes. I've been hoping for literally years to find the time to go in an clean that up, but not yet So -- if someone can dedicate some time to clean up the wx back-end, then it wold make sense to look into normalizing this, too. But I agree with Eric, this is likely to be a significant job -- wouldn't tough unless your'e ready to commit to some real work. If it ain't broke. -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 [email protected] -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] subtle design difference with Wx backend from others
On Mon, Nov 24, 2014 at 9:41 AM, Benjamin Root wrote: > It is odd you mentioned the extra refreshes. I have to double-check my > book examples, but I think I found that I needed to add some extra > draw_idle() calls when using native wx widgets. > I haven't messed with widgets within MPL at all -- so I'm no help there. > This does raise another point. As a development policy, how should we > treat the backends? Should we be free to change it up so long as it works > well with Matplotlib, or should we be cautious and recognize that there are > users who go down beyond the canvas layer? > I've toyed with using the guts of MPL as a generic for-something-other-than-plotting AGG renderer. But I think it's fair to not support that kind of use-case with guarantees of backwards compatibility. I do think a just-agg-drawing lib would be a nice think to have. So some day, it may make sense to spilt it our out of MPL, and then we'd need to worry about preserving the API, but while it's built into MPL, I wouldn't worry about it. -CHB > > Ben Root > > On Mon, Nov 24, 2014 at 12:28 PM, Chris Barker > wrote: > >> On Sun, Nov 23, 2014 at 12:59 PM, Eric Firing wrote: >> >>> On 2014/11/23, 12:18 PM, Benjamin Root wrote: >>> > Reading through the backend_wx.py code, I noticed a small deviation >>> from >>> > the other interactive backends. All other >>> > new_figure_manager_given_figure() separately creates a canvas and >>> > manager object (which, in turn, creates the window object) and hooks >>> > them all up. The manager would handle all window responsibilities such >>> > as creation/destruction and sizing. However, for the WX backend, this >>> > function just creates a FigureFrameWx object, which is the window >>> > widget. This object also becomes responsible for creating the canvas >>> and >>> > the manager. >>> > >>> > This setup seems a bit backwards to me, but I am not entirely sure. It >>> > is definitely different. Does anybody know if it is merely a remnant of >>> > older designs (I think WX was the first backend)? What are the >>> > limitations of this approach, if any? Is there any interest in >>> > normalizing this backend design with the others (or vice versa)? >>> >>> In general, making the backends as similar as possible (and factoring >>> out as much as possible) is good; but actually messing around with these >>> things can be time consuming, painful, and hazardous. It's hard to test >>> with all the different platforms and versions. >>> >> >> Last I looked, and I doubt much has changed, the wx back-end required a >> fair bit of love -- there was a lot of extra refresh() calls being made in >> various places, most of which were unnecessary most of the time -- i.e. a >> bunch of extra refreshes. I've been hoping for literally years to find the >> time to go in an clean that up, but not yet >> >> So -- if someone can dedicate some time to clean up the wx back-end, then >> it wold make sense to look into normalizing this, too. But I agree with >> Eric, this is likely to be a significant job -- wouldn't tough unless >> your'e ready to commit to some real work. >> >> If it ain't broke. >> >> -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 >> >> [email protected] >> >> >> -- >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> >> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > -- 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 [email protected] -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better defaults all around?
On Wed, Nov 26, 2014 at 1:30 AM, Todd wrote: > About this, I am not expert so forgive me if this is nonsensical. > However, it would seem to me that these requirements are basically the same > as the requirements for the new default colormap that prompted this whole > discussion. So, rather than create two inconsistent set of colors that > accomplish similar goals, might it be better to instead use the default > colormap for the line colors? You could pick "N" equally-spaced colors > from the colormap and use those as the line colors. > I'm no expert either, but while similar principles about colorblind compatibility, etc apply, you want to sue a different scheme to represent a continuous range of colors and a set of distinct colors that aren't intended to be ranked. -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 [email protected] -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Date overhaul?
On Wed, Jan 7, 2015 at 2:10 PM, Eric Firing wrote: > One thing that has held this up is that datetime64 > came into numpy half-baked, and has remained experimental with known > problems that need to be fixed. It looks like the core of datetime64, > ignoring timezone problems, isn't going to change, so it should be > possible to work with that in matplotlib. > you can do some googling, but the issue with timezones in datetime64 is that is _always_ uses the system timezone to translate when parsing iso strings (and bare datetime.datetime objects) without a timezone, and I'm pretty sure does somethign like that when formatting string output, too. It can be worked around if you are careful to always make it think you are working in UTC. This should change in a release or two (and I'm sorry to say that I've held that up by stalling on getting proposals properly written up), but Eric's right, the internals should stay close enough that it's worth using. -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 [email protected] -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Date overhaul?
On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro wrote: > I'm real naive about this stuff, but I have always wondered why > matplotlib didn't just use datetime objects, or at least use > timezone-aware datetime objects as an "interchange" format to get the > timezone stuff right. > Time zone handling is a pain in the %}€* And the definitions keep changing. So you need a complex DB and library that needs frequent updating. This is why neither the standard library nor numpy support time zone handling out of the box. But the datetime object does support a hook to add timezone info. The numpy datetime64 may implementation _may_ provide a similar hook in the future. There is the pytz package, which MPL could choose to depend on. But even that is a bit ugly--e.g. from the pytz docs: """Unfortunately using the tzinfo argument of the standard datetime constructors ‘’does not work’’ with pytz for many timezones.""" So my suggestion is that MPL punts, and stick with leaving time zone handling up to the user, I.e only use datetimes that are timezone "naive". What this means is that MPL would always a assume all datetimes interacting with each other are in the same time zone (including same DST status). Anyway, I'm being a bit lazy here, so I may be wrong, but I think the issue at hand is that MPL currently uses a float array to store and manipulate datetimes, and the thought is that it may be better to use numpy datetime64 arrays -- that would give us more consistent precision, and less code to convert to/from various datetime formats. I'm a bit on the fence about whether it's time to do it, as datetime64 does have issues with the locale timezone, but as any implementation would want to work with not-just-the-latest numpy anyway, it may make sense to start now. -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 [email protected] -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib and Numfocus Fiscal Sponsorship Agreement (FSA)
+1 -- sounds great! On Tue, Jan 20, 2015 at 7:48 AM, Michael Droettboom wrote: > > > > > > > > > * Matplotlib is a widely used, well regarded, and powerful visualization > library that has dominated the Python visualization stack for over a > decade. However, to maintain that position, matplotlib must continue to > evolve. Complementary or alternative libraries are appearing at an > increasing rate, including browser-based plotting and GPU acceleration. To > maintain its leadership position for the next decade, Matplotlib must > interface with these alternatives while simultaneously expanding its > capabilities and becoming easier to use and learn. Matplotlib’s large > existing user base (greater than 50,000) means that new developments need > to be carefully balanced with maintaining existing interfaces. With the > large user and code base comes a significant maintenance and user-support > burden. These responsibilities currently account for a majority of the > core-developer time spent on matplotlib and has resulted in both the code > base and community being in a healthier state than ever before. Even 6 > years ago there was no automated testing to speak of and the number of > contributors continues to soar on github. However, this effort is, for the > most part, done on a volunteer basis in the nights and weekends of the core > developers. To go beyond this maintenance level—to make step-change > improvements for the benefit of matplotlib’s users—will require funding for > full-time developers. Inspired and encouraged by the example of IPython, we > would like to begin the process of fundraising. Managing funding on the > needed scale is a complex and time-consuming process. Thankfully, > NumFOCUS, a 501(c)3 charity organisation co-founded by John Hunter, offers > a fiscal sponsorship agreement to minimize the administrative and legal > burden on open source projects. We would like to enlist NumFOCUS as our > agents in all legal and financial matters, including banking, accepting > donations as a non-profit, payroll, and access to legal counsel. As part > of the agreement, NumFOCUS would charge a percentage of all funds raised to > cover their costs. The full text of the agreement is attached. To comply > with the legal and accounting requirements of a non-profit, matplotlib > needs to form an administrative body to interact with NumFOCUS and direct > the disbursement of any funds. The proposed initial members of the body, > are myself (Mike Droettboom), Eric Firing, Phil Elson, and Thomas Caswell, > with Thomas acting as the point of contact with NumFOCUS. In practice, > signing an FSA will have very little impact on the matplotlib project > itself - it will still be BSD-licensed and community-driven as it has > always been, and the only motivation for doing this is to give us an > opportunity to apply for funding to do more work on matplotlib. We'd like > to canvas the community's opinion on the matter, but to put a concrete > timeline on the discussion, we would like to propose signing an FSA with > NumFOCUS in 3 weeks (Feb 10th 2015) unless there is a major community > discomfort with us doing so. Cheers, Michael Droettboom * > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > http://www.droettboom.com > > > > -- > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- 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 [email protected] -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Kivy backend
On Sat, Mar 7, 2015 at 4:17 PM, Thomas Caswell wrote:
> Thank your for your interest, mpl on touch devices sounds super cool!
>
Indeed!
> The easiest course is probably to develop a backend modeled after the
> {qt,wx,gtk}Agg backends which embed an Agg backend into the gui framework
> of choice. In those cases we rely on Agg to handle the mpl specific
> drawing tasks and then embed the resulting bitmap into the GUI.
>
Kivy is all built on OpenGL, so it would probably be pretty straightforward
to generate teh image with AGG, then dump it to the screen as an OpenGL
texture. But it would be a bit sad to not take advantage of OpenGL at all
in that process. (and getting AGG to work with Kivy may be less than
trivial...)
Note that vector graphics in OpenGL is a serious pain, but maybe Kivy has
some stuff to help?
Also, the MPL back-end structure wasn't designed to push much of the
transforming, etc to the back -end, which is too bad, as that's what OpenGL
does well.
But I'd still take a look at the work done to make a real OpenGL back-end
-- not sure how far that got, but worth a look.
Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe not!
form teh vispy docs:
"Vispy now ships a very basic and experimental OpenGL backend for
matplotlib."
HTH,
-Chris
> A majority of the work in the gui backends deals window/widget creation
> and the plumbing required to convert interaction events from the GUI into
> the internal events mpl uses.
>
> Tom
>
> On Sat, Mar 7, 2015 at 4:15 PM Achyut Rastogi
> wrote:
>
>> Hello , I am a novice gsoc aspirant and I want to write a backend for
>> kivy, I read some of the other conversations on the mailing list and I know
>> about the template you guys provide but I am having trouble getting
>> started, can you please help me get up-to speed. I would be great help if
>> you could tell me what all I need to know of matplotlib to write a good
>> backend.
>> Thank You
>> Achyut Rastogi
>>
>> --
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> ___
>> Matplotlib-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
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
[email protected]
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Kivy backend
On Fri, Mar 13, 2015 at 10:21 AM, Benjamin Root wrote: > Probably what I am most interested in from OpenGL is its transforms stack. > OpenGL can't do anything with transforms that you couldn't do in python (or C, or Cython). What it can do is push the transform computations to the GPU(s) -- making for monstrously faster performance. This is the "problem" with the current MPL architecture. It does all the transforming outside of the back-ends, and assumes that the backends can only render in 2-d pixel coordinates. If we can re-factor to push the transforms to the back-end, most of them could use the same generic code, but you'd have the option of the back-end providing the transforms, which would buy you a LOT with Open GL, and could maybe by you some with, say, wxAgg, as you could put the transforms in C/C++ perhaps more efficiently. Note that with OPenGL in general, its the transforming that buys you performance -- when you push brand new data to be rendered, it takes a lot of time to push that data to the video card, so drawing the first time doesn't buy you much. But if you need to re-render that same data in a different view, say zooming in or out, etc, then GL can fly -- if that transformation can be done on the GPU. As far as I understand it, that's what vispy is doing. -CHB > While matplotlib's transforms stack is fantastic, it is inherently limited > to 2D operations. Upgrading the transforms stack in some way would be huge > thing to me. > > On Fri, Mar 13, 2015 at 1:08 PM, Nicolas P. Rougier < > [email protected]> wrote: > >> >> It might be difficult to stick to matplotlib architecture and still >> benefit from OpenGL speed. >> There are a lot of GL techniques that speed up things a lot but are are >> not really compatible. >> >> For example, isolines, quiver plots, image interpolations and most >> transformations can be handled directly by the GPU >> (see http://glumpy.github.io/gallery.html) >> >> But we'll try to use matplotlib public api such that things will be >> mostly transparent for the user >> >> Nicolas >> >> > On 13 Mar 2015, at 17:33, Benjamin Root wrote: >> > >> > +1 on an OpenGL backend! Especially if I can off-load a lot of mplot3d >> stuff to it! Does vispy have any plans to eventually bring that into >> mainline matplotlib, or does it break too much with the standard set of >> backends to make sense in matplotlib (or maybe it is too much of a >> maintenance/packaging burden?) >> > >> > Ben Root >> > >> > On Fri, Mar 13, 2015 at 12:12 PM, Cyrille Rossant < >> [email protected]> wrote: >> > Kivy is all built on OpenGL, so it would probably be pretty >> straightforward to generate teh image with AGG, then dump it to the screen >> as an OpenGL texture. But it would be a bit sad to not take advantage of >> OpenGL at all in that process. (and getting AGG to work with Kivy may be >> less than trivial...) >> > >> > Note that vector graphics in OpenGL is a serious pain, but maybe Kivy >> has some stuff to help? >> > >> > Also, the MPL back-end structure wasn't designed to push much of the >> transforming, etc to the back -end, which is too bad, as that's what OpenGL >> does well. >> > >> > But I'd still take a look at the work done to make a real OpenGL >> back-end -- not sure how far that got, but worth a look. >> > >> > Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe >> not! form teh vispy docs: >> > >> > "Vispy now ships a very basic and experimental OpenGL backend for >> matplotlib." >> > >> > >> > Yes, and we plan to work on this backend in the next few months. We >> might have a couple of GSoC students working partly on the OpenGL MPL >> backend and possibly on Kivy integration. >> > >> > >> > >> -- >> > Dive into the World of Parallel Programming The Go Parallel Website, >> sponsored >> > by Intel and developed in partnership with Slashdot Media, is your hub >> for all >> > things parallel software development, from weekly thought leadership >> blogs to >> > news, videos, case studies, tutorials and more. Take a look and join the >> > conversation now. http://goparallel.sourceforge.net/ >> > ___ >> > Matplotlib-devel mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > >> > >> > >> -- >> > Dive into the World of Parallel Programming The Go Parallel Website, >> sponsored >> > by Intel and developed in partnership with Slashdot Media, is your hub >> for all >> > things parallel software development, from weekly thought leadership >> blogs to >> > news, videos, case studies, tutorials and more. Take a look and join the >> > conversation now. >> http://goparallel.sourceforge.net/___ >> > Matplotlib-devel mailing list >> > M
Re: [matplotlib-devel] Make matplotlib running on GPU/CUDA
On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda wrote: > But there’s a good news, I have a nice GPU available (an NVIDIA Tesla > K40c), so I’d like to know if there is a way to make matplotlib run on it, > or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly. > I tihnk you want VisPy: https://vispy.readthedocs.io/en/latest/ It's a plotting package with a kinda like matplotlib API, built on OpenGL. Unfortunately, it doesn't look like it's been updated in a while -- from teh docs. But the gitHub project is active: https://github.com/vispy/vispy So maybe it's only the docs that haven't been updated! But probably a much better option than trying to shoehorn GPU rendering into MPL. The problem is that while MPL was designed to be "backend" independent -- so it is "easy" to plug in an alternative renderer, the rendering model is not really well suited to GPU rendering -- it would take a lot of refactoring to really be able to take advantage of the graphics card. -CHB -- 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 [email protected] -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Make matplotlib running on GPU/CUDA
On Wed, Sep 13, 2017 at 12:31 AM, Francesco Faccenda wrote: > I have to admit I already stumbled on VisPy while doing my research on the > web. Still, I've got a lot of code already working with *matplotlib*. > Indeed, not only I plot data with it, but i manage a lot of *mpl events* > to provide the users usefool tools, like lines picking, tooltips, lines > copy/paste, square selectors for multiple selections, context menu and so > on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While at > the beginning few lines were managed and noone complained, now that big > amout of data has to be displayed, the non-GPU core of the library is > starting to show its limits. > > Since matplotlib is a reference library for this kind of applications, I > thought it deserved an update in this direction. > Well, As I understand it, VisPY made some effort to be compatible with the MPL API -- but that is going to depend on how much you use the lower-level parts f the API -- things like the transform, etc. to take advantage of GPU rendering, all the transforms, etc needs to be pushed to the GPU, so the architecture (and API) needs to be quite different. > If anyone is willing to do so, I'm available to discuss possible solutions > and also provide any help I can give. > As Ben pointed out, and I was trying to make clear -- it really isn't a matter of "just" writing an OpenGL backend -- there really needs to be a major restructuring. And VisPy is pretty much that project. Whether it is feature complete, robust and maintained enough for your use-cases, I have no idea, but even if not -- you'll probably be better off contributing to that effort than starting all over with trying to make an GPU_based OPenGL back-end. However -- maybe there is another option: Taking full advantage of GPUs does require a full restructuring, but maybe there are other ways to get better performance -- for instance, optimizing the transform code, etc: Using the GPU with PyCuda or [what the heck is the name of the more general GPU-using lib??] using numba Maybe there is still room for Cython, etc In short, profiling MPL carefully, to see where the performance bottlenecks are: With modern hardware, actually rendering stuff is no longer the slow part of visualization. Rather, it's pushing data to the renderer, transforming data etc. This is why to take advantage of the GPU, you need to do the transformations, etc on the GPU -- which the MPL architecture doesn't make easy by dropping in a new back-end. Which is why VisPy built a new architecture from the bottom up. -CHB -- 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 [email protected] -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
On Fri, Nov 30, 2012 at 6:06 AM, Michael Droettboom wrote: > If you read between the lines of what I was saying, that is basically > where I fall as well. There seems to be a lot of desire to use Cython > to make the code more accessible, I'll add a beat to that drum -- I'm a big Cython fan. > however, and I'm willing to consider > it if it can be shown to be superior to the raw C/API for this task -- I think there is NO QUESTION that Cython is superior to the C/API -- why would you want to deal with the reference counting, etc yourself? Cython can handle the boiler plate code for you very cleanly an elegantly. Something to keep in mind about Cython: It can be used in multiple ways: 1) Add static typing to what is essentially Python code to get better performance -- this may be what you mean by the "more accesible" part. A great use, but maybe, maybe, maybe not best for the core bits of MPL. 2) Calling C/C++ code -- Cython is s great way to call C/C++ code -- it can handle the packing and unpacking of python types, reference counting, etc. for you, so much like using the C API, but a lot less tricky boiler plate code to write. (2) is the use case that I'm arguing is NO QUESTION a better option than the C API. Compared to SWIG, SIP (and I assume C_XX), the downside is that there is no auto-generation of wrappers (at least nothing mature). However, for the MPL case, we're not trying to wrap a large existing library, but rather particular code that is often written for MPL specifically, so hand-writing the Cython is a fine option. So why not Ctypes, or??? I think the real strength of Cython in wrapping C code is that you can write a "thick" wrapper in an almost_python language. So if you want to vectorize a C function, for instance, you can write that bit in Cython very easily (and Cython's built-in understanding of numpy array is very helpful here). When you use ctypes, you need to write that in pure Python -- easy enough, but probably not very performant. With SWIG, etc, you end up writing a fair bi tof C (or SWIG) code to handle the thicker bits of the wrapper -- so you're dealing with the raw CPython API, and , well, C. Cython really is an easier option. I've found that for stuf that is less than very small (i.e. one or two loops through an array), writing the core code in native C or C++ can be easier, you know for sure you're not accidentally making expensive Python calls, etc. but using Cython to call it is still very helpful. > I'm not sure it is -- I always seem to end up with things that are more > lines of code with more obscure workarounds than just coding in C directly. Exactly -- but I don't think that applies to the CPython-API bits, but rather the core code -- so keep that in C. In summary, I guess what I think is the power of Cython is the flexibility in where you draw the line between Python, Cython, and C -- you can pass pure Python through Cython, or you can do almost nothing with it but call a C function, and eveything in between. > From my experience, I would prefer to write such extensions in C directly > rather > than relying on Cython, SWIG, or Boost.Python, because those approaches would > lead to another dependency (for developers at least), The dependency is pretty easy to deal with compared to the many others in MPL. > and requires developers to > learn how to code in them. Which may not be very hard, but we may as well > avoid > that if possible. Here's where I disagree -- if we go pure C and C-API developers need to know the Python C-API -- that is actually a pretty big deal, and hard to get right. Knowing enough Cython to call some C code is a smaller lift for sure. Anyway, I saw give it a shot -- I suspect you'll like 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 [email protected] -- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
On Sat, Dec 1, 2012 at 6:44 AM, Michiel de Hoon > > Since the Python/C glue code is modified only very rarely, there may not be > a need for regenerating the Python/C glue code by developers or users from a > Cython source code. True. > In addition, it is much easier to maintain the Python/C glue code than to > write it from scratch. Once you have the Python/C glue code, it's relatively > straightforward to modify it by looking at the existing Python/C glue code. > not so true -- getting reference counting right, etc is difficult -- I suppose once the glue code is robust, and all you are changing is a bit of API to the C, maybe > > This argues against making the Cython source code a part of the matplotlib > codebase. > huh? are you suggesting that we use Cython to generate the glue, then hand-maintain that glue? I think that is a really, rally bad idea -- generated code is ugly and hard to maintain, it is not designed to be human-readable, and we wouldn't get the advantages of bug-fixes further development in Cython. So -- if you use Cython, you want to keep using, and theat means the Cython source IS the source. I agree that it's a good idea to ship the generated code as well, so that no one that is not touching the Cython has to generate. Other than the slight mess from generated files showing up in diffs, etc, this really works just fine. Any reason MPL couldn't continue with EXACTLY the same approach now used with C_XX -- it generates code as well, yes? Michael Droettboom wrote: > For the PNG extension specifically, it was creating callbacks that can > be called from C and the setjmp magic that libpng requires. I think > it's possible to do it, but I was surprised at how non-obvious those > pieces of Cython were. I was really hoping by creating this experiment > that a Cython expert would step up and show the way ;) Did you not get the support you expected from the cython list? Anyway, there's no reason you can't keep stuff in C that's easier in C (or did C_XX make this easy?). I think making basic callbacks is actually pretty straightforward, but In don't know about the setjmp magic (I have no idea hat that means!). > The Agg backend has more C++-specific challenges, particularly > instantiating very complex template expressions -- I'm guessing you'd do the complex template stuff in C++ -- and let Cython see a more traditional static API. > but some of that complexity could be reduced by using Numpy arrays in place > of the > image buffer types that each of them contain OR Cython arrays and/or memoryviews -- this is indeed a real strength of Cython. > The Cython version isn't that much shorter than the C++ version. I think some things make sense to keep in C++, though I do see a fair bit of calls (in the C++) to the python API -- I'm surprised there isn't much code advantage, but anyway, the goal is more robust/easier to maintain, which may correlate with code-size, but not completely. > These declarations aren't exact matches to what one would find in the header > file(s) >because Cython doesn't support exact-width data types etc. It does support the C99 fixed-width integer types: from libc.stdint cimport int16_t, int32_t, Or are you talking about something else? > I'm not sure why some of the Python/C API calls I needed were not defined in > Cython's include wrappers. I suspect that's an oversight -- for the most part, stuff has been added as it's needed. One other note -- from a quick glance at your Cython code, it looks like you did almost everything is Cython-that-will-compile-to-pure-C -- i.e. a lot of calls to the CPython API. But the whole point of Cython is that it makes those calls for you. So you can do type checking, and switching on types, and calling np.asarray(), etc, etc, etc, in Python, without calling the CPython api yourself. I know nothing of the PNG API, and am pretty week on the CPython API (and C for that matter), but I it's likely that the Cython code you've written could be much simplified. > Once things compiled, due to my own mistake, calling the function segfaulted. > Debugging > that segfault in gdb required, again, wading through the generated code. > Using gdb on > hand-written code is *much* nicer. for sure -- there is a plug-in/add-on/something for using gdb on Cython code -- I haven't used it but I imagine it would help. Ian Thomas wrote: > I have never used Cython, but to me the code looks like an inelegant > combination of > Python,C/C++ and some Cython-specific stuff. well, yes, it is that! > I can see the advantage of this approach for small sections of code, but I > have strong > reservations about using it for complicated modules that have > extensive use of > templated code and/or Standard Template Library collections (mpl has examples > of > both of these). So far, I've found that Cython is good for: - The simple stuff -- basic loops through numpy arrays, etc. - wrapping/calling more complex C or C
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
On Mon, Dec 3, 2012 at 11:59 AM, Michael Droettboom wrote: >>> but some of that complexity could be reduced by using Numpy arrays in place >>> of the >>> image buffer types that each of them contain >> OR Cython arrays and/or memoryviews -- this is indeed a real strength of >> Cython. > > Sure, but when we return to Python, they should be Numpy arrays which > have more methods etc. -- or am I missing something? Cython makes it really easy to switch between ndarrays and memoryviews, etc -- it's a question of what you want to work with in your code, so you have write a function that takes numpy arrays and returns numpy arrays, but uses a memoryview internally (and passes to C code that way). But I'm not an expert on this, I'mve found that I'm either doing simplestuff where using numpy arrays directly works fine, or passing the pointer to the data array off to C: def a_function_to_call_C( cnp.ndarray[double, ndim=2, mode="c" ] in_array ): """ calls the_c_function, altering the array in-place """ cdef int m, n m = in_array.size[0] m = in_array.size[1] the_c_function( &in_array[0], m, n ) >> It does support the C99 fixed-width integer types: >> from libc.stdint cimport int16_t, int32_t, >> > The problem is that Cython can't actually read the C header, yeah, this is a pity. There has been some work on auto-generating Cython from C headers, though nothing mature. For my work, I've been considering writing some simple pyd-generating code, just to make sure my data types are inline with the C++ as it may change. > so there > are types in libpng, for example, that we don't actually know the size > of. They are different on different platforms. In C, you just include > the header. In Cython, I'd have to determine the size of the types in a > pre-compilation step, or manually determine their sizes and hard code > them for the platforms we care about. yeah -- this is a tricky problem, however, I think you can follow what you'd do in C -- i.e. presumable the header define their own data types: png_short or whatever. The actually definition is filled in by the pre-processor. So I wonder if you can declare those types in Cython, then have it write C code that uses those types, and it all gets cleared up at compile time -- maybe. The key is that when you declare stuff in Cython, that declaration is used to determine how to write the C code, I don't think the declarations themselves are translated. > It would at least make this a more fair comparison to have the Cython > code as Cythonic as possible. However, I couldn't find any ways around > using these particular APIs -- other than the Numpy stuff which probably > does have a more elegant solution in the form of Cython arrays and > memory views. yup -- that's what I noticed right away -- I"m note sure it there is easier handling of file handles. > True. We do have two categories of stuff using PyCXX in matplotlib: > things that (primarily) wrap third-party C/C++ libraries, and things > that are actually doing algorithmic heavy lifting. It's quite possible > we don't want the same solution for all. And I'm not sure the wrappers all need to be written the same way, either. -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 [email protected] -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
On Mon, Dec 3, 2012 at 2:21 PM, Nathaniel Smith wrote: > For the file handle, I would just write > > cdef FILE *fp = fdopen(file_obj.fileno(), "w") > > and be done with it. This will work with any version of Python etc. yeah, that makes sense -- though what if you want to be able to read_to/write_from a file that is already open, and in the middle of the file somewhere -- would that work? I just posted a question to the Cython list, and indeed, it looks like there is no easy answer to the file issue. -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 [email protected] -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
On Mon, Dec 3, 2012 at 12:24 PM, Chris Barker - NOAA Federal
wrote:
>>>> but some of that complexity could be reduced by using Numpy arrays in place
>> It would at least make this a more fair comparison to have the Cython
>> code as Cythonic as possible. However, I couldn't find any ways around
>> using these particular APIs -- other than the Numpy stuff which probably
>> does have a more elegant solution in the form of Cython arrays and
>> memory views.
OK -- so I poked at it, and this is my (very untested) version of
write_png (I left out the py3 stuff, though it does look like it may
be required for file handling...
Letting Cython unpack the numpy array is the real win. Maybe having it
this simple won't work for MPL, but this is what my code tends to look
like.
def write_png(cnp.ndarray[cnp.uint32, ndim=2, mode="c" ] buff not None,
file_obj,
double dpi=0.0):
cdef png_uint_32 width = buff.size[0]
cdef png_uint_32 height = buff.size[1]
if PyFile_CheckExact(file_obj):
cdef FILE *fp = fdopen(file_obj.fileno(), "w")
fp = PyFile_AsFile(file_obj)
write_png_c(buff[0,0], width, height, fp,
NULL, NULL, NULL, dpi)
return
else:
raise TypeError("write_png only works with real PyFileObject")
NOTE: that could be:
cnp.ndarray[cnp.uint8, ndim=3, mode="c" ]
I'm not sure how MPL stores image buffers.
or you could accept any object, then call:
np.view()
-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
[email protected]
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
On Mon, Dec 3, 2012 at 4:16 PM, Nathaniel Smith wrote: > Yeah, this is a general problem with the Python file API, trying to > hook it up to stdio is not at all an easy thing. A better version of > this code would skip that altogether like: > > cdef void write_to_pyfile(png_structp s, png_bytep data, png_size_t count): > fobj = png_get_io_ptr(s) > pydata = PyString_FromStringAndSize(data, count) > fobj.write(pydata) Good point -- not at all Cython-specific, but do you need libpng (or whatever) to write to the file? can you just get a buffer with the encoded data and write it on the Python side? Particularly if the user wants to pass in an open file object. This might be a better API for folks that might want stream an image right through a web app, too. As a lot of Python APIs take either a file name or a file-like object, perhaps it would make sense to push that distinction down to the Cython level: -- if it's a filename, open it with raw C -- if it's a file-like object, have libpng write to a buffer (bytes object) , and pass that to the file-like object in Python anyway, not really a Cython issue, but that second object sure would be easy on Cython -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 [email protected] -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] ANN: matplotlib-1.3.0rc1
On Wed, May 29, 2013 at 2:19 PM, Russell E. Owen wrote: > I guess we could serve the associated packages (pytz, dateutil and six), > or if they can be installed by pip, ask users to install those. But > users using binary installers may not even have pip available, so it's a > big initial hurdle. If the binary installers are available (and easy to find), not such a big deal -- this is teh case with Christoph's repository for Windows, for instance. Russell, have you been following the thread I started on the pythonmac list? We really need a way to deal better with binaries on the Mac, including dependency handling. Note that supposedly the "wheel" format is coming (soon?), and after that support for binary wheels by pip. Of course, none of that helps right now... -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 [email protected] -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] ANN: matplotlib-1.3.0rc1
On Wed, May 29, 2013 at 5:54 PM, Michael Droettboom wrote: > It looks like the ability to include pytz and other dependencies in > binary distributions has been removed? > > It's really just that the matplotlib source no longer includes them. > Binaries can be built however we want them to be. Not knowing how the .dmg > is put together, is it possible to add pytz, dateutil, pyparsing and six to > the dmg during its creation? I agree -- adding them to the binary package is the way to go here -- it's packaging issue, not a development or building issue. I can't imagine it would be hard to write a little script that includes them all in one mpkg. > Right -- and we're not using pip (because we can't) to handle our C/C++ > dependencies, many of which we continue to ship with matplotlib. Should the code that's shipped with MPL be build-able with PIP? But the harder issue is third-party dependencies that we expect the system to provide: libpng, libfreetype, On the building side, I'd really like to see more support for this -- the Linux package managers handle it OK on LInux, but there is no good system for Windows or OS-X. I'm taking a look at gattai: http://sourceforge.net/projects/gattai/ Mostly for the Mac, but it does support Windows and linux as well. I'm not looking at Windows right now, as Christoph's repository gives me all I need -- which makes me think: Christoph, do you have a build system for all those that might be a good basis for a multi-platform solution? -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 [email protected] -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP14: Improve text handling
On Thu, May 30, 2013 at 8:59 AM, Michael Droettboom wrote: > I've drafted a MEP with a plan to improve some of the text and font handling > in matplotlib. > > I'd love any and all feedback. nice writ-up and thanks for workign on this. One idea (alternative?) would be to put more effort into the "mathtext" renderer. TeX itself, of course does an outstanding job of laying out text, paragraphs, etc. I'm assuming that the core stuff is already in mathtext, so adding better support for regular old non-math text would be a less-than-huge deal. And we still wouldn't need the full how-to-split-pages and all that code for MPL. Not sure about properly handling unicode issues, though modern TeX does support unicode. With a fully-function mathtex, it could be the default (only?) text layout system for MPL, simplifying things quite a bit. ... just a thought. -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 [email protected] -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP14: Improve text handling
On Thu, May 30, 2013 at 11:29 PM, Nicolas Rougier wrote: >> I'm also concerned about the overhead of >> ctypes, given that there are already so many required optimizations in >> the matplotlib freetype wrapper to make it fast enough. But I'm willing >> to hold judgement on that until some measurements have been made. >> > > I would never have thought ctypes would be a problem for speed/optimization > and I never benchmarked the freetype-py. Well, I see it this way -- for high performing Python code, you often need to "vectorize" operations one way or another. i.e. if you need to do a given operation on a bunch of numbers, objects, whatever, you need to be able to pass the collection in to lower-level code, so you dont have all the overhead of python funciton calls, dynamic typing, etc, inside your loop. Many (most) C libraries are not designed this way. So when writing python wrappers, you need to loop though a sequence in python, and call the underlying c function for each item. With ctypes, you write that code inPython, with cython, it's easy to write that code in cython, which gets compiled down to C -- you can get major performance benefits from this. And Cython is almost at easy to write as Python. How this applied to freetype, I don't know. >> 2) It's not Numpy-aware. For example, it loads image buffers into >> regular Python lists. This really should use Numpy for speed. you can do this with ctypes, and would work fine for image buffers, by many not as well as Cython for say, a large sequence of characters... -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 [email protected] -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Setuptools and release candidate testing
On Jul 24, 2013, at 7:23 AM, Michael Droettboom wrote: Part of this is due to the change to setuptools/distribute, Even though I was the one who spearheaded the move to setuptools, I'm wondering whether we shouldn't examine backtracking on some of this for the 1.4.x release. I don't think so--in this case the timing was particularly bad, but the core developers are pretty commited to setup tools/pip as the way of the future, so these things will settle down. And just like MPL has issues because many of us wait for "final" to test ( guilty as charged...) the distribution tools need to be tested by complex packages like MPL in order to get robust and stable. -CHB The second issue is more one of process. When I make a release candidate, I announce it here, and Cc all of the packagers of the major Linux distributions, as well as Christoph and Russell who put together packages for Windows and Mac respectively. Part of that delegation is because I don't have installations of all of those platforms, and part is to spread some of the workload. And most of the time it works really well -- a big thanks to everyone involved. However, this cycle there have been a small number of critical bugs discovered in the fifth release candidate that existed in the first release candidate, which doesn't give me a lot of confidence that final won't have critical bugs either. I think some of this will be ameliorated over time as we build out a more effective continuous integration infrastructure (see MEP19: we could really use some help on this one), but some of it may have to do with users being unwilling to test a release until it has the word "final" attached. How can we get more ordinary users (who may have even more unusual environments) involved? I also suspect some of it has to do with the timing in the summer which hits in the middle of vacations and conference travel for many. We can certainly avoid the summer months next time. But I don't think it's just about building more time into the schedule. Let me know if I'm doing something boneheaded ;) Mike -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Calling to those "embedding" matplotlib in applications
On Mon, Aug 12, 2013 at 7:01 AM, Michael Droettboom wrote: > I propose to fix this by turning on interactive only when > running at an interactive console. I embed MPL more than other uses, and this sounds like a fine solution to me/ Thanks, -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 [email protected] -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Calling to those "embedding" matplotlib in applications
On Mon, Aug 12, 2013 at 11:16 AM, Michael Droettboom wrote: > Would you mind testing the very simple patch in the PR [1] and confirm > that it has no negative consequences for you? > > [1] http://github.com/matplotlib/matplotlib/pull/2286 Hmm -- I'm not set up to build it right now -- but I'll see what I can do. -Chris > Mike > > On 08/12/2013 01:55 PM, Chris Barker - NOAA Federal wrote: >> On Mon, Aug 12, 2013 at 7:01 AM, Michael Droettboom wrote: >>> I propose to fix this by turning on interactive only when >>> running at an interactive console. >> I embed MPL more than other uses, and this sounds like a fine solution to me/ >> >> Thanks, >> >> -Chris >> >> > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- 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 [email protected] -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] I have a Mac!
On Fri, Aug 16, 2013 at 7:32 AM, Michael Droettboom wrote: > We actually discussed this very issue yesterday in our Google hangout about > continuous integration. We're probably going to need to script a full setup > from a clean Mac + XCode to a working matplotlib development environment in > order to make that happen, Just a note -- this did NOT "just work" the other day for me -- it found the freetype libs that OS-X has in the X11 build, but didn't like them at compile time. I haven't debugged it yet, sorry. But the real trick here is what you want to build: which OS-X versions do you want to support? which architectures? which Python Build(s)? What I've been planning on doing is setting up a gitHub (or something) project for building the various dependencies that various python packages need -- there are a few that are broadly used: libpng, libfreetype (used by MPL, PIL, wxPython, ???). The idea is that if you wanted to build MPL (or PIL, or ???) you'd grab the MacPyton_Dependencies project, build it, then go from there. Anyone want to help? It just feels like we are all repeating each-others work a LOT here! NOTE: the big issues come up if you want to build binaries that are re-distributable (as a package, or with py2app, or???). In this case, you need binaries that can run on perhaps older machines than the one you're building on, or a different architecture. Building to run on the machine it's built-on is a lot easier. (particularly with macport or homebrew) -CHB and obviously that will be shared with the world. > Things are even more complex on Windows, and I'd like to do that there, too. > So stay tuned. > > Mike > > > On 08/16/2013 10:02 AM, Paul Hobson wrote: > > Mike, > > That's great news. Is there any chance we can look forward to "official" > instructions for setting up a Mac to develop matplotlib? > > I gave up a long time ago and started piecing to together my meager PRs in a > linux VM. > -paul > > > On Fri, Aug 16, 2013 at 6:52 AM, Michael Droettboom wrote: >> >> Thanks to the gracious donation from Hans Petter Langtangen and the >> Center for Biomedical Computing at Simula (http://home.simula.no/~hpl), >> I now have a new Mac Mini sitting at my desk. This should allow me to >> keep on top of changes that affect the Mac builds and to better track >> down Mac-only issues. >> >> Stay tuned over the next few weeks and months as we will most likely be >> using some more of these funds to pay for hosted continuous integration >> services (as discussed yesterday in our MEP19 Google Hangout). >> >> Cheers, >> Mike >> >> >> >> >> -- >> Get 100% visibility into Java/.NET code with AppDynamics Lite! >> It's a free troubleshooting tool designed for production. >> Get down to code-level detail for bottlenecks, with <2% overhead. >> Download for free and get started troubleshooting in minutes. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- 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 [email protected] -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] I have a Mac!
On Fri, Aug 16, 2013 at 3:41 PM, Hubert Holin wrote: > Building for various architectures than one is on, on the > Mac, is something I regretfully bought into (Apple in the beginning told us > to go for it) but latter found out to be a useless hassle (Apple silently > removing PPC64 dev tools anybody? Urgh!) > > Bon courage merci. and I've felt your frustration, but it is setting down -- I know I finally got rid of my old Mac G5 (nice machine to the end...), and I think we can simply stick with Intel32+64 bit now, so not as bad. And I do think there a real benefit to being about to provide newbie-friendly option that "just works" on the Mac. -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 [email protected] -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] I have a Mac!
On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry wrote: > I'm banging away at installing MPL on top of python.org's python. This is why binary installers are good idea! > the libfreetype/freetype issue. yeah, that's kind of uglyand where is doesn't "just work" for me... > 1) install libpng[1] and freetype[2] from source libpng and freetype are different, though install from source may be the way to go: libpng is there, but is not properly installed, I'm not sure it's got the header for the same version as the lib, and libpng-config is either not there or not for the right version or somethign ugly. It look, form messages at build time, that someone has hacked some code into the MPL build that figures all that out, but for other stuff I'm doing, I just punt and build libpng -- that's pretty straighforward, at least. But teh solution in the MPL code now seems to work. > 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's > directions[4]) so MPL finds XQuartz's libpng/freetype I _think_ that OS-X now ships with X11, which has freetype (though installed weirdly once again...) we certainly should NOT expect people to install anything big to build MPL, and binaries should not depend on anything not shipped by Apple by default. According to Russell, you do need to install something, so I think that's out. > 4) create the MPL binary installer and use that That's what most people should do -- but one of us needs to build it. > Option 1 seems simple-est, but installing freetype requires more than > ./configure && make && sudo make install. darn. But hopefully we can figure it out. > Option 4: This would require some input from whoever (Gohlke?, Owen?) makes > the binary installers. I think Russell has been doing it for MPL lately. My thoughts: We want to support two user-bases: 1) folks that don't mind a little command line work, and probably need other scientific libs, etc anyway, an want an MPL that runs on their machine: - these folks should use homebrew or macports to build the dependencies (or even hand-compile them). Ideally we have setup.py that will find those libs, and test to see that the builds work once in a while. 2) folks that "just want to use it" and/or want a binary they can re-distribute via py2app, etc. - for these folks, we need to provide binaries. These binaries should: 1) Match the python.org python builds. (probably only the Intel ones now...) 2) statically link the non-sytem libs This has been done for a while, off and on, most recently by Russell, AFAIK. But this is not a problem unique to MPL. All sorts of python packages need this, and only some of the package maintainers do it (well). Also, a bunch of packages require the same dependencies (i.e. PIL and MPL both need png and freetype) So, rather than re-inventing the wheel over and over again, It would be great to have a central repository where we can develop build scripts, etc that share an infrustructure for building these binaries. I've started one: https://github.com/MacPython/mac-builds there is not much there, only a couple things I'm working on at the moment (netCDF4, which is of interest to scipy folks, and py_gd, which is my own simple drawing lib, that no one else uses (yet?) If anyone wants to join the project let me know -- if I know you from your work with this community, I'll gladly add you. I'm using the gattai build system: (https://sourceforge.net/projects/gattai/). I decided to do that, as I was sick of re-writing essentially the same build scripts, and I kept adding features to mine that would have resulted in re-implementing gattai anyway. I've been hacking at gattai, and its author is quite open to moving it forward. That being said, there is no reason that we need to use the same build system -- we could easily have custom build scripts for a project, and still have it share the dependencies. I was planning on getting it all further along before announcing the project and looking for help, but since is came up... -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 [email protected] -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] I have a Mac!
On Fri, Aug 23, 2013 at 11:21 AM, Russell Owen wrote: > Here are my old instructions (I deleted them when I started using Apple's > libraries, but the wayback machine saves the day): Thanks Russell -- this is helpful. A few comments: > • If you plan to redistribute matplotlib, delete (or temporarily > move) the dynamic library so matplotlib statically links to libpng: > % sudo rm /usr/local/lib/libpng*.dylib I've found that passing --disable-shared works to prevent the dylibs from being built at all. At least with libpng. > • To check if a library is universal, run "file" on it, e.g.: > % file /usr/local/lib/libpng*.a this doesn't work for me on *.a files -- though it does on dylibs > • Before building, you may wish to modify > include/freetype/configure/ftoption.h to enable hinting: > • uncomment: #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER > • perhaps comment out: #define > TT_CONFIG_OPTION_UNPATENTED_HINTING handy to know. Thanks, -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 [email protected] -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] OS-X binaries?
Are there recent binaries for OS-X anywhere? There don't seem to be any for recent releases on the MPL download page. I know we had a discussion about this a whole back, but don't remember the outcome. But I hope we'll continue to put them up-- macports and friends really aren't the best solutions for everyone. Chris -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Kivy backend
On Mar 13, 2015, at 12:50 PM, Cyrille Rossant wrote: > Exactly. Note that pushing data on the GPU is not that slow: No -- and something has to be pushed to the video card at some point anyway. But my experience is that if you need to push the data to the CPU, that pretty much overwhelms the advantages you get by rendering on the GPU. And OpenGL only supports simple primitives -- so it's substantially more a pain to do something as sole as render a filled polygon, let alone a spline. And yes, back In the day, it was faster to render on the video card, but CPUs have gotten a lot faster, and memory busses not so much. But whatever, I think we all agree that pushing the transformations to the GPU is the big win. -CHB > in one > second, you can send hundreds of millions of points on a modern GPU. > However it would be a bit slow to send large amounts of data at every > frame. > > GPU-based transformations are extremely fast, and you have full > control on how they're implemented; in the end, it's just arbitrary C > code that runs on the GPU on a per-vertex or per-pixel basis. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Cairo backends and OpenGL use
MPL does not have a backend that used “real” GPU rendering. And it’s very hard to make one, due to the really low level nature of OpenGL and similar APIs, and MPL’s rendering model. You might try VisPy — it was designed for OpenGL from the start. -CHB Sent from my iPhone On Jul 5, 2018, at 5:37 AM, Francesco Faccenda wrote: Dear all, I am writing to you because of an issue regarding the use of OpenGL in cairo backends from matplotlib. As I set a cairo backend with the instruction matplotlib.Use(“WXCairo”), there is evidence that the graphic computation is not being carried out by the graphic card. Since the significative amount of plotted data, the chart are heavy and slow when the user is interacting with them, so a graphic acceleration would be really appreciated. As a side note, I am embedding matplotlib canvas on wxPython stages, that’s why I choose WXCairo as backend, at first. However, setting other backends (GTKCario, TKCairo, Qt4Cairo, Qt5Cairo etc) while still using wx, still provides a working code without any errors, even if the graphic card is still not exploited. Is this an actual malfunction or am I missing something? What should I do to run matplotlib graphic computation on a graphic card? Thank you in advance. Best regards, Francesco Faccenda -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
