matplotlib-devel Mailing List for matplotlib (Page 3)

On Mon, Jun 8, 2009 at 2:25 PM, Jouni K. Seppänen <jk...@ik...> wrote:
> (Answering only on the devel list.)
>
> Gökhan SEVER <gok...@gm...> writes:
>
> > How do you add you automatically check-out new added files from
> matplotlib
> > trunk? Is there a specific svn command for this?
>
> Yes: svn update
>
> > $ python setupegg.py develop
>
> That works with matplotlib as well. When you run svn update, if the
> output shows that only Python files have been updated, you are all set
> up. If C files have changed, you need to run the setupegg develop
> command again to compile them.
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
I am glad to see that setupegg.py develop works for matplotlib, too. (I
tested and worked well in my first try :) Documentation building always take
longer time.
One more question: After svn co completes checking out the main trunk it
says:
Checked out revision 7203.
However when I do:
In [1]: matplotlib.__revision__
Out[1]: '$Revision: 6887 $'
Which one is correct?
I am not going to ask much about git since it's very experimental stage :)
Thanks for the explanations...
Gökhan

(Answering only on the devel list.)
Gökhan SEVER <gok...@gm...> writes:
> How do you add you automatically check-out new added files from matplotlib
> trunk? Is there a specific svn command for this?
Yes: svn update
> $ python setupegg.py develop
That works with matplotlib as well. When you run svn update, if the
output shows that only Python files have been updated, you are all set
up. If C files have changed, you need to run the setupegg develop
command again to compile them.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On Mon, Jun 8, 2009 at 2:16 PM, John Hunter <jd...@gm...> wrote:
> On Mon, Jun 8, 2009 at 2:14 PM, Gökhan SEVER<gok...@gm...> wrote:
> > Hello,
> >
> > How do you add you automatically check-out new added files from
> matplotlib
> > trunk? Is there a specific svn command for this?
>
>
> Check out svn as indicated here::
>
>
> http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-svn
>
> Once you have a checkout, you can get updates with ::
>
> > svn up
>
> JDH
>
I need to issue a "python setup.py install" after each svn up, right?

Hello,
How do you add you automatically check-out new added files from matplotlib
trunk? Is there a specific svn command for this?
Another question: For example IPython has uses bzr and when I issue bzr
branch lp:ipython command I grab the latest development branch. I do a
development installation quoting from IPython documentation:
"Some users want to be able to follow the development branch as it changes.
If you have setuptools installed, this is easy. Simply replace the last step
by:
$ python setupegg.py develop
and one more step:
This creates links in the right places and installs the command line script
to the appropriate places. Then, if you want to update your IPython at any
time, just do:
$ bzr pull
No duplicated folders and bzr pulls the changes for me.
Could this be possible with matplotlib's VCS system?
Thank you
Gökhan

On Mon, Jun 8, 2009 at 2:29 AM, Jouni K. Seppänen<jk...@ik...> 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

On Mon, Jun 8, 2009 at 5:58 AM, John Hunter<jd...@gm...> 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

On Mon, Jun 8, 2009 at 11:33 AM, Reinier Heeres<re...@he...> wrote:
> Hi John,
>
> On Mon, Jun 8, 2009 at 2:58 PM, John Hunter<jd...@gm...> wrote:
>> On Sun, Jun 7, 2009 at 6:27 PM, Reinier Heeres<re...@he...> wrote:
>>> Hi all,
>>>
>>> I just updated mplot3d with some refactoring, more examples and the
>>> start of documentation. Also semi-3D text is available again.
>>
>> Great -- I made a minor change to special case atan2 with inputs 0,0,
>> which raises an error on my solaris box. I took a look at the
>> documentation commit -- I see the reference
>>
>> See :ref:`toolkit_mplot3d-index` for more documentation and examples.
>>
>> in docs/users/toolkits.rst, but there is nothing in doc/mpl_toolkits.
>> Did you forget to svn add the file?
>
> Oops, they are there now.
The exclude-members tag is causing problems for my build
(.Sphinx-0.6dev_20090302-py2.5.egg) I don't know if the usage is too
new for my sphinx version but this line
./mpl_toolkits/mplot3d/api.rst: :exclude-members: contour3D,
contourf3D, plot3D, scatter3D
is causing the following error listed below. For now I am just
removing the exclude-members line.
 http://matplotlib.sourceforge.net/mpl_toolkits/mplot3d/index.html#toolkit-mplot3d-index
w/ the exclude-members tag I am getting::
Traceback (most recent call last):
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/cmdline.py",
line 172, in main
 app.build(all_files, filenames)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/application.py",
line 129, in build
 self.builder.build_update()
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/builders/__init__.py",
line 238, in build_update
 'out of date' % len(to_build))
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/builders/__init__.py",
line 259, in build
 purple):
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/builders/__init__.py",
line 114, in status_iterator
 for item in iterable:
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/environment.py",
line 510, in update
 self.read_doc(docname, app=app)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/environment.py",
line 599, in read_doc
 pub.publish()
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/core.py",
line 203, in publish
 self.settings)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/readers/__init__.py",
line 69, in read
 self.parse()
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/readers/__init__.py",
line 75, in parse
 self.parser.parse(self.input, document)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/__init__.py",
line 157, in parse
 self.statemachine.run(inputlines, document, inliner=self.inliner)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 170, in run
 input_source=document['source'])
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 232, in run
 context, state, transitions)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 420, in check_line
 return method(match, context, next_state)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 2888, in text
 self.section(title.lstrip(), source, style, lineno + 1, messages)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 308, in section
 self.new_subsection(title, lineno, messages)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 376, in new_subsection
 node=section_node, match_titles=1)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 266, in nested_parse
 node=node, match_titles=match_titles)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 195, in run
 results = StateMachineWS.run(self, input_lines, input_offset)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 232, in run
 context, state, transitions)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 420, in check_line
 return method(match, context, next_state)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 2663, in underline
 self.section(title, source, style, lineno - 1, messages)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 308, in section
 self.new_subsection(title, lineno, messages)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 376, in new_subsection
 node=section_node, match_titles=1)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 266, in nested_parse
 node=node, match_titles=match_titles)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 195, in run
 results = StateMachineWS.run(self, input_lines, input_offset)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 232, in run
 context, state, transitions)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/statemachine.py",
line 420, in check_line
 return method(match, context, next_state)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 2243, in explicit_markup
 nodelist, blank_finish = self.explicit_construct(match)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 2255, in explicit_construct
 return method(self, expmatch)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 1998, in directive
 directive_class, match, type_name, option_presets)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/parsers/rst/states.py",
line 2047, in run_directive
 result = directive_instance.run()
 File "/home/jdhunter/dev/lib/python2.5/site-packages/Sphinx-0.6dev_20090302-py2.5.egg/sphinx/ext/autodoc.py",
line 1047, in run
 self.options.items(), doc_class.option_spec))
 File "/home/jdhunter/dev/lib/python2.5/site-packages/docutils/utils.py",
line 306, in assemble_option_dict
 convertor = options_spec[name] # raises KeyError if unknown
KeyError: 'exclude-members'
> /home/jdhunter/dev/lib/python2.5/site-packages/docutils/utils.py(306)assemble_option_dict()
-> convertor = options_spec[name] # raises KeyError if unknown

Hi John,
On Mon, Jun 8, 2009 at 2:58 PM, John Hunter<jd...@gm...> wrote:
> On Sun, Jun 7, 2009 at 6:27 PM, Reinier Heeres<re...@he...> wrote:
>> Hi all,
>>
>> I just updated mplot3d with some refactoring, more examples and the
>> start of documentation. Also semi-3D text is available again.
>
> Great -- I made a minor change to special case atan2 with inputs 0,0,
> which raises an error on my solaris box. I took a look at the
> documentation commit -- I see the reference
>
> See :ref:`toolkit_mplot3d-index` for more documentation and examples.
>
> in docs/users/toolkits.rst, but there is nothing in doc/mpl_toolkits.
> Did you forget to svn add the file?
Oops, they are there now.
> One other feature request that I think you could add w/o too much
> difficulty is colormapping on the surface plots (eg inherit from
> cm.ScalaraMappable. I did this in a local branch of the old axes3d
> code which I might be able to dig up, but I think it should be pretty
> forward to implement de novo.
I've been thinking about this too. It would be great if you could dig
this up as an example! (I haven't looked at ScalarMappable yet, so it
might indeed be relatively straightforward). I was also thinking about
a sort-of pcolor3d or voxel generation although I'm not sure how to
best implement it. But maybe allowing the surface plots to be colored
is enough.
Regards,
Reinier
>
>> 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.
>
> JDH
>
--
Reinier Heeres
Bleijenburg 64
2511 VD Den Haag
The Netherlands
Tel: +31 6 10852639

On Sun, Jun 7, 2009 at 8:05 PM, Eric Firing<ef...@ha...> wrote:
> Jouni K. Seppänen wrote:
>> The current pyplot wrappers all have an argspec of (*args, **kwargs),
>> which means that any interactive tools that show the possible arguments
>> will not be able to show anything very useful for the wrapped functions.
>> Also, since the docstrings are generated dynamically, any static code
>> analysis tools will not see them.
>
> Jouni,
>
> This looks like a very good idea.
I agree -- the presence of *args and **kwargs in the pyplot
docstrings, the interface most people use, is a major wart. I suggest
committing this to HEAD when you are ready to go. Once that is done
we can remove all the redundant pyplot docstrings from axes.py which
will make Eric very happy.
JDH

On Sun, Jun 7, 2009 at 6:27 PM, Reinier Heeres<re...@he...> wrote:
> Hi all,
>
> I just updated mplot3d with some refactoring, more examples and the
> start of documentation. Also semi-3D text is available again.
Great -- I made a minor change to special case atan2 with inputs 0,0,
which raises an error on my solaris box. I took a look at the
documentation commit -- I see the reference
 See :ref:`toolkit_mplot3d-index` for more documentation and examples.
in docs/users/toolkits.rst, but there is nothing in doc/mpl_toolkits.
Did you forget to svn add the file?
One other feature request that I think you could add w/o too much
difficulty is colormapping on the surface plots (eg inherit from
cm.ScalaraMappable. I did this in a local branch of the old axes3d
code which I might be able to dig up, but I think it should be pretty
forward to implement de novo.
> 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.
JDH

Eric Firing <ef...@ha...> writes:
>> The current pyplot wrappers all have an argspec of (*args, **kwargs),
>> which means that any interactive tools that show the possible arguments
>
> It is in some ways a separate change, but it would be nice if the 
> boilerplate were generated at build time, and/or generated as a separate 
> file from which pyplot.py would import everything. I don't like having 
> a single file that is partly hand-edited and partly machine-generated.
You're right, it would be better to generate it at build time. One
problem with this is that my version of boilerplate.py needs to import
axes.py to access the methods of the Axes class, and axes.py in turn
imports other things, making it impossible to run boilerplate.py without
having compiled the compilable modules. That's why I munge sys.path
before importing axes -- and there are lots of things that could go
wrong with that.
I guess a more correct approach would be to use something like the
parser module to read axes.py without executing the code.
>> Since we only support Python >=2.4 now, we could get rid of the whole
>> boilerplate code system and replace it with something more dynamic as
>> envisioned in
>> 
>> http://groups.google.com/group/comp.lang.python/browse_frm/thread/dcd63ec13096a0f6/1b14640f3a4ad3dc?#1b14640f3a4ad3dc
>> 
>> but I don't see any way of keeping the wrapped function's argspec
>> without doing something much like what we do now.
>> 
>
> 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!
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Andrew Straw <str...@as...> writes:
> Anyhow, now that I've pushed up a more recent master, assuming you want
> to apply your work onto that, you could either rebase your commits onto
> the master -- thus ignoring the true historical state you developed them
> against -- or merge the master branch -- causing the history to be more
> complicated, as it's no longer linear.
I opted for the merge, since all the git documentation I have read seems
to frown on rebasing anything that has been published. Besides, dealing
with non-linear history in this relatively simple case is probably good
practice for us git newbies.
By the way, would it have been possible for me to use git-svn on my own
repository, update it from the official svn and then have everything
work out right once you updated your repository? I suppose that should
be possible if git-svn guarantees that every one of its users gets the
exact same trees for every svn commit, but perhaps even then it would
not show up as a proper merge in git.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Andrew Straw wrote:
> Jouni K. Seppänen wrote:
> 
>> I coded up what I think is an improvement, but since it has a lot of
>> potential to break something and release time is near, I didn't commit
>> my changes into svn. I tried playing around with git, to see if it is
>> useful for communicating patches. 
> 
> I think it's useful.
> 
>> Any git gurus out there: is this the "right" way for using git to discuss
>> patches, or am I missing something?
> 
> Yes, as much as there is one... My git mirror isn't automatically synced
> so often falls behind a bit - as it was when you did this (I have just
> now updated, though). Furthermore, I recently discovered that I
> collapsed a bunch of svn commits into a single big git commit (the git
> repo's idea of svn r7100 contains a lot more than the real svn r7100).
> So, the branch currently labeled "master" in my github repository should
> not become the cannonical git repository. (Of course, it will be very
> easy to label the correct branch -- when it gets made -- "master".)
> 
> Anyhow, now that I've pushed up a more recent master, assuming you want
> to apply your work onto that, you could either rebase your commits onto
> the master -- thus ignoring the true historical state you developed them
> against -- or merge the master branch -- causing the history to be more
> complicated, as it's no longer linear.
> 
> And now that we're talking about this, Eric, as the only MPL dev that I
> know who prefers Hg over git, have you seen
> http://github.com/blog/439-hg-git-mercurial-plugin and would you be
> willing to try it out? I'd be very interested to know if it could make a
> git central repo work seamlessly for both Hg and git clients.
I had not seen it until you mentioned it above. Now I downloaded it, 
enabled it, and tried to make a clone of Jouni's repo. Hit an 
exception. It's probably because I am using a newer version of hg than 
what hg-git is being developed with. This will take a little time to 
sort out.
I'm moderately optimistic about hg-git despite hitting that pothole; I 
suspect hg-git interoperability is much easier than interoperability of 
either with svn. For the latter, I have been doing some testing of 
hgsubversion, but I am quite leery of trying to work routinely with a 
central svn and local dvcs.
In any case, I can work with git if I have to (although after some 
experience with git I still think that hg is *much* easier to learn and 
use casually), and I really would like to see numpy and mpl both move 
completely to either git or hg. And it doesn't even have to be the same 
one for both.
Eric

>> And now that we're talking about this, Eric, as the only MPL dev that I
>> know who prefers Hg over git, have you seen
>> http://github.com/blog/439-hg-git-mercurial-plugin and would you be
>> willing to try it out? I'd be very interested to know if it could make a
>> git central repo work seamlessly for both Hg and git clients.
> 
> I had not seen it until you mentioned it above. Now I downloaded it, 
> enabled it, and tried to make a clone of Jouni's repo. Hit an 
> exception. It's probably because I am using a newer version of hg than 
> what hg-git is being developed with. This will take a little time to 
> sort out.
OK, I was able to clone successfully by switching to the last released 
version of hg. More testing later.
Eric

Eric Firing wrote:
>
>>> And now that we're talking about this, Eric, as the only MPL dev that I
>>> know who prefers Hg over git, have you seen
>>> http://github.com/blog/439-hg-git-mercurial-plugin and would you be
>>> willing to try it out? I'd be very interested to know if it could
>>> make a
>>> git central repo work seamlessly for both Hg and git clients.
>>
>> I had not seen it until you mentioned it above. Now I downloaded it,
>> enabled it, and tried to make a clone of Jouni's repo. Hit an
>> exception. It's probably because I am using a newer version of hg
>> than what hg-git is being developed with. This will take a little
>> time to sort out.
>
> OK, I was able to clone successfully by switching to the last released
> version of hg. More testing later.
Great.
I would suggest not attempting to judge on a crazy git-hg-svn triangle
-- git/svn itself is enough pain I wouldn't recommend it to anyone.
Hopefully git/hg is better. (In other words, if there's a project you're
interested that is exclusively git based, it may be best to play around
with that than rather than using hg to interact with my git mirror of
the MPL svn repo.)
BTW, I have no reason to disagree with you that learning hg is easier
than learning git. I haven't used Hg for anything complicated, but it
was certainly no trouble for me to do basic stuff with. I'm glad to read
about their bookmarks extension, which apparently makes hg able to
branch more like git rather than copying the entire repository.
-Andrew

Jouni K. Seppänen wrote:
> The current pyplot wrappers all have an argspec of (*args, **kwargs),
> which means that any interactive tools that show the possible arguments
> will not be able to show anything very useful for the wrapped functions.
> Also, since the docstrings are generated dynamically, any static code
> analysis tools will not see them.
Jouni,
This looks like a very good idea.
It is in some ways a separate change, but it would be nice if the 
boilerplate were generated at build time, and/or generated as a separate 
file from which pyplot.py would import everything. I don't like having 
a single file that is partly hand-edited and partly machine-generated.
> --
> 
> Since we only support Python >=2.4 now, we could get rid of the whole
> boilerplate code system and replace it with something more dynamic as
> envisioned in
> 
> http://groups.google.com/group/comp.lang.python/browse_frm/thread/dcd63ec13096a0f6/1b14640f3a4ad3dc?#1b14640f3a4ad3dc
> 
> but I don't see any way of keeping the wrapped function's argspec
> without doing something much like what we do now.
> 
Have you looked at the decorator module? 
http://pypi.python.org/pypi/decorator
Eric

Jouni K. Seppänen wrote:
> I coded up what I think is an improvement, but since it has a lot of
> potential to break something and release time is near, I didn't commit
> my changes into svn. I tried playing around with git, to see if it is
> useful for communicating patches. 
I think it's useful.
> Any git gurus out there: is this the "right" way for using git to discuss
> patches, or am I missing something?
Yes, as much as there is one... My git mirror isn't automatically synced
so often falls behind a bit - as it was when you did this (I have just
now updated, though). Furthermore, I recently discovered that I
collapsed a bunch of svn commits into a single big git commit (the git
repo's idea of svn r7100 contains a lot more than the real svn r7100).
So, the branch currently labeled "master" in my github repository should
not become the cannonical git repository. (Of course, it will be very
easy to label the correct branch -- when it gets made -- "master".)
Anyhow, now that I've pushed up a more recent master, assuming you want
to apply your work onto that, you could either rebase your commits onto
the master -- thus ignoring the true historical state you developed them
against -- or merge the master branch -- causing the history to be more
complicated, as it's no longer linear.
And now that we're talking about this, Eric, as the only MPL dev that I
know who prefers Hg over git, have you seen
http://github.com/blog/439-hg-git-mercurial-plugin and would you be
willing to try it out? I'd be very interested to know if it could make a
git central repo work seamlessly for both Hg and git clients.

Hi all,
I just updated mplot3d with some refactoring, more examples and the
start of documentation. Also semi-3D text is available again.
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.
Regards,
-- 
Reinier Heeres
Bleijenburg 64
2511 VD Den Haag
The Netherlands
Tel: +31 6 10852639

The current pyplot wrappers all have an argspec of (*args, **kwargs),
which means that any interactive tools that show the possible arguments
will not be able to show anything very useful for the wrapped functions.
Also, since the docstrings are generated dynamically, any static code
analysis tools will not see them.
I coded up what I think is an improvement, but since it has a lot of
potential to break something and release time is near, I didn't commit
my changes into svn. I tried playing around with git, to see if it is
useful for communicating patches. You can see the files here:
http://github.com/jkseppan/matplotlib/tree/boilerplate
or view the commits at:
http://github.com/jkseppan/matplotlib/commit/a94764aa78da1716ee21b0108c6a771af02a0ffc
http://github.com/jkseppan/matplotlib/commit/fc4a62b810cd34f73156c6bccc77a1cb9f0049dc
(the first one is a small bugfix, the second one is the big change). Git
users can clone git://github.com/jkseppan/matplotlib.git which is a fork
of Andrew Straw's repository; the boilerplate branch has the changes.
Any git gurus out there: is this the "right" way for using git to discuss
patches, or am I missing something?
 --
Since we only support Python >=2.4 now, we could get rid of the whole
boilerplate code system and replace it with something more dynamic as
envisioned in
http://groups.google.com/group/comp.lang.python/browse_frm/thread/dcd63ec13096a0f6/1b14640f3a4ad3dc?#1b14640f3a4ad3dc
but I don't see any way of keeping the wrapped function's argspec
without doing something much like what we do now.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hey John,
On Sat, Jun 6, 2009 at 4:40 AM, John Hunter<jd...@gm...> 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

Gökhan SEVER a écrit :
> Hi,
>
> formlayout will definitely a very nice addition to matplotlib Qt4 
> backended plotting windows. It reminds me Traits UI's 
> configure.traits() method.
>
> PyQt4 programming is still a mystery to me, and have chosen to learn 
> Traits instead.
>
> I am also curious to know what happened to pydee - IPython integration 
> plans?
I changed its priority but the IPython integration in pydee is still 
planned for this summer.
To be honest, I didn't have the time to work on this for a long time now 
(actually since the IPython PyQt4 frontend demo I've coded in April).
In the meantime, I concentrated on cleaning the code, fixing a lot of 
bugs, improving performances (Workspace mainly) and adding new features: 
console in a separate process (the "external console": running scripts, 
debugging, interacting, opening a Python interpreter... with 
code-completion, calltips, ...), files/directories explorer, class 
browser, fast code analysis (pyflakes), find in files (next release)...
>
> I should also mention, I have started a weekly Python meeting in our 
> department. I highly recommended to Windows users to start with 
> Python(X,Y).
Of course, I agree that is certainly the best thing to do ;-)
Pierre
> I will see the results next week :)
>
> Gökhan
>
> Hi all,
>
> Dave, you are absolutely right.
>
> Last week-end, I found myself surfing on PyQt's website and I told to
> myself: what about re-reading the license? (always a pleasure) And
> surprisingly, I found out that anyone using the GPL version of PyQt
> can release source code under a very permissive license (like MIT or
> BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not
> part of the distributed package (otherwise the whole package has to be
> licensed under GPL) - and with other little restrictions. It was a
> surprise because I've read here and there a lot of things on PyQt
> license and the general idea was "if you write PyQt code without the
> commercial license, your code *must* be licensed under GPL" - I can
> tell now that it's not true (to be absolutely certain about it, I even
> asked to Phil Thompson to confirm this, and he did).
>
> So, I switched all the code I was referring to in my original e-mail
> to MIT license.
> I guess now it could be integrated to matplotlib Qt4 backend?
>
> formlayout (generate option dialogs):
> http://code.google.com/p/formlayout/
>
> pydee (IDE which integrates matplotlib and the option dialog):
> http://code.google.com/p/pydee/
> Meanwhile, thanks to the brand new Google-code Mercurial support, you
> may browse the source code if you like:
> http://code.google.com/p/pydee/source/browse/pydeelib/widgets/figureoptions.py
>
> Cheers,
> Pierre
>

Hi,
formlayout will definitely a very nice addition to matplotlib Qt4 backended
plotting windows. It reminds me Traits UI's configure.traits() method.
PyQt4 programming is still a mystery to me, and have chosen to learn Traits
instead.
I am also curious to know what happened to pydee - IPython integration
plans?
I should also mention, I have started a weekly Python meeting in our
department. I highly recommended to Windows users to start with Python(X,Y).
I will see the results next week :)
Gökhan
Hi all,
>
> Dave, you are absolutely right.
>
> Last week-end, I found myself surfing on PyQt's website and I told to
> myself: what about re-reading the license? (always a pleasure) And
> surprisingly, I found out that anyone using the GPL version of PyQt
> can release source code under a very permissive license (like MIT or
> BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not
> part of the distributed package (otherwise the whole package has to be
> licensed under GPL) - and with other little restrictions. It was a
> surprise because I've read here and there a lot of things on PyQt
> license and the general idea was "if you write PyQt code without the
> commercial license, your code *must* be licensed under GPL" - I can
> tell now that it's not true (to be absolutely certain about it, I even
> asked to Phil Thompson to confirm this, and he did).
>
> So, I switched all the code I was referring to in my original e-mail
> to MIT license.
> I guess now it could be integrated to matplotlib Qt4 backend?
>
> formlayout (generate option dialogs):
> http://code.google.com/p/formlayout/
>
> pydee (IDE which integrates matplotlib and the option dialog):
> http://code.google.com/p/pydee/
> Meanwhile, thanks to the brand new Google-code Mercurial support, you
> may browse the source code if you like:
>
> http://code.google.com/p/pydee/source/browse/pydeelib/widgets/figureoptions.py
>
> Cheers,
> Pierre
>

2009年4月28日 Dave Peterson <dpe...@en...>:
> Darren Dale wrote:
>
> On Tue, Apr 28, 2009 at 12:19 PM, Pierre Raybaut <co...@py...>
> wrote:
>>
>> 2009年4月28日 John Hunter <jd...@gm...>:
>> >
>> >
>> > On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut <co...@py...>
>> > wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I would like to contribute to matplotlib with this enhancement for the
>> >> PyQt4 backend: the idea is to add a toolbar button to configure figure
>> >> options (axes, curves, ...).
>> >>
>> >> It's based on a tiny module called formlayout to generate PyQt4 form
>> >> dialog automatically.
>> >>
>> >> Some screenshots:
>> >> http://code.google.com/p/formlayout/
>> >>
>> >> So, if you're interested (all the following is GPL2):
>> >>
>> >> *matplotlib patch*
>> >>
>> >> In FigureManagerQT.__init__, added:
>> >> self.canvas.axes = self.canvas.figure.add_subplot(111)
>> >>
>> >> In NavigationToolbar2QT._init_toolbar, added:
>> >> a = self.addAction(self._icon("customize.png"), 'Customize',
>> >> self.edit_parameters)
>> >> a.setToolTip('Edit curves line and axes parameters')
>> >>
>> >> Added the following method in NavigationToolbar2QT:
>> >> def edit_parameters(self):
>> >>  from figureoptions import figure_edit
>> >>  figure_edit(self.canvas, self)
>> >>
>> >> *additionnal modules and data*
>> >>
>> >> formlayout.py (http://code.google.com/p/formlayout/)
>> >> figureoptions.py (http://code.google.com/p/PyQtShell/)
>> >> customize.png (http://code.google.com/p/PyQtShell/)
>> >
>> > Hi Pierre -- this looks very nice (the last link is broken though , I
>> > get a
>> > 404 error). We would be happy to include this in matplotlib or as a
>>
>> Here is the last link:
>> http://code.google.com/p/pyqtshell/
>>
>> > toolkit. To contribute it to to mpl, the license needs to be
>> > matplotlib
>> > compatible
>> > (http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses) but
>> > we
>> > have more licensing flexibility in a toolkit, though we prefer to keep
>> > everything BSD compatible where possible.  And of course you would need
>> > to
>> > agree to maintain it :-) but I think many users would appreciate a GUI
>> > plot
>> > configuration dialog.
>>
>> I was not aware of this license restriction in matplotlib... I fully
>> understand the motivation, of course, but still: I wrote all this on
>> my free time which means no PyQt4 commercial license, so it can't be
>> anything but GPL. Sorry...
>
> I think you have overlooked a subtlety of PyQt4's license. The author of
> PyQt4 wrote on the enthought-dev mailing list:
>
> "PyQt is GPL but has exceptions that allow it to be used with BSD code -
> hence it's Ok for TraitsBackendQt to be BSD.
>
> However, the exception imposes additional conditions which, to all intents
> and purposes, infects the code with the GPL. To be fair to people that
> should be made clear in any text.
>
> It's still a good idea for TraitsBackendQt to use a BSD license because it
> allows commercial (ie. non-GPL) users to use it without problems."
>
> Darren
>
> I think it might be worth contacting the PyQt folks (Phil Thompson) about
> this. I think there might be some differences here because Phil was the
> author of TraitsBackendQt and thus his efforts didn't quite fall under the
> "develop under a free license, your results needs to be GPL" clause Qt/PyQt
> have in their licensing.
>
> -- Dave
>
>
Hi all,
Dave, you are absolutely right.
Last week-end, I found myself surfing on PyQt's website and I told to
myself: what about re-reading the license? (always a pleasure) And
surprisingly, I found out that anyone using the GPL version of PyQt
can release source code under a very permissive license (like MIT or
BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not
part of the distributed package (otherwise the whole package has to be
licensed under GPL) - and with other little restrictions. It was a
surprise because I've read here and there a lot of things on PyQt
license and the general idea was "if you write PyQt code without the
commercial license, your code *must* be licensed under GPL" - I can
tell now that it's not true (to be absolutely certain about it, I even
asked to Phil Thompson to confirm this, and he did).
So, I switched all the code I was referring to in my original e-mail
to MIT license.
I guess now it could be integrated to matplotlib Qt4 backend?
formlayout (generate option dialogs):
http://code.google.com/p/formlayout/
pydee (IDE which integrates matplotlib and the option dialog):
http://code.google.com/p/pydee/
Meanwhile, thanks to the brand new Google-code Mercurial support, you
may browse the source code if you like:
http://code.google.com/p/pydee/source/browse/pydeelib/widgets/figureoptions.py
Cheers,
Pierre

On Fri, Jun 5, 2009 at 9:56 PM, Fernando Perez<fpe...@gm...> wrote:
> 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).
Hey Fernando -- thanks for the report and test case.
I committed a change to svn which fixes this -- I'd like one of the
color gurus (Eric?) to take a look at this because the color handling
code is fairly complex as it handles a lot of different cases. The
problem here was that the ColorConverter.to_rgba_array was applying
the alpha even though the input array was rgba already. I special
case this and do not convert when the input is already an Nx4 array.
Are there any cases I am missing? See the inline comment below:
 def to_rgba_array(self, c, alpha=None):
 """
 Returns a numpy array of *RGBA* tuples.
 Accepts a single mpl color spec or a sequence of specs.
 Special case to handle "no color": if *c* is "none" (case-insensitive),
 then an empty array will be returned. Same for an empty list.
 """
 try:
 if c.lower() == 'none':
 return np.zeros((0,4), dtype=np.float_)
 except AttributeError:
 pass
 if len(c) == 0:
 return np.zeros((0,4), dtype=np.float_)
 try:
 result = np.array([self.to_rgba(c, alpha)], dtype=np.float_)
 except ValueError:
 if isinstance(c, np.ndarray):
 if c.ndim != 2 and c.dtype.kind not in 'SU':
 raise ValueError("Color array must be two-dimensional")
 if len(c.shape)==2 and c.shape[-1]==4:
 # looks like rgba already, nothing to be done; do
 # we want to apply alpha here if
 # (c[:,3]==1).all() ?
 return c
 result = np.zeros((len(c), 4))
 for i, cc in enumerate(c):
 result[i] = self.to_rgba(cc, alpha) # change in place
 return np.asarray(result, np.float_)
JDH

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()