AttributeError: 'module' object has no attribute 'GraphicsContext'

_Nils_Wagner1 · June 12, 2008, 7:23pm

Hi All,

I have changed the backend in matplotlibrc from GTKAgg to WX

#### CONFIGURATION BEGINS HERE
# the default backend; one of GTK GTKAgg GTKCairo FltkAgg QtAgg TkAgg
# WX WXAgg Agg Cairo GD GDK Paint PS PDF SVG Template
#backend : GTKAgg
backend : WX

Now I get

python -i nlp_3.py --verbose-helpful
$HOME=/home/nwagner
CONFIGDIR=/home/nwagner/.matplotlib

Bad key "text.markup" on line 154 in
/home/nwagner/.matplotlib/matplotlibrc.
You probably need to get an updated matplotlibrc file from
http://matplotlib.sf.net/matplotlibrc or from the matplotlib source
distribution
matplotlib data path /usr/local/lib64/python2.5/site-packages/matplotlib/mpl-data
loaded rc file /home/nwagner/.matplotlib/matplotlibrc
matplotlib version 0.98.0
verbose.level helpful
interactive is False
units is False
platform is linux2
Using fontManager instance from /home/nwagner/.matplotlib/fontManager.cache
numerix numpy 1.2.0.dev5282
backend WX version 2.6.3.3

···

-----------------------------------------------------
starting solver ipopt (license: CPL) with problem nlp3
[PyIPOPT] Ipopt will use Hessian approximation.
[PyIPOPT] nele_hess is 0
  iter objFunVal log10(maxResidual)
     0 -1.640e+02 0.81
Traceback (most recent call last):
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1051, in _onSize
     self.draw()
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 889, in draw
     self.figure.draw(self.renderer)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/figure.py", line 745, in draw
     if self.frameon: self.figurePatch.draw(renderer)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/patches.py", line 222, in draw
     gc = renderer.new_gc()
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 359, in new_gc
     self.gc = GraphicsContextWx(self.bitmap, self)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 456, in __init__
     gfx_ctx = wx.GraphicsContext.Create(dc)
AttributeError: 'module' object has no attribute 'GraphicsContext'
Traceback (most recent call last):
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1051, in _onSize
     self.draw()
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 889, in draw
     self.figure.draw(self.renderer)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/figure.py", line 745, in draw
     if self.frameon: self.figurePatch.draw(renderer)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/patches.py", line 222, in draw
     gc = renderer.new_gc()
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 359, in new_gc
     self.gc = GraphicsContextWx(self.bitmap, self)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 456, in __init__
     gfx_ctx = wx.GraphicsContext.Create(dc)
AttributeError: 'module' object has no attribute 'GraphicsContext'
Traceback (most recent call last):
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1051, in _onSize
     self.draw()
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 889, in draw
     self.figure.draw(self.renderer)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/figure.py", line 745, in draw
     if self.frameon: self.figurePatch.draw(renderer)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/patches.py", line 222, in draw
     gc = renderer.new_gc()
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 359, in new_gc
     self.gc = GraphicsContextWx(self.bitmap, self)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 456, in __init__
     gfx_ctx = wx.GraphicsContext.Create(dc)
AttributeError: 'module' object has no attribute 'GraphicsContext'
Traceback (most recent call last):
   File "nlp_3.py", line 65, in <module>
     r = p.solve(solver)
   File "/usr/local/lib64/python2.5/site-packages/scikits/openopt/Kernel/BaseProblem.py", line 239, in solve
     return runProbSolver(self, solvers, *args, **kwargs)
   File "/usr/local/lib64/python2.5/site-packages/scikits/openopt/Kernel/runProbSolver.py", line 221, in runProbSolver
     solver(p)
   File "/usr/local/lib64/python2.5/site-packages/scikits/openopt/solvers/CoinOr/ipopt_oo.py", line 78, in __solver__
     p.iterfcn(p.x0)
   File "/usr/local/lib64/python2.5/site-packages/scikits/openopt/Kernel/BaseProblem.py", line 57, in <lambda>
     self.iterfcn = lambda *args: ooIter(self, *args)# this parameter is only for OpenOpt developers, not common users
   File "/usr/local/lib64/python2.5/site-packages/scikits/openopt/Kernel/ooIter.py", line 78, in ooIter
     for df in p.graphics.drawFuncs: df(p)
   File "/usr/local/lib64/python2.5/site-packages/scikits/openopt/Kernel/ooGraphics.py", line 127, in oodraw
     if self.nSubPlots>1: pylab.subplot(self.nSubPlots, 1, 1)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 518, in subplot
     fig = gcf()
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 210, in gcf
     return figure()
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 200, in figure
     draw_if_interactive()
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1167, in draw_if_interactive
     figManager.canvas.draw()
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 889, in draw
     self.figure.draw(self.renderer)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/figure.py", line 745, in draw
     if self.frameon: self.figurePatch.draw(renderer)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/patches.py", line 222, in draw
     gc = renderer.new_gc()
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 359, in new_gc
     self.gc = GraphicsContextWx(self.bitmap, self)
   File "/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 456, in __init__
     gfx_ctx = wx.GraphicsContext.Create(dc)
AttributeError: 'module' object has no attribute 'GraphicsContext'

Any idea ?

Nils

_John_Hunter · June 12, 2008, 7:54pm

Unfortunately, I do not have access to wxpython 2.6. Perhaps you can
inspect the wx namespace and see if there is anything like a
GraphicsContext, eg by using dir(wx) or wx.G<TAB> in ipython.

JDH

···

On Thu, Jun 12, 2008 at 2:23 PM, Nils Wagner <nwagner@...607... wrote:

"/usr/local/lib64/python2.5/site-packages/matplotlib/backends/backend_wx.py",
line 456, in __init__
gfx_ctx = wx.GraphicsContext.Create(dc)
AttributeError: 'module' object has no attribute
'GraphicsContext'

Any idea ?

Ken_McIvor2 · June 12, 2008, 8:07pm

Nils,

To the best of my knowledge the wx.GraphicsContext class is not present in wxPython 2.6.

Ken

_Chris.Barker · June 12, 2008, 8:12pm

John Hunter wrote:

AttributeError: 'module' object has no attribute
'GraphicsContext'

Unfortunately, I do not have access to wxpython 2.6.

wx.GraphicsContext was introduced in wxPython 2.8 -- it's never going to work with 2.6 or older.

Personally, I think we should just focus on wxAgg, but if people need to use it over a remote X connection, that may not be acceptable.

-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

Chris.Barker@...236...

_John_Hunter · June 12, 2008, 8:22pm

Nils, part of what we are trying to do on the 0.98 release series is
remove a lot of legacy code supporting 18 versions of everything. For
folks who need older numpy, older wx, etc, we have the 0.91
maintenance branch. For folks who want the latest matplotlib, they
will need to be willing to upgrade to a recent numpy and wxpython. I
looked briefly at the graphics context issue -- with the exception of
the call to GetFullTextExtent, all the calls are to SetPen, so we
could just use the MemoryDC dc object for those. But I am not
inclined to put a lot of version conditional stuff in the wx backend
code for the reasons mentioned above.

If some wx guru sees an easy fix here, by all means add it.
Otherwise, we should decide on a minimum wxpython version for the
trunk and raise an exception.

JDH

···

On Thu, Jun 12, 2008 at 3:07 PM, Ken McIvor <mcivor@...227...> wrote:

To the best of my knowledge the wx.GraphicsContext class is not
present in wxPython 2.6.

Ken_McIvor2 · June 12, 2008, 8:38pm

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

···

On Jun 12, 2008, at 3:22 PM, John Hunter wrote:

_John_Hunter · June 12, 2008, 9:02pm

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.

Well, you are a guru to us

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.

It looks like debian stable is now packaging numpy 1.01. Am I reading
this right?

Debian -- Package Search Results -- python-numpy

I think it is reasonable for folks who want the latest mpl to be
willing to get the latest numpy. For the GUI toolkits, given how hard
they are to build, your suggestion of targeting debian stable may be
more reasonable, but supporting multiple GUI versions has always been
a pain since we definitely want to support the most recent.

wxpython is on 2.8.7 and stable is still 2.6? pygtk is at 2.10 and
debian stable is at 2.6. matplotlib is at 0.98 and debian stable is
at 0.87 (Oct 2006 release). So if we want to support stable, *and*
the latest releases, we've got a lot of ongoing compatibility work to
do. For backend maintainers willing to do it, I think that will be
good. But I am hesitant to target such a slow moving repository as a
requirement.

JDH

···

On Thu, Jun 12, 2008 at 3:38 PM, Ken McIvor <mcivor@...227...> wrote:

On Jun 12, 2008, at 3:22 PM, John Hunter wrote:

_Chris.Barker · June 12, 2008, 9:02pm

John Hunter wrote:

If some wx guru sees an easy fix here, by all means add it.
Otherwise, we should decide on a minimum wxpython version for the
trunk and raise an exception.

I don't know how GraphicsContext is used in MPL, but it provides nifty features like alpha blending and anti-aliasing -- if we want those features, we need it, and 2.6 is out.

On the other hand, we can get all that with wxAgg, so maybe keeping the plain wx back-end simple, and use only DCs is fine.

Personally, I use recent wx versions and wxAgg, so it makes no difference to me.

Ken,

Thanks for you work on the wx back-ends in general

-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

Chris.Barker@...236...

Chris_Walker · June 13, 2008, 2:25pm

"John Hunter" <jdh2358@...149...> writes:

>>
>> 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.

Well, you are a guru to us

>> 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.

It looks like debian stable is now packaging numpy 1.01. Am I reading
this right?

Debian -- Package Search Results -- python-numpy

Yes, that's right. 1.1 is likely to be in the next debian release.

I think it is reasonable for folks who want the latest mpl to be
willing to get the latest numpy. For the GUI toolkits, given how hard
they are to build, your suggestion of targeting debian stable may be
more reasonable, but supporting multiple GUI versions has always been
a pain since we definitely want to support the most recent.

wxpython is on 2.8.7 and stable is still 2.6? pygtk is at 2.10 and
debian stable is at 2.6. matplotlib is at 0.98 and debian stable is
at 0.87 (Oct 2006 release).

September is the target date for the next release of debian according
to the release schedule at:

http://lists.debian.org/debian-devel-announce/2008/06/msg00000.html

The packages currently in debian are:

                            Distribution(codename)

Package Stable Testing Unstable
                  (etch) (lenny) (sid)
python-matplotlib 0.87.7-0.3 0.91.2-2 0.91.2-2
python-wxversion 2.6.3.2.1.5 2.6.3.2.2-2 2.6.3.2.2-2
python-gtk2 2.8.6-8 2.12.1-1 2.12.1-6
python-numpy 1:1.0.1-1 1:1.0.4-8 1:1.1.0-1
python 2.4.4-2 2.5.2-1 2.5.2-1

There is also
python-wxversion (2.8.7.1-0.1) in experimental.

Packages are uploaded to unstable. If after a period of time (usually
10 days) there are no major bugs found, and their dependencies can be
met by packages in testing, they migrate to testing.
For more details Debian -- Debian “trixie” Release Information and
Debian “testing” distribution

Thus packages in "testing" will be in the next stable release (barring
show stopping bugs), packages in "unstable" will probably be in the
next stable release, and packages in "experimental" may or may not be
in the next stable release.

Thus I'd expect python-numpy 1.1.0 to make the next release, but
python-wxversion (2.8.7.1) is looking a bit marginal.

So if we want to support stable, *and*
the latest releases, we've got a lot of ongoing compatibility work to
do. For backend maintainers willing to do it, I think that will be
good. But I am hesitant to target such a slow moving repository as a
requirement.

Would the next debian release (lenny) be a better target for
development versions of matplotlib?

What version of matplotlib do you want to go into the next debian release?

Chris

···

On Thu, Jun 12, 2008 at 3:38 PM, Ken McIvor <mcivor@...227...> wrote:
> On Jun 12, 2008, at 3:22 PM, John Hunter wrote:

_John_Hunter · June 13, 2008, 2:52pm

Hi Chris -- thanks for all the information. Since 0.98 requires numpy
1.1, 0.98.1 (a bugfix release slated for next week or the week after)
should be in unstable and 0.91.4 (again a bugfix scheduled for next
week or the week after) should be in testing and 0.91.2 should be in
stable. I find this a bit conservative, since I think numpy 1.1
should be in testing along with matplotlib 0.98.1, but that is
apparently how debian does it.

JDH

···

On Fri, Jun 13, 2008 at 9:25 AM, Chris Walker <chrisw@...235...> wrote:

So if we want to support stable, *and*
the latest releases, we've got a lot of ongoing compatibility work to
do. For backend maintainers willing to do it, I think that will be
good. But I am hesitant to target such a slow moving repository as a
requirement.

Would the next debian release (lenny) be a better target for
development versions of matplotlib?

What version of matplotlib do you want to go into the next debian release?

Chris_Walker · June 13, 2008, 5:26pm

"John Hunter" <jdh2358@...149...> writes:

>> So if we want to support stable, *and*
>> the latest releases, we've got a lot of ongoing compatibility work to
>> do. For backend maintainers willing to do it, I think that will be
>> good. But I am hesitant to target such a slow moving repository as a
>> requirement.
>
> Would the next debian release (lenny) be a better target for
> development versions of matplotlib?
>
> What version of matplotlib do you want to go into the next debian release?

Hi Chris -- thanks for all the information.

Pleasure, Hope it was useful, but please note I don't speak for the
Debian Matplotlib maintainers.

There are some things I need to clarify though.

Since 0.98 requires numpy
1.1, 0.98.1 (a bugfix release slated for next week or the week after)
should be in unstable and 0.91.4 (again a bugfix scheduled for next
week or the week after) should be in testing

Ah, I think you may have misunderstood how debian
stable/testing/unstable works.

A grossly oversimplified view[1] is as follows.

1) A new version of the package is uploaded to sid (unstable)

2) When the package has been in sid (unstable) for 10 days, it is a
candidate for moving to lenny (testing). when they can do so
without breaking other packages lenny (testing).

3) Eventually, lenny is released as the stable distribution, and you
are stuck with it for a year or two (except security or dataloss
bugs).

so it sounds like 0.98.x should be what is uploaded to unstable (from
where it will migrate to testing).

and 0.91.2 should be in
stable.

The version in etch (stable) is only likely to be upgraded (from
0.87.7-0.3) if there are major bugs (such as security problems or data
loss issues). See Debian -- Security Information

I find this a bit conservative, since I think numpy 1.1
should be in testing

It was only uploaded 3 days ago, so in theory could migrate in 7 days
time.

along with matplotlib 0.98.1,

Debian Package Tracking System - matplotlib gives debian package
information on matplotlib - including which versions are in
stable,testing and unstable. Hopefully 0.98.0 or 0.98.1 packages will
be uploaded soon. If not, then giving the maintainers a push to ensure
they are in the next debian stable would be a good idea.

but that is
apparently how debian does it.

Hopefully that is now slightly clearer.

Chris

[1] Packages can migrate more quickly if they contain urgent bug fixes
http://www.debian.org/ and specifically
Debian “testing” distribution contains more accurate
information.

···

On Fri, Jun 13, 2008 at 9:25 AM, Chris Walker > <chrisw@...235...> wrote:

Manuel_Metz1 · June 17, 2008, 12:07pm

Chris Walker wrote:

"John Hunter" <jdh2358@...149...> writes:

So if we want to support stable, *and*
the latest releases, we've got a lot of ongoing compatibility work to
do. For backend maintainers willing to do it, I think that will be
good. But I am hesitant to target such a slow moving repository as a
requirement.

Would the next debian release (lenny) be a better target for
development versions of matplotlib?

What version of matplotlib do you want to go into the next debian release?

Hi Chris -- thanks for all the information.

Pleasure, Hope it was useful, but please note I don't speak for the
Debian Matplotlib maintainers.

There are some things I need to clarify though.

Since 0.98 requires numpy
1.1, 0.98.1 (a bugfix release slated for next week or the week after)
should be in unstable and 0.91.4 (again a bugfix scheduled for next
week or the week after) should be in testing

Ah, I think you may have misunderstood how debian
stable/testing/unstable works.

A grossly oversimplified view[1] is as follows.

1) A new version of the package is uploaded to sid (unstable)

2) When the package has been in sid (unstable) for 10 days, it is a
   candidate for moving to lenny (testing). when they can do so
   without breaking other packages lenny (testing).

3) Eventually, lenny is released as the stable distribution, and you
   are stuck with it for a year or two (except security or dataloss
   bugs).

so it sounds like 0.98.x should be what is uploaded to unstable (from
where it will migrate to testing).

and 0.91.2 should be in
stable.

The version in etch (stable) is only likely to be upgraded (from
0.87.7-0.3) if there are major bugs (such as security problems or data
loss issues). See Debian -- Security Information

I find this a bit conservative, since I think numpy 1.1
should be in testing

It was only uploaded 3 days ago, so in theory could migrate in 7 days
time.

along with matplotlib 0.98.1,

Debian Package Tracking System - matplotlib gives debian package
information on matplotlib - including which versions are in
stable,testing and unstable. Hopefully 0.98.0 or 0.98.1 packages will
be uploaded soon. If not, then giving the maintainers a push to ensure
they are in the next debian stable would be a good idea.

Hi,
the debian maintainers are already aware of the new versions, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486074

According to them, matplotlib 0.98.x will be uploaded to experimental first, before it migrates to unstable. Unstable has been updated to 0.91.3 some days ago.

Manuel

···

On Fri, Jun 13, 2008 at 9:25 AM, Chris Walker >> <chrisw@...235...> wrote:

_Sandro_Tosi · June 17, 2008, 2:58pm

Hi guys,
sorry to have spotted it out late (the thread subject don't help
and thanks to Manuel to have notified me about this thread.

the debian maintainers are already aware of the new versions, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486074

According to them, matplotlib 0.98.x will be uploaded to experimental
first, before it migrates to unstable. Unstable has been updated to
0.91.3 some days ago.

My plan (as one of maintainers of matplotlib in Debian) is to keep
uploading 0.91.x in unstable, so it can migrate to testing (the
staging area to prepare the next stable release) when needed, and
prepare the 0.98.x package into experimental. I need this since 0.98
introduced API changes, and I need to let depending packages check if
they are compatible with this new version (if not, adapting them)
before uploading to unstable and break things.

Since numpy in unstable is already at 1.1.0 (scheduled to be migrated
in testing in few days), I try my best to have 0.98.x in unstable
asap, so to let lenny (the upcoming stable release) ship 0.98.x!

Cheers,
Sandro

···

--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

_John_Hunter · June 17, 2008, 3:18pm

Hi Sandro, thanks for writing and all the work packaging matplotlib
for debian.

Just to be clear on the API changes: every release of matplotlib
pretty much has some API changes which are documented in the
API_CHANGES file). They are usually quite minor, and 95% of our users
interact with matplotlib through the pylab/pyplot interface, which is
*extremely* stable, and pretty much hasn't changed since 0.1 and
probably will never change much.

The changes affect folks who use the matplotlib API directly, which
are probably 5% of our users, who are almost by definition the power
users. 0.98 introduced significantly more API changes (and features)
than a typical major release (hence the big bump in version number)
but nonetheless these have a very minor user facing impact. We have
nearly 100 figure generating tests in our regression suite and all of
them are passing. The major changes to the API occur for people
manipulating transformations directly, which is almost noone.

We are certainly discovering and fixing issues now that we are getting
some users on it with the 0.98.0 release, but the majority of these
are not API issues, but plain-ol-bugs or backend version issues,
etc... We are trying to get a bug fix release out ASAP to address
these, but we want to balance getting as many bug reports in before we
do this since none of the bugs reported thus far have been critical.

Thanks again,
JDH

···

On Tue, Jun 17, 2008 at 9:58 AM, Sandro Tosi <matrixhasu@...149...> wrote:

My plan (as one of maintainers of matplotlib in Debian) is to keep
uploading 0.91.x in unstable, so it can migrate to testing (the
staging area to prepare the next stable release) when needed, and
prepare the 0.98.x package into experimental. I need this since 0.98
introduced API changes, and I need to let depending packages check if
they are compatible with this new version (if not, adapting them)
before uploading to unstable and break things.

Since numpy in unstable is already at 1.1.0 (scheduled to be migrated
in testing in few days), I try my best to have 0.98.x in unstable
asap, so to let lenny (the upcoming stable release) ship 0.98.x!