[matplotlib-devel] [ANN-JOB] Project Jupyter is hiring a Project Manager - position at UC Berkeley
Hi all, [ please direct all replies directly to me ] Project Jupyter is announcing the opening of a position for a full-time project manager, who will help us coordinate our technical development, engage the open source community and work with our multiple stakeholders in academia and industry. If you have experience leading technical teams in open source communities, we'd love to hear from you! In the last few years the project has rapidly grown in multiple directions, and this presents both challenges and opportunities. We are looking for someone who can help us harness the energy and activity from our many contributors that include those funded by our research grants, our industry partners, and the entire open source community. The role of the project manager is to help us maintain this activity focused into a solid whole, so we can deliver timely and robust releases, evolve our architecture coherently, ensure our documentation and communication matches our technical foundation, and continue engaging a wide range of stakeholders to evolve the project in new, interesting and valuable directions. This position will be hosted at the Berkeley Institute for Data Science, working locally with Fernando Perez, Matthias Bussonnier, and our new postdoctoral scholars. But the scope of this role is the entire project, so we are looking for a candidate who will be regularly communicating with project stakeholders from all locations, traveling to conferences, development workshops and other project activities. For specific details on the position and to apply, you can learn more at jobs.berkeley.edu, Job ID #20975: https://hrw-vip-prod.is.berkeley.edu/psc/JOBSPROD/EMPLOYEE/HRMS/c/HRS_HRAM.HRS_CE.GBL?Page=HRS_CE_JOB_DTL=A=20975=1=1; Note that while the application review date is listed as January 1, 2016, we will be considering applicants past that date (that is the cutoff for us to be allowed to look at incoming applications). The search will remain open until filled. -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] [JOB] Project Jupyter is hiring two postdoctoral fellows @ UC Berkeley
Hi all, We are delighted to announce today that Project Jupyter/IPython has two postdoctoral fellowships open at UC Berkeley, open immediately. Interested candidates can apply here: https://aprecruit.berkeley.edu/apply/JPF00899 We hope to find candidates who will work on a number of challenging questions over the next few years, as described in our grant proposal here: http://blog.jupyter.org/2015/07/07/project-jupyter-computational-narratives-as-the-engine-of-collaborative-data-science/ Interested candidates should carefully read that proposal before applying to familiarize themselves with the full scope of the questions we intend to tackle. We'd like to thank the support of the Helmsley Trust, the Gordon and Betty Moore Foundation and the Alfred P. Sloan Foundation. Cheers, Brian Granger and Fernando Perez. -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] Interactive matplotlib figures in the IPython notebook
Hi Phil, On Thu, Apr 24, 2014 at 6:57 AM, Phil Elson pelson@gmail.com wrote: Cross posted to IPython-dev and mpl-dev. Over the Easter holidays I had a chance to take a look at implementing a new matplotlib backend which would allow interactive figures inline in the IPython notebook. It's something that has been on the radar for a couple of years now, with work needed from both projects to make the functionality possible, so I'm pleased to have been able to submit a PR ( https://github.com/matplotlib/matplotlib/pull/3008) to matplotlib which finally adds the nbagg backend - the final piece of the jigsaw. this is great news, thanks for posting this! Most/all of us will be at SciPy and staying for the sprints, so if there's remaining design work that this uncovers that's needed for future improvements, please make note of it and we can discuss it face to face. Cheers f -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] [ANN, x-post] Creating a space for scientific open source at Berkeley (with UW and NYU)
Hi folks, forgive me for the x-post to a few lists and the semi off-topic nature of this post, but I think it's worth mentioning this to our broader community. To keep the SNR of each list high, I'd prefer any replies to happen on the numfocus list. Yesterday, during an event at the White House OSTP, an announcement was made about a 5-year, $37.8M initative funded by the Moore and Sloan foundations to create a collaboration between UC Berkeley, the University of Washington and NYU on Data Science environments: - Press release: http://www.moore.org/newsroom/press-releases/2013/11/12/%20bold_new_partnership_launches_to_harness_potential_of_data_scientists_and_big_data - Project description: http://www.moore.org/programs/science/data-driven-discovery/data-science-environments We worked in private on this for a year, so it's great to be able to finally engage the community in an open fashion. I've provided some additional detail in my blog: http://blog.fperez.org/2013/11/an-ambitious-experiment-in-data-science.html At Berkeley, we are using this as an opportunity to create the new Berkeley Institute for Data Science (BIDS): http://newscenter.berkeley.edu/2013/11/13/new-data-science-institute-to-help-scholars-harness-big-data and from the very start, open source and the scientific Python ecosystem have been at the center of our thinking. In the team of co-PIs we have, in addition to me, a bunch of Python supporters: - Josh Bloom leads our Python bootcamps and graduate seminar) - Cathryn Carson founded the DLab (dlab.berkeley.edu), which runs python.berkeley.edu. - Philip Stark: Stats Chair, teaches reproducible research with Python tools. - Kimmen Sjolander: comp. biologist whose tools are all open source Python. - Mike Franklin and Ion Stoica: co-directors of AMPLab, whose Spark framework has Python support. - Dave Culler: chair of CS, which now uses Python for its undergraduate intro courses. We will be working very hard to basically make BIDS a place for people like us (and by that I mean open source scientific computing, not just Python: Juila, R, etc. are equally welcome). This is a community that has a significant portion of academic scientists who struggle with all the issues I list in my post, and solving that problem is an explicit goal of this initiative (in fact, it was the key point identified by the foundations when they announced the competition for this grant). Beyond that, we want to create a space where the best of academia, the power of a university like Berkeley, and the best of our open source communities, can come together. We are just barely getting off the ground, deep in more mundane issues like building renovations, but over the next few months we'll be clarifying our scientific programs, starting to have open positions, etc. Very importantly, I want to thank everyone who, for the last decade+, has been working like mad to make all of this possible. It's absolutely clear to me that the often unrewarded work of many of you was essential in this process, shaping the very existence of data science and the recognition that it should be done in an open, collaborative, reproducible fashion. Consider this event an important victory along the way, and hopefully a starting point for much more work in slightly better conditions. Here are some additional resources for anyone interested: http://bitly.com/bundles/fperezorg/1 -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- 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=63469471iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Regular matplotlib meetings
Great! I just wanted to say that for us (ipython), that has worked really well. Our workflow is: 1. G+ hangout, with an invite list of ~ 15 (the limit), and we're always happy to offer an invite to anyone who wants to speak. 2. As soon as we start, we post the public link on g+, twitter and our hackpad. 3. We take running notes on a shared, public hackpad session that serves as our 'minutes' document: https://hackpad.com/IPython-dev-meetings-6wTSjJt7TZK 4. A summary of prior meetings and logistics info is kept here: https://github.com/ipython/ipython/wiki/Dev:-Lab-meetings-on-Air Very simple, lightweight and surprisingly effective at giving the core team a high-bandwidth channel for in-depth discussions while maintaining the openness we want to engage the broader community. Cheers, f -- 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=60133471iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Regular matplotlib meetings
Oops, and I missed the last point: we monitor our public chat room on hipchat: http://www.hipchat.com/ghtNzvmfC where anyone can post questions, follow ups, etc, that they don't want to record persistently on hackpad in the minutes. On Tue, Sep 24, 2013 at 5:50 PM, Fernando Perez fperez@gmail.com wrote: Great! I just wanted to say that for us (ipython), that has worked really well. Our workflow is: 1. G+ hangout, with an invite list of ~ 15 (the limit), and we're always happy to offer an invite to anyone who wants to speak. 2. As soon as we start, we post the public link on g+, twitter and our hackpad. 3. We take running notes on a shared, public hackpad session that serves as our 'minutes' document: https://hackpad.com/IPython-dev-meetings-6wTSjJt7TZK 4. A summary of prior meetings and logistics info is kept here: https://github.com/ipython/ipython/wiki/Dev:-Lab-meetings-on-Air Very simple, lightweight and surprisingly effective at giving the core team a high-bandwidth channel for in-depth discussions while maintaining the openness we want to engage the broader community. Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- 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=60133471iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] In Memoriam, John D. Hunter III: 1968-2012
Hi all, after John's untimely passing we had a memorial service in Chicago, but only a few on these lists were able to attend. At last week's scipy conference I read a slightly edited version of the eulogy from that memorial service, and I figured some of you might be interested if you missed the conference: http://blog.fperez.org/2013/07/in-memoriam-john-d-hunter-iii-1968-2012.html Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Weird KnownFailure problem in IPython test suite with mpl master
Thanks a ton, Mike! Great not to have to worry about this on our side. cheers, f On Wed, Jun 19, 2013 at 10:02 AM, Michael Droettboom md...@stsci.edu wrote: Just to close the loop on this, I have created: https://github.com/matplotlib/matplotlib/pull/2139 On 06/18/2013 07:18 PM, Fernando Perez wrote: Good point, I didn't know about that new mechanism. I think we should keep 2.6 support for IPython 1.0, but drop it afterwards. We can discuss that during the dev meeting... Cheers, f On Tue, Jun 18, 2013 at 4:16 PM, Thomas Kluyver tho...@kluyver.me.uk wrote: On 19 June 2013 00:09, Fernando Perez fperez@gmail.com wrote: I wish we could just fix this plugin issue. When we drop support for Python 2.6, I think we can use the expectedFailure mechanism included in unittest from 2.7 onwards. So long as nose recognises that, we should be able to drop our copy of the KnownFailure plugin. Thomas -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Weird KnownFailure problem in IPython test suite with mpl master
Hi folks, I'm wondering if the following rings any bells for you... Right now, on an ubuntu 13.04 machine, if I install mpl master (say to my home directory), the IPython test suite fails here: iptest -vx IPython.core.tests.test_run ... == ERROR: Test that namespace cleanup is not too aggressive GH-238 -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/nose/case.py, line 197, in runTest self.test(*self.arg) File /usr/lib/python2.7/dist-packages/numpy/testing/decorators.py, line 213, in knownfailer raise KnownFailureTest(msg) KnownFailureTest: This test is known to fail If I uninstall mpl from master and revert to the system version (1.2.1), then it's all OK. We'd seen this problem a few years ago, but in that case it was the opposite: mpl master was OK and the issue was mis-packaging by Ubuntu: https://github.com/ipython/ipython/issues/823 https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/871176 But now the problem appears to be caused by mpl master. Can you think of any recent changes to mpl in how you load your nose plugins that could be causing this? Since SciPy'13 is coming and I know Mike will be there, I'm happy to try to debug this face to face in Austin. I just wanted to put it on your radar, in case it's an easy fix (esp. if it's one you can apply before 1.3.0 goes out). Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Weird KnownFailure problem in IPython test suite with mpl master
Hi Ben, On Tue, Jun 18, 2013 at 1:29 PM, Benjamin Root ben.r...@ou.edu wrote: Does the same thing happen with the v1.3.x branch? You said you tested master, but that isn't exactly the same as v1.3.x. I just tested with the v1.3.0rc3, and the problem is present there: ((v1.3.0rc3))longs[matplotlib] iptest -vx IPython.core.tests.test_run Check that %run doesn't damage __builtins__ ... ok Check that the type of __builtins__ doesn't change with %run. ... ok Test that prompts correctly generate after %run ... ok Test that the option -p, which invokes the profiler, do not ... ok Test that namespace cleanup is not too aggressive GH-238 ... ERROR == ERROR: Test that namespace cleanup is not too aggressive GH-238 -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/nose/case.py, line 197, in runTest self.test(*self.arg) File /usr/lib/python2.7/dist-packages/numpy/testing/decorators.py, line 213, in knownfailer raise KnownFailureTest(msg) KnownFailureTest: This test is known to fail -- Ran 5 tests in 0.006s FAILED (errors=1) Cheers, f -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Weird KnownFailure problem in IPython test suite with mpl master
Hi Mike,
On Tue, Jun 18, 2013 at 3:37 PM, Michael Droettboom md...@stsci.edu wrote:
This was an attempt to fix a bug that mpl's KnownFailure plugin wouldn't
load when running tests directly using the nosetests commandline
script. I see IPython has a testing wrapper script (iptest) -- is that
in part to solve that problem?
Only in part. We wrote iptest because we need to start nose multiple
times in different subprocesses for each chunk of IPython, as trying
to load all of IPython into a single python process ends up producing
tears (conflicts between things that don't like to live together in
sys.modules like multiple gui toolkits, etc).
In any case, the revert should be simple -- can you try commenting out
the entry_points kwarg at the bottom of the setup.py script? (You'll
probably need to blitz the matplotlib installation directory and `build`
for good measure). I can't actually reproduce the bug myself, but I
suspect that's because this is somewhat dependent on the order in which
things are installed into the virtualenv or the phases of the moon...
Yup, problem gone. With this change:
((v1.3.0rc3))longs[matplotlib] git diff
diff --git a/setup.py b/setup.py
index 5f1b561..b4d1763 100644
--- a/setup.py
+++ b/setup.py
@@ -230,9 +230,9 @@ if __name__ == '__main__':
zip_safe=False,
# Install our nose plugin so it will always be found
- entry_points={
- 'nose.plugins.0.10': [
- 'KnownFailure = matplotlib.testing.noseclasses:KnownFailure'
-]
-},
+ # entry_points={
+ # 'nose.plugins.0.10': [
+ # 'KnownFailure = matplotlib.testing.noseclasses:KnownFailure'
+ # ]
+ # },
)
I get as expected:
((v1.3.0rc3))longs[matplotlib] iptest -vx IPython.core.tests.test_run
[...]
--
Ran 23 tests in 2.277s
OK (KNOWNFAIL=1)
If that works for you, we can just take that out and require testers to
use our testing script (and unfortunately will have to make another
release candidate).
Well, I wouldn't want to force mpl to have to ship a custom testing
script, that's kind of an ugly kludge that we live with but that is
really sub-optimal. I wish we could just fix this plugin issue. The
problem, I suspect, is the presence of multiple KnownFailure classes
in a way that trips an isisnstance() check somewhere.
Cheers,
f
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Weird KnownFailure problem in IPython test suite with mpl master
Good point, I didn't know about that new mechanism. I think we should keep 2.6 support for IPython 1.0, but drop it afterwards. We can discuss that during the dev meeting... Cheers, f On Tue, Jun 18, 2013 at 4:16 PM, Thomas Kluyver tho...@kluyver.me.uk wrote: On 19 June 2013 00:09, Fernando Perez fperez@gmail.com wrote: I wish we could just fix this plugin issue. When we drop support for Python 2.6, I think we can use the expectedFailure mechanism included in unittest from 2.7 onwards. So long as nose recognises that, we should be able to drop our copy of the KnownFailure plugin. Thomas -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] A generous donation of $10, 000 from Simula/Hans Petter Langtangen via NumFOCUS
Hi all, I just wanted to let you all know that Hans Petter Langtangen, well-known author of books on scientific Python and long-time champion of these tools at the University of Oslo for many years, has arranged for a donation of $10,000 to support matplotlib's development. Hans Petter is the Director of the Center for Biomedical Computing at Simula (http://home.simula.no/~hpl), where a number of projects use Python as key elements of their research, the Fenics platform being among the most well-known (http://fenicsproject.org). We have now confirmed that these funds have been transferred to the NumFOCUS donations account, where Michael and the rest of the team can make use of them. I wanted to publicly thank Hans Petter and Simula Labs for persistently jumping through the necessary hoops to make this possible, and to Leah, Travis and Anthony at NumFOCUS for managing the receiving side of things. -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] png error with git master, is it just me?
On Fri, Apr 5, 2013 at 10:06 AM, Julian Taylor jtaylor.deb...@googlemail.com wrote: whats the output of: ldd /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so apt-cache policy libpng12-dev the system libpng in ubuntu 12.10 does have this symbol defined, maybe you are picking up some other installation. Here's what I get: longs[~] ldd /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so linux-vdso.so.1 = (0x7fff56dff000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f97ecaeb000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f97ec8d4000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f97ec6b7000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f97ec2f8000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f97ebffb000) /lib64/ld-linux-x86-64.so.2 (0x7f97ed04b000) longs[~] apt-cache policy libpng12-dev libpng12-dev: Installed: 1.2.49-1ubuntu1 Candidate: 1.2.49-1ubuntu1 Version table: *** 1.2.49-1ubuntu1 0 500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/main amd64 Packages 100 /var/lib/dpkg/status Thanks for any insights you may provide... f -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] png error with git master, is it just me?
On Fri, Apr 5, 2013 at 1:49 PM, Julian Taylor jtaylor.deb...@googlemail.com wrote: strange, it isn't linked against libpng at all. I can't reproduce that on my Ubuntu machine with git head. Do you still have a buildlog? Maybe do a new build from a clean folder (and save the log). I just did a fully clean rebuild in a fresh clone, and the same thing happens. Build log here: http://pastebin.com/eCGbEvKb The only thing that jumpts at me is: Package PyCXX was not found in the pkg-config search path. Perhaps you should add the directory containing `PyCXX.pc' to the PKG_CONFIG_PATH environment variable No package 'PyCXX' found which I don't understand, as pycxx is clearly installed: (master)longs[matplotlib] apt-cache policy python-cxx python-cxx: Installed: 6.2.4-1 Candidate: 6.2.4-1 Version table: *** 6.2.4-1 0 500 http://ubuntu.cs.utah.edu/ubuntu/ quantal/universe amd64 Packages 100 /var/lib/dpkg/status Puzzled... f -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] png error with git master, is it just me?
On Fri, Apr 5, 2013 at 2:51 PM, Julian Taylor jtaylor.deb...@googlemail.com wrote: I filed an issue: https://github.com/matplotlib/matplotlib/issues/1884 Go figure, it was an actual bug! Well, thanks a lot for tracking it down :) I guess for now I'll just remove pycxx-dev from my system. Fortunately I don't need it for anything else. But it means that right now, mpl can't be built on a system with the matplotlib build-deps loaded, which is a bummer. Cheers, f -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] png error with git master, is it just me?
Thanks, Damon, for this info. Based on this, I've tested now on another, different system with the same version of linux and can't reproduce it either. Very odd, but it looks like something is amiss on my end, so let me investigate further before anyone burns further cycles on the issue. Cheers, f On Thu, Apr 4, 2013 at 8:06 PM, Damon McDougall damon.mcdoug...@gmail.comwrote: On Thu, Apr 4, 2013 at 6:41 PM, Fernando Perez fperez@gmail.comwrote: Hi folks, I'm getting the following error from a clean build of master on an ubuntu 12.10 machine: longs[junk] python -c 'import matplotlib._png' Traceback (most recent call last): File string, line 1, in module ImportError: /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so: undefined symbol: png_create_read_struct I hadn't seen anything like this recently, nor can I find similar reports, so I'm wondering if anyone knows what's going on, or if it's an error on my side. I can try to bisect it but I figured I'd ask first in case it's obvious to someone else... Cheers, f Hi Fernando, I can't recreate this on OS X with the current git master branch, which is at 11e7ed. Best wishes, Damon -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] png error with git master, is it just me?
Well, I'm using the system libpng, which is what puzzles me: there should be no need for me to modify my LD_..., and I haven't done so in the past. I'll have to dig into the build tomorrow to figure out exactly what's going on there... Will report back. On Thu, Apr 4, 2013 at 9:24 PM, Damon McDougall damon.mcdoug...@gmail.comwrote: On Thu, Apr 4, 2013 at 10:51 PM, Fernando Perez fperez@gmail.comwrote: Thanks, Damon, for this info. Based on this, I've tested now on another, different system with the same version of linux and can't reproduce it either. Very odd, but it looks like something is amiss on my end, so let me investigate further before anyone burns further cycles on the issue. Cheers, f On Thu, Apr 4, 2013 at 8:06 PM, Damon McDougall damon.mcdoug...@gmail.com wrote: On Thu, Apr 4, 2013 at 6:41 PM, Fernando Perez fperez@gmail.comwrote: Hi folks, I'm getting the following error from a clean build of master on an ubuntu 12.10 machine: longs[junk] python -c 'import matplotlib._png' Traceback (most recent call last): File string, line 1, in module ImportError: /home/fperez/usr/opt/lib/python2.7/site-packages/matplotlib-1.3.x-py2.7-linux-x86_64.egg/matplotlib/_png.so: undefined symbol: png_create_read_struct I hadn't seen anything like this recently, nor can I find similar reports, so I'm wondering if anyone knows what's going on, or if it's an error on my side. I can try to bisect it but I figured I'd ask first in case it's obvious to someone else... Cheers, f Hi Fernando, I can't recreate this on OS X with the current git master branch, which is at 11e7ed. Best wishes, Damon -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 Any time, Fernando. Out of curiosity, is the png_create_read_struct a symbol from libpng? If so, try adding wherever your libpng lives to your LD_LIBRARY_PATH and see what happens. Best wishes, Damon -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Usefulness of Travis-CI
On Wed, Jan 16, 2013 at 12:10 AM, Nelle Varoquaux nelle.varoqu...@gmail.com wrote: Last but not least, maybe we can see what numfocus has to offer. Absolutely! I'll be offline for two weeks, but others on the list can certainly propose this to numfocus on the list and we can look into what can be done, esp. in a way that could also help other projects as well. Also, there's snakebite: http://www.snakebite.net. The project seemed very dormant for a long time, but there's been some activity since: http://www.snakebite.net/network. I'd ping Titus Brown on Twitter (@ctitusbrown) for info... Cheers, f -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Py3 Binaries for OSX?
Hi folks, quick question; on the downloads page (https://github.com/matplotlib/matplotlib/downloads) I only see py27 OSX binaries; is there any official location for Py3 ones? I just had a colleague ask me about them and I couldn't find any in the places I'm used to searching for (github, pypi, superpack). thanks, f -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Py3 Binaries for OSX?
Hi Russell, On Tue, Dec 11, 2012 at 3:14 PM, Russell E. Owen ro...@uw.edu wrote: I have not yet made them, but it's on my to do list. One problem is that there are so many flavors of Python 3 (version 3.2, version 3.3, each in two flavors: for MacOS X 10.5 and later and for MacOS 10.6 and later). Anyone have suggestions for easily building against multiple versions of python? thanks for the info, I totally understand the effort involved and we're all super grateful that you put in this work in the first place! Best, f -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OpenGL backend with Galry
On Sat, Nov 17, 2012 at 4:07 PM, Cyrille Rossant cyrille.ross...@gmail.com wrote: OK so I now have a very experimental proof of concept of how integrating Galry in the IPython notebook. There's a short demo here: http://www.youtube.com/watch?v=taN4TobRS-E I'll put the code on github but there's of course much more to do. I'll also work on a basic matplotlib-like high-level interface that will work in both standard python/ipython consoles, and in the IPython notebook. Awesome! This is really great to see, before long we'll sort out these APIs so all this can be made available easily to end users. Great job! Cheers, f -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OpenGL backend with Galry
Hi Cyrille, On Thu, Nov 15, 2012 at 11:24 AM, Cyrille Rossant cyrille.ross...@gmail.com wrote: I am developing a high-performance interactive visualization package in Python based on PyOpenGL (http://rossant.github.com/galry/). It is primarily meant to be used as a framework for developing complex interactive GUIs (in QT) that deal with very large amounts of data (tens of millions of points). But it may also be used, like matplotlib, as a high-level interactive library to plot and visualize data. quick question: how easy/feasible is WebGL integration? I ask b/c we're starting to get the necessary machinery for easy WebGL visualization in the ipython notebook, see e.g.: http://www.flickr.com/photos/47156828@N06/8183294725 so bringing galry to the notebook with minimal code duplication would be great. I just mention it now in case it helps you make design decisions as you go along. Cheers, f -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OpenGL backend with Galry
Hi Cyrille, On Fri, Nov 16, 2012 at 1:00 PM, Cyrille Rossant cyrille.ross...@gmail.com wrote: Hi Fernando, It would be really great if galry could be integrated in the notebook indeed. Is the code of this demo available somewhere, so that I can get an idea about how this integration works? In theory, galry should be compatible with WebGL because one of the main components of galry is a shader code generator that can produce OpenGL ES-compatible GLSL code. Apart from that, I suppose you have some way of making Javascript and Python communicate? The interaction system of Galry, which is based on QT but with an abstraction layer, could then be plugged to Javascript somehow... Anyway, if I could take a look to the code of this demo, I should be able to evaluate how complicated this integration would be. Yup, it's a bit of a hack right now b/c you need to merge several branches and tools that are still in review, but it's not too bad. You need to start from this branch: https://github.com/ellisonbg/ipython/tree/jsonhandlers and then grab this repo: https://github.com/ipython/jsplugins I would start by testing the d3graph plugin and verify that you can do what I show here (watch ~ 40 seconds): http://www.youtube.com/watch?v=F4rFuIb1Ie4t=40m0s That should give you the basics. Then the webgl visualizer example is here: https://github.com/RishiRamraj/seepymol Cheers, f -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded
Hi folks, On Sun, Nov 11, 2012 at 1:20 PM, Damon McDougall damon.mcdoug...@gmail.com wrote: Yeah that's a great idea. Get the word out. I did: https://speakerdeck.com/fperez/science-and-python-a-interactively-biased-retrospective-of-a-mostly-successful-decade?slide=17 and the crowd actually erupted into spontaneous applause when I pointed out the py3 support! So good job to the whole team. I also put in a slide about John pointing people to the memorial fund: https://speakerdeck.com/fperez/science-and-python-a-interactively-biased-retrospective-of-a-mostly-successful-decade?slide=50 Cheers, f -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded
On Sun, Nov 11, 2012 at 11:47 AM, Benjamin Root ben.r...@ou.edu wrote: Don't see why not. Thanks for the advertising! OK, so it will be! Thanks again for everyone who made this possible! f -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] A sad day for our community. John Hunter: 1968-2012.
Dear friends and colleagues, [please excuse a possible double-post of this message, in-flight internet glitches] I am terribly saddened to report that yesterday, August 28 2012 at 10am, John D. Hunter died from complications arising from cancer treatment at the University of Chicago hospital, after a brief but intense battle with this terrible illness. John is survived by his wife Miriam, his three daughters Rahel, Ava and Clara, his sisters Layne and Mary, and his mother Sarah. Note: If you decide not to read any further (I know this is a long message), please go to this page for some important information about how you can thank John for everything he gave in a decade of generous contributions to the Python and scientific communities: http://numfocus.org/johnhunter. Just a few weeks ago, John delivered his keynote address at the SciPy 2012 conference in Austin centered around the evolution of matplotlib: http://www.youtube.com/watch?v=e3lTby5RI54 but tragically, shortly after his return home he was diagnosed with advanced colon cancer. This diagnosis was a terrible discovery to us all, but John took it with his usual combination of calm and resolve, and initiated treatment procedures. Unfortunately, the first round of chemotherapy treatments led to severe complications that sent him to the intensive care unit, and despite the best efforts of the University of Chicago medical center staff, he never fully recovered from these. Yesterday morning, he died peacefully at the hospital with his loved ones at his bedside. John fought with grace and courage, enduring every necessary procedure with a smile on his face and a kind word for all of his caretakers and becoming a loved patient of the many teams that ended up involved with his case. This was no surprise for those of us who knew him, but he clearly left a deep and lasting mark even amongst staff hardened by the rigors of oncology floors and intensive care units. I don't need to explain to this community the impact of John's work, but allow me to briefly recap, in case this is read by some who don't know the whole story. In 2002, John was a postdoc at the University of Chicago hospital working on the analysis of epilepsy seizure data in children. Frustrated with the state of the existing proprietary solutions for this class of problems, he started using Python for his work, back when the scientific Python ecosystem was much, much smaller than it is today and this could have been seen as a crazy risk. Furthermore, he found that there were many half-baked solutions for data visualization in Python at the time, but none that truly met his needs. Undeterred, he went on to create matplotlib (http://matplotlib.org) and thus overcome one of the key obstacles for Python to become the best solution for open source scientific and technical computing. Matplotlib is both an amazing technical achievement and a shining example of open source community building, as John not only created its backbone but also fostered the development of a very strong development team, ensuring that the talent of many others could also contribute to this project. The value and importance of this are now painfully clear: despite having lost John, matplotlib continues to thrive thanks to the leadership of Michael Droetboom, the support of Perry Greenfield at the Hubble Telescope Science Institute, and the daily work of the rest of the team. I want to thank Perry and Michael for putting their resources and talent once more behind matplotlib, securing the future of the project. It is difficult to overstate the value and importance of matplotlib, and therefore of John's contributions (which do not end in matplotlib, by the way; but a biography will have to wait for another day...). Python has become a major force in the technical and scientific computing world, leading the open source offers and challenging expensive proprietary platforms with large teams and millions of dollars of resources behind them. But this would be impossible without a solid data visualization tool that would allow both ad-hoc data exploration and the production of complex, fine-tuned figures for papers, reports or websites. John had the vision to make matplotlib easy to use, but powerful and flexible enough to work in graphical user interfaces and as a server-side library, enabling a myriad use cases beyond his personal needs. This means that now, matplotlib powers everything from plots in dissertations and journal articles to custom data analysis projects and websites. And despite having left his academic career a few years ago for a job in industry, he remained engaged enough that as of today, he is still the top committer to matplotlib; this is the git shortlog of those with more than 1000 commits to the project: 2145 John Hunter jdh2...@gmail.com 2130 Michael Droettboom mdb...@gmail.com 1060 Eric Firing efir...@hawaii.edu All of this was done by a man who had three children to raise
Re: [matplotlib-devel] A sad day for our community. John Hunter: 1968-2012.
On Wed, Aug 29, 2012 at 8:42 PM, Jim Benson jben...@nofs.navy.mil wrote: My apologies also for replying to the lists (double post), but the above web address did not work for me under Safari Version 5.1.7 (6534.57.2) (there was only one other post when i tried to post). I only got a Please complete the CAPTCHA, The message i attempted to post was: There's a little CAPTCHA which is a little arithmetic problem. Did you by any chance miss that? Cheers, f -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Stacked plotting in matplotlib
On Thu, Aug 23, 2012 at 4:21 PM, Eric Firing efir...@hawaii.edu wrote: OK, here are mine: I oppose overloading plot with a stacked kwarg and functionality. It is complicated enough as it is. I don't see any problem with having stackplot and hist(..., stacked=True). They are just not all that similar. Nor are plot and stackplot so very similar. But stacked and non-stacked histograms *are* very similar, so using the kwarg to turn on stacking there makes sense. Quick q: how would things like log plots be handles for the stacked case? Log plots are really just axis scale choices on a normal plot, but for historical reasons they happen to be implemented via a bunch of different functions. But for that reason, any interface changes that make sense for plot pretty should also apply to the *log* functions, no? Cheers, f -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Stacked plotting in matplotlib
Hi Eric, On Thu, Aug 23, 2012 at 7:56 PM, Eric Firing efir...@hawaii.edu wrote: I'm not sure I understand what you are getting at, but I don't think there should be any interface changes for plot or for their log variants. I probably phrased my question poorly. I'm just wondering, how would one use the proposed stackplot function to obtain a stacked plot but that used log axes (x, y or both)? Cheers, f -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib.github.com
On Fri, Aug 10, 2012 at 7:26 AM, Michael Droettboom md...@stsci.edu wrote: Supporting existing links to matplotlib.sourceforge.net is of course very important, and I would put whatever redirects we need to keep those working in any event. Actually, why not move all the official domain machinery to matplotlib.org? That can be managed with the github tools, and github/pypi can be used for downloads with a far simpler workflow than the particular incarnation of UX hell that is sourceforge's upload system... We've been doing that for a while with ipython since we moved to ipython.org, and we've been very happy. With suitable redirects in place, no google rank will be lost nor will users be confused, and gradually everyone's bookmarks and habits will transition to mpl.org. If you guys want to do that and run into any issues, we (ipython) will be happy to share how it works for us and help out. Just a thought... f -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib.github.com
On Fri, Aug 10, 2012 at 1:00 PM, Michael Droettboom md...@stsci.edu wrote: That is the end goal. I'm talking simply about the static webpage hosting here. If I recall correctly, I think the space limitations on github used to be a problem for us, which is why we haven't used it as the canonical web hosting. But that doesn't seem to be a problem anymore. I was mostly hoping that anyone involved in the decision to not go with github's web hosting at the time could remember any other downsides. Glad to hear that! The github folks have been very flexible in their application of the quotas and have always said that any OSS project that has a legitimate need for additional space will always be granted. They just don't want github to become somebody's picture/music/movie backup system for free, that's all. I have never seen them actually enforce the limits on any OSS project, but I'd be happy to put you in touch directly with someone there if you want a more direct clarification on this. Best, f -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.1.1rc2 tarballs are up
On Sat, Jun 30, 2012 at 11:46 AM, John Hunter jdh2...@gmail.com wrote: Well, looks like we better get moving then ;-) Go MPL! It would be great to have matching releases of IPython and MPL, just in time for the Debian freeze and SciPy 2012 :) Cheers, f -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.1.1rc2 tarballs are up
On Sat, Jun 30, 2012 at 12:55 PM, John Hunter jdh2...@gmail.com wrote: OK, the v1.1.1 tarball is up at https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1 and this is now the download folder the main site points to. I'm leaving up the rc2 binaries til Russell and Christoph can build v1.1.1 binaries and we get them uploaded. Sandro, if you're around, you are good to go for including this in debian, hopefully squeaking in under the freeze (sorry for the last minute push). I will hold off on the users and announce list emails til the updated binaries are up. Tagged: git tag v1.1.1 7e47149a7b05f8e5cf1cc899a7e4e7c90dd4244f Thanks to all! Awesome, congrats! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.1.1rc2 tarballs are up
On Sat, Jun 30, 2012 at 1:42 PM, Sandro Tosi mo...@debian.org wrote: ... we're already too late for the Debian freeze :( the diff is quite small, so I'll ask for a freeze exception. Wow, I guess it paid off for us to stay up until 2am last night to get IPython in... Our diff was enormous so we would have not been allowed in at al. Whew :) I hope they'll grant the exception for mpl... Cheers, f -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.1.1rc2 tarballs are up
On Sat, Jun 30, 2012 at 1:54 PM, John Hunter jdh2...@gmail.com wrote: Yeah, the diff Sandro is referring to for us is just between rc2 and final. Hopefully he can argue that since r1.1.1-rc2 is already in, they can accept this minor diff to final. In our case unfortunately we didn't have time to cut an RC, so our diff beta1-HEAD was way too big. We just had to push through the work. Let's just say that my wife was not amused with my Friday night being a non-stop IRC marathon with Min because we really need to get in before debian freeze tonight!!! :) f -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.1.1rc2 tarballs are up
On Sat, Jun 30, 2012 at 3:07 PM, Sandro Tosi mo...@debian.org wrote: It's probably a nomenclature difference: it's a freeze exception so asking to overrule the freeze in place and allow a package to enter testing, but it must match basic rules, but in this case they are not matched. Just out of curiosity, what is the mismatch? (I believe you, I just know very little about the debian process). f -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] [ANN] PyData workshop videos are up online, including panel with Guido
Hi all, just to let you know that the videos from the PyData workshop we held at Google a couple of weeks ago are now online (not all talks are up yet, so watch the page over the next few days if a talk you wanted to see isn't posted yet): http://marakana.com/s/2012_pydata_workshop,1090/index.html The panel discussion with Guido that we talked about on these lists is in there; I hope to write up a short summary about it soon. Many thanks to Simeon Franklin and the rest of the Marakana team for doing all this work (for free)! Cheers, f -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Discussion with Guido van Rossum and (hopefully) core python-dev on scientific Python and Python3
Hi folks, [ I'm broadcasting this widely for maximum reach, but I'd appreciate it if replies can be kept to the *numpy* list, which is sort of the 'base' list for scientific/numerical work. It will make it much easier to organize a coherent set of notes later on. Apology if you're subscribed to all and get it 10 times. ] As part of the PyData workshop (http://pydataworkshop.eventbrite.com) to be held March 2 and 3 at the Mountain View Google offices, we have scheduled a session for an open discussion with Guido van Rossum and hopefully as many core python-dev members who can make it. We wanted to seize the combined opportunity of the PyData workshop bringing a number of 'scipy people' to Google with the timeline for Python 3.3, the first release after the Python language moratorium, being within sight: http://www.python.org/dev/peps/pep-0398. While a number of scientific Python packages are already available for Python 3 (either in released form or in their master git branches), it's fair to say that there hasn't been a major transition of the scientific community to Python3. Since there is no more development being done on the Python2 series, eventually we will all want to find ways to make this transition, and we think that this is an excellent time to engage the core python development team and consider ideas that would make Python3 generally a more appealing language for scientific work. Guido has made it clear that he doesn't speak for the day-to-day development of Python anymore, so we all should be aware that any ideas that come out of this panel will still need to be discussed with python-dev itself via standard mechanisms before anything is implemented. Nonetheless, the opportunity for a solid face-to-face dialog for brainstorming was too good to pass up. The purpose of this email is then to solicit, from all of our community, ideas for this discussion. In a week or so we'll need to summarize the main points brought up here and make a more concrete agenda out of it; I will also post a summary of the meeting afterwards here. Anything is a valid topic, some points just to get the conversation started: - Extra operators/PEP 225. Here's a summary from the last time we went over this, years ago at Scipy 2008: http://mail.scipy.org/pipermail/numpy-discussion/2008-October/038234.html, and the current status of the document we wrote about it is here: file:///home/fperez/www/site/_build/html/py4science/numpy-pep225/numpy-pep225.html. - Improved syntax/support for rationals or decimal literals? While Python now has both decimals (http://docs.python.org/library/decimal.html) and rationals (http://docs.python.org/library/fractions.html), they're quite clunky to use because they require full constructor calls. Guido has mentioned in previous discussions toying with ideas about support for different kinds of numeric literals... - Using the numpy docstring standard python-wide, and thus having python improve the pathetic state of the stdlib's docstrings? This is an area where our community is light years ahead of the standard library, but we'd all benefit from Python itself improving on this front. I'm toying with the idea of giving a lighting talk at PyConn about this, comparing the great, robust culture and tools of good docstrings across the Scipy ecosystem with the sad, sad state of docstrings in the stdlib. It might spur some movement on that front from the stdlib authors, esp. if the core python-dev team realizes the value and benefit it can bring (at relatively low cost, given how most of the information does exist, it's just in the wrong places). But more importantly for us, if there was truly a universal standard for high-quality docstrings across Python projects, building good documentation/help machinery would be a lot easier, as we'd know what to expect and search for (such as rendering them nicely in the ipython notebook, providing high-quality cross-project help search, etc). - Literal syntax for arrays? Sage has been floating a discussion about a literal matrix syntax (https://groups.google.com/forum/#!topic/sage-devel/mzwepqZBHnA). For something like this to go into python in any meaningful way there would have to be core multidimensional arrays in the language, but perhaps it's time to think about a piece of the numpy array itself into Python? This is one of the more 'out there' ideas, but after all, that's the point of a discussion like this, especially considering we'll have both Travis and Guido in one room. - Other syntactic sugar? Sage has a..b = range(a, b+1), which I actually think is both nice and useful... There's also the question of allowing a:b:c notation outside of [], which has come up a few times in conversation over the last few years. Others? - The packaging quagmire? This continues to be a problem, though python3 does have new improvements to distutils. I'm not really up to speed on the situation, to be frank. If we want to bring this up,
[matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...
Hi all,
in ipython for the qtconsole and notebook, we send inline figures using
fig.canvas.print_figure(bytes_io, format=fmt, bbox_inches='tight')
as seen here:
https://github.com/ipython/ipython/blob/master/IPython/core/pylabtools.py#L104
However, this produces truncated figure titles. Consider this code:
f, ax = plt.subplots()
ax.plot(rand(100))
ax.set_title('Axis title')
f.suptitle('Figure title');
###
which produces this in the notebook:
http://img546.imageshack.us/img546/5448/selection001c.png
As you can see, the figure title gets truncated.
We started using bbox_inches='tight' because otherwise in many cases
the images were coming back with insane amounts of white padding, and
Stefan vdW suggested this fix. But it seems that in other cases it
actually loses data, which is even worse...
A slightly more complicated example, using basemap, not only truncates
the title but also all the x and y labels:
from mpl_toolkits.basemap import Basemap
lon0, lat0, lon1, lat1 = (84.38, 26.22, 88.9, 29.8)
resolution = 'i'
parallels = np.linspace(lat0, lat1, 5)
meridians = np.linspace(lon0, lon1, 5)
f, ax = plt.subplots()
m = Basemap(lon0, lat0, lon1, lat1, resolution=resolution, ax=ax)
m.drawcountries(color=(1,1,0)) # country boundaries in pure yellow
m.drawrivers(color=(0,1,1)) # rivers in cyan
m.bluemarble() # NASA bluemarble image
m.drawmeridians(meridians, labels=[0,0,0,1], fmt='%.2f')
m.drawparallels(parallels, labels=[1,0,0,0], fmt='%.2f')
f.suptitle('The Himalayas');
#
produces:
http://img192.imageshack.us/img192/986/selection002e.png
This looks like a matplotlib bug, but I have no idea how easy it is to
fix. In the meantime, should we in ipython just revert back to not
using bbox_inches, or is there an alternative?
Thanks!
f
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...
On Sun, Jan 29, 2012 at 10:22 AM, Nathaniel Smith n...@pobox.com wrote: Not a bug. There are only so many artist objects we assume for determining the tight bbox. Suptitle is not one of them. Why is this the desired behavior? I was just going to ask the same. And as Jeff Whitaker points out, all x and y (longitude/latitude) labels also get clipped. I can understand not considering the position of arbitrarily laid out text that a user could have put in a random location. But clipping something that is provided by a standard api call, such as a figure title, does seem much more like a bug than a feature to me, I'm afraid. Cheers, f -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...
On Sun, Jan 29, 2012 at 10:30 AM, Fernando Perez fperez@gmail.com wrote: And as Jeff Whitaker points out, all x and y (longitude/latitude) labels also get clipped. I meant to put at the end of that sentence: in the basemap example. The simple plot has no clipping issues with labels, only with the suptitle. Cheers, f -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...
On Sun, Jan 29, 2012 at 11:25 AM, Benjamin Root ben.r...@ou.edu wrote: I certainly have no objections. Most likely it was an oversight. OK, thanks. Filed so at least there's a record of it: https://github.com/matplotlib/matplotlib/issues/688 We'll find a workaround in ipython in the meantime. Cheers, f -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] All information about SF-filed bugs is inaccessible at SF
Hi all, I don't know if you guys were aware of this, and if there's anything that can be done, but I just realized that all the bugs tagged SF: https://github.com/matplotlib/matplotlib/issues?labels=SFsort=createddirection=descstate=openpage=1 have useless links to their SF original pages, b/c SF has completely closed access to the old tracker, e.g.: http://sourceforge.net/tracker/?func=detailaid=3044267group_id=80706atid=560723 I don't know if in the migration, the github issue has all the information that was in the old bug. In ipython when we migrated from launchpad we kept links to the old issues as well: https://github.com/ipython/ipython/issues/13 == https://bugs.launchpad.net/ipython/+bug/508971 but fortunately launchpad continues to show the original bug in full. This is useful for a number of reasons. Launchpad is nice enough to let you disable the bug tracker for new bug submissions while leaving all existing bug pages still available. This is much more sensible than what SF seems to be doing. I don't know there's much we can do, since this is really a SourceForge issue. But I wanted to mention it at least; if there's important information buried in there, it might be possible to reopen the SF tracker temporarily, scrape the bug pages for everything and close it again. I just don't know if the orignal bug transfer process managed to move everything or not... Cheers, f -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] All information about SF-filed bugs is inaccessible at SF
Hi Eric,
On Sun, Jan 29, 2012 at 1:35 PM, Eric Firing efir...@hawaii.edu wrote:
Yes, this became evident right away after the transition; in addition,
there was a coordination glitch such that quite a few bugs that I had
closed on SF, trying to clear out some junk before the transition, ended
up getting resurrected on github, complete with dead links.
Got it, I missed that previous discussion.
This is a triage situation; we have to consider the cost/benefit
tradeoff of various ways of dealing with the mess, and with the glut of
bug and other reports. The fact is that we were way behind in dealing
with the SF bugs, and we are falling behind in dealing with github bugs.
I think the best approach is to be fairly brutal in closing bug reports.
We don't have the developer time to deal with very many. Those that
accumulate faster than we can deal with them merely cost us time
whenever one of us scans the set of reports in an attempt to get the
list under control by finding ways to close a few.
It's unfortunate that github doesn't offer a 'priority' field so that
one can threshold on it. We use 'prio-X' labels with X in {low,
medium, high, blocker} as a substitute, but there's no way to see 'all
with prioirty = high', for example.
But we've been trying to aggressively label everything with a
priority, and in practice only high/blocker ones really get worked on,
unless someone external shows up with a pull request for anything
below that.
My take right now is that even bugs are almost all lower priority than
pull requests: if someone took the time to actually contribute code, I
think it's critically important to get back to them with feedback.
Not having a timely review and response to a PR is the best way to
discourage potential new contributors. My hope is that by being
pretty aggressive on that, we'll grow our developer pool enough to be
able to make some headway into the bug backlog. One can dream... :)
So, the dead SF links are the least of our problems; not that big a
deal. We would lose little by simply closing all of the transfered
reports; or at least closing all of those older than some threshold.
You're probably right, though I sort of prefer to keep an open bug if
the problem really isn't resolved. But marking all SF bugs with
priority low (if you decide to create a similar set of priority
labels) would at least indicate this intent, and let you focus only on
the real problems more easily. Because actually closing them raises
the risk that they will get re-reported, and then it's even more work
to start linking bugs or closing dupes.
Ultimately though, we're all (mpl, ipython, scipy, etc) suffering from
the same problem: despite the enormous growth in the user base of the
scientific python tools in the last few years, the developer pool has
not really grown at the same rate. Our projects are have dangerously
small core teams. I wish I knew how to change this...
Cheers,
f
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Should we update sample_data in the old SVN repo?
On Sat, Dec 17, 2011 at 11:56 AM, John Hunter jdh2...@gmail.com wrote:
Did you test? I did enable the same old fer_perez sf account you've always
had. I was just referring to you by your email moniker in the post above. If
it's still not working, I'll see if there is some other setting that needs
tweaking.
OK, it worked now. I was using before an auto-generated password that
was OK for web login but had funny quote characters that were
confusing the svn login (probably being escaped by the shell). I
changed that to a more normal password, and now I was able to push.
Sorry for the confusion, and thanks!
Doing these updates should be easy and infrequent enough that I'm
happy to push them by hand when needed, just ping me.
Checked and the system mpl on ubuntu 11.10 can now fetch stinkbug correctly:
In [3]: matplotlib.__version__
Out[3]: '1.0.1'
In [4]: cbook.get_sample_data('stinkbug.png')
Out[4]: open file
'/home/fperez/.matplotlib/sample_data/stinkbug.png', mode 'rb' at
0x2860b70
Cheers,
f
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Should we update sample_data in the old SVN repo?
Hi all, I just added the stinkbug.png file to the sample_data repo so the Image tutorial and other examples using this image could be run by users making cbook.get_sample_data calls. But while it works fine with a reasonably recent MPL, I tested with the system one in Ubuntu 11.10, and it does not find the file. The reason is simply that this version of mpl still had the old SVN sample_data repo URL: baseurl = 'http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/sample_data/' So the problem is that any users of 11.10 are now stuck with a 'frozen in time' sample_data repo. We can fix this easily by simply pushing over to sample_data an update with any new files in the github one. Since that repo changes fairly slowly and the changes typically involve just putting new files in and no actual code, it should be fairly easy to do manually. What do folks think? If you agree, I'm happy to push an update now (I'm assuming the SVN repo is still writable, which might not be the case...). Cheers, f -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Should we update sample_data in the old SVN repo?
On Fri, Dec 16, 2011 at 3:34 PM, Eric Firing efir...@hawaii.edu wrote: If you are willing and able to do it, please go ahead. I can't think of any problem it would create. (But I don't know whether the repo is writable.) Great, thanks. I'll see if I can push and will report back. If it doesn't work, we'll see if John can later restore write access to it. Cheers, f -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Should we update sample_data in the old SVN repo?
On Fri, Dec 16, 2011 at 5:11 PM, Eric Firing efir...@hawaii.edu wrote: Nope: efiring@manini:~/temp/sample_data_svn$ svn commit -mSync SVN repo with contents in current git repo svn: Commit failed (details follow): svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/svnroot/matplotlib/!svn/act/9b074418-cd32-4039-88d8-06b46c4c8764' I think the repo was frozen when we moved to github. OK, thanks for trying. Next week we can see if John can reopen it for this. I think there's no danger of anyone mistakenly committing any real work there anymore. Cheers, f -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] bbox_inches='tight' error, is this an mpl bug or misuse on my part?
Hi all, I'm getting an error (with current mpl master) illustrated by this code: ### from cStringIO import StringIO import matplotlib.pyplot as plt import matplotlib.lines as lines fig = plt.figure() l1 = lines.Line2D([0, 1], [0, 1], transform=fig.transFigure, figure=fig) l2 = lines.Line2D([0, 1], [1, 0], transform=fig.transFigure, figure=fig) fig.lines.extend([l1, l2]) fig.canvas.draw() sio = StringIO() fig.canvas.print_figure(sio, format='png', bbox_inches='tight') ### Is this a bug, or am I misusing print_figure? I don't want to open a ticket if it's not a real bug, if it is one I'll file it on gh. Thanks, f -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Who's packaging mpl for ubuntu? The package is doing something quite nasty on Oneiric..
Howdy, do we have the ubuntu packaging team on this list, or any way to contact them? Today Stefan and I burned a few hours tracking this bug down, again, which I'd already debugged a couple of months ago and totally forgotten about: https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/871176 It would be great if anyone here has any contacts with the ubuntu mpl team and this could get fixed. On launchpad there's been zero response, so I'm trying this way now... Cheers, f -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Heads-up: master badly broken, syntaxerror in setup.py
(master)longs[matplotlib] python setup.py File setup.py, line 281 (float(i) / len(filtered) * 100.0), end='\r') ^ SyntaxError: invalid syntax Sorry, can't debug it right now... f -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Merging Python 3 branch?
Hey guys, On Fri, Oct 28, 2011 at 11:41 AM, Eric Firing efir...@hawaii.edu wrote: 1) In the coding guide, it might be good to have notes (tips) about how to maintain compatibility, or at least references to such notes. I have read about py3 but have never worked with it. +1 for the py3 merge! IPython master is already fully on py3 and we should be releasing very soon 0.12 with this. So once mpl is merged, it will be possible to have from either releases or master, the full 'minimal stack' (numpy/scipy/mpl/sympy/cython/ipython) on py3, which I think is awesome. In case it's of any use to you guys, feel free to pillage our little bag of utilities for py3 compatibility: https://github.com/ipython/ipython/blob/master/IPython/utils/py3compat.py By grepping the IPython sources for py3compat imports you can also see how we use them, in case it helps. Best, f ps - full credit on all this in IPython goes to @takluyver, who joined the project initially just based on his need to have ipython on py3 and has turned out to be an all-around amazing member of the project. I'm sure if you guys hit any bumps he'd be able to help out, as he uses py3 regularly as his default platform and therefore knows quite a bit about it. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] KnownFailure getting added as a global nose plugin in ubuntu 11.10 - bad idea
Hi all, I'm writing here in the hopes that both the ubuntu packagers are on this list, and that we change things a bit in mpl to prevent this problem from happening. After a nasty debugging marathon with the IPython test suite failing on Ubuntu 11.10 beta -- see details at https://github.com/ipython/ipython/issues/823, I finally tracked the problem down to this little gem: amirbar[matplotlib-1.0.1.egg-info] pwd /usr/share/pyshared/matplotlib-1.0.1.egg-info amirbar[matplotlib-1.0.1.egg-info] cat entry_points.txt [nose.plugins] KnownFailure = matplotlib.testing.noseclasses:KnownFailure I'm not sure why the packagers decided to register this as a global plugin, but it makes a mess. You can read some of the details in the thread above if you're really interested. I've filed the ubuntu bug here: https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/871176 But I suggest we actually *remove* this code from matplotlib altogether. In ipython we do carry a copy of the same code, but we load it very conditionally, only if numpy isn't found: https://github.com/ipython/ipython/blob/master/IPython/external/decorators/_numpy_testing_noseclasses.py This ensures we'll never collide with the 'real' version in numpy. For IPython, numpy isn't a dependency, so we have to do this. But mpl always has numpy around, so perhaps it would be better to simply use it from numpy? Cheers, f -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] propose 1.1.0 release tomorrow
On Thu, Oct 6, 2011 at 11:03 AM, Benjamin Root ben.r...@ou.edu wrote: That's valid. I guess I am just wondering if there is a decent error message to the user explaining that the test could not proceed. Rig the test runner to properly skip them instead of failing? The test data should be considered a dependency for those tests, and absent the dependency, the users simply get less tests, but not a ton of failures. Not saying this should be done *now*, but I think in general having users be able to run the test suite in their environments is useful, even if parts are skipped for some reason. You never know when that will uncover true failures... That's the approach we take in ipython: we have a lot of tests that depend on various tools/environment/os, that simply get skipped. In fact, there is no way to run the *entire* ipython test suite in one go, since there are mutually exclusive tests (like things that only run on OSX or Windows). So inevitably, every test run is *always* partial. Once you think about it that way, then this is just one more dependency to be handled just like any other. Cheers, f -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
On Tue, Sep 6, 2011 at 9:53 AM, Michael Droettboom md...@stsci.edu wrote: It occurred to me that it's also possible to file pull requests very early on while working on a branch. This would make these branches that others may care about more visible. We would just want some convention to say wait -- this branch isn't done yet, don't merge. We do that all the time: we simply say this PR isn't meant for merge yet, just to get the discussion going while the problem is worked on. In IPython, we've merged over 250 PRs since switching to github, and I think we've had *two* long-lived branches in the main repo (newparallel and htmlnotebook). I still think that's the right approach, as situations like these should be exceptional. I think getting used to many long-lived branches in the main repo precisely encourages the kind of workflow that leads to hard-to-review, hard-to-integrate branches. By *not* putting them in the main repo, there's a certain pressure on keeping things small, self-contained and easy to review in little pull requests. Each time we've done one of these monster branches there's been a solid reason to do it, but it has required summoning extra resources, committing big chunks of time for difficult and lengthy review periods, and being very careful about how they can go out of sync with the rest of the repo. So while occasionally necessary, these things have such a high cost that I absolutely want a workflow that discourages them in everyday practice. HTH, f -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
On Wed, Aug 31, 2011 at 20:16, Matthew Brett matthew.br...@gmail.com wrote: 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?). Limited internet access here, so no time for a long discussoin... Just to say that I'm totally in agreement with Matthew here. We only make branches in the main ipython repo under exceptional circumstances, when there's a major piece of work that requires multiple-developer commit collaboration to beat into shape and cross-pulling from personal repos would just get annoying. But once those are ready and merge we delete them as visible branches right away. For example, since we moved to github, we've only done this *twice*: once for the big parallel rewrite, and once for the notebook work. Both of these were *major* efforts that took months to shape up, so it made sense to have them in there. But we make such a decision only for such special cases, otherwise following the workflow Matthew points out seems to work really well. Once you get into the habit of using multiple remotes to get a handle of an entire team's worth of contributions to a project, you realize how simple and effective it is. Cheers, f -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: [IPython-dev] Announcing shrubbery
FYI -- Forwarded message -- From: Grahame Bowland grah...@angrygoats.net Date: Sun, Aug 21, 2011 at 2:18 AM Subject: [IPython-dev] Announcing shrubbery To: ipython-...@scipy.org Hi everyone I've spent the last few days coming up with a Python 3 distribution of iPython and friends for Mac OS X. It now works (mostly), and I thought I'd share it. The home page is here: https://github.com/grahame/shrubbery and I've put an experimental installer image here: https://github.com/downloads/grahame/shrubbery/shrubbery.pkg For a long time I've maintained my Python setup by hand, installing packages into /usr/local and eventually having a huge mess. Hence this project - a distribution of software for Mac OS to make it easier for people to get started with iPython. I've targeted Python 3 in the hope it'll encourage the porting of more software to the new version of the language. There's not too much Mac OS specific about this, except that on Linux you'd probably want to get packages from your distribution. If anyone wants to make it work on other platforms that'd be great. Cheers Grahame ___ IPython-dev mailing list ipython-...@scipy.org http://mail.scipy.org/mailman/listinfo/ipython-dev -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plan for cutting v1.1.0?
On Wed, Jul 13, 2011 at 1:58 PM, Benjamin Root ben.r...@ou.edu wrote: I would love to find out if there is some way to embed a video using sphinx have a look at the sources for: http://fperez.org/talks Cheers, f -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Update Qt import logic for event loop handling?
On Mon, Jul 4, 2011 at 2:31 PM, Eric Firing efir...@hawaii.edu wrote: See https://github.com/matplotlib/matplotlib/pull/390. Excellent, thanks! Ran tests and commented on the PR. Cheers, f -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] EPS export broken in HEAD?
Howdy,
a simple
plot(rand(100))
savefig('foo.eps')
is giving me the traceback below. Is it something I'm doing wrong on my side?
Running on linux, ubuntu 10.10, python2.6.
Thanks for any tips...
f
---
TypeError Traceback (most recent call last)
/home/fperez/research/dif-tx/src/python/ipython-input-2-3f85c055f45e
in module()
1 savefig('foo.eps')
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/pyplot.pyc
in savefig(*args, **kwargs)
426 def savefig(*args, **kwargs):
427 fig = gcf()
-- 428 return fig.savefig(*args, **kwargs)
429
430 @docstring.copy_dedent(Figure.ginput)
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/figure.pyc
in savefig(self, *args, **kwargs)
1160 kwargs.setdefault('edgecolor',
rcParams['savefig.edgecolor'])
1161
- 1162 self.canvas.print_figure(*args, **kwargs)
1163
1164 if transparent:
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_qt4agg.pyc
in print_figure(self, *args, **kwargs)
151
152 def print_figure(self, *args, **kwargs):
-- 153 FigureCanvasAgg.print_figure(self, *args, **kwargs)
154 self.draw()
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backend_bases.pyc
in print_figure(self, filename, dpi, facecolor, edgecolor,
orientation, format, **kwargs)
1977 orientation=orientation,
1978 bbox_inches_restore=_bbox_inches_restore,
- 1979 **kwargs)
1980 finally:
1981 if bbox_inches and restore_bbox:
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backend_bases.pyc
in print_eps(self, *args, **kwargs)
1744 from backends.backend_ps import FigureCanvasPS # lazy import
1745 ps = self.switch_backends(FigureCanvasPS)
- 1746 return ps.print_eps(*args, **kwargs)
1747
1748 def print_pdf(self, *args, **kwargs):
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
in print_eps(self, outfile, *args, **kwargs)
933
934 def print_eps(self, outfile, *args, **kwargs):
-- 935 return self._print_ps(outfile, 'eps', *args, **kwargs)
936
937
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
in _print_ps(self, outfile, format, *args, **kwargs)
966 self._print_figure(outfile, format, imagedpi,
facecolor, edgecolor,
967orientation, isLandscape, papertype,
-- 968**kwargs)
969
970 def _print_figure(self, outfile, format, dpi=72,
facecolor='w', edgecolor='w',
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
in _print_figure(self, outfile, format, dpi, facecolor, edgecolor,
orientation, isLandscape, papertype, **kwargs)
1059 bbox_inches_restore=_bbox_inches_restore)
1060
- 1061 self.figure.draw(renderer)
1062
1063 if dryrun: # return immediately if dryrun (tightbbox=True)
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/artist.pyc
in draw_wrapper(artist, renderer, *args, **kwargs)
53 def draw_wrapper(artist, renderer, *args, **kwargs):
54 before(artist, renderer)
--- 55 draw(artist, renderer, *args, **kwargs)
56 after(artist, renderer)
57
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/figure.pyc
in draw(self, renderer)
872 dsu.sort(key=itemgetter(0))
873 for zorder, func, args in dsu:
-- 874 func(*args)
875
876 renderer.close_group('figure')
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/artist.pyc
in draw_wrapper(artist, renderer, *args, **kwargs)
53 def draw_wrapper(artist, renderer, *args, **kwargs):
54 before(artist, renderer)
--- 55 draw(artist, renderer, *args, **kwargs)
56 after(artist, renderer)
57
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/axes.pyc
in draw(self, renderer, inframe)
1981
1982 for zorder, a in dsu:
- 1983 a.draw(renderer)
1984
1985 renderer.close_group('axes')
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/artist.pyc
in draw_wrapper(artist, renderer, *args, **kwargs)
53 def draw_wrapper(artist, renderer, *args, **kwargs):
54 before(artist, renderer)
--- 55 draw(artist, renderer, *args, **kwargs)
56 after(artist, renderer)
57
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/axis.pyc
in draw(self, renderer, *args, **kwargs)
1035
1036 ticks_to_draw = self._update_ticks(renderer)
- 1037 ticklabelBoxes, ticklabelBoxes2 =
self._get_tick_bboxes(ticks_to_draw, renderer)
1038
1039 for
Re: [matplotlib-devel] Bleeding edge repository location
On Thu, Apr 14, 2011 at 7:53 AM, John Hunter jdh2...@gmail.com wrote: Any idea when this will be back up -- building the docs on my solaris box here at work is proving more difficult than expected (segfaults due to a bug in numpy's complex dtype handling, reported months ago but still unfixed) Give me an hour or so, I'll ping you back... f -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bleeding edge repository location
On Thu, Apr 14, 2011 at 3:01 PM, John Hunter jdh2...@gmail.com wrote: Docs are now pushed to sf -- preliminary look looks good. Thanks Fernando for the build resources. My pleasure; my office has no heating, but everytime a mpl doc build happens it gets a little less chilly here :) f -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mpl@wired
http://www.wired.com/wiredscience/2011/04/crashing-into-wall/ need to teach him about annotations, though, because the acceleration plot looks annotated by hand after the fact (from the fonts, I'm guessing on a Mac, maybe with Keynote). cheers f -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New issue tracker on GitHub
On Mon, Apr 11, 2011 at 2:19 PM, Darren Dale dsdal...@gmail.com wrote: Brilliant, whatever they use allows uploading attachments. I know this isn't ideal, but a workaround for screenshots/images in mpl bug reports would be to upload them to something like imgur (free - no registration required): http://imgur.com/tools/ and then put the image link in the markdown for the bug report: https://github.com/blog/831-issues-2-0-the-next-generation#comment-11405 I realize it's a workaround, but better than nothing... f -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bleeding edge repository location
On Tue, Apr 12, 2011 at 4:13 PM, John Hunter jdh2...@gmail.com wrote: Yes, I'll get thus fixed ASAP John, quick note: our local network is down (firewall transfer went awry), so if you need to rebuild the docs, you'll need to do it on another system than my box (I'm using a laptop over wireless to send this). Cheers, f -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] [ANN] IPython 0.10.2 is out
Hi all, we've just released IPython 0.10.2, full release notes are below. Downloads in source and windows binary form are available in the usual location: http://ipython.scipy.org/dist/ as well as on github: http://github.com/ipython/ipython/archives/rel-0.10.2 and at the Python Package Index (which easy_install will use by default): http://pypi.python.org/pypi/ipython so at any time you should find a location with good download speeds. You can find the full documentation at: http://ipython.github.com/ipython-doc/rel-0.10.2/html/ http://ipython.github.com/ipython-doc/rel-0.10.2/ipython.pdf Enjoy! Fernando (on behalf of the whole IPython team) Release 0.10.2 == IPython 0.10.2 was released April 9, 2011. This is a minor bugfix release that preserves backward compatibility. At this point, all IPython development resources are focused on the 0.11 series that includes a complete architectural restructuring of the project as well as many new capabilities, so this is likely to be the last release of the 0.10.x series. We have tried to fix all major bugs in this series so that it remains a viable platform for those not ready yet to transition to the 0.11 and newer codebase (since that will require some porting effort, as a number of APIs have changed). Thus, we are not opening a 0.10.3 active development branch yet, but if the user community requires new patches and is willing to maintain/release such a branch, we'll be happy to host it on the IPython github repositories. Highlights of this release: - The main one is the closing of github ticket #185, a major regression we had in 0.10.1 where pylab mode with GTK (or gthread) was not working correctly, hence plots were blocking with GTK. Since this is the default matplotlib backend on Unix systems, this was a major annoyance for many users. Many thanks to Paul Ivanov for helping resolve this issue. - Fix IOError bug on Windows when used with -gthread. - Work robustly if $HOME is missing from environment. - Better POSIX support in ssh scripts (remove bash-specific idioms). - Improved support for non-ascii characters in log files. - Work correctly in environments where GTK can be imported but not started (such as a linux text console without X11). For this release we merged 24 commits, contributed by the following people (please let us know if we ommitted your name and we'll gladly fix this in the notes for the future): * Fernando Perez * MinRK * Paul Ivanov * Pieter Cristiaan de Groot * TvrtkoM -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Scientific Python at SIAM CSE 2011 conference
Hi all, sorry for the massive cross-post, but since all these projects were highlighted with talks at this event, I figured there would be interest... Hans-Petter Langtangen, Randy LeVeque and I organized a set of Python-focused sessions at the recent SIAM Computational Science and Engineering conference, with talks on numpy/scipy, cython, matplotlib, ipython, sympy, as well as application-oriented talks on astronomy and femhub. For those interested: - The slides: http://fperez.org/events/2011_siam_cse/ - A blog post: http://blog.fperez.org/2011/04/python-goes-to-reno-siam-cse-2011.html - Some pictures: https://picasaweb.google.com/fdo.perez/SIAMCSE2011InReno# Back to being quiet... f -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Simple animation test
On Wed, Mar 2, 2011 at 3:00 PM, Ryan May rma...@gmail.com wrote: I trust you're going to check in that completely awesome example. BTW, that completely awesome example was just demoed in front of a standing-room only audience at the SIAM CSE 11 meeting :) The matplotlib talk (delivered by yours truly b/c John couldn't make it) was very well received, the interest in Python here is remarkable. Cheers, f -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
On Sat, Feb 26, 2011 at 3:24 PM, Darren Dale dsdal...@gmail.com wrote: I agree that the github interface is not great. The github devs seem to know that everybody complains about it. Yup. I hold on to the hope that, because it's so egregiously, painfully broken and braindead and it stands out so badly in comparison to the rest of github (which is brilliant), that it won't be too long before this improves. Granted, we can't know what's on their internal todo list, but those guys are obviously good and listen to feedback (from what I've seen elsewhere on the site), and their bug tracker has become something of a laughing stock, so I can only imagine that they're actually working on it. In the meantime, Min recently pointed out this interesting alternative: http://githubissues.heroku.com/#darrendale/mpl-issues You can point it to any repository you want, and it makes interacting with the issue list far, far saner than via github itself. We're using now that interface ourselves for IPython: http://githubissues.heroku.com/#ipython/ipython and I have to say that I like it quite a bit. For those on OSX, this can even be installed to run locally, with the feel of a native app (it's still a webkit app, but it launches like a local app). Something to keep in mind as you make the decision... In the end, in IPython we decided to move to github in order to benefit from the close integration between pull requests, bugs and commits. Pull requests automatically create an issue, one can close bugs automatically from the commit message, etc. I figured these things would be nice to have for an everyday workflow, and that eventually github itself would improve its native bug system. Cheers, f -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github devel question
On Fri, Feb 25, 2011 at 11:48 AM, Darren Dale dsdal...@gmail.com wrote: On Fri, Feb 25, 2011 at 2:43 PM, Ryan May rma...@gmail.com 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. HTH, f -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github devel question
On Fri, Feb 25, 2011 at 12:01 PM, John Hunter jdh2...@gmail.com wrote: I just want to throw out there that in the migration to github, we never officially said we were going to switch the development process. In fact, we said the opposite. After the migration, Jarrod suggested the pull request workflow as espoused in gitwash, and I am happy to experiment with it, but only to the extent that it works, ie we are getting fast enough code reviews and pull requests closed that development is slowed significantly. In our experience on sf, we weren't doing a good job keeping up with submitted requests by non-developers on the trackers, much less reviewing the core devs' contributions. Let he who thinks they can keep up with MD and JJ step forward... One comment from the peanut gallery: what we've found in ipython is that the git pull request system does make the review process vastly more efficient. The tool is good enough that we've been reviewing things pretty quickly, and it does overall help the project's code quality quite a bit. It makes a big difference if doing a review has high overhead or if it's just a matter of clicking on a link, having all the information nicely presented there for you (conversation, files changed, highlighted diff), and being able to comment in 2 minutes. For simple things often my review amounts to 'good job, merge away but fix this little thing I commented on inline'. It takes me 2 minutes to do it, I manage to get in some feedback that improves the code before merge, and I don't even ever download the actual branch, since I do all the reviewing (for simple ones) just from the diffs on the github pages. Cheers, f -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git migration this weekend
Hey, On Wed, Feb 16, 2011 at 5:00 AM, Darren Dale dsdal...@gmail.com wrote: John, could you freeze the svn repo around noon on Friday? I'll convert the repositories and push them up to github on Saturday. Is it possible to close the sourceforge bugtracker, feature requests, etc to new issues as well? are you guys planning on transfering the old bugs to github? As I mentioned, I have code lying around for the upload (and to download from launchpad, but that's irrelevant here). I'm going to be mosly offline til Monday (conference trip), but if someone pings me on my Berkeley email address, which I monitor even while traveling, I'll be happy to help out. Glad to see eveythong moving over to github! (since scipy is also about to do the same, as soon as 0.9 is out, for which things are already at the RC stage). A huge thank you to Darren for putting so much hard work into this, I admire your attention to detail (and I wish I'd been so thorough when I transitioned ipython, where we could have recovered from some old history problems, but I'm too lazy for that :). Cheers, f -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Contribute streamgraph chart type
Hi Uri, On Wed, Feb 9, 2011 at 12:13 PM, Uri Laserson laser...@mit.edu wrote: I wrote a bit of code for plotting streamgraphs with MPL (e.g., http://goo.gl/7sjcR). Fantastic, many thanks! For anyone who is willing to shepherd this through inclusion in MPL, I *strongly* recommend they read the paper in the link above, titled: “Stacked Graphs – Geometry Aesthetics” by Lee Byron Martin Wattenberg. PDF link: http://www.leebyron.com/else/streamgraph/download.php?file=stackedgraphs_byron_wattenberg.pdf In fact, I'm sure anyone who's intrested enough in data viz to be on this list would tremendously enjoy the paper, it's a really good piece. It is available on my GitHub page here: http://goo.gl/qGGPS What is the best way for me to integrate it into MPL? Unfortunately I'm too swamped to fully help you move this through, but a few pointers now so to get you going, and hopefully another core dev can pitch in... - For mpl inclusion, your code needs to be explicitly BSD licensed, and should mention that the original code it's based on (if you read any of the implementation) was also BSD licensed (which it is, as per this file: https://github.com/leebyron/streamgraph_generator/blob/master/COPYRIGHT). - I read your implementation and it looks very nice and concise, excellent job. After reading the paper, I was just wondering if this problem might not benefit from a bit of object orientation... I'm just thinking out loud here, and I actually tend to always favor holding of on the OO until a more decoupled, functional approach shows its limitations. So perhaps your take is just fine for now. But what I'm thinking about is that the Streamgraph construction has a number of moving parts: * the optimization formulation to select g_0. * the colormap choices, which can be fairly sophisticated. * the sorting of the time series and their assignment on the stream stack. It might be more convenient to bundle all these into an object that exposes the already implemented options and can be extended to other algorithms. This is a case where I'm thinking of going OO not because of inheritance, but simply as a way of grouping related functions and data in a way that's easier to pass around in more complex codes. In fact, a good solution might be to keep a number of standalone functions and offer a wrapper object that exposes an OO interface. For simple cases people could just call the function with some data, but for more complex development using (and possibly extending) the object would be cleaner. In any case, I hope this feedback is useful, and I look forward to streamgraphs in MPL! Sorry that I won't be able to work on the review/merge itself in the future; as interested as I was by the paper (many thanks for bringing it to our attention), I'm already neglecting other things far too much :) Regards, f -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Backend for Pyside
On Tue, Jan 18, 2011 at 11:18 PM, Eric Firing efir...@hawaii.edu wrote: 2) Interactive backends, to be fully useful, need to be be supported by ipython. As long as the event loop handling of pyside is similar to pyqt's one, it might just work already. But even if it doesn't, from the IPython side we are *very* interested in pyside, and actually just a few days ago we got full Pyside support contributed by the author of our new Qt console: https://github.com/ipython/ipython/pull/259 It's not merged yet, but the code is ready (reviews from experts welcome). So from our side, consider pyside to be high priority. Cheers, f -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Event handling broken in svn?
On Mon, Oct 4, 2010 at 6:13 AM, Michael Droettboom md...@stsci.edu wrote: The problem is when callbacks create cyclical references (which your example does not). If the Handler class in your example needed to update the figure or canvas in some way in the callback (which is a common usage pattern), that cyclical reference prevents either from being destroyed without running the cyclical garbage collector. And in that case, you can't write a __del__ method on the handler to explicitly disconnect the callbacks. In any case, if my logic is flawed (quite likely, since I imagine M. D. had a good look at this), it might be worth adding a .. warning:: section about this pattern to the event docs: http://matplotlib.sourceforge.net/users/event_handling.html because the problem is subtle and hard to diagnose (I just noticed it had also been reported recently http://sourceforge.net/mailarchive/forum.php?thread_name=4C9B7793.5020908%40gmail.comforum_name=matplotlib-devel). True -- it's non-obvious and confusing. On the other hand, the user is no longer required to explicitly disconnect callbacks, which was the source of many other subtle and hard to diagnose problems within the matplotlib code itself. I'm still not completely happy with it, so I'd love to find a third way if there's anything anyone can suggest. Thanks for your explanation, it makes complete sense. I think it's OK, Eric just added a warning to the docs, which will go a long ways towards making this less of a user trap. Given the details you provided, I can't think of a generic way to handle these cycles 100% automatically. Using weakrefs seems like the most sensible solution, and users will just need to understand a little bit more before using this functionality. Event handling isn't raw beginner material in any case, so I don't think it's a huge problem. And if someone ever devises a clever solution to the problem, then great! But for now I think you can safely ignore this further. Regards, f -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Event handling broken in svn?
On Sun, Oct 3, 2010 at 2:05 PM, Eric Firing efir...@hawaii.edu wrote: section about this pattern to the event docs: http://matplotlib.sourceforge.net/users/event_handling.html Done in 8723. Thanks! Cheers, f -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Event handling broken in svn?
Howdy,
I spent a while chasing my tail today with some event handling code
until I tried backtracking from SVN matplotlib back to 0.99.1 (the one
in ubuntu 10.04) and the problem went away.
I'm attaching a script that reproduces the problem with a full
description in the docstring, reproduced here for completeness:
This example wires two event handlers that both respond to clicks by printing
event info identically. One is written as a standalone function, the other as
a method of an object.
- when run with MPL 0.99.1.1 (stock in ubuntu 10.04), both fire fine:
amirbar[mplbrush] python mpleventbug.py
MPL version: 0.99.1.1
MPL: /usr/lib/pymodules/python2.6/matplotlib/__init__.py
/usr/lib/pymodules/python2.6/matplotlib/backends/backend_gtk.py:621:
DeprecationWarning: Use the new widget gtk.Tooltip
self.tooltips = gtk.Tooltips()
C1 - button=1, x=146, y=229, xdata=23.783488, ydata=0.846491
C2 - button=1, x=146, y=229, xdata=23.783488, ydata=0.846491
C1 - button=1, x=216, y=189, xdata=42.919628, ydata=0.671053
C2 - button=1, x=216, y=189, xdata=42.919628, ydata=0.671053
C1 - button=1, x=288, y=117, xdata=62.602515, ydata=0.355263
C2 - button=1, x=288, y=117, xdata=62.602515, ydata=0.355263
etc...
- when run with matplotlib r8721, the one that is a method does not fire:
amirbar[mplbrush] python mpleventbug.py
MPL version: 1.0.0
MPL: /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/__init__.pyc
C1 - button=1, x=150, y=170, xdata=24.876982, ydata=0.587719
C1 - button=1, x=169, y=160, xdata=30.071077, ydata=0.543860
C1 - button=1, x=187, y=135, xdata=34.991799, ydata=0.434211
C1 - button=1, x=210, y=120, xdata=41.279388, ydata=0.368421
###
This manifested itself in some more complex MPL code that had multiple
events not working when run inside ipython, but working OK outside of
ipython. Fortunately, the small self-contained example demonstrates
the problem even with ipython not being in the picture at all (the
runs above were from the command line), so I think there is an issue
in MPL proper.
Sorry that I can't dig deeper into the code right now to look for a fix...
Timing note: EPD is planning a release in a few weeks, I don't know
how close MPL is to a bugfix release in the 1.0.x series. I don't
know what version of mpl EPD plans to use, but if event handling is
really broken and a fix is feasible in the time available, it might be
worth pushing it through.
Cheers,
f
Event handling bug in matplotlib 1.0.x from svn.
This example wires two event handlers that both respond to clicks by printing
event info identically. One is written as a standalone function, the other as
a method of an object.
- when run with MPL 0.99.1.1 (stock in ubuntu 10.04), both fire fine:
amirbar[mplbrush] python mpleventbug.py
MPL version: 0.99.1.1
MPL: /usr/lib/pymodules/python2.6/matplotlib/__init__.py
/usr/lib/pymodules/python2.6/matplotlib/backends/backend_gtk.py:621: DeprecationWarning: Use the new widget gtk.Tooltip
self.tooltips = gtk.Tooltips()
C1 - button=1, x=146, y=229, xdata=23.783488, ydata=0.846491
C2 - button=1, x=146, y=229, xdata=23.783488, ydata=0.846491
C1 - button=1, x=216, y=189, xdata=42.919628, ydata=0.671053
C2 - button=1, x=216, y=189, xdata=42.919628, ydata=0.671053
C1 - button=1, x=288, y=117, xdata=62.602515, ydata=0.355263
C2 - button=1, x=288, y=117, xdata=62.602515, ydata=0.355263
etc...
- when run with matplotlib r8721, the one that is a method does not fire:
amirbar[mplbrush] python mpleventbug.py
MPL version: 1.0.0
MPL: /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/__init__.pyc
C1 - button=1, x=150, y=170, xdata=24.876982, ydata=0.587719
C1 - button=1, x=169, y=160, xdata=30.071077, ydata=0.543860
C1 - button=1, x=187, y=135, xdata=34.991799, ydata=0.434211
C1 - button=1, x=210, y=120, xdata=41.279388, ydata=0.368421
import sys
import matplotlib
import matplotlib.pylab as plt
import numpy as np
def onclick1(event):
print 'C1 - button=%d, x=%d, y=%d, xdata=%f, ydata=%f'%(
event.button, event.x, event.y, event.xdata, event.ydata)
sys.stdout.flush()
class Handler:
def __init__(self, figure):
cid1 = figure.canvas.mpl_connect('button_press_event', onclick1)
cid2 = figure.canvas.mpl_connect('button_press_event', self.onclick2)
def onclick2(self, event):
print 'C2 - button=%d, x=%d, y=%d, xdata=%f, ydata=%f'%(
event.button, event.x, event.y, event.xdata, event.ydata)
sys.stdout.flush()
if __name__ == __main__:
print MPL version:, matplotlib.__version__
print MPL:, matplotlib.__file__
f = plt.figure()
ax = f.add_subplot(111)
ax.plot(np.random.rand(100))
Handler(f)
plt.show()
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
Re: [matplotlib-devel] Event handling broken in svn?
Hey Ryan, On Fri, Oct 1, 2010 at 6:27 AM, Ryan May rma...@gmail.com wrote: On Fri, Oct 1, 2010 at 1:05 AM, Fernando Perez fperez@gmail.com wrote: This manifested itself in some more complex MPL code that had multiple events not working when run inside ipython, but working OK outside of ipython. Fortunately, the small self-contained example demonstrates the problem even with ipython not being in the picture at all (the runs above were from the command line), so I think there is an issue in MPL proper. Sorry that I can't dig deeper into the code right now to look for a fix... Somewhere in the 1.0 development cycle, Michael modified the callback code to take weak references to methods. The purpose was to eliminate some leaks that were occurring because callback connections to objects were keeping them around and the proper disconnects were not made (much simpler fix than tracking down every mpl_connect and trying to see where do disconnect). What you're seeing in your script is that since you're not assigning the Handler object to anything, it's being garbage collected. It works for me if I change the second to last line to: h = Handler(f) Many thanks for the info, that helps a lot. I was wondering though, would we still have a leak if strong references are held in the canvas attribute? The canvas will be deleted when the figure goes away, so that should properly allow the callback references to be deleted, without deleting them early otherwise, no? In any case, if my logic is flawed (quite likely, since I imagine M. D. had a good look at this), it might be worth adding a .. warning:: section about this pattern to the event docs: http://matplotlib.sourceforge.net/users/event_handling.html because the problem is subtle and hard to diagnose (I just noticed it had also been reported recently http://sourceforge.net/mailarchive/forum.php?thread_name=4C9B7793.5020908%40gmail.comforum_name=matplotlib-devel). In any case, thanks again for the help! Cheers, f -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news
On Tue, Sep 14, 2010 at 8:21 AM, John Hunter jdh2...@gmail.com wrote: How about this as an alternative: on my box, I can drag the source code link from the browser into my terminal, which by default pastes the URL of the referenced *.py into the terminal. If run supported a -w (web) option, or automatically detected that the URL starts with http, it could do a web run of the file. Of course, you may want the source code pasted in for illustrative purposes... To support this, you could add a -u (url) option to paste which assumes the input is a url, fetches it, and pastes the contents into ipython. So you could type paste -u and then drag the link into the terminal, and it would fetch it and paste the code into an input block. Ask and ye shall receive (yes, the url was drag-dropped from the 'source code' link in the mpl page), welcome %loadpy: http://fperez.org/tmp/iqlab_mpl_loadpy.png Full credits go to Brian and Evan! Cheers, f -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Buglets in svg backend?
Howdy, I just wanted to bump this again: given the speed of Michael's recent SVG fixes, maybe fixing these two is also quite easy. They are the only problem coming from matplotlib right now regarding the use of the new qt console for ipython. If not let me know and I'll just file reports on the tracker for long-term storage :) Cheers, f On Tue, Sep 7, 2010 at 3:39 AM, Fernando Perez fperez@gmail.com wrote: Hi folks, I've just implemented support in ipython for simultaneous use of the interactive mpl gui backends along with inlined figures, as I had suggested to Eric things could work. But I'm seeing two little glitches, illustrated here: http://fperez.org/tmp/mpl_svg_bug.png The white console on the right is IPython, the mpl window was my only open figure. The code I ran was: x=rand(1000) plot (x) # this pops up the normal gui, I tested Qt4Agg and GTKAgg paste() # this pasted the open figure into the IPython console. At this point, the plot in the window got that funny size, with the x-labels double-drawn. It seems as if the figure got re-drawn over the previous canvas, at a different size. If I resize the window, the problem goes away, but if I don't resize it, it persists through new plot/draw operations. The second problem... I then zoomed the interactive window and issued paste again, getting the plot in the bottom right of the figure: paste() And here the bug seems to be related to clipping: while the window clips OK, the SVG seems not to. Is this a fundamental limitation of the SVG backend? For IPython we can also switch to pngs if that turns out to work better, but I figured I'd report these... All this was done with current mpl from trunk. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] IPython (new) + matplotlib report: happy news
On Tue, Sep 14, 2010 at 8:59 AM, Michael Droettboom md...@stsci.edu wrote: This is now fixed in r8699. - One produced an error: http://matplotlib.sourceforge.net/examples/axes_grid/simple_axisline4.html ... ...: plt.draw() ...: plt.show() ...: Received invalid plot data. This is now fixed in r8700. Great, many thanks for these fixes! It means that we're probably capable now of running just about every pylab example out of the box... We'll keep testing and will report if we see anything weird. One small request: is it possible/easy to add to the MPL examples a little 'copy to clipboard' button or link? Now that one can copy/paste wholesale examples into an interactive session to explore them, it feels annoying to have to highlight the whole text box and then do Ctrl-C or menu-copy. It would be really nice to have a one-click 'copy to clipboard'... But I have no idea if that's easy or hard in HTML... Good idea. I'll have a look at how hard this would be to add as a Sphinx extension. Great, if it can be done it would be wonderful (Robert indicated it may require flash, but others provided JS pointers; I'll leave it to you to navigate those lovely waters :) Cheers, f -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news
On Tue, Sep 14, 2010 at 11:48 AM, Anne Archibald aarch...@physics.mcgill.ca wrote: On 14 September 2010 11:08, Gökhan Sever gokhanse...@gmail.com wrote: 1-) When one downloads a script from the matplotlib gallery via an external script (name it load_into_ipython or open_with_ipython) the contents of that gallery script (or any python script) can be executed locally inside an ipython session. Not to be difficult, but I should point out that allowing users to run code with one click, particularly if that code is from a wiki or other user-submitted gallery, is just asking for trouble. How long before someone submits import os, shutil; shutil.deltree(os.environ['HOME'])? Or sneaks it into some otherwise inoffensive script? Very valid points. I'm leaning more towards something like a combination of (hopefully) a 'copy code' button on the MPL webpages themselves, so users don't have to scroll/highlight a lot but would still do paste, execute manually, and a special %mplexample magic. This would only run examples from the mpl gallery (hardcoding the path), would display the code to the user first, and would ask for confirmation before execution. Since those html pages are built by executing those same scripts, there's a layer of sanity already built into it (the rmtree call would have already nuked the builder's home directory in the build process if it had been there). Showing the code to the user and confirming execution before proceeding adds a final chance for the person to check her parachute before jumping off the cliff. Does that sound reasonable? 2-) Matplotlib gallery might turn to an interactive environment where you can execute the script from right within your browser and change parameters in the same browser window. As far as I know mpl figures can now be drawn on html canvas. This might for sure boost the number of matplotlib audience. Is there a sandboxed browser plugin? Or server plugin, depending on where you run the script? This would have to be server-side, and code needs to be written. Part of our interest with this explicit separation of ipython kernel and clients with a well-defined protocol is to make the above possible. But we haven't written any of the code necessary to have a browser client, and to serve code read from a sphinx-generated HTML page. Gokhan, your patches will be welcome, the infrastructure is now ready and waiting for you :) Cheers, f -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news
On Tue, Sep 14, 2010 at 12:38 PM, Gökhan Sever gokhanse...@gmail.com wrote:
Sage provides some level of interaction actually without any deployment made
on local side. Try for instance the following example on sagenb.org
from scipy import stats
import numpy as np
import matplotlib.pyplot as plt
@interact
def plot_gamma(a=(1,(1,10)), loc=(0,(0,10)), scale=(1,(1,10))):
rv = stats.gamma(a, loc, scale)
x = np.linspace(-1,20,1000)
plt.plot(x,rv.pdf(x))
plt.grid(True)
plt.savefig('plt.png')
plt.clf()
This one is very useful for educational and demonstrative purposes. Still
requires a bit Sage syntax manipulations to make things fully interacting on
browser.
Nice that you have matured IPython infra for implementing
such interactive functionality. I was thinking perhaps running something on
top GApss Engine but not sure they allow compiling/running C/C++ extensions
on their servers. Alternatively, like in Sage servers virtual OS'es might be
the way to go with it then possibly there will be user registration and
management issues (not sure about all specifics).
Actually sage does have one *implicit* but very particular 'local
deployment': its notebook execution model is *strictly* tied to the
idea that the client is a web browser. Try this code in the sage
terminal (i.e. their customized ipython, not the notebook):
sage: @interact
: def x(a=(1, (1, 10))):
: print a
:
and you'll see:
html!--notruncate--div padding=6 id='div-interact-0' table
width=800px height=20px bgcolor='#c5c5c5'
cellpadding=15trtd bgcolor='#f9f9f9' valign=top
align=lefttabletrtd align=rightfont
color=blackanbsp;/font/tdtdtabletrtd
div id='slider-a-0' style='margin:0px; margin-left: 1.0em;
margin-right: 1.0em; width: 15.0em;'/div
... lots more...
/tablediv id='cell-interact-0'?__SAGE__START
table border=0 bgcolor='#white' width=100% height=100%
trtd bgcolor=white align=left
valign=toppre?__SAGE__TEXT/pre/td/tr
trtd align=left valign=top?__SAGE__HTML/td/tr
/table?__SAGE__END/div/td
/tr/table/div
/html
sage:
So you can see, @interact in sage does basically:
- analyze the inputs of the function
- do some basic 'type inference' and emit javascript/html controls for
each parameter.
- emit an html section that wires the above controls to repeated calls
of the decorated function as the controls are operated.
This is very cool, and it enables great functionality, but it's
hard-coded to an html/javascript client.
What we're doing is a little different, as we've built a *protocol*
that clients can use to talk to the kernel, regardless of how they are
implemented.
As the functionality matures, we'll see who contributes a
browser-based client (that will require wrapping the kernel in an http
server, obviously). And then the question of things like @interact
will be an interesting one to think about. @interact by nature is
creating a user interface (Mathematica's Manipulate creates Notebook
controls, sage's @interact creates HTML ones). I'm not sure yet how
we'll approach that: having per-client implementations? A traits-style
approach where each client renders it differently? No idea yet.
Cheers,
f
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news
On Tue, Sep 14, 2010 at 6:01 PM, Benjamin Root ben.r...@ou.edu wrote: True... but, consider this. ipython can already display the code for a particular module/function using the '??' idiom. Why not have some way to take that text and bring it into the input buffer? Yes, but that's a separate issue. The approach you propose would likely have in ex.demo_somehting() a stub to retrieve the actual example code as a string from a file elsewhere, because (at least right now) the mpl examples are written as 100% standalone files, not as functions inside of some other control module. What you are saying does apply to the mayavi.mlab.test_*() functions, that do serve as examples precisely in that manner, since those *do* contain their code inside the functions. So for the matplotlib examples, that live in standalone files, we'd still need something different. I can imagine this being useful beyond matplotlib where anybody could have their example codes easily accessed and edited. Certainly! Right now the pager is a very simple tool, but I hope that once we put this code out we'll get contributions from enterprising Qt coders who may improve it and add things like a button that would copy the code from the source part of an info pane and paste it in the interactive area, all with a single click. We want to settle the core protocol/messaging behavior first, and once this is ready and people test it a little, I really hope we'll get contributions that enhance the user experience very much in this manner. Cheers, f -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news
On Tue, Sep 14, 2010 at 6:29 PM, Benjamin Root ben.r...@ou.edu wrote: Good point. I guess I am just a little *too* terminal-oriented. It's probably worth mentioning that we've gone to great lengths to try to produce in the new console an experience that's as seamless and fluid as possible to anyone who 'lives in a terminal' (like myself). We want this to be 'a terminal, but better': multiline editing, inline graphics, html documentation, popups with call tips, but all the keyboard friendliness and raw efficiency of a terminal. Put another way: this should be 100% usable *without* a mouse, and you should be more efficient with this in python than with any terminal. If you're not, it's a bug :) Cheers, f -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news
On Mon, Sep 13, 2010 at 2:22 PM, Gökhan Sever gokhanse...@gmail.com wrote: Either in Firefox or Chrome you could use extensions [Auto Copy] to copy text selections into clipboard. Thanks, that's good to know. But I'm mostly thinking of teaching situations, so it would be nice to have this in the source: it's not for my use but for the benefit of students who may be in a lab where they can't install extensions. But I don't know if that can even be done in html in the first place. Cheers, f -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
Hi Jeff, On Mon, Sep 6, 2010 at 6:27 AM, Jeff Whitaker jsw...@fastmail.fm wrote: Fernando: Got it, thanks. Sounds reasonable to me. Just playing with it a bit, one thing I found myself looking for was a way to save the entire session (inline figures included) to html. Of course! When is the patch coming? ;) Yes, that will be the obvious first thing everybody will want. And it shouldn't be too hard to write, either. In fact, if we store the svg payloads in a dict keyed by input line number kernel-side, it would be pretty easy to write a little function that will take a session and will generate a reST document with figures and all, with .. image:: directives. BTW, in my branch (fperez/newkernel) it's already working with inline figures not needing a show() call at all, and a 'paste()' function to paste any figure inline if you use one of the gui backends. We should have it merged in a day or two. Cheers, f ps - tip: Ctrl-. restarts the kernel, and Ctrl-L clears the screen. So it's quick to get a fresh state, but keeping all your input history you've been typing client-side unmodified. We're starting to get the benefits of the two-process model... -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
Hi Jeff, On Sun, Sep 5, 2010 at 10:18 AM, Jeff Whitaker jsw...@fastmail.fm wrote: Fernando: I've got ipython-newkernal ipythonqt working on my mac - how do I tell it to switch between external plot windows and inline plots? External windows seems to be the default... if you start it with --rich, it will use inline plots. I'll try to improve the code so that *both* are possible simultaneously: interactive external windows for zooming and panning, and a function loaded into the user's namespace, similar to show(), that would instead embed them inline. Cheers, f -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
Hi Jeff, On Sun, Sep 5, 2010 at 5:25 PM, Jeff Whitaker jsw...@fastmail.fm wrote: Fernando: That works, but it seems like I have to run show() to make the plot appear inline. draw() doesn't do it. Is this the expected behavior? Yes, currently it is, because the show() you're running is actually *our* show() which we've overwritten to do the svg transport. The interface to all of this is very new and completely experimental, so we're more than happy to take suggestions/ideas/code on how to make it work better. Regards, f -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] Uniform GUI support across matplotlib, ets and ipython
Hi folks,
On Sat, Aug 28, 2010 at 12:42 PM, Brian Granger elliso...@gmail.com wrote:
Hi all,
As you may know, this summer we have been working on a new two
process IPython that has a beautiful Qt frontend GUI and a ZMQ based
messaging layer between that GUI and the new IPython kernel. Many
thanks to Enthought for funding this effort!
We are currently in the process of adding GUI event loop integration
to the ipython kernel so users can do interactive plotting like they
can with the regular ipython. You may also remember that last summer
we implemented a new PyOs_InputHook based GUI integration for the
regular ipython. This has not been released yet, but all of this will
be released in the upcoming 0.11 release.
I am emailing everyone because we see that there is a need for all of
us to agree on two things:
1. How to detect if a GUI application object has been created by someone
else.
2. How to detect if a GUI event loop is running.
Currently there is code in both ETS and matplotlib that fails to
handle these things properly in certain cases. With IPython 0.10,
this was not a problem because we used to hijack/monkeypatch the GUI
eventloops after we started them. In 0.11, we will no longer be doing
that. To address these issues, we have created a standalone module
that implements the needed logic:
http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py
This module is heavily commented and introduces a new informal
protocol that all of use can use to detect if event loops are
running. This informal protocol is inspired by how some of this is
handled inside ETS. Our idea is that all projects will simply copy
this module into their code and ship it. It is lightweight and does
not depend on IPython or other top-level imports. As you will see, we
have implemented the logic for wx and qt4, we will need help with
other toolkits. An important point is that matplotlib and ets WILL
NOT WORK with the upcoming release of IPython unless changes are made
to their respective codebases. We consider this a draft and are more
than willing to modify the design or approach as appropriate. One
thing that we have not thought about yet is how to continue to support
0.10 within this model.
The good news amidst all of this is that the quality and stability of
the GUI support in IPython is orders of magnitude better than that in
the 0.10 series.
I just wanted to ping back with this topic, both to update you a
little and to ask for help...
Brian is now using Andrew's git repo and made an mpl branch for
experimenting with the guisupport work:
http://github.com/ellisonbg/matplotlib/tree/guisupport
For now there's just one commit, but at any point in time, this URL
will easily let you compare what's new vs Andrew's trunk (which I'm
considering the canonical reference on github):
http://github.com/ellisonbg/matplotlib/compare/astraw:trunk...guisupport
Basically we're a bit stumped with GTK, and also partly with Tk. With
Tk things *seem* to work ok in light testing, but it's possible that
problems lurk. It's just that we do get something 'for free' because
python itself manages the Tk event loop.
But for GTK, no clue...
This type of code will be needed to support the multiprocess
capabilities we're developing with ipython, and for qt, wx and
(apparently, but only by chance) tk, matplotlib with the guisupport
added, works right now on IPython:
- 0.10.1 with the old -Xthread flags (just like always, rather fragile
and brittle but useful for a lot of things).
- trunk at the command-line, using --pylab {qt, wx, tk}: this uses
PyOSInputHook, which is more reliable than the --Xthread flags.
- our 'newkernel' branch with the fancy Qt widget and two process control.
So we're doing pretty good: Qt and Wx seem solid, Tk so far is cutting
us slack. But GTK is simply hosed. Brian tried and got lost, and I
don't have the foggiest clue.
So if anyone here can help us out solidify the GTK solution, as well
as point out anything that might be needed for Tk and any possible
flaws in the code for Wx/Qt, we'd be immensely grateful.
We're very, very excited about the possibilities the code we're
building in ipython opens up. But we don't want to have the massive
regression of breaking GTK support for matplotlib, and we're a bit
stuck.
Once the code in Brian's branch is tested/fixed/approved by you guys,
we'd like to propose it for merging into matplotlib. The idea is that
MPL would carry its own copy of this guisupport file, enabling it to
cooperate well with IPython or anyone else who supports this approach
(and we've talked with the IEP author --http://code.google.com/p/iep,
enthought for the Traits machinery, etc). But it would NOT create an
ipython dependency on matplotlib, nor should it break any embedded
uses in a GUI application, etc.
This stuff is hard, and Brian and I are both pretty ignorant when it
comes to GUIs, so any help we can get will
Re: [matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx
On Fri, Sep 3, 2010 at 6:57 PM, Eric Firing efir...@hawaii.edu wrote: It's not quite that simple. After some initial thrashing around, I installed zmq from source, and then pyzmq--but I can't import zmq: Mhh, sorry to see you burn up on this, Eric. Brian is the zmq expert, not me, but it *may* be a version compatibility issue, perhaps? I am using these versions of zmq/pyzmq: - zmq 2.0.8: http://www.zeromq.org/local--files/area:download/zeromq-2.0.8.tar.gz - pyzmq 2.0.7: http://github.com/downloads/zeromq/pyzmq/pyzmq-2.0.7.tar.gz These two worked fine for me, with: - for zmq: ./configure --prefix=$HOME/usr/opt make make install note that $HOME/usr/opt/lib is in my LD_LIBRARY_PATH, and the include/ dir in my include path, etc. - for pyzmq: python setup.py install --prefix=$HOME/usr/opt And at that point it just worked. A few questions: - is it possible that you did a build from the head of either zmq/pyzmq git tree? that might cause an incompatibility. - could it be that /usr/local/lib isn in your LD_LIBRARY_PATH? I'll be available over the weekend and will be more than happy to try and help sort this out. Regards, and sorry for the hassle f -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Tue, Aug 31, 2010 at 1:21 PM, Ondrej Certik ond...@certik.cz wrote: That'd be great. I think I either want to use regular terminal, or a worksheet in the browser. You may change your mind when you start playing with the new Qt terminal :) It feels very much like a terminal, except with a ton of little useful touches that make it very effective. It still has a lot of rough edges, but Evan has done a phenomenal job there. I'm now using it as my regular ipython instead of the normal one, dogfooding enough that we hit all the key usability quirks quickly, and act on them. Cheers, f -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Tue, Aug 31, 2010 at 1:55 PM, Ondrej Certik ond...@certik.cz wrote: Ok, I'll give it a shot then. As I mentioned elsewhere, getting it going is a bit rough right now. So unless you really want to play with real bleeding edge code, give us a couple of weeks. It will be much nicer then. Cheers, f -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] A small fix for backend specification...
Hi folks,
I'd like to know if the fix below looks reasonable to you, this is a
diff against current svn trunk:
dreamweaver[matplotlib] svn diff
Index: __init__.py
===
--- __init__.py (revision 8656)
+++ __init__.py (working copy)
@@ -880,10 +880,14 @@
if 'matplotlib.backends' in sys.modules:
if warn: warnings.warn(_use_error_msg)
return
-arg = arg.lower()
if arg.startswith('module://'):
name = arg
else:
+# For non-module backends, normalize name to lowercase. Note that this
+# must NOT be done to module backends, because those need to be valid
+# Python module specifications that can be imported, and Python module
+# names *are* case sensitive.
+arg = arg.lower()
be_parts = arg.split('.')
name = validate_backend(be_parts[0])
if len(be_parts) 1:
# END PATCH
I hope the comments explain clearly enough the problem. For a bit of
context, this is biting us in ipython where we're building a custom
backend for Qt terminals that inline mpl figures (very neat [1]), but
our backend's name is module://IPython.zmq.pylab.backend_payload_svg.
If you lowercase that, it won't import later. I know we shouldn't
have called IPython's module with that funny capitalization, but it's
a bit late to change now, I'm afraid.
Do you foresee any problems with the above change?
If everyone OK's it, I'm happy to commit it, but I won't do anything
until others better informed than I reply.
Regards,
f
[1] teaser for the curious:
http://fperez.org/tmp/ipython_qt_pylab.png. All code is in the
'newkernel' github branch. Special credits to Evan Patterson from
Enthought, the Qt brains behind the magic.
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] A small fix for backend specification...
On Wed, Aug 25, 2010 at 2:59 PM, Gael Varoquaux gael.varoqu...@normalesup.org wrote: Freeking awesome! Go go team! Thanks :) We're pretty happy, we'll post more in a few weeks when there's something more solid to show. Take care, f -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] A small fix for backend specification...
On Wed, Aug 25, 2010 at 3:06 PM, Eric Firing efir...@hawaii.edu wrote: Looks fine to me. It's fixing a bug. I don't think the comment is even necessary--the rationale looks pretty obvious, and the code is clear. Great, thanks. I'll shorten the comment to just one line then: +# Lowercase only non-module backend names (modules are case-sensitive) so that it serves as a little safety for the bug not to return, but is less verbose than before. Committed as revision 8657. Thanks! f -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
On Wed, Jul 21, 2010 at 3:38 AM, Andrew Straw straw...@astraw.com wrote: We could also make a meta repository that uses git submodules (somewhat akin to svn externals). I have to confess that I first heard of git submodules when you first mentioned them on this list a while ago, but a reasonable amount of reading left me with the feeling that it was far more git-fu than I was willing to handle for everyday work. They seemed like a fairly complex system, with a very nasty set of failure modes (easy to make mistakes having serious consequences). I say this as the guy who's been raving about git to anyone who won't shut me up, but git submodules seemed just a tad much. Maybe I just didn't find the right explanation, or it was my natural slowness, but I found all the descriptions to be confusing, with lots of moving parts and many things to remember carefully. The tags approach is certainly simple-minded, but it seemed easy enough and something that one or two shell scripts would turn into mindless one-liners in day-to-day practice, I think. Glad to have you around again :) Cheers, f -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
Howdy, On Tue, Jul 20, 2010 at 11:48 AM, Eric Firing efir...@hawaii.edu wrote: Although I would like the transition to occur soon, it might make sense to let the numpy people do it first so that we can take maximum advantage of their systematic approach. I don't know how much of a delay that would entail, but it might provide us with a nice ready-made set of instructions, saving us from some thrashing around. Matthew Brett wrote a set of instructions meant to be easily re-used by any project: http://github.com/matthew-brett/gitwash Here's the one for ipython: http://ipython.scipy.org/doc/nightly/html/development/gitwash/index.html The idea is to have one workflow we agree on (for nipy and ipython, so far), but generate docs whose URLs are correct for each project, so people can copy/paste easily from the docs. Cheers, f -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] question about svnmerge
On Tue, Jul 20, 2010 at 7:43 PM, John Hunter jdh2...@gmail.com wrote: The major issues I am aware of are: * what do to about all the various subdirs of the mpl trunk (trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to one tags all with a unique revision number. In git, how do we synchronize between them? Putting them all in the same tree would be monolithic and require huge checkouts. Unlike svn, in git it is difficult/impossible to check out just a subdir (eg trunk/matplotlb) and also commit to it. So we might end up having to informally synchronize parts of the trunk. Eg, basemap rXXX requires mpl rYYY in the CHANGELOG or release notes. Probably using a common tag across repos would be the easiest. Any time you want a known 'sync point', you tag all the relevant repos with the same tag. It then becomes very simple to write a little script that will update checkout a bunch of repos sitting in the same parent directory (each as its own dir, of course) at a common tag. You can make up a convention for these special tags so that they are always named with a given pattern (you could even use r if you wanted). * organizational stuff: how do we handle the notion of the central repo? Now that github support organizations this should be relatively easy. Andrew and I registered a matplotlib user acct at github and created a gmail acct mplgithub as a central administrator (matplot...@gmail.com was taken, the bastards). Email me offlist if you are interested in obtaining the passwd for the github or gmail admin accts -- but you should probably coordinate with Andrew who is our point person as soon as he re-emerges. No need. Organizations let you designate more than one 'owner', so you can mark more than one person with full admin privileges without having to give out the password around. I recently converted the extra ipython account to an organization, added Brian Granger as a second 'owner', and that's it. You can then make as many teams and repos as you want within an organization. The github org model is fairly simple but very effective (much nicer than how launchpad uses teams). * porting the buildbot to work w/ github commits * related: porting the trunkdocs build to work with github commits * how to handle the svn tree at sf -- should it mirror the new github tree or remain stale or simply removed? I would freeze it during a transition period and later on make a static backup of teh repo dump somewhere for historical purposes (and just in case, disk is cheap). I would then nuke it for simplicity of administration, since on github people can still use svn if they want to track a git repo: http://github.com/blog/626-announcing-svn-support I should note that I have not used this in practice, but a quick and dirty test with the ipython repo seems to work (you just get the master git branch though): amirbar[junk] svn checkout http://svn.github.com/ipython/ipython.git [...] amirbar[junk] cd ipython.git/ amirbar[ipython.git] svn info Path: . URL: http://svn.github.com/ipython/ipython.git Repository Root: http://svn.github.com/ipython/ipython.git Repository UUID: e94b1212-8258-e27c-589c-ce57b7db7bff Revision: 2611 Node Kind: directory Schedule: normal Last Changed Author: fernando.perez Last Changed Rev: 2611 Please add to the list other issues that need to be handled. Of all these, I'm only concerned philosophically with the first. The others are matters of time and work as people make the transition to the new server. The first seems like a true potential workflow impediment for those who run off svn/git HEAD and analogues. Others with more git expertise may suggest a different workflow, but for that the tags approach, along with a couple of simple script helpers to make creation/checkout of these tags a one-line operation, seems like it should do the job. Cheers, f -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
