matplotlib-devel Mailing List for matplotlib

Andrew Straw wrote:

I realize I may have ignored an important question.

> Michael Droettboom wrote:

>> Now I feel stuck.  How do I "undo" the merge from experimental to master?

To do that, I actually delete the master branch with "git branch -D
master" and then re-create a new one with "git checkout -b master
028a0df8" (where I've identified commit 028a0df8 as where I want the new
master to be).

Note that before deleting the master branch, it's probably wise to
create a branch, which will probably be deleted momentarily, as a
reference to this location in case you need to get back to it. Do so
with "git checkout -b tmp/old-master". When everything is done, use "git
branch -D tmp/old-master" to delete it.

On Thu, Dec 11, 2008 at 11:20 AM, Andrew Straw <str...@as...> wrote:
> Michael Droettboom wrote:
>> Darren Dale wrote:
>>
>>> Having worked with bzr and launchpad for a few months now, I wonder if
>>> we might consider such an approach in the future. I know there has
>>> been some experimentation with a git repository, is git supported on
>>> windows now?
>>>
>> I'm not sold that bzr/hg/git makes things simpler for this development
>> model.
> My thought is that matplotlib.sourceforge.net is a centralized website
> making centralized, official releases and other  centralized facilities.
> Thus, it seems to me that a centralized, official version control branch
> is an entirely reasonable thing to have. svn provides a
> least-common-denominator for this job, and I don't see the reasons to
> shift to bzr/hg/git as sufficiently strong to merit such a shift. In
> particular, the svn model is pretty darn simple, and therefore easy to
> interface with (whether you're a human or a computer program).

I just wanted to interject some things from the bzr side. Bzr can work
either in a distributed or centralized model which makes it sort of
handy for SVN people, though I don't personally see that as any good
motivation to completely convert the whole thing to bzr. At this point
in time as I've had a chance to work with several projects using SVN,
git, and bzr I agree with you that SVN is a good
least-common-denominator, especially if the project is already using
SVN.

> Of course, part of why I think this way is that git seems to be working
> pretty well for inter-operation with the official svn repository. My
> experimental repository, described at
> http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-git
> , is nicely allowing me to browse history locally, do git bisect,
> maintain my own branches, commit back to the svn repository when
> desired, and so on. I think there *may* be some impedance mis-matching
> if we tried to really map git branches on svnmerge branches, but right
> now that hasn't been an issue I've pursued.

bzr-svn is also fantastic, I use it all the time. I also wanted to
point out that Launchpad has a bzr mirror of matplotlib going so if
you want to play around with bzr you can try that. In the past bzr has
been very slow when branching but with the latest stable release I
got:

$ time bzr branch lp:matplotlib
Branched 4100 revision(s).

real	2m9.893s

Which is pretty impressive considering you're getting the entire
history. Anyway, I'm not a bzr fanatic but I just wanted to point out
the above for completeness and in case anybody was interested.

-Jordan

Hi Michael,

The main issue is that we can't use git "normally" because the main
history will be kept with svn. Thus, there's going to be a lot of
history rewriting going on through the rebase command. (These
complications are obviously not the ideal scenario for git newbies...)
Rather than answer your questions directly, I'll walk you through how I
do things. (This is not tried on the MPL svn repo, but some a private
svn repo. I don't see any fundamental differences, though. So this
should work.)

(Hopefully this will be cut-and-pasteable ReST, which could go in the
docs somewhere):

Making a git feature branch and committing to svn trunk
-------------------------------------------------------

Start with a virgin tree in sync with the svn trunk on the git branch
"master"::

  git checkout master
  git svn rebase

To create a new, local branch called "whizbang-branch"::

  git checkout -b whizbang-branch

Do make commits to the local branch::

  # hack on a bunch of files
  git add bunch of files
  git commit -m "modified a bunch of files"
  # repeat this as necessary

Now, go back to the master branch and append the history of your branch
to the master branch, which will end up as the svn trunk::

  git checkout master
  git svn rebase # Ensure we have most recent svn
  git rebase whizbang-branch # Append whizbang changes to master branch
  git svn dcommit -n # Check that this will apply to svn
  git svn dcommit # Actually apply to svn

Finally, you may want to continue working on your whizbang-branch, so
rebase it to the new master::

  git checkout whizbang-branch
  git rebase master

Michael Droettboom wrote:
> This is mostly for Andrew Straw, but thought anyone else experimenting
> with git may be interested.  I'm going through some real newbie pains
> here, and I don't think what I'm doing is all that advanced.
> 
> So, I've had a local git repository cloned from github (as per Andrew's
> instructions), made a branch, started hacking, all is well.  Now, I
> would like to update my master branch from SVN to get some of the recent
> changes others have been making.
> 
> Following the instructions in the FAQ,
> 
>  git svn rebase
> 
> actually results in a number of conflicts in files I didn't touch.  I
> shouldn't have to resolve this conflicts, right?  'git status' shows no
> local changes, nothing staged -- nothing that should conflict.
> 
> It turns out, if I do
> 
>   git pull
> 
> then,
> 
>   git svn rebase
> 
> all is well.
> 
> Any idea why?  Should I add that to the instructions in the FAQ?
> 
> Now, here's where I'm really stumped.  I finished my experimental
> branch, and I would like to commit it back to SVN.
> 
> This is what I did, with comments preceded by '#'
> 
> # Go back to the master branch
>> git checkout master
> # Merge in experimental
>> git merge experimental
> # Ok -- looks good: experimental new feature is integrated, there were
> no conflicts
> # However...
>> git svn dcommit
> Committing to
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
> ...
> Merge conflict during commit: File or directory
> 'doc/users/whats_new.rst' is out of date; try updating: resource out of
> date; try updating at /home/mdroe/usr/libexec/git-core//git-svn line 467
> # 1) I didn't change that file, why should I care
> # 2) I don't know who to update it
>> git pull
> Already up-to-date.
>> git svn rebase
> First, rewinding head to replay your work on top of it...
> Applying: more doc adds
> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
> whitespace.
> a lot of new features and bug-fixes. warning: 1 line adds whitespace
> errors.
> Applying: added some docs for linestyles and markers
> Applying: Remove trailing whitespace.
> Applying: figure/subplot and font_manager bugfixes
> Applying: added support for xlwt in exceltools
> Applying: fixed a typo in whats_new_98_4_legend.py
> Applying: fixed typo in Line2D.set_marker doc.
> Applying: /matplotlib/__init__.py: catch OSError when calling subprocess.
> Applying: more doc adds
> /home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing
> whitespace.
> a lot of new features and bug-fixes. error: patch failed:
> doc/users/whats_new.rst:10
> error: doc/users/whats_new.rst: patch does not apply
> Using index info to reconstruct a base tree...
> <stdin>:14: trailing whitespace.
> a lot of new features and bug-fixes. warning: 1 line adds whitespace
> errors.
> Falling back to patching base and 3-way merge...
> No changes -- Patch already applied.
> Applying: added some docs for linestyles and markers
> error: patch failed: doc/devel/coding_guide.rst:62
> error: doc/devel/coding_guide.rst: patch does not apply
> error: patch failed: doc/matplotlibrc:43
> error: doc/matplotlibrc: patch does not apply
> error: patch failed: doc/pyplots/whats_new_98_4_legend.py:4
> error: doc/pyplots/whats_new_98_4_legend.py: patch does not apply
> error: patch failed: lib/matplotlib/lines.py:313
> error: lib/matplotlib/lines.py: patch does not apply
> Using index info to reconstruct a base tree...
> Falling back to patching base and 3-way merge...
> Auto-merged doc/pyplots/whats_new_98_4_legend.py
> CONFLICT (content): Merge conflict in doc/pyplots/whats_new_98_4_legend.py
> Auto-merged lib/matplotlib/lines.py
> Failed to merge in the changes.
> Patch failed at 0010.
> 
> When you have resolved this problem run "git rebase --continue".
> If you would prefer to skip this patch, instead run "git rebase --skip".
> To restore the original branch and stop rebasing run "git rebase --abort".
> 
> rebase refs/remotes/trunk: command returned error: 1
> # Ok, I'm back to merging files that don't conflict with my changes! # I
> shouldn't have to do that, right?
> # And FYI:
>> git status
> doc/pyplots/whats_new_98_4_legend.py: needs merge
> # Not currently on any branch.
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> #    modified:   lib/matplotlib/lines.py
> #
> # Changed but not updated:
> #   (use "git add <file>..." to update what will be committed)
> #
> #    unmerged:   doc/pyplots/whats_new_98_4_legend.py
> #
> # Untracked files:
> #   (use "git add <file>..." to include in what will be committed)
> #
> #    lib/matplotlib/mpl-data/matplotlib.conf
> #    lib/matplotlib/mpl-data/matplotlibrc
> #    setupext.pyc
> #    src/backend_agg.cpp~
> 
> Now I feel stuck.  How do I "undo" the merge from experimental to master?
> 
> Sorry if these are obvious questions, but I think I've followed the
> git-svn instructions -- I must have made a mistake somewhere along the
> way, but I'm not sure how to debug and/or fix it.
> 
> Mike

John,
One thing that would help w/ a rapid delivery/response cycle would be more comprehensive tests.    They would let other developers try out various ideas and see what breaks before you release it.

We’ve implemented an automated approach where we run an MPL script using Agg, save the output image and then compare it against a “good” image that someone looked at.  We use PIL to do the compare and if it’s close (that’s the hard part), then the test passes.  If it’s not, someone looks at the two images to see if the difference is benign.  Something similar to this could be done (if you’re not already) for the MPL examples to make sure that changes don’t cause plotting problems in other areas.

Having this kind of system is also a great driver for people to expand it.  For example – we really care about unit processing support everywhere.  Every once in awhile, we find a change that someone submits that breaks unit support.  So once of the tasks we‘re going to work on next year is to build a set of automated test cases that try and hit every plot function with units which can then run on every release.  If there were a simple to use MPL standard test system like this, other people might contribute more tests as a way of insuring that the things they care about stay working through various changes.

It would also be nice to have a test system for unit testing of components.  A lot of the code that does different transformations, symbol and color mapping, etc etc could be unit tested without the need for actually drawing anything.  If there was a standard location, style, and system, people could slowly add to the tests over time.  You can also consider requiring some level of unit test for newly submitted code where ever it’s possible.

Just some thoughts…
Ted

From: John Hunter [mailto:jd...@gm...]
Sent: Wednesday, December 10, 2008 8:10 PM
To: Darren Dale
Cc: mat...@li...
Subject: Re: [matplotlib-devel] requesting permission to remove traits and configobj


On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <dsd...@gm...<mailto:dsd...@gm...>> wrote:
There has been a report at the bugtracker complaining that matplotlib is overwriting an existing installation of configobj. I had a look at the code and thought the bug report must be a mistake or windows specific, but I just saw similar behavior on my linux system.

Ignoring for a minute the question of whether we can/should flush configobj/traits, it sounds like the real problem is that setup.cfg is not working like we expect it to.  And that is something that should be fixed if is broken.  If mpl is installing configobj or traits even if we are telling it not to via setup.cfg, then we have a problem.   This is worth knowing, since the last mpl release was broken vis-a-vis the default backend on win32, which *could* be explained by a broken setup.cfg.

I would like to simply remove configobj and traits from our repository. They are only used by the long-neglected experimental traited config package, which is only of interest to developers who can easily install them as external dependencies. Is it ok to remove them? If so, should it be done on all the branches?

How long are we going to continue to maintain the different branches? It was so much easier back when we only had to worry about the trunk...

You can remove them from the trunk.  They should remain on the 0.91 branch as is (with any known bugs fixed and merged) since that is the point of the branch (stability for those who cannot upgrade -- in principle someone might be depending on the traited config, in practice unlikely).  As for the 0.98 branch, it is slated for destruction so no worries.  I share your visceral reaction against branches, but my head is starting to override this bodily reaction, as I see the need for them in practice.  If we carefully document the best practices and motivations in the developerr's guide, we can use them advantageously.

We have a lot of people contributing to mpl, and approaching or just after release time we need some mechanism for stabilizing the tested feature set  of the release candidate while allowing other development to proceed, and branches are the natural mechanism for that.  That we are starting to use them is a reflection of the fact that we have many more active developers than we ever had before (12 developers contributed between 98.3 and 98.4, it used to be just 3 or 4 at a time).   I wouldn't be advocating branches otherwise, because I am an advocate of doing things as simply as possible: "Make everything as simple as possible, but not simpler.".

In general, I am in favor of the wildest, wooliest, development process we can afford.  I would like to have  everyone on the trunk, making releases as often as possible (nightly if we can), with an attitude of "if you break it, just fix it an rerelease it".  This model worked fine for us for years, and I think it would continue to work if we have a hyper-active developer or an automated build bot.  In the old days, I would release any time I added a new feaure, and if I broke something I would have a new release out in hours.  I no longer have the time for that, and  we are lucky to have Charlie buildng OS X and win32 binaties and eggs for multiple python versions.  When we release broken code, Charlie has to go through the entire test/upload/release cycle again, building for multiple OSs and python versions while taking care of his wife and two babies, so we want to minimize that.  At the same time, we have lots of developers pushing code into the mainline.  We need some mechanism of balancing the desire of developers to get new code in and the need for the packagers and release manangers to get stable code out.

I think the right balance for mpl before a release is to test the HEAD, sign off on it, branch it, let development proceed on the HEAD, and put any release critical bugs and fixes into the branch.  When the next release comes up, delete the old branch, and wash-rinse-repeat.  We will have in perpetuity one active release branch at a time, which gets important bug fixes and nothing else, and in addition (for a while) a legacy branch (0.91) which is updated once a month or so.  I am happy to get input on this.
JDH

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.16/1841 - Release Date: 12/10/2008 6:53 PM

This is mostly for Andrew Straw, but thought anyone else experimenting 
with git may be interested.  I'm going through some real newbie pains 
here, and I don't think what I'm doing is all that advanced.

So, I've had a local git repository cloned from github (as per Andrew's 
instructions), made a branch, started hacking, all is well.  Now, I 
would like to update my master branch from SVN to get some of the recent 
changes others have been making.

Following the instructions in the FAQ,

  git svn rebase

actually results in a number of conflicts in files I didn't touch.  I 
shouldn't have to resolve this conflicts, right?  'git status' shows no 
local changes, nothing staged -- nothing that should conflict.

It turns out, if I do

   git pull

then,

   git svn rebase

all is well.

Any idea why?  Should I add that to the instructions in the FAQ?

Now, here's where I'm really stumped.  I finished my experimental 
branch, and I would like to commit it back to SVN.

This is what I did, with comments preceded by '#'

# Go back to the master branch
 > git checkout master
# Merge in experimental
 > git merge experimental
# Ok -- looks good: experimental new feature is integrated, there were 
no conflicts
# However...
 > git svn dcommit
Committing to 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib 
...
Merge conflict during commit: File or directory 
'doc/users/whats_new.rst' is out of date; try updating: resource out of 
date; try updating at /home/mdroe/usr/libexec/git-core//git-svn line 467
# 1) I didn't change that file, why should I care
# 2) I don't know who to update it
 > git pull
Already up-to-date.
 > git svn rebase
First, rewinding head to replay your work on top of it...
Applying: more doc adds
/home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing 
whitespace.
a lot of new features and bug-fixes. 
warning: 1 line adds whitespace errors.
Applying: added some docs for linestyles and markers
Applying: Remove trailing whitespace.
Applying: figure/subplot and font_manager bugfixes
Applying: added support for xlwt in exceltools
Applying: fixed a typo in whats_new_98_4_legend.py
Applying: fixed typo in Line2D.set_marker doc.
Applying: /matplotlib/__init__.py: catch OSError when calling subprocess.
Applying: more doc adds
/home/mdroe/builds/matplotlib.git/.git/rebase-apply/patch:14: trailing 
whitespace.
a lot of new features and bug-fixes. 
error: patch failed: doc/users/whats_new.rst:10
error: doc/users/whats_new.rst: patch does not apply
Using index info to reconstruct a base tree...
<stdin>:14: trailing whitespace.
a lot of new features and bug-fixes. 
warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: added some docs for linestyles and markers
error: patch failed: doc/devel/coding_guide.rst:62
error: doc/devel/coding_guide.rst: patch does not apply
error: patch failed: doc/matplotlibrc:43
error: doc/matplotlibrc: patch does not apply
error: patch failed: doc/pyplots/whats_new_98_4_legend.py:4
error: doc/pyplots/whats_new_98_4_legend.py: patch does not apply
error: patch failed: lib/matplotlib/lines.py:313
error: lib/matplotlib/lines.py: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merged doc/pyplots/whats_new_98_4_legend.py
CONFLICT (content): Merge conflict in doc/pyplots/whats_new_98_4_legend.py
Auto-merged lib/matplotlib/lines.py
Failed to merge in the changes.
Patch failed at 0010.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

rebase refs/remotes/trunk: command returned error: 1
# Ok, I'm back to merging files that don't conflict with my changes! 
# I shouldn't have to do that, right?
# And FYI:
 > git status
doc/pyplots/whats_new_98_4_legend.py: needs merge
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#    modified:   lib/matplotlib/lines.py
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#    unmerged:   doc/pyplots/whats_new_98_4_legend.py
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#    lib/matplotlib/mpl-data/matplotlib.conf
#    lib/matplotlib/mpl-data/matplotlibrc
#    setupext.pyc
#    src/backend_agg.cpp~

Now I feel stuck.  How do I "undo" the merge from experimental to master?

Sorry if these are obvious questions, but I think I've followed the 
git-svn instructions -- I must have made a mistake somewhere along the 
way, but I'm not sure how to debug and/or fix it.

Mike

Michael Droettboom wrote:
> Darren Dale wrote:
>   
>> Having worked with bzr and launchpad for a few months now, I wonder if 
>> we might consider such an approach in the future. I know there has 
>> been some experimentation with a git repository, is git supported on 
>> windows now?
>>     
> I'm not sold that bzr/hg/git makes things simpler for this development 
> model.
My thought is that matplotlib.sourceforge.net is a centralized website
making centralized, official releases and other  centralized facilities.
Thus, it seems to me that a centralized, official version control branch
is an entirely reasonable thing to have. svn provides a
least-common-denominator for this job, and I don't see the reasons to
shift to bzr/hg/git as sufficiently strong to merit such a shift. In
particular, the svn model is pretty darn simple, and therefore easy to
interface with (whether you're a human or a computer program).

Of course, part of why I think this way is that git seems to be working
pretty well for inter-operation with the official svn repository. My
experimental repository, described at
http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-git
, is nicely allowing me to browse history locally, do git bisect,
maintain my own branches, commit back to the svn repository when
desired, and so on. I think there *may* be some impedance mis-matching
if we tried to really map git branches on svnmerge branches, but right
now that hasn't been an issue I've pursued.

As far as git on Windows: I think there's some kind of msys git and also
the cygwin approach. Not using windows much, though, I'm not sure. I did
hear that Microsoft just started using github for ironruby, so
presumably something works for them.

Hi Nils. I think I fixed the issue causing the traceback with r6563. Can
you please update and try again with text.usetex enabled?

My guess is that you don't have dvipng installed, which was causing the
detection check to throw a traceback rather than return a value
signifying undetected. So, enabling usetex should again trigger the
check, but hopefully this time it will fail gracefully rather than crashing.

-Andrew

Nils Wagner wrote:
> On Thu, 11 Dec 2008 09:13:02 +0100
>   "Nils Wagner" <nw...@ia...> wrote:
>> On Wed, 10 Dec 2008 21:11:12 -0600
>>  "John Hunter" <jd...@gm...> wrote:
>>> On Wed, Dec 10, 2008 at 4:26 PM, John Hunter 
>>> <jd...@gm...> wrote:
>>>
>>>>> Is it planned to adapt the example wrt xlwt ?
>>>>>
>>>>> http://pypi.python.org/pypi/xlwt
>>>>>
>>>>
>>>> True it is no longer maintained, but it does work.  We 
>>>> are looking into
>>>> xlwt (I wasn't aware of it until today when you 
>>>> forwarded the message)
>>>>
>>> I've added support for xlwt in svn r6560  -- give it a 
>>> whirl
>>>
>>> JDH
>> Hi John,
>>
>> I have upgraded to r6561.
>>
>> python test.py --verbose-helpful
>> $HOME=/data/home/nwagner
>> CONFIGDIR=/data/home/nwagner/.matplotlib
>> matplotlib data path 
>> /data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mpl-data
>> loaded rc file 
>> /data/home/nwagner/.matplotlib/matplotlibrc
>> Traceback (most recent call last):
>>   File "test.py", line 1, in <module>
>>     import matplotlib.mlab as mlab
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
>> line 700, in <module>
>>     rcParams['text.usetex'] = 
>> checkdep_usetex(rcParams['text.usetex'])
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
>> line 367, in checkdep_usetex
>>     dvipng_v = checkdep_dvipng()
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
>> line 261, in checkdep_dvipng
>>     stderr=subprocess.PIPE)
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/subprocess.py", 
>> line 593, in __init__
>>     errread, errwrite)
>>   File 
>> "/data/home/nwagner/local/lib/python2.5/subprocess.py", 
>> line 1079, in _execute_child
>>     raise child_exception
>> OSError: [Errno 2] No such file or directory
>>  
>>
>> Any idea ?
>>
>>             Nils
>>
>   
> Works for me if I disable text.usetex in 
> ~/.matplotlib/matplotlibrc, but for what reason ?
> 
> 
> ### LaTeX customizations. See 
> http://www.scipy.org/Wiki/Cookbook/Matplotlib/UsingTex
> #text.usetex         : True   # use latex for all text 
> handling. The following fonts
> 
> Nils
> 
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John,

I guess the number of "=" of the first column should be 10 (now 9),
because of 'CARETRIGHT'.

I submitted the change to the TRUNK.

-JJ



On Wed, Dec 10, 2008 at 9:50 PM, John Hunter <jd...@gm...> wrote:
> In response to a question on matplotlib-users, I added some additional
> documentation for the linestyles and markers in the matplotlib.lines API
> docs.  Specifically, I added a rest table mapping the linestyle/marker to
> the meaning of the marker.  Strangely, the set_linestyle table renders fine
>
>
> http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_linestyle
>
> but the table in set_marker is absent
>
>
> http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_marker
>
> I've tried cleanly building and installing mpl in my src tree, running
> svn-clean to make sure no cruft is impacting me, but I have not succeeeded
> in getting the marker table to render.  Perhaps a fresh set of eyeballs can
> spot the problem.  I'm pasting the docstrings below::
>
>     def set_linestyle(self, linestyle):
>
> """
>         Set the linestyle of the line (also accepts
> drawstyles)
>
>
>         ================
> =================
>         linestyle
> description
>         ================
> =================
>         '-'
> solid
>         '--'
> dashed
>         '-.'
> dash_dot
>         ':'
> dotted
>         'None'              draw
> nothing
>         ' '                 draw
> nothing
>         ''                  draw
> nothing
>         ================    =================
>
>
>         ..
> seealso::
>
> :meth:`set_drawstyle`
>
>         ACCEPTS: [ '-' | '--' | '-.' | ':' | 'None' | ' ' | '' ]
> and
>         any drawstyle in combination with a linestyle, e.g.
> 'steps--'.
>         """
>
> And here is set_marker docstring::
>
>     def set_marker(self, marker):
>         """
>         Set the line marker
>
>         =========  ==========================
>         marker     description
>         =========  ==========================
>         '.'        point
>         ','        pixel
>         'o'        circle
>         'v'        triangle_down
>         '^'        triangle_up
>         '<'        triangle_left
>         '>'        triangle_right
>         '1'        tri_down
>         '2'        tri_up
>         '3'        tri_left
>         '4'        tri_right
>         's'        square
>         'p'        pentagon
>         '*'        star
>         'h'        hexagon1
>         'H'        hexagon2
>         '+'        plus
>         'x'        x
>         'D'        diamond
>         'd'        thin_diamond
>         '|'        vline
>         '_'        hline
>         TICKLEFT   tickleft
>         TICKRIGHT  tickright
>         TICKUP     tickup
>         TICKDOWN   tickdown
>         CARETLEFT  caretleft
>         CARETRIGHT caretright
>         CARETUP    caretup
>         CARETDOWN  caretdown
>         'None'     nothing
>         ' '        nothing
>         ''         nothing
>         =========  ==========================
>
>
>         ACCEPTS: [ '+' | '*' | ',' | '.' | '1' | '2' | '3' | '4'
>                  | '<' | '>' | 'D' | 'H' | '^' | '_' | 'd'
>                  | 'h' | 'o' | 'p' | 's' | 'v' | 'x' | '|'
>                  | TICKUP | TICKDOWN | TICKLEFT | TICKRIGHT
>                  | 'None' | ' ' | '' ]
>
>         """
>
>
>
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On Thu, Dec 11, 2008 at 8:25 AM, Michael Droettboom <md...@st...> wrote:

>> And I'll try and get the maintenance branch right next time :-)
>
> All of the above sounds good to me.

I will be traveling to my conference starting at noon, so will be in
sporadic, light email contact for the next few days.  Charlie will
look at fixing the builds tonight -- everyone else, please do what you
can if something comes up because I would love to have a good set of
binaries on line by the time my talk starts at noon tomorrow:

  http://mloss.org/workshop/nips08/

JDH

Darren Dale wrote:
>
>
>     We have a lot of people contributing to mpl, and approaching or
>     just after release time we need some mechanism for stabilizing the
>     tested feature set  of the release candidate while allowing other
>     development to proceed, and branches are the natural mechanism for
>     that.  That we are starting to use them is a reflection of the
>     fact that we have many more active developers than we ever had
>     before (12 developers contributed between 98.3 and 98.4, it used
>     to be just 3 or 4 at a time).   I wouldn't be advocating branches
>     otherwise, because I am an advocate of doing things as simply as
>     possible: "Make everything as simple as possible, but not
>     simpler.".  
>
>
> Having worked with bzr and launchpad for a few months now, I wonder if 
> we might consider such an approach in the future. I know there has 
> been some experimentation with a git repository, is git supported on 
> windows now?
I'm not sold that bzr/hg/git makes things simpler for this development 
model.  Brett Cannon is currently developing a PEP to propose DVCS for 
CPython development.  See here:

http://docs.google.com/View?docid=dg7fctr4_40dvjkdg64

What John is proposing for matplotlib is identical to the "Backport" use 
case in the PEP.  As you can see, hg actually makes things a lot more 
complicated than svn/svnmerge in this regard.  I don't know if bzr 
(which I have almost no experience with), or git (which I've tried to do 
this kind of thing but haven't found the magic incantation yet), are any 
better in this regard.  Perhaps they are, but it's difficult to find 
documentation on "methodologies" rather than just "methods" for these 
youngish tools.  I think it would be fantastic for anyone with enough 
knowledge able to help Brett flesh out his PEP, because then we'd all 
have a really clean comparison between the tools for specific use 
cases.  And it's a very scientific and "spin-free" way forward, IMHO.

So, I'm not meaning to jump on your suggestion specifically, Darren, but 
I think I've reached some sort of level of fatigue with people saying 
(mainly outside matplotlib) "if we just switched to X, all this 
merging/branching would be so much easier", without a specific 
description of how to migrate to and use X and how that's superior 
enough to warrant the effort.  I don't mean that rhetorically -- I 
actually believe anything is probably better than Subversion, but 
specifically why and how is so often lacking.

I happen to like svnmerge, because one developer (a VC specialist, if 
you will) can set up the branching and merge tracking and all anyone 
else needs to know is "svnmerge.py merge", if they care about merging at 
all.  It always feels like using the DVCS tools that everyone is forced 
to know the topology of the project just to do anything with it -- 
that's a matter of style more than the tool, but DVCS do seem to 
encourage a more spaghetti-branched approach from what I've seen.

Mike

John Hunter wrote:
>
>
> On Wed, Dec 10, 2008 at 5:43 PM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     Hmm... Seems Thunderbird butchered my long URLs.
>
>     Anyway, the problem is worse than I thought.  Since the branch was
>     created from trunk/ to branches/v0_98_4_maint/, svnmerge.py will
>     only merge from one of those to the other.  What we really want to
>     be able to do is merge from branches/v0_98_4_maint/matplotlib to
>     trunk/matplotlib (i.e. source tree to source tree, not from the
>     whole matplotlib universe to another), so the branch must be
>     created in the same way.  svnmerge does its magic by going back to
>     find how the branch was created, and if the merging doesn't match
>     the branch operation, it basically can't do anything.  Hope that
>     description makes sense.
>
>     This means, presently, in order to do a merge, one has to check
>     out the whole kit-and-caboodle with htdocs, py4science etc., and
>     not just the matplotlib source tree.
>
>     I would suggest fixing this creating a new branch just from the
>     source tree, and setting up merging from that to the trunk source
>     tree, and then retiring or deleting the current v0_98_4_maint
>     branch (if that's possible).
>
>
> Yes, this was just a screwup on my part when I made the branch; be 
> gentle, it was my first time.  I agree with your suggestion of just 
> deleting the branch and starting over. 
No worries.  These things can be hopelessly fiddly.
>
> Unfortunately, there is  a critical bug reported on the users list 
> where is GTKAgg is installed as the default backend on the windows 
> installer (I confirmed this for the win 2.5 win32 egg and assume the 
> problem is in the other win binaries too).  Charlie, did you perhaps 
> forget to set the tkagg backend in the setup.cfg config for the 
> windows installer (and make sure the configobj and traits are turned 
> off as Darren mentioned in another thread)?   I have deleted the win32 
> files from the sf release page. 
>
> Given that the win32 binaries have to be fixed ASAP and that the 
> branch is fubar, it may be in everyone's best interest to simply start 
> over.
> I've added Michael's font_manager and Jae-Joon's figure/subplot fixes 
> to the trunk at r6559 and bumped the version number to 0.98.5rc.  I 
> did another round of testing with these changes (including a nose test 
> for Jae-Joon's problem!) so Charlie if you have time to do another set 
> of binaries we can kill all these birds with one stone an just release 
> 0.98.5 (if you go this route, just remove the rc from the version num 
> and bump to 0.98.5)
>
> Or Charlie, if you do not have time for this in the next 24 hours, but 
> do have time to upload new win32 binaries from your existing build 
> dirs with the backend fixed, that is fine too and we can push out a 
> bug fix release with these other non-critical changes next week.  If 
> you decide to go this route, you should know that I may have 
> accidentally deleted the python 2.4 os x egg when deleting the win32 
> binaries,  because if there was one there isn't one there now :-(
>
> And if your new baby is requiring some attention and you don't have 
> time for either of these, let me know and I will simply hide the 98.4 
> release until we sort this out.
>
> And I'll try and get the maintenance branch right next time :-) 
All of the above sounds good to me.

Mike

On Wed, Dec 10, 2008 at 11:10 PM, John Hunter <jd...@gm...> wrote:

>
>
> On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <dsd...@gm...> wrote:
>
>> There has been a report at the bugtracker complaining that matplotlib is
>> overwriting an existing installation of configobj. I had a look at the code
>> and thought the bug report must be a mistake or windows specific, but I just
>> saw similar behavior on my linux system.
>
>
> Ignoring for a minute the question of whether we can/should flush
> configobj/traits, it sounds like the real problem is that setup.cfg is not
> working like we expect it to.  And that is something that should be fixed if
> is broken.  If mpl is installing configobj or traits even if we are telling
> it not to via setup.cfg, then we have a problem.   This is worth knowing,
> since the last mpl release was broken vis-a-vis the default backend on
> win32, which *could* be explained by a broken setup.cfg.
>

I think I figured this our in my sleep last night. I dont think setup.cfg or
setupext.py is broken. Here is what happened:

I have a new system and I want to build mpl. I run setup.py build, with no
setup.cfg, and setupext.py tells me that I dont have configobj and mpl is
going to provide it. That's not what I want, I would rather install it with
kubuntu's package manager, so I do. Now I run setup.py build again and mpl
tells me that it found the configobj I installed with apt-get. Great, so I
run setup.py install and, wait for it, mpl installs its own configobj,
overwriting the one I just installed, because I forgot to delete my build/
which contained a configobj from the first time I ran setup.py build.

This can probably bite us when building the windows installers too,
hopefully Charlie is deletes his build as part of the standard procedure.


I would like to simply remove configobj and traits from our repository. They
>> are only used by the long-neglected experimental traited config package,
>> which is only of interest to developers who can easily install them as
>> external dependencies. Is it ok to remove them? If so, should it be done on
>> all the branches?
>>
>> How long are we going to continue to maintain the different branches? It
>> was so much easier back when we only had to worry about the trunk...
>>
>
> You can remove them from the trunk.  They should remain on the 0.91 branch
> as is (with any known bugs fixed and merged) since that is the point of the
> branch (stability for those who cannot upgrade -- in principle someone might
> be depending on the traited config, in practice unlikely).  As for the 0.98
> branch, it is slated for destruction so no worries.  I share your visceral
> reaction against branches, but my head is starting to override this bodily
> reaction, as I see the need for them in practice.  If we carefully document
> the best practices and motivations in the developerr's guide, we can use
> them advantageously.
>

At least we have a nice overview of the procedure in the developers guide.
Thanks for that.

I will remove these from the trunk, but I might not get to it until this
afternoon or evening. I have something pressing this morning at work.

>
> We have a lot of people contributing to mpl, and approaching or just after
> release time we need some mechanism for stabilizing the tested feature set
> of the release candidate while allowing other development to proceed, and
> branches are the natural mechanism for that.  That we are starting to use
> them is a reflection of the fact that we have many more active developers
> than we ever had before (12 developers contributed between 98.3 and 98.4, it
> used to be just 3 or 4 at a time).   I wouldn't be advocating branches
> otherwise, because I am an advocate of doing things as simply as possible: "Make
> everything as simple as possible, but not simpler.".
>

Having worked with bzr and launchpad for a few months now, I wonder if we
might consider such an approach in the future. I know there has been some
experimentation with a git repository, is git supported on windows now?

> sudo easy_install -U matplotlib
Searching for matplotlib
Reading http://pypi.python.org/simple/matplotlib/
Reading http://matplotlib.sourceforge.net
Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
Reading https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
Reading http://sourceforge.net/project/showfiles.php?group_id=80706
Best match: matplotlib 0.98.4
Downloading http://downloads.sourceforge.net/matplotlib/matplotlib-0.98.4.tar.gz?modtime=1228859358&big_mirror=0
Processing matplotlib-0.98.4.tar.gz
Running matplotlib-0.98.4/setup.py -q bdist_egg --dist-dir /tmp/easy_install-nLdSJf/matplotlib-0.98.4/egg-dist-tmp-n2Ro0u
============================================================================
BUILDING MATPLOTLIB
            matplotlib: 0.98.4
                python: 2.5.2 (r252:60911, Sep 30 2008, 15:42:03)  [GCC
                        4.3.2 20080917 (Red Hat 4.3.2-4)]
              platform: linux2

REQUIRED DEPENDENCIES
                 numpy: 1.2.0
             freetype2: 9.18.3

OPTIONAL BACKEND DEPENDENCIES
                libpng: 1.2.33
               Tkinter: Tkinter: 50704, Tk: 8.5, Tcl: 8.5
                        * Guessing the library and include directories for
                        * Tcl and Tk because the tclConfig.sh and
                        * tkConfig.sh could not be found and/or parsed.
              wxPython: 2.8.9.1
                        * WxAgg extension not required for wxPython >= 2.8
                  Gtk+: gtk+: 2.14.4, glib: 2.18.3, pygtk: 2.13.0,
                        pygobject: 2.15.4
       Mac OS X native: no
                    Qt: Qt: 3.3.8, PyQt: 3.17.4
                   Qt4: Qt: 4.4.1, PyQt4: 4.4.3
                 Cairo: 1.4.12

OPTIONAL DATE/TIMEZONE DEPENDENCIES
              datetime: present, version unknown
              dateutil: 1.4
                  pytz: 2006p

OPTIONAL USETEX DEPENDENCIES
                dvipng: 1.11
           ghostscript: 8.63
                 latex: 3.141592

EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
             configobj: 4.5.2
      enthought.traits: no

[Edit setup.cfg to suppress the above messages]
============================================================================
error: lib/matplotlib/mpl-data/matplotlib.conf.template: No such file or directory
Exception exceptions.OSError: (2, 'No such file or directory', 'src/image.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x2fae1b8>> ignored
Exception exceptions.OSError: (2, 'No such file or directory', 'src/path.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x2fac638>> ignored
Exception exceptions.OSError: (2, 'No such file or directory', 'src/backend_gdk.c') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x31e27a0>> ignored
Exception exceptions.OSError: (2, 'No such file or directory', 'src/backend_agg.cpp') in <bound method CleanUpFile.__del__ of <setupext.CleanUpFile instance at 0x2facfc8>> ignored

On Thu, 11 Dec 2008 09:13:02 +0100
  "Nils Wagner" <nw...@ia...> wrote:
> On Wed, 10 Dec 2008 21:11:12 -0600
>  "John Hunter" <jd...@gm...> wrote:
>> On Wed, Dec 10, 2008 at 4:26 PM, John Hunter 
>><jd...@gm...> wrote:
>> 
>>>
>>>> Is it planned to adapt the example wrt xlwt ?
>>>>
>>>> http://pypi.python.org/pypi/xlwt
>>>>
>>>
>>>
>>> True it is no longer maintained, but it does work.  We 
>>>are looking into
>>> xlwt (I wasn't aware of it until today when you 
>>>forwarded the message)
>>>
>> 
>> I've added support for xlwt in svn r6560  -- give it a 
>>whirl
>> 
>> JDH
> 
> Hi John,
> 
> I have upgraded to r6561.
> 
> python test.py --verbose-helpful
> $HOME=/data/home/nwagner
> CONFIGDIR=/data/home/nwagner/.matplotlib
> matplotlib data path 
> /data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mpl-data
> loaded rc file 
>/data/home/nwagner/.matplotlib/matplotlibrc
> Traceback (most recent call last):
>   File "test.py", line 1, in <module>
>     import matplotlib.mlab as mlab
>   File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
> line 700, in <module>
>     rcParams['text.usetex'] = 
> checkdep_usetex(rcParams['text.usetex'])
>   File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
> line 367, in checkdep_usetex
>     dvipng_v = checkdep_dvipng()
>   File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
> line 261, in checkdep_dvipng
>     stderr=subprocess.PIPE)
>   File 
> "/data/home/nwagner/local/lib/python2.5/subprocess.py", 
> line 593, in __init__
>     errread, errwrite)
>   File 
> "/data/home/nwagner/local/lib/python2.5/subprocess.py", 
> line 1079, in _execute_child
>     raise child_exception
> OSError: [Errno 2] No such file or directory
>  
> 
> Any idea ?
> 
>             Nils
> 
  
Works for me if I disable text.usetex in 
~/.matplotlib/matplotlibrc, but for what reason ?


### LaTeX customizations. See 
http://www.scipy.org/Wiki/Cookbook/Matplotlib/UsingTex
#text.usetex         : True   # use latex for all text 
handling. The following fonts

Nils

On Wed, 10 Dec 2008 21:11:12 -0600
  "John Hunter" <jd...@gm...> wrote:
> On Wed, Dec 10, 2008 at 4:26 PM, John Hunter 
><jd...@gm...> wrote:
> 
>>
>>> Is it planned to adapt the example wrt xlwt ?
>>>
>>> http://pypi.python.org/pypi/xlwt
>>>
>>
>>
>> True it is no longer maintained, but it does work.  We 
>>are looking into
>> xlwt (I wasn't aware of it until today when you 
>>forwarded the message)
>>
> 
> I've added support for xlwt in svn r6560  -- give it a 
>whirl
> 
> JDH

Hi John,

I have upgraded to r6561.

python test.py --verbose-helpful
$HOME=/data/home/nwagner
CONFIGDIR=/data/home/nwagner/.matplotlib
matplotlib data path 
/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mpl-data
loaded rc file /data/home/nwagner/.matplotlib/matplotlibrc
Traceback (most recent call last):
   File "test.py", line 1, in <module>
     import matplotlib.mlab as mlab
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
line 700, in <module>
     rcParams['text.usetex'] = 
checkdep_usetex(rcParams['text.usetex'])
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
line 367, in checkdep_usetex
     dvipng_v = checkdep_dvipng()
   File 
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/__init__.py", 
line 261, in checkdep_dvipng
     stderr=subprocess.PIPE)
   File 
"/data/home/nwagner/local/lib/python2.5/subprocess.py", 
line 593, in __init__
     errread, errwrite)
   File 
"/data/home/nwagner/local/lib/python2.5/subprocess.py", 
line 1079, in _execute_child
     raise child_exception
OSError: [Errno 2] No such file or directory
  

Any idea ?

             Nils

On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <dsd...@gm...> wrote:

> There has been a report at the bugtracker complaining that matplotlib is
> overwriting an existing installation of configobj. I had a look at the code
> and thought the bug report must be a mistake or windows specific, but I just
> saw similar behavior on my linux system.


Ignoring for a minute the question of whether we can/should flush
configobj/traits, it sounds like the real problem is that setup.cfg is not
working like we expect it to.  And that is something that should be fixed if
is broken.  If mpl is installing configobj or traits even if we are telling
it not to via setup.cfg, then we have a problem.   This is worth knowing,
since the last mpl release was broken vis-a-vis the default backend on
win32, which *could* be explained by a broken setup.cfg.


I would like to simply remove configobj and traits from our repository. They
> are only used by the long-neglected experimental traited config package,
> which is only of interest to developers who can easily install them as
> external dependencies. Is it ok to remove them? If so, should it be done on
> all the branches?
>
> How long are we going to continue to maintain the different branches? It
> was so much easier back when we only had to worry about the trunk...
>

You can remove them from the trunk.  They should remain on the 0.91 branch
as is (with any known bugs fixed and merged) since that is the point of the
branch (stability for those who cannot upgrade -- in principle someone might
be depending on the traited config, in practice unlikely).  As for the 0.98
branch, it is slated for destruction so no worries.  I share your visceral
reaction against branches, but my head is starting to override this bodily
reaction, as I see the need for them in practice.  If we carefully document
the best practices and motivations in the developerr's guide, we can use
them advantageously.

We have a lot of people contributing to mpl, and approaching or just after
release time we need some mechanism for stabilizing the tested feature set
of the release candidate while allowing other development to proceed, and
branches are the natural mechanism for that.  That we are starting to use
them is a reflection of the fact that we have many more active developers
than we ever had before (12 developers contributed between 98.3 and 98.4, it
used to be just 3 or 4 at a time).   I wouldn't be advocating branches
otherwise, because I am an advocate of doing things as simply as
possible: "Make
everything as simple as possible, but not simpler.".

In general, I am in favor of the wildest, wooliest, development process we
can afford.  I would like to have  everyone on the trunk, making releases as
often as possible (nightly if we can), with an attitude of "if you break it,
just fix it an rerelease it".  This model worked fine for us for years, and
I think it would continue to work if we have a hyper-active developer or an
automated build bot.  In the old days, I would release any time I added a
new feaure, and if I broke something I would have a new release out in
hours.  I no longer have the time for that, and  we are lucky to have
Charlie buildng OS X and win32 binaties and eggs for multiple python
versions.  When we release broken code, Charlie has to go through the entire
test/upload/release cycle again, building for multiple OSs and python
versions while taking care of his wife and two babies, so we want to
minimize that.  At the same time, we have lots of developers pushing code
into the mainline.  We need some mechanism of balancing the desire of
developers to get new code in and the need for the packagers and release
manangers to get stable code out.

I think the right balance for mpl before a release is to test the HEAD, sign
off on it, branch it, let development proceed on the HEAD, and put any
release critical bugs and fixes into the branch.  When the next release
comes up, delete the old branch, and wash-rinse-repeat.  We will have in
perpetuity one active release branch at a time, which gets important bug
fixes and nothing else, and in addition (for a while) a legacy branch (0.91)
which is updated once a month or so.  I am happy to get input on this.

JDH

There has been a report at the bugtracker complaining that matplotlib is
overwriting an existing installation of configobj. I had a look at the code
and thought the bug report must be a mistake or windows specific, but I just
saw similar behavior on my linux system.

I would like to simply remove configobj and traits from our repository. They
are only used by the long-neglected experimental traited config package,
which is only of interest to developers who can easily install them as
external dependencies. Is it ok to remove them? If so, should it be done on
all the branches?

How long are we going to continue to maintain the different branches? It was
so much easier back when we only had to worry about the trunk...

Thanks,
Darren

On Wed, Dec 10, 2008 at 4:26 PM, John Hunter <jd...@gm...> wrote:

>
>> Is it planned to adapt the example wrt xlwt ?
>>
>> http://pypi.python.org/pypi/xlwt
>>
>
>
> True it is no longer maintained, but it does work.  We are looking into
> xlwt (I wasn't aware of it until today when you forwarded the message)
>

I've added support for xlwt in svn r6560  -- give it a whirl

JDH

In response to a question on matplotlib-users, I added some additional
documentation for the linestyles and markers in the matplotlib.lines API
docs.  Specifically, I added a rest table mapping the linestyle/marker to
the meaning of the marker.  Strangely, the set_linestyle table renders fine


http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_linestyle

but the table in set_marker is absent


http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_marker

I've tried cleanly building and installing mpl in my src tree, running
svn-clean to make sure no cruft is impacting me, but I have not succeeeded
in getting the marker table to render.  Perhaps a fresh set of eyeballs can
spot the problem.  I'm pasting the docstrings below::

    def set_linestyle(self, linestyle):

"""

        Set the linestyle of the line (also accepts
drawstyles)




        ================
=================
        linestyle
description
        ================
=================
        '-'
solid
        '--'
dashed
        '-.'
dash_dot
        ':'
dotted
        'None'              draw
nothing
        ' '                 draw
nothing
        ''                  draw
nothing
        ================    =================



        ..
seealso::

:meth:`set_drawstyle`


        ACCEPTS: [ '-' | '--' | '-.' | ':' | 'None' | ' ' | '' ]
and
        any drawstyle in combination with a linestyle, e.g.
'steps--'.
        """

And here is set_marker docstring::

    def set_marker(self, marker):
        """
        Set the line marker

        =========  ==========================
        marker     description
        =========  ==========================
        '.'        point
        ','        pixel
        'o'        circle
        'v'        triangle_down
        '^'        triangle_up
        '<'        triangle_left
        '>'        triangle_right
        '1'        tri_down
        '2'        tri_up
        '3'        tri_left
        '4'        tri_right
        's'        square
        'p'        pentagon
        '*'        star
        'h'        hexagon1
        'H'        hexagon2
        '+'        plus
        'x'        x
        'D'        diamond
        'd'        thin_diamond
        '|'        vline
        '_'        hline
        TICKLEFT   tickleft
        TICKRIGHT  tickright
        TICKUP     tickup
        TICKDOWN   tickdown
        CARETLEFT  caretleft
        CARETRIGHT caretright
        CARETUP    caretup
        CARETDOWN  caretdown
        'None'     nothing
        ' '        nothing
        ''         nothing
        =========  ==========================


        ACCEPTS: [ '+' | '*' | ',' | '.' | '1' | '2' | '3' | '4'
                 | '<' | '>' | 'D' | 'H' | '^' | '_' | 'd'
                 | 'h' | 'o' | 'p' | 's' | 'v' | 'x' | '|'
                 | TICKUP | TICKDOWN | TICKLEFT | TICKRIGHT
                 | 'None' | ' ' | '' ]

        """

On Wed, Dec 10, 2008 at 5:43 PM, Michael Droettboom <md...@st...> wrote:

> Hmm... Seems Thunderbird butchered my long URLs.
>
> Anyway, the problem is worse than I thought.  Since the branch was created
> from trunk/ to branches/v0_98_4_maint/, svnmerge.py will only merge from one
> of those to the other.  What we really want to be able to do is merge from
> branches/v0_98_4_maint/matplotlib to trunk/matplotlib (i.e. source tree to
> source tree, not from the whole matplotlib universe to another), so the
> branch must be created in the same way.  svnmerge does its magic by going
> back to find how the branch was created, and if the merging doesn't match
> the branch operation, it basically can't do anything.  Hope that description
> makes sense.
>
> This means, presently, in order to do a merge, one has to check out the
> whole kit-and-caboodle with htdocs, py4science etc., and not just the
> matplotlib source tree.
>
> I would suggest fixing this creating a new branch just from the source
> tree, and setting up merging from that to the trunk source tree, and then
> retiring or deleting the current v0_98_4_maint branch (if that's possible).


Yes, this was just a screwup on my part when I made the branch; be gentle,
it was my first time.  I agree with your suggestion of just deleting the
branch and starting over.

Unfortunately, there is  a critical bug reported on the users list where is
GTKAgg is installed as the default backend on the windows installer (I
confirmed this for the win 2.5 win32 egg and assume the problem is in the
other win binaries too).  Charlie, did you perhaps forget to set the tkagg
backend in the setup.cfg config for the windows installer (and make sure the
configobj and traits are turned off as Darren mentioned in another
thread)?   I have deleted the win32 files from the sf release page.

Given that the win32 binaries have to be fixed ASAP and that the branch is
fubar, it may be in everyone's best interest to simply start over.
I've added Michael's font_manager and Jae-Joon's figure/subplot fixes to the
trunk at r6559 and bumped the version number to 0.98.5rc.  I did another
round of testing with these changes (including a nose test for Jae-Joon's
problem!) so Charlie if you have time to do another set of binaries we can
kill all these birds with one stone an just release 0.98.5 (if you go this
route, just remove the rc from the version num and bump to 0.98.5)

Or Charlie, if you do not have time for this in the next 24 hours, but do
have time to upload new win32 binaries from your existing build dirs with
the backend fixed, that is fine too and we can push out a bug fix release
with these other non-critical changes next week.  If you decide to go this
route, you should know that I may have accidentally deleted the python 2.4
os x egg when deleting the win32 binaries,  because if there was one there
isn't one there now :-(

And if your new baby is requiring some attention and you don't have time for
either of these, let me know and I will simply hide the 98.4 release until
we sort this out.

And I'll try and get the maintenance branch right next time :-)