matplotlib-devel Mailing List for matplotlib (Page 2)

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> Could someone please regenerated the swig wrappings with
 Charlie> swig-1.3.29 instead of swig-1.3.27 and commit?
I just did this -- give it a test drive.
JDH

The swig wrappings are causing some compile time errors on windows and
python2.5. All seem to be this error:
error C2440: 'initializing' : cannot convert from 'const char *' to 'char *'
Could someone please regenerated the swig wrappings with swig-1.3.29
instead of swig-1.3.27 and commit?
Thanks,
 Charlie

I've updated the docstring with a comment about display issues in wxGTK.
Martin
Martin Spacek wrote:
> Not sure if this already exists, but here's an example file of how to 
> get a wx.ToolTip to pop up and report the current mouse position in data 
> coordinates over a MPL axes. Not sure if it's the best way of doing 
> this, but it seems to work really well for me. Perhaps it would be 
> useful to add this to the MPL examples?
> 
> Cheers,
> 
> Martin
> 
> 

Martin Spacek wrote:
> That initial tooltip never shows up for me, which I think is the correct 
> behaviour,
Probably. You have that Enable(False) call in there. However, I notice 
from the docs that wx.ToolTip.Enable() is a "global" call -- it doesn't 
just enable or disable that particular tooltip. I can't say I really 
understand what that means, though.
> so I just put whatever in there to make it a really long line 
> to get around the wx bug.
Well, it seems to work OK for all the next tips.
> Cool. Yeah, I don't think wx gets as much testing on GTK as it does on 
> Windows.
I think it does. I think GTK and MSW get about equal usage, with wxMac a 
very distant third.
(and this is working very poorly on Mac)
Some things work better on Windows, some on GTK. In this case, I thihk 
we're bumping into cross-platfrom issues. wx tries to use native 
functionality where it can and that does make for differences.
I'm going to take this discussion over to wxpython-users -- are you on 
that list too?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Im graphing temperature over time. I would like to have the C scale on the
left side, and the F scale on the other with 0 on the C scale being equal to
32 on the F scale. I can get both scales on the graph, but can't get them to
line up with 0 = 32. 
Thanks for the help. 
-- 
View this message in context: http://www.nabble.com/temperature-scales-tf2274053.html#a6314470
Sent from the matplotlib - devel forum at Nabble.com.

> What is this supposed to give you. I get a Very long tooltip box with:
> 
> tip with a
> long
> line and a newline
> 
> 
> In it.
> 
> then, when the mouse starts moving, I get a tip that is just the right 
> size to hold the two coords, each on their own line.
That initial tooltip never shows up for me, which I think is the correct 
behaviour, so I just put whatever in there to make it a really long line 
to get around the wx bug.
> wxGTK2
> 
>> Also, disables the tooltip when the mouse moves off of the axes, which 
>> prevents stray tooltips from hanging around.
> 
> this doesn't work for me either. If that code in enables, the tip goes 
> away and does not come back at all.
> 
> I guess I'll make a non-MPL version, and send a note to the wxPython list.
> 
> -Chris
> 
Cool. Yeah, I don't think wx gets as much testing on GTK as it does on 
Windows.
Martin

And here's yet another refinement. Works around a wx bug (see 
http://article.gmane.org/gmane.comp.python.wxpython/37937/match=tooltip) 
that prevents newlines from being recognized in the tooltip string. 
Also, disables the tooltip when the mouse moves off of the axes, which 
prevents stray tooltips from hanging around.
Martin
Martin Spacek wrote:
> Here's an updated version. mpl.use('WXAgg') should come before importing 
> pylab.
> 
> Martin
> 

Here's an updated version. mpl.use('WXAgg') should come before importing 
pylab.
Martin
Martin Spacek wrote:
> Not sure if this already exists, but here's an example file of how to 
> get a wx.ToolTip to pop up and report the current mouse position in data 
> coordinates over a MPL axes. Not sure if it's the best way of doing 
> this, but it seems to work really well for me. Perhaps it would be 
> useful to add this to the MPL examples?
> 
> Cheers,
> 
> Martin

"Way of the future" or not, I tried to download easy_install to use 
the egg version and got nowhere fast. mpkgs are much easier for 
those of us who aren't command-line gurus
(I didn't realize you could drop the contents of an egg right into 
site-packages though. I'll have to try that next time)
Thanks for the files Charlie
On 9/12/06, Christopher Barker <Chr...@no...> wrote:
> Charlie Moad wrote:
> > I've been busy, but I will try to make mpkgs for mpl and numpy 
> tonight
> > and post them to the pythonmac-sig list so they get added to the
> > pythonmac listing.
>
> In the meantime, why not just post the eggs there? That's probably the
> way of the future anyway.
>
> And for the OP: Charlie has put eggs for OS-X that work for a t 
> least a
> few of us here:
>
> http://euclid.uits.iupui.edu/mplfiles/
>
> -Chris
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> NOAA/OR&R/HAZMAT (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Ok, I uploaded the mpkgs to, "http://euclid.uits.iupui.edu/mplfiles/".
 Chris, can you please notify the pythonmac list? I am shuffling
around my mailing lists and I am not subscribed at this instant.
Thanks,
On 9/12/06, Christopher Barker <Chr...@no...> wrote:
> Charlie Moad wrote:
> > I've been busy, but I will try to make mpkgs for mpl and numpy tonight
> > and post them to the pythonmac-sig list so they get added to the
> > pythonmac listing.
>
> In the meantime, why not just post the eggs there? That's probably the
> way of the future anyway.
>
> And for the OP: Charlie has put eggs for OS-X that work for a t least a
> few of us here:
>
> http://euclid.uits.iupui.edu/mplfiles/
>
> -Chris
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> NOAA/OR&R/HAZMAT (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
>

Not sure if this already exists, but here's an example file of how to 
get a wx.ToolTip to pop up and report the current mouse position in data 
coordinates over a MPL axes. Not sure if it's the best way of doing 
this, but it seems to work really well for me. Perhaps it would be 
useful to add this to the MPL examples?
Cheers,
Martin

Charlie Moad wrote:
> I've been busy, but I will try to make mpkgs for mpl and numpy tonight
> and post them to the pythonmac-sig list so they get added to the
> pythonmac listing.
In the meantime, why not just post the eggs there? That's probably the 
way of the future anyway.
And for the OP: Charlie has put eggs for OS-X that work for a t least a 
few of us here:
http://euclid.uits.iupui.edu/mplfiles/
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

I've been busy, but I will try to make mpkgs for mpl and numpy tonight
and post them to the pythonmac-sig list so they get added to the
pythonmac listing.
- Charlie
On 9/11/06, Brendan Simons <spa...@ya...> wrote:
> Sigh, this is driving me crazy
>
> I tried downloading the Scipy-Superpack for os x from scipy.org,
> which supposedly contains compatible numpy and scipy binaries. But
> when I try to import pylab, I get:
> ---
> "RuntimeError: module compiled against version 90709 of C-API but
> this version of numpy is 1000000"
> ---
> So I went off to find a newer build of matplotlib, but Sourceforge
> and pythonmac.org only have mpkg binaries for 87.4. I tried
> installing setuptools to use the .egg version, but didn't get very
> far before my head started hurting (who named this thing "easy"?).
> Similarly trying to compile the source code gives me:
> ---
> C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/
> MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
> -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3
> compile options: '-I/usr/local/include -I/usr/include -I. -I/Library/
> Frameworks/Python.framework/Versions/2.4/include/python2.4 -c'
> gcc: src/_isnan.c
> gcc: cannot specify -o with -c or -S and multiple compilations
> ---
>
> Long story short, I'm giving up. Has anyone compiled an mpkg binary
> of mpl 87.5 (compatible with numpy 1.0b5) for os x?
>
> Sincerely,
> Brendan
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Sigh, this is driving me crazy
I tried downloading the Scipy-Superpack for os x from scipy.org, 
which supposedly contains compatible numpy and scipy binaries. But 
when I try to import pylab, I get:
---
 "RuntimeError: module compiled against version 90709 of C-API but 
this version of numpy is 1000000"
---
So I went off to find a newer build of matplotlib, but Sourceforge 
and pythonmac.org only have mpkg binaries for 87.4. I tried 
installing setuptools to use the .egg version, but didn't get very 
far before my head started hurting (who named this thing "easy"?). 
Similarly trying to compile the source code gives me:
---
C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/ 
MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp 
-mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3
compile options: '-I/usr/local/include -I/usr/include -I. -I/Library/ 
Frameworks/Python.framework/Versions/2.4/include/python2.4 -c'
gcc: src/_isnan.c
gcc: cannot specify -o with -c or -S and multiple compilations
---
Long story short, I'm giving up. Has anyone compiled an mpkg binary 
of mpl 87.5 (compatible with numpy 1.0b5) for os x?
Sincerely,
 Brendan
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

No problem. After upgrading to the latest mpl, and finding my changes not
there, I realized that I might as well make them into patches for my own use
in locally patching future releases, if for nothing else. If you end up
applying them to the base, all the better.
Thanks,
Bill
On 9/11/06, Ken McIvor <mc...@ii...> wrote:
>
> On Sep 10, 2006, at 9:50 AM, Bill Baxter wrote:
> >
> > I've just uploaded two patch files that apply the changes discussed
> > in this thread.
>
> Thanks Bill. I'm sorry I've been dragging a** on getting your
> patches reviewed. I'll try get to it early this week.
>
> Ken
>

On Sep 10, 2006, at 9:50 AM, Bill Baxter wrote:
>
> I've just uploaded two patch files that apply the changes discussed 
> in this thread.
Thanks Bill. I'm sorry I've been dragging a** on getting your 
patches reviewed. I'll try get to it early this week.
Ken

I've just uploaded two patch files that apply the changes discussed in this
thread.
-->
1555805
1555814
https://sourceforge.net/tracker/?func=detail&atid=560722&aid=1555805&group_id=80706
https://sourceforge.net/tracker/?func=detail&atid=560722&aid=1555814&group_id=80706
These were made against the latest release (xx.5 was it?)
Hopefully these will make it easer to integrate the changes.
--Bill
On 7/31/06, Ken McIvor <mc...@ii...> wrote:
> On Jul 30, 2006, at 8:07 AM, Bill Baxter wrote:
> > I went ahead and implemented this yesterday on a long plane flight.
> > The changed files (backend_bases.py, and widgets.py) are attached to
> > the above tracker entry. Also I changed backend_wx.py to grab the
> > mouse generally when you click on the graphs, so that panning and such
> > continues to track even when you go outside the window. Similar
> > changes should probably also be made to the other backends too.
>
> This sounds like it could be a pretty stellar improvement to the WX
> backend. Thanks!
>
> I should be at a work-related meeting on Tuesday with Matt Newville,
> the WX backend maintainer. I'll try to get some time set aside to
> get your changes merged on my laptop before them, so that we can
> check them out properly afterward. My big concern is to investigate
> how these changes may affect people who are embedding WxAgg figures
> in wxPython applications. If you've done what I think you have, that
> shouldn't be a problem.
>
> > I also added get_value methods to the CheckButtons and RadioButtons,
> > because it didn't seem like there was any good way to get that info.
>
> You may want to submit this portion of the changes as a separate
> patch. I've found that my patches get accepted faster when I only do
> one thing per patch.
>
> > Finally I don't really get what the deal is with the Slider's
> > "closedmin"/"closedmax" options.
>
> Sorry, I can't help you with this one.
>
> > Please let me know if there's a better way/place to submit patches.
>
> I've always done exactly what you're doing now: uploading it on SF
> then emailing the developers' list.
>
> Ken
>

On Sat, Sep 09, 2006 at 10:40:47AM -0600, Fernando Perez wrote:
> On 9/9/06, John Hunter <jdh...@ac...> wrote:
> > >>>>> "Fernando" =3D=3D Fernando Perez <Fer...@co...> =
writes:
> > Fernando> What I think could be improved in the default behavior
> > Fernando> is the legend. I'm sure there's a way to get the resul=
t
> > Fernando> even today
> > Indeed
> > legend(numpoints=3D2)
> > or set your rc setting
> > legend.numpoints =3D 2
> Great, thanks!
> > I'll change the default rc setting to two points if noone objects.
> +1 from me.
+1 from me to.
Ga=EBl

On 9/9/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
>
> Fernando> What I think could be improved in the default behavior
> Fernando> is the legend. I'm sure there's a way to get the result
> Fernando> even today
>
> Indeed
>
> legend(numpoints=2)
>
> or set your rc setting
>
> legend.numpoints = 2
Great, thanks!
> I'll change the default rc setting to two points if noone objects.
+1 from me.
Cheers,
f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> What I think could be improved in the default behavior
 Fernando> is the legend. I'm sure there's a way to get the result
 Fernando> even today
Indeed
 legend(numpoints=2)
or set your rc setting
 legend.numpoints = 2
I'll change the default rc setting to two points if noone objects.
JDH

Hi all,
I have a suggestion to make regarding the default results for legends when 
plots have both lines and markers. Consider the following plot commands:
plot(range(10),marker='o',linestyle='-',markerfacecolor='r',label='data')
legend()
I've attached a small png of what I get on my system, with a very recent svn 
build.
This is a common (at least for me) way to plot data points with a line for 
visual aid connecting the dots.
What I think could be improved in the default behavior is the legend. I'm 
sure there's a way to get the result even today, I'm just advocating for an 
improved out-of-the-box output. Currently, the code puts so many markers in 
the legend that the line is not visible. This isn't very pretty, nor very 
useful. In contrast, I think the gnuplot default behavior is a lot better, 
see this page for a simple example (no, I don't think that graph looks better 
than mpl, I just think the way /legend/ labels are created is clearer):
http://www.sbml.org/software/libsbml/libsbml-vs-xerces-dom-memusage.png
What I think would be a better default legend behavior than the current one 
would be either (ascii art, with 0 denoting a marker and - a line):
 (a) 0---0 OR (b) --0--
meaning two markers bracketing a bit of the line, or (like gnuplot) two line 
segments bracketing a single marker. The advantage of (a) IMO is that with 
dashed lines it is easier to read than (b), since there's a longer continuous 
section of line.
Just a suggestion...
f

Darren Dale wrote:
> On Friday 08 September 2006 10:29, Darren Dale wrote:
> 
>>On Friday 08 September 2006 10:11, Jouni K Seppanen wrote:
>>
>>>Hi,
>>>
>>>With numpy 1.0b5 and a recent matplotlib from svn (rev 2761), and
>>>numerix set to numpy, I'm getting errors like this:
>>>
>>>Python 2.4.3 (#1, Apr 7 2006, 10:54:33)
>>>[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
>>>Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>
>>>>>>from pylab import *
>>>>>>eye(3)
>>>
>>>Traceback (most recent call last):
>>> File "<stdin>", line 1, in ?
>>> File
>>>"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-pac
>>>ka ges/numpy/oldnumeric/mlab.py", line 24, in eye m =
>>>nn.equal(nn.subtract.outer(nn.arange(N), nn.arange(M)),-k) NameError:
>>>global name 'nn' is not defined
>>>
>>>Somehow numerix is getting the eye function from
>>>numpy.oldnumeric.mlab, and it's not working. Maybe this is a numpy
>>>bug,
>>
>>It is a numpy bug.
> 
> 
> And it has been fixed as of svn 3139.
> 
I should note, that you can install SVN version of NumPy without 
changing matplotlib. The 0.87.5 release should work for all of the 1.0 
and 1.0.X releases of NumPy
-Travis

On Friday 08 September 2006 10:29, Darren Dale wrote:
> On Friday 08 September 2006 10:11, Jouni K Seppanen wrote:
> > Hi,
> >
> > With numpy 1.0b5 and a recent matplotlib from svn (rev 2761), and
> > numerix set to numpy, I'm getting errors like this:
> >
> > Python 2.4.3 (#1, Apr 7 2006, 10:54:33)
> > [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
> > Type "help", "copyright", "credits" or "license" for more information.
> >
> > >>> from pylab import *
> > >>> eye(3)
> >
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in ?
> > File
> > "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-pac
> >ka ges/numpy/oldnumeric/mlab.py", line 24, in eye m =
> > nn.equal(nn.subtract.outer(nn.arange(N), nn.arange(M)),-k) NameError:
> > global name 'nn' is not defined
> >
> > Somehow numerix is getting the eye function from
> > numpy.oldnumeric.mlab, and it's not working. Maybe this is a numpy
> > bug,
>
> It is a numpy bug.
And it has been fixed as of svn 3139.

On Friday 08 September 2006 10:11, Jouni K Seppanen wrote:
> Hi,
>
> With numpy 1.0b5 and a recent matplotlib from svn (rev 2761), and
> numerix set to numpy, I'm getting errors like this:
>
> Python 2.4.3 (#1, Apr 7 2006, 10:54:33)
> [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> from pylab import *
> >>> eye(3)
>
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File
> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packa
>ges/numpy/oldnumeric/mlab.py", line 24, in eye m =
> nn.equal(nn.subtract.outer(nn.arange(N), nn.arange(M)),-k) NameError:
> global name 'nn' is not defined
>
> Somehow numerix is getting the eye function from
> numpy.oldnumeric.mlab, and it's not working. Maybe this is a numpy
> bug, 
It is a numpy bug. 
> but apparently the eye function that you get from numpy does 
>
> work:
> >>> from numpy import *
> >>> eye(3)
>
> array([[ 1., 0., 0.],
> [ 0., 1., 0.],
> [ 0., 0., 1.]])
>
> >>> eye.__module__
>
> 'numpy.lib.twodim_base'
>
> It seems that numerix is importing oldnumeric on purpose, but why is
> this?
The eye function in oldnumeric does not work, and we import from there to 
allow transparent compatibility between numpy, Numeric and numarray.

Hi,
With numpy 1.0b5 and a recent matplotlib from svn (rev 2761), and
numerix set to numpy, I'm getting errors like this:
Python 2.4.3 (#1, Apr 7 2006, 10:54:33) 
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from pylab import *
>>> eye(3)
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/numpy/oldnumeric/mlab.py", line 24, in eye
 m = nn.equal(nn.subtract.outer(nn.arange(N), nn.arange(M)),-k)
NameError: global name 'nn' is not defined
Somehow numerix is getting the eye function from
numpy.oldnumeric.mlab, and it's not working. Maybe this is a numpy
bug, but apparently the eye function that you get from numpy does
work:
>>> from numpy import *
>>> eye(3)
array([[ 1., 0., 0.],
 [ 0., 1., 0.],
 [ 0., 0., 1.]])
>>> eye.__module__
'numpy.lib.twodim_base'
It seems that numerix is importing oldnumeric on purpose, but why is
this?
-- 
Jouni