matplotlib-devel Mailing List for matplotlib

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/ 
> <https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/%5C>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/ 
> <https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/%5C>v0_98_4_maint/matplotlib 
> mpl98.4
>
> Cheers,
> Mike
>
> John Hunter wrote:
>   
>> On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <md...@st... 
>> <mailto:md...@st...>> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

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

https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/ 
<https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/%5C>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/ 
<https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/%5C>v0_98_4_maint/matplotlib 
mpl98.4

Cheers,
Mike

John Hunter wrote:
>
> On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> 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

On Wed, Dec 10, 2008 at 3:28 PM, Nils Wagner
<nw...@ia...>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

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
  

On Wed, Dec 10, 2008 at 11:30 AM, Michael Droettboom <md...@st...>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

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/\ 
> <https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/%5C>
>    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

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

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

    Added support for data with units (e.g. dates) to
    Axes.fill_between. -RM

    Added fancybox keyword to legend. Also applied some changes for
    better look, including baseline adjustment of the multiline texts
    so that it is center aligned. -JJL

    The transmuter classes in the patches.py are reorganized as
    subclasses of the Style classes. A few more box and arrow styles
    are added. -JJL

    Fixed a bug in the new legend class that didn't allowed a tuple of
    coordinate vlaues as loc. -JJL

    Improve checks for external dependencies, using subprocess
    (instead of deprecated popen*) and distutils (for version
    checking) - DSD

    Reimplementaion of the legend which supports baseline alignement,
    multi-column, and expand mode. - JJL

    Fixed histogram autoscaling bug when bins or range are given
    explicitly (fixes Debian bug 503148) - MM

    Added rcParam axes.unicode_minus which allows plain hypen for
    minus when False - JDH

    Added scatterpoints support in Legend. patch by Erik Tollerud -
    JJL

    Fix crash in log ticking. - MGD

    Added static helper method BrokenHBarCollection.span_where and
    Axes/pyplot method fill_between.  See
    examples/pylab/fill_between.py - JDH

    Add x_isdata and y_isdata attributes to Artist instances, and use
    them to determine whether either or both coordinates are used when
    updating dataLim.  This is used to fix autoscaling problems that
    had been triggered by axhline, axhspan, axvline, axvspan. - EF

    Update the psd(), csd(), cohere(), and specgram() methods of Axes
    and the csd() cohere(), and specgram() functions in mlab to be in
    sync with the changes to psd().  In fact, under the hood, these
    all call the same core to do computations. - RM

    Add 'pad_to' and 'sides' parameters to mlab.psd() to allow
    controlling of zero padding and returning of negative frequency
    components, respecitively.  These are added in a way that does not
    change the API. - RM

    Fix handling of c kwarg by scatter; generalize is_string_like to
    accept numpy and numpy.ma string array scalars. - RM and EF

    Fix a possible EINTR problem in dviread, which might help when
    saving pdf files from the qt backend. - JKS

    Fix bug with zoom to rectangle and twin axes - MGD

    Added Jae Joon's fancy arrow, box and annotation enhancements --
    see examples/pylab_examples/annotation_demo2.py

    Autoscaling is now supported with shared axes - EF

    Fixed exception in dviread that happened with Minion - JKS

    set_xlim, ylim now return a copy of the viewlim array to avoid
    modify inplace surprises

    Added image thumbnail generating function
    matplotlib.image.thumbnail.  See examples/misc/image_thumbnail.py
    - JDH

    Applied scatleg patch based on ideas and work by Erik Tollerud and
    Jae-Joon Lee. - MM

    Fixed bug in pdf backend: if you pass a file object for output
    instead of a filename, e.g. in a wep app, we now flush the object
    at the end. - JKS

    Add path simplification support to paths with gaps. - EF

    Fix problem with AFM files that don't specify the font's full name
    or family name. - JKS

    Added 'scilimits' kwarg to Axes.ticklabel_format() method, for
    easy access to the set_powerlimits method of the major
    ScalarFormatter. - EF

    Experimental new kwarg borderpad to replace pad in legend, based
    on suggestion by Jae-Joon Lee.  - EF

    Allow spy to ignore zero values in sparse arrays, based on patch
    by Tony Yu.  Also fixed plot to handle empty data arrays, and
    fixed handling of markers in figlegend. - EF

    Introduce drawstyles for lines. Transparently split linestyles
    like 'steps--' into drawstyle 'steps' and linestyle '--'.  Legends
    always use drawstyle 'default'. - MM

    Fixed quiver and quiverkey bugs (failure to scale properly when
    resizing) and added additional methods for determining the arrow
    angles - EF

    Fix polar interpolation to handle negative values of theta - MGD

    Reorganized cbook and mlab methods related to numerical
    calculations that have little to do with the goals of those two
    modules into a separate module numerical_methods.py Also, added
    ability to select points and stop point selection with keyboard in
    ginput and manual contour labeling code.  Finally, fixed contour
    labeling bug. - DMK

    Fix backtick in Postscript output. - MGD

    [ 2089958 ] Path simplification for vector output backends
    Leverage the simplification code exposed through path_to_polygons
    to simplify certain well-behaved paths in the vector backends
    (PDF, PS and SVG).  "path.simplify" must be set to True in
    matplotlibrc for this to work.  - MGD

    Add "filled" kwarg to Path.intersects_path and
    Path.intersects_bbox. - MGD

    Changed full arrows slightly to avoid an xpdf rendering problem
    reported by Friedrich Hagedorn. - JKS

    Fix conversion of quadratic to cubic Bezier curves in PDF and PS
    backends. Patch by Jae-Joon Lee. - JKS

    Added 5-point star marker to plot command q- EF

    Fix hatching in PS backend - MGD

    Fix log with base 2 - MGD

    Added support for bilinear interpolation in
    NonUniformImage; patch by Gregory Lielens. - EF

    Added support for multiple histograms with data of
    different length - MM

    Fix step plots with log scale - MGD

    Fix masked arrays with markers in non-Agg backends - MGD

    Fix clip_on kwarg so it actually works correctly - MGD

    Fix locale problems in SVG backend - MGD

    fix quiver so masked values are not plotted - JSW

    improve interactive pan/zoom in qt4 backend on windows - DSD

    Fix more bugs in NaN/inf handling.  In particular, path
    simplification (which does not handle NaNs or infs) will be turned
    off automatically when infs or NaNs are present.  Also masked
    arrays are now converted to arrays with NaNs for consistent
    handling of masks and NaNs - MGD and EF

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

On Wed, Dec 10, 2008 at 12:36 AM, Jae-Joon Lee <lee...@gm...> 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

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


import matplotlib.pyplot as plt
import matplotlib.axes as maxes

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



/Users/jjlee/.virtualenvs/default/lib/python2.5/site-packages/matplotlib/figure.pyc
in add_subplot(self, *args, **kwargs)
    687                 self._axstack.remove(ax)
    688
--> 689         a = subplot_class_factory(projection_class)(self,
*args, **kwargs)
    690         self.axes.append(a)
    691         self._axstack.push(a)

UnboundLocalError: local variable 'projection_class' referenced before
assignment


It seems that some of the code Mike recently introduced in "figure.py"
have incorrect indentation, but I'm not 100% sure.
I'm attaching a patch which seems to work for me, and It would be
great if Mike or others review it and apply.

-JJ