matplotlib-devel Mailing List for matplotlib

a doughnut to the developer who can figure this one out for me!
If you resize the figure window slightly, the alpha channel gets
whacked on the rectangles. This only happens if the legend is added
to the axes -- comment that out and the alpha channel is fine. I
suspect we are screwing up somewhere in the way we copy properties
from legended objects to their legend proxies (ie we are reversing
this somewhere and copying properties from a proxy to the axes
The problem is in svn and probably earlier releases but I haven't tested.
from pylab import figure, show, cm, nx
from matplotlib.patches import Rectangle
fig = figure()
ax = fig.add_subplot(111, axisbelow=True)
ax.grid(True)
ax.plot([1,2,3,4,5,6,7])
ax.axvspan(1,2, facecolor='red', alpha=0.5)
ax.axvspan(3,4, facecolor='green', alpha=0.5)
red = Rectangle((0,0), 1, 1, facecolor='red', alpha=0.5)
green = Rectangle((0,0), 1, 1, facecolor='green', alpha=0.5)
# comment out next line and bug goes away!
ax.legend((red, green), ('red', 'green'), loc='best')
show()

On 2/28/07, Nicolas Grilly <nic...@ga...> wrote:
> Have you seen this patch I proposed several days ago, during your
> vacations? Can you reproduce the problem on your machine and do you
> agree with the solution?
No, I missed it the first time around, thanks for resending. I've
been battling these half-center alignment problems since we added the
agg backend -- search throughout the _backend_agg.cpp backend for
"snapto". I do two things differently from you, and we need to
decide on the right approach and do it consistently.
+ ppath->vertex(i, &x, &y);
+ x = x - 0.5;
+ y = y + 0.5;
+ ppath->modify_vertex(i, x, y);
You are subtracting from x and adding to y, and preserving the
original float, whereas I have been truncating to int and adding 0.5
to insure that the number is a pixel center. Eg,
 //snapto pixel centers
 l = (int)l + 0.5;
 b = (int)b + 0.5;
 r = (int)r + 0.5;
 t = (int)t + 0.5;
What is the justification for subtracting from x and adding to y? And
do you agree that it is preferable to first truncate to an int before
doing the 0.5 offset to insure the pixel center?
I do agree that it makes more sense to do this in the backend since
the notion of pixel center has no place in the vector backends. Would
you consider looking over the rest of backend agg and making sure this
is applied consistently and correctly? In the past, I have been only
applying this adjustment on horizontal and vertical lines, but perhaps
we should apply it to all vertices in the agg backend regardless, as
you are doing in your patch. I would love to vanquish this pesky
problem once and for all -- it seems that everytime I push it down in
one place, it crops up in another.
JDH

John,
Have you seen this patch I proposed several days ago, during your
vacations? Can you reproduce the problem on your machine and do you
agree with the solution?
Thanks,
Nicolas
=== My original post hereunder: ===
When using a vectorial backend like PS or PDF, I noticed tick marks
and grid lines are not perfectly aligned.
Here is a little script revealing the problem:
 import os
 from pylab import *
 rc('axes', linewidth=0.5, axisbelow=True)
 rc('xtick', direction='out')
 rc('ytick', direction='out')
 t = arange(0.0, 2.0, 0.01)
 s = sin(2*pi*t)
 plot(t, s, linewidth=1.0)
 title('Tick marks, grid lines and other marks should be aligned')
 xlabel('time (s)')
 ylabel('voltage (mV)')
 grid(True, linestyle='-', color='#d3d3d3')
 axhline(0.5, linewidth=0.5)
 plot([0.5], [0.5], '+')
 plot([1.0], [0.5], marker=0)
 savefig('testchart.eps')
 savefig('testchart.png')
 show()
The attached file testchart-misaligned.eps shows the result with the
PS backend: tick marks and grid lines are not perfectly aligned, which
is bad; but the "+" mark placed in the plot is correctly aligned with
the grid lines, as expected.
In the attached file testchart-misaligned.png, produced with the Agg
backend, this is the opposite: tick marks and grid lines are perfectly
aligned, but the "+" mark is not exactly over the grid lines.
I think this is caused by a workaround used in lines.py, in methods
_draw_tickleft, _draw_tickright, _draw_tickup and _draw_tickdown,
consisting in adding 0.5 to marks coordinates in order to place them
in pixel center. This is good for bitmap backends like Agg, but it's
bad for vectorial backends like PS, PDF and SVG. I propose to remove
this behavior from lines.py and move it in _backend_agg.cpp.
The attached file alignment.patch is a patch implementing this proposition.
The files testchart_aligned.eps and testchart_aligned.png show the
results with the PS and Agg backends after applying the patch:
everything is aligned.
Do you agree to apply this patch, or have I misunderstood something? :-)
Cheers,
-- Nicolas Grilly

Hi John,
thanks *very much* for your message. This is exactly what I want.
And it is going to be a lot less work than it was in C / Xlib. Even
re-reading that code was a nightmare, adding new features would be
nearly impossible :-)
I will now start redoing all my code using matplotlib.
cheers
Antonio
Antonio Kanaan
Departamento de Fisica - Universidade Federal de Santa Catarina
CP 476 -- CEP 88040-900 -- Florianopolis -- SC -- Brasil
http://www.astro.ufsc.br/~kanaan e-mail: ka...@as...
Phone: 55,48,33319069 FAX : 55,48,33319946
On 2/26/07, John Hunter <jd...@gm...> wrote:
> On 2/26/07, Antonio Kanaan <ank...@gm...> wrote:
> > Hi folks,
> >
> > I am planning to re-write a data viewer program I wrote ages ago using C + Xlib.
> >
> > This program allows me to plot on the same window several graphs (time
> > versus brightness - I work on variable stars). They all share the
> > same independent variable (time passes the same for everybody).
> >
> > I can scroll and zoom the graphs both in X and Y. When I scroll/zoom
> > in X all plots suffer the same action. Y scrolling/zooming may be
> > done for each plot.
> >
> > Now the question: I need a data cursor, by that I mean some marker
> > that sits on top of a point and which may be moved forward/backward by
> > pressing a key. Matplotlib has a mouse cursor that gives me the
> > cursor coordinates, but it doesn't
>
> This isn't too bad actually -- you can subclass the existing Cursor
> class to override the xdata and ydata atrributes to insure that the
> cursor sits only on your data points. The example below uses the
> cursor class to overrride the toolbar formatting, and shows you how to
> toggle the visibility of multiple cursors in multiple axes with shared
> x axes. I'll also attach it in case the mail system mangles the
> newlines. Take a look at the MultiCursor in
> the widgets module, you might be able to do a similar trick there to
> have common x cursoring across multiple axes.
>
> from pylab import figure, show, nx
> from matplotlib.widgets import Cursor
>
> class DataCursor(Cursor):
> def __init__(self, t, y, ax, useblit=True, **lineprops):
> Cursor.__init__(self, ax, useblit=True, **lineprops)
> self.y = y
> self.t = t
> self.xstr = ''
> self.ystr = ''
>
> def onmove(self, event):
> """
> we override event.xdata to force it to snap-to nearest data
> item here we assume t is sorted and I'll use searchsorted
> since it is a little faster, but you can plug in your nearest
> neighbor routine, eg to grab the closest x,y point to the
> cursor
> """
> xdata = event.xdata
> ind = nx.searchsorted(self.t, xdata)
> ind = min(len(self.t)-1, ind)
> event.xdata = self.t[ind]
> event.ydata = self.y[ind]
> self.xstr = '%1.3f'%event.xdata
> self.ystr = '%1.3f'%event.ydata
> Cursor.onmove(self, event)
>
> def fmtx(self, x):
> return self.xstr
>
> def fmty(self, y):
> return self.ystr
>
> fig = figure()
> ax1 = fig.add_subplot(211)
> ax2 = fig.add_subplot(212, sharex=ax1) # connect x pan/zoom events
>
> t = nx.cumsum(nx.rand(20))
> s1 = nx.mlab.rand(len(t))
> s2 = nx.mlab.rand(len(t))
>
> ax1.plot(t, s1, 'go')
> ax2.plot(t, s2, 'bs')
> ax1.set_title("Press 1 for upper cursor and 2 for lower cursor")
> cursor1 = DataCursor(t, s1, ax1, useblit=True, color='red', linewidth=2 )
>
> # we'll let the cursor do the toolbarformatting too.
> ax1.fmt_xdata = cursor1.fmtx
> ax1.fmt_ydata = cursor1.fmty
>
> cursor2 = DataCursor(t, s2, ax2, useblit=True, color='red', linewidth=2 )
> ax2.fmt_xdata = cursor2.fmtx
> ax2.fmt_ydata = cursor2.fmty
>
>
> # now we'll control the visibility of the cursor; turn off cursor2 by default
> cursor2.visible = False
>
> def keyevent(event):
> cursor1.visible = event.key=='1'
> cursor2.visible = event.key=='2'
> fig.canvas.draw()
>
> fig.canvas.mpl_connect('key_press_event', keyevent)
> show()
>
>
> >
> > - sit on top of my points and therefore doesn't give me the exact
> > value of that point
> > - allow me to move from one point to the next
> > - allow me to change which graph I want the cursor sitting on
> >
> > I thought of drawing my own cursor, deleting it and moving to the next
> > point . It seems this would take forever as (far as I understand)
> > matplotlib will redo the entire plot each time I do this.
> >
> > How hard is it for the developers to include a built in data cursor in
> > a similar fashion to the mouse cursor now available. I am affraid
> > this isn't too easy, I don't know any plotting program that has one
> > like what I need.
> >
> > thanks for your attention,
> >
> > Antonio Kanaan
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>

On 2/26/07, Antonio Kanaan <ank...@gm...> wrote:
> I thought of drawing my own cursor, deleting it and moving to the next
> point . It seems this would take forever as (far as I understand)
> matplotlib will redo the entire plot each time I do this.
I forgot to mention in my previous post -- as long as you use the blit
techniques embodied in the Cursor class in the example above and
discussed here:
http://www.scipy.org/Cookbook/Matplotlib/Animations
matplotlib will not redraw you figure each time.
JDH

On 2/26/07, Antonio Kanaan <ank...@gm...> wrote:
> Hi folks,
>
> I am planning to re-write a data viewer program I wrote ages ago using C + Xlib.
>
> This program allows me to plot on the same window several graphs (time
> versus brightness - I work on variable stars). They all share the
> same independent variable (time passes the same for everybody).
>
> I can scroll and zoom the graphs both in X and Y. When I scroll/zoom
> in X all plots suffer the same action. Y scrolling/zooming may be
> done for each plot.
>
> Now the question: I need a data cursor, by that I mean some marker
> that sits on top of a point and which may be moved forward/backward by
> pressing a key. Matplotlib has a mouse cursor that gives me the
> cursor coordinates, but it doesn't
This isn't too bad actually -- you can subclass the existing Cursor
class to override the xdata and ydata atrributes to insure that the
cursor sits only on your data points. The example below uses the
cursor class to overrride the toolbar formatting, and shows you how to
toggle the visibility of multiple cursors in multiple axes with shared
x axes. I'll also attach it in case the mail system mangles the
newlines. Take a look at the MultiCursor in
the widgets module, you might be able to do a similar trick there to
have common x cursoring across multiple axes.
from pylab import figure, show, nx
from matplotlib.widgets import Cursor
class DataCursor(Cursor):
 def __init__(self, t, y, ax, useblit=True, **lineprops):
 Cursor.__init__(self, ax, useblit=True, **lineprops)
 self.y = y
 self.t = t
 self.xstr = ''
 self.ystr = ''
 def onmove(self, event):
 """
 we override event.xdata to force it to snap-to nearest data
 item here we assume t is sorted and I'll use searchsorted
 since it is a little faster, but you can plug in your nearest
 neighbor routine, eg to grab the closest x,y point to the
 cursor
 """
 xdata = event.xdata
 ind = nx.searchsorted(self.t, xdata)
 ind = min(len(self.t)-1, ind)
 event.xdata = self.t[ind]
 event.ydata = self.y[ind]
 self.xstr = '%1.3f'%event.xdata
 self.ystr = '%1.3f'%event.ydata
 Cursor.onmove(self, event)
 def fmtx(self, x):
 return self.xstr
 def fmty(self, y):
 return self.ystr
fig = figure()
ax1 = fig.add_subplot(211)
ax2 = fig.add_subplot(212, sharex=ax1) # connect x pan/zoom events
t = nx.cumsum(nx.rand(20))
s1 = nx.mlab.rand(len(t))
s2 = nx.mlab.rand(len(t))
ax1.plot(t, s1, 'go')
ax2.plot(t, s2, 'bs')
ax1.set_title("Press 1 for upper cursor and 2 for lower cursor")
cursor1 = DataCursor(t, s1, ax1, useblit=True, color='red', linewidth=2 )
# we'll let the cursor do the toolbarformatting too.
ax1.fmt_xdata = cursor1.fmtx
ax1.fmt_ydata = cursor1.fmty
cursor2 = DataCursor(t, s2, ax2, useblit=True, color='red', linewidth=2 )
ax2.fmt_xdata = cursor2.fmtx
ax2.fmt_ydata = cursor2.fmty
# now we'll control the visibility of the cursor; turn off cursor2 by default
cursor2.visible = False
def keyevent(event):
 cursor1.visible = event.key=='1'
 cursor2.visible = event.key=='2'
 fig.canvas.draw()
fig.canvas.mpl_connect('key_press_event', keyevent)
show()
>
> - sit on top of my points and therefore doesn't give me the exact
> value of that point
> - allow me to move from one point to the next
> - allow me to change which graph I want the cursor sitting on
>
> I thought of drawing my own cursor, deleting it and moving to the next
> point . It seems this would take forever as (far as I understand)
> matplotlib will redo the entire plot each time I do this.
>
> How hard is it for the developers to include a built in data cursor in
> a similar fashion to the mouse cursor now available. I am affraid
> this isn't too easy, I don't know any plotting program that has one
> like what I need.
>
> thanks for your attention,
>
> Antonio Kanaan
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi folks,
I am planning to re-write a data viewer program I wrote ages ago using C + Xlib.
This program allows me to plot on the same window several graphs (time
versus brightness - I work on variable stars). They all share the
same independent variable (time passes the same for everybody).
I can scroll and zoom the graphs both in X and Y. When I scroll/zoom
in X all plots suffer the same action. Y scrolling/zooming may be
done for each plot.
Now the question: I need a data cursor, by that I mean some marker
that sits on top of a point and which may be moved forward/backward by
pressing a key. Matplotlib has a mouse cursor that gives me the
cursor coordinates, but it doesn't
- sit on top of my points and therefore doesn't give me the exact
value of that point
- allow me to move from one point to the next
- allow me to change which graph I want the cursor sitting on
I thought of drawing my own cursor, deleting it and moving to the next
point . It seems this would take forever as (far as I understand)
matplotlib will redo the entire plot each time I do this.
How hard is it for the developers to include a built in data cursor in
a similar fashion to the mouse cursor now available. I am affraid
this isn't too easy, I don't know any plotting program that has one
like what I need.
thanks for your attention,
Antonio Kanaan

On Feb 23, 2007, at 8:00 PM, Andrew Straw wrote:
>
> 2) make our own distutils monkeypatch a la setuptools. Looking at
> setuptools/dist.py, this doesn't look trivial -- certainly beyond my
> free bandwidth capacity.
I've written a script that attempts to simplify writing setup.py's 
that includes automagic support for package_data in Python 2.3:
	http://agni.phys.iit.edu/~kmcivor/downloads/metasetup.py
You can see a simple example of it in the WxMpl source:
	http://svn.csrri.iit.edu/mr-software/wxmpl/trunk/setup.py
Ken

On 2/24/07, Andrew Straw <str...@as...> wrote:
> Robert Kern wrote:
> > IPython does something similar and possibly better.
> >
> > http://ipython.scipy.org/svn/ipython/ipython/trunk/setupext/install_data_ext.py
> >
> From a quick look at the code, it's hard to determine whether this new
> distutils command (install_data_ext) can handle installation to a nested
> directory structure. Can it? If it can, there's still the question of
> whether we want to continue rolling our own solution or simply using
> Python >= 2.4's standard "package_data".
I think it does, but you should actually ask someone who knows about ipython :)
I say 'I think' from reading setup.py, where this code is invoked:
datafiles = [('data', docdirbase, docfiles),
 ('data', os.path.join(docdirbase, 'examples'),
 examfiles),
 ('data', os.path.join(docdirbase, 'manual'),
 manfiles),
 ('data', manpagebase, manpages),
 ('lib', 'IPython/UserConfig', cfgfiles)]
[...]
and then the setup() call contains:
 cmdclass = {'install_data': install_data_ext},
 data_files = datafiles,
So it certainly looks like it works fine for copying things like the
example files and the html manual (which is nested, below doc/manual).
This code was actually given to me years ago, by some kind soul who
cringed at the horrid hacks I had in place to achieve the goal. It
has never been modified and has served us well for years, so feel free
to grab it if it happens to be useful to mpl. It's a tiny bit of
code, so if it gets you out of a bind, I'd say just use it.
It does work fine with python 2.3, if that's one of your goals.
Cheers,
f

Robert Kern wrote:
> Andrew Straw wrote:
>
>> 1) revert to the old way. The primary issues with this are a) 
>> "package_data" is supported as standard Python from 2.4 on, and the old 
>> way required carrying our own distutils command and b) we switched the 
>> data directory to have a nested structure, which required code changes 
>> and repository layout changes that would have to be undone.
>> 2) make our own distutils monkeypatch a la setuptools. Looking at 
>> setuptools/dist.py, this doesn't look trivial -- certainly beyond my 
>> free bandwidth capacity.
>> 
>
> Actually, it ought to be pretty trivial without setuptools (but compatible with
> setuptools, AFAICT). Here is a Cookbook recipe that ought to work:
>
> http://wiki.python.org/moin/DistutilsInstallDataScattered
>
> 
That's exactly "the old way", referred to in point #1.
> IPython does something similar and possibly better.
>
> http://ipython.scipy.org/svn/ipython/ipython/trunk/setupext/install_data_ext.py
> 
 From a quick look at the code, it's hard to determine whether this new 
distutils command (install_data_ext) can handle installation to a nested 
directory structure. Can it? If it can, there's still the question of 
whether we want to continue rolling our own solution or simply using 
Python >= 2.4's standard "package_data".
AFAICT, the monkeypatching setuptools does for 2.3 to support 
"package_data" goes beyond adding a new distutils command. (I don't 
consider adding a distutils command to be monkeypatching -- that's just 
extending distutils is a pre-designed way.) Instead, setuptools actually 
replaces the distutils.dist.Distribution class with 
setuptools.dist.Distribution.

Andrew Straw wrote:
> 2) make our own distutils monkeypatch a la setuptools. Looking at 
> setuptools/dist.py, this doesn't look trivial -- certainly beyond my 
> free bandwidth capacity.
Actually, it ought to be pretty trivial without setuptools (but compatible with
setuptools, AFAICT). Here is a Cookbook recipe that ought to work:
 http://wiki.python.org/moin/DistutilsInstallDataScattered
IPython does something similar and possibly better.
 http://ipython.scipy.org/svn/ipython/ipython/trunk/setupext/install_data_ext.py
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Andrew,
I agree with your proposal; I think it makes more sense than either 
alternative. Let's see what John says when he gets back from his vacation.
Eric
Andrew Straw wrote:
> (Picking up this thread a bit late... And I just wrote a longer email 
> which got munched due to email configuration issues...)
> 
> I'm responsible for the "package_data" keyword being added to setup.py. 
> The bottom line is Python 2.3 is still supported. I simply didn't 
> realize that it would screw things up. I propose that setuptools be a 
> requirement for matplotlib with Python 2.3 and have committed a change 
> that does this. So the issue is now closed unless we want to implement 
> an alternative solution. These, as I see them, are:
> 
> 1) revert to the old way. The primary issues with this are a) 
> "package_data" is supported as standard Python from 2.4 on, and the old 
> way required carrying our own distutils command and b) we switched the 
> data directory to have a nested structure, which required code changes 
> and repository layout changes that would have to be undone.
> 
> 2) make our own distutils monkeypatch a la setuptools. Looking at 
> setuptools/dist.py, this doesn't look trivial -- certainly beyond my 
> free bandwidth capacity.
> 
> -Andrew
> 
> Eric Firing wrote:
>> Darren Dale wrote:
>> 
>>> We support setuptools, but we do not require it.
>>> 
>>
>> So, it sounds like setuptools is required now if one has Python 2.3. 
>> If so, is that acceptable--is the gain worth the pain? Is there any 
>> significant pain associated with requiring setuptools, at least for 
>> people with Python 2.3?
>>
>> Eric
>>
>> 
>>> On Friday 23 February 2007 5:46:58 am Edin Salkovic wrote:
>>> 
>>>> I'm learning a bit about setuptools and distutils, so sorry if this is
>>>> a no brainer: Are we using only distutils for matplotlib? I.e. - no
>>>> setuptools?
>>>>
>>>> This is because I stumbled across this at the setuptools page:
>>>> http://peak.telecommunity.com/DevCenter/setuptools
>>>> ====
>>>> Feature Highlights:
>>>>
>>>> ....
>>>> * Include data files inside your package directories, where your
>>>> code can actually use them. (Python 2.4 distutils also supports this
>>>> feature, but setuptools provides the feature for Python 2.3 packages
>>>> also, and supports accessing data files in zipped packages too.)
>>>> ....
>>>>
>>>> Cheers,
>>>> Edin
>>>>
>>>> On 2/22/07, Darren Dale <dd...@co...> wrote:
>>>> 
>>>>> I noticed today that setup.py is using package_data. Is this 
>>>>> absolutely
>>>>> necessary? The most recent version of Red Hat Enterprise Linux 
>>>>> includes
>>>>> python-2.3, which does not support package_data. We are still 
>>>>> supporting
>>>>> python-2.3, aren't we?
>>>>>
>>>>> Darren
>>>>> 
> 

(Picking up this thread a bit late... And I just wrote a longer email 
which got munched due to email configuration issues...)
I'm responsible for the "package_data" keyword being added to setup.py. 
The bottom line is Python 2.3 is still supported. I simply didn't 
realize that it would screw things up. I propose that setuptools be a 
requirement for matplotlib with Python 2.3 and have committed a change 
that does this. So the issue is now closed unless we want to implement 
an alternative solution. These, as I see them, are:
1) revert to the old way. The primary issues with this are a) 
"package_data" is supported as standard Python from 2.4 on, and the old 
way required carrying our own distutils command and b) we switched the 
data directory to have a nested structure, which required code changes 
and repository layout changes that would have to be undone.
2) make our own distutils monkeypatch a la setuptools. Looking at 
setuptools/dist.py, this doesn't look trivial -- certainly beyond my 
free bandwidth capacity.
-Andrew
Eric Firing wrote:
> Darren Dale wrote:
> 
>> We support setuptools, but we do not require it.
>> 
>
> So, it sounds like setuptools is required now if one has Python 2.3. If 
> so, is that acceptable--is the gain worth the pain? Is there any 
> significant pain associated with requiring setuptools, at least for 
> people with Python 2.3?
>
> Eric
>
> 
>> On Friday 23 February 2007 5:46:58 am Edin Salkovic wrote:
>> 
>>> I'm learning a bit about setuptools and distutils, so sorry if this is
>>> a no brainer: Are we using only distutils for matplotlib? I.e. - no
>>> setuptools?
>>>
>>> This is because I stumbled across this at the setuptools page:
>>> http://peak.telecommunity.com/DevCenter/setuptools
>>> ====
>>> Feature Highlights:
>>>
>>> ....
>>> * Include data files inside your package directories, where your
>>> code can actually use them. (Python 2.4 distutils also supports this
>>> feature, but setuptools provides the feature for Python 2.3 packages
>>> also, and supports accessing data files in zipped packages too.)
>>> ....
>>>
>>> Cheers,
>>> Edin
>>>
>>> On 2/22/07, Darren Dale <dd...@co...> wrote:
>>> 
>>>> I noticed today that setup.py is using package_data. Is this absolutely
>>>> necessary? The most recent version of Red Hat Enterprise Linux includes
>>>> python-2.3, which does not support package_data. We are still supporting
>>>> python-2.3, aren't we?
>>>>
>>>> Darren
>>>> 

Darren Dale wrote:
> We support setuptools, but we do not require it.
So, it sounds like setuptools is required now if one has Python 2.3. If 
so, is that acceptable--is the gain worth the pain? Is there any 
significant pain associated with requiring setuptools, at least for 
people with Python 2.3?
Eric
> 
> On Friday 23 February 2007 5:46:58 am Edin Salkovic wrote:
>> I'm learning a bit about setuptools and distutils, so sorry if this is
>> a no brainer: Are we using only distutils for matplotlib? I.e. - no
>> setuptools?
>>
>> This is because I stumbled across this at the setuptools page:
>> http://peak.telecommunity.com/DevCenter/setuptools
>> ====
>> Feature Highlights:
>>
>> ....
>> * Include data files inside your package directories, where your
>> code can actually use them. (Python 2.4 distutils also supports this
>> feature, but setuptools provides the feature for Python 2.3 packages
>> also, and supports accessing data files in zipped packages too.)
>> ....
>>
>> Cheers,
>> Edin
>>
>> On 2/22/07, Darren Dale <dd...@co...> wrote:
>>> I noticed today that setup.py is using package_data. Is this absolutely
>>> necessary? The most recent version of Red Hat Enterprise Linux includes
>>> python-2.3, which does not support package_data. We are still supporting
>>> python-2.3, aren't we?
>>>
>>> Darren
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to share
>>> your opinions on IT & business topics through brief surveys-and earn cash
>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share
>> your opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> 

Hi,
I just submitted a patch to sourceforge that adds some more marker types
to scatter: asterisk like symbols. They are created similar to the
Starlike symbols as a Polygon collection.
The patch is attached to this mail together with a modified version of
scatter_star_poly.py from the examples and its output.
Manuel
-- 
---------------------------------------
 Manuel Metz ............ Stw@AIfA
 Argelander Institut fuer Astronomie
 Auf dem Huegel 71 (room 3.06)
 D - 53121 Bonn
 E-Mail: mm...@as...
 Web: www.astro.uni-bonn.de/~mmetz
 Phone: (+49) 228 / 73-3660
 Fax: (+49) 228 / 73-3672
---------------------------------------

We support setuptools, but we do not require it.
On Friday 23 February 2007 5:46:58 am Edin Salkovic wrote:
> I'm learning a bit about setuptools and distutils, so sorry if this is
> a no brainer: Are we using only distutils for matplotlib? I.e. - no
> setuptools?
>
> This is because I stumbled across this at the setuptools page:
> http://peak.telecommunity.com/DevCenter/setuptools
> ====
> Feature Highlights:
>
> ....
> * Include data files inside your package directories, where your
> code can actually use them. (Python 2.4 distutils also supports this
> feature, but setuptools provides the feature for Python 2.3 packages
> also, and supports accessing data files in zipped packages too.)
> ....
>
> Cheers,
> Edin
>
> On 2/22/07, Darren Dale <dd...@co...> wrote:
> > I noticed today that setup.py is using package_data. Is this absolutely
> > necessary? The most recent version of Red Hat Enterprise Linux includes
> > python-2.3, which does not support package_data. We are still supporting
> > python-2.3, aren't we?
> >
> > Darren
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
dd...@co...

I'm learning a bit about setuptools and distutils, so sorry if this is
a no brainer: Are we using only distutils for matplotlib? I.e. - no
setuptools?
This is because I stumbled across this at the setuptools page:
http://peak.telecommunity.com/DevCenter/setuptools
====
Feature Highlights:
....
 * Include data files inside your package directories, where your
code can actually use them. (Python 2.4 distutils also supports this
feature, but setuptools provides the feature for Python 2.3 packages
also, and supports accessing data files in zipped packages too.)
....
Cheers,
Edin
On 2/22/07, Darren Dale <dd...@co...> wrote:
> I noticed today that setup.py is using package_data. Is this absolutely
> necessary? The most recent version of Red Hat Enterprise Linux includes
> python-2.3, which does not support package_data. We are still supporting
> python-2.3, aren't we?
>
> Darren
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Darren Dale wrote:
> I noticed today that setup.py is using package_data. Is this absolutely 
> necessary? The most recent version of Red Hat Enterprise Linux includes 
> python-2.3, which does not support package_data. We are still supporting 
> python-2.3, aren't we?
Yes, I am sure that is the intention. The change to setup.py occurred 
in revision 3011 as part of the reorganization to support running from a 
working directory and making eggs, or something like that.
Eric

On Feb 22, 2007, at 5:17 PM, Christopher Barker wrote:
>
> I had written some "smarts" for setup.py (and utilities it uses) to 
> do a better job of finding the correct wx-config. Is there any 
> point to that now? If so, I'll sent it along to you.
Debian stable is going to be released soon with wxPython 2.4 and 2.6, 
so I'd like to keep working to improve the C++ accelerator when 
practical. Could you send me the changes?
Ken

FYI Christopher, et al. - Due to operator incompetence the changes I 
blabbed about earlier haven't hit the repository yet.
Ken

Ken McIvor wrote:
>> Are these in Python or c++?
> 
> Since BitmapFromBuffer() and its aforementioned cousin are covered in 
> the wxWidgets documentation for wxBitmap, I believe they're mostly in C++.
umm, I meant, is YOUR code in Python or C++, but it looks like you 
answered that below:
>> um, how is that possible if you're using the new 2.8 functions?
> 
> There are two conditional checks based on wx.__version__. One is in 
> setup.py to not build the C++ accelerator for wxPython 2.8. The other 
> is in backend_wxagg.py and figures out which of the three agg/wx.Bitmap 
> conversion implementations to use -- the pure Python routines, the C++ 
> accelerator, or the wxPython 2.8 edition of the pure Python routines.
Ah. I had written some "smarts" for setup.py (and utilities it uses) to 
do a better job of finding the correct wx-config. Is there any point to 
that now? If so, I'll sent it along to you.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Feb 22, 2007, at 1:11 PM, Christopher Barker wrote:
>
>> More importantly, I written another set of the agg-to-wx.Bitmap 
>> conversion routines that uses the new BitmapFromBufferRGBA() 
>> function in wxPython 2.8.
>
> Are these in Python or c++?
Since BitmapFromBuffer() and its aforementioned cousin are covered in 
the wxWidgets documentation for wxBitmap, I believe they're mostly in 
C++.
>> The blit()
>> routine also got a bit faster after I realized it was more efficient
>> to just convert the whole buffer and blit part of it instead of
>> clipping during conversion.
>
> really? interesting -- it shows you never know!
Yep. Benchmarking is your friend!
>> I have tested these changes with wxPython 2.8.1.1 under OSX 10.4.8.
>> My goal is that none of the changes break compatibility with wxPython
>> 2.4 or 2.6.
>
> um, how is that possible if you're using the new 2.8 functions?
There are two conditional checks based on wx.__version__. One is in 
setup.py to not build the C++ accelerator for wxPython 2.8. The 
other is in backend_wxagg.py and figures out which of the three agg/ 
wx.Bitmap conversion implementations to use -- the pure Python 
routines, the C++ accelerator, or the wxPython 2.8 edition of the 
pure Python routines.
>> I'd really appreciate it if someone could test and
>> benchmark those versions using `examples/animation_blit_wx.py'.
>
> I'll see what I can do.
>
> By the way, did you see the weird toolbar behavior with 2.8 on OS-X?
It didn't jump out at me, but I wasn't paying much attention. I'll 
try to reproduce it tomorrow.
Ken

I noticed today that setup.py is using package_data. Is this absolutely 
necessary? The most recent version of Red Hat Enterprise Linux includes 
python-2.3, which does not support package_data. We are still supporting 
python-2.3, aren't we?
Darren

Thanks Ken!!
 > More importantly, I written
> another set of the agg-to-wx.Bitmap conversion routines that uses the 
> new BitmapFromBufferRGBA() function in wxPython 2.8.
Are these in Python or c++?
> The blit() 
> routine also got a bit faster after I realized it was more efficient 
> to just convert the whole buffer and blit part of it instead of 
> clipping during conversion.
really? interesting -- it shows you never know!
> I have tested these changes with wxPython 2.8.1.1 under OSX 10.4.8. 
> My goal is that none of the changes break compatibility with wxPython 
> 2.4 or 2.6.
um, how is that possible if you're using the new 2.8 functions?
> I'd really appreciate it if someone could test and 
> benchmark those versions using `examples/animation_blit_wx.py'.
I'll see what I can do.
By the way, did you see the weird toolbar behavior with 2.8 on OS-X?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

T24gMi8yMS8wNywgSm91bmkgSy4gU2VwcMOkbmVuIDxqa3NAaWtpLmZpPiB3cm90ZToKPiA+IEhh
dmUgeW91IGhhZCB0aW1lIHRvIGxvb2sgYXQgbXkgcGF0Y2ggcmVnYXJkaW5nIHRoZSBQREYgYmFj
a2VuZD8gOi0pCj4KPiBBIGJpdCwgYW5kIEkgY291bGRuJ3QgcXVpdGUgZ2V0IGl0IHRvIHdvcmsu
IEJ1dCB3aGF0IHRoZSBoZWNrLCBsZXQncwo+IHB1dCBpdCBpbiB0aGUgcmVwb3NpdG9yeSBzbyB3
ZSBjYW4gYWxsIGhhY2sgb24gaXQuIEl0IGlzIHF1aXRlIGFuCj4gaW1wcm92ZW1lbnQgdG8gdGhl
IGJhY2tlbmQsIGFuZCBpdCBkb2Vzbid0IHNlZW0gdG8gYnJlYWsgYW55dGhpbmcgdGhhdAo+IHVz
ZWQgdG8gd29yay4gKEkgcmFuIHRoZSBleGFtcGxlcyB1c2luZyBiYWNrZW5kX2RyaXZlci5weSBv
biBib3RoIGFnZwo+IGFuZCBwZGYuKSBZb3VyIHBhdGNoIChzbGlnaHRseSBtb2RpZmllZCkgaXMg
Y29tbWl0dGVkIGFzIG9mIHN2bgo+IHJldmlzaW9uIDMwMjcuCgpUaGFua3MgSm91bmkgZm9yIGNv
bW1pdHRpbmcgdGhpcyBwYXRjaC4KCk5vdywgSSdtIHdvcmtpbmcgb24gdGhlIHR3byBpc3N1ZXMg
eW91J3ZlIG1lbnRpb25lZCBiZWxvdy4gSSdsbApwcm9iYWJseSBzZW5kIGEgbmV3IHBhdGNoIGZp
eGluZyB0aGUgZm9udCBpc3N1ZSBpbiB0aGUgbmV4dCBmZXcgZGF5cy4KCj4gVGhlIHByb2JsZW0g
SSdtIGhhdmluZyBpcyB0aGF0IGlmIEkgc2V0IHVzZTE0Y29yZWZvbnRzIG9uLCBJIGhhdmUgdG8K
PiBtYWtlIHN1cmUgdGhhdCBIZWx2ZXRpY2EgKG9yIHdoYXRldmVyKSBpcyBjaG9zZW4gYXMgdGhl
IHRleHQgZm9udC4KPiBJIHVzZWQgdG8gaGF2ZSB0aGUgc2V0dGluZwo+Cj4gZm9udC5zYW5zLXNl
cmlmICAgICA6IEJpdHN0cmVhbSBWZXJhIFNhbnMKPgo+IGJlY2F1c2UgdGhhdCBmb250IHdvcmtz
LCBhbmQgc29tZSBvdGhlciBmb250cyB0aGF0IG1wbCBmaW5kcyAob24gbXkKPiBPUyBYIHN5c3Rl
bSkgZG9uJ3Q7IGJ1dCB0aGVuIHNldHRpbmcgdXNlMTRjb3JlZm9udHMgb24gY2F1c2VkIHRoZSBh
Zm0KPiBoZWFkZXIgcGFyc2VyIHRvIGJlIGNhbGxlZCBvbiBWZXJhLnR0Ziwgd2hpY2ggaXQgb2J2
aW91c2x5IGNvdWxkbid0Cj4gbWFrZSBhbnkgc2Vuc2Ugb2YuIEknbSBub3Qgc3VyZSBJIHF1aXRl
IHVuZGVyc3RhbmQgdGhlIE1hdHBsb3RsaWIgZm9udAo+IHNlbGVjdGlvbiBzeXN0ZW0sIHRob3Vn
aC4KPgo+IFJlcGxhY2luZyB0aGUgc2V0dGluZyBieQo+Cj4gZm9udC5zYW5zLXNlcmlmICAgICA6
IEhlbHZldGljYSwgQml0c3RyZWFtIFZlcmEgU2Fucwo+Cj4gaGVscHMsIGJ1dCBpdCB3b3VsZCBi
ZSBuaWNlIHRvIHB1dCBpbiBzb21lIHNhbml0eSBjaGVja3Mgc28gdGhhdCB3ZQo+IGRvbid0IHNl
bmQgdGhlIHR0ZiBmaWxlIHRvIHRoZSBhZm0gcGFyc2VyLgo+Cj4gT24gYW5vdGhlciBub3RlLCB0
aGUgZHBpIHNldHRpbmcgd2FzIHVzZWQgZm9yIGltYWdlcy4gUmVtb3ZpbmcgaXQgZG9lcwo+IG1h
a2UgdGhlIGNvZGUgc2ltcGxlciwgYnV0IHRoZW4gYWxsIGltYWdlcyB3aWxsIGJlIGF0IGEgcmVz
b2x1dGlvbiBvZgo+IDcyIGRwaS4gQ2FuIHlvdSBiZSBtb3JlIHNwZWNpZmljIGFib3V0IHRoZSBw
cm9ibGVtcyB0aGF0IHRoZSBkcGkKPiBzZXR0aW5nIHdhcyBjYXVzaW5nPyBBbnl3YXksIHBlcmhh
cHMgd2Ugc2hvdWxkIGZpbmQgYSBiZXR0ZXIgaW50ZXJmYWNlCj4gZm9yIHNwZWNpZnlpbmcgaW1h
Z2UgcmVzb2x1dGlvbiBmb3IgdmVjdG9yaWFsIGJhY2tlbmRzLgo=