matplotlib-devel Mailing List for matplotlib (Page 5)

On Tue, Jan 08, 2008 at 04:49:00PM -0500, Michael Droettboom wrote:
> I don't think "UR DOIN IT WRONG" is an entirely correct assessment, 
> however. Much of this change can be considered refactoring wrt to the 
> high-level public API. 
Refactoring is often defined (in test driven development) as reworking
the codebase given a complete set of tests that pass at the beginning,
and should pass at the end.
My 2 cents,
Gaël

On Jan 8, 2008 1:49 PM, Michael Droettboom <md...@st...> wrote:
> Thank you for enlightening us. This overloaded and contentious word
> will be replaced.
BTW Michael, ready to go when you are
JDH

Thank you for enlightening us. This overloaded and contentious word 
will be replaced.
I don't think "UR DOIN IT WRONG" is an entirely correct assessment, 
however. Much of this change can be considered refactoring wrt to the 
high-level public API. For instance, I believe basemap only had to 
change a handful of lines of code to work with the transforms changes. 
It's "Refactoring with some exceptional edge cases", perhaps? At the 
lower levels, where matplotlib developers are concerned, however, there 
may be some necessary changes, and that's what the API_CHANGES and other 
warnings are for. And in fact, the Wikipedia entry you point to makes 
references to lower-level interfaces being changed as the result of 
refactoring.
Anyway,
Mike
Tom Holroyd wrote:
> UR DOIN IT WRONG
> 
> http://en.wikipedia.org/wiki/Refactoring
> 
> On Tue, 2008年01月08日 at 10:48 -0800, John Hunter wrote:
> 
>> To check out the trunk with the latest transforms refactoring:
> 
> The word refactoring applies to cases of code cleanup and so on.
> Refactoring implies functional equivalence. 
> 
> Dr. Tom
> --
> There is in the world much filth: so much is true! But the world itself
> is not therefore a filthy monster! Thus spoke Zarathustra.
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

UR DOIN IT WRONG
http://en.wikipedia.org/wiki/Refactoring
On Tue, 2008年01月08日 at 10:48 -0800, John Hunter wrote:
> To check out the trunk with the latest transforms refactoring:
The word refactoring applies to cases of code cleanup and so on.
Refactoring implies functional equivalence. 
Dr. Tom
--
There is in the world much filth: so much is true! But the world itself
is not therefore a filthy monster! Thus spoke Zarathustra.

On 2008年1月07日 19:54:38 -1000
Eric Firing <ef...@ha...> wrote:
> Andrew Straw wrote:
> > Something I haven't seen addressed on the numpy list (or here) is
> > using hg or bzr to mirror an svn repository. What would be the
> > added advantage to the project of using a DVCS if all the
> > DVCS-ophiles would simply sync the svn tree?
> 
> There has been numpy discussion of starting with a read-only mirror.
> My sense is that doing two-way synchronization may be possible using 
> tailor, but it doesn't sound very practical. Without two-way 
> synchronization, getting changes from the user's DVCS committed back
> to svn would be a clumsy process.
I'm all for the DVCS concept. I have recently started using git for my
own work, including reading the matplotlib repository. git includes
built-in tools to talk to svn and cvs repositories. In fact, the reason
I chose git over the alternatives (hg, bzr, etc.) is the way it allows
me to use DVCS for my own work (and, occasionally, the work of my close
collaborators) without requiring a change to an entire project's
infrastructure. Using git in this way does not allow one to take
advantage of all of the potential DVCS promises, but it goes a long way
in the right direction.
It's something to consider.
Disclaimers:
(a) I am not an active matplotlib developer.
(b) I really don't want to start a git vs. hg vs. bzr
discussion/flamewar.
--Jim Amundson

On Jan 8, 2008 8:11 AM, Michael Droettboom <md...@st...> wrote:
> Also -- we probably want a news item to say something like this:
I just added MIGRATION.txt to the trunk -- after you do the merge, we
can post this document to provide the migration instructions. I've
tried to add all your text with minor reorganization and added a
general introduction. Feel free to edit and add to this document as
you see fit, and after you do the merge and new branches, I'll post it
and update a news flash on the web site.
JDH
Migrating to the new matplotlib codebase
========================================
Michael Droettboom has spent the last several month working on the
"transforms branch" of matplotlib, in which he rewrote from the ground
up the transformation infrastructure in matplotlib, whih many found
unintuitive and hard to extend. In addition to a cleaner code base,
the refactoring allows you to define your own trasformations and
projections (eg map projections) within matplotlib. He has merged his
work into the HEAD of the svn trunk, and this will be the basis for
future matplotlib releases.
If you are a svn user, we encourage you to continue using the trunk as
before, but with the understanding that you are now truly on the
bleeding edge. Michael has made sure all the examples still pass with
the new code base, so for the vast majority of you, I except to see
few problems. But we need to get as many people as possible using the
new code base so we can find and fix the remaining problems. We have
take the svn cde used in the last stable release in the 0.91 series,
and made it a maintenance branch so we can still fix bugs and support
people who are not ready to migrate to the new transformation
infrastructure but nonetheless need acccess to svn bug fixes.
The experimental transforms refactoring changes have been merged into
SVN trunk. While this version is passing all examples and unit tests,
there may be changes that subtly break things that used to work, raise
nasty exceptions or kill innocent puppies. To help move matplotlib
forward, we encourage all users who are comfortable with the bleeding
edge to use the trunk with their own plots and report any bugs to the
mailing list.
Using the new code
==================
To check out the trunk with the latest transforms refactoring:
 > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
If you already have a working copy of the trunk, your next "svn up" will
include the latest transforms refactoring.
Using the old svn code
======================
To check out the maintenance branch, in order to commit bugfixes to 0.91.x:
 > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint
 matplotlib_0_91_maint
Any applicable bugfixes on the 0.91.x should be merged into the trunk so
they are fixed there as well.
API CHANGES in the new transformation infrastructure
====================================================
While Michael worked hard to keep the API mostly unchanged while
performing what has been called "open heart surgery on matplotlib",
there have been some changes, as discussed below.
The primary goal of this refactoring was to make it easier to
extend matplotlib to support new kinds of projections. This is
primarily an internal improvement, and the possible user-visible
changes it allows are yet to come.
These changes are detailed in the API_CHANGES document

Also -- we probably want a news item to say something like this:
====
The experimental transforms refactoring changes have been merged into 
SVN trunk. While this version is passing all examples and unit tests, 
there may be changes that subtly break things that used to work, raise 
nasty exceptions or kill innocent puppies. To help move matplotlib 
forward, we encourage all users who are comfortable with the bleeding 
edge to use the trunk with their own plots and report any bugs to the 
mailing list. If the trunk is not working for you and you just need 
something that works, download the 0.91.2 release, or check out the 
0.91.x maintenance branch from svn:
 svn co
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint 
matplotlib_0_91_maint
====
Mike
John Hunter wrote:
> Now that the 0.91.2 release is out, I am inclined to merge Michael's
> transforms branch into the trunk. Since many people rely on svn, we
> probably need to advertise this move broadly, with a news item on the
> web page and announcements on the mailing lists, with instructions on
> how to checkout the 0.91 maintenance branch (which does not exist but
> would be created as the maintenance branch). There was some
> suggestion earlier that we leave Michael's work on a branch, but I
> think we need to get it on the trunk so developers and svn users will
> get it by default which will help us move more rapidly in shaking out
> the remaining bugs and problems.
> 
> Michael, since you know more about this than anyone, you should
> probably spearhead the svn reorganization and let people know when the
> changes become effective with some advance notice. I will update the
> website with pointers to the relevant docs (your API_CHANGES and
> Changelog and the relevant svn commands and anything else you think we
> will need).
> 
> If this seems like a reasonable plan, perhaps we should shoot for
> doing this in a day or two. If any of you think this is the wrong
> approach, let us know.
> 
> JDH
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> Michael, since you know more about this than anyone, you should
> probably spearhead the svn reorganization and let people know when the
> changes become effective with some advance notice. I will update the
> website with pointers to the relevant docs (your API_CHANGES and
> Changelog and the relevant svn commands and anything else you think we
> will need).
Here's a summary of my plan:
1) Create a tag in tags/v0_91_2 of the exact revision Charlie released 
as 0.91.2. This is useful to diff against.
2) Create a branch in branches/v0_91_maint that will be used exclusively 
for bugfixes to 0.91.x, and be the source of any future 0.91.x releases.
3) Merge branches/transforms into trunk/matplotlib
Putting the most recent API_CHANGES and CHANGELOG from the transforms 
branch on the web is a good idea -- however, it should be clear that it 
applies only to SVN versions, and not the 0.91.2 release. (It's 
reasonably self-evident to me, but maybe not to everyone).
As for svn instructions (applicable after the above changes):
====
To check out the trunk with the latest transforms refactoring:
 svn co 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib 
matplotlib
If you already have a working copy of the trunk, your next "svn up" will 
include the latest transforms refactoring.
To check out the maintenance branch, in order to commit bugfixes to 0.91.x:
 svn co 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint 
matplotlib_0_91_maint
Any applicable bugfixes on the 0.91.x should be merged into the trunk so 
they are fixed there as well. I will provide further instructions about 
this (using svnmerge.py) once I have everything in place.
====
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Jan 7, 2008 2:37 PM, Eric Firing <ef...@ha...> wrote:
> 
>> (At the moment I can't compile the branch--I just sent Mike a message
>> about that off the list, with voluminous output.)
>>
>> It seems like what is needed is not exactly a merge operation but simply
>> a renaming of the trunk and the branch. Maybe some doc files need to be
>> merged, but that is about it. Correct?
> 
> Sorry if I used sloppy terminology, all I mean is that Michael's stuff
> will become the HEAD of the svn trunk, and the current HEAD of the
> trunk will become a branch. No merge will be necessary since Michael
> has been merging all changes in the HEAD into his branch on a ongoing
> basis. I don't actually know how one does this move in svn, but I
> have faith that Michael does.
I've been using svnmerge.py
http://www.orcaware.com/svn/wiki/Svnmerge.py#Quick_Usage_Overview
Essentially, it eliminates the need to remember the last points at which 
one branch was merged into another (which IMHO is the awful thing about 
svn's built-in merge). I understand this functionality will be brought 
into SVN proper in 1.5.
It also has a facility to merge the branch back into the trunk once 
we're ready. (Whether it's technically a merge or a copy, I don't 
really know -- that's where the line gets blurry. The point is, it 
should be straightforward.)
>> All this brings to mind the discussion taking place over the last week
>> on the numpy list regarding switching from svn to bzr or hg.
>> http://thread.gmane.org/gmane.comp.python.numeric.general/18130
>> (I have been using hg locally for a couple years, and I like it.) The
>> motivation is the greater ease of branching and merging with distributed
>> VCS systems in comparison to SVN. In the numpy list discussion, it
>> sounds like all participants except Travis favor making the switch.
> 
> I'm personally -1 on this. I prefer to keep things as simple as
> possible and do not see the need for a lot of branching, though there
> is clearly a need for some. svn is the standard version control
> system and has the best install base (now on OS X and all linux
> systems), making it easiest for users to get checkouts. If numpy,
> ipython and scipy all decide to move, I would probably be inclined to
> go along with it for consistency between these packages, but I
> wouldn't be leading the charge. I have never felt the need for a
> distributed version control system, personally, though some swear by
> it. It is probably because mpl has always just had a trunk with no
> branches, and I'd like to stick to that as much as possible,
> 
> Michael, how onerous was it for you to do the merges using svn -- this
> seems to be the most significant problem with svn in my reading of
> David's summary.
David Cournapeau seems to have had some non-specific bad experiences 
with svnmerge.py. I agree, it does force you to be explicit (i.e. set 
up the branch correctly from the start), unlike a DVCS where it is 
built-in. But I've had absolutely no problems with it (maybe I'm just 
lucky).
I had hesitated to add to the discussion, since so much has been said 
already over on numpy. However, besides the merge-tracking (that 
svnmerge adequately meets for me) I see one other important advantage to 
DVCS: It's easier to create local and non-official branches (meaning 
created by developers without write access to the "official" 
repository), and track changes that aren't really ready to be shared. I 
worked at a place (that shall remain nameless), that used a centralized 
VCS, but the culture (as mandated by management) was to commit to the 
trunk only very rarely, usually right before an alpha or beta cycle. 
This meant that it was a) hard to keep track of what others were doing, 
b) there was a high likelihood of conflicts with others (not just at the 
source code level, but the logical level), c) all the ad-hoc testing 
that developers do as they write code had to be completely redone after 
this "merge" and long after the developers had forgotten about what they 
had written. I'm a strong believer in "continuous integration" of code. 
 It seems to me that at its worst, a DVCS lightly discourages 
continuous integration because it makes it so easy to go off on 
tangents, and tangents aren't necessarily always a good thing if the end 
result is intended to be truly "one product". Tangents are necessary, 
yes, but their number needs to be somehow limited. This is all a matter 
of process, of course, and neither approach to version control really 
prevents any particular process -- I'd just like to make the argument 
that the "lots of little branches" process that DVCS make so easy, is 
not necessarily always appropriate.
Lastly, it seems to me that there are upteen ways to emulate a DVCS on 
top of a core repository that is still running on SVN. For instance, I 
used SVK (a DVCS specifically designed to be used in conjunction with 
SVN) in the above situation to maintain my sanity and keep my own local 
revision history. It also helps with laptop situations. Nothing is 
stopping anyone from doing that today, and we don't even need to know 
about it. I'll admit it's not really the same thing (there's would be 
no single way for someone else to get at my local changes), but it meets 
a lot of the needs with no organizational impact on others.
All this is to say, I'm sort of -0 on this -- I see as many plusses and 
negatives, I guess.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
[...]
> Michael, how onerous was it for you to do the merges using svn -- this
> seems to be the most significant problem with svn in my reading of
> David's summary.
Here is a new thread related to merging, and the difference between svn 
and a DVCS:
http://www.mail-archive.com/num...@sc.../msg05938.html
Eric

Andrew Straw wrote:
> Something I haven't seen addressed on the numpy list (or here) is using 
> hg or bzr to mirror an svn repository. What would be the added advantage 
> to the project of using a DVCS if all the DVCS-ophiles would simply sync 
> the svn tree?
There has been numpy discussion of starting with a read-only mirror. My 
sense is that doing two-way synchronization may be possible using 
tailor, but it doesn't sound very practical. Without two-way 
synchronization, getting changes from the user's DVCS committed back to 
svn would be a clumsy process.
It also seems that even one-way synchronization from a remote svn 
repository can be difficult. A little googling suggests that even 
making a read-only *svn* mirror of an svn repository is not necessarily 
as easy as one might expect.
Eric

Something I haven't seen addressed on the numpy list (or here) is using 
hg or bzr to mirror an svn repository. What would be the added advantage 
to the project of using a DVCS if all the DVCS-ophiles would simply sync 
the svn tree?
Eric Firing wrote:
> John Hunter wrote:
>> On Jan 7, 2008 2:37 PM, Eric Firing <ef...@ha...> wrote:
> [...]
>>> All this brings to mind the discussion taking place over the last week
>>> on the numpy list regarding switching from svn to bzr or hg.
>>> http://thread.gmane.org/gmane.comp.python.numeric.general/18130
>>> (I have been using hg locally for a couple years, and I like it.) The
>>> motivation is the greater ease of branching and merging with distributed
>>> VCS systems in comparison to SVN. In the numpy list discussion, it
>>> sounds like all participants except Travis favor making the switch.
>> I'm personally -1 on this. I prefer to keep things as simple as
>> possible and do not see the need for a lot of branching, though there
>> is clearly a need for some. svn is the standard version control
>> system and has the best install base (now on OS X and all linux
>> systems), making it easiest for users to get checkouts. If numpy,
>> ipython and scipy all decide to move, I would probably be inclined to
>> go along with it for consistency between these packages, but I
>> wouldn't be leading the charge. I have never felt the need for a
>> distributed version control system, personally, though some swear by
>> it. It is probably because mpl has always just had a trunk with no
>> branches, and I'd like to stick to that as much as possible,
> 
> John,
> 
> I understand your points, and this is not something I am going to push, 
> but I suspect that over the next year or two there will be a migration 
> of numpy, ipython, and scipy. Certainly there is no need for us to 
> lead, and it might be downright foolish for us to try to do so. My 
> sense, however, is that a good DVCS is something like python itself--the 
> majority of people who seriously try one get hooked.
> 
> The point of the DVCS is not to facilitate long-term branches; it is 
> still normal to have a single official version. Instead, what a DVCS 
> does is to make version control easy to use locally, regardless of 
> whether one is connected to the net or not; and to use VC while 
> experimenting with changes. A full working repository (and a very fast 
> one at that) is always available. It is extremely fast and cheap to 
> make a clone for experimentation; if things work out, the changes can be 
> propagated back to the main repo, either as they were made initially or 
> by first generating a single clean patch; and then the experimental repo 
> is deleted.
> 
> I have never used hg as a central repo in a project with more than two 
> developers (my helper and me), so I don't know exactly how it would be 
> set up, how authentication would be handled, etc. for projects like 
> numpy and mpl. What I do know is that using hg--and consequently having 
> repos for our software on all the ships we work with, and on our laptops 
> when we travel--has been a big help. I suspect that if you tried it, 
> you would find yourself liking hg for entirely private use on work for 
> your employer.
> 
> Eric
> 
>> Michael, how onerous was it for you to do the merges using svn -- this
>> seems to be the most significant problem with svn in my reading of
>> David's summary.
>>
>> JDH
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John Hunter wrote:
> On Jan 7, 2008 2:37 PM, Eric Firing <ef...@ha...> wrote:
[...]
>> All this brings to mind the discussion taking place over the last week
>> on the numpy list regarding switching from svn to bzr or hg.
>> http://thread.gmane.org/gmane.comp.python.numeric.general/18130
>> (I have been using hg locally for a couple years, and I like it.) The
>> motivation is the greater ease of branching and merging with distributed
>> VCS systems in comparison to SVN. In the numpy list discussion, it
>> sounds like all participants except Travis favor making the switch.
> 
> I'm personally -1 on this. I prefer to keep things as simple as
> possible and do not see the need for a lot of branching, though there
> is clearly a need for some. svn is the standard version control
> system and has the best install base (now on OS X and all linux
> systems), making it easiest for users to get checkouts. If numpy,
> ipython and scipy all decide to move, I would probably be inclined to
> go along with it for consistency between these packages, but I
> wouldn't be leading the charge. I have never felt the need for a
> distributed version control system, personally, though some swear by
> it. It is probably because mpl has always just had a trunk with no
> branches, and I'd like to stick to that as much as possible,
John,
I understand your points, and this is not something I am going to push, 
but I suspect that over the next year or two there will be a migration 
of numpy, ipython, and scipy. Certainly there is no need for us to 
lead, and it might be downright foolish for us to try to do so. My 
sense, however, is that a good DVCS is something like python itself--the 
majority of people who seriously try one get hooked.
The point of the DVCS is not to facilitate long-term branches; it is 
still normal to have a single official version. Instead, what a DVCS 
does is to make version control easy to use locally, regardless of 
whether one is connected to the net or not; and to use VC while 
experimenting with changes. A full working repository (and a very fast 
one at that) is always available. It is extremely fast and cheap to 
make a clone for experimentation; if things work out, the changes can be 
propagated back to the main repo, either as they were made initially or 
by first generating a single clean patch; and then the experimental repo 
is deleted.
I have never used hg as a central repo in a project with more than two 
developers (my helper and me), so I don't know exactly how it would be 
set up, how authentication would be handled, etc. for projects like 
numpy and mpl. What I do know is that using hg--and consequently having 
repos for our software on all the ships we work with, and on our laptops 
when we travel--has been a big help. I suspect that if you tried it, 
you would find yourself liking hg for entirely private use on work for 
your employer.
Eric
> 
> Michael, how onerous was it for you to do the merges using svn -- this
> seems to be the most significant problem with svn in my reading of
> David's summary.
> 
> JDH

On Jan 7, 2008 2:37 PM, Eric Firing <ef...@ha...> wrote:
> (At the moment I can't compile the branch--I just sent Mike a message
> about that off the list, with voluminous output.)
>
> It seems like what is needed is not exactly a merge operation but simply
> a renaming of the trunk and the branch. Maybe some doc files need to be
> merged, but that is about it. Correct?
Sorry if I used sloppy terminology, all I mean is that Michael's stuff
will become the HEAD of the svn trunk, and the current HEAD of the
trunk will become a branch. No merge will be necessary since Michael
has been merging all changes in the HEAD into his branch on a ongoing
basis. I don't actually know how one does this move in svn, but I
have faith that Michael does.
> All this brings to mind the discussion taking place over the last week
> on the numpy list regarding switching from svn to bzr or hg.
> http://thread.gmane.org/gmane.comp.python.numeric.general/18130
> (I have been using hg locally for a couple years, and I like it.) The
> motivation is the greater ease of branching and merging with distributed
> VCS systems in comparison to SVN. In the numpy list discussion, it
> sounds like all participants except Travis favor making the switch.
I'm personally -1 on this. I prefer to keep things as simple as
possible and do not see the need for a lot of branching, though there
is clearly a need for some. svn is the standard version control
system and has the best install base (now on OS X and all linux
systems), making it easiest for users to get checkouts. If numpy,
ipython and scipy all decide to move, I would probably be inclined to
go along with it for consistency between these packages, but I
wouldn't be leading the charge. I have never felt the need for a
distributed version control system, personally, though some swear by
it. It is probably because mpl has always just had a trunk with no
branches, and I'd like to stick to that as much as possible,
Michael, how onerous was it for you to do the merges using svn -- this
seems to be the most significant problem with svn in my reading of
David's summary.
JDH

John et al.,
(At the moment I can't compile the branch--I just sent Mike a message 
about that off the list, with voluminous output.)
It seems like what is needed is not exactly a merge operation but simply 
a renaming of the trunk and the branch. Maybe some doc files need to be 
merged, but that is about it. Correct?
In any case, I will be happy to see the move take place, and I think we 
already agreed that this is a good time to do it.
All this brings to mind the discussion taking place over the last week 
on the numpy list regarding switching from svn to bzr or hg.
http://thread.gmane.org/gmane.comp.python.numeric.general/18130
 (I have been using hg locally for a couple years, and I like it.) The 
motivation is the greater ease of branching and merging with distributed 
VCS systems in comparison to SVN. In the numpy list discussion, it 
sounds like all participants except Travis favor making the switch.
For us to make such a change would require switching the repo host from 
sourceforge to something else--I suspect Enthought would be happy to 
host us.
Apart from the initial effort and spinup required--and I don't mean to 
dismiss that as trivial--I think that using a suitable DVCS would 
facilitate progress with mpl. If so, is it crazy to do it as part of a 
major branch/trunk switch, or does that perhaps make it easier?
Comments?
Eric
John Hunter wrote:
> Now that the 0.91.2 release is out, I am inclined to merge Michael's
> transforms branch into the trunk. Since many people rely on svn, we
> probably need to advertise this move broadly, with a news item on the
> web page and announcements on the mailing lists, with instructions on
> how to checkout the 0.91 maintenance branch (which does not exist but
> would be created as the maintenance branch). There was some
> suggestion earlier that we leave Michael's work on a branch, but I
> think we need to get it on the trunk so developers and svn users will
> get it by default which will help us move more rapidly in shaking out
> the remaining bugs and problems.
> 
> Michael, since you know more about this than anyone, you should
> probably spearhead the svn reorganization and let people know when the
> changes become effective with some advance notice. I will update the
> website with pointers to the relevant docs (your API_CHANGES and
> Changelog and the relevant svn commands and anything else you think we
> will need).
> 
> If this seems like a reasonable plan, perhaps we should shoot for
> doing this in a day or two. If any of you think this is the wrong
> approach, let us know.
> 
> JDH
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Now that the 0.91.2 release is out, I am inclined to merge Michael's
transforms branch into the trunk. Since many people rely on svn, we
probably need to advertise this move broadly, with a news item on the
web page and announcements on the mailing lists, with instructions on
how to checkout the 0.91 maintenance branch (which does not exist but
would be created as the maintenance branch). There was some
suggestion earlier that we leave Michael's work on a branch, but I
think we need to get it on the trunk so developers and svn users will
get it by default which will help us move more rapidly in shaking out
the remaining bugs and problems.
Michael, since you know more about this than anyone, you should
probably spearhead the svn reorganization and let people know when the
changes become effective with some advance notice. I will update the
website with pointers to the relevant docs (your API_CHANGES and
Changelog and the relevant svn commands and anything else you think we
will need).
If this seems like a reasonable plan, perhaps we should shoot for
doing this in a day or two. If any of you think this is the wrong
approach, let us know.
JDH

We have uploaded source and binary releases of matplotlib-0.91.2 to
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=566411.
Thanks to Charlie Moad for doing the release.
This is a bugfix release and includes several important fixes listed
below.
2008年01月06日 Released 0.91.2 at revision 4802
2007年12月26日 Reduce too-late use of matplotlib.use() to a warning
 instead of an exception, for backwards compatibility - EF
2007年12月25日 Fix bug in errorbar, identified by Noriko Minakawa - EF
2007年12月25日 Changed masked array importing to work with the upcoming
 numpy 1.05 (now the maskedarray branch) as well as with
 earlier versions. - EF
2007年12月16日 rec2csv saves doubles without losing precision. Also, it
 does not close filehandles passed in open. - JDH,ADS
2007年12月13日 Moved rec2gtk to matplotlib.toolkits.gtktools and rec2excel
 to matplotlib.toolkits.exceltools - JDH
2007年12月12日 Support alpha-blended text in the Agg and Svg backends -
 MGD
2007年12月10日 Fix SVG text rendering bug. - MGD
2007年12月10日 Increase accuracy of circle and ellipse drawing by using an
 8-piece bezier approximation, rather than a 4-piece one.
 Fix PDF, SVG and Cairo backends so they can draw paths
 (meaning ellipses as well). - MGD
2007年12月07日 Issue a warning when drawing an image on a non-linear axis. - MGD
2007年12月06日 let widgets.Cursor initialize to the lower x and y bounds
 rather than 0,0, which can cause havoc for dates and other
 transforms - DSD
2007年12月06日 updated references to mpl data directories for py2exe - DSD
2007年12月06日 fixed a bug in rcsetup, see bug 1845057 - DSD
2007年12月05日 Fix how fonts are cached to avoid loading the same one
multiple times.
 (This was a regression since 0.90 caused by the refactoring of
 font_manager.py) - MGD
2007年12月05日 Support arbitrary rotation of usetex text in Agg backend. - MGD
2007年12月04日 Support '|' as a character in mathtext - MGD

> Agreed. I know there are still some matplotlib users on python2.3, but
> they'll have to move on eventually... ;)
Yes, we decided to drop support for python2.3, because we use
decorators. But I am not going to drop support for 2.4, because
Debian (my distribution) still uses it by default. :)
> >> I generally don't like ctypes-based wrappers since changes in the
> >> dependency can mean segfaults at runtime. I'm having a problem getting
> >> pyglet to work on my particular version of OpenGL, for instance. But
> >> perhaps freetype is stable enough for that not to be a problem.
> >
> > Could you please report it to http://groups.google.com/group/pyglet-users ?
>
> Sorry -- I should have mentioned I already did.
Ah, so mdboom is you? I saw the headline, but I didn't look further.
Nice bug report!
> > So it's needed for path collections - what is that?
>
> A collection of a large number of paths (or polygons) that need to be
> rendered quickly.
>
> > When I want to do
> > regular plots,
> > like plotting some set of points, is that needed too? If not, it
> > should be optional imho.
>
> That's actually a tough one. On the transforms branch, by the time it
> hits the rendering level, everything is a polycurve path. Determining
> if something contains curves or not (which in the current implementation
> would require running through the entire path, which may be quite large)
> would probably be too slow.
I see. In this case, it's probably not worthy to create pure python kernel.
We do have some 2D plotting already, it's fast enough. But it
doesn't contain so many nice features of matplotlib.
> There are. But the multiple versions of the library must be
> individually tested to have a hope of working -- whereas with the
> compiled model, sometimes the changes between library versions will be
> seamless, other times the compile will fail, both of which are
> preferable to segfaulting at runtime (which admittedly is still possible
> even when compiling.)
I got it now. That's right.
> >> Great! I'll start by looking at pyglet's freetype wrapper and see how
> >> far I get.
> >
> > Awesome. Please ask on the list above, as I said, Alex is quite guru, so he
> > will answer any technical questions.
>
> Thanks,
Since you already asked, let's wait. :)
> > Granted, this page is getting a little dated, but here's what you get
> > with OpenGL: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html
>
> Thanks, that's the link I was basically quoting from memory, which I'd
> read when you posted it a while ago. Great reference on this topic.
That's nice enough for me. Don't forget, that I am comparing no
plotting, to some plotting.
Well, definitely, we try to support good interaction with external
packages, like numpy
and matplotlib. But builtin is builtin. :)
Ondrej
Ondrej

On Jan 4, 2008 1:04 PM, Andrew Straw <str...@as...> wrote:
> Excellent summary, Fernando -- are looking to burnish your visual
> neuroscientist credentials? ;)
Gotta start somewhere, no? :) Now I just have to convince the NSF
it's true as well... Back to grant writing :)
> > The other issue I recall is that the quality of openGL antialiasing is
> > highly dependent on the video card and/or driver. While that may be
> > OK for gamers, it's completely unacceptable IMO for scientific
> > publication.
>
>
> Granted, this page is getting a little dated, but here's what you get
> with OpenGL: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html
Thanks, that's the link I was basically quoting from memory, which I'd
read when you posted it a while ago. Great reference on this topic.
Cheers,
f

On Jan 4, 2008, at 1:08 PM, Fernando Perez wrote:
> No worries, you misunderstood me :) My point was that a linux
> developer could keep a vwmare image around to produce the binary
> windows *installer* for win32 users, if there were compiled code
> around.
Oh.
That's all right, then.
Sorry.
(Actually I might be a tad more Windows-neutral, as Python gets us 
halfway there... so far our user community hasn't asked for it, whew!)
(lurking resumes...)
 - boyd

On Jan 4, 2008 1:00 PM, Ondrej Certik <on...@ce...> wrote:
>
> On Jan 4, 2008 8:44 PM, Darren Dale <dar...@co...> wrote:
> > Why would your users have to compile anything on windows? Matplotlib's windows
> > users just run the installer, the compilation has already been done. Am I
> > missing something?
As I mentioned, it does meant that the project does need a volunteer
to *produce* the win32 installers. That might be trivial (if that
person already exists) or could require some work, but it's not
insurmountable (and as I hinted, with virtualization that person can
even be one of the regular unix people with only limited pain).
Cheers,
f

On Jan 4, 2008 1:04 PM, Boyd Waters <bw...@nr...> wrote:
>
> On Jan 4, 2008, at 12:44 PM, Fernando Perez wrote:
>
> > Indeed, compiled code in a project basically forces you to have a
> > windows developer in the team who can build the binary installers.
> > These days with vmware/qemu it's not the end of the world (it can be
> > done in a normal computer running linux/osx) but it's still a pain for
> > most of us, no doubt about it.
>
>
> Not to open a can of trolls here, but I must strongly disagree.
>
> Why does "compiled code" mean "Windows"?
No worries, you misunderstood me :) My point was that a linux
developer could keep a vwmare image around to produce the binary
windows *installer* for win32 users, if there were compiled code
around. I was just explaining how even if the project has no windows
volunteers on hand to generate the installers, this isn't
insurmountable these days thanks to vmware. You still need a
linux/osx dev who's willing to install virtualized windows and
compiler, but that's a lower requirement than asking one of us to
switch to win32 altogether :)
Relax, anyone who knows me has already seen how big of a fan of win32 I am ;)
Cheers,
f

Ondrej Certik wrote:
> On Jan 4, 2008 7:41 PM, Michael Droettboom <md...@st...> wrote:
>> Ondrej Certik wrote:
>>> * freetype (this could be rewritten using ctypes)
>> I see that pyglet already has a freetype wrapper using ctypes -- it
>> would be interesting to see if that could be used as a starting point.
>> That could be used as a starting point. (Of course, ctypes is an
>> external dependency before Python-2.5, which adds a dependency to
>> matplotlib).
> 
> That is correct. I forgot about that. We do support python2.4 and it's
> true that in order
> for plotting to work, you need to install python-ctypes.
> But python2.4 will hopefully get old soon, in favor of python2.5.
Agreed. I know there are still some matplotlib users on python2.3, but 
they'll have to move on eventually... ;)
>> I generally don't like ctypes-based wrappers since changes in the
>> dependency can mean segfaults at runtime. I'm having a problem getting
>> pyglet to work on my particular version of OpenGL, for instance. But
>> perhaps freetype is stable enough for that not to be a problem.
> 
> Could you please report it to http://groups.google.com/group/pyglet-users ?
Sorry -- I should have mentioned I already did.
>>> * Agg (this could be optional)
>> On the transforms branch, Agg is used for bezier curve realisation,
>> whether the Agg renderer is being used or not. This is used for things
>> like hit-testing and range-setting of path collections etc. This was
>> not fast enough in my earlier numpy-based implementation, since to take
>> advantage of numpy, you generally have to allocate lots of memory to
>> store the results in. In this particular case, each value can be
>> immediately thrown away, so all that extra work was unnecessary.
> 
> So it's needed for path collections - what is that? 
A collection of a large number of paths (or polygons) that need to be 
rendered quickly.
> When I want to do
> regular plots,
> like plotting some set of points, is that needed too? If not, it
> should be optional imho.
That's actually a tough one. On the transforms branch, by the time it 
hits the rendering level, everything is a polycurve path. Determining 
if something contains curves or not (which in the current implementation 
would require running through the entire path, which may be quite large) 
would probably be too slow.
>>> Compiling really sucks.
>> Agreed. But there is a spectrum of suckage here. It also sucks to be
>> unable to check that a call to some library that you don't provide
>> (freetype) will succeed.
> 
> That sucks too. But I think there are mechanisms to check the exact version
> of the library, aren't there?
There are. But the multiple versions of the library must be 
individually tested to have a hope of working -- whereas with the 
compiled model, sometimes the changes between library versions will be 
seamless, other times the compile will fail, both of which are 
preferable to segfaulting at runtime (which admittedly is still possible 
even when compiling.)
>>>>> Another cool stuff in matplotlib is the pure python latex renderer
>>>>> (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for
>>>>> more info:
>>>> Yes, the mathtext support in matplotlib is very nice, and Michael
>>>> deserves the credit for taking from a package that
>>>> works but has warts, to an extremely nice math layout engine using the
>>>> Knuth algorithms. I'm sure others would like to use it without having
>>>> to pull in all of matplotlib. With a ctypes freetype wrapper, it
>>>> should be possible to build a free-standing mathtext.
>>> And this is really cool. I would like to have that. :)
>>>
>>> We'll try to help with that one.
>> Great! I'll start by looking at pyglet's freetype wrapper and see how
>> far I get.
> 
> Awesome. Please ask on the list above, as I said, Alex is quite guru, so he
> will answer any technical questions.
Thanks,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Jan 4, 2008, at 12:44 PM, Fernando Perez wrote:
> Indeed, compiled code in a project basically forces you to have a
> windows developer in the team who can build the binary installers.
> These days with vmware/qemu it's not the end of the world (it can be
> done in a normal computer running linux/osx) but it's still a pain for
> most of us, no doubt about it.
Not to open a can of trolls here, but I must strongly disagree.
Why does "compiled code" mean "Windows"?
I'd recommend that some OpenGL layer be used from Python. Use automake 
for the build system.
We'd have to drop Matplotlib if it required Windows; at the moment we 
only have Linux and Macintosh developers (the Mac got in because it's 
a Unix platform, but it still took some porting).
I believe that many other scientific research organizations have many 
Unix boxes and few Windows machines for their analysis workstations. I 
know it's true of the astronomy places that I've visited, but I 
haven't seen other science in a while so perhaps Windows has taken 
over science, too. But at our facility we can't support Windows for 
scientific development.
/me runs away, covering head...
;-)
 - boyd
Boyd Waters
Scientific Programmer
National Radio Astronomy Observatory
Socorro, New Mexico

Fernando Perez wrote:
> It's probably worth mentioning that one of the reasons John chose Agg
> is because of image *quality* concerns. If I'm not mistaken (John and
> A. Straw will correct me as needed), the OpenGL anti-aliasing quality
> is positively horrible when you compare it to the quality of Agg.
> Keep in mind that OpenGL is typically focused on keeping high
> frame-rates for moving images, so pixel-perfect antialiasing is much
> less of a concern for them, since your eye is a lot less likely to
> notice such fine details (as long as there is *some* antialiasing).
> For a static image, you tend to be a lot pickier, and Agg goes to
> great lengths to ensure the best possible antialiasing quality. This
> is part of the reason why normal television, at abysmally low
> resolutions is still acceptable for viewing, while nobody would
> consider a 400-line-image an acceptable photograph for most uses. You
> 'stare' at the moving image only for 1/30 s or so, while you look at
> the static one for much longer.
Excellent summary, Fernando -- are looking to burnish your visual
neuroscientist credentials? ;) The only thing I'd add is that the
spatio-temporal nature of video means that, despite course spatial
quantization on any single image, we perceive something with a much
higher resolution essentially because we have many samples where the
source is moving against the sampling array and we "fill in". Not only
do we do this, so do our electronic devices these days -- upsampling
(spatially and temporally) DVD players make use of algorithms to fill in
pixels that weren't directly specified. And video compression codecs
essentially remove information that's perceptually less significant to
this filling in process. (Stop me here...)
> I've never seen any opengl-based antialiasing be of that quality. But
> there may be ways of achieving the same thing in OpenGL, I don't know
> (and to do so efficiently and portably, without requiring specific
> video cards).
>
> The other issue I recall is that the quality of openGL antialiasing is
> highly dependent on the video card and/or driver. While that may be
> OK for gamers, it's completely unacceptable IMO for scientific
> publication.
Granted, this page is getting a little dated, but here's what you get
with OpenGL: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html
FWIW, one cheap trick to get better anti-aliasing with OpenGL is to
render the image much bigger than you need and then downsample it
appropriately. As OpenGL implementations have maximum rendering sizes,
this often means tiling the image. This probably wouldn't work for
realtime rendering, but for saving bitmaps it would produce decent results.
In general, I think we should explore collaboration (and I'm very
excited about the sympy project). Yet, it's difficult for me to see how
MPL could be turned into a pure-Python project with acceptable speed and
retaining the backends that we support with the quality we support. All
the more so with the new transforms branch.