Re: [matplotlib-devel] plot directive in reST tutorials
Hi guys, > You can now do: > > .. plot:: > > from matplotlib.pyplot import * > plot([1,2,3]) This is very nice - thank you for doing that. But, thinking about the online tutorials, you often want to do something as you can do with the sourcecode directive, as in: .. testcode:: import numpy as np print np.inf Some text then .. testoutput:: inf More text .. testcode:: # I still have the context from the blocks above print np.nan More text .. testoutput:: nan In that way, I can build up a tutorial, setting and calculating variables, doing plots as I go, without having to recreate the calculations at each step. Is it possible to make the ..plot directive pick up the context in the same way? Thanks a lot, Matthew -- 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] Segmentation fault from fresh OSX snow leopard build
Hi,
I am rashly building matplotlib from source on Snow Leopard, and
getting a segmentation fault as soon as I try and do a plot.
me $ python -c 'import pylab; pylab.plot(range(10))'
Segmentation fault
I've built python myself with:
export MACOSX_DEPLOYMENT_TARGET=10.6
./configure --prefix=/Users/mb312/usr/local
Then numpy using the usual procedure (tests look good)
For matplotlib, I've hacked the make.osx file so the top looks like:
begin make.osx snippet
PYVERSION=2.6
PYTHON=python${PYVERSION}
ZLIBVERSION=1.2.3
PNGVERSION=1.2.40
FREETYPEVERSION=2.3.11
MACOSX_DEPLOYMENT_TARGET=10.6
OSX_SDK_VER=10.6
ARCH_FLAGS=
## You shouldn't need to configure past this point
PKG_CONFIG_PATH="${PREFIX}/lib/pkgconfig"
CFLAGS="${ARCH_FLAGS} -I${PREFIX}/include
-I${PREFIX}/include/freetype2 -isysroot
/Developer/SDKs/MacOSX${OSX_SDK_VER}.sdk"
LDFLAGS="${ARCH_FLAGS} -L${PREFIX}/lib
-syslibroot,/Developer/SDKs/MacOSX${OSX_SDK_VER}.sdk"
--- end make.osx snippet ---
This builds correctly but then causes the segfault above. I've tried
with the original make.osx package versions of freetype and libpng
with the same outcome.
Running simple_script.py:
blair:~ mb312$ python
scipybuild/matplotlib/examples/pylab_examples/simple_plot.py
--verbose-helpful
$HOME=/Users/mb312
CONFIGDIR=/Users/mb312/.matplotlib
matplotlib data path
/Users/mb312/usr/local/lib/python2.6/site-packages/matplotlib/mpl-data
loaded rc file
/Users/mb312/usr/local/lib/python2.6/site-packages/matplotlib/mpl-data/matplotlibrc
matplotlib version 1.0.svn
verbose.level helpful
interactive is False
units is False
platform is darwin
Using fontManager instance from /Users/mb312/.matplotlib/fontList.cache
backend MacOSX version unknown
Segmentation fault
gcc version is i686-apple-darwin10-gcc-4.2.1
Did I take a mis-step somewhere in the build process? Any advice very
gratefully received...
Thanks a lot,
Matthew
--
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] Segmentation fault from fresh OSX snow leopard build
> I am rashly building matplotlib from source on Snow Leopard, and > getting a segmentation fault as soon as I try and do a plot. > > me $ python -c 'import pylab; pylab.plot(range(10))' > Segmentation fault Sorry - here the is top of the build output: export PKG_CONFIG_PATH="/Users/mb312/usr/local/lib/pkgconfig" &&\ export MACOSX_DEPLOYMENT_TARGET=10.6 &&\ export CFLAGS=" -I/Users/mb312/usr/local/include -I/Users/mb312/usr/local/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.6.sdk" &&\ export LDFLAGS=" -L/Users/mb312/usr/local/lib -syslibroot,/Developer/SDKs/MacOSX10.6.sdk" &&\ python2.6 setup.py install --prefix=/Users/mb312/usr/local BUILDING MATPLOTLIB matplotlib: 1.0.svn python: 2.6.4 (r264:75706, Nov 29 2009, 00:03:57) [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] platform: darwin REQUIRED DEPENDENCIES numpy: 1.4.0.dev7803 freetype2: found, but unknown version (no pkg-config) * WARNING: Could not find 'freetype2' headers in any * of '.', './freetype2'. OPTIONAL BACKEND DEPENDENCIES libpng: found, but unknown version (no pkg-config) * Could not find 'libpng' headers in any of '.' Tkinter: Tkinter: 73770, Tk: 8.5, Tcl: 8.5 wxPython: no * wxPython not found Gtk+: no * Building for Gtk+ requires pygtk; you must be able * to "import gtk" in your build/install environment Mac OS X native: yes Qt: no Qt4: no Cairo: no OPTIONAL DATE/TIMEZONE DEPENDENCIES datetime: present, version unknown dateutil: matplotlib will provide pytz: 2008c OPTIONAL USETEX DEPENDENCIES dvipng: no ghostscript: /bin/sh: gs: command not found latex: no Thanks a lot, Matthew -- 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] Segmentation fault from fresh OSX snow leopard build
Hi, On Sun, Nov 29, 2009 at 1:30 AM, Jouni K. Seppänen wrote: > Matthew Brett writes: > >> I am rashly building matplotlib from source on Snow Leopard, and >> getting a segmentation fault as soon as I try and do a plot. > > Can you get a backtrace in gdb? (gdb) run scipybuild/matplotlib/examples/pylab_examples/simple_plot.py ... Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x 0x000102d96ffb in py_to_agg_transformation_matrix (obj=0x102d794d0, errors=false) at src/agg_py_transforms.cpp:21 21 matrix = (PyArrayObject*) PyArray_FromObject(obj, PyArray_DOUBLE, 2, 2); hum... I'm running from the latest svn numpy... Cheers, Matthew -- 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] Segmentation fault from fresh OSX snow leopard build
Hi, >> Can you get a backtrace in gdb? > > (gdb) run scipybuild/matplotlib/examples/pylab_examples/simple_plot.py ... > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: 13 at address: 0x > 0x000102d96ffb in py_to_agg_transformation_matrix > (obj=0x102d794d0, errors=false) at src/agg_py_transforms.cpp:21 > 21 matrix = (PyArrayObject*) PyArray_FromObject(obj, > PyArray_DOUBLE, 2, 2); > > hum... I'm running from the latest svn numpy... Same outcome with numpy 1.3 though... Matthew -- 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] Segmentation fault from fresh OSX snow leopard build
On Sun, Nov 29, 2009 at 9:49 AM, Jouni K. Seppänen wrote:
> Matthew Brett
> writes:
>
>>> Can you get a backtrace in gdb?
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: 13 at address: 0x
>> 0x000102d96ffb in py_to_agg_transformation_matrix
>> (obj=0x102d794d0, errors=false) at src/agg_py_transforms.cpp:21
>> 21 matrix = (PyArrayObject*) PyArray_FromObject(obj,
>> PyArray_DOUBLE, 2, 2);
>
> Can you type "bt" in gdb at this point to see the whole call stack?
Sorry - yes - here:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
0x000102cf703b in py_to_agg_transformation_matrix
(obj=0x102cde590, errors=false) at src/agg_py_transforms.cpp:21
21 matrix = (PyArrayObject*) PyArray_FromObject(obj,
PyArray_DOUBLE, 2, 2);
(gdb) bt
#0 0x000102cf703b in py_to_agg_transformation_matrix
(obj=0x102cde590, errors=false) at src/agg_py_transforms.cpp:21
#1 0x000102cf762c in get_path_iterator (path=0x102cde710,
trans=,
remove_nans=1, do_clip=0, rect=0x7fff5fbf9480,
quantize_mode=QUANTIZE_AUTO, do_simplify=1) at src/path_cleanup.cpp:58
#2 0x000102ce9e90 in GraphicsContext_draw_path (self=0x102cd19d0,
args=) at
src/_macosx.m:881
#3 0x0001000b31d8 in PyEval_EvalFrameEx (f=0x102b65f50,
throwflag=) at
Python/ceval.c:3706
#4 0x0001000b3f30 in PyEval_EvalCodeEx (co=0x102cd0be8,
globals=,
locals=,
args=0x102b61900, argcount=5, kws=0x102b61928, kwcount=0,
defs=0x102cde1a8, defcount=1, closure=0x0) at Python/ceval.c:2968
#5 0x0001000b1f1d in fast_function [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
#6 0x0001000b1f1d in PyEval_EvalFrameEx (f=0x102b61720,
throwflag=) at
Python/ceval.c:3727
#7 0x0001000b3f30 in PyEval_EvalCodeEx (co=0x10180ceb8,
globals=,
locals=,
args=0x102cae2a8, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2968
#8 0x0001000362a5 in function_call (func=0x101839b18,
arg=0x102cae290, kw=0x0) at Objects/funcobject.c:524
#9 0x00016fe2 in PyObject_Call (func=0x101839b18,
arg=0x102cae290, kw=0x0) at Objects/abstract.c:2492
#10 0x0001000ae352 in PyEval_EvalFrameEx (f=0x102b61530,
throwflag=) at
Python/ceval.c:4019
#11 0x0001000b3f30 in PyEval_EvalCodeEx (co=0x1014647b0,
globals=,
locals=,
args=0x102b61100, argcount=2, kws=0x102b61110, kwcount=0, defs=0x0,
defcount=0, closure=0x101825dc0) at Python/ceval.c:2968
#12 0x0001000b1f1d in fast_function [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
#13 0x0001000b1f1d in PyEval_EvalFrameEx (f=0x102b60f00,
throwflag=) at
Python/ceval.c:3727
#14 0x0001000b3f30 in PyEval_EvalCodeEx (co=0x102c90288,
globals=,
locals=,
args=0x102cae260, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2968
#15 0x0001000362a5 in function_call (func=0x102cad1b8,
arg=0x102cae248, kw=0x0) at Objects/funcobject.c:524
#16 0x00016fe2 in PyObject_Call (func=0x102cad1b8,
arg=0x102cae248, kw=0x0) at Objects/abstract.c:2492
#17 0x0001000ae352 in PyEval_EvalFrameEx (f=0x102b607f0,
throwflag=) at
Python/ceval.c:4019
#18 0x0001000b3f30 in PyEval_EvalCodeEx (co=0x1014647b0,
globals=,
locals=,
args=0x102cae218, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x102c8d6e0) at Python/ceval.c:2968
#19 0x0001000362a5 in function_call (func=0x102cad320,
arg=0x102cae200, kw=0x0) at Objects/funcobject.c:524
#20 0x00016fe2 in PyObject_Call (func=0x102cad320,
arg=0x102cae200, kw=0x0) at Objects/abstract.c:2492
#21 0x00010001905d in instancemethod_call (func=0x102cad320,
arg=0x102cae200, kw=0x0) at Objects/classobject.c:2579
#22 0x00016fe2 in PyObject_Call (func=0x102aa7fa0,
arg=0x100438c90, kw=0x0) at Objects/abstract.c:2492
#23 0x0001a760 in call_function_tail [inlined] () at
/Users/mb312/stable_trees/Python-2.6.4/Objects/abstract.c:2524
#24 0x0001a760 in PyObject_CallMethod (o=, name=, format=0x102cfd504 "O") at
Objects/abstract.c:2601
#25 0x000102ce5653 in -[View drawRect:] (self=0x102b50960,
_cmd=,
rect={origin = {x = 0, y = 0}, size = {width = 640, height = 480}}) at
src/_macosx.m:4517
#26 0x7fff8676afae in -[NSView _drawRect:clip:] ()
#27 0x7fff86769c21 in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#28 0x7fff86769f8b in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#29 0x7fff86769f8b in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#30 0x7fff867682f3 in -[NSView
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
()
#31 0x7fff86767e17 in -[NSThemeFrame
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
()
#32 0x7fff867646bf in -[NSView
_displayRectIgnoring
Re: [matplotlib-devel] Segmentation fault from fresh OSX snow leopard build
Hi, >> I've been having an almost identical problem with described above with >> the MacOSX backend. When I switched to the TkAgg backend, the segfault >> occurs when I try pylab.close() instead. >> > I may have had the same problem. Do you happen to be on a recent revision? > > Christoph Gohlke pointed out a typo introduced in r7985 (see bug report). The > patch below fixed the segfaults on my system. Yes - thanks - segfault gone for me... Cheers, Matthew -- 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
[matplotlib-devel] Mac osx make generalization
Hi, Can I suggest the following generalization in the make.osx make file? It makes it a bit easier to configure for odd builds like mine... Thanks a lot, Matthew generalize_mac_deployment.diff Description: Binary data -- 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] git migration
Hi, > Apart from being inflammatory, has anyone considered code.google.com (GC) as > a solution? ;) - speaking as someone with no right to offer an opinion - please, no. Google blocks Cuba from google code completely, for no obvious reason, and a) that seems to me quite wrong and outside the spirit of free software and b) I work there fairly often and it's hard for me to persuade the excellent scientists there to use Python if they are being specifically blocked for political reasons. See you, Matthew -- 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] git migration
Hi, On Tue, Mar 2, 2010 at 10:17 PM, william ratcliff wrote: > I think there's a legal reason for the embargo--sourceforge apparently also > has such a policy: > http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ > So, as a US company, they may not have a choice... In my experience Google is the worst in this respect by a considerable margin, and has become more so in the last year. See you, Matthew -- 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] Upcoming Debian stable release and matplotlib new release(s)
Hi, >> Multiple options (as far as I have understand github). You could use one >> account with multiple ssh-keys or you can add "contributors" to the >> repository >> in the repositorys Admin-panel, which I haven't tried out, yet. > > The github TOS allow only one person per account. I guess that's why > Eric refers to an exception being required. It's trivial to add people as collaborators to a github repository (the Admin panel Eric mentioned); that's the equivalent of SVN per-repository permissions. Adding collaborators gives the collaborator push access to the repo with their own github user / ssh key. http://github.com/guides/managing-collaborators I guess, by one-person-per-account, github means that only one person should be logging into the account and administering it, but they did agree with Fernando a while ago that it was OK to have project accounts: http://support.github.com/discussions/email/6289-contact-per-project-account-for-open-source-projects?anon_token=5139fe18a00792fd470a9fe3b7bca187b64ddb8d See you, Matthew -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Unblock matplotlib sourceforge?
Hi, Sorry to ask, but would y'all mind unblocking matlplotlib downloads from Cuba? I just tried the download from here in Havana, and got: 403 Error – Forbidden Your request is being denied as it appears to be coming from a location banned by our Terms of Use. That's because Sourceforge runs an opt-out blocking policy. If y'all agree that there's no reason to block matplotlib downloads from Cuba, China etc, would someone mind setting the 'this is not a cryptographic program' setting in the sourceforge interface? Thanks a lot, Matthew -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Unblock matplotlib sourceforge?
Hi, >> That's because Sourceforge runs an opt-out blocking policy. If y'all >> agree that there's no reason to block matplotlib downloads from Cuba, >> China etc, would someone mind setting the 'this is not a cryptographic >> program' setting in the sourceforge interface? > > Done. > > The relevant option in "export controls" is > > This project does NOT incorporate, access, call upon, or otherwise use > encryption of any kind, including, but not limited to, open source > algorithms and/or calls to encryption in the operating system or > underlying platform. Thanks very much ;) Matthew -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SourceForge.net: matplotlib: Modify: 2973874 - Text box, Save dialog for mac
Hi, On Sat, Oct 9, 2010 at 7:30 PM, Eric Firing wrote: > https://sourceforge.net/tracker/?func=detail&aid=2973874&group_id=80706&atid=560720 > > Would someone with a Mac please look at this bug and say whether it is > occurring with our release of mpl? If not, I will close the ticket. Not for me (python.org 2.6 32 bit, mpl 1.0.0) with the macosx backend or the tkagg backend. I don't have a 64 bit python / matplotlib to test with - maybe that's the trick? Or maybe it was for a different backend? Best, Matthew -- 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/beautyoftheweb ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] plot directive, thank you and a question
Hi,
First - thank you - it makes my heart very glad to be able to do this:
.. plot::
:include-source:
import matplotlib.pyplot as plt
plt.plot(range(10))
plt.show()
Here's my question. This is already a huge step forward for me, but
the full monty would be to be able to do:
.. testcode::
import some_module
res = some_module.use_it('a string')
.. plot::
:include-source:
plt.imshow(res)
and so on. I mean, the ability to keep the code context across the
page, both in the ..plot: and ..testcode:: and even >>> directives, so
I can build up my tutorial examples on top of the previous results.
That step would make it the perfect tool for the tutorials that I have
ready to port - and I am sure - many others.
Is that already possible? If not, how easy would it be? It if isn't
easy, can y'all give me some pointers as to how to get there?
Thanks again,
Matthew
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] plot directive, thank you and a question
Hi, On Mon, Nov 8, 2010 at 7:06 PM, John Hunter wrote: > On Mon, Nov 8, 2010 at 6:55 PM, Matthew Brett wrote: ... >> and so on. I mean, the ability to keep the code context across the >> page, both in the ..plot: and ..testcode:: and even >>> directives, so >> I can build up my tutorial examples on top of the previous results. >> That step would make it the perfect tool for the tutorials that I have >> ready to port - and I am sure - many others. >> >> Is that already possible? If not, how easy would it be? It if isn't >> easy, can y'all give me some pointers as to how to get there? > > This is a useful feature I've wanted myself. I just contributed a > change to the plot directive in svn to support this using two new > options :context: and :nofigs:, and updated the sampledoc tutorial. > The relevant bit from the tutorial is in the link below: > > http://matplotlib.sourceforge.net/sampledoc/extensions.html#inserting-matplotlib-plots > > Also, we have a really useful ipython directive that is stateful by > default, and includes many options for suppressing input blocks, > doctesting on output blocks, saving figures, and more. It is included > in the ipython src tree. My original proposal is at > http://matplotlib.sourceforge.net/ipymode/_build/html/proposal.html, > which I've implemented with minor changes. A real world working > example from some lecture notes I prepared recently is attached as > convolution.rst, and some notes are below. I need to get this added > to the sampledoc tutorial Thanks for extensions, and the pointer to the ipython directive, I had only half remembered it, but it does look very well designed for what I had in mind. For the first time for a few years, I'm looking forward to writing some tutorials... See you, Matthew -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git-svn matplotlib mirror
Hi, >> >> What have been the proposed solutions to dealing with basemap's data? >> > >> > Separate repo? I just fished up some previous discussions: http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8275 http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8461 Do I remember correctly that a plan was needed to keep track of the relationship of matplotlib-proper, the sample data and basemap, when they are not part of the same repository? See y'all, Matthew -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github devel question
Yo, On Fri, Feb 25, 2011 at 12:02 PM, Fernando Perez wrote: > On Fri, Feb 25, 2011 at 11:48 AM, Darren Dale wrote: >> On Fri, Feb 25, 2011 at 2:43 PM, Ryan May wrote: > >>> Agreed in principle. However, do we as devs want to get/give reviews >>> on every change that fixes typos in the docs or fixes stupid bugs in >>> examples? I think there's a point of diminishing returns. >> >> I agree. Hence the "in general" qualification. > > FWIW, my take on this question from the same conversation on > ipython-dev a few days ago: > > http://mail.scipy.org/pipermail/ipython-dev/2011-February/007258.html > > Others seemed OK with that approach. In nipy, we really haven't got into the swing of code review, but I see sympy going for it with enthusiasm, and they're better than us :) Our policy thus far has been: doc changes : go for it small bug fix with test : use judgment, probably go for it anything else : post and ask for review. In general (TM). No review, after some period, perhaps with reminder, go for it. It may not be very obvious, but the wait-for-review step has far less inconvenient consequences using git than svn because it's so easy to merge, rebase and so on. (lurking now resumed), Matthew -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] What's the status of the py3k branch?
Hi, On Sat, Feb 26, 2011 at 4:30 AM, Michiel de Hoon wrote: >> In any case it appears that with the exception of Tkinter, it may take a >> long time before interactive mpl backends can be used with py3k. > > The MacOSX backend has already been ported to Py3k (at least the C part of > it, which is the largest and most difficult part of it), though I won't be > able to test it until the rest of matplotlib has been ported. > >> The damn-ing part about the backends is that many users use only one of >> the GUI backends, and if that one is broken for them, they believe that >> matplotlib is completely broken. (Evidence: the user who complained >> that matplotlib was not designed correctly when it turned out that the >> macosx backend didn't support (non-?)interactive mode). > > Sometimes I wonder if it is better to retire the MacOSX backend. When it was > first introduced, it was much faster (depending on what you wanted to draw) > because of how its event loop is organized. By now the other backends use the > same event loop strategy, and as far as I know there is no significant > difference in speed compared to e.g. the TkAgg backend. The remaining > advantage of the MacOSX backend is that it does not rely on other toolkits, > and therefore it is easier to compile and use if something changes (e.g., > when a new version of OS X comes out, or when compiling for 64-bits, or when > Py3K comes out). Still, it needs some maintenance work, and it is hard to > keep up. > Opinions, anybody? Seconding Jeff - I use the MacOSX backend too - was very grateful not to have to install the other toolkits or suffer ugliness. So, I'm also grateful... Best, Matthew -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] What's the status of the py3k branch?
Hi, On Sat, Feb 26, 2011 at 6:23 AM, Pauli Virtanen wrote: > On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote: > [clip] >> Yes. The minimum version for this Python 3.x compatibility work is >> Python 2.6. Anything earlier is just insane ;) > > Out of curiosity: did you consider using a single source tree for Python > 2.x and 3.x, rather than a separate branch; providing Python 3 support by > running 2to3 on build stage and #ifdef's + compatibility headers in C > code? > > This approach allowed Numpy to support Pythons down to 2.4 with little > extra work, and requires manual Python 3 specific fixes only when > something breaks (which does not seem to occur often in practice). I haven't done any Py3k porting. I saw you (Pauli) doing the numpy and scipy ports using the same codebase / 2to3 strategy, and that you were pleased with the results (and it worked...). IIRC the nose testing framework had a py3k branch that got very stale, and they finally got there by dumping the py3k branch and using 2to3 on the same source tree. See you, Matthew -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] I screwed up matplotlib/master on github
Hi Paul, On Thu, Mar 24, 2011 at 2:55 AM, Paul Ivanov wrote: > Paul Ivanov, on 2011-03-24 01:30, wrote: >> I offer my sincerest apologies, I royally screwed up and thought >> that I was pushing out to one of my own branches and somehow >> ended up pushing a 2 day old copy of master out to >> matplotlib/master with 'git push -f'. Assuming Mike's work from >> today is also in his own master branch, I think the damage can be >> undone by just pulling from >> https://github.com/mdboom/matplotlib/master and pushing that to >> https://matplotlib/matplotlib/master, but at this point I don't >> trust myself and just want to not cause any more damage than I've >> already done. >> >> I realize that people get their commit right revoked for such >> careless shenanigans, but I will be grateful if you'd all allow >> me the opportunity always run any push commands with the >> --dry-run flag from now on. > > I can't figure out a way to pull it from there, but I think Eric > was the last to commit to trunk before I (destructively) pushed > my stale copy. Eric's last commit hash was: > 8506c33c811e970c6aa73a446d3ed223ac48f989 > > At least that's what I see on https://github.com/organizations/matplotlib > > hopefully this will help someone who get git better than I do. Welcome to the wonderful world of git and DVCS! I think you could have solved this one by: git reset --hard 8506c33c811e970c6aa73a446d3ed223ac48f989 and pushing that. Assuming you had that commit, which I guess you would have. The way I try and avoid doing that very easy thing is 1) Having a moderately frightening name for the upstream remote like 'upstream-rw'. 2) Having a moderately frightening name for the tracking branch like: git co -b main-master --track upstream-rw/master 3) Making sure I've got the git-completion bash command line completion tools working, so I can always see my branch name 4) Never working on main-master, always branching, and merging when I'm sure. 5) Deleting my own master branch to avoid confusion. This involves: Going to your github fork, choosing Admin, set default branch to be something other than 'master' git co that-other-branch git branch -D master # delete locally git push origin :master # delete on github Every error, is a jewel. See you, Matthew -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] I screwed up matplotlib/master on github
Yo, On Mon, Mar 28, 2011 at 8:17 AM, Michael Droettboom wrote: > There's also this git command I just discovered. It seems to solve all of > these issues, and the documentation is written in the same crystal-clear > style of the other git manpages: > > http://wingolog.org/archives/2011/03/28/git-brunch1 It is indeed a stylistic masterpiece. And then you have the aptly named and actually useful: http://git-wt-commit.rubyforge.org/git-wtf Matthew -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git repository access
Hi, On Wed, Mar 30, 2011 at 12:06 PM, James Evans wrote: > Hello All, > > > > I am finally getting around to checking out a local copy of the git > repository following the directions here: > > http://matplotlib.github.com/devel/gitwash/set_up_fork.html > > > > and I keep getting the following error: > > > > ~/source % git clone [email protected]:jrevans/matplotlib.git matplotlib-git > > Cloning into matplotlib-git... > > Permission denied (publickey). > > fatal: The remote end hung up unexpectedly > > > > I also tried replacing ‘git@’ with my github username ‘jrevans@’ > > > > Is this a github permission error? This is my first time using git, so I am > still learning. Did you follow the instructions at http://matplotlib.github.com/devel/gitwash/forking_hell.html#set-up-and-configure-a-github-account ? Particularly the ssh key stuff? http://help.github.com/linux-set-up-git/ Best, Matthew -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
Hi, On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing wrote: >> The current practice worked very nicely with SVN (IMHO), and I think it > > (I recall that Mike had to rescue us more than once from svnmerge > confusions, at least during the earlier days.) I was just idly looking at the matplotlib network graph: https://github.com/matplotlib/matplotlib/network There seem to be lots of branches and cross merges ; the history of 1.0.x is extremely confusing. I wonder whether it would be worthwhile to review git workflow? I like Pauli's edits to the numpy gitwash docs in numpy for this. I've actually just merged these back into the gitwash main docs, example build here: http://matthew-brett.github.com/pydagogue/gitwash/git_development.html Maybe the overall point is that git does require some thought to history, and some rules-of-work, to avoid confusion. I've been managing a maintenance branch for my much smaller nibabel project without much trouble; I've just been doing the occasional cherry-pick and rebase from trunk for bugfixes. Cheers, Matthew -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
Hi, On Wed, Jun 1, 2011 at 4:05 PM, Darren Dale wrote: > On Wed, Jun 1, 2011 at 6:38 PM, Matthew Brett wrote: >> Hi, >> >> On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing wrote: >>>> The current practice worked very nicely with SVN (IMHO), and I think it >>> >>> (I recall that Mike had to rescue us more than once from svnmerge >>> confusions, at least during the earlier days.) >> >> I was just idly looking at the matplotlib network graph: >> >> https://github.com/matplotlib/matplotlib/network >> >> There seem to be lots of branches and cross merges ; the history of >> 1.0.x is extremely confusing. >> >> I wonder whether it would be worthwhile to review git workflow? >> >> I like Pauli's edits to the numpy gitwash docs in numpy for this. >> I've actually just merged these back into the gitwash main docs, >> example build here: >> >> http://matthew-brett.github.com/pydagogue/gitwash/git_development.html >> >> Maybe the overall point is that git does require some thought to >> history, and some rules-of-work, to avoid confusion. >> >> I've been managing a maintenance branch for my much smaller nibabel >> project without much trouble; I've just been doing the occasional >> cherry-pick and rebase from trunk for bugfixes. > > I have a simpler rule of thumb. When merging work to push to the > matplotlib repository: inspect the history graph before the merge, > perform the merge locally, and inspect the graph after the merge but > before the push. Inspecting the history graph doesn't take long. If > the graph doesn't look the way you anticipated (unexplained or > unexpected complexity), don't push to the matplotlib repo. If you are > unsure or want help, push to your personal fork and post to the > mailing list. If you don't know how the history graph should look > after the merge, you aren't ready to push that merge to the matplotlib > repo. Sounds right to me :) Pauli actually has the same rule, I discovered: http://matthew-brett.github.com/pydagogue/gitwash/maintainer_workflow.html#check-the-history See you, Matthew -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
Hi, On Wed, Jun 1, 2011 at 4:06 PM, Eric Firing wrote: > On 06/01/2011 12:38 PM, Matthew Brett wrote: >> Hi, >> >> On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing wrote: >>>> The current practice worked very nicely with SVN (IMHO), and I think it >>> >>> (I recall that Mike had to rescue us more than once from svnmerge >>> confusions, at least during the earlier days.) >> >> I was just idly looking at the matplotlib network graph: >> >> https://github.com/matplotlib/matplotlib/network >> >> There seem to be lots of branches and cross merges ; the history of >> 1.0.x is extremely confusing. > > Agreed! > >> >> I wonder whether it would be worthwhile to review git workflow? > > Yes. > >> >> I like Pauli's edits to the numpy gitwash docs in numpy for this. >> I've actually just merged these back into the gitwash main docs, >> example build here: > > I will have to take a look; mpl did pull some version of gitwash into > its doc build. > >> >> http://matthew-brett.github.com/pydagogue/gitwash/git_development.html > > Thanks, I will take a look. If you like what you see, then the 'gitwash_dumper.py' script will pull a new copy into your repo... If you don't, then I'd love suggestions for improvements. >> Maybe the overall point is that git does require some thought to >> history, and some rules-of-work, to avoid confusion. > > I think one of the problems is that documentation such as the Git book > and at least early versions of gitwash, if I remember correctly, > emphasize workflow for people who do not access the central repo > directly. There has been much discussion on the lists of procedure for > those who do push to central repos, but I am not sure to what extent it > has gotten condensed down into a sufficiently simple set of rules and > examples in the standard documentation. Maybe you and Pauli have done > that now. That's quite right, we did more or less assume that the maintainers were git experts, and yes, Pauli did fix that to some extent. The result, as ported back by me, is this page, which is new, and needs expanding: http://matthew-brett.github.com/pydagogue/gitwash/maintainer_workflow.html >> >> I've been managing a maintenance branch for my much smaller nibabel >> project without much trouble; I've just been doing the occasional >> cherry-pick and rebase from trunk for bugfixes. > > In a way, this illustrates the difficulty: you describe a procedure for > working with a maintenance branch that is completely different from the > one we have been using (apart from the errors). What we have been doing > is initiating bug fixes in the maintenance branch and then merging that > branch to master. I'm sure either way can work fine, if one doesn't > make mistakes. I'm not sure what the relative merits of the two methods > are, in terms of simplicity, clarity, and robustness against errors. I > think they result in very different graphs, correct? With your > approach, the maintenance branch and master are separate lines, while > with our approach, the merges keep pulling the branches together in the > graph, even though their contents are steadily getting farther apart. I must confess that my git fu is not 10/10, but to me the idea of _merging_ the maintenance branch into trunk is very confusing.I mean, the trees should increasingly diverge, surely, so there will be more and more stuff you don't want to see back in trunk. At the moment, you have to trust git magic to correctly leave out the commits you don't want... See you, Matthew -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
Hi, On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale wrote: > On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing wrote: ... >> Even without the foulup, I think you would see that the merges from >> maintenance branches into subsequent branches and into master make it >> very hard to figure out what has actually been done on any given branch. > > I strongly disagree. The only reason you get cleaner history graphs > with cherry picking is because it doesn't graph the cherry picks! If > you want to know what has been merged, you have to inspect the commit > message in one branch and match it up with the commit message in > another branch. How does that make it easier to figure out what has > been done on any given branch? I think Eric's point is that it kind of feels (and looks) wrong to merge maintenance into master, rather than backporting fixes from master with cherry-picks. Maybe 'feels wrong' might be translatable as 'harder to think about' and therefore 'more error prone'? I can see the argument for doing it though. It is a common workflow? See you, Matthew -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
Hi, On Thu, Jun 2, 2011 at 7:06 PM, Darren Dale wrote: > Matthew, > > On Thu, Jun 2, 2011 at 8:17 PM, Matthew Brett wrote: >> Hi, >> >> On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale wrote: >>> On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing wrote: >> ... >>>> Even without the foulup, I think you would see that the merges from >>>> maintenance branches into subsequent branches and into master make it >>>> very hard to figure out what has actually been done on any given branch. >>> >>> I strongly disagree. The only reason you get cleaner history graphs >>> with cherry picking is because it doesn't graph the cherry picks! If >>> you want to know what has been merged, you have to inspect the commit >>> message in one branch and match it up with the commit message in >>> another branch. How does that make it easier to figure out what has >>> been done on any given branch? >> >> I think Eric's point is that it kind of feels (and looks) wrong to >> merge maintenance into master, rather than backporting fixes from >> master with cherry-picks. Maybe 'feels wrong' might be translatable >> as 'harder to think about' and therefore 'more error prone'? > > Maybe "feels wrong" translates to "unfamiliar", and has nothing to do > with difficulty or potential for error. Ah no - I mean that the way I think most of think of bugfix workflow is that we fix in trunk and backport the fix to the maintenance branch. Here though you are fixing in the maintenance branch and _merging_ to trunk. The counter-argument is 'well think of it the other way round and it will be fine'. It's a little difficult to know if that's true I suppose. It's a funny kind of thing too, because it puts an extra constraint on the bugfix. For example, imagine a bugfix in maintenance, in some code that has crazy-changed in trunk. Now you have to decide if you try and merge it anyway, and basically do a rewrite as you fix the merge conflict. Or you could merge-ours on that commit and write a completely different fix on trunk. But that's getting a bit dark and magic. And so it imposes some slight what-will-happen brain overhead on the person writing the fix. > Git is a powerful tool. If we > used a cherry-picking workflow (which I would not advocate), there > would still be chances for error by inappropriately specifying hash > ranges, for example. I think there is much more potential for error > using cherry-picking. There are other advantages as well, see > http://stackoverflow.com/questions/1241720/git-cherry-pick-vs-merge-workflow > (note the warnings about rebasing, which are not relevant to this > discussion) > >> I can >> see the argument for doing it though. It is a common workflow? > > Yes, I believe it is a very common workflow. Ah - OK, I guess I had not seen it before. > Before we made the git transition, I read about various workflows. > What we are doing now is somewhat similar to what used to be done with > svnmerge. I just googled "git workflow", and found > http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html . > See the section on "Merging Upwards": Yes, I think I see why it would be attractive. > With cherry picking, imagine we get ready to cut a v1.0.2 release, and > we want to know if all of the bug fixes that should be applied to the > maintenance branch have been applied. How do we verify? Much easier is > to apply them like the docs at kernel.org suggest, to the oldest > supported branch that require them and then merge upwards. Then the > history graph can tell you that the bug fixes in older versions have > been applied to newer branches. I believe that the git log --cherry etc machinery is designed to deal with this case, but I haven't used it myself. I have to emphasize, the projects I've been involved with have fewer developers and smaller code-bases, Cheers, Matthew -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
Yo, On Wed, Aug 31, 2011 at 7:54 PM, John Hunter wrote: > github workflow: this seems to present a different workflow than that > espoused in gitwash used by mpl and other projects > > http://scottchacon.com/2011/08/31/github-flow.html > > I like the idea of lots of feature branches off upstream/master and > master always being deployable (nightly builds?). What is the > advantage of core devs working in their own forks, as we currently do, > over working on feature branches off of > https://github.com/matplotlib/matplotlib? Seems like a lighter-weight > approach that works, and it would probably make it easier for users to > follow mpl development by tracking the mpl repo and all the branches > off of it, rather than having to pull in the various dev's forked > branches. The issue being - why not have all the development branches in the same main repo? Because: a) Everyone needs write access to the main repo b) It's much less tempting to start experimental and highly unstable branches c) You can get a very similar effect by adding remotes to your own repo. d) It only very slightly simplifies an unusual case (what's developer X working on today?). Less tempting -- Just as a minor example, here's my nipy branch list: https://github.com/matthew-brett/nipy/branches Lots of crap in there; I just made a branch with a single extra commit that I may well throw away, the branch I'm currently working on: https://github.com/matthew-brett/nipy/tree/fmristat-test-refactor - I am constantly rebasing and reorganizing while I try to work out what I'm doing. I'd think much harder about that if I thought other people were expecting to pull down all my stuff. Thinking harder = slower coding (for me at least :)) Similar effect - I'd like to see what Gael and Jonathan Taylor are up to from time to time: Once: git clone [email protected]:matthew-brett/nipy.git # origin remote git remote add gael git://github.com/GaelVaroquaux/nipy.git git remote add jonathan git://github.com/jtaylor/nipy.git >From time to time: git fetch --all - same effect, and it allows me to chose who I'm following. But actually, I very rarely do that in the abstract, I look when they tell me to look at something, and I'm pretty sure it's the same for them and my stuff. See you, Matthew -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
Hi, On Wed, Aug 31, 2011 at 8:37 PM, John Hunter wrote: > On Wed, Aug 31, 2011 at 10:16 PM, Matthew Brett > wrote: >> Yo, >> >> On Wed, Aug 31, 2011 at 7:54 PM, John Hunter wrote: >>> github workflow: this seems to present a different workflow than that >>> espoused in gitwash used by mpl and other projects >>> >>> http://scottchacon.com/2011/08/31/github-flow.html >>> >>> I like the idea of lots of feature branches off upstream/master and >>> master always being deployable (nightly builds?). What is the >>> advantage of core devs working in their own forks, as we currently do, >>> over working on feature branches off of >>> https://github.com/matplotlib/matplotlib? Seems like a lighter-weight >>> approach that works, and it would probably make it easier for users to >>> follow mpl development by tracking the mpl repo and all the branches >>> off of it, rather than having to pull in the various dev's forked >>> branches. >> >> The issue being - why not have all the development branches in the >> same main repo? >> >> Because: >> >> a) Everyone needs write access to the main repo > > I'm thinking about core devs here -- they all have write access to the > main repo. Users and non core devs can continue with the fork > approach. Will you document both workflows? Will the core-devs have to keep track of two working sets that belong to them, some in forks and some on the main repo? Will you document what criteria the core-devs should use for this transfer? I suppose I can see that the one-repo workflow would make sense for 20 people in the same building working on a private repo, but, for y'all, with people coming in all the time saying, hey, I've got a patch, and much less direct contact between the developers, I'd be really surprised if it wasn't substantially more complicated than what you have. >> b) It's much less tempting to start experimental and highly unstable branches > > This can still be done in forks. And experimental and unstable > branches are a minor threat -- they may increase the signal-to-noise, > but dead branches can be pruned and users and devs can probably get a > pretty good feel for which are active by looking at the "last update" > time on the branch list. Right - or follow Benjamin's suggestion, which seems very reasonable, of having one or two sensible branches in your main repo, like, master (maybe always deployable) and feature-several-of-us-are-working on, and just do pull requests from forks into whichever one make sense. >> c) You can get a very similar effect by adding remotes to your own repo. > > Yes, I do this and I'm sure other mpl developers do to, but you need > to know who to follow, which is harder for the casual developer or > user. By having the core devs develop in feature branches off of > upstream, it makes it easier for users and other developers to see > what all the other cores devs are up to w/o having to specify who to > track. They track the main repo, they see the main work of the core > devs as they come and go. > >> d) It only very slightly simplifies an unusual case (what's developer >> X working on today?). > > I think it simplifies it dramatically, because the average user or > part time developer doesn't have to ask "which developers should I > follow?" and do the work to add them to externals. They can assume > that by tracking the upstream branches, they see the important > non-experimental branches the core developers are working on. It is > easy to follow developer X if you know a priori who X is. But since > 95% of the work is done by people who have write access to the central > repo, and 95% of the users want to track this, it makes sense to me to > push more of the workflow into the central repo, while still > supporting external contributions via pull requests from forks. I'm the core dev on a couple of projects, and I almost never want the thing that you want, which is to see what everyone is working on right now. I don't think I've knowingly come across the user who is a) not up to adding remotes to the repo and b) will benefit from seeing or want to see what everyone is working on. I'm not saying they aren't out there, it's just not something I've considered. > Maybe I'm missing something, but I feel the gitwash workflow is more > complicated than it needs to be and this article re-inforces that > view. I'm missing it though - isn't the article describing a work-flow substantially the same as gitwash? That's what I meant in my reply, the one-repo thing is - as far as I
Re: [matplotlib-devel] github workflow
Hi, On Tue, Sep 6, 2011 at 8:38 AM, Michael Droettboom wrote: > I think most of the points being made here are valid. However, a common > occurrence (at least for me) is for a user to struggle against a bug > that I'm currently working on in one of my branches. Looking at the > main repository, it isn't very discoverable that a solution may already > exist, and the user can waste time wondering if it's a bug or user error > etc. Perhaps a compromise between these two approaches would be to have > a wiki page which is a directory of any branches that developers > consider interesting and want to point people toward? Maybe that's just > creating busy work, of course. Maybe the summary is that putting the branches in the main repo labels those branches somehow. You're suggesting the label means 'you might consider merging these to see if they fix your bug'. John is suggesting the label means 'here are the main threads of development going on'. Of course you have another virtual label which is 'branch in pull request state'. Maybe, as Fernando says, that's the best label to use for a branch that the user might consider merging? See you, Matthew -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Cairo backend prospects
> I have never run into a problem with relative imports, though I don't > object to removing them. Why are they bad style and what is the danger? I had assumed because it would not be as obvious that the imports were local modules, but might be wrong... Best, Matthew - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Test failure testing binary installer - any clues?
Hi, I'm testing the binary installer build: https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220 and I'm getting a test failure on Python 3.3 (not Python 2.7): == FAIL: matplotlib.tests.test_lines.test_invisible_Line_rendering.test -- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/nose/case.py", line 198, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/testing/decorators.py", line 73, in test self._func() File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/tests/test_lines.py", line 54, in test_invisible_Line_rendering assert_true(slowdown_factor < slowdown_threshold) AssertionError: False is not true -- Ran 1464 tests in 656.822s Is this a problem? What should I do to debug further? Cheers, Matthew -- 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] Test failure testing binary installer - any clues?
Hi, On Fri, Oct 18, 2013 at 4:47 AM, Michael Droettboom wrote: > On 10/18/2013 02:11 AM, Matthew Brett wrote: >> Hi, >> >> I'm testing the binary installer build: >> >> https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220 >> >> and I'm getting a test failure on Python 3.3 (not Python 2.7): >> >> == >> FAIL: matplotlib.tests.test_lines.test_invisible_Line_rendering.test >> -- >> Traceback (most recent call last): >>File >> "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/nose/case.py", >> line 198, in runTest >> self.test(*self.arg) >>File >> "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/testing/decorators.py", >> line 73, in test >> self._func() >>File >> "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/tests/test_lines.py", >> line 54, in test_invisible_Line_rendering >> assert_true(slowdown_factor < slowdown_threshold) >> AssertionError: False is not true >> >> -- >> Ran 1464 tests in 656.822s >> >> Is this a problem? What should I do to debug further? >> > > I've never seen that failure before... > > I wonder if Pierre Haessig has any thoughts, as the author of that test... > > Mike Thanks. I get the same error running under Python 2.7 on a clean 10.6 machine. Also I get: == FAIL: matplotlib.tests.test_contour.test_contour_manual_labels.test -- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py", line 40, in failer result = f(*args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py", line 159, in do_test '(RMS %(rms).3f)'%err) ImageComparisonFailure: images not close: /Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels.png vs. /Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels-expected.png (RMS 15.521) The images look identical to me... Cheers, Matthew -- 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?
Hi Chris, On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal wrote: > Are there recent binaries for OS-X anywhere? There don't seem to be > any for recent releases on the MPL download page. > > I know we had a discussion about this a whole back, but don't remember > the outcome. But I hope we'll continue to put them up-- macports and > friends really aren't the best solutions for everyone. I hope I have this cracked now, at least in principle. The latest versions are here: http://nipy.bic.berkeley.edu/scipy_installers/ Following Matt Terry's example, I'm testing the builds and then the installers here: https://travis-ci.org/matthew-brett/mpl-osx-binaries It would be great if you could give them a try. Cheers, Matthew -- 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] OS-X binaries?
Hi, On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen wrote: > In article > , > Matthew Brett > wrote: > >> Hi Chris, >> >> On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal >> wrote: >> > Are there recent binaries for OS-X anywhere? There don't seem to be >> > any for recent releases on the MPL download page. >> > >> > I know we had a discussion about this a whole back, but don't remember >> > the outcome. But I hope we'll continue to put them up-- macports and >> > friends really aren't the best solutions for everyone. >> >> I hope I have this cracked now, at least in principle. >> >> The latest versions are here: >> >> http://nipy.bic.berkeley.edu/scipy_installers/ >> >> Following Matt Terry's example, I'm testing the builds and then the >> installers here: >> >> https://travis-ci.org/matthew-brett/mpl-osx-binaries > > 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. > > Thank you very much for providing these! I hope you will post them to > the matplotlib official site. I'd be happy to - I think I'm waiting for some agreement that that is OK. I suppose I don't have permission to do that at the moment. > One odd failure (in both of them) that I don't remember seeing before: > /2.7/lib/python2.7/site-packages/matplotlib/projections/geo.py:485: > RuntimeWarning: invalid value encountered in arcsin > theta = np.arcsin(y / np.sqrt(2)) > > There's a complaint about an invalid font name, but I've seen that for > quite some time: > Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' ' > > FAILED (KNOWNFAIL=2, SKIP=1, errors=2) > > One small suggestion: if it's not too much trouble, might you make them > .dmgs? It's a bit more convenient then having to unzip them to use them. > But if it's too much work don't bother; zipped mpkg are fine and it's > wonderful to have complete binary installers. Yes - sure - I'll build the DMGs - was just trying to save myself some effort while waiting for feedback - and - thanks for the feedback ... Cheers, Matthew -- 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] OS-X binaries?
Hi, On Wed, Oct 23, 2013 at 12:37 PM, Chris Barker wrote: > 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? Yup: https://github.com/matthew-brett/mpl-osx-binaries/blob/master/wscript#L20 through line 44 define the build rules for the libraries. I then (this came from John H's make script I think) delete any shared libraries: https://github.com/matthew-brett/mpl-osx-binaries/blob/master/wscript#L183 and force mpl to link against these libraries first by setting 'basedir' in 'setup.cfg': https://github.com/matthew-brett/mpl-osx-binaries/blob/master/wscript#L183 I should probably disable building the shared libraries as Matt T does in his builds. Cheers, Matthew -- 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] Hangout today
Hi, Very sorry to miss this one - I'm in Cuba at the moment - if Google doesn't block hangouts, then there would not be enough bandwidth. Sorry not to get to setting up buildbot testing. Paul - do you have time for that? Cheers, Matthew On Thu, Nov 14, 2013 at 5:57 PM, Paul Ivanov wrote: > Michael Droettboom, on 2013-11-14 10:23, wrote: >> Sorry - I've been without network connection this morning, but it's back >> up... >> >> I'll be starting the matplotlib hangout shortly. Let me know if you >> don't get an invite and would like to join. > > Mike and others, > > is there a link to this hangout, or was this one not recorded > "on-air"? > > best, > -- >_ > / \ > A* \^ - > ,./ _.`\\ / \ > / ,--.S\/ \ >/ `"~,_ \\ > __o ? >_ \<,_ /:\ > --(_)/-(_).../ | \ > --...J > Paul Ivanov > http://pirsquared.org > > -- > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] I added a wheels build to binary build framework
Hi, Prompted by Chris B, I just added matplotlib wheels building to the framework here: https://github.com/matthew-brett/mpl-osx-binaries Instructions for build in the README. Sorry - am In Cuba at the moment with very low internet bandwidth and can't upload the wheels, but they should be simple to build (or I messed up with the instructions), Cheers, Matthew -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Download links on 'installing' page?
Hi, I just noticed that the installation page points to the old github download page: http://matplotlib.org/users/installing.html https://github.com/matplotlib/matplotlib/downloads I think it should point to the website download page: http://matplotlib.org/downloads.html Is that right? https://github.com/matplotlib/matplotlib/pull/2821 If so - what should happen to the github downloads page? Cheers, Matthew -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] I added a wheels build to binary build framework
Hi, On Sat, Dec 14, 2013 at 12:28 PM, Matthew Brett wrote: > Hi, > > Prompted by Chris B, I just added matplotlib wheels building to the > framework here: > > https://github.com/matthew-brett/mpl-osx-binaries > > Instructions for build in the README. > > Sorry - am In Cuba at the moment with very low internet bandwidth and > can't upload the wheels, but they should be simple to build (or I > messed up with the instructions), Following up on this one - I have built OSX wheels for python 2.7, 3.3 and 3.4 here: https://nipy.bic.berkeley.edu/scipy_installers/ You should now be able to do: # upgrade to latest pip pip install --upgrade pip # get fully binary install of matplotlib pip install --find-links=https://nipy.bic.berkeley.edu/scipy_installers matplotlib I've tested on a bare 10.6 machine for Python 2.7, will test for 3.3 and 3.4 - but - could y'all give the installation a try and see if it works for you? It will work as well into a virtualenv. There are also numpy wheels there so you can get the full stack with that command. These wheels are only for OSX I'm afraid - I'm no expert in windows builds. Cheers, Matthew -- 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/13534_NeoTech ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] I added a wheels build to binary build framework
Hi, On Sun, Mar 23, 2014 at 1:46 AM, Matthew Brett wrote: > Hi, > > On Sat, Dec 14, 2013 at 12:28 PM, Matthew Brett > wrote: >> Hi, >> >> Prompted by Chris B, I just added matplotlib wheels building to the >> framework here: >> >> https://github.com/matthew-brett/mpl-osx-binaries >> >> Instructions for build in the README. >> >> Sorry - am In Cuba at the moment with very low internet bandwidth and >> can't upload the wheels, but they should be simple to build (or I >> messed up with the instructions), > > Following up on this one - I have built OSX wheels for python 2.7, 3.3 > and 3.4 here: > > https://nipy.bic.berkeley.edu/scipy_installers/ > > You should now be able to do: > > # upgrade to latest pip > pip install --upgrade pip > # get fully binary install of matplotlib > pip install --find-links=https://nipy.bic.berkeley.edu/scipy_installers > matplotlib > > I've tested on a bare 10.6 machine for Python 2.7, will test for 3.3 > and 3.4 - but - could y'all give the installation a try and see if it > works for you? It will work as well into a virtualenv. There are > also numpy wheels there so you can get the full stack with that > command. Yes, they seem to work on bare 10.6 on all three python versions. I got one failure on python 3.4 but it didn't look related to the wheel: == FAIL: matplotlib.tests.test_basic.test_override_builtins -- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/nose/case.py", line 198, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/matplotlib/tests/test_basic.py", line 38, in test_override_builtins assert not overridden nose.proxy.AssertionError: >> begin captured stdout << - '__spec__' was overridden in globals(). - >> end captured stdout << -- Cheers, Matthew -- 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/13534_NeoTech ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] I added a wheels build to binary build framework
Hi, On Mon, Mar 24, 2014 at 6:29 AM, Benjamin Root wrote: > I thought we fixed this one... > > Seems like we haven't as there is an open issue for it: > https://github.com/matplotlib/matplotlib/issues/2842 Sorry - I didn't say - but the wheels are for the 1.3.1 release... Cheers, Matthew -- 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/13534_NeoTech ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] OK to upload wheels to pypi?
Hi, I've built and tested some binary wheels for OSX - available here: https://nipy.bic.berkeley.edu/scipy_installers/ I'd really like to upload these to pypi so that people get them by default with 'pip install matplotlb'. Is that OK? Can someone give me permission to do that? Thanks a lot, Matthew -- 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/13534_NeoTech ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Binary wheels for OSX
Hi, I've just uploaded binary wheels for OSX to pypi. If you're on Python.org python, then this should work pip install --upgrade pip # if you're not on latest pip already pip install matplotlib I mean - you should get the binary wheel for matplotlib. If fact this wheel will also work for Mac system python or homebrew or macports if suitably renamed, but I put this current one up now, for testing. Please do let me know if you have any problems. (By the way - this should also work in a fresh install / virtualenv, because numpy is already pip'ed up with wheels). Cheers, Matthew -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Renaming OSX wheels on pypi to make them more general
Hi, Sorry for those of you on the numpy mailing list - this email will seem a bit familiar. I want to rename the matplotlib wheel OSX wheel files on pypi so they will also install into homebrew, macports and system python. I'm just doing this now for numpy and scipy, but I wanted to make sure y'all had no objections for matplotlib. The logic of the renaming is explained here: https://github.com/MacPython/wiki/wiki/Spinning-wheels Basically, by adding extra 'platform tags' to the wheel filename, we can signal to pip that the wheel is compatible with these other systems. The page above explains why the wheels I built are compatible with the other Pythons, and this test grid: https://travis-ci.org/matthew-brett/scipy-stack-osx-testing/builds/26482436 confirms that the renamed wheels install and test OK on homebrew, macports, system python. So, I propose to rename the current matplotlib python 2.7 wheel from: matplotlib-1.3.1-cp27-none-macosx_10_6_intel.whl to matplotlib-1.3.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl and so on for python 3.3, 3.4. I don't think this has a downside, but I'm happy for any feedback, Cheers, Matthew -- 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, On Mon, Jun 2, 2014 at 5:14 PM, Chris Barker wrote: > 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! Yes, it could, but this list: https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion 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. Cheers, Matthew -- 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, On Tue, Jun 3, 2014 at 1:00 PM, Russell E. Owen wrote: > In article > , > Chris Barker wrote: > >> 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. > > 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. 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... Cheers, Matthew -- 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, On Thu, Jun 5, 2014 at 5:18 AM, Chris Barker wrote: > 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... Updating for those of you not on the numpy mailing list - I've uploaded 32 / 64 bit numpy / scipy wheels to pypi, so we should be good for 32-bit compatibility now. I hope that will continue for at least a couple of years, because I've automated the 32 / 64 bit build process [1] and added 32-bit tests to my scipy-stack test rig [2]. So, I think it is time to rename the matplotlib wheels as I proposed at the beginning of the thread. I propose to do that tomorrow unless anyone can think of a reason not to. Cheers, Matthew [1] https://github.com/matthew-brett/numpy-atlas-binaries [2] https://travis-ci.org/matthew-brett/scipy-stack-osx-testing -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ 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 Fri, Jun 20, 2014 at 12:01 PM, Matthew Brett wrote: > Hi, > > On Thu, Jun 5, 2014 at 5:18 AM, Chris Barker wrote: >> 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... > > Updating for those of you not on the numpy mailing list - I've > uploaded 32 / 64 bit numpy / scipy wheels to pypi, so we should be > good for 32-bit compatibility now. I hope that will continue for at > least a couple of years, because I've automated the 32 / 64 bit build > process [1] and added 32-bit tests to my scipy-stack test rig [2]. > > So, I think it is time to rename the matplotlib wheels as I proposed > at the beginning of the thread. I propose to do that tomorrow unless > anyone can think of a reason not to. Done - please let me know if you have any problems. Matthew -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] tests.py missing
Hi, On Wed, Jun 25, 2014 at 4:49 PM, wrote: > Thanks, but I didn't get it when I downloaded matplotlib-1.3.1.tar.gz. > > kbriggs:~/Downloads> tar tf matplotlib-1.3.1.tar.gz | grep tests.py > > Keith > > > From: [email protected] [[email protected]] On Behalf Of Benjamin Root > [[email protected]] > Sent: 25 June 2014 16:45 > To: Briggs,KM,Keith,TUB2 R > Cc: matplotlib development list > Subject: Re: [matplotlib-devel] tests.py missing > > It is right there in the root directory for the distribution: > > https://github.com/matplotlib/matplotlib/tree/v1.3.x > > > On Thu, Jun 19, 2014 at 11:29 AM, > mailto:[email protected]>> wrote: > README.rst in matplotlib-1.3.1 says: > >> After installation, you can launch the test suite:: >> >> python tests.py > > but actually there is no tests.py anywhere in the distribution. Actually, it would be very good to have the tests.py file somewhere from a standard install - I had to hack round that for automated tests of a pip tarball, for example, by downloading the test.py separately. Cheers, Matthew -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] plot_directive, context and multiple plots
Hi, I am happily using `plot_directive`, but I've run into an inconvenience when using the 'context' option. Consider this rst file: ``` ### A title ### .. plot:: :context: import matplotlib.pyplot as plt plt.plot(range(10)) Then some text. .. plot:: :context: plt.figure() plt.plot(range(5), 'r') ``` In the second panel you see plots for both the first figure and the second figure, because the underlying code is making this call: fig_managers = _pylab_helpers.Gcf.get_all_fig_managers() to find all current figures, finding the first and the second figure, and rendering both. I think this is unlikely to be what the user expects (it confused me), but I wasn't sure what the best way to work round it was. I considered adding another option like `:myfigs: true` to the directive which would only pick up figures I create using the current code block - is there a better way? Cheers, Matthew -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] windows binaries for 1.4.0rc2 are available
Hi, On Sun, Jul 27, 2014 at 7:52 PM, Thomas Caswell wrote: > https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.4.0rc2/ > > Thanks to Christoph Gohlike the widows binaries now posted on sourceforge. > Also automatically built OSX wheels here: http://wheels.scikit-image.org/ Wheels built via travis-ci from https://github.com/matthew-brett/matplotlib-wheels. Usual procedure: pip install -f http://wheels.scikit-image.org --pre matplotlib Please do send feedback. Cheers, Matthew -- 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
[matplotlib-devel] OSX wheels for 1.4.0rc2 available for testing
Hi, Sorry for the repost - just in case OSX users out there missed it... We have automatically built OSX wheels for the upcoming release here: http://wheels.scikit-image.org/ Wheels built via travis-ci from https://github.com/matthew-brett/matplotlib-wheels. Usual procedure: pip install -f http://wheels.scikit-image.org --pre matplotlib Please do send feedback. Cheers, Matthew -- 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] v1.4.0rc3
Hi, On Sat, Aug 9, 2014 at 2:18 PM, Thomas Caswell wrote: > I have tagged the third (and hopefully last) RC for 1.4. > > The outstanding issues are documentation related (rebase guide which I > need to edit a bit more, a what's new entry, a decision if we have > improved the install documentation enough, and to make sure that docs > for backend_bases gets added to sphinx) and the re-design of the front > page. Thanks for doing this. I did a full test against the scipy stack: https://travis-ci.org/matthew-brett/scipy-stack-osx-testing/builds/32131131 It turns out there's a new failure testing pandas against mpl, reproduced with ``nosetests pandas.tseries.tests.test_converter`` after installing pandas: == ERROR: test_dateindex_conversion (pandas.tseries.tests.test_converter.TestDateTimeConverter) -- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pandas/tseries/tests/test_converter.py", line 77, in test_dateindex_conversion xp = converter.dates.date2num(dateindex) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/dates.py", line 310, in date2num return _to_ordinalf_np_vectorized(d) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/function_base.py", line 1573, in __call__ return self._vectorize_call(func=func, args=vargs) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/function_base.py", line 1633, in _vectorize_call ufunc, otypes = self._get_ufunc_and_otypes(func=func, args=args) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/function_base.py", line 1597, in _get_ufunc_and_otypes outputs = func(*inputs) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/dates.py", line 204, in _to_ordinalf base = float(dt.toordinal()) AttributeError: 'numpy.datetime64' object has no attribute 'toordinal' I confirmed that the same command running against mpl 1.3.1 passes. Same error with numpy 1.7.1 and numpy 1.8.2. Does this ring any bells? Cheers, Matthew -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mac osx dmg files
Hi, On 8/22/14, Thomas Caswell wrote: > Are we planning to make and distribute .dmg (damage?!?) files for 1.4? > If so who is making them? If not, we should remove that section form > `installing_faq.rst`. I can build them, but they are a bit frightening because they unconditionally replace any pre-installed versions of the dependencies. I seem to remember there were still some people who would like these though. Is that right? Cheers, Matthew -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: plot_directive, context and multiple plots
Sorry - I accidentally sent this reply just to Nathaniel - returning
to this as it bit me again:
On 7/14/14, Nathaniel Smith wrote:
> Wouldn't a better default be to just close all figures when they're
> displayed? It can't be common that someone wants to show the same plot
> repeatedly (and if they do that could have an option)...?
Yes, I think that would be a better default.
You mean that if :context: is true, then always do something like
``plt.close('all')`` before running the relevant code and looking for
figures.
It would change the current behavior, but I agree that would be better.
Anyone disagree?
If not, I will make a pull request to change the behavior...
Cheers,
Matthew
--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: plot_directive, context and multiple plots
Hi, On Tue, Oct 28, 2014 at 12:15 PM, Benjamin Root wrote: > Yeah, put together a PR, and we can evaluate it better that way. I think the > current plot directive behavior might need this sort of tightening up Thanks for the feedback, sorry for the delay: https://github.com/matplotlib/matplotlib/pull/3916 Cheers, Matthew -- 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=164703151&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.4.3rc1
Hi, On Mon, Feb 2, 2015 at 2:58 AM, Jens Nielsen wrote: > Thanks Tom, > > I ran the test suite on OSX 10.10 with both python 2.7.8 and 3.4.2 including > the tex and QT4 tests that are skipped on Travis. > Everything passes as expected. I built wheels for OSX testing, via the automated travis builders [1]. Install with: pip install -f http://wheels.scipy.org -U --pre matplotlib Scipy ecosystem tests (numpy, scipy, pandas, etc) running against the rc1 wheel at [2]. Cheers, Matthew [1] https://travis-ci.org/MacPython/matplotlib-wheels [2] https://travis-ci.org/MacPython/scipy-stack-osx-testing -- 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] Capitalization of Matplotlib
Hi, On Mon, Feb 16, 2015 at 10:53 AM, Nelle Varoquaux wrote: > > IMO, never. Rationale, please? >>> >>> >>> Consistency: it is never capitalized in matplotlib's documentation. >> >> >> True, and a valid point--but we could easily change that. Wouldn't it make >> it bit more readable if sentences always started with a capital letter? >> Starting with lower case just looks wrong and artificial. > > I'm going to give two bad reasons to keep it this way: > 1. backward compatibility :p > 2. you are used to having sentences start with capital letter, but > this is mostly cultural. German People capitalize almost all Words in > a Sentence. It just looks weird too… (There is the other extreme: > people who don't seem to know where the shift button on their keyboard > is when writing an email.) > > I'm actually fine with changing it, but I think we should try as much > as possible to be consistent. I suppose everyone would agree that matplotlib should never be capitalized. I guess also that your (Ben's) typsetters will not often be using formatted matplotlib. In that case I would say Matplotlib is a English proper noun and standard capitalization rules apply. It would probably be confusing to try and distinguish between the project and the software with capitalization. Does it matter that the book and the mpl documentation have a different convention? Cheers, Matthew -- 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=190641631&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Capitalization of Matplotlib
Hi, On Mon, Feb 16, 2015 at 1:26 PM, Paul Kuin wrote: > Ah, since it is a proper name it should be capitalised, but it never was. I > think that it should remain uncapitalised and that you want to propose an > alternative, like a change in type for the proper name matplotlib. Could be > typescript, or something else. I'm guessing the type-setters would object to always using typewriter (or other special) font for matplotlib, as it would quickly get tiring on the eye. Cheers, Matthew -- 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=190641631&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
