matplotlib-devel Mailing List for matplotlib

On Jan 8, 2006, at 9:55 AM, Charlie Moad wrote:
> I ended up using their win-devel pkg and got the same results.
If wxPython was built with Microsoft Visual C++, then this behavior 
makes some kind of sense. Should matplotlib be built with VC++, I'd 
still recommend using the win-devel package to ensure compatibility 
with the stable version of wxPython.
> Well, decision time. Should we go ahead and push a mpl release
> without wx blitting on windows? I personally think there have been
> more than enough changes to justify it.
By all means. WXAgg still works without the _wxagg module, as does 
FigureCanvasWxAgg.blit(). It's just slower, because the Agg- 
 >wx.Bitmap conversion is done in pure Python when the _wxagg module 
isn't present.
Ken

> That's pretty strange behavior in a compiler. The compiler output
> you posted earlier doesn't make it clear how your build environment
> was set up. It seems to me that the _wxagg extension must be built
> using the wxPython-win32-devel headers and libraries to ensure
> compatibility with the current stable version of wxPython and wxWidgets.
I ended up using their win-devel pkg and got the same results.
Well, decision time. Should we go ahead and push a mpl release
without wx blitting on windows? I personally think there have been
more than enough changes to justify it.
- Charlie

Greetings,
I was able to make a small change to axes.py which augments errorbar() with a 
keyword, 'ealpha' (similar to 'ecolor'), which controls the alpha blending of 
the error bar lines. The motivation was to make overlapping error bars of 
different color slightly less confusing (or at least more interesting). It's 
up to the user to resist the temptation to utilize it for "error 
reduction." ;)
Patch attached, use ad lib.
Mike

On Jan 7, 2006, at 3:33 PM, Charlie Moad wrote:
> I was on the wx list a little and got some help, but no solutions.
> Basically I get the same linker errors if I pass no wx libs, so mingw
> is not finding any symbols in the libraries. It is not complaining
> about the libraries either.
That's pretty strange behavior in a compiler. The compiler output 
you posted earlier doesn't make it clear how your build environment 
was set up. It seems to me that the _wxagg extension must be built 
using the wxPython-win32-devel headers and libraries to ensure 
compatibility with the current stable version of wxPython and wxWidgets.
This may result in an extension that only works with one version of 
wxPython. I'm not sure how best to deal with that situation in a 
binary distribution. It may be to build a _wxagg extension for 
several versions of wxPython and select the right one at run time.
> Someone on the list said the c++ symbols are mangled by visual studio,
> so the only way to get it to work is compile _wxagg wil vs.
That's something I hadn't considered before now, but is no doubt the 
case. There isn't a standard application binary interface for C++ 
compilers, so they tend to use different name mangling schemes to 
discourage you from shooting your foot (e.g. by linking incompatible 
object files together into an application that doesn't work).
I'm afraid I'm not going to be of much help here, since don't have 
easy access to a windows computer. I just got back from the lab, 
where I spent several hours trying to get the build environment setup 
so I could build matplotlib. I gave up in the end, having failed to 
get the Agg backend to build due to weird linking errors.
If anyone needs me I'll be hugging my iBook and crying. ;-)
Ken