Re: [matplotlib-devel] error in add_subplot

[John Hunter]

On Wed, Dec 10, 2008 at 12:36 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:

> Current SVN (r6540) raise an error for the following code.



Arg, bad timing.  Charlie released 0.98.4 hours before you found this.
Fortunately, the use case,

fig = plt.figure()
ax = maxes.Subplot(fig, 1, 1, 1)
fig.add_subplot(ax)

is pretty rare, since most use the fig.add_subplot(111) construction.In
fact, we didn't catch this because none of the examples use it in
backend_driver.

I just added a units/notes_tests.py with this example added to it.  Please
add other regression tests here as you develop.

JDH
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] 98.4 maintenance branch

[John Hunter]

Since we already have a bug in the 98.4 release, we can anticipate needing
to do a bugfix release accumulating all the bugs we fix in the next week
(presuming we don't discover any critical bugs which would require us to
push out a fix earlier).  To make sure we achieve maximal stability, I have
created a 98.4 maintenance branch which should only get bugfixes.  All other
development can proceed apace on the trunk.

   svn co
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/\
   v0_98_4_maint mpl98.4 --username=youruser --password=yourpass

Mike, can you advise on the procedure for doing merges from the new branch
to the trunk.  In particular, what I am confused about is how to inform
svn-merge that I want to merge from 98.4 branch and not 91.4 branch.

JDH
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] ANN: matplotlib-0.98.4

[John Hunter]

We have just released a new version of matplotlib, available for download at


https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646146

These "what's new" release notes, with graphs and links, are available in
html at

  http://matplotlib.sourceforge.net/users/whats_new.html

Thanks to Charlie Moad for testing and preparing the source release,
including binaries for OS X and Windows for python 2.4 and 2.5 (2.6
and 3.0 will not be available until numpy is available on those
releases).  Thanks to the many developers who contributed to this
release, with contributions from Jae-Joon Lee, Michael Droettboom,
Ryan May, Eric Firing, Manuel Metz, Jouni K. Seppaenen, Jeff Whitaker,
Darren Dale, David Kaplan, Michiel de Hoon and many others who
submitted patches


What new in 0.98.4
==

It's been four months since the last matplotlib release, and there are
a lot of new features and bug-fixes

Legend enhancements


Jae-Joon has rewritten the legend class, and added support for
multiple columns and rows, as well as fancy box drawing.  See


http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.legend

http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.legend.Legend

http://matplotlib.sourceforge.net/examples/pylab_examples/legend_demo3.html


Fancy annotations and arrows
-

Jae-Joon has added lot's of support to annotations for drawing fancy
boxes and connectors in annotations.  See



http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.annotate

http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.patches.BoxStyle

http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.patches.ArrowStyle

http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.patches.ConnectionStyle

http://matplotlib.sourceforge.net/examples/pylab_examples/annotation_demo2.html


Native OS X backend


Michiel de Hoon has provided a native Mac OSX backend that is almost
completely implemented in C. The backend can therefore use Quartz
directly and, depending on the application, can be orders of magnitude
faster than the existing backends. In addition, no third-party
libraries are needed other than Python and NumPy. The backend is
interactive from the usual terminal application on Mac using regular
Python. It hasn't been tested with ipython yet, but in principle it
should to work there as well.  Set 'backend : macosx' in your
matplotlibrc file, or run your script with::

> python myfile.py -dmacosx

psd amplitude scaling
-

Ryan May did a lot of work to rationalize the amplitude scaling of
:func:`~matplotlib.pyplot.psd` and friends.  The changes should
increase MATLAB (TM) compatabililty and increase scaling options.


http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.psd

http://matplotlib.sourceforge.net/examples/pylab_examples/psd_demo2.html#pylab-examples-psd-demo2

http://matplotlib.sourceforge.net/examples/pylab_examples/psd_demo3.html#pylab-examples-psd-demo3

Fill between
--

Added a fill_between function to make it easier to do shaded region
plots in the presence of masked data.  You can pass an *x* array and a
*ylower* and *yupper* array to fill betweem, and an optional *where*
argument which is a logical mask where you want to do the filling. See


http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.fill_between

http://matplotlib.sourceforge.net/examples/pylab_examples/fill_between.html


Lots more
---

Here are the 0.98.4 notes from the CHANGELOG::

Added mdehoon's native macosx backend from sf patch 2179017 - JDH

Removed the prints in the set_*style commands.  Return the list of
pprinted strings instead - JDH

Some of the changes Michael made to improve the output of the
property tables in the rest docs broke of made difficult to use
some of the interactive doc helpers, eg setp and getp.  Having all
the rest markup in the ipython shell also confused the docstrings.
I added a new rc param docstring.harcopy, to format the docstrings
differently for hardcopy and other use.  Ther ArtistInspector
could use a little refactoring now since there is duplication of
effort between the rest out put and the non-rest output - JDH

Updated spectral methods (psd, csd, etc.) to scale one-sided
densities by a factor of 2 and, optionally, scale all densities by
the sampling frequency.  This gives better MatLab
compatibility. -RM

Fixed alignment of ticks in colorbars. -MGD

drop the deprecated "new" keyword of np.histogram() for numpy 1.2
or later.  -JJL

Fixed a bug in svg backend that new_figure_manager() ignores
keywords arguments such as figsize, etc. -JJL

Fixed a bug that the handlelength of the new legend class set too
short when numpoints=1 -JJL

A

[matplotlib-devel] TextCollection

[Ryan May]

Hi,

I was going to try to start working on a TextCollection class (finally!), and I 
thought it might be good to discuss some of it here before I get too far along.

Motivations:
  *Speed up and simplify drawing of multiple text objects with common properties
by reusing a single graphics context while drawing

  *Useful for doing plots using the text representation of values (think of a
scatter plot with numbers instead of markers). This is my particular
use case.

  *Useful for handling tick labels

Current thoughts:
  - TextCollection will draw multiple strings (at multiple locations) with a
common FontProperties(), rotation, linespacing, and alignment.

  - TextCollection will inherit from Text so that all of the 
getting/setting of  these common properties is gotten "for 
free".  What about 
all of the new
Fancy bbox support of text? Do we handle this in text collection as 
well?

  - Should TextCollection also inherit from ScalarMappable so that we can 
colormap
text values?  On one hand this sounds nice and would be similar to the
other collections.  On the other, I can see this making for a difficult
to understand plot.  My feeling is that if there's no technical reason
not to add a feature, give the user the power (to shoot themselves in 
the
foot).

  - Create a new Axes method `text_plot()` (anyone got a better name?) that 
works
like scatter, based on TextCollection. Takes x,y, and data values, as
well as optional colormapping array.  Also takes a string or function
that controls formatting of text as well as (optional) x0,y0 scalar
offsets (in points/pixels) that control where the text is placed in
relation to the x,y location.  These offsets would, for instance, allow
one to plot city names above the dot marking the location instead of on
top of it.

Any thoughts?  I'm especially interested in any potential pitfalls (like 
inheriting from Text).

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 98.4 maintenance branch

[Michael Droettboom]

John Hunter wrote:
> Since we already have a bug in the 98.4 release, we can anticipate 
> needing to do a bugfix release accumulating all the bugs we fix in the 
> next week (presuming we don't discover any critical bugs which would 
> require us to push out a fix earlier).  To make sure we achieve 
> maximal stability, I have created a 98.4 maintenance branch which 
> should only get bugfixes.  All other development can proceed apace on 
> the trunk.
>
>svn co 
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/\ 
> 
>v0_98_4_maint mpl98.4 --username=youruser --password=yourpass
>
> Mike, can you advise on the procedure for doing merges from the new 
> branch to the trunk.  In particular, what I am confused about is how 
> to inform svn-merge that I want to merge from 98.4 branch and not 91.4 
> branch.
You can add a new branch for the trunk to "track" using "svnmerge.py 
init", e.g., from a working copy of the trunk:

  > svnmerge.py init 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_98_4_maint
 

  property 'svnmerge-integrated' set on '.'

After doing a "svn commit" on this, this merge tracking is available to 
everyone, so there's no need for anyone else to do the "svnmerge init".  
I'll go ahead and commit this now.

Now, the trunk is tracking two branches for merges, 0.91.x and 0.98.4.  
This means that when doing a merge, one must manually specify which 
branch to merge from using the "-S" parameter.  You can see which 
branches are available for merge using "svnmerge.py avail":

 > svnmerge.py avail
svnmerge: multiple sources found. Explicit source argument (-S/--source) 
required.
The merge sources available are:
  /branches/v0_91_maint
  /branches/v0_98_4_maint

So to merge from 0.98.4, one would type:

 > svnmerge.py --source v0_98_4_maint merge

(rather than the "svnmerge.py merge" we used to do).

The tracking for 0.91.x can be removed with the "svnmerge.py uninit" 
command, e.g.:

 > svnmerge.py --source v0_91_maint uninit

This will make merging slightly easier, (since the -S parameter is not 
required), and it is generally good practice in the long run to not keep 
extra branches lying around.  I'm happy to make this change, but thought 
I'd run it by you first -- it means we're effectively abandoning the 
0.91.x series, or at least saying any bugfixes to it will have to be 
manually brought over to 0.98.x.


Mike

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 98.4 maintenance branch

[John Hunter]

On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <[EMAIL PROTECTED]>wrote:

>
> This will make merging slightly easier, (since the -S parameter is not
> required), and it is generally good practice in the long run to not keep
> extra branches lying around.  I'm happy to make this change, but thought I'd
> run it by you first -- it means we're effectively abandoning the 0.91.x
> series, or at least saying any bugfixes to it will have to be manually
> brought over to 0.98.x.
>
>
Thanks for the notes -- I'l incorporate them into the dev guide.

I definitely do not want to abandon the 91 branch.  I expect this branch to
last a while, perhaps a year.  the 98.4 branch is intended to be short
lived, order of a week or two, just to fix critical bugs for this release.
Or better yet, we keep it alive until the next point release, then kill it
and make a new release branch.  That way if we ever need to fix a critical
bug in the latest release, we can go to the branch w/o having all the
testing required on the head.  Since the major incompatibility was between
91 and 98, I anticipate that there are some users with a lot of code (eg an
axes3d dependency) where moving may never be feasible.

JDH
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Status of pylab example loadrec.py

[Nils Wagner]

Hi all,

The example loadrec.py illustrates the usage of 
PyExcelerator.

However it seems PyExcelerator is no longer maintained

Is it planned to adapt the example wrt xlwt ?

http://pypi.python.org/pypi/xlwt

Cheers,
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Status of pylab example loadrec.py

[John Hunter]

On Wed, Dec 10, 2008 at 3:28 PM, Nils Wagner
<[EMAIL PROTECTED]>wrote:

> Hi all,
>
> The example loadrec.py illustrates the usage of
> PyExcelerator.
>
> However it seems PyExcelerator is no longer maintained
>
> 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)

JDH
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 98.4 maintenance branch

[Michael Droettboom]

It looks like there was a slight "oops" making the branch.

https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/ 
v0_98_4_maint

points to one level above the source tree.  See:

http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_98_4_maint/

Was this intentional?

In any case, the svnmerge setup I did this morning is incorrect.  Would 
you like me to fix that, or would you rather remove and recreate the 
branch?  If we don't fix the branch, I would suggest changing the 
instructions for checking out the branch to:

svn co 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/ 
v0_98_4_maint/matplotlib
 
mpl98.4

Cheers,
Mike

John Hunter wrote:
>
> On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <[EMAIL PROTECTED] 
> > wrote:
>
>
> This will make merging slightly easier, (since the -S parameter is
> not required), and it is generally good practice in the long run
> to not keep extra branches lying around.  I'm happy to make this
> change, but thought I'd run it by you first -- it means we're
> effectively abandoning the 0.91.x series, or at least saying any
> bugfixes to it will have to be manually brought over to 0.98.x.
>
>
> Thanks for the notes -- I'l incorporate them into the dev guide.
>
> I definitely do not want to abandon the 91 branch.  I expect this 
> branch to last a while, perhaps a year.  the 98.4 branch is intended 
> to be short lived, order of a week or two, just to fix critical bugs 
> for this release.  Or better yet, we keep it alive until the next 
> point release, then kill it and make a new release branch.  That way 
> if we ever need to fix a critical bug in the latest release, we can go 
> to the branch w/o having all the testing required on the head.  Since 
> the major incompatibility was between 91 and 98, I anticipate that 
> there are some users with a lot of code (eg an axes3d dependency) 
> where moving may never be feasible.
>
> JDH


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 98.4 maintenance branch

[Michael Droettboom]

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

In the meantime, I've removed merge tracking on branches/v0_98_4_maint 
to trunk/matplotlib, since it's broken.

Cheers,
Mike

Michael Droettboom wrote:
> It looks like there was a slight "oops" making the branch.
>
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/ 
> v0_98_4_maint
>
> points to one level above the source tree.  See:
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_98_4_maint/
>
> Was this intentional?
>
> In any case, the svnmerge setup I did this morning is incorrect.  Would 
> you like me to fix that, or would you rather remove and recreate the 
> branch?  If we don't fix the branch, I would suggest changing the 
> instructions for checking out the branch to:
>
> svn co 
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/ 
> v0_98_4_maint/matplotlib
>  
> mpl98.4
>
> Cheers,
> Mike
>
> John Hunter wrote:
>   
>> On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <[EMAIL PROTECTED] 
>> > wrote:
>>
>>
>> This will make merging slightly easier, (since the -S parameter is
>> not required), and it is generally good practice in the long run
>> to not keep extra branches lying around.  I'm happy to make this
>> change, but thought I'd run it by you first -- it means we're
>> effectively abandoning the 0.91.x series, or at least saying any
>> bugfixes to it will have to be manually brought over to 0.98.x.
>>
>>
>> Thanks for the notes -- I'l incorporate them into the dev guide.
>>
>> I definitely do not want to abandon the 91 branch.  I expect this 
>> branch to last a while, perhaps a year.  the 98.4 branch is intended 
>> to be short lived, order of a week or two, just to fix critical bugs 
>> for this release.  Or better yet, we keep it alive until the next 
>> point release, then kill it and make a new release branch.  That way 
>> if we ever need to fix a critical bug in the latest release, we can go 
>> to the branch w/o having all the testing required on the head.  Since 
>> the major incompatibility was between 91 and 98, I anticipate that 
>> there are some users with a lot of code (eg an axes3d dependency) 
>> where moving may never be feasible.
>>
>> JDH
>> 
>
>
> --
> 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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   


--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 98.4 maintenance branch

[John Hunter]

On Wed, Dec 10, 2008 at 5:43 PM, Michael Droettboom <[EMAIL PROTECTED]> 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 :-)
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] rest table in matplotlib.lines.Line2D.set_marker

[John Hunter]

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
CARETUPcaretup
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Status of pylab example loadrec.py

[John Hunter]

On Wed, Dec 10, 2008 at 4:26 PM, John Hunter <[EMAIL PROTECTED]> 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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] requesting permission to remove traits and configobj

[Darren Dale]

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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] requesting permission to remove traits and configobj

[John Hunter]

On Wed, Dec 10, 2008 at 9:20 PM, Darren Dale <[EMAIL PROTECTED]> 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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel