problem with 2.6.3.3 and matplotlib wxagg

Richard Harvey Chapman wrote:

Whenever I try to plot with the new wxPython, I get an error. Here are two sequences I used to test it. I upgraded to the latest matplotlib, 0.87.5 (from 0.86.2), just in case, but I received the same result. I use Numeric in matplotlib if that matters.

matplotlib wxAgg can be compiled in two ways: with the accelerator, which is faster, or without, which is slower. The downside of the accelerator is that it has to be compiled against the version of wxPython that is is used with, so you can't plug in a new wxPython with an older matplotlib and expect it to work.

This has been discussed recently on the matplotlib list (or maybe matplotlib-devel). With the new wxPython, there are now some methods for directly dumping data into a wx.Bitmap, so the wxAgg code could be written to not need the accelerator, which should help with this problem in the future. No one seems to have the time to do this right now, however. If you want to work on it, great!

So your options are:

1) Patch matplotlib wxAgg to use the new wx.Bitmap methods.

2) recompile MPL with the new wxPython

3) re-compile MPL without the accelerator enabled, and give up some performance.

4) you might be able to go in and hack the code a little to keep wxAgg from using the accelerator code, without re-building anything.

5) wait until someone else does one of those first.

-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

Chris.Barker@noaa.gov

Hello,

···

Am Mittwoch, den 06.09.2006, 10:06 -0700 schrieb Christopher Barker:

With the new wxPython, there are now some methods for
  directly dumping data into a wx.Bitmap,...

This sounds like a fast method of updating a display of a bitmap.
Which wxPython-version is this? Where can I find information about it?

Thanks

Lars

Hello,

from help(wx.App) and help(wx.PySimpleApp) I conclude that the usual way
of designing an application would be:

########################start code
class MyAppClass(wx.App):
  OnInit(self):
    #instantiate some wx.Frame objects here
app=MyAppClass(0)
app.MainLoop()
########################end code

Using wx.PySimpleApp, it would be like this:

########################start code
app = wx.PySimpleApp
#instantiate some wx.Frame objects here
app.MainLoop()
########################end code

Now, I found a third way, using PyShell as a frame of my application. I
tried the following:

########################start code
class MyAppClass(wx.App):
  OnInit(self):
    #instantiate a PyShell-Frame here
app=MyAppClass(0)
app.MainLoop()

#####start the above, then go to the PyShell-Frame and type:

app.frame=wx.frame(None)
app.frame.Show()

########################end code

This will also open a new frame. My question is: Is this safe? Is this a
way of creating my application's frames I can use without running into
big problems after some time? I really would like to use this way,
because the user of my application will use the PyShell-frame as his or
her main user-interface. Eventually, he or she will want to have a
special window for a special purpose. Then he or she could just
instantiate an object of the appropriate class derived from wx.frame,
and there the frame appears.

Thanks for every comment

Lars Friedrich

Hello,

from help(wx.App) and help(wx.PySimpleApp) I conclude that the usual way
of designing an application would be:

########################start code
class MyAppClass(wx.App):
  OnInit(self):
    #instantiate some wx.Frame objects here
app=MyAppClass(0)
app.MainLoop()
########################end code

Using wx.PySimpleApp, it would be like this:

########################start code
app = wx.PySimpleApp
#instantiate some wx.Frame objects here
app.MainLoop()
########################end code

wx.App and wx.PySimpleApp are functionally identical in modern wxPython
releases.

Now, I found a third way, using PyShell as a frame of my application. I
tried the following:

########################start code
class MyAppClass(wx.App):
  OnInit(self):
    #instantiate a PyShell-Frame here
app=MyAppClass(0)
app.MainLoop()

#####start the above, then go to the PyShell-Frame and type:
>>>app.frame=wx.frame(None)
>>>app.frame.Show()
########################end code

This will also open a new frame. My question is: Is this safe? Is this a
way of creating my application's frames I can use without running into
big problems after some time? I really would like to use this way,
because the user of my application will use the PyShell-frame as his or
her main user-interface. Eventually, he or she will want to have a
special window for a special purpose. Then he or she could just
instantiate an object of the appropriate class derived from wx.frame,
and there the frame appears.

Currently, basically every application that uses PyShell allows its
users to dig into the application state and do strange things. I have
never seen this as a good idea, not the least of which being...

    while 1: pass

Try running that in your application, heck, try running that in any GUI
application with an embedded Python shell. Be warned, your app will
probably stop responding and you will have to kill it.

Any time a user can destroy their own work so easily, it suggests that
there is likely a design failure (at least in my opinion). There are
many solutions to this, from custom languages (Mathematica, matlab, etc.),
to even external-process interpreters (see Idle and PyPE for Python
editors with shells that do this). Heck, you may find that your users
don't need or want to build new windows, etc., using wxPython,
especially by copying, pasting, etc., into a PyShell window.

Ask yourself if your users need this functionality. If so, ask yourself
if running the interpreter in another process is a reasonable solution
(I can point you to the relevant bits of PyPE if you are interested).
If not, ask yourself if you really want your users to be able to destroy
their work with a programming mistake.

- Josiah

···

Lars Friedrich <lfriedri@imtek.de> wrote: