[matplotlib-devel] Making WxMpl a matplotlib toolkit
Now that I've got a version of WxMpl that works properly I'd like to transition it over to being a matplotlib toolkit. From poking around in svn, it looks like the correct thing to do would be to import the source directory into '$(SVNROOT)/trunk/toolkits/wxmpl'. Is that correct? I'd like to try to get started on version 2.0 before I have my first carpal tunnel release surgery in later March. The goals would be: 1. Optional full support for MPL events 2. API for binding user interactions to selection and zoom behavior (e.g. "I want right-click selections to zoom in and the 'u' key to zoom out, like GNUPLOT") 3. API for controlling Axes zoom state What do you all think would be the best way to do this? Create a branch in '$(SVNROOT)/branches' for 1.3 maintenance? Ken -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] print_figure(), savefig() and file-like objects
Steve, I am aware of the caveats associated with the "name" attribute, which is why the code I sent you attempts to do the right thing when it doesn't exist. I hadn't considered the case of stdout, but you could probably detect situations like that by testing to see if the extension is the empty string: > # figure out what the format is > if extension is None or extension == '': > ... However, this variety of special case handling could make things more confusing for beginning users. I think ultimately you should do whatever you think strikes the best balance between convenience and clarity. On Jul 21, 2006, at 7:27 PM, Steven Chaplin wrote: > > I think an explicit 'format' argument is better than reading a 'name' > attribute which only works sometimes. In general I tend to agree with you, but I'd like to see Just Work when writing to an open file. I don't have a lot of stake in this either way, since I spend most of my time with matplotlib pushing the RGB data onto wxPython widgets. Ken - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib as a separate process
On Jul 24, 2006, at 9:16 PM, Bill Baxter wrote:
> I think all these problems could be fixed if the display interface
> were turned into a separate process that communicates with the Python
> program using pipes or some other IPC mechanism. I used this
> technique in a (C/C++) image debugging utility program I wrote
> (http://www.billbaxter.com/projects/imdebug) and it works quite well.
The biggest problem I see with this approach is that matplotlib has a
"display list" drawing model (as opposed to the "big matrix of
pixels" model). An example of what I mean is that when someone
resizes a {Gtk,Tk,Wx}Agg figure, the entire plot is re-rendered from
scratch to the new pixel dimensions. It could be a failure of
imagination, but I can't see how you could move the display interface
to a subprocess without moving the rest of matplotlib along with it.
I just can't see a clear line along which to separate out the "graph
display server" part.
> Has anyone given thought to making matplotlib work in such a manner?
> It would be hell to do in C or C++ I think, but with Python's
> extensive RPC libs I bet it wouldn't be so bad.
Python has extensive RPC libraries?!?! ;-)
In seriousness, RPC is an acknowledged weakness of Python's standard
library. For example, Python gives you a sockets API that is much
nicer to use than the BSD sockets API or WinSock, but which still
makes you worry about all of the platform-specific idiosyncrasies of
socket programming. It's my understanding that this is one of the
big reasons Twisted came into being.
As another example, before Python 2.4 added the "subprocess" module,
there was no portable way to spawn and communicate with
subprocesses... you'd have to worry about the shell of whatever
platform you were on mangling the commandline, you couldn't reliably
interrupt subprocesses on win32 (no os.kill() to send a SIGINT with),
etc.
The point of this long-winded email is that you probably could build
some kind of RPC system to run matplotlib remotely, but I believe it
would be an awful lot of work. In terms of manhours, my opinion is
that you'd come out ahead if you just focused on debugging your
current problems. I suspect that the matplotlib developers and
irregular contributers like myself will more able to help with that
debugging than we would be able to help with writing a display
server... but please don't think that I'm speaking for everyone!
Ken
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] wx-style layout engine for matplotlib: mplsizer
Andrew, This looks very cool, and I'm looking forward to playing around with it. Thanks for the hard work! Shooting from the hip, here are some initial comments. I may be able to submit patches for some of the more innocuous items later in the week. 1. It appears that as_sizer_element() uses the _axes_sizer_elements dictionary to cache MplAxesSizerElement instances. Using a WeakKeyDictionary from the "weakref" module instead of a regular dictionary may be necessary to allow the garbage collection of the MplAxesSizerElements when their associated Axes gets GC'd. 2. Convenience MplBoxSizer subclasses that let you omit the "orient" keyword might be nice: class MplHBoxSizer(MplBoxSizer): def __init__(self): MplBoxSizer.__init__(self, orientation='vertical') 3. Couldn't you just drop mplsizer.py into the "matplotlib.toolkits" virtual package? Maybe you can't -- I'm pretty new to applied python- eggery. 4. I feel we should avoid the whole European/American spelling problem that WX has. Why not make both 'align_centre' and 'align_center' do the same thing? 5. Why not use shorter names, with less redundancy? (e.g. "matplotlib.toolkits.sizer", FigureSizer, Box, HBox, Grid, etc) Ken - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [ 1530104 ] Slider should grab mouse
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: [wxPython-users] Re: using wxImage in C++ python extension]
Chris,
Thanks for the cross-post. I'm not sure this approach will help
speed up the wxAgg accelerator, but I'll put it on the list of things
to look into. The problem I foresee is that the Agg renderer's RGBA
data has to be converted to RGB before a wxImage can be created by
convert_agg2image().
Ken
On Aug 18, 2006, at 6:14 PM, Christopher Barker wrote:
> As a probably final installment in the thread about optimizing the wx
> back-end, here is a post from the wxPython list, in which someone
> posted
> SWIG code for making a PyBuffer from his data set, then using it to
> create a wx.Image without copying. A similar approach could be used
> for
> the wxAgg back-end.
>
> -Chris
>
> Original Message
> Subject: [wxPython-users] Re: using wxImage in C++ python extension
> Date: Fri, 18 Aug 2006 16:48:08 + (UTC)
> From: Andrew Murray <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> References: <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
>
> Hi all :)
>
> I've followed the combined advice of Robin and Christopher in using
> a python
> buffer object to instance a wx.Image in the python wrapper layer. It
> all seems
> to be working - and I don't think there are any 'data copies' going
> on ;)
>
> To keep my underlying C++ python-free, I introduced the buffer (and
> creation of
> the wx.Image) via my .i Swig file. In case anyone who is reading is
> keen trying
> to solve a similar problem, I've included the code that I added to
> my .i
> file in
> order to implement the change below. (I'd appreciate any comments
> regarding
> errors or shortcomings that anyone spots in my implementation.)
>
> Sorry I didn't reply to the thread earlier. A combination of being
> tied
> up with
> more boring work, moving house and background research into using
> python
> buffers
> with Swig means that I've only just got this far.
>
> One remaining question I have is: Does the call to wx.EmptyImage
> that I make
> cause any memory to be allocated? I see from Robin's recent post
> that in my
> case this call is now redundant (as I will soon be using
> ImageFromBuffer) - but
> I'm curious to know the answer anyway ;)
>
> Thanks for all the help. The more I use wxPython the more I like
> it...
>
> Andrew ;)
>
>
> /* the RawImage C++ class that we are wrapping offers a method that
> returns a pointer to an internal 'unsigned char' buffer of display
> data. To make the python class generated by SWIG a bit more
> friendly to the rest of our wxPython code we instruct SWIG to make
> two modifications during the wrapping process. First we add a
> method to the C++ class that will return a version of the internal
> display buffer wrapped up as a 'python buffer object' (performing
> this in the C++ wrapper class keeps the wrapped C++ python-
> free)...
> */
> %extend RawImage {
> PyObject* RawImage::getDisplayBuffer(void) {
> // return a new 'python buffer object' that intialised using
> // the memory address and length of our display buffer...
> void* pvBufferData = (void*)self->pcGetDisplayData();
> int iBufferSize = self->getDisplayBufferSize();
> return PyBuffer_FromMemory(pvBufferData, iBufferSize);
> }
> }
> /* ... we also add a method to the python wrapper class that will use
> the buffer offered by our new C++ method to create a wx.Image
> (neither of these methods actually copies the image data)...
> */
> %extend RawImage {
> %pythoncode %{
> def getImage(self):
> # create an unintialised wx.Image of the correct size...
> wximage = wx.EmptyImage(self.getWidth(), self.getHeight(),
> clear=False)
> # then define the data content of the image...
> wximage.SetDataBuffer(self.getDisplayBuffer())
> return wximage
> %}
> }
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: wxPython-users-
> [EMAIL PROTECTED]
>
>
> --
> 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
>
> [EMAIL PROTECTED]
>
> --
> ---
> 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
> [email protected]
> https://lists.sour
Re: [matplotlib-devel] [Fwd: [wxPython-users] Re: using wxImage in C++ python extension]
On 08/28/06 12:19, Christopher Barker wrote: > > wx is really due for an update to support alpha properly. But I guess > you'll always have problems with different data formats. I think they added preliminary support for alpha channels in 2.5, in the form of wx.Image.HasAlpha(). My beef is that you have to convert everything to a wx.Bitmap before you can do anything useful with it. > Anyway, this thread started because people were having binary > compatibility issues. Even if this doesn't speed up the accelerator, it > may be possible to get the same performance without using > wx-version-specific compiled code -- i.e. pure python. As near as I can tell, the primary slowdown at this point is the way wxWidgets distinguishes from RGB image data (wx.Image) as opposed to displayed image data (wx.Bitmap). Right now you cannot draw a wx.Image without first converting it into a wx.Bitmap, nor can you use a MemoryDC to blit or otherwise munge a wx.Image directly. My impression is that this made sense when wxWindows was getting started (Win16 and Motif), but is more of an artificial distinction at this point. I don't think we're going to be able to get performance similar to that of the accelerator using straight Python code unless something changes in the wxWidgets' Image/Bitmap/MemoryDC department. That being said, I'd love to be proven wrong! If you're interested in the gory details, you should check out the pure-Python implementation of the image conversion functions, at the end of `backend_wxagg.py'. > I do have one question -- does the agg back-end really need to use an > alpha channel for it's buffer? Isn't it the whole image anyway? What is > is it going to get blended with? I don't know enough about Agg to venture an educated guess. My un-educated guess is that there's an RGBA buffer to support alpha in the drawing operations... how can Agg alpha-composite new pixels into the buffer when you draw something, unless you know the alpha values of the existing pixels? Ken - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: [wxPython-users] Re: using wxImage in C++ python extension]
On 08/31/06 13:43, Christopher Barker wrote: > Ken McIvor wrote: > > a wxBitmap is the same format as the native rendering system. While most > systems use 24b RGB (or 32b RGBA), people can still run displays at > 16bpp or whatever, so it's still needed. I can understand why it's still necessary, although it's nice to sometimes pretend that everyone's running 24-bit color displays. I hope I didn't sound too judgemental! >>I don't think we're going to be able to get performance similar to that >>of the accelerator using straight Python code > > But whether it's Python or C++, you still need to do the Image->Bitmap > conversion -- so if we can get rid of the data copying from Agg buffer > to wxImage in Python, we don't need C++. I think we got some wires crossed at some point in the conversation, although it could be that I'm wearing the Stupid Hat today. I was talking about the image-from-a-buffer business not helping us with WX 2.4/2.6 due to the RGBA to RGB conversion. > And it has. For wxPython 2.7 (and now in CVS) there are methods for > dumping 32 bit RGBA data directly into a wxBitmap with no copying, if > the data source is a Python Buffer object. I think I posted a note about > this here yesterday. Yes, you did mention it. I agree completely with this analysis of the situation. When I replied I wasn't thinking in terms of wxPython 2.7. > To really get it to work, the 24bit RGB Agg buffer needs to be a Python > Buffer object -- is it now? I'm sorry I don't have the time to mess with > this now -- maybe some day. I guess Guido lets John borrow his time machine, because RendererAgg appears to already have a buffer_rgba() method. > You can alpha composite into a non-alpha background. You just lose the > alpha there, so that the background couldn't be alpha-composited onto > anything else -- but does it ever need to be? I thought that the buffer's accumulated alpha played a role in compositing new pixels onto it, but I apparently misunderstood. It must be time to read "Compositing Digital Images. Anyway, if the buffer's alpha channel isn't used, then the whole situation does seem a bit odd. Could the information be retained for PNGs or something? > However, there is something to be said for just using alpha everywhere, > and as we'll soon be able to dump RGBA data straight into a wx.Bitmap, > this should work great. Yes, it will be a great improvement over the current situation. Ken - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [ 1530104 ] Slider should grab mouse
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] WXAgg backend updates
Hello everyone, I just committed some accelerator-related updates to the WXAgg backend. I have fixed the problem with the way I was calling the wxBitmap constructor in _wxagg.src. More importantly, I written another set of the agg-to-wx.Bitmap conversion routines that uses the new BitmapFromBufferRGBA() function in wxPython 2.8. 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. 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. I'd really appreciate it if someone could test and benchmark those versions using `examples/animation_blit_wx.py'. Ken - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] WXAgg backend updates
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] WXAgg backend updates
FYI Christopher, et al. - Due to operator incompetence the changes I blabbed about earlier haven't hit the repository yet. Ken - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] WXAgg backend updates
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] building with python-2.3
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 - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] compiling matplotlib using VC6?
On Mar 16, 2007, at 9:28 AM, Berthold Höllmann wrote: > > I need a python compile with VC6. This python also needs a > matplotlib. Chris Barker and I worked on this a while ago, and I believe we decided it was impossible due to bugs/limitations in the VC++ 6 compiler. Ken - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib SVN trunk and wxPython 2.8.1.1
On Mar 16, 2007, at 4:24 PM, Berthold Höllmann wrote: > > Applying the following patch current matplotlib SVN compiles against > wxPython 2.8.1.1. The resulting module seems to work. That test is present in setupext.pu because I don't intend to support the C++ WXAgg accelerator module with wxPython 2.8 and later. Ken - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release?
On May 31, 2007, at 12:42 PM, Christopher Barker wrote: > > I think all the real work is done, but I"m not totally sure what's > checked in now. There may be some changes needed to the build > scripts so > that it doesn't try to build the accelerator by default. I'm not sure either. My modifications of setup.py, which disable the accelerator for wxPython >= 2.8, should already be in the trunk. I also modified backend_wxagg.py to ignore the accelerator when running with 2.8. I haven't heard any negative feedback about these changes, but I'm not sure anyone has rigorously tested them. > I propose that we just stop building the accelerator, and if people > want > better performance they need to switch to 2.8 (actually, I think the > pre-2.8 code could be improved with pure python too, but I"m not going > to bother, as I use 2.8 anyway) I'm fine with that, given that the difficulties of getting the accelerator built under Debian and Ubuntu make it pretty useless to my current target audience. It should be as simple making BUILD_WXAGG default to False. Ken - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release?
On May 31, 2007, at 12:51 PM, Charlie Moad wrote: > > It would be nice to use the pure-python wx so we don't have to > provide separate 2.6 and 2.8 builds. At this point it should be possible to include a _wxagg.so built for wxPython 2.6 and have everything Just Work with 2.8. If mixing versions causes linking errors it won't be hard to fix in backend_wxagg.py. Ken - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote: > > Interesting. I don't get that, but I do get some random segfaults (I > got lucky the first time I tested). It looks like wxPython doesn't retain a reference to the wxApp PyObj for you: [EMAIL PROTECTED]:~/Projects/matplotlib-svn$ pythonw Python 2.4.4 (#1, Oct 18 2006, 10:34:39) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import wx >>> app = wx.PySimpleApp() >>> del app >>> wx.GetApp() Segmentation fault > I'm awfully surprised that wx.GetApp() would return an iterator, as > you > are getting, so maybe it's corruption of some sort? My guess is that Eric got lucky and ob_type was pointing to the listiterator's C type instance. > Since I didn't want to just put the wxapp global variable back in, > I assigned it to the figure that creates it, therefore stick around > as long as the figure does. (Is that the correct thing for its > lifetime?) I don't think this will work if you create two figures, destroy the first one, and then create another figure. Once created, the wxApp needs to exist for the life of the python process. I'll go ahead an put the global variable back in. > Also, I'm a little puzzled by this code in show() in backend_wx.py: > > wxapp = wx.GetApp() > if wxapp is not None: > # wxPython 2.4 has no wx.App.IsMainLoopRunning() method > imlr = getattr(wxapp, 'IsMainLoopRunning', lambda: False) > if imlr(): > wxapp.MainLoop() > > If I'm reading this correctly, shouldn't it be "if not imlr()"? Yes, it should be. I'll try to code with my eyes open from now on. :-/ Ken - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Memory leaks
On Jul 5, 2007, at 3:48 PM, Eric Firing wrote: > > This qualifies as a wx bug, doesn't it? I believe so. I'll file it. > If wx doesn't retain the reference, then instead of a segfault > shouldn't it raise an exception? I'd expect wx.GetApp() to work like the rest of wxPython and always return the wx.App instance. This has been fixed in revision 3463. Ken - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
Wow, lots of food for thought. Thanks John! On Jul 19, 2007, at 12:18 PM, John Hunter wrote: = Objects that talk to the backend "primitives" = Have just a few, fairly rich obects, that the backends need to understand. Clear candidates are a Path, Text and Image, but despite their names, don't confuse these with the eponymous matplotlib matplotlib Artists, which are higher level than what I'm thinking of here (eg matplotlib.text.Text does *a lot* of layout, and this would be offloaded ot the backend in this conception of the Text primitive). This sounds like a great idea. I think you should consider making transformations a first-class citizen as well, to improve code readability. Some of us have to think really hard to translate "[[width, 0, 0], [0, -height, height], [0, 0, 1]]" into English! ;-) = Where do the plot functions live? = In matplotlib, the plot functions are matplotlib.axes.Axes methods and I think there is consensus that this is a poor design. Where should these live, what should they create, etc? I propose that the plot functions be replaced by plot classes that implement whatever the new Artist API ends up being. I'm not sure where I'd put them (grouped into modules by type?) or how they should be added to an Axes (add_artist()?). = How much of an intermediate artist layer do we need? = Do we want to create high level objects like Circle, Rectangle and Line, each of which manage a Path object under the hood? Yes, but I don't think they should be subclassed from Path. I found that rather confusing because I read that as "Rectangle is-a Path". = Z-ordering, containers, etc = Peter has been doing a lot of nice work on z-order and layers for chaco, stuff that looks really useful for picking, interaction, etc... We should look at this approach, and think carefully about how this should be handled. Is there somewhere in particular that I can look to see what Peter's been working on? Enthought's svn repositories? I also plan to use the SWIG agg wrapper, so this gets rid of _backend_agg. If we can enhance the SWIG agg wrapper, we can also do images through there, getting rid of _image.cpp. Having a fully featured, python-exposed agg wrapper will be a plus in mpl and beyond. But with the agg license change, I'm open to discussion of other approaches. Have you looked into Fredrik Lundh's aggdraw module? Apart from not yet supporting image drawing/blitting, I think it might do the trick. I've attached an aggdraw version your mpl1.py that I wrote as proof of concept. I opted to start hacking instead of installing the traits package, so there's just a basic demo of the renderer for now. Since aggdraw can work natively with the Python Imaging Library we'd be able to support every raster format under the sun *and* save those images to Python strings. That would make the webapps people very happy. I want to do away with *all* GUI extension code. Hurrah! This means someone needs to figure out how to get TkInter talking to a python buffer object or a numpy array. I think PIL's ImageTk module would do the trick for converting RGBA - > PIL Image -> Tk Bitmap/PhotoImage. = Traits = I think we should make a major committment to traits and use them from the ground up. Even without the UI stuff, they add plenty to make them worthwhile, especially the validation and notification features. I hate to be the first one to disagree, but here goes: traits give me the heebie-jeebies. I agree that matplotlib 1.0/2.0 needs to validate all user-settable parameters. However, I'm concerned about the development overhead that might result from making traits as a core dependency. Code readability is also a concern to me -- the experience of reading mpl1.py suggests to me that newcomers might find traits a bit too "voodoo". I'm confident that the same thing could be achieved using Python properties to validate attributes. Change notification is another matter, granted, but I think that a major rewrite will provide the opportunity to better design for those situations. Ken import aggdraw import Image import numpy as npy class Renderer: def __init__(self, width, height): self.width, self.height = width, height # almost all renderers assume 0,0 is left, upper, so we'll flip y here by default self.affinerenderer = npy.array( [[width, 0, 0], [0, -height, height], [0, 0, 1]], dtype=npy.float_) self.pathd = dict() # dict mapping path id -> path instance def add_path(self, pathid, path): self.pathd[pathid] = path def remove_path(self, pathid): if pathid in self.pathd: del self.pathd[pathid] def render_path(self, pathid): pass class RendererAggDrawPIL(Renderer): def __init__(self, width, height): Renderer.__init__(self, width, height) # XXX: this flips the origin without sc
Re: [matplotlib-devel] mpl1 draft
On Jul 20, 2007, at 6:26 AM, Michael Droettboom wrote: > Ken McIvor wrote: >>> >> I think PIL's ImageTk module would do the trick for converting >> RGBA -> >> PIL Image -> Tk Bitmap/PhotoImage. > > That's what I was thinking, too. I don't think there's a way to do > this > in a raw Tkinter. But is PIL something we plan to depend on? I don't know, although I'm warming to the idea myself. If we don't want the Tk backend to depend on PIL, we could create a string containing an X11 bitmap of the renderer's RGB array and use it to construct or update a Tkinter.BitmapImage. Ken - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
On Jul 23, 2007, at 7:18 PM, Peter Wang wrote: On Jul 19, 2007, at 10:42 PM, Ken McIvor wrote: Code readability is also a concern to me -- the experience of reading mpl1.py suggests to me that newcomers might find traits a bit too "voodoo". I'm confident that the same thing could be achieved using Python properties to validate attributes. This is a true statement. In fact, the first version of traits basically used properties to implement a lot of the validation and notification. Eventually for power and speed, we moved to using a metaclass with a C extension. I think the code readability question comes down to "is it easier for someone to learn some basic things about traits, or is it easier for them to decipher the massive jumble of property setters and getters I've wired up"? I think that the amount of duplicated code that has to written using simple python properties is non-trivial. In retrospect, I should've been clearer about my objection to using traits in mpl1. I don't have any problem with enthought.traits in an abstract sense -- it seems like an excellent solution to the problems of attribute validation and change notification. My concerns regard building a backend rendering system that uses change notifications to maintain graphics state. I believe this approach makes the rendering system harder to understand and optimize. Since my original comment about traits I have been working hard to put my money where my mouth is. Attached is an experimental rendering system with an alternative transform architecture that does not require attribute change notification. Please let me know what you think, everybody. Ken #!/usr/bin/env python # Name: mpl1_displaypdf.py # Purpose: Experimental rendering system using DisplayPDF's drawing model # Author: Ken McIvor <[EMAIL PROTECTED]> # # Copyright 2007 Illinois Institute of Technology # # Permission is hereby granted, free of charge, to any person obtaining # a copy of this software and associated documentation files (the # "Software"), to deal in the Software without restriction, including # without limitation the rights to use, copy, modify, merge, publish, # distribute, sublicense, and/or sell copies of the Software, and to # permit persons to whom the Software is furnished to do so, subject to # the following conditions: # # The above copyright notice and this permission notice shall be # included in all copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, # EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF # MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. # IN NO EVENT SHALL ILLINOIS INSTITUTE OF TECHNOLOGY BE LIABLE FOR ANY # CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, # TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE # SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. # # Except as contained in this notice, the name of Illinois Institute # of Technology shall not be used in advertising or otherwise to promote # the sale, use or other dealings in this Software without prior written # authorization from Illinois Institute of Technology. # # Derived from code Copyright 2007 John D. Hunter and released under the # license agreement for matplotlib 0.90.1 """ An experimental rendering system inspired by John Hunter's mpl1.py. This system uses a Renderer to draw series of Primitive plot objects on a Canvas implementing some of DisplayPDFs' drawing model and graphics state. The current transformation matrix is an affine transformation matrix are stored in PDF's form: a b 0 c d 0 e f 1 A Render uses the Canvas's DisplayPDF operations to draw Primitives on the Canvas. The Renderer draws in units of 1/72 of an inch with a scaling specified in dots-per-inch. Primitives may be modified at any time and may be shared between Renderers. A Canvas may have more than one Renderer associated with them. A Renderer may be associated with more than one Canvas during its lifetime. The Group primitives (Group, CanvasScaledGroup, and ScaledView) work like matlab's 'hgtransform' plot objects. The CanvasScaledGroup renderer works like an mpl1 FigurePane. """ from matplotlib import agg import numpy as npy def affine_identity(): """ a b 0 c d 0 e f 1 """ affine = npy.zeros((3,3), npy.float_) affine[0,0] = affine[1,1,] = affine[2,2] = 1 return affine def affine_from_values(a, b, c, d, e, f): affine = npy.zeros((3,3), npy.float_) affine[:,0] = a, c, e affine[:,1] = b, d, f affine[2,2] = 1 return affine def affine_from_rotation(angle): return affine_
Re: [matplotlib-devel] mpl1 draft
On Jul 24, 2007, at 10:46 AM, Gael Varoquaux wrote: > > AFAIK chaco is based on this approach. Not as such. Chaco uses traits for its high-level plot objects but the rendering system, Kiva, does not appear to use traits all. mpl1.py is using traits to maintain pre-calculated affine transformation matrices and graphics styles for each plot object. I believe this approach is confusing and results in rendering code that is hard to understand and optimize. > It makes a very nice API to use in interactive programs. I agree that an attribute-based API would much nicer for the high- level plot objects like Figure and Axes. However, I don't think traits are a technical necessity to accomplish that goal. > As far as understanding and optimizing it would be nice to see if > Peter Wang has something to say about this. It would be great to learn how Chaco/Kiva caches the things that I think of as "canvas primitives", like native AGG paths. I'd also be interested in learning how the transformation model is implemented in Chaco. Ken - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl1 draft
On Jul 25, 2007, at 12:09 PM, John Hunter wrote: > > Hi Ken -- sorry for the radio silence, I'm not intentionally ignoring > you. Real life has made some demands on my time of late, and probably > will until next week, but I was able to download, read through and > test your code. I appreciate you making the time to take a look at my code in spite of it. > But I don't think that closes the book on the subject -- for > example, I have realized I am introducing too much complexity and > trait forwarding, and I think I know a way to work around this, so > I will be hacking through my version one more time while at the > same time taking a closer look at yours. I'd hardly expect it to close the book on the subject. Although it functions as a proof-of-concept, my rendering model needs more work before it can handle special cases like the blended affine transformation to plot an axis. I've been thinking about how best to accomplish this and will try to have something for you to look at by early next week. Please drop me a line when you're satisfied with your changes to mpl1.py, as I'm looking forward to seeing them. > I also would like to hear more about the "hard to optimize" part, > because that is not intuitively clear to me. Moving to a rendering model when the primitives modify the CTM instead of replacing it with a pre-calculated value removes the dependency between primitives and their containers. A Primitive object, like a Path, may be reused and shared between renderers. The native version of a Primitive object is stored by the Primitive object itself, so it can be reused by any Canvas that draws the Primitive. This also means that you incur very little cost in clearing a Renderer and then repopulating it with existing Primitives. An Artist-level implementation of z-order could leverage this to avoid having to sort primitives by z-order every time a figure is rendered. Since primitives modify graphics state instead of replacing it wholesale the it's easier for the Canvas to push as few changes to the backend as possible. For example, if none of the child primitives of a ScaledView have their own transforms then the CTM only gets modified once when the ScaledView is rendered. The same is true for all of the other graphics state parameters, like linewidth and strokecolor. This saves on unnecessary backend overhead (e.g. creating the same agg.trans_affine repeatedly). It could also lead to tighter PDF and EPS output. Finally, the Renderer class is canvas-independent so it can be used to draw on multiple canvases during the course of its lifetime. I hope this will substantially simplify the process of saving a figure that was drawn interactively. I'm also contemplating making Renderers able to contain child Renderers so parts of a figure can be selectively updated. For example, drawing the non-Axis children of an Axes by using a subrenderer could further improve animation performance. > I confess to being a meta-class ignoramus, so I am intrigued to study > how you handled the canvas primitive cache problem using meta classes. I hate to disappoint you, but metaclasses aren't involved. Right now the caching is implemented cooperatively by Canvas and CanvasPrimitive to reduce duplicate code. CanvasPrimitive.get_canvas_primitive() handles the caching logic and calls CanvasPrimitive.create_canvas_primitive() to create a new native object if necessary. Subclasses of CanvasPrimitiveoverride create_canvas_primitive() to delegate the call to the appropriate method of Canvas, e.g. Path.create_canvas_primitive() returns the result of Canvas.create_canvas_path(). Subclasses of Canvas that do not cache Primitives should not override the create_canvas_xxx() methods. > How for example, if one modifies a Rectangle object which embodies a > path primitive, would the canvas get the notification to update it's > internal path representation (egg the agg_path_storage)?. Native canvas objects are always created at render-time, so rectangle would just update its associated Path instance when its bounds changed. The next time the Path is drawn, Canvas.draw_path() would call CanvasPrimitive.get_canvas_primitive() and end up with a new AGG path. That being said, it might be more efficient if all Rectangles share one Path that draws a unit square and change its size by updating the CTM. > With traits, I use the trait event handling mechanism so that when > any of > the box properties (left, width, top, etc...) are modified, the > PathPrimitiveAgg would get a callback. So when the user does > > rect.left = 0.1 > > the agg path knows to update itself. This is pretty cool. Yes it is, and I agree that mpl1 should have an attribute-based API for modifying plot object parameters. > vis-a-vis properties vs traits, I second Peter's comment that once > you've written 8,000 setters and getters and
Re: [matplotlib-devel] matplotlib installation error
On Aug 29, 2007, at 1:59 PM, Hardeep Nahal wrote: > > build/temp.linux-x86_64-2.3/src/_na_backend_agg.o -L/usr/local/lib > -L/usr/lib -L/usr/lib64 -L/usr/local/lib -L/usr/lib -L/usr/lib64 -lpng > -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o > build/lib.linux-x86_64-2.3/matplotlib/backends/_na_backend_agg.so > /usr/bin/ld: /usr/local/lib/libpng.a(png.o): relocation R_X86_64_32 > against `a local symbol' can not be used when making a shared object; > recompile with -fPIC > /usr/local/lib/libpng.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > error: command 'c++' failed with exit status 1 You need to either recompile libpng so it builds a shared library or delete `/usr/local/lib/libpng.a' so gcc picks up the default version provided by Debian. > I think this Debian distribution of matplotlib (which is older than > the current release) is incompatible with the current version of > numpy/Numeric that I have installed, but I'm not sure. I would rather > have the latest matplotlib vesrion installed (version 0.90.1), but I > can't seem to get it to even build properly. Did you install your own copy of numpy or are you using the one that comes with Debian? If you're using the one that comes with Debian, I'll try to reproduce the problem and file a bug report. Ken - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib installation error
On Aug 29, 2007, at 5:12 PM, Hardeep Nahal wrote: > > Yes, I think my libpng library was corrupt, but when I tried > reinstalling, it still wouldn't work. It's not corrupt, it's just not the correct kind of library. There are two types: static libraries (.a), which get compiled into a program, and shared libraries (.so), which are stored outside of the program. Trying to compile a shared library that uses a static library is always a bit dodgy and sometimes fails completely. If you really need to use your own copy of libpng you should re-run the configure script with the "--enable-shared" option and then recompile. Since you're using Debian I'd advise you to just use the libraries it provides whenever possible. That ought to make your life easier. > It appears the matplotlib and numpy packages that come with Debian are > incompatible. I have been unable to reproduce the problem you were having with the Debian matplotlib and numpy packages. I'd appreciate more details about the packages you had installed, if you don't mind breaking your system again briefly. Could you please reinstall them, verify that the problem still occurs, and then email me the output of the following four commands? If you don't have time to work on this right now don't worry about it. Here are the commands which will provide me with the information I require: $ cat /etc/debian_version $ dpkg -s python $ dpkg -s python-numpy $ dpkg -s python-numarray Thanks, Ken - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Backends status on transforms branch
On Nov 8, 2007, at 12:17 PM, Christopher Barker wrote: > > I wonder if there is another way to speed that up with Agg -- can you > compress the bitmap data to pass it to the Xserver? is that happening > already? I'm not aware of any obvious method for enabling compression in remote X11 connections. Using the NX remote desktop system might be faster: http://www.nomachine.com Ken - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Backends status on transforms branch
On Nov 8, 2007, at 10:23 AM, Michael Droettboom wrote: > > So, we need to look at the pros/cons of continuing to support these > legacy APIs going forward. I've got some more benchmarks for the WX and WXAgg backends in trunk. It looks like using ssh with compression or the NX remote desktop both substantially improve performance. I don't know why WXAgg consistently outperforms WX for me, but my guess is that the difference involves Apple's X server. X11 Remote WX: 0.96 fps WXAgg: 1.93 fps X11 Remote w/compression WX: 3.93 fps WXAgg: 6.43 fps NX WX: 7.39 fps WXAgg: 10.83 fps Local WX:11.91 fps WXAgg: 19.16 fps Ken - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AttributeError: 'module' object has no attribute 'GraphicsContext'
Nils, To the best of my knowledge the wx.GraphicsContext class is not present in wxPython 2.6. Ken - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AttributeError: 'module' object has no attribute 'GraphicsContext'
On Jun 12, 2008, at 3:22 PM, John Hunter wrote: > > If some wx guru sees an easy fix here, by all means add it. Not to imply that I'm a guru, but I'll try to look into it this evening. > Otherwise, we should decide on a minimum wxpython version for the > trunk and raise an exception. I'm always in favor of ensuring that MPL can run on Debian Stable without too much pain and suffering. Doing so would entail supporting wxPython 2.6. Ken - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
