[matplotlib-devel] compiler error: reload_cse_simplifty_operands
Hi all,
I am trying to compile matplotlib under MacOSX 10.5, and I get the
following error message:
src/_image.cpp:842: error: insn does not satisfy its constraints:
(insn 2573 1070 2574 126 agg24/include/agg_color_rgba.h:268 (set
(mem:QI (plus:SI (reg/f:SI 6 bp)
(const_int -280 [0xfee8])) [0 SR.2990+0 S1 A8])
(reg:QI 5 di)) 56 {*movqi_1} (nil)
(nil))
src/_image.cpp:842: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:391
Has anyone seen this before? I have found the following link, but no
solution is indicated:
http://www.nabble.com/internal-compiler-error-on-os-x-with--arch-i386-td14716109.html
Is this a compiler bug, or are there flags I can use to fix the
problem? I'd appreciate any advice.
Thanks,
Stéfan
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] QtAgg backend drawing everything twice?
On Thursday 13 March 2008 05:02:36 pm Ted Drain wrote: > I'm working on improving the plotting speed of one of our applications. As > part of that, I was looking at how quickly the QtAgg backend is drawing. I > added some print out's to the backend and noticed that it seems to be > drawing everything twice. In the code: > > backend_qtagg.py: FigureCanvasQTAgg class: > > def draw( self ): > """ > Draw the figure when xwindows is ready for the update > """ > > if DEBUG: print "FigureCanvasQtAgg.draw", self > self.replot = True > FigureCanvasAgg.draw(self) > self.repaint( False ) > > > > FigureCanvasAgg.draw() will cause a draw the repaint call will cause a > draw. If I comment out the FCAgg.draw() call, my application (QtAgg > embedded in a PyQt program) works fine. I've also run several of the > various example scripts and they seem to work fine as well. Panning, > zooming, redraws, resize, and file saving seem to be unaffected. > > Does anyone know why the extra draw call might be necessary? Thank you for pointing this out, Ted. It actually solves a problem I was seeing with the qt4agg backend, where the widgets.Cursor crosshairs were not being drawn when blitting was disabled. I removed the lines from qtagg and qt4agg, and saw no problems in the examples or my own application, so I checked in the changes - svn 5002. Darren - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] [Fwd: axes.py scatter doc-bug]
Happend with your commit from version 4979 -> 4989. Who's going to fix that ? Whom can I directly contact ? Original Message Subject: [matplotlib-devel] axes.py scatter doc-bug Date: Wed, 12 Mar 2008 12:30:12 +0100 From: Manuel Metz <[EMAIL PROTECTED]> To: matplotlib-devel@lists.sourceforge.net CC: John Hunter <[EMAIL PROTECTED]> Hi, the doc-string of the axes scatter method is buggy. Somehow the svn-conflict messages got committed to the repository: I mean this <<< .working [...] === [...] >>> .merge-right.r4987 ... stuff) Manuel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Scatter plot legend
A few weeks ago there was a discussion about putting scatter symbols in the legend (see http://www.nabble.com/Show-shapes-on-scatterplot-legend--to15744380.html). I would like to implement scatter symbols in the legend, but I am having some problems doing so. In the function _get_handles in legend.py, the symbol can be placed in the legend by doing something like: for path in handle._paths: xy = path.vertices p = Polygon(xy) The problem is that the polygon that gets drawn is the wrong size and aspect ratio. It would seem that this would call for some sort of scaling or transform to make the symbol the proper size, but I need some assistance or a pointer to documentation on how to do this. Thanks, Paul Novak - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pcolor curiosity
Eric Firing wrote: > Ryan, > > The pcolor implementation is fundamentally unsuited to large arrays. > Therefore I made the pcolorfast axes method, which tries to use the > fastest available Agg extension code, depending on the characteristics > of the spatial grid. If the grid is rectangular and regular in both > directions it uses a slight modification of the image code; if it is > rectangular but with irregular spacing, it uses the nonuniform image > code; and if it is not rectangular it uses the quadmesh code. It sounds > like what you need is the quadmesh version, which you can access either > via pcolormesh or pcolorfast. Neither is exposed via the pylab or > pyplot API at present; both are axes methods. The pcolorfast API also > may change slightly in the future; it probably needs a little more work. Yeah, I think for purposes of plotting radar data, quadmesh is what i need. > The quadmesh code has problems with masked arrays in the released > version of mpl, but not in the svn version. It is *much* faster than > pcolor, but may not be fast enough for your needs. My latest testing with the trunk with both pcolorfast and pcolormesh would seem to indicate that it's still a bit too slow for me. > If you are looking into what sounds like an OpenGL backend, or component > to a backend, then the place to start is still probably pcolormesh or > pcolorfast, not pcolor. This is the approach I'm considering. I've been poking around, and managed to create something that rendered, but not too well. However this was basically modifying the Gtk backend, and I'm sure there are some Gtk things that could be replaced. I noticed there are some other draw_* methods in other backends that aren't in the gtk, like draw_quad_mesh and draw_rectangle. Is there a definitive list somewhere? I tried RendererBase in backend_bases, but it did not have draw_rectangle. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
