[matplotlib-devel] mpl from svn build failure?
Hi folks, I don't see anything in the archives, but today mpl won't build on any of my boxes: building 'matplotlib.backends._tkagg' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fPIC -I/usr/include -I/usr/include -I/usr/local/include -I/usr/include -I. -I/home/fperez/usr/opt/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/home/fperez/usr/opt/lib/python2.5/site-packages/numpy/core/include -I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c src/_tkagg.cpp -o build/temp.linux-x86_64-2.5/src/_tkagg.o src/_tkagg.cpp: In function 'int PyAggImagePhoto(void*, Tcl_Interp*, int, char**)': src/_tkagg.cpp:134: error: no match for 'operator*' in '*aggRenderer->RendererAgg::renderingBuffer' error: command 'gcc' failed with exit status 1 John, this is on bic, in case you want to have a look. Cheers, f - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] John: Thoughts on a standard test system
Howdy, On Tue, Jan 6, 2009 at 7:58 AM, Drain, Theodore R wrote: > OK - nose it is. How do you want to handle the dependency? My opinion is > that since tests are development tools, it's not unreasonable to require that > nose be installed by the developer and not as an embedded dependency in MPL > (or at least that should be an option). Don't forget to have a look at numpy's extra nose support, which may come in handy for you (and since you already have a numpy dependency, you can use it at will): http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/testing There's a lot of handy stuff in there. Suitable use of decorators make it very easy to tag tests for skipping under certain conditions (no X, no WX, etc). I've improved the code in numpy in my local ipython tree for that but haven't pushed it yet, ping me for the code if you need it quickly. Yay for testing! f -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] A small patch for sphinxext tools
Hi all,
in various places I've been using the mpl sphinxext tools, so I
figured I'd best send you a few small updates I've made to them before
they bitrot too much. Most of the changes are just cleanup and
documentation, though there is a functional fix in
inheritance_diagram, which was just not working for us in nipy.
There's a comment indicating the change, I hope it makes sense.
I made the patch against svn trunk, though I can't quite test because
I'm getting this:
maqroll[doc]> ./make.py html
Traceback (most recent call last):
File "./make.py", line 98, in
func()
File "./make.py", line 31, in html
shutil.copy('../lib/matplotlib/mpl-data/matplotlibrc',
'_static/matplotlibrc')
File "/usr/lib/python2.5/shutil.py", line 85, in copy
copyfile(src, dst)
File "/usr/lib/python2.5/shutil.py", line 51, in copyfile
fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory:
'../lib/matplotlib/mpl-data/matplotlibrc'
I'm a bit surprised to see this problem, since I imagine you guys
build frequently. But my svn is indeed up to date and that file is
just not there. I'm not sure which way you want the fix to go, so
I'll leave that decision to you guys.
Cheers,
f
Index: inheritance_diagram.py
===
--- inheritance_diagram.py (revision 6861)
+++ inheritance_diagram.py (working copy)
@@ -42,6 +42,17 @@
from docutils.parsers.rst import directives
from sphinx.roles import xfileref_role
+def my_import(name):
+"""Module importer - taken from the python documentation.
+
+This function allows importing names with dots in them."""
+
+mod = __import__(name)
+components = name.split('.')
+for comp in components[1:]:
+mod = getattr(mod, comp)
+return mod
+
class DotException(Exception):
pass
@@ -84,6 +95,13 @@
path = base
try:
module = __import__(path, None, None, [])
+# We must do an import of the fully qualified name. Otherwise if a
+# subpackage 'a.b' is requested where 'import a' does NOT provide
+# 'a.b' automatically, then 'a.b' will not be found below. This
+# second call will force the equivalent of 'import a.b' to happen
+# after the top-level import above.
+my_import(fullname)
+
except ImportError:
raise ValueError(
"Could not import class or module '%s' specified for inheritance diagram" % name)
Index: ipython_console_highlighting.py
===
--- ipython_console_highlighting.py (revision 6861)
+++ ipython_console_highlighting.py (working copy)
@@ -1,18 +1,32 @@
+"""reST directive for syntax-highlighting ipython interactive sessions.
+"""
+
+#-
+# Needed modules
+
+# Standard library
+import re
+
+# Third party
from pygments.lexer import Lexer, do_insertions
-from pygments.lexers.agile import PythonConsoleLexer, PythonLexer, \
-PythonTracebackLexer
+from pygments.lexers.agile import (PythonConsoleLexer, PythonLexer,
+ PythonTracebackLexer)
from pygments.token import Comment, Generic
+
from sphinx import highlighting
-import re
+
+#-
+# Global constants
line_re = re.compile('.*?\n')
+#-
+# Code begins - classes and functions
+
class IPythonConsoleLexer(Lexer):
"""
For IPython console output or doctests, such as:
-Tracebacks are not currently supported.
-
.. sourcecode:: ipython
In [1]: a = 'foo'
@@ -24,7 +38,14 @@
foo
In [4]: 1 / 0
+
+Notes:
+
+ - Tracebacks are not currently supported.
+
+ - It assumes the default IPython prompts, not customized ones.
"""
+
name = 'IPython console session'
aliases = ['ipython']
mimetypes = ['text/x-ipython-console']
@@ -72,4 +93,6 @@
pylexer.get_tokens_unprocessed(curcode)):
yield item
+#-
+# Register the extension as a valid pygments lexer
highlighting.lexers['ipython'] = IPythonConsoleLexer()
Index: mathmpl.py
===
--- mathmpl.py (revision 6861)
+++ mathmpl.py (working copy)
@@ -1,3 +1,25 @@
+"""matplotlib-based directive for math rendering in reST using sphinx.
+
+To use this extension, add ``mathmpl`` to the list of extensions in
+:file:`conf.py`.
+
+Note:
+
+Current SVN versions of Sphinx now include built-in support for math.
+There are two flavors:
+
+ - pngmath: uses dvipng to render the equation
+
+ - jsmath: renders the math in the browser using Javascript
+
+To
Re: [matplotlib-devel] A small patch for sphinxext tools
On Sun, Feb 1, 2009 at 9:22 PM, Jae-Joon Lee wrote: >> I'm a bit surprised to see this problem, since I imagine you guys >> build frequently. But my svn is indeed up to date and that file is >> just not there. I'm not sure which way you want the fix to go, so >> I'll leave that decision to you guys. > > I believe mpl-data/matplotlibrc is not version-controled, but created > when you run setup.py. > Maybe you're trying to build the documentation from a new svn checkout > but didn't build the library? Aha, that's it, thanks. I'd run svn-clean just before to make sure I had a clean setup before making the patch, so my build had just been nuked. Nothing to worry then, I just did a rebuild and it all seems to work. So at least the patch doesn't completely crash the doc build :) Cheers, f -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bug in latex with \dots
Howdy,
the attached screenshot shows the output in matplotlib of:
In [18]: plot([1,2])
Out[18]: []
In [19]: title(r'$a+b+\dots+\dot{s}+\ldots$')
Out[19]:
along with the PostScript that Latex produces for the same equation.
There are two bugs, I think:
- \dots --> \dot{s} by matplotlib
- \ldots rendered by MPL centered vertically, while in latex those are
'lower' dots.
Should I open an SF ticket for this, or is it a quick fix?
Cheers,
f
<>--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in latex with \dots
Hi Michael,
[Cc'ing nipy-dev, where we ran into the problem. Docs should look
fine now, if you rebuild mpl]
On Wed, Feb 4, 2009 at 7:42 AM, Michael Droettboom wrote:
> There was both a parser bug (where accents were taking precedence over
> symbols), and a mapping bug (where ldots was mapped to the wrong Unicode
> code point). Both of these should now be fixed on the branch and trunk.
> Let me know if you see any further problems.
Many thanks, it all looks good now.
Cheers,
f
> Mike
>
> Fernando Perez wrote:
>>
>> Howdy,
>>
>> the attached screenshot shows the output in matplotlib of:
>>
>> In [18]: plot([1,2])
>> Out[18]: []
>>
>> In [19]: title(r'$a+b+\dots+\dot{s}+\ldots$')
>> Out[19]:
>>
>> along with the PostScript that Latex produces for the same equation.
>> There are two bugs, I think:
>>
>> - \dots --> \dot{s} by matplotlib
>> - \ldots rendered by MPL centered vertically, while in latex those are
>> 'lower' dots.
>>
>> Should I open an SF ticket for this, or is it a quick fix?
>>
>> Cheers,
>>
>> f
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] plot directive in reST tutorials
Howdy, recently, Matthew Brett pointed out that reST supports a mode that's very handy for writing tutorial-like documents that contain code blocks including their output, and they can even be run as tests. Here's a simple example with its corresponding source: http://neuroimaging.scipy.org/site/doc/manual/html/users/analysis_pipeline.html http://neuroimaging.scipy.org/site/doc/manual/html/_sources/users/analysis_pipeline.txt and they can even use the MPL math support, as seen here: http://neuroimaging.scipy.org/site/doc/manual/html/users/glm_spec.html http://neuroimaging.scipy.org/site/doc/manual/html/_sources/users/glm_spec.txt But we were thinking it would be great to have also plot support for this, without being forced to use standalone scripts like in mpl's current form of the plot directive. I unfortunately have to go now and will be mostly offline for a week, but I just had a chat about this with John, so I want to leave some context in here in case this is of interest to you guys. If there's a discussion on the API, I'll do my best to keep up, but I'm also cc'ing the nipy list so those interested can pitch in (though we should keep the conversation to the MPL list, where the plot machinery is implemented). Cheers, f -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: [sage-devel] Re: Massively collaborative mathematics + Sage-ready blogs and forums
Interesting: gnuplot rendered in HTML5. It would be interesting to see this in mpl... -- Forwarded message -- From: Pat LeSmithe Date: Sun, Feb 8, 2009 at 3:44 AM Subject: [sage-devel] Re: Massively collaborative mathematics + Sage-ready blogs and forums To: [email protected] William Stein wrote: > I just want to point out that the above *is* what the 3d plotting in > Sage currently does. > > Doing something similar for 2d plots would be great. I just stumbled upon this announcement for a HTML5 'canvas' driver for gnuplot: http://www.nabble.com/New-terminal-driver%3Aset-term-canvas-tc21364389.html The demos are at: http://skuld.bmsc.washington.edu/~merritt/gnuplot/canvas_demos/ --~--~-~--~~~---~--~~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~--- -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Unit-Test Structure Submitted
On Wed, Feb 18, 2009 at 11:43 AM, James Evans wrote:
> All,
>
> I have just submitted a first-cut at a unit-test harness. The unit-tests do
> require the use of the 'nose' python module.
[...]
> Any questions or comments?
This is great, many thanks! I'd just suggest, if possible, adding a
top-level .test() function, so that the usual idiom for package
testing 'import foo;foo.test()' can be applied. I have a shell
function for that:
function pytest {
# Run the test suite for a python package by name.
# This assumes the package has a top-level .test() routine to run its
# test suite.
local pname=$1
python -c "import $pname;${pname}.test()"
}
that I use for things like testing numpy or scipy easily:
uqbar[~]> pytest numpy
Running unit tests for numpy
[...]
--
Ran 1931 tests in 4.999s
OK (KNOWNFAIL=1, SKIP=11)
Cheers,
f
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Nipy-devel] Sphinx custom extension mess, and patches
On Mon, Feb 16, 2009 at 3:21 PM, Gael Varoquaux
wrote:
> I am not blaming anyone, just pointing out a non ideal situation. It has
> already improved a lot with the matplotlib guys and the scipy guys
> merging some changes in extensions and publishing the extensions in an
> importable part of their source tree.
In keeping with the spirit of trying to get all of these extension
changes upstream so that we can all eventually stop carrying our own
copies, below is a tiny change I just made to the inheritance diagram
one. This is needed to ensure that the figure is separated from any
surrounding text, since otherwise you get hideous off-screen diagrams
in the rendered PDF.
This has been committed to the nipy trunk already.
Similarly (for the pymvpa crowd), the api autogen code is now a
module, and it also contains a few small fixes, in particular
regarding chapter titles. Feel free to grab and update your copy:
http://bazaar.launchpad.net/~nipy-developers/nipy/trunk/annotate/head%3A/tools/apigen.py
I've been told the gods of numpy/sphinx don't like auto-generated
docs, but I think there's a valid use case for these tools, so
hopefully in the future it will be possible to include them upstream
for us lesser mortals to use. If not, I guess we'll just continue to
carry our copies around :)
Cheers,
f
# diff, inline because it's so trivial:
=== modified file 'doc/sphinxext/inheritance_diagram.py'
--- doc/sphinxext/inheritance_diagram.py2009-01-30 02:00:57 +
+++ doc/sphinxext/inheritance_diagram.py2009-02-20 21:11:38 +
@@ -370,7 +370,7 @@
graph.run_dot(['-Tpdf', '-o%s' % pdf_path],
name, parts, graph_options={'size': '"6.0,6.0"'})
-return '\\includegraphics{%s}' % pdf_path
+return '\n\\includegraphics{%s}\n\n' % pdf_path
def visit_inheritance_diagram(inner_func):
"""
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Has IPython been useful to you? Please let me know...
Hi all, [ apologies for the semi-spam, I'll keep this brief and expect all replies off-list ] IPython is a project that many of you on this list are likely to use in your daily work, either directly or indirectly (if you've embedded it or used it as a component of some other system). I would simply like to ask you, if IPython has been significantly useful for a project you use, lead, develop, etc., to let me know. For legal/professional reasons, I need to gather information about who has found IPython to be of value. I started IPython as a toy 'afternoon hack' in late 2001, and today it continues to grow, as the nicely summarized Ohloh stats show: https://www.ohloh.net/p/ipython (obviously, this is now the result of the work of many, not just myself, as is true of any healthy open source project as it grows). But I have never systematically tracked its impact, and now I need to do so. So, if you have used IPython and it has made a significant contribution to your project, work, research, company, whatever, I'd be very grateful if you let me know. A short paragraph on what this benefit has been is all I ask. Once I gather any information I get, I would contact directly some of the responders to ask for your authorization before quoting you. I should stress that any information you give me will only go in a documentation packet in support of my legal/residency process here in the USA (think of it as an oversized, obnoxiously detailed CV that goes beyond just publications and regular academic information). To keep traffic off this list, please send your replies directly to me, either at this address or my regular work one: [email protected] In advance, many thanks to anyone willing to reply. I've never asked for anything in return for working on IPython and the ecosystem of scientific Python tools, but this is actually very important, so any information you can provide me will be very useful. Best regards, Fernando Perez. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OpenGL backend and pyglet expertiments
On Fri, Apr 3, 2009 at 4:17 AM, Nicolas Rougier
wrote:
>
> Hello,
>
> While looking at possible solutions for a matplotlib OpenGL backend,
> I've been experimenting with pyglet (that has no dependencies) and coded
> a terminal with embedded 2d arrays display.
>
> Sources & screenshots are available at:
> http://www.loria.fr/~rougier/glnumpy.html
Wow, the screenshots look gorgeous!
Unfortunately I tried to run it after installing it in my path and I
got this (same for glnumpy):
uqbar[bin]> ./glpython
Traceback (most recent call last):
File "./glpython", line 70, in
logo = pyglet.resource.image('logo.png')
File "/var/lib/python-support/python2.5/pyglet/resource.py", line
481, in image
identity = self._cached_images[name] = self._alloc_image(name)
File "/var/lib/python-support/python2.5/pyglet/resource.py", line
425, in _alloc_image
file = self.file(name)
File "/var/lib/python-support/python2.5/pyglet/resource.py", line 383, in file
raise ResourceNotFoundException(name)
pyglet.resource.ResourceNotFoundException: Resource "logo.png" was not
found on the path. Ensure that the filename has the correct
captialisation.
This is on ubuntu 8.10, 64 bit, installed with --prefix=$HOME/usr/opt.
Cheers,
f
--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OpenGL backend and pyglet expertiments
On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier wrote: > > > Sorry for that, I coded it on linux and just tested on mac. > I fixed the error and upload the new version on the same link. Tell me if > it's ok. Great! Would you have any interest in having this be shipped/developed as part of IPython itself? You are using a fair amount of internals of the ipython machinery, and we're getting ready for a large cleanup. Having your code shipped with ipython itself would give it perhaps more exposure, as well as allow it to evolve in sync with the rest of the API, since we could test it as the internals change. I think it would be great to ship this with ipython itself, and I'm sure you'd get help and contributions from the rest of the ipython team as well... Best, f -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] buglet: fig saving filenames (at least with Tk)
Howdy. This is using Tk, svn build from just now:
In [4]: plot([1,2])
Out[4]: []
In [5]: savefig('foo')
# Then, click on the 'save' icon in the figure window, and simply type
'foo2' in the dialog. Result:
In [6]: d foo*
-rw-r--r-- 1 fperez 35100 2009-04-15 10:02 foo2png.png
-rw-r--r-- 1 fperez 35100 2009-04-15 10:02 foo.png
The dialog, instead of adding '.png', is adding 'png.png' to the
filename. I'm pretty sure this used to work fine a while ago.
I don't know if the problem exists with all the backends. Wx at least
seems to manually add the .png extension in the right place...
Cheers,
f
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bizarre ipython -pylab bug. Help?
Hi folks, this: https://bugs.launchpad.net/ipython/+bug/349634 is a really strange bug report we had from an ipython/pylab user on Windows. I don't have the foggiest idea of how his opening of matplotlib with Tk under Windows could open a calendar. I don't have windows to test on, but if anyone here has seen this (the problem is only seen with MPL) or has any clue, I'd be very grateful for ideas. Cheers, f -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] buglet: fig saving filenames (at least with Tk)
On Wed, Apr 15, 2009 at 10:53 AM, John Hunter wrote: > svn up and give this a test drive under a few different save/extension > scenarios Thanks! So far, looking good... Take care, f -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bizarre ipython -pylab bug. Help?
On Wed, Apr 15, 2009 at 11:03 AM, John Hunter wrote: > Recently I was trying to diagnose a segfault in Charlie's win32 release > candidate, and was using dependency walker to step through the _tkagg.pyd > binary in the egg, and noticed all kinds of funky DLLs that based on their > name I did not know why they were getting linked in (netapi32.dll, > dnsapi32.dll, ieframe.dll). It looks like tk is bringing in a bunch of > internet related stuff, and maybe one of these is doing something to launch > the calendar. Never seen it before though... Mkay, thanks for the info. We'll leave this one filed away until some win32 guru can come to the rescue... Cheers, f -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Multiline equations: misuse in our part or wishlist item for mpl?
Hi all,
in the NIPY documentation, we're heavily taking advantage of mpl's
math support, and for the most part it's working great. But having it
in there, we may have gotten a bit carried away... If you look at this
page:
http://neuroimaging.scipy.org/site/doc/manual/html/users/glm_spec.html
its reST sources here:
http://neuroimaging.scipy.org/site/doc/manual/html/_sources/users/glm_spec.txt
Contain text like:
/begin quote
"""
Typically, the events occur in groups, say odd events are labelled
*a*, even ones *b*. We might rewrite this as
.. math::
E = \delta_{(t_1,a)} + \delta_{(t_2,b)} + \delta_{(t_3,a)} + \dots +
\delta_{t_{10},b}
This type of experiment can be represented by two counting processes
:math:`(E_a, E_b)` defined as
.. math::
\begin{aligned}
E_a(t) &= \sum_{t_j, \text{$j$ odd}} 1_{\{t_j \leq t\}} \\
E_b(t) &= \sum_{t_j, \text{$j$ even}} 1_{\{t_j \leq t\}}
\end{aligned}
These delta-function responses are effectively events of duration 0
and infinite height.
""" / end quote
In the final PDF
(http://neuroimaging.scipy.org/site/doc/manual/nipy.pdf) that all
renders fine, since it's 'real' latex doing the work. However, the
HTML linked above renders the first equation fine, while the multiline
one doesn't work.
Is this something possible with today's MPL but where we are just not
making the right calls, or is it a missing feature. If the latter, is
it realistic to expect it to be added, or should we rather plan for
avoiding such type of typesetting in our docs or switching math
engines for the html docs? Or is the feature 'almost there' but
slightly buggy?
Any hints much appreciated, I just wasn't sure whether this would be a
bug report, feature request or just seeking advice...
Cheers,
f
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bizarre ipython -pylab bug. Help?
On Wed, Apr 15, 2009 at 11:16 AM, Jouni K. Seppänen wrote: > One possible reason for weird stuff like this is the way Python searches > for modules. Say you have been experimenting with calendar stuff, and > have in your current directory (or somewhere on your search path) a file > named calendar.py. Then you import matplotlib, and matplotlib imports > dateutil.rrule, which in turn imports calendar... and your calendar.py > file gets executed, not the one shipped with Python. OK, thanks for the info. I linked to this thread on the bug report, the OP might track this kind of behavior down with this info. Cheers, f -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Multiline equations: misuse in our part or wishlist item for mpl?
Hi Mike, On Wed, Apr 15, 2009 at 11:26 AM, Michael Droettboom wrote: > Multiline equations are not currently supported by the mathtext engine. > It's the alignment stuff that makes it more than just a "throw a vbox > together". It's a good feature request -- go ahead and add it to the > tracker if you're really interested in it -- but I don't know if I'll have > time to do this myself in the near future. I'm happy to help show someone > around the code... Many thanks for the info. I did file it here, so you guys can track it for when someone has a chance to tackle it: https://sourceforge.net/tracker/?func=detail&aid=2766156&group_id=80706&atid=560723 > Of course, in your case, you could also investigate one of the other math > rendering directives included with Sphinx. For now, that seems the most prudent course of action for us, since I don't think we can tackle the mpl code right now. Best, f -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mplot3d: thanks and buglet.
On Wed, Apr 15, 2009 at 2:04 PM, Reinier Heeres wrote: > Hi Fernando, > > This is a known issue, and I hope to resolve it soon... > > Thanks for reporting though; if you notice any other problems, please > let me know! Will do, and I'll be happy to test as needed. f -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] MPL in the wild
Neat to see mpl getting into the linux kernel-dev crowd: http://lwn.net/Articles/329458/ (see the two screenshots). I wasn't thrilled with the charts being described as 'rudimentary', but what can you do :) Congrats to the team! World domination is assured... Cheers, f -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Tutorial topics for SciPy'09 Conference
Hi all, The time for the Scipy'09 conference is rapidly approaching, and we would like to both announce the plan for tutorials and solicit feedback from everyone on topics of interest. Broadly speaking, the plan is something along the lines of what we had last year: one continuous 2-day tutorial aimed at introductory users, starting from the very basics, and in parallel a set of 'advanced' tutorials, consisting of a series of 2-hour sessions on specific topics. We will request that the presenters for the advanced tutorials keep the 'tutorial' word very much in mind, so that the sessions really contain hands-on learning work and not simply a 2-hour long slide presentation. We will thus require that all the tutorials will be based on tools that the attendees can install at least 2 weeks in advance on all platforms (no "I released it last night" software). With that in mind, we'd like feedback from all of you on possible topics for the advanced tutorials. We have space for 8 slots total, and here are in no particular order some possible topics. At this point there are no guarantees yet that we can get presentations for these, but we'd like to establish a first list of preferred topics to try and secure the presentations as soon as possible. This is simply a list of candiate topics that various people have informally suggested so far: - Mayavi/TVTK - Advanced topics in matplotlib - Statistics with Scipy - The TimeSeries scikit - Designing scientific interfaces with Traits - Advanced numpy - Sparse Linear Algebra with Scipy - Structured and record arrays in numpy - Cython - Sage - general tutorial - Sage - specific topics, suggestions welcome - Using GPUs with PyCUDA - Testing strategies for scientific codes - Parallel processing and mpi4py - Graph theory with Networkx - Design patterns for efficient iterator-based scientific codes. - Symbolic computing with sympy We'd like to hear from any ideas on other possible topics of interest, and we'll then run a doodle poll to gather quantitative feedback with the final list of candidates. Many thanks, f -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Is this a bug in LineCollection's handling of alpha values?
Hi all, Hopefully the code below is illustrative and commented enough to clarify my question (also attached if you prefer to download it than to copy/paste). Cheers, f """LineCollection ignores alpha value? The second figure below works, but it sets alpha globally for the whole collection. If LineCollection accepts rgbA tuples, why does it ignore the alpha channel? Is it possible somehow to have alpha for each line (without having to make a single-line collection each time? """ from matplotlib import pyplot as plt from matplotlib.collections import LineCollection # Make two lines line0 = [(0,0),(1,1)] line1 = [(1,0),(0,1)] lines = [line0,line1] # Make colors for each. Note alpha is 0.2, so they should be fairly faint, the # red one is meant to be darker than the blue one alpha = 0.2 colors = [(0,0,1,alpha), # blue line (1,0,0,2*alpha)] # red line # Make a figure with these f = plt.figure() ax = f.add_subplot(111) lc = LineCollection(lines,10,colors) ax.add_collection(lc) # Another figure, where we set the alpha globally for the line collection f = plt.figure() ax = f.add_subplot(111) lc = LineCollection(lines,10,colors) lc.set_alpha(alpha) ax.add_collection(lc) plt.show() """LineCollection ignores alpha value? The second figure below works, but it sets alpha globally for the whole collection. If LineCollection accepts rgbA tuples, why does it ignore the alpha channel? Is it possible somehow to have alpha for each line (without having to make a single-line collection each time? """ from matplotlib import pyplot as plt from matplotlib.collections import LineCollection # Make two lines line0 = [(0,0),(1,1)] line1 = [(1,0),(0,1)] lines = [line0,line1] # Make colors for each. Note alpha is 0.2, so they should be fairly faint, the # red one is meant to be darker than the blue one alpha = 0.2 colors = [(0,0,1,alpha), # blue line (1,0,0,2*alpha)] # red line # Make a figure with these f = plt.figure() ax = f.add_subplot(111) lc = LineCollection(lines,10,colors) ax.add_collection(lc) # Another figure, where we set the alpha globally for the line collection f = plt.figure() ax = f.add_subplot(111) lc = LineCollection(lines,10,colors) lc.set_alpha(alpha) ax.add_collection(lc) plt.show() -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Is this a bug in LineCollection's handling of alpha values?
Hey John, On Sat, Jun 6, 2009 at 4:40 AM, John Hunter wrote: > Hey Fernando -- thanks for the report and test case. > > I committed a change to svn which fixes this Awesome, many thanks! This is really great, the Berkeley neuroscience team continues to be impressed by how fast bugs get fixed in the open source python projects (we had a similar one for numpy a few days ago). The comment I just got was: "Wow, people like fixing bugs?" :) Cheers, f -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mplot3d update
On Mon, Jun 8, 2009 at 5:58 AM, John Hunter wrote: >> Please let me know what you think, perhaps mostly about the >> user-facing API. It would be good to get that 'right' so that we don't >> have to change it in the future. > > You may want to take a look at what other popular toolkits do: > gnuplot, matlab, vtk. These are time worn implementations so we could > benefit from seeing what they've done for the interface. I'd very much suggest having a look at Mayavi's mlab interface too. When Gael and Prabhu worked on it, they took strong inspiration in mpl.pylab, to try to 'keep the spirit' of MPL while implementing high level 3d support in mayavi, at a time when it seemed that MPL would not have its own 3d. Now that this is changing, I think it would be great if API-wise, MPL and Mayavi.mlab were as compatible as is reasonable. This would make code reuse across tools much easier. Reinier, I'm sure if you ping Gael he'd be happy to share some thoughts with you, he's very interested in code reusability (he may be on this list for all I know, but I did CC him just to be safe). Thanks a lot for mplot3d! Cheers, f -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better pyplot wrappers
On Mon, Jun 8, 2009 at 2:29 AM, Jouni K. Seppänen wrote: >> Have you looked at the decorator module? >> http://pypi.python.org/pypi/decorator > > That looks like it could work -- the memoize example seems to be pretty > close to our wrapping needs. I'll spend some time thinking about this > later. Thanks for the link! > We use Michele's decorators.py extensively in ipython for writing testing wrappers, we carry a local copy we call decorators_msim and then add some utilities on top. Feel free to pillage as needed or just read for info: http://bazaar.launchpad.net/~ipython-dev/ipython/0.10/annotate/head%3A/IPython/testing/decorators.py Cheers, f -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Tutorial topics for SciPy'09 Conference
Hi all, In order to proceed with contacting speakers, we'd now like to get some feedback from you. This Doodle poll should take no more than a couple of minutes to fill out (no password or registration required): http://doodle.com/hb5bea6fivm3b5bk So please let us know which topics you are most interested in, and we'll do our best to accommodate everyone. Keep in mind that speaker availability and balancing out the topics means that the actual tutorials offered probably won't be exactly the list of top 8 voted topics, but the feedback will certainly help us steer the decision process. Thanks for your time, Dave Peterson and Fernando Perez On Mon, Jun 1, 2009 at 10:21 PM, Fernando Perez wrote: > Hi all, > > The time for the Scipy'09 conference is rapidly approaching, and we > would like to both announce the plan for tutorials and solicit > feedback from everyone on topics of interest. > > Broadly speaking, the plan is something along the lines of what we > had last year: one continuous 2-day tutorial aimed at introductory > users, starting from the very basics, and in parallel a set of > 'advanced' tutorials, consisting of a series of 2-hour sessions on > specific topics. > > We will request that the presenters for the advanced tutorials keep > the 'tutorial' word very much in mind, so that the sessions really > contain hands-on learning work and not simply a 2-hour long slide > presentation. We will thus require that all the tutorials will be > based on tools that the attendees can install at least 2 weeks in > advance on all platforms (no "I released it last night" software). > > With that in mind, we'd like feedback from all of you on possible > topics for the advanced tutorials. We have space for 8 slots total, > and here are in no particular order some possible topics. At this > point there are no guarantees yet that we can get presentations for > these, but we'd like to establish a first list of preferred topics to > try and secure the presentations as soon as possible. > > This is simply a list of candiate topics that various people have > informally suggested so far: > > - Mayavi/TVTK > - Advanced topics in matplotlib > - Statistics with Scipy > - The TimeSeries scikit > - Designing scientific interfaces with Traits > - Advanced numpy > - Sparse Linear Algebra with Scipy > - Structured and record arrays in numpy > - Cython > - Sage - general tutorial > - Sage - specific topics, suggestions welcome > - Using GPUs with PyCUDA > - Testing strategies for scientific codes > - Parallel processing and mpi4py > - Graph theory with Networkx > - Design patterns for efficient iterator-based scientific codes. > - Symbolic computing with sympy > > We'd like to hear from any ideas on other possible topics of interest, > and we'll then run a doodle poll to gather quantitative feedback with > the final list of candidates. > > Many thanks, > > f > -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Tutorial topics for SciPy'09 Conference
Hi, On Mon, Jun 1, 2009 at 10:20 PM, Fernando Perez wrote: > The time for the Scipy'09 conference is rapidly approaching, and we > would like to both announce the plan for tutorials and solicit > feedback from everyone on topics of interest. rather than rehash much here, where it's not easy to paste a table, I've posted a note with the poll results here: http://fdoperez.blogspot.com/2009/06/scipy-advanced-tutorials-results.html The short and plain-text-friendly version is the final topic ranking: 1 Advanced topics in matplotlib use 2 Advanced numpy 3 Designing scientific interfaces with Traits 4 Mayavi/TVTK 5 Cython 6 Symbolic computing with sympy 7 Statistics with Scipy 8 Using GPUs with PyCUDA 9 Testing strategies for scientific codes 10 Parallel computing in Python and mpi4py 11 Sparse Linear Algebra with Scipy 12 Structured and record arrays in numpy 13 Design patterns for efficient iterator-based scientific codes 14 Sage 15 The TimeSeries scikit 16 Hermes: high order Finite Element Methods 17 Graph theory with NetworkX We're currently contacting speakers, and we'll let you know once a final list is made with confirmed speakers. Cheers, f -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner wrote: > When I set the linewidths to 0 (in the patch I'm working on) I get an image > looking like this: > > http://static.ryanjwagner.com/mpl_patches/lw0.png > > I don't think this looks correct to me, as I can still see the grid. I have a > workaround in place so if linewidth=0 then the image looks like this: > > http://static.ryanjwagner.com/mpl_patches/lw0_fix.png > > Would you agree that this should be the expected functionality or should I > leave this alone, or should it be a new keyword? Perhaps leaving it as it is today for lw=0, but having your behavior be the result for lw=None? I can see people wanting the very fine grid that lw=0 gives today, and lw=None to me seems to be very explicitly saying 'no lines'. Just an idea... Cheers, f ps - Congrats to all on the release! You've all done an absolutely terriffic job, and the benefits are already becoming obvious with these new ideas and contributions. We'll have to celebrate at scipy :) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mlab cohere_pairs patch
On Tue, Aug 11, 2009 at 7:29 PM, Ariel Rokem wrote:
> ASR:matplotlib arokem$ make build_os105
> make: *** No rule to make target `build_os105'. Stop.
Typo: John said:
make build_osx105
Note the extra 'x'.
By the way John, in this particular case, I don't think the change
warrants a before/after example, because the before case is "it
doesn't run" :) The code today makes calls to Numeric routines like
typecode() that simply don't exist anymore, so it's totally broken:
In [1]: x = rand(512,3)
In [2]: ij = [(0,1),(1,2)]
In [3]: mlab.cohere_pairs(x,ij)
---
NameError Traceback (most recent call last)
/home/installers/src/scipy/matplotlib/ in ()
/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/mlab.pyc
in cohere_pairs(X, ij, NFFT, Fs, detrend, window, noverlap,
preferSpeedOverMemory, progressCallback, returnPxx)
597 windowVals = window
598 else:
--> 599 windowVals = window(np.ones((NFFT,), typecode(X)))
600 ind = range(0, numRows-NFFT+1, NFFT-noverlap)
601 numSlices = len(ind)
NameError: global name 'typecode' is not defined
The fixes Ariel is sending are strictly confined to making the code
run again, by using the equivalent numpy calls:
In [1]: x = rand(512,3)
In [2]: ij = [(0,1),(1,2)]
In [3]: mlab.cohere_pairs(x,ij)
Out[3]:
({(0, 1): 0.68070570340049885, (1, 2): 0.70577163603522997},
{(0, 1): -0.007568280470951907, (1, 2): 0.0027428217481150026},
array([ 0., 0.0078, 0.0156, 0.0234, 0.0312, 0.0391, 0.0469, 0.0547,
0.0625, 0.0703, 0.0781, 0.0859, 0.0938, 0.1016, 0.1094, 0.1172,
0.125 , 0.1328, 0.1406, 0.1484, 0.1562, 0.1641, 0.1719, 0.1797,
0.1875, 0.1953, 0.2031, 0.2109, 0.2188, 0.2266, 0.2344, 0.2422,
0.25 , 0.2578, 0.2656, 0.2734, 0.2812, 0.2891, 0.2969, 0.3047,
0.3125, 0.3203, 0.3281, 0.3359, 0.3438, 0.3516, 0.3594, 0.3672,
0.375 , 0.3828, 0.3906, 0.3984, 0.4062, 0.4141, 0.4219, 0.4297,
0.4375, 0.4453, 0.4531, 0.4609, 0.4688, 0.4766, 0.4844, 0.4922,
0.5 , 0.5078, 0.5156, 0.5234, 0.5312, 0.5391, 0.5469, 0.5547,
0.5625, 0.5703, 0.5781, 0.5859, 0.5938, 0.6016, 0.6094, 0.6172,
0.625 , 0.6328, 0.6406, 0.6484, 0.6562, 0.6641, 0.6719, 0.6797,
0.6875, 0.6953, 0.7031, 0.7109, 0.7188, 0.7266, 0.7344, 0.7422,
0.75 , 0.7578, 0.7656, 0.7734, 0.7812, 0.7891, 0.7969, 0.8047,
0.8125, 0.8203, 0.8281, 0.8359, 0.8438, 0.8516, 0.8594, 0.8672,
0.875 , 0.8828, 0.8906, 0.8984, 0.9062, 0.9141, 0.9219, 0.9297,
0.9375, 0.9453, 0.9531, 0.9609, 0.9688, 0.9766, 0.9844, 0.9922,
1.]))
Ariel, if you are still struggling with the binary build, since your
changes are confined to a pure python file, you can submit the patch
by simply running:
- svn udpate
- modify in-place mlab.py with your version of cohere_pairs
- svn diff > mlab_cohere_pairs.diff
You may want to watch out for the fact that the docstring in your
version doesn't start with
u"""
This means the string is Unicode. It seems mpl has been unicode-ified
so it's best to fix this before you generate the diff. This is why
John encourages the diff to be made against HEAD, so these little
things can be easily spotted. By doing this, you'll notice small
changes in formatting you might not have meant to introduce, so it
lets you clean up the contribution before sending it so it really only
changes what you intended to.
Cheers,
f
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: SciPy2009 BoF Wiki Page
Hi folks, David Warde-Farley kindly set up a page to coordinate BoF attendance at the conference, in case anyone on this list is interested. Details below. Cheers, f -- Forwarded message -- From: David Warde-Farley Date: Thu, Aug 13, 2009 at 2:20 PM Subject: [IPython-user] SciPy2009 BoF Wiki Page To: SciPy Users List , Discussion of Numerical Python , [email protected] I needed a short break from some heavy writing, so on Fernando's suggestion I took to the task of aggregating together mailing list traffic about the BoFs next week. So far, 4 have been proposed, and I've written down under "attendees" the names of anyone who has expressed interest (except in Perry's case, where I've only heard it via proxy). The page is at http://scipy.org/SciPy2009/BoF I've created sections below that are hyperlink targets for the topic of the session, if someone more knowledgeable of that domain can fill in those sections, please do. Edit away, and see you next week! (And if someone can forward this to the Matplotlib list, I'm not currently subscribed) David ___ IPython-user mailing list [email protected] http://mail.scipy.org/mailman/listinfo/ipython-user -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] Testing matplotlib on IPython trunk
Hey Gokhan, thanks for the summary. On Tue, Sep 8, 2009 at 12:45 PM, Gökhan Sever wrote: > ### In a new IPython, these lines work --no locking after plt.show() "-a" > makes the difference. > > I[1]: import matplotlib.pyplot as plt > > I[2]: %gui -a qt > O[2]: > > I[3]: plt.plot(range(10)) > O[3]: [] > > I[4]: plt.show() If you do plt.ion() right after you import it, then you don't need to do 'show' explicitely anymore. Basically what today's '-pylab' does is: - a bunch of imports - the equivalent of %gui, but uglier and at startup - do plt.ion() for you - patch %run a little so it does ioff() before starting up and ion() at the end. As you can see, even now with trunk in the state of upheaval it is, you can get almost all of this back with this snippet. This is pretty much what we'll make available built-in when the dust settles (with the 'import *' being optional, as they are today): %gui -a qt import numpy as np import matplotlib.pyplot as plt import matplotlib.pylab as pylab import matplotlib.mlab as mlab from numpy import * from matplotlib.pyplot import * plt.ion() ### END CODE Cheers, f -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Question on sphinxext.plot_directive...
Hi folks, if one were to say, think of writing something like a book (or a paper) using sphinx and plots generated from python scripts, the plot directive would be extremely useful. But as best as I can tell, it generates at the end of the day 'image' directives, where as for including figures in latex-produced PDF with captions and labels one can later refer to, the plain sphinx 'figure' directive appears to be more appropriate. As we can read here: http://docutils.sourceforge.net/docs/ref/rst/directives.html#images Their signatures are: Image Directive Type: "image" Doctree Element:image Directive Arguments:One, required (image URI). Directive Options: Possible. Directive Content: None. Figure Directive Type: "figure" Doctree Elements: figure, image, caption, legend Directive Arguments:One, required (image URI). Directive Options: Possible. Directive Content: Interpreted as the figure caption and an optional legend. A key difference is that image takes no content, while figure accepts content and uses it for the figure caption. Would it be possible/sensible to switch the plot directive to be a superset of 'figure' instead of 'image'? Before I dive into the code too far, I figured I'd ask the experts. Thanks! f -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Question on sphinxext.plot_directive...
On Sat, Sep 12, 2009 at 8:29 PM, Fernando Perez wrote:
> Before I dive into the code too far, I figured I'd ask the experts.
Too late for that, common sense has never been my forte.
Here's a diff against current trunk to play with this idea.
WARNING: Please note that this is NOT meant to be applied for mpl yet!!!
I've actually modified the plot directive and renamed it to 'figplot',
so we can experiment a little to better understand things. The point
is that this now lets us write reST of this type:
.. figplot:: code/make_figure_brainx.py
:width: 3.6 in
**Example from fMRI data:** In the graph presented, the nodes represent the
areas of the brain described in Figure 1. Nodes are labeled accordingly and
etc...
The text block is then passed as a caption to latex.
I renamed it because there's a bit of a conflict with the current
'plot' directive, which allows a filename *or* a content block, but in
that case the content block is meant to be the source code, as
illustrated in sampledoc:
http://matplotlib.sourceforge.net/sampledoc/extensions.html#inserting-matplotlib-plots
Since I'm not sure if we can find a clean solution to:
- path to script: goes into arg list
- inlined (multiline) code: goes into content block
- inlined (possibly multiline) caption: goes into content block
I put this version so we can start experimenting. This does what
Ariel and I need, but I hope over time we can figure out a good
long-term solution.
Speaking of sphinx for books, as I've mentioned before to John, the
last big problem is being able to cross-reference arbitrary text
elements like you can in latex, be they chapters or sections or
whatever, and get a number or something that's meaningful in print.
I looked around, and apparently it's on the main docutils todo list:
http://docutils.sourceforge.net/docs/dev/todo.html#object-numbering-and-object-references
I hope we don't have to be the ones fixing that one...
Cheers,
f
Index: plot_directive.py
===
--- plot_directive.py (revision 7753)
+++ plot_directive.py (working copy)
@@ -46,7 +46,7 @@
import matplotlib.image as image
from matplotlib import _pylab_helpers
-import only_directives
+from matplotlib.sphinxext import only_directives
if hasattr(os.path, 'relpath'):
relpath = os.path.relpath
@@ -100,12 +100,16 @@
[%(links)s]
- .. image:: %(prefix)s%(tmpdir)s/%(outname)s.png
+ .. figure:: %(prefix)s%(tmpdir)s/%(outname)s.png
%(options)s
+%(caption)s
+
.. latexonly::
- .. image:: %(prefix)s%(tmpdir)s/%(outname)s.pdf
+ .. figure:: %(prefix)s%(tmpdir)s/%(outname)s.pdf
%(options)s
+
+%(caption)s
"""
exception_template = """
@@ -228,10 +232,15 @@
return len(fig_managers)
-def plot_directive(name, arguments, options, content, lineno,
+def figplot_directive(name, arguments, options, content, lineno,
content_offset, block_text, state, state_machine):
"""
Handle the plot directive.
+
+Modified from the original matplotlib plot directive.
+
+This one does NOT allow source code, only filenames, but it produces a
+'figure' instead of an 'image', along with an optional caption.
"""
formats = setup.config.plot_formats
if type(formats) == str:
@@ -243,16 +252,26 @@
basedir, fname = os.path.split(reference)
basename, ext = os.path.splitext(fname)
basedir = relpath(basedir, setup.app.builder.srcdir)
-if len(content):
-raise ValueError("plot directive may not specify both a filename and inline content")
-content = None
+# If there is content, it will be passed as a caption.
+
+# Indent to match expansion below. XXX - The number of spaces matches
+# that of the 'options' expansion further down (plus 3, which is the
+# indent in the templates above). This should be moved to common code
+# to prevent them from diverging accidentally.
+caption = '\n'.join(' %s' % line.strip() for line in content)
+plot_code = None
else:
basedir = "inline"
-content = '\n'.join(content)
+plot_code = '\n'.join(content)
+caption = ''
# Since we don't have a filename, use a hash based on the content
-reference = basename = md5(content).hexdigest()[-10:]
+reference = basename = md5(plot_code).hexdigest()[-10:]
fname = None
+# One way or another, we've transformed the content, so set it to null
+# further on.
+content = None
+
# Get the directory of the rst file, and determine the relative
# path from the resulting html file to the plot_directive links
# (li
Re: [matplotlib-devel] Question on sphinxext.plot_directive...
On Sat, Sep 12, 2009 at 11:12 PM, Fernando Perez wrote:
> Here's a diff against current trunk to play with this idea.
Updated patch that handles correctly more than one option (I think the
bug was even in the original, not sure).
Cheers,
f
Index: plot_directive.py
===
--- plot_directive.py (revision 7753)
+++ plot_directive.py (working copy)
@@ -46,7 +46,7 @@
import matplotlib.image as image
from matplotlib import _pylab_helpers
-import only_directives
+from matplotlib.sphinxext import only_directives
if hasattr(os.path, 'relpath'):
relpath = os.path.relpath
@@ -100,12 +100,16 @@
[%(links)s]
- .. image:: %(prefix)s%(tmpdir)s/%(outname)s.png
- %(options)s
+ .. figure:: %(prefix)s%(tmpdir)s/%(outname)s.png
+%(options)s
+%(caption)s
+
.. latexonly::
- .. image:: %(prefix)s%(tmpdir)s/%(outname)s.pdf
- %(options)s
+ .. figure:: %(prefix)s%(tmpdir)s/%(outname)s.pdf
+%(options)s
+
+%(caption)s
"""
exception_template = """
@@ -228,10 +232,15 @@
return len(fig_managers)
-def plot_directive(name, arguments, options, content, lineno,
+def figplot_directive(name, arguments, options, content, lineno,
content_offset, block_text, state, state_machine):
"""
Handle the plot directive.
+
+Modified from the original matplotlib plot directive.
+
+This one does NOT allow source code, only filenames, but it produces a
+'figure' instead of an 'image', along with an optional caption.
"""
formats = setup.config.plot_formats
if type(formats) == str:
@@ -243,16 +252,25 @@
basedir, fname = os.path.split(reference)
basename, ext = os.path.splitext(fname)
basedir = relpath(basedir, setup.app.builder.srcdir)
-if len(content):
-raise ValueError("plot directive may not specify both a filename and inline content")
-content = None
+# If there is content, it will be passed as a caption.
+
+# Indent to match expansion below. XXX - The number of spaces matches
+# that of the 'options' expansion further down. This should be moved
+# to common code to prevent them from diverging accidentally.
+caption = '\n'.join(' %s' % line.strip() for line in content)
+plot_code = None
else:
basedir = "inline"
-content = '\n'.join(content)
+plot_code = '\n'.join(content)
+caption = ''
# Since we don't have a filename, use a hash based on the content
-reference = basename = md5(content).hexdigest()[-10:]
+reference = basename = md5(plot_code).hexdigest()[-10:]
fname = None
+# One way or another, we've transformed the content, so set it to null
+# further on.
+content = None
+
# Get the directory of the rst file, and determine the relative
# path from the resulting html file to the plot_directive links
# (linkdir). This relative path is used for html links *only*,
@@ -289,18 +307,19 @@
cbook.mkdirs(destdir)
# Generate the figures, and return the number of them
-num_figs = makefig(reference, content, tmpdir)
+num_figs = makefig(reference, plot_code, tmpdir)
if options.has_key('include-source'):
-if content is None:
-content = open(reference, 'r').read()
-lines = ['::', ''] + ['%s'%row.rstrip() for row in content.split('\n')]
+if plot_code is None:
+plot_code = open(reference, 'r').read()
+lines = ['::', ''] + ['%s'%row.rstrip()
+ for row in plot_code.split('\n')]
del options['include-source']
else:
lines = []
if num_figs > 0:
-options = [' :%s: %s' % (key, val) for key, val in
+options = [' :%s: %s' % (key, val) for key, val in
options.items()]
options = "\n".join(options)
if fname is not None:
@@ -339,7 +358,7 @@
setup.config = app.config
setup.confdir = app.confdir
-app.add_directive('plot', plot_directive, True, (0, 1, 0), **options)
+app.add_directive('figplot', figplot_directive, True, (0, 1, 0), **options)
app.add_config_value(
'plot_formats',
['png', 'hires.png', 'pdf'],
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Question on sphinxext.plot_directive...
Hi Michael, On Mon, Sep 14, 2009 at 6:57 AM, Michael Droettboom wrote: > I'm not sure it's that bad. It's certainly possible to do all these things > with a single directive, since providing a path or providing source code is > mutually exclusive. The thing one can't do is provide inline source *and* a > caption. I applied your patch, renaming the directive back to "plot" and > ran it over the matplotlib docs, and it doesn't seem to break anything. Well, if you're OK with the api-by-inputs approach (name+text = caption, text only=code), then I have no qualms using it. It felt a bit hackish so I was perhaps overly cautious, but I'd much rather: - have this in upstream mpl than in my own projects - have a single directive to remember So many thanks for integrating it! > Of course, we can also provide two directives, "plot" and "figplot" based on > essentially the same source code. I'm kind of neutral on the matter. I'm pretty neutral too, though perhaps it might be worth thinking about this a little more, to get a really good long-term solution. Basically, what I'd like to have is a directive that can cover these two scenarios: 1. Like today, plot with code: .. plot:: plot(x,y) 2. An extended version of today's support for files, that can handle entry points: .. plot:: script.py func1 Caption for figure 1 .. plot:: script.py func2 Caption for figure 2 This would *import* script only once, and then for each figure it would call the given function (argumentless, to keep things simple for now). Basically each call would be the equivalent of import script; script.funcN() # N=1,2 This would make it easy to compute expensive data in script once, and then render multiple plots out of it without re-executing the script in full each time. Or is this already possible with today's plot()? I think this would cover all the use cases I have in mind, from years of using a similar approach but with Makefiles. Cheers, f -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Question on sphinxext.plot_directive...
On Tue, Sep 15, 2009 at 7:57 AM, Michael Droettboom wrote: > Yeah, I have the same "not quite right" feeling about it. What about > putting the caption in an "option" such as: > > .. plot:: foo.py > :caption: This is my caption > > I don't know if the caption can have newlines in this mode, though. I will > have to experiment. Not possible, as far as I could tell. This was my first reflex and all of my experiments ended losing the other lines, and I couldn't find by searching the lists whether there was any way to do it. But I admit I didn't go as far as asking on the docutils or sphinx lists. > It's not possible now. The tricky part of this is that currently we don't > keep the module around after it's done plotting. This is actually very much > on purpose since keeping all that data around for all of the example plots > in the matplotlib documentation would quickly consume a lot of memory. > Perhaps when used in this mode (with a function argument) we could. Alas, > again that's api-by-inputs :) Well, even if the module isn't kept in memory, from an api perspective I think it would still be useful to have this .. plot:: script.py func mode. It would make it easier to organize scripts for plot generation in papers. But don't worry too much about it. The real problem was having figures with captions, and at least we have that done. Hopefully some time in the future these extensions can be cleaned up a little bit (the code is indeed a bit messy). In the meantime, we have something very useful that we need *today*, so I'm happy :) Cheers, f -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib image tutorial
Hi Michael, On Sat, Aug 29, 2009 at 9:45 AM, John Hunter wrote: > On Sat, Aug 29, 2009 at 10:58 AM, Michael Sarahan > wrote: >> Here you go. If you can think of anything else to include, I'll work >> on it. I think the next thing I'll add is something on embedding >> images in the corners of plots. figimage is the way to do this, >> right? This is very nice, many thanks! If you are interested, I think that a presentation on this would be very well received at the informal scientific computing in python group that I coordinate at UC Berkeley: https://cirl.berkeley.edu/view/Py4Science I don't know how convenient it is for you to make the trip, but if it's possible, we'd love to have you do a presentation on image processing. Just let me know any time, it's best if you write directly to my work address: [email protected] in case I miss a message on the mailing lists (I monitor that address much more closely). Cheers, f -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] sampledoc: mark out prompts in ipython sessions?
Howdy, this fixes the ipython console sphinx extension to mark up output prompts as well. Mind if I put it in? Thanks, f maqroll[sphinxext]> diff -u ipython_console_highlighting.py ~/research/papers/nitime/sphinxext/ipython_console_highlighting.py --- ipython_console_highlighting.py 2009-08-26 00:03:06.0 -0700 +++ /home/fperez/research/papers/nitime/sphinxext/ipython_console_highlighting.py 2009-09-11 18:03:19.0 -0700 @@ -77,8 +77,11 @@ [(0, Generic.Prompt, continue_prompt.group())])) curcode += line[continue_prompt.end():] elif output_prompt is not None: +# Use the 'error' token for output. We should probably make +# our own token, but error is typicaly in a bright color like +# red, so it works fine for our Output prompts. insertions.append((len(curcode), - [(0, Generic.Output, output_prompt.group())])) + [(0, Generic.Error, output_prompt.group())])) curcode += line[output_prompt.end():] else: if curcode: -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] sampledoc: mark out prompts in ipython sessions?
2009/9/17 John Hunter : > On Thu, Sep 17, 2009 at 9:30 AM, Michael Droettboom wrote: >> Looks fine to me. We were offering to commit this to matplotlib, or >> should I? > > You should let Fernando, so he can survive the annual purge of > developers no longer committing :-) Thanks :) I'll take care of it later then, I'll try to fix a warning we're seeing as well because it lacks a setup.py. Cheers, f -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] sampledoc: mark out prompts in ipython sessions?
On Thu, Sep 17, 2009 at 11:02 AM, Fernando Perez wrote: > Thanks :) I'll take care of it later then, I'll try to fix a warning > we're seeing as well because it lacks a setup.py. > Done. I also committed the update to sampledoc, with a note in the log to eventually remove it once it's 'enough' in the wild in mpl. Cheers, f -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] Testing matplotlib on IPython trunk
2009/9/21 Gökhan Sever : > > It's a very late reply but I am wondering how to make these appear in the Ipy > dev loaded into the session but not visible to a whos listing? > I don't think that's supported quite right now. IPython does one special thing to support a clean %whos listing: right before opening up the user mainloop, it checks all keys in the user namespace, and later on when %whos is run, those variables that were initially present are not displayed. So for now if you do this interactively, you will unfortunately pollute %whos. This is one thing we'll need to make sure works nicely again when the dust settles. Cheers, f -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] [ANN] For SF Bay Area residents: a discussion with Guido at the Berkeley Py4Science seminar
Hi folks, if you reside in the San Francisco Bay Area, you may be interested in a meeting we'll be having tomorrow November 4 (2-4 pm), as part of our regular py4science meeting series. Guido van Rossum, the creator of the Python language, will visit for a session where we will first do a very rapid overview of a number of scientific projects that use Python (in a lightning talk format) and then we will have an open discussion with Guido with hopefully interesting questions going in both directions. The meeting is open to all, bring your questions! More details on this seminar series (including location) can be found here: https://cirl.berkeley.edu/view/Py4Science Cheers, f -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] boxplot notch
On Tue, Dec 15, 2009 at 9:57 AM, Andrew Straw wrote: > > notch_max = med + 1.57*iq/np.sqrt(row) > notch_min = med - 1.57*iq/np.sqrt(row) > > Is this code actually calculating a meaningful value? If so, what? > >From the statistics ignoramus in the room, so take this with a grain of salt... I'd write that code as notch_max = med + (iq/2) * (pi/np.sqrt(row)) and it makes more sense. The notch limits are an estimate of the interval of the median, which is (one-half, for each up/down) the q3-q1 range times a normalization factor which is pi/sqrt(n), where n==row=len(d). The 1/sqrt(n) makes some sense, as it's the usual statistical error normalization factor. The multiplication by pi, I'm not so sure, and I can't find that exact formula in any quick stats reference, but I'm sure someone who actually knows stats can point out where it comes from. Note that the code below does: if notch_max > q3: notch_max = q3 if notch_min < q1: notch_min = q1 though matlab explicitly states in: http://www.mathworks.com/access/helpdesk/help/toolbox/stats/boxplot.html that """ Interval endpoints are the extremes of the notches or the centers of the triangular markers. When the sample size is small, notches may extend beyond the end of the box. """ So it seems to me that the more principled thing to do would be to leave those notch markers outside the box if they land there, because that's a warning of the robustness of the estimation. Clipping them to q1/q3 is effectively hiding a problem... cheers, f -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] boxplot notch
On Fri, Dec 18, 2009 at 2:28 PM, Andrew Straw wrote: > (This still leaves open the question of what the notches actually _are_...) No idea. I'd still leave the code instead written as notch_max = med + (iq/2) * (pi/np.sqrt(row)) as that's what it appears to be doing (unless 1.57 is *not* pi/2 in this case). That might help someone spot what formula the factors come from. Even better would be to get from the original author an explanation of where those factors come from :) I did look around some more, couldn't find an answer... Cheers, f -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Qt4 backend: critical bug with PyQt4 v4.6+
Howdy,
On Sat, Nov 7, 2009 at 12:30 PM, Darren Dale wrote:
> Me too. And thank you for posting the report and a workaround.
Quick question: would it be worth adding this monkeypatch to mpl
proper? Right now, the qt4 backend is effectively unusable out of the
box in distros like Karmic. Which is a bummer, because with the
ipython sitting on my laptop, one can now load 'pylab' at any time
during a session:
maqroll[scratch]> ip
Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15)
Type "copyright", "credits" or "license" for more information.
IPython 0.11.bzr.r1219 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: import sys
In [2]: 'matplotlib' in sys.modules
Out[2]: False
In [3]: %pylab wx
Activating matplotlib with backend: WXAgg
Welcome to pylab, a matplotlib-based Python environment.
For more information, type 'help(pylab)'.
Switching IPython gui support to: wx True
In [4]: 'matplotlib' in sys.modules
Out[4]: True
In [5]: plot(sin(linspace(0,2*pi,200)))
Out[5]: []
This is starting to look very promising, but unfortunately:
- right now we don't have gui switching support for Qt3 at all in
ipython. Help is welcome, but I have no clue if it's easy/hard or
even needed much anymore...
- qt4 is unusable with the system's qt/pyqt...
So perhaps a local patch would be worth it, no? I can confirm that
with the attached patch, the new ipython support works:
In [1]: %pylab qt
Activating matplotlib with backend: Qt4Agg
Welcome to pylab, a matplotlib-based Python environment.
For more information, type 'help(pylab)'.
In [2]: run simpleplot.py
In [3]: close('all')
In [4]: run simpleplot.py
whereas before, I'd get the same nasty error mentioned above.
The patch now has no run-time impact (I modified Pierre's code a bit
so the check is done only once), but I'm not about to commit something
in the Qt backend without someone else's eyes, especially Darren's :)
Cheers,
f
mpl_qt4.diff
Description: Binary data
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Allowing mpl backend switching?
Howdy, are there fundamental reasons to keep this code around in backends/__init__.py:use() ? if 'matplotlib.backends' in sys.modules: if warn: warnings.warn(_use_error_msg) return I am now testing the new IPython gui stuff, and if I comment that out and call pyplot.switch_backend() when I load mpl (along with the qt patch I sent earlier), I can hop around backends, at least with Qt4 and Wx: In [10]: %pylab qt Welcome to pylab, a matplotlib-based Python environment. Backend in use: Qt4Agg For more information, type 'help(pylab)'. In [11]: run simpleplot.py In [13]: %pylab wx Welcome to pylab, a matplotlib-based Python environment. Backend in use: WXAgg For more information, type 'help(pylab)'. In [16]: run simpleplot.py In [17]: figure() Out[17]: In [18]: plot(sin(linspace(0,2*pi,200)**2)) Out[18]: [] In [19]: %pylab qt Welcome to pylab, a matplotlib-based Python environment. Backend in use: Qt4Agg For more information, type 'help(pylab)'. In [20]: run simpleplot.py In [21]: figure() Out[21]: In [22]: plot(sin(linspace(0,2*pi,200))) Out[22]: [] etc... I see lockups trying to throw Tk or Gtk in the mix, but being able to switch from Wx to Qt and back would be nice, especially since it would allow using Mayavi and other enthought apps together with Qt-based tools. mpl closes open windows on backend switch, but at least you can go back and forth, which is better than nothing and can be useful for debugging. This is still very early/experimental ipython code, I just want to start getting a feel for the mpl-side of the equation... Cheers, f -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Qt4 backend: critical bug with PyQt4 v4.6+
On Thu, Dec 31, 2009 at 4:54 AM, Darren Dale wrote: > I have been resistant to committing this patch because (in my opinion) > mpl should not have to provide workarounds for bugs in package X on OS > Y, distribution Z. I think this particular issue was fixed when > PyQt4-4.6.2 was released. But its time to get practical, I suppose. > The patch looks fine, I just checked it into the trunk. Thanks! As the zen goes, practicality beats purity :) I understand your reluctance though, it's annoying to pepper mpl's code with this kind of junk. Happy New Year! f -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] glumpy, fast opengl visualization
Hi Nicolas, On Mon, Jan 25, 2010 at 2:46 AM, Nicolas Rougier wrote: > > > Hello, > > This is an update about glumpy, a fast-OpenGL based numpy visualization. > I modified the code such that the only dependencies are PyOpenGL and > IPython (for interactive sessions). You will also need matplotlib and > scipy for some demos. > > Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy > No installation required, you can run all demos inplace. > > Homepage: http://code.google.com/p/glumpy/ This is great, and it would be very cool to have it updated to the new code we're now landing in ipython with a much cleaner internal API (finally :) Have you had a chance to look at the code in my trunk-dev branch? https://code.launchpad.net/~fdo.perez/ipython/trunk-dev Brian finished a large review of it and we just had a chance to go over his feedback directly, so there's now one more round of reviews to do (once he applies the changes from our discussion) and this should become trunk very soon. The apis are much cleaner, this is the big cleanup I told you about last year, and now we're getting to the point where having multiple ipython frontends is a very realistic prospect. Unfortunately we won't be able to use your code directly in IPython as it stands, since the GPL provisions in it would require us to GPL all of IPython to make use of any of it directly in IPython. Your code uses iptyhon, numpy, matplotlib and scipy (in some demos), which amounts to hundreds of thousands of lines of code; here are the sloccount outputs from their respective trunks: IPython Totals grouped by language (dominant language first): python: 47357 (99.24%) lisp: 262 (0.55%) sh: 62 (0.13%) objc:37 (0.08%) Numpy Totals grouped by language (dominant language first): ansic: 152950 (67.19%) python: 73188 (32.15%) cpp:828 (0.36%) fortran:298 (0.13%) sh: 156 (0.07%) pascal: 120 (0.05%) f90: 97 (0.04%) Matplotlib Totals grouped by language (dominant language first): python: 83290 (52.64%) cpp: 68212 (43.11%) objc: 4517 (2.85%) ansic: 2149 (1.36%) sh: 69 (0.04%) Scipy Totals grouped by language (dominant language first): cpp: 220149 (48.35%) fortran: 87240 (19.16%) python: 79164 (17.38%) ansic:68746 (15.10%) sh: 61 (0.01%) Glumpy: Totals grouped by language (dominant language first): python:3751 (100.00%) We're looking at ~300.000 lines of python alone in these tools. It's unfortunately not realistic for us to consider GPL-ing them in order to incorporate glumpy into the core set; it would be fantastic if you were willing to consider licensing your code under a license that is compatible with the body of work you are building on top of. You are obviously free to choose your license as you see fit, and end users (myself included) will be always able to use glumpy along with ipython, numpy, matplotlib and scipy. So *users* get all of the benefit of your contribution, and for that I am the first to be delighted and grateful that you've put your code out there. But as it stands, your code builds on close to half a million lines of other code which can not benefit back from your contributions. If you consider licensing glumpy to be compatible with ipython, numpy and matplotlib, it would be possible to incorporate your ideas back into those projects: perhaps in some places the right solution would be to fix our own designs to better provide what glumpy needs, in other cases we may find fixes you've made fit better upstream, etc. But this kind of collaboration will not be possible as long as glumpy can benefit from our tools but our codes are not allowed to benefit from glumpy (without changing licenses, which isn't going to happen). I hope you consider this from our perspective and in the most friendly and open manner: I completely respect your right to license your own code as you see fit (I've seen people put out GPL 'projects' that effectively consist of 3 lines that import IPython and make a function call, and that's OK too, and allowed by the license I chose to use). The only reason I ask you is because I think your tool is very interesting, and it would ultimately lead to a much more productive relationship with ipython, numpy and matplotlib if it could be a collaboration instead of a one-way benefit. Best regards, Fernando. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Matplotlib-devel mailing list [email protected]
[matplotlib-devel] A small improvement to plot directive
Hi all,
would anyone mind if I commit the attached patch?
It's 100% backwards compatible and allows for turning plot directive
errors into fatal exceptions easily, so one can make sure that docs
either build correctly or not at all. This is useful for having
examples be a kind of test suite, in addition to any unit tests a
codebase may have.
Thanks,
f
Index: lib/matplotlib/sphinxext/plot_directive.py
===
--- lib/matplotlib/sphinxext/plot_directive.py (revision 8097)
+++ lib/matplotlib/sphinxext/plot_directive.py (working copy)
@@ -76,6 +76,21 @@
from matplotlib import _pylab_helpers
from matplotlib.sphinxext import only_directives
+
+class PlotWarning(Warning):
+"""Warning category for all warnings generated by this directive.
+
+By printing our warnings with this category, it becomes possible to turn
+them into errors by using in your conf.py::
+
+ warnings.simplefilter('error', plot_directive.PlotWarning)
+
+This way, you can ensure that your docs only build if all your examples
+actually run successfully.
+"""
+pass
+
+
# os.path.relpath is new in Python 2.6
if hasattr(os.path, 'relpath'):
relpath = os.path.relpath
@@ -208,7 +223,7 @@
figman.canvas.figure.savefig(outpath, dpi=dpi)
except:
s = cbook.exception_to_str("Exception saving plot %s" % plot_path)
-warnings.warn(s)
+warnings.warn(s, PlotWarning)
return 0
if j > 0:
shutil.copyfile(outpath, os.path.join(destdir, outname))
@@ -270,7 +285,7 @@
run_code(plot_path, function_name, plot_code)
except:
s = cbook.exception_to_str("Exception running plot %s" % plot_path)
-warnings.warn(s)
+warnings.warn(s, PlotWarning)
return 0
num_figs = run_savefig(plot_path, basename, tmpdir, destdir, formats)
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] A small improvement to plot directive
On Wed, Jan 27, 2010 at 6:06 PM, Andrew Straw wrote: > I'm +1 on this. We can have then have the buildbot doc builder enable > this when building the docs. (Which are output at > http://matplotlib.sourceforge.net/trunk-docs/ and > http://matplotlib.sourceforge.net/trunk-docs/Matplotlib.pdf , for > reference .) Thanks, with your and John's (off-list) approvals, it's committed. The patch that went in had more docs than what I posted here, but the code is identical. Cheers, f -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] A small improvement to plot directive
On Thu, Jan 28, 2010 at 2:51 PM, Fernando Perez wrote: > Thanks, with your and John's (off-list) approvals, it's committed. > The patch that went in had more docs than what I posted here, but the > code is identical. Oops, somehow my commit had never made it, I just noticed now I was trying to use it from another machine. Fixed now, r8110. Cheers, f -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: [IPython-dev] GUI support: conflicts between IPython 0.11 and Matplotlib/ETS
Hi folks, the message below is an important discussion on which we'd like feedback/ideas both from Enthought.traits experts and matplotlib ones. It would be great if we could keep things in one list, so it seems most sensible to hold the discussion in the ipython-dev list, but this is a heads-up in case one of you is interested but may not monitor ipython-dev. Thanks! f -- Forwarded message -- From: Brian Granger Date: Tue, Feb 9, 2010 at 11:59 PM Subject: [IPython-dev] GUI support: conflicts between IPython 0.11 and Matplotlib/ETS To: IPython Development list Hello all, As many of you know, we have been working hard on IPython 0.11. One of the big new features of 0.11 is a refactored integration with GUI event loops. We are very excited about this as it is much more stable and add new capabilities, like being able to enable pylab *after* starting IPython (it is a magic: %pylab). BUT, as Fernando and I have started to use the IPython 0.11 alpha for our daily work, we have found some subtle issue with IPython 0.11 and the current versions of matplotlib and Enthought tool suite (traits, chaco, mayavi). All of these packages rely on IPython's previous way of handling GUI integration. Because of this, current versions of matplotlib and ets don't work fully with IPython 0.11. In some cases, they work OK, but there are a whole class of bugs that keep popping up. We don't want to release IPython 0.11 until these issues are resolved. All of these bugs are related to a few aspects of creating the main GUI app objects and starting event loops. We think we understand the issues, but we will need to work with the devs of matplotlib and ets to decide on how we all want to handle these things. Here is where we are at... Current situation = Both matplotlib and ets have code that tries to: * See what GUI toolkit is being used * Get the global App object if it already exists, if not create it. * See if the main loop is running, if not possibly start it. All of this logic makes many assumptions about how IPython affects the answers to these questions. Because IPython's GUI support has changed in significant ways, current matplotlib and ets make incorrect decisions about these issues (such as trying to start the event loop a second time, creating a second main App ojbect, etc.) under IPython 0.11. This leads to crashes... Description of GUI support in 0.11 == IPython allows GUI event loops to be run in an interactive IPython session. This is done using Python's PyOS_InputHook hook which Python calls when the :func:`raw_input` function is called and is waiting for user input. IPython has versions of this hook for wx, pyqt4 and pygtk. When the inputhook is called, it iterates the GUI event loop until a user starts to type again. When the user stops typing, the event loop iterates again. This is how tk works. When a GUI program is used interactively within IPython, the event loop of the GUI should *not* be started. This is because, the PyOS_Inputhook itself is responsible for iterating the GUI event loop. IPython has facilities for installing the needed input hook for each GUI toolkit and for creating the needed main GUI application object. Usually, these main application objects should be created only once and for some GUI toolkits, special options have to be passed to the application object to enable it to function properly in IPython. What we need to decide === We need to answer the following questions: * Who is responsible for creating the main GUI application object, IPython or third parties (matplotlib, enthought.traits, etc.)? * What is the proper way for third party code to detect if a GUI application object has already been created? If one has been created, how should the existing instance be retrieved? * In a GUI application object has been created, how should third party code detect if the GUI event loop is running. It is not sufficient to call the relevant function methods in the GUI toolkits (like ``IsMainLoopRunning``) because those don't know if the GUI event loop is running through the input hook. * We might need a way for third party code to determine if it is running in IPython or not. Currently, the only way of running GUI code in IPython is by using the input hook, but eventually, GUI based versions of IPython will allow the GUI event loop in the more traditional manner. We will need a way for third party code to distinguish between these two cases. Thanks for participating in this discussion! Cheers, Brian ___ IPython-dev mailing list [email protected] http://mail.scipy.org/mailman/listinfo/ipython-dev -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.
[matplotlib-devel] An easier way to create figure and group of axes; useful?
Howdy, in trying to teach a more structured use of mpl, I keep getting annoyed by the whole figure(), add_subplot(), grab axes dance. I've also seen students get confused by it. Does something along these lines sound useful to have in the core (see attached)? In use, below. You'd normally capture f, a = figaxes(...) to get the figure and axes list, but I leave it off here for display purposes: In [37]: figaxes() Out[37]: (, []) In [38]: figaxes((2,1)) Out[38]: (, [, ]) In [39]: figaxes((2,2),dict(polar=True)) Out[39]: (, [, , , ]) Feedback welcome. Cheers, f fax.py Description: Binary data -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 7:27 PM, David Warde-Farley wrote: > > An effusive "yes, yes, good god yes!" from this mpl-devel lurker. Thanks, that's two good pluses. Any suggestions on name changes, or other fixes to make? Otherwise, once I find a free minute I'll put it in. Should it go into pyplot directly, or elsewhere and imported from pyplot to expose it at the top-level? (I'm not overly familiar with the layout of the whole library). I'm also trying to show my students how *they* can improve their tools; e.g. earlier this week a homework problem I wrote up led me to a useful sympy patch that was quickly upstreamed: http://git.sympy.org/?p=sympy.git;a=commit;h=507c4df6a9edfd5de5ad28535d1f9236db23bf04 and perhaps with this one we can do the same. I hope that with a few of these examples, at least a few of them will see the value of making the transition from pure user-mode to more involved users/contributors (for context, this is a group of scientists in Colombia with good computational skills but no tradition of open source contributions; I'm hoping to help a little on this front). Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 10:17 PM, John Hunter wrote: > I think the name "figsubplots" or "fig_subplots" is better because you > are creating Subplot instances. Alternatively, you might want to > consider simply "subplots" which returns just the list of subplots: > the figure can always be accessed as an attribute of the Subplot > instance:: > > ax1, ax2, ax2, ax4 = subplots(2,2) > fig = ax1.figure > > Not sure that this is better; just a thought. Mmh, even I didn't know that, so I doubt my students would :) Idle thought: we've inherited the ugly 1-offset numbering scheme for subplots from matlab, how about making fig_subplots return [fig, ax1, ax2, ...] This would at least make it easier to remember indexing, since axN == ax[N] would be true. It would also help with the shareax below, see rest of message... >> Should it go into pyplot directly, or elsewhere and imported from >> pyplot to expose it at the top-level? (I'm not overly familiar with >> the layout of the whole library). > > pyplots is the right place for it since it is implicitly creating a > current figure and the only place where that magic happens is in > pyplot. OK. >> I'm also trying to show my students how *they* can improve their >> tools; e.g. earlier this week a homework problem I wrote up led me to >> a useful sympy patch that was quickly upstreamed: > > This is a worthy goal. One use case I would like to see supported > is the sharex/sharey args:: Sheesh, some people really want everything :) > ax1 = fig.add_subplot(211) > ax2 = fig.add_subplot(212, sharex=ax1) [...] > Perhaps the solution to my sharex conundrum is to support an axes number, eg > > ax1, ax2, ax3, ax4 = subplots(4,1, sharex=1) > > so all the subplots would have sharex with ax1. That was what I had in mind, I just hadn't had time to try it. Here it goes (since I started this while preparing class exercises, it's now in the class git repo): http://gfif.udea.edu.co/idf/indefero/www/index.php/p/mscomp-2010/source/tree/master/0217/figsubp.py Comment away, I'll polish it later for mpl over svn, while waiting for us to catch up with the XXth century and move over to git :) There are examples to try it out and see how it works (download link at the bottom of that page). Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Feb 18, 2010 at 8:02 AM, John Hunter wrote: > Yes, you should know better by now than to propose a minor enhancement And you should know by know common sense has somehow been amputated from my system :) > Another thought about the interface. How about *just* returning the > figure instance, and let the users simply index into the axes list. > Then they can have their 0 based indexing because it is a python > list:: > > fig = fig_subplot((2,1), sharex=1) > fig.axes[0].plot(...) > fig.axes[1].scatter(...) > > mpl is creating this axes list anyway I'm also fine with your > implementation -- just a suggestion. Mmh, doubting: the more compact api is appealing, but in actual use it seems to make for a lot of typing, since the really useful objects for most things are the axes. Given that in python3 we'll have more flexible unpacking: Python 3.1.1 (r311:74480, Sep 18 2009, 19:43:55) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = list(range(10)) >>> x, y, *z = a >>> x, y, z (0, 1, [2, 3, 4, 5, 6, 7, 8, 9]) >>> m, *n, p, q = a >>> m, n, p, q (0, [1, 2, 3, 4, 5, 6, 7], 8, 9) makes me lean towards keeping the [fig, ax1, ax2...] notation. But I'm willing to reconsider on further arguments. > One other thing: I don't think a tuple is best for the axes > dimensionality. We always require two and exactly two shape arguments > (numrows, numcols) so we don't need the flexibility of the tuple in > the way that numpy.zeros does. And it is easier to type:: > > fig_subplot(2, 1, sharex=1) > > than:: > > fig_subplot((2,1), sharex=1) > > As the world master of keystroke efficiency, I would think you would > appreciate the savings! But again, if you prefer the tuple, I don't > have a problem with it. It does have the advantage of visually > suggesting a single shape argument. > +1 for the (nr, nc, share...) form. I won't have time to work on this for a couple of days though; keep further feedback coming, I should be back home on Monday and able to finish it (I'm away on a teaching-sprint-within-a-teaching-marathon for a couple of days). If anyone wants to finish it first, run with it., I'm not personally attached to it. Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Howdy On Thu, Feb 18, 2010 at 1:19 PM, Jae-Joon Lee wrote: > > I thought there is no master and slave for an axis-sharing? > If that's the case, maybe "sharex=True" should be suffice? I defer to your wisdom here: I had no clue about this, so I went for the clumsier API. If you are right, it would also make the implementation much simpler, as I had to play some not-totally-obvious gymnastics to alter axis creation order based on this parameter. One more, related question: is it possible/reasonable to share *both* x and y axes? It would be really nice if you were correct. The api could be nicer and the implementation simpler. > Also, how about "subplots" returns a some kind of object so that we > may define some methods on it. We can define "__iter__" method so > that above syntax also works. As an example, > > mysubplots = subplots(4,1, sharex=True) > mysubplots.label_outer() > ax1, ax2, ax3, ax4 = mysubplots Mmh, more than I have time for right now, I'm afraid (I'm really pushing it with these little side-trips already). But if you do have a minute to do it, run with it. I can only commit to finish the basic implementation with the changes discussed above, plus any fixes to share* based on clarifying these points. A fancier object API would be great to have, so by all means go ahead if you have the bandwidth! Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sat, Feb 20, 2010 at 3:50 PM, Jae-Joon Lee wrote: > > > After quickly going through the mpl source (and in my experience), I > think it is quite safe to assume that there is no master-slave > relation among the shared axes. > > >> One more, related question: is it possible/reasonable to share *both* >> x and y axes? > > Yes, it is possible as I often do. OK, thanks for the feedback. I've just finalized it here: http://gfif.udea.edu.co/idf/indefero/www/index.php/p/mscomp-2010/source/tree/master/0217/figsubp.py Knowing now that the sharing doesn't have an actual master/slave relationship (like the existing examples suggest since they appear to require an explicit index for sharing), the actual implementation was really trivial in the end. It might be a good idea to clarify this in the main docs, the current examples make axis sharing look harder than it actually is (all those tricks with order creation I was playing are completely unnecessary). If you all like this API, I'm happy to push into the real svn repo. Final question: should I put the little demo code at the bottom that I used for testing this up in an example file? I put some of that in the docstring as an example, but not all to avoid clutter. Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Tue, Feb 23, 2010 at 10:14 PM, Fernando Perez wrote: > Final question: should I put the little demo code at the bottom that I > used for testing this up in an example file? I put some of that in > the docstring as an example, but not all to avoid clutter. OK, since I know people are busy, I took silence as acquiescence. Committed in r8151, please let me know if I messed anything up and I'll try to fix it. I'm used to the numpy docstring standard, but I tried to adapt it to the mpl one by looking at the rest of pyplot, let me know if it needs fine-tuning. Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Howdy, On Wed, Feb 24, 2010 at 11:27 AM, Fernando Perez wrote: > OK, since I know people are busy, I took silence as acquiescence. > Committed in r8151, please let me know if I messed anything up and > I'll try to fix it. I'm used to the numpy docstring standard, but I > tried to adapt it to the mpl one by looking at the rest of pyplot, > let me know if it needs fine-tuning. While chatting today with John, he suggested that a better api for this would be to return an *array* of supblots, so that one could index them with a[i,j] for the plot in row i, column j. I've implemented this already, but before committing it, I have one doubt: what to do when nrows==ncols==1, the single subplot case? I'm inclined to return only the subplot instead of a one-element array, so that one can say f, a = fig_subplot() a.plot(...) instead of having to do f, a = fig_subplot() a[0].plot(...) But this means the return value of the function would be: - fig, axis if nr=nc=1 - fig, axis_array in all other cases. so it's a bit ugly. I think this is a case where practicality beats purity and my nose tells me to go for the less pretty but more convenient api, but I'm happy to get feedback. The return code reads currently: # Reshape the array to have the final desired dimension (nrow,ncol), though # discarding unneeded dimensions that equal 1. If we only have one # subplot, just return it instead of a 1-element array. if nplots==1: return fig, axarr[0] else: return fig, axarr.reshape(nrows, ncols).squeeze() Once we settle this design decision, I'll update the docstring and example and will post the patch for final review before committing. Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 11:47 AM, John Hunter wrote: > I disagree here -- if you are 2,1 or 1,2 rows x cols, 1D indexing is > natural. This is also the most common use case so the most important > to get right. If you aren't doing multiple subplots, a plain ol > subplot(111) may be preferred to fig_subplots anyhow. > I agree with John that for nx1 or 1xn, 1-d indexing seems more natural, and is the more pythonic solution given how numpy doesn't distinguish between row and column arrays when they are 1-d, in contrast to matlab. This is why I went for the approach above. Based on the feedback, I'll finish it tonight with squeeze=True as a kwarg, that behaves: - if True (default): single axis is returned as a scalar, Nx1 or 1xN are returned as numpy 1-d arrays, and only NxM with N>1 and M>1 are returned as a 2d array. - if False, no squeezing at all is done, the return value is always a 2-d array, even if it ends up being 1x1. I think this gives a very convenient interactive/lightweight scripting interface, while letting application builders who may need to write generic code that is dimension agnostic have robust code that needs no special-casing by passing squeeze=False. Unless I hear otherwise, I'll make the commit with these changes (updating the docstring and example script accordingly). Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 3:49 PM, Christopher Barker wrote: > > > Good solution, and thanks for working on this! Thanks. I have one more question on this feature. I personally think that this should be the way to use mpl in general when scripting, and the way I want to teach, because it's easy and short while encouraging access to more robust patterns (figure/axes handing instead of the stateful pyplot). For this reason, I think the name should be really well chosen, and I'm not convinced fig_subplot is a very good one. I know naming discussions can be annoying, but if this ends up being the most popular/common entry point for making plots, it may be worth spending a moment on picking it right. Ideas (I'm *awful* at naming)? - plot_array? - plots? - subplots? - parray? - plotarr? - something actually good from someone else? I'll finish the patch tonight, we can always fix the name later as it's a trivial search/replace on fig_subplots -> new_great_name. Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 6:39 PM, John Hunter wrote: > I also think the name should be changed, and there should be an entry > in the matplotlib.figure.Figure API. One additional suggestion is > "subarray" and matplotlib.pyplot.subarray would be a thin wrapper to > matplotlib.figure.Figure.add_subarray. The former would return (fig, > axarray) using gcf() to get the current figure, and the latter would > simply create the subarray and return it. The would break a bit with > the pyplot "axes" and "subplot" commands that only return the Axes and > Subplot instances (and not the implicit Figure instance created/used) > but I can live with that because part of the goal here is to give easy > access to axes and figure creation so the user can get in the habit of > using the API directly for most things. > > As for the other name suggestions, I like "subplots". Without further feedback, I went with John's vote on 'subplots' and have committed the changes to the API as agreed, now naming it plt.subplots(). I'm sorry but I didn't implement the full Figure.add_subarray() changes you suggested, ran out of time... There is, however, a fly in the ointment: while this new code feels very nice from playing wtih it in scripts like the example just committed: http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/examples/pylab_examples/subplots_demo.py?revision=8202&view=markup it is NOT pleasant to use interactively, because the OO api requires explicit draw() calls all the time. I just realized this now using it more, and it's a bummer, because it makes it less likely that one will use this type of code in everyday interactive exploration. I wonder if it's possible to put things like a draw_if_interactive() call at the end of the OO methods... I realize that pyplot was the only one meant to do that, but if we are to encourage using the OO api more, then it's going to have to be as pleasant to use as pyplot... I don't know the codebase well enough to mess with this right now, so I hope someone who's more versed in that part of the code can make a fix for this whose impact isn't too severe on the runtime of OO code. Cheers, f ps - Chris, thanks for the encouragement :) -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sat, Mar 20, 2010 at 4:00 PM, Jae-Joon Lee wrote: > On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perez wrote: >> I wonder if it's possible to put things like a draw_if_interactive() >> call at the end of the OO methods... I realize that pyplot was the >> only one meant to do that, but if we are to encourage using the OO api >> more, then it's going to have to be as pleasant to use as pyplot... I >> don't know the codebase well enough to mess with this right now, so I >> hope someone who's more versed in that part of the code can make a fix >> for this whose impact isn't too severe on the runtime of OO code. > > I'm not very inclined to this but I'll wait to hear what others think. > I use oo api in the interactive mode but I still prefer to call draw() > explicitly. > Of course, we can make it optional. Mmh, back to this one: I do think it would be something useful to have somewhere, because typing draw() after *every* operation when working interactively does get tiresome, it seems to me... If we encourage calling subplots() for new teaching, then we do want it to be as pleasant as pyplot to use interactively, I think... Is it technically expensive to put in? Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Passing errorbar width arguments to bar/barh ?
Hi all, I just spent some time digging through the matplotlib code, and I see that the errorbar line width argument isn't passed through to the underlying call. In axis.bar, we have this code: if xerr is not None or yerr is not None: if orientation == 'vertical': # using list comps rather than arrays to preserve unit info x = [l+0.5*w for l, w in zip(left, width)] y = [b+h for b,h in zip(bottom, height)] elif orientation == 'horizontal': # using list comps rather than arrays to preserve unit info x = [l+w for l,w in zip(left, width)] y = [b+0.5*h for b,h in zip(bottom, height)] self.errorbar( x, y, yerr=yerr, xerr=xerr, fmt=None, ecolor=ecolor, capsize=capsize) while errorbar has this signature: def errorbar(self, x, y, yerr=None, xerr=None, fmt='-', ecolor=None, elinewidth=None, capsize=3, barsabove=False, lolims=False, uplims=False, xlolims=False, xuplims=False, **kwargs): For a poster, we wanted thicker errorbars drawn and had to resort to: plt.rcParams['lines.markeredgewidth'] = 2 plt.rcParams['lines.linewidth'] = 2 and reverting back to normal width after making the errorbar calls. Should I file a ticket about this, or are such fine-tuning tasks considered as fair game for rcParams manipulations? I'm happy to file the ticket, I just don't want to create unnecessary noise if the rcparams is meant to be 'the way' to do it. Cheers, f -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?
On Tue, Jun 1, 2010 at 4:35 PM, Eric Firing wrote: > it seems to me that the solution is for > bar to take a kwarg, say "errorkw", which is a dict that will be passed > to errorbar via **errorkw, and that can have any valid errorbar kwargs > in it. There is some precedent for this sort of thing, and I find it a > useful way of keeping kwargs from getting out of control when one is > making complicated compound plots. That would be my suggessted approach as well, I've used it elsewhere. > If there is no objection, I will do it. Fabulous, many thanks! Cheers, f -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?
On Wed, Jun 2, 2010 at 1:44 PM, Eric Firing wrote: > Done in svn 8369. Its usage is illustrated in barchart_demo.py. > Partially following your lead with subplots, I spelled it error_kw. > Fabulous, much appreciated! Regards, f -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] refactoring of show
Hey guys, On Mon, Jul 19, 2010 at 4:07 PM, Eric Firing wrote: > > Please leave out the -a. It is harmful, not helpful, for mpl. This may > mean we need to change mpl and/or ipython, or the documentation, to > prevent problems with the -a option; but I think you will find that if > you leave out that option, the behavior will be more consistent and the > need for Ctrl-C will go away. Without %gui, there will still be an > inconsistency between wx and the others--but that's what the %gui magic > is for, to make wx use PyOS_InputHook like the others. I just wanted to say thanks a LOT for this testing. Right now we're not quite in the gui code, but it's *very* useful for us to have this information. And please keep in mind that if you find out that from the ipython side we're doing something silly/backwards regarding this, we're more than happy to change it. We ultimately want the gui integration to be as painless as possible. One extra twist to consider: we're moving to a 2-process model for most of ipython, so that user interface and code execution live in separate processes. It will continue to be possible to use a one-process ipython, but we think most users will prefer the two-process model. One quirk there will be that %gui now uses PyOSInputHook to talk to the GUI event loop, but this is only called by Python if stdin is waiting for input. In a server process (like we are starting to develop), there is no interactive input (the input comes over a socket) so we'll need to worry about letting the GUI event loop work while keeping the network event loop also responsive. As our picture becomes clearer we'll make sure to update you folks as well, so we can work from both ends (ipython/mpl) to ensure a good end-user experience with minimal fuss and all relevant backends. 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 [email protected] 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 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 [email protected] 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 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 > ([email protected] 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 [email protected] 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 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 [email protected] 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
[email protected]
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 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 [email protected] 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 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing wrote: > I committed it. > Many thanks Eric, for being so responsive! Some eye candy to give you an idea of what we're getting from this work: http://fperez.org/tmp/multiplot.png http://fperez.org/tmp/multiplot2.png The second is the MPL contours example, pasted straight into the new ipython frontend, and all plots are correctly rendered inline. All this should be ready for adventurous users to begin testing in a few weeks (it's still a bit alpha right now, so really 'hardhat-only'). But we're very happy with how things are progressing, and it's fabulous to have your rapid response rate on the MPL side. Best regards, 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
Hi Eric, On Sat, Aug 28, 2010 at 4:27 PM, Eric Firing wrote: > > Impressive--but I don't think I understand why one would want plots rendered > inline rather than in separate windows. It's not 'rather than', it's 'in addition to' :) Imagine you and I are working on a problem together, you have IPython open and you get the plot windows on your desk. You'd like to discuss something about the data with me (I'm away in California, not at your desk), so I open an IPython client that connects to your kernel, and start getting on my frontend the static versions of all the plots. You have the full windows on your desktop which zoom and pan, but with a simple 'show()' I can get static snapshots of all the figures on my desk, while we both work with and control the same kernel. That could be useful, no? Regards, 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root wrote: > Dude, that just blew my mind! > Glad you like it :) And needless to say, once the dust settles and someone is willing, the obvious thing to do is to put a zeromq-http bridge and make a web browser-based client, so you can use ipython/matplotlib from your android/iphone/netbook/whatever. We've been scrupulously careful not to introduce any python assumptions client-side, so that in principle frontends can be written in any language or toolkit (e.g. html/javascript), the entire system is specified by its messaging protocol: http://ipython.scipy.org/doc/nightly/html/development/messaging.html 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root wrote: > Dude, that just blew my mind! > > Awesome idea! By the way, I don't know if it was clear, but this wasn't just an idea, it's already implemented: http://fperez.org/tmp/ip-multiclient.png The two windows are talking to the same kernel, the one at the top issues the plot command, and the one at the bottom then just does 'show()' and it gets the same figure. Notice how they share a global prompt counter, since that number lives kernel-side. They're both on the same computer, but it makes no difference if they run on different hosts. This isn't anywhere near production-quality yet, but it does work. We're busy finishing the core pieces so we can spend some time polishing it for user testing. 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 [email protected] 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 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 [email protected] 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 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 [email protected] 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 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, s
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 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 [email protected] 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 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 [email protected] 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 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Buglets in svg backend?
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. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx
Hi Eric, On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing wrote: > > I have been doing a little testing with ipython 0.10 versus > ipython-newkernel, both modes, and with mpl svn versus your guisupport. > There are so many possible modes of operation and combinations of > versions and backends that all this will take some time to sort out. > > Can you give me simple examples of what does *not* work correctly when > you use mpl *svn* with ipython-newkernel, in either or both of the > console or gui modes, but *does* work with your guisupport version? Thanks for your testing, Eric. With matplotlib *alone*, I can't find a way to crash/lock/whatever the combo of matplotlib(svn)+ipython-newkernel. The reason, i believe, is that guisupport.py is available in ipython itself, and it goes out of its way to avoid creating a second main qt app, letting matplotlib create it. Since that main app is alive all the time, there's only one app and one event loop and life is good. But if I were to open another library that uses Qt and makes a new main qApp unconditionally, we'd have problems. Brian and Evan have recently just added the guisupport.py patch to Enthought's ETS, so that now it probably will be pretty hard to actually see the problem: if both ipython and ets go out of their way to avoid the nested main app issue, mpl can get away with making one unconditionally and things will probably work OK. But the idea is for all of us (ipython, ets, mpl, etc) to agree on a collaborative protocol with a simple api: check for one special '_in_event_loop' flag in the main toolkit before making one. That will make it easier to have interactive code that uses Wx or Qt from more than one library coexisting in the same process. I'll let Brian fill in with more details when he has some availability, but I think that's the gist of it. 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 [email protected] 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 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] IPython (new) + matplotlib report: happy news
Hi folks, [ sorry for the cross-post, but devs on both lists will care about this] I just went through the exercise of pasting 100 randomly chosen examples from the gallery into the new ipython console with inline graphics. Report: - 98 worked perfectly: the figures I got were identical to those on the website. - 1 had minor visual differences: http://matplotlib.sourceforge.net/examples/pylab_examples/quadmesh_demo.html: in the SVG render, the masked region appears black instead of transparent. - One produced an error: http://matplotlib.sourceforge.net/examples/axes_grid/simple_axisline4.html ... ...: plt.draw() ...: plt.show() ...: Received invalid plot data. But when I save the file and try to load it into firefox, it seems to indeed be bad SVG: XML Parsing Error: mismatched tag. Expected: . Location: file:///home/fperez/ipython/ipython/bad.svg Line Number 287, Column 3: --^ In summary: we can run pretty much any MPL example by straight copy/paste, and the only two glitches I see are in the SVG data itself. Once the other two buglets I reported earlier get fixed up, this will be a very nice way to interact with MPL. 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... Anyway, I think we're starting to be in pretty good shape! 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 [email protected] 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 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 [email protected] 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 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 [email protected] 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 7:08 PM, David Warde-Farley wrote: > > Nice work IPython people! I haven't been following too closely but this looks > exciting. Thanks, David. Hopefully by next week we'll complete our stabilization so that we're willing to foist this on the ipython-dev and mpl-dev denizens. Anyone is welcome to try it out now, but we're moving things around enough that at any given point it may or may not work. We'll move it into trunk once the churn stops. Regards, 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news
Hey, On Tue, Sep 14, 2010 at 8:21 AM, John Hunter 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. I'll play with those ideas, good thoughts. %paste may not be the best location because paste is now a terminal-only magic, since gui clients have 'real' paste. What's a little trickier now is that we really need to think all the time in terms of completely separate kernel and client codes, that only communicate via messages. So a magic can't muck with code in the client, because the magic executes inside the kernel and the client is in a separate process (and possibly in a separate computer). While this is a bit more constraining, it forces us to have a clean separation between different kinds of functionality. We've toyed with the idea of enabling a special syntax for *purely client side* commands, something like :cmd that would never be sent to the kernel, and would be something for the client to process internally. But we'll have to mull this a little longer... One very important point in all of this is that the client *may not be written in Python*. All we have is a messaging protocol, the client could be a web browser or anything else. But in any case, I'll play with ways to expose this that are as easy as possible for the users thanks for the feedback. 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 [email protected] 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 wrote: > On 14 September 2010 11:08, Gökhan Sever 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 [email protected] 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 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:
a
... lots more...
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
[email protected]
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:57 PM, Benjamin Root wrote: > > Why not have an examples module that contains function calls to each > example? On the website, we can show the source code, but also say that one > could just do: > import matplotlib.examples as ex ex.bars3d_demo() The idea is to have the *actual code* pasted in your terminal, because now we can easily edit complex multi-line examples directly in ipython. So it's not just a matter of seeing the figure results, but mostly of having the actual source in your input buffer to play with. 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 [email protected] 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 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 [email protected] 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 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 [email protected] 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 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
