Re: [matplotlib-devel] 0.99.1 and the setup.cfg file
John Hunter writes: > > On Wed, Sep 23, 2009 at 8:47 AM, Lev Givon wrote: > > contain a setup.cfg file: > > > > $ tar zft matplotlib-0.99.1.tar.gz |grep setup.cfg > > matplotlib-0.99.1/setup.cfg > > matplotlib-0.99.1/setup.cfg.template > > It seems to depend on which mirror you get the file from. From Voxel, > I see setup.cfg but from "German Research Network (Berlin, Germany) " > I do not see it. We may just need time for the mirrors to update. I > probably should have used a different file name... John Hunter writes: > > On Wed, Sep 23, 2009 at 8:47 AM, Lev Givon wrote: > > contain a setup.cfg file: > > > > $ tar zft matplotlib-0.99.1.tar.gz |grep setup.cfg > > matplotlib-0.99.1/setup.cfg > > matplotlib-0.99.1/setup.cfg.template > > It seems to depend on which mirror you get the file from. From Voxel, > I see setup.cfg but from "German Research Network (Berlin, Germany) " > I do not see it. We may just need time for the mirrors to update. I > probably should have used a different file name... I also find setup.cfg in 0.99.1.1.tar.gz, and had to delete it to begin building: $ wget http://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib- 0.99.1/matplotlib-0.99.1.1.tar.gz?use_mirror=kent ... 20:44:41 (2.11 MB/s) - `matplotlib-0.99.1.1.tar.gz' saved [11905737/11905737] $ tar xf matplotlib-0.99.1.1.tar.gz $ cd matplotlib-0.99.1.1 $ ls setup.cfg setup.cfg Chris -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Building matplotlib 0.99.1.1: cannot find -ltk8.5 (whereas 0.91.4 works)
Hi, I posted this same message to matplotlib-users a couple of days ago, but now I realize that this list is the more appropriate place. I'm having trouble building matplotlib 0.99.1.1 (transcript below). I'm using copies of Python (2.5.1) and Tcl/Tk (8.5.5) that I have built myself, and that are apparently working fine. I can use this exact procedure to build 0.91.4 without any problems. Any suggestions would be greatly appreciated - thanks! Chris $ cd matplotlib-0.99.1.1 $ env PREFIX=/a/b/ LD_LIBRARY_PATH=/a/b/lib /a/b/bin/python setup.py build BUILDING MATPLOTLIB matplotlib: 0.99.1.1 python: 2.5.1 (r251:54863, Feb 5 2009, 13:11:08) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] platform: linux2 REQUIRED DEPENDENCIES numpy: 1.2.1 freetype2: 9.10.3 OPTIONAL BACKEND DEPENDENCIES libpng: 1.2.10 Tkinter: Tkinter: 50704, Tk: 8.5, Tcl: 8.5 Gtk+: no * Building for Gtk+ requires pygtk; you must be able * to "import gtk" in your build/install environment Mac OS X native: no Qt: no Qt4: no Cairo: no OPTIONAL DATE/TIMEZONE DEPENDENCIES datetime: present, version unknown dateutil: matplotlib will provide pytz: matplotlib will provide adding pytz OPTIONAL USETEX DEPENDENCIES dvipng: 1.5 ghostscript: 8.15.2 latex: 3.141592 pdftops: 3.00 [Edit setup.cfg to suppress the above messages] pymods ['pylab'] packages ['matplotlib', 'matplotlib.backends', 'matplotlib.projections', 'mpl_toolkits', 'mpl_toolkits.mplot3d', 'mpl_too\ lkits.axes_grid', 'matplotlib.sphinxext', 'matplotlib.numerix', 'matplotlib.numerix.mlab', 'matplotlib.numerix.ma', 'matp\ lotlib.numerix.linear_algebra', 'matplotlib.numerix.random_array', 'matplotlib.numerix.fft', 'matplotlib.delaunay', 'pytz\ ', 'dateutil', 'dateutil/zoneinfo'] running build running build_py copying lib/matplotlib/mpl-data/matplotlibrc -> build/lib.linux-i686-2.5/matplotlib/mpl-data copying lib/matplotlib/mpl-data/matplotlib.conf -> build/lib.linux-i686-2.5/matplotlib/mpl-data running build_ext building 'matplotlib.backends._tkagg' extension g++ -pthread -shared build/temp.linux-i686-2.5/src/agg_py_transforms.o build/temp.linux-i686-2.5/src/_tkagg.o build/temp.\ linux-i686-2.5/CXX/cxx_extensions.o build/temp.linux-i686-2.5/CXX/cxxsupport.o build/temp.linux-i686-2.5/CXX/IndirectPyth\ onInterface.o build/temp.linux-i686-2.5/CXX/cxxextensions.o -L/usr/lib -L/usr/lib -L/usr/local/lib -L/usr/lib -L/usr/lib6\ 4 -L/usr/local/lib -L/usr/lib -L/usr/lib64 -ltk8.5 -ltcl8.5 -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o build/lib.linux-i\ 686-2.5/matplotlib/backends/_tkagg.so /usr/bin/ld: cannot find -ltk8.5 collect2: ld returned 1 exit status error: command 'g++' failed with exit status 1 make: *** [matplotlib] Error 1 $ ls /a/b/lib/*tk* lib/libtk8.5.so lib/libtkstub8.5.a lib/tkConfig.sh ... -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building matplotlib 0.99.1.1 : cannot find -ltk8.5 (whereas 0.91.4 works )
Chris writes: > > Hi, > > I posted this same message to matplotlib-users a couple of days ago, but now I > realize that this list is the more appropriate place. > > I'm having trouble building matplotlib 0.99.1.1 (transcript below). > > I'm using copies of Python (2.5.1) and Tcl/Tk (8.5.5) that I have > built myself, and that are apparently working fine. I can use this > exact procedure to build 0.91.4 without any problems. > > Any suggestions would be greatly appreciated - thanks! > > Chris > > $ cd matplotlib-0.99.1.1 > $ env PREFIX=/a/b/ LD_LIBRARY_PATH=/a/b/lib /a/b/bin/python setup.py build I'm not sure what changed in matplotlib between 0.91.4 and 0.99.1.1, but the procedure below seems to work for me: $ tar -xzf matplotlib-0.99.1.1.tar.gz $ cd matplotlib-0.99.1.1/ $ rm setup.cfg $ /a/b/bin/python setup.py build_ext -L$/a/b/lib/ $ env PREFIX=/a/b/ LD_LIBRARY_PATH=/a/b/lib /a/b/bin/python setup.py build Chris -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New doc update
"John Hunter" <[EMAIL PROTECTED]> writes: > On Wed, Oct 15, 2008 at 8:18 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > The new stylesheet for the docs looks great, John! > > I just ripped this off hook-line-and-sinker from the sphinx docs, and > added the few css bits you created earlier. They do look nice :-) Indeed they do. http://matplotlib.sourceforge.net/doc/html/index.html links to http://matplotlib.sourceforge.net/doc/html/goals.html which doesn't seem to exist yet. I guess this is temporary, but thought it worth pointing out. Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] using new in axes.hist
John Hunter <[EMAIL PROTECTED]> writes: > I think the version check is a good idea, so people won't get the > annoying warning. Could you add this? > > Sent from my iPhone > > On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <[EMAIL PROTECTED]> wrote: > > > I'm currently using numpy 1.1.1 and np.histogram behave differently > > depending on the "new" value. > > ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that > > this different behavior is still there. > > So, as far as we're going to support numpy 1.1 and later, we may > > better not to drop the "new" silently. Debian lenny (which is currently in freeze and will be the next stable) has numpy 1.1 at present. It is possible that the package maintainers will try to get a later version in - but you should check before relying on it. Chris -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errors building docs
Michael Droettboom writes: > Darren Dale wrote: > > I am seeing some errors when I build the docs, including import errors > > for nonexistent date_support and basic_units modules, and: > I added the ability for explicitly setting sys.path so that modules in > the same directory as an example would be importable. It looks likes > that has somehow broken again. I'll look into it. > > > > Most importantly: > > > > copying static files... > > Exception occurred: > > File "/usr/lib/python2.5/shutil.py", line 165, in rmtree > > names = os.listdir(path) > > OSError: [Errno 2] No such file or directory: > > '/home/darren/src/matplotlib/doc/build/html/_static/plot_directive' > > The full traceback has been saved in /tmp/sphinx-err-qaZ8fg.log, if > > you want toreport the issue to the author. > > Please also report this if it was a user error, so that a better error > > message can be provided next time. > > Send reports to [email protected] > > <mailto:[email protected]>. Thanks! > > Building HTML failed. > I haven't been able to get to the root of this problem, but an > "svn-clean" in the doc directory always fixes it for me. I get a similar error that I assumed was caused by the docs being generated by the version of matplotlib that is currently installed, rather than the new version that has just been compiled. I know the debian package has a workaround for this. I get: Sphinx v0.5, building html loading pickled environment... not found building [html]: targets for 369 source files that are out of date updating environment: 369 added, 0 changed, 0 removed reading sources... api/afm_api api/api_changes api/artist_api makefig: fullpath=../mpl_examples/pylab_examples/findobj_demo.py, outdir=_static/plot_directive/../mpl_examples/pylab_examples Exception occurred: File "/usr/lib/python2.5/shutil.py", line 46, in copyfile fsrc = open(src, 'rb') IOError: [Errno 2] No such file or directory: '../mpl_examples/pylab_examples/findobj_demo.py' The full traceback has been saved in /tmp/sphinx-err-L8wLV6.log, if you want to report the issue to the author. Please also report this if it was a user error, so that a better error message can be provided next time. Send reports to [email protected]. Thanks! Building HTML failed. There is an examples directory, but no mpl_examples directory. Nb this error is from the 0.98.4 tarfile compiled on debian lenny with the sphinx 0.5 from debian's experimental packages. Chris -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] What would you like to see in a book about Matplotlib?
Note: Posted to matplotlib-devel and debian-science. Sandro, Firstly, good luck with the book. The sort of book I'd buy would explain how to use the combination of matplotlib/ipython/scipy/numpy to analyse data. > - what are you using matplotlib for? I want to use matplotlib/ipython/numpy/scipy for analysis of experimental data - plotting and fitting models to it. Also perhaps simulation of the data. I have also wanted to use matplotlib to plot data as it was acquired - see below. I've not really used matplotlib in anger - but am likely to do so in the future (and it would have been useful during my PhD had it been around then). > - what are the things you like the most of matplotlib, that you want > to give emphasis to? And why? Quality plots. The ability to add TeX labels. I've been keeping an eye on matplotlib for several years - it looks good. I really must spend some time exploring it. > - what are the (basic) things that, when you were beginning to use > matplotlib, you wanted to see grouped up but couldn't find? > - what would you like to see in a book about matplotlib? Start off by reading data from a file, plotting it and fitting a function to that data. Often, several scans are in the same data file. An elegant solution to reading data something like this example would be useful. # Scan: 1 # Time: 18:00 # Temperature: 21 # t data 1 12 2 33 3 14 4 40 5 60 # Scan: 2 # Time: 18:02 # Temperature: 30 # t data 1 22 2 33 3 44 4 55 And so on. Fitting a function to several data sets - with some of the parameters fitted to both sets of data and some not would be useful. > - what are some those advanced feature that made you yell "WOW!!" ? > - what are the things you'd like to explore of matplotlib and never > had time to do? Plotting with related scales Sometimes it is useful to plot related scales on x1 and x2 axes. I've come across this several times in different contexts. In its simplest form, there is a linear relationship between the axes. In a mechanical test, you might want extension on the x1 axis and strain on the x2 axis (for example). Sometimes there is not a linear relationship. For example you might want to plot frequency (or photon energy) on x1 and wavelength on x2. An even more complex example is a Hall-Petch plot: (Yield Stress) = k/sqrt(Grain Size) So plotting 1/Sqrt(Grain Size) on the X1 axis gives a linear plot, but it would be useful to plot the grain size on the X2 scale. ipython and emacs - Suppose I want to write a script to analyse some data (perhaps I want a record of what I've done, or perhaps I'd like to perform the same analysis on several data sets). I'd probably do so in emacs - but it is useful to do some experimentation in ipython - tab completion is particularly useful. I feel there must be a good way to do my experimentation in ipython and save the important bits in emacs - but I've not sat down and worked out an efficient way of doing this. Data aqcuisition and experimental control: - Writing a simple application to acquire data - ideally from multiple sources and plot the data as it is acquired. In my case I wanted to combine mechanical with electrical tests. A couple of interesting articles by G Varoquaux are listed at http://wiki.debian.org/DebianScience/DataAcquisition This is perhaps beyond the scope of the book, but it has come up on the mailing lists a couple of times. The ideal application would have a gui for simple use, but a command line (probably ipython) for more more complex use - perhaps performing a series of tests under different conditions. Some discussion of plotting non gridded 2d data should also be in there. > > Your suggestions are really appreciated :) And wish me good luck! I don't think it is the thrust of your book, but another book I was looking for is "A cookbook of Numerical simulations of classic physics/engineering problems". For use by physicists/engineers who don't want to rewrite things from scratch. Good luck. Chris -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] What would you like to see in a book about Matplotlib?
On Sun, Feb 01, 2009 at 11:59:06PM +0100, Sandro Tosi wrote: > Hi Chris, > thanks for your reply, helpful as usual :) > > On Fri, Jan 30, 2009 at 18:59, Chris Walker > wrote: > > Firstly, good luck with the book. > > cheers :) > > > The sort of book I'd buy would explain how to use the combination of > > matplotlib/ipython/scipy/numpy to analyse data. > > Sadly, that would not the book I'll write :( The editor wanted to > target another audience for the book: experienced python developers, > with no knowledge of matplotlib; so an introductionary book, that will > show even how to integrate mpl on GTK/WX application and on the web. > > I pushed to have something about science, and a chapter will be about > that, but I need your (all) inputs, because my science days are long > back in the past ;) Sure - though anyone wanting to use matplotlib is likely to be acquiring, manipulating and then plotting data. > > >> - what are the (basic) things that, when you were beginning to use > >> matplotlib, you wanted to see grouped up but couldn't find? > >> - what would you like to see in a book about matplotlib? > > > > Start off by reading data from a file, plotting it and fitting a > > function to that data. > > That sounds something that could land in the "science" chapter. Indeed. > > > Plotting with related scales > > > > > > Sometimes it is useful to plot related scales on x1 and x2 axes. I've > > come across this several times in different contexts. In its simplest > > form, there is a linear relationship between the axes. In a mechanical > > test, you might want extension on the x1 axis and strain on the x2 axis > > (for example). > > > > Sometimes there is not a linear relationship. For example you might > > want to plot frequency (or photon energy) on x1 and wavelength on x2. > > > > An even more complex example is a Hall-Petch plot: > > > > (Yield Stress) = k/sqrt(Grain Size) > > > > So plotting 1/Sqrt(Grain Size) on the X1 axis gives a linear > > plot, but it would be useful to plot the grain size on the X2 scale. > > Err, I think I lost you ;) Figure 3b/3c at http://dcwww.camd.dtu.dk/~schiotz/papers/risoesymp/html/node3.html is an example - note that the y2 scale is not linear. > > What you want is 2 plots on the same figure? so not 2 Ys for the same > X 2 scales on the same figure, yes. > (let's say X is time, and Y1 is stock price variation, and Y2 is the > percentage change), you want X1-Y1 (let's say on the bottom-left) and > X2-Y2 (on the upper-right): did I get you? Exactly. http://en.wikipedia.org/wiki/File:Body_mass_index_chart.svg is the sort of thing I had in mind. > > > ipython and emacs > > - > > > > Suppose I want to write a script to analyse some data (perhaps I want > > a record of what I've done, or perhaps I'd like to perform the same > > analysis on several data sets). I'd probably do so in emacs - but it > > is useful to do some experimentation in ipython - tab completion is > > particularly useful. I feel there must be a good way to do my > > experimentation in ipython and save the important bits in emacs - but > > I've not sat down and worked out an efficient way of doing this. > > I think the preferred way to do so it using ipython, and for now I > plan only to show it on the book. Whether or not this make it into the book, I'm interested in how people do this. Surely you don't write your application using just ipython do you? > > > Data aqcuisition and experimental control: > > - > > > > Writing a simple application to acquire data - ideally from multiple > > sources and plot the data as it is acquired. In my case I wanted to > > combine mechanical with electrical tests. A couple of interesting > > articles by G Varoquaux are listed at > > http://wiki.debian.org/DebianScience/DataAcquisition > > > > This is perhaps beyond the scope of the book, but it has come up on > > the mailing lists a couple of times. The ideal application would have > > a gui for simple use, but a command line (probably ipython) for more > > more complex use - perhaps performing a series of tests under > > different conditions. > > I thought about an example for this already! :) Excellent. > I thought to develop a > sample application for GTK/WX that display some system value (like cpu > usage or so, in this way everyone can run the example) plotting the > information as it comes (for
[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
[matplotlib-devel] basemap not working with GEOS 3.1
Hi, I get a Topology Exception with GEOS 3.1: import mpl_toolkits.basemap as bm print "GEOS version: ", bm._geoslib.__geos_version__ print "basemap version: ", bm.__version__ m = bm.Basemap(width=1200,height=800, \ resolution='l',projection='laea',\ lat_0=55,lon_0=175.) output: GEOS version: 3.1.0-CAPI-1.5.0 basemap version: 0.99.3 GEOS_ERROR: TopologyException: found non-noded intersection between 3.03025e+06 1.45852e+07, 3.02518e+06 1.45831e+07 and 3.02379e+06 1.45823e+07, 3.02937e+06 1.45857e+07 3.02519e+06 1.45831e+07 Segmentation fault Any solutions? cheers Chris -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] basemap not working with GEOS 3.1
On Mon, Jul 27, 2009 at 8:14 PM, Jeff Whitaker wrote: > Chris Petrich wrote: >> >> Hi, >> >> I get a Topology Exception with GEOS 3.1: >> >> import mpl_toolkits.basemap as bm >> print "GEOS version: ", bm._geoslib.__geos_version__ >> print "basemap version: ", bm.__version__ >> >> m = bm.Basemap(width=1200,height=800, \ >> resolution='l',projection='laea',\ >> lat_0=55,lon_0=175.) >> >> output: >> >> GEOS version: 3.1.0-CAPI-1.5.0 >> basemap version: 0.99.3 >> GEOS_ERROR: TopologyException: found non-noded intersection between >> 3.03025e+06 1.45852e+07, 3.02518e+06 1.45831e+07 and 3.02379e+06 >> 1.45823e+07, 3.02937e+06 1.45857e+07 3.02519e+06 1.45831e+07 >> Segmentation fault >> >> >> Any solutions? >> cheers >> >> Chris >> >> > > Chris: This usually happens when you build mix different versions of geos, > i.e. build with the 3.1 lib but the 2.2.3 headers, or link with the 3.1 > shared lib and then have it pick up the 2.2.3 shared lib at run time. Do > you have two versions of geos on your system? If so, make sure basemap is > only finding one of them, both at build time and run time. > > -Jeff > Thanks, Jeff, that was it. I had both geos 3.1 and 2.2.3 installed in /usr. basemap found 3.1 during build/installation while _libgeos tried to import 2.2.3 at run time (this became obvious after I removed the 2.2.3 libraries). Removed libgeos 2.2.3 and "python setup.py install"-ed basemap 0.99.3 from a fresh tar ball, works like a charm now! I appreciate the effort you put into developing basemap. The result is awesome. cheers Chris -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
Re: [matplotlib-devel] Contributed example
I agree, very instructional example. As for the width of the tick lines, line 78 line.set_linewidth(1) should probably read line.set_markeredgewidth(1) though. Chris > Date: Fri, 8 Jul 2011 16:18:52 -0600 > From: G?khan Sever > Subject: Re: [matplotlib-devel] Contributed example > To: Nicolas Rougier > Cc: matplotlib development list > > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > I think this illustration deserves its places amongst the mpl gallery > --probably somewhere towards the very beginning. > > Thanks for the well documented code Nicolas. > On Fri, Jul 8, 2011 at 2:09 AM, Nicolas Rougier > wrote: > >> >> >> Hi, >> >> >> I've been playing with matplotlib to check if it can produce graphics like: >> >> >> http://www.thebuzzmedia.com/wp-content/uploads/2010/03/anandtech-nvidia-geforce-480-ati-benchmark2.png >> >> >> Here is the result: >> http://www.loria.fr/~rougier/tmp/benchmark.png >> >> and the script (as attachment) >> >> I do not know if it's worth adding it to examples ? >> >> >> >> Nicolas >> >> >> >> >> -- >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of 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-d2d-c2 >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > > > -- > G?khan > -- next part -- > An HTML attachment was scrubbed... > > -- > > -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of 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-d2d-c2 > > -- > > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > End of Matplotlib-devel Digest, Vol 62, Issue 3 > *** -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of 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-d2d-c2 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Home page text
John Hunter <[EMAIL PROTECTED]> writes: > >>>>> "Charlie" == Charlie Moad <[EMAIL PROTECTED]> writes: > > Charlie> I think this needs some clean-up: "The latest > Charlie> matplotlib-0.87.7 for windows was compiled with numpy 1.0 > Charlie> final. Please make sure you are not using the latest > Charlie> numpy-1.0." > > Oops -- done. Thanks. On which subject, "What's new" starts: What's new in matplotlib 0.83 rather than the 0.87.7 Chris - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ 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] SPAM on matplotlib WIKI topical software
Jeez ... OK, a second try without mentioning the word. (to evade the spam filters). Browsing the matplotlib wiki topical software page tonight I stumbled across a link to "that drug that men can use when they need some help below the waistline starts with the letter V" placed next to a topic link. A page search revealed many more of the same. I hope whoever manages this page can clean it up. (btw - thanks for an awesome python package). cya - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] 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
[matplotlib-devel] Classic Toolbar in backend_gtk out of sync with API changes
The old "classic" toolbar is out of sync with some API updates. This is what I get when running embedding_in_gtk2.py (after tweaking to use the classic toolbar) Traceback (most recent call last): File "embedding_in_gtk2.py", line 39, in toolbar = NavigationToolbar(canvas, win) File "c:\python25\lib\site-packages\matplotlib\backends\backend_gtk.py", line 746, in __init__ default_type=self.canvas.get_default_filetype()) TypeError: __init__() got an unexpected keyword argument 'default_type' and the diffs, after what seemed like the appropriate fixing: for 0.91.2 0 % diff be_gtk_912.py be_gtk_912-fixd.py 738,739c738,739 < formats=self.canvas.get_supported_filetypes(), < default_type=self.canvas.get_default_filetype()) --- > filetypes=self.canvas.get_supported_filetypes(), > default_filetype=self.canvas.get_default_filetype()) for 0.98.0 0 % diff be_gtk_980.py be_gtk_980-fixd.py 745,746c745,746 < formats=self.canvas.get_supported_filetypes(), < default_type=self.canvas.get_default_filetype()) --- > filetypes=self.canvas.get_supported_filetypes(), > default_filetype=self.canvas.get_default_filetype()) Cheers Chris Fuller University of Minnesota - 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] AttributeError: 'module' object has no attribute 'GraphicsContext'
"John Hunter" <[EMAIL PROTECTED]> writes: > On Thu, Jun 12, 2008 at 3:38 PM, Ken McIvor <[EMAIL PROTECTED]> wrote: > > On Jun 12, 2008, at 3:22 PM, John Hunter wrote: > >> > >> If some wx guru sees an easy fix here, by all means add it. > > > > Not to imply that I'm a guru, but I'll try to look into it this evening. > > Well, you are a guru to us :-) > > >> Otherwise, we should decide on a minimum wxpython version for the > >> trunk and raise an exception. > > > > I'm always in favor of ensuring that MPL can run on Debian Stable without > > too much pain and suffering. Doing so would entail supporting wxPython 2.6. > > It looks like debian stable is now packaging numpy 1.01. Am I reading > this right? > > http://packages.debian.org/search?keywords=python-numpy Yes, that's right. 1.1 is likely to be in the next debian release. > > I think it is reasonable for folks who want the latest mpl to be > willing to get the latest numpy. For the GUI toolkits, given how hard > they are to build, your suggestion of targeting debian stable may be > more reasonable, but supporting multiple GUI versions has always been > a pain since we definitely want to support the most recent. > > wxpython is on 2.8.7 and stable is still 2.6? pygtk is at 2.10 and > debian stable is at 2.6. matplotlib is at 0.98 and debian stable is > at 0.87 (Oct 2006 release). September is the target date for the next release of debian according to the release schedule at: http://lists.debian.org/debian-devel-announce/2008/06/msg0.html The packages currently in debian are: Distribution(codename) Package StableTesting Unstable (etch)(lenny) (sid) python-matplotlib 0.87.7-0.30.91.2-20.91.2-2 python-wxversion 2.6.3.2.1.5 2.6.3.2.2-2 2.6.3.2.2-2 python-gtk2 2.8.6-8 2.12.1-12.12.1-6 python-numpy 1:1.0.1-1 1:1.0.4-8 1:1.1.0-1 python2.4.4-2 2.5.2-1 2.5.2-1 There is also python-wxversion (2.8.7.1-0.1) in experimental. Packages are uploaded to unstable. If after a period of time (usually 10 days) there are no major bugs found, and their dependencies can be met by packages in testing, they migrate to testing. For more details http://www.debian.org/releases/testing/ and http://www.debian.org/devel/testing Thus packages in "testing" will be in the next stable release (barring show stopping bugs), packages in "unstable" will probably be in the next stable release, and packages in "experimental" may or may not be in the next stable release. Thus I'd expect python-numpy 1.1.0 to make the next release, but python-wxversion (2.8.7.1) is looking a bit marginal. > So if we want to support stable, *and* > the latest releases, we've got a lot of ongoing compatibility work to > do. For backend maintainers willing to do it, I think that will be > good. But I am hesitant to target such a slow moving repository as a > requirement. Would the next debian release (lenny) be a better target for development versions of matplotlib? What version of matplotlib do you want to go into the next debian release? Chris - 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] AttributeError: 'module' object has no attribute 'GraphicsContext'
"John Hunter" <[EMAIL PROTECTED]> writes: > On Fri, Jun 13, 2008 at 9:25 AM, Chris Walker > <[EMAIL PROTECTED]> wrote: > > >> So if we want to support stable, *and* > >> the latest releases, we've got a lot of ongoing compatibility work to > >> do. For backend maintainers willing to do it, I think that will be > >> good. But I am hesitant to target such a slow moving repository as a > >> requirement. > > > > Would the next debian release (lenny) be a better target for > > development versions of matplotlib? > > > > What version of matplotlib do you want to go into the next debian release? > > Hi Chris -- thanks for all the information. Pleasure, Hope it was useful, but please note I don't speak for the Debian Matplotlib maintainers. There are some things I need to clarify though. > Since 0.98 requires numpy > 1.1, 0.98.1 (a bugfix release slated for next week or the week after) > should be in unstable and 0.91.4 (again a bugfix scheduled for next > week or the week after) should be in testing Ah, I think you may have misunderstood how debian stable/testing/unstable works. A grossly oversimplified view[1] is as follows. 1) A new version of the package is uploaded to sid (unstable) 2) When the package has been in sid (unstable) for 10 days, it is a candidate for moving to lenny (testing). when they can do so without breaking other packages lenny (testing). 3) Eventually, lenny is released as the stable distribution, and you are stuck with it for a year or two (except security or dataloss bugs). so it sounds like 0.98.x should be what is uploaded to unstable (from where it will migrate to testing). > and 0.91.2 should be in > stable. The version in etch (stable) is only likely to be upgraded (from 0.87.7-0.3) if there are major bugs (such as security problems or data loss issues). See http://www.debian.org/security/ > I find this a bit conservative, since I think numpy 1.1 > should be in testing It was only uploaded 3 days ago, so in theory could migrate in 7 days time. > along with matplotlib 0.98.1, http://packages.qa.debian.org/m/matplotlib.html gives debian package information on matplotlib - including which versions are in stable,testing and unstable. Hopefully 0.98.0 or 0.98.1 packages will be uploaded soon. If not, then giving the maintainers a push to ensure they are in the next debian stable would be a good idea. > but that is > apparently how debian does it. > Hopefully that is now slightly clearer. Chris [1] Packages can migrate more quickly if they contain urgent bug fixes http://www.debian.org/ and specifically http://www.debian.org/devel/testing contains more accurate information. - 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] upcoming release
"Sandro Tosi" <[EMAIL PROTECTED]> writes: > On Mon, Jun 23, 2008 at 13:48, Sandro Tosi <[EMAIL PROTECTED]> wrote: > > On Mon, Jun 23, 2008 at 04:43, Charles Moad <[EMAIL PROTECTED]> wrote: > >> The releases and builds are up. Please test them out, and I'll leave the > >> announcements to you, John. > > > > I just downloaded it (MD5Sum: 1f673f82eb4f7422c1e45545f8e083d4) and I > > plan to upgrade the package in Debian this evening. > > mpl 0.98.1 has just been uploaded in unstable (tomorrow will be > available on debian mirrors hosts). I've installed this (in a chroot). All the wx examples I've tried seem fail at the line: from wx import * eg: [EMAIL PROTECTED]:/usr/share/doc/python-matplotlib-doc/examples/user_interfaces$ ./embedding_in_wx.py Traceback (most recent call last): File "./embedding_in_wx.py", line 45, in from wx import * AttributeError: 'module' object has no attribute '__DocFilter' This must be a bug in the Debian package providing wx (which I ought to report). Is it good practice though? > Thanks for the support, Indeed - and thanks for packaging it so rapidly. Chris - 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] 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
[matplotlib-devel] Minor typo in docs
The patch below fixes a minor typo in the documentation. Chris [EMAIL PROTECTED]:~/mydeb/mpl-svn/matplotlib/trunk/matplotlib/lib/matplotlib$ svn diff afm.py Index: afm.py === --- afm.py (revision 5683) +++ afm.py (working copy) @@ -4,7 +4,7 @@ than mine) I decided not to go with them because either they were either - 1) copyighted or used a non-BSD compatible license + 1) copyrighted or used a non-BSD compatible license 2) had too many dependencies and I wanted a free standing lib - 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
[matplotlib-devel] Latex Documentation build errors - possibly scale_docs
When building the docs using make.py in the doc directory, Latex hangs.
I'm using the svn version of the docs on a debian system with
matplotlib 0.98.1 and sphinx 0.4.
Latex hangs ( but can be made to continue by pressing return) at the
following point:
Underfull \hbox (badness 1) in paragraph at lines 17819--17822
[]\T1/txr/m/n/10.95 A dic-tio-nary with key-word ar-gu-ments ac-cepted by the
[181] [182]
Underfull \hbox (badness 1) in paragraph at lines 18251--18254
[][][]\T1/txtt/m/n/10.95 semilogx()[][] \T1/txr/m/n/10.95 sup-ports all the key
-word ar-gu-ments of [][]\T1/txtt/m/n/10.95 plot()[][] \T1/txr/m/n/10.95 and
[183]
Overfull \hbox (92.42264pt too wide) in paragraph at lines 18443--18444
[][]
Underfull \hbox (badness 1) in paragraph at lines 18458--18461
[][][]\T1/txtt/m/n/10.95 semilogy()[][] \T1/txr/m/n/10.95 sup-ports all the key
-word ar-gu-ments of \T1/txtt/m/n/10.95 plot() \T1/txr/m/n/10.95 and
[184]
Overfull \hbox (92.42264pt too wide) in paragraph at lines 18650--18651
[][]
[185]
Overfull \hbox (92.41579pt too wide) in paragraph at lines 18760--18761
[][]
[186]
Overfull \hbox (92.45047pt too wide) in paragraph at lines 19150--19151
[][]
[187]
Overfull \hbox (92.45047pt too wide) in paragraph at lines 19351--19352
[][]
[188] [189]
! LaTeX Error: Too deeply nested.
See the LaTeX manual or LaTeX Companion for explanation.
Type H for immediate help.
...
l.19440 [EMAIL PROTECTED]
?
This corresponds to the following latex code where a second
\begin{quote} is opened before closing the first. Commenting out one
of these \begin{quote} (and the corresponding \end{quote} fixes the
problem:
Set the scaling of the y-axis: `linear' | `log' | `symlog'
ACCEPTS: {[}'linear' | `log' | `symlog'{]}
Different kwargs are accepted, depending on the scale:
`linear'
\begin{quote}
`log'
\begin{quote}
\begin{description}
\item[\emph{basex}/\emph{basey}:]
The base of the logarithm
\item[\emph{subsx}/\emph{subsy}:]
Where to place the subticks between each major tick.
Should be a sequence of integers. For example, in a log10
scale:
This latex seems to be generated by the following lines in axes.py -
but I haven't worked out how to fix it.
def set_yscale(self, value, **kwargs):
"""
call signature::
set_yscale(value)
Set the scaling of the y-axis: %(scale)s
ACCEPTS: [%(scale)s]
Different kwargs are accepted, depending on the scale:
%(scale_docs)s
"""
self.yaxis.set_scale(value, **kwargs)
self.autoscale_view()
self._update_transScale()
set_yscale.__doc__ = cbook.dedent(set_yscale.__doc__) % {
'scale': ' | '.join([repr(x) for x in mscale.get_scale_names()]),
'scale_docs': mscale.get_scale_docs().strip()}
Chris
-
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] preparing for 0.98.3 and 0.91.5
"John Hunter" <[EMAIL PROTECTED]> writes: > On Sun, Jul 27, 2008 at 12:39 PM, Mikhail Gusarov > <[EMAIL PROTECTED]> wrote: > > Twas brillig at 12:30:39 27.07.2008 UTC-05 when [EMAIL PROTECTED] did gyre > > and gimble: > > > > JH> Mikhail, if you are so inclined and there is still time, you may > > JH> want to see if Georg wants to put out another point release that > > JH> fixes this problem, and push the fix into the debian pipeline. > > > > Well, freeze just was declared, so I'll need to request an exception for > > sphinx, as well as you for mpl :-| > > > > It will help if you file a RC bug for sphinx :) > > I'll be happy to, but should I wait until there is actually a sphinx > release out with the bugfix in it? No, don't wait. Debian packages can included patches if necessary. Pointing at the fix in svn (in the bug report) would be helpful. Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] a patch to have a correct baseline when usetex=True
"Jae-Joon Lee" <[EMAIL PROTECTED]> writes:
> Here is a patch which uses a preview package. It uses a "showbox"
> option in the preview package, with a slight tweak (this only patches
> the texmanager.py. You still need to apply the agg backend patch in my
> previous post). It would be good if this patch will be accepted, but
> the extra requirement of the preview package may need some dicussion.
> Although it seems that the preview package is commonly found with a
> TeX installation, I guess it is not part of the major TeX distribution
> (e.g. tetex, tex-live) yet. One way would be to make it as an optional
> feature.
FWIW, Debian provides preview.sty in the binary package
preview-latex-style (generated from the source package auctex).
Chris
>
>
>
> On Fri, Aug 29, 2008 at 12:04 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
> > Thanks,
> >
> > I quickly went through the code of the pngmath.py, and it seems that
> > the depth(descent) of the dvi file is reported by "dvipng" (but the
> > preview package must be used in the tex file for this to work
> > correctly). Therefore, with this method, we need to run dvipng even if
> > we use ps of pdf backend. Although this seems fine to me, I'll see if
> > I can extract the depth of the text without running the dvipng.
> >
> > Regards,
> >
> > -JJ
> >
> >
> >
> >
> > On Fri, Aug 29, 2008 at 7:59 AM, Michael Droettboom <[EMAIL PROTECTED]>
> > wrote:
> >> Sphinx contains one way to do this in its new "pngmath" extension. It uses
> >> the LaTeX package "preview" which does all of this magic internally. And I
> >> believe it's a little more general. If I recall, the approach you're
> >> taking
> >> won't work with some LaTeX constructs such as:
> >>
> >> \begin{align}
> >>x & = 2
> >>y & = 2
> >> \end{align}
> >>
> >> Plus, Sphinx is BSD-licensed, so it should be fine to copy-and-paste
> >> whatever code is necessary.
> >>
> >> Of course, latex-preview is required to be installed, but I think it's a
> >> pretty common package.
> >>
> >> See here:
> >>
> >> http://svn.python.org/projects/doctools/trunk/sphinx/ext/pngmath.py
> >>
> >> Cheers,
> >> Mike
> >>
> >> Jae-Joon Lee wrote:
> >>>
> >>> On Thu, Aug 28, 2008 at 4:18 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> >>>
> >>>>
> >>>> On Thu, Aug 28, 2008 at 2:57 PM, Jae-Joon Lee <[EMAIL PROTECTED]>
> >>>> wrote:
> >>>>
> >>>>
> >>>>>
> >>>>> First of all, I borrowed this idea from the PyX which is in GPL.
> >>>>> Although there is little of copying, other than the basic idea, I'm
> >>>>> not 100% sure if this could be BSD-compatible.
> >>>>>
> >>>>
> >>>> I think it is fine to borrow the idea; what we need to do is a clean
> >>>> room implementation with no copying. You can best answer that, so if
> >>>> you tell us your patch is cleanly implemented, we can accept it.
> >>>>
> >>>> JDH
> >>>>
> >>>>
> >>>
> >>> Thanks for the response.
> >>>
> >>> Well, the only part I borrowed from PyX is TeX related commands they
> >>> use (there is not much of implementation as far as TeX-related code is
> >>> concerned). From their code, I learned the meaning and usage of the
> >>> following TeX commands
> >>>
> >>> \newbox
> >>> \setbox
> >>> \immediate\write16
> >>>
> >>> And I used the same TeX commands in my code.
> >>> But I personally think this is not a (code) copy.
> >>>
> >>> Other than this, the code is clean.
> >>> Regards,
> >>>
> >>> -JJ
> >>>
> >>> -
> >>> This SF.Net email is sponsored by the Moblin Your Move Developer's
> >>> challenge
> >>> Build the coolest Linux based applications with Moblin SDK & win great
> >>> prizes
> >>> Grand prize is a trip for two to an Open Source event anywhere in the
> >>> world
> >>> http://moblin-contest.org/redirect.php?banner_id=
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] Plot or Not: voting to create better matplotlibrc
Hi, I thought I'd chime in on this discussion -- Adrian Price-Whelan and I put together plotornot during the SciPy sprints. I wouldn't advocate for linking to plotornot from matplotlib -- the idea is semi tongue-in-cheek, and meant to gauge to what extent there is consensus about plot styles. It's not set up to teach about rcParams, nor does it systematically explore all possible styles. The votes (>10K, last I checked) are saved, and eventually Adrian or I will look over the feedback and report back to you all. I haven't had time for that yet. I hope the name didn't *actually* offend anyone. At the risk of sounding unappreciative of MPL (which I love, and rely upon daily), I must admit I was disheartened after hearing the MPL devs at SciPy discuss styles and defaults. I understand that you don't want to change the default styles without a clearly better alternative. I also understand that, to some extent, style preferences are subjective. However, there seemed to be quite a bit of resistance to the idea that MPL defaults should change *at all.* Even if you ignore the subjective component of this (which I think is a mistake, since in my experience there is broad consensus that projects like ggplot2, d3, tableau, and spotfire do a "better" job than MPL at styling), there are some well-established visual principles that matplotlib violates. Some of my biggest pet peeves are: 1) The default 'axes.color_cycle' values should be equally visible, with similar luminance values. The current defaults (bgrcmyk) do not have this property -- c and y are harder to see, and thus carry less visual emphasis. A color table like the "Dark2" color brewer table ( http://learnr.files.wordpress.com/2009/04/colours-dark2.png, colorbrewer2.org) is more uniform, and carefully designed for visibility and contrast. 'rgbcmyk' is clearly an arbitrary choice -- why not use a smarter default? 2) The default 'jet' colormap for images has a lot of poor properties (which is even mentioned on the MPL docs at http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at ordering changes in hue (which is bigger -- purple or yellow?), and better at ordering changes in intensity or saturation. A colleague of mine designed a visualization tool for doctors, and found that the rainbow color table had a dramatic negative effect on the effectiveness of the tool (you can watch her TED talk about this at https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is especially frustrating, since it *cannot* be modified via rcParams 3) Some of the defaults violate Tufte principles like minimizing "chart junk." For example, the 'stepfilled' mode for hist is probably better than the default, which draws vertical lines between every bin. Those lines make the histogram noisier -- do they convey any extra information? Again, this can't be tweaked via rcParams. Sorry for being long-winded -- I just want to make the case that this is an important (and not *entirely* subjective) issue. If nothing else, it would be great to see some clear statement about where the MPL devs stand on this issue -- what criteria must be met to consider a change to the defaults? My apologies if such a document already exists somewhere! Cheers, Chris Beaumont On Sat, Jul 20, 2013 at 3:03 PM, < [email protected]> wrote: > Send Matplotlib-devel mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Matplotlib-devel digest..." > > > Today's Topics: > >1. Re: Plot or Not: voting to create better matplotlibrc > (Eric Firing) >2. Re: How to use STIX fonts in matplotlib plots? (Eric Firing) >3. Re: Plot or Not: voting to create better matplotlibrc > (Benjamin Root) >4. Re: How to use STIX fonts in matplotlib plots? (Benjamin Root) > > > -- > > Message: 1 > Date: Sat, 20 Jul 2013 08:20:11 -1000 > From: Eric Firing > Subject: Re: [matplotlib-devel] Plot or Not: voting to create better > matplotlibrc > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2013/07/20 4:18 AM, David P. Sanders wrote: >
Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc
'image.cmap' -- nice! Shows how much I know :)
I don't fully agree with Eric that changing the defaults should be treated
as an API break -- yes, it may irritate a minority of users, but their code
will still run. I'd flip around your argument for the role of rcParams and
customization: the majority user is probably someone who doesn't know much
about rcParams, or all the ways plots can be customized. *That* is the use
case to optimize, not the "legacy" users invested in the current style.
However, default tweaking need not be painful. As has been mentioned, a
first step would be an easier way to change a whole set of rcParams:
something like mpl.set_style('style-name'). As long as one style is
'classic', users can keep the current style for as long as they want. It's
a one line fix, and could even be rcParams-settable.
With such a framework, it would be possible for people to contribute new
styles that ship with MPL, and users could change styles without having to
find (and potentially merge) rcParams files from the web. Finally, people
could nominate that mature styles be made default (you could even assign
version numbers to track the default style as it evolves towards visual
awesomeness)
chris
On Sat, Jul 20, 2013 at 9:07 PM, Eric Firing wrote:
> On 2013/07/20 2:38 PM, David P. Sanders wrote:
> > And this is my problem with 'rc': it brings to mind an arcane config
> > file hidden away somewhere that has a terrible syntax and must not be
> > touched.
> >
> > As Chris and Adrian have emphasized, the point is that we *should* be
> > tweaking away at the parameters all the time.
> > I propose to rename as mpl_params=rcParams
> >
>
> Yes, mpl_params is more descriptive and easy to remember. rcParams is
> ugly, obscure, and archaic. It will have to remain available for a long
> time, but I don't object to changing standard usage to a nicer name.
> There might even be a better name than "mpl_params"--"settings" comes to
> mind, or maybe "style".
>
> As for parameter tweaking: the defaults shipped with mpl should be
> changed only rarely, but we should make it as easy as possible for users
> to customize plots, including coming up with good combinations of style
> parameters. In some cases it makes sense to do this via a matplotlibrc
> file, in other cases it is better to do the parameter setting explicitly
> at the top of a script.
>
> Regarding defaults, note that I said "rarely", not "never".
>
> The whole rc system could use a good review--maybe resulting in lots of
> changes, maybe not--so I welcome the attention you are directing to it.
>
> Eric
>
>
> --
> 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
>
--
Chris Beaumont
Graduate Student
Institute for Astronomy
University of Hawaii at Manoa
2680 Woodlawn Drive
Honolulu, HI 96822
www.ifa.hawaii.edu/~beaumont
--
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] Plot or Not: voting to create better matplotlibrc
I had the same question about opt-out vs opt-in. Personally, I vote for
opt-out. I would like to see each release of MPL have an associated style
(which may be the same as the last release, but maybe not). With Tony's
style PR, users that need constant styles would either put
`style.use('1.3')` in their script, or `style: 1.3` in an rcParams file.
This would then freeze the style FOR-EV-ER (sandlot voice). However, the
default would be `style: latest`, so that the default user benefits from
the community's effort into making the best possible set of defaults. Is
that sufficiently pain-free for people who want future proofing? Or do you
think styles must be opt-in (which, effectively, means that defaults cannot
change).
I'm not sure if I understand what you're getting at re:
approximately_emulate. I'm in favor of two modes for style loading -- some
kind of lazy version that only touches the options explicitly addressed in
the file, and an explicit version that defaults all other options to
something. Thus, explicit loading would guarantee that a style never
changes.
chris
--
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] 1.3.0rc5 tagged
Same with me. I had a stale pyparsing.pyc file in the MPL source directory (presumably from an old MPL version) whose version # was too old. When mpl tried to 'import pyparsing', it found that version, and raised an error. Of course, if I tried "import pyparsing; print pyparsing.__version__" from my home directory, python found a more recent pyparsing. So the error message was a little confusing. I only think this is going to effect people building from the Git source, who have the old pyparsing.pyc file. On Wed, Jul 24, 2013 at 10:45 AM, Benjamin Root wrote: > > > > On Wed, Jul 24, 2013 at 9:39 AM, Michael Droettboom wrote: > >> On 07/23/2013 03:33 PM, Benjamin Root wrote: >> >> Just checked out rc5 from git and did an install, and ran into a >> pyparsing version check issue. >> >> >> What was the issue? Is it that you had 2.0.1 which rc5 still considers >> to be incompatible with Python 2? I'd like to know specifically what >> happened in case there's a deeper issue. >> >> >> > It claimed I didn't meet the minimum pyparsing version needed when I tried > importing matplotlib after installing from source. However, importing > pyparsing on its own yielded a version slightly above the minimum (I forget > the actual numbers). I had also just came from an build of an older > version of matplotlib. > > Ben > > > -- > 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 > > -- Chris Beaumont Graduate Student Institute for Astronomy University of Hawaii at Manoa 2680 Woodlawn Drive Honolulu, HI 96822 www.ifa.hawaii.edu/~beaumont -- 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] MEP19: Continuous integration virtual meeting
I'd like to sit in on this if I'm available. Please keep me posted Cheers, Chris -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Faceted plotting
Pandas has some nice tools to make faceted plots -- small multiples of plots where data is grouped by category ( http://pandas.pydata.org/pandas-docs/stable/rplot.html). However, I think there would be value in having this functionality built into matplotlib. Mainly: 1. Not every dataset lives in a dataframe 2. The pandas library mimics the ggplot interface, and some people would prefer an interface closer to matplotlib 3. Properly implemented, I think a matplotlib facet system would enable a wider variety of faceted plots than the pandas tools. I've taken a stab at this, and came up with an interface that I think has potential. This currently exists as a separate repository at https://github.com/ChrisBeaumont/mplfacet, and an example notebook at http://bit.ly/17u1JzP There two basic ways to use a facet object: Facet(key, data).method() will group one or more data arrays by key, and build a subplot for each group by calling method (which is any axes plot method). Alternatively, for item in Facet(key, data): x, y = item.data item.axes.scatter(x, y) sets up the subplots and groups the data for you, but gives you more freedom to populate each subplot however you like. Is there interest in building this into matplotlib? If so, I would like to polish it up and submit a PR. Cheers, Chris -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Faceted plotting
Hi Damon,
Thanks for your thoughts on how this should fit in with MPLs API. My $0.02:
What would feel more natural is if I could do the following:
> f = Facet(...)
> ax.facet(f, 'scatter')
>
Three things about this style bother me:
1. It seems too verbose ("facet" gets typed a lot -- 4 times if you call
the variable facet instead of f).
2. I don't love having to invoke methods like 'scatter' by naming them as a
string. It feels kludgy for some reason.
3. I think the axes plotting methods belong to a different category than a
facet. The former are "artist factories" that add artists like
lines/patches/etc to axes. A facet, on the other hand, is a higher-level
"axes factory" that creates multiple subplot axes objects. Making facet an
axes method seems out of place, since I think it's more natural to have a
separate axes for each subplot. What do you think?
Admittedly, functions like plot() are a total disaster, they take a
> plethora of different argument orders and types and try to conform to many
> calling signatures at once. Specifically, the way the data is passed to
> the plotting method varies wildly.
>
Good point. My implementation relies on a pretty general (but not universal
or formally documented) property of most plot functions: the first
arguments for each method are usually data arrays. This means that, in most
situations, Facet can extract the appropriate subset of the original data,
pass them as the first arguments to an axes method, and this will "do the
right thing". This works most of the time, but might be considered a hack.
The iterator interface is meant to address the cases where this doesn't
work (for example, calling Facet.imshow or Facet.streamplot doesn't work).
I think your Faceted plotting API supports exactly what I'm hoping to see
> matplotlib will move towards:
>
> class Facet(matplotlib.Plottable)
> def __init__(self, ...)
> ...
>
> f = Facet(...)
> ax.scatter(f)
>
This interface addresses my first two concerns above, but not the third --
I don't think that all facets should live in a single axes. I'm not sure
what you envision the Plottable interface looks like, but I imagine it
provides methods to extract data, so that you can plot things besides
arrays. In this case, I think a facet could *use* Plottables when building
subplots, but I'm not sure a facet *is* a plottable.
Tangential to the notion of Plottable objects: if there were a standard
protocol for passing data and style arguments to all plotting methods, it
would be easier to build robust, higher level axes factories. Facets are
one such factory, but there are others. For example (and not the prettiest,
I admit), see the map at
http://www.tableausoftware.com/public/gallery/new-jersey-test-score-analysis-visualization.
It's basically a faceted group of pie charts, that are positioned and sized
according to more data. The generalized description is something like:
atomic_plot + faceted_by(variable) + positioned_by(x, y) + sized_by(z)
Where atomic_plot is an axes plot method (e.g., ax.pie, but why not ax.bar
or any other single-variable plot?). You could imagine building a layered
API like this, and it would be easier if the interface for all atomic_plot
objects were compatible. Matplotlib was first built to win converts over
from matplotlib -- with a layered API, you can start converting the
ggplot/d3/bokeh/vega community :)
Cheers,
Chris
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&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 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
[matplotlib-devel] Plot or Not Results Summary
Hi Everyone, I found some time to look at the votes from the "Plot or Not?" experiment Adrian Price-Whelan and I ran during SciPy last summer. You can take a look at my summary at http://datarazzi.wordpress.com/2014/01/13/plot-or-not-voting-results/, or explore for yourself at http://plotornot.chrisbeaumont.org . Plot or Not was mostly a tongue-in-cheek idea, but there is nonetheless some interesting information about style preferences in these data. I'm happy to share the raw vote data if anyone is interested in digging further. Cheers, Chris Beaumont -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Meeting...?
I have another long-simmering feature request along these lines: if Matplotlib were to evolve a formal DOM-like figure structure like mentioned above, it would be cool if this structure retained more semantic information about the visualization itself. By this, I mean that many high-level commands like hist, scatter, etc. spawn a bunch of low level artists like rectangles and circles. After these methods exit, it's hard/impossible to introspect a Figure and diagnose that it, for example, is a histogram and not a bar chart. Retaining a better high-level description of a plot (which probably amounts to creating more compound artist types) would make it easier to build tools like mpld3 and other cool things that involve runtime editing or optimization of tree-like data structures. chris On Tue, Jan 14, 2014 at 3:34 PM, Jacob Vanderplas wrote: > On Tue, Jan 14, 2014 at 12:04 PM, Michael Droettboom wrote: > >> >> I hope all of the above makes sense... >> > > Definitely makes sense: what I've built-up in mpld3 is essentially > something that mimics this sort of visitor pattern, though it misses some > things because of the draw-time difficulties you mention. > I think a two-stage draw() would be a _very_ helpful restructure. > Currently, I'm forced to achieve this result by writing a png to a > throwaway byte-stream... >Jake > > >> >> Mike >> >> >> On 01/14/2014 01:30 PM, Jacob Vanderplas wrote: >> >> Thanks - we'll make it happen at some point. >> >> Perhaps I can give the seed for a discussion: the stuff I've been doing >> with mpld3 is a lot of fun, but it's fundamentally limited by the fact that >> I have to dig around the internals of the figure object to find the >> relevant information to construct a plot representation. I may be able to >> do the same thing by creating a backend, but the problem is that the draw() >> methods of most objects call the renderer with no reference to whether the >> points lie in the data space or figure space: that is, paths and points are >> usually specified in figure/pixel coordinates or some transformed version >> thereof, which makes it near impossible to construct interactive >> representations absent Python kernel callbacks. >> >> What I'd love to see is some enhancement of the backend framework where >> there are some extra flags and information passed to the renderer: i.e. for >> each draw command, we need to know whether the drawn object should be >> linked to static figure coordinates or to dynamic axes/data coordinates. >> >> I've been in touch with Cyrille Rossant from the vispy team, Chris >> Beaumont from the Glue team, and Matt Sundwuist from the plotly team, all >> of whom asked if there might be a way to use what I've done with mpld3 to >> enable matplotlib to export into their own front-end format. I didn't >> start mpld3 with that sort of extensibility in mind, but I'm starting to >> invest some time thinking about how to design that. >> >> With the current matplotlib package, I think there are two ways to >> accomplish it: one is to create a general backend-like interface based on >> the figure introspection that mpld3 currently uses. The artist elements in >> each figure contain enough information to be able to infer whether the >> elements should move & zoom with the axes or not. The problem is, a lot of >> elements (like legends, axes aspects, etc.) are not fully established until >> the draw() command is called, so there are a few ugly hacks required to >> make it happen. >> >> The other option is to use an even uglier hack, and wrap the current >> backend framework with an object that somehow links back into the figure >> and infers from the draw_*() commands whether the path/point/marker/etc. >> should be drawn in static figure coordinates or in dynamic axes >> coordinates. I've started a simple prototype backend translator which has a >> renderer class that uses ``inspect`` back-trace the stack and accomplish >> this: It's really ugly, and I'm not particularly proud about it, but I >> think it's the current best way to accomplish the desired behavior. >> >> Ugly hacks aside, I think all of this points to a general desire for a >> new type of backend-like hook that can export dynamic plot elements in data >> coordinates, and static plot elements in figure coordinates. An >> enhancement in that direction could pave the way for a lot of interesting >> interactive front-ends to matplotlib figures. >> >> Anyway - if any of you have suggestions or responses to this,
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] OSX framework detection
Hi Derek, > the framework. Though, if I understand correctly, Anaconda provides a > framework version of the interpreter > pythonw and a non-frameworked python? This is right -- the GUI backends to matplotlib cause python to crash, but not pythonw. This is annoying, since the two binaries are equivalent under most other python installs. E.g. the mac system python manpage reads: To support multiple versions, the programs named python and pythonw now just select the real version of Python to run, depending on various set- tings. (As of Python 2.5, python and pythonw are interchangeable; both execute Python in the context of an application bundle, which means they have access to the Graphical User Interface; thus both can, when properly programmed, display windows, dialogs, etc.) So people don't usually think to invoke different anaconda python commands, leading to unexpected crashes (especially when using tools like pytest, which invoke python, run a test that needs MPL, and crash). This definitely seems like Anaconda's problem rather than matplotlib's (it affects any program that tries to import Qt, e.g.) chris -- ___ 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] [Anaconda Support] OSX: why not make "python" invoke the framework?
There are some idiosyncrasies to Anaconda's pythonw -- for example, the behavior of "-c": python -c "print 1+2" -> 3 pythonw -c "print 1+2" -> Nothing /usr/bin/pythonw -c "print 1+2" -> 3 chris On Thu, Aug 21, 2014 at 6:59 PM, Chris Barker wrote: > 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 >
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
d 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++ -- essentially handling the reference counting and python type packing/unpacking of python types. So we find we do write some shim code in C++ to make the access to the core libraries Cython-friendly. We haven't dealt with complex templating, etc, but I'd guess if we did I'd keep that in C++. And since the resulting actual glue code is pretty simple, it makes the debugging easier. > Maybe rather than asking "if we switched to using Cython, would more > participate", I > should be asking "among those that can participate in removing the PyCXX > dependency, what is the preferred approach?" I don't know that we need a one-sieze fits all approach -- perhaps some bits make the most sense to move to plain old C/C++, and some to Cython, either because of the nature of the code itself, or because of the experience/preference of the person that takes ownership of a particular problem. -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 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
