[matplotlib-devel] Typo in mplconf
Hello, I came across a typo in mplconfig.py that results in an error when processing the matplotlib configurations. Attached is a patch. Ben Root Index: matplotlib/lib/matplotlib/config/mplconfig.py === --- matplotlib/lib/matplotlib/config/mplconfig.py (revision 8491) +++ matplotlib/lib/matplotlib/config/mplconfig.py (working copy) @@ -117,7 +117,7 @@ class path(TConfig): simplify = T.false -simplify_threshold = T.float(1.0 / 9.0) +simplify_threshold = T.Float(1.0 / 9.0) snap = T.true class patch(TConfig): -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Triplot function problems
Hi, I've been using mpl_tri package, from Ian Thomas, and recently the tri module, from the svn repository. When I use the triplot function with 100-1000 points it works well. The problem is that in my work I often use grids with 3-10 points. With those grids triplot takes a long time to compute (I never wait for the results, it takes really a long time). The matlab triplot function takes just a few seconds, with the same grids). And when I was using mpl_tri package, I never had this problem (the triplot function was faster!!!) Does anyone have this problem? How can I solve this? Thank you in advace for any help, Alberto === E-mail verificado pelo Spyware Doctor Não foram encontrados vírus ou spyware. (Email Guard: 7.0.0.18, Base de dados de vírus/spyware: 6.15350) http://www.pctools.com/?cclick=EmailFooterClean_51 === -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] axes3d button-check fix
While I don't think this has caused any problems yet, I have noticed a discrepancy in how a button-click test was being done versus other checks in the same file. It also makes more sense to check against a compiled list of buttons instead of using a hard-coding value. Attached is a patch Ben Root Index: matplotlib/lib/mpl_toolkits/mplot3d/axes3d.py === --- matplotlib/lib/mpl_toolkits/mplot3d/axes3d.py (revision 8491) +++ matplotlib/lib/mpl_toolkits/mplot3d/axes3d.py (working copy) @@ -446,7 +446,7 @@ if self.M is None: return '' -if self.button_pressed == 1: +if self.button_pressed in self._rotate_btn: return 'azimuth=%d deg, elevation=%d deg ' % (self.azim, self.elev) # ignore xd and yd and display angles instead -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Typo in mplconf
On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root wrote: > Hello, > > I came across a typo in mplconfig.py that results in an error when > processing the matplotlib configurations. Attached is a patch. I can apply this patch because it is a simple fix, but the larger question is whether we want to distribute/support the traited config at all. It seems like this development branch is mostly abandoned. Any comments Darren, or others? But in any case as long as we *do* currently have it it is good to fix these bugs, so thanks for the patch. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] axes3d button-check fix
On Sun, Jul 4, 2010 at 4:56 PM, Benjamin Root wrote: > While I don't think this has caused any problems yet, I have noticed a > discrepancy in how a button-click test was being done versus other checks in > the same file. It also makes more sense to check against a compiled list of > buttons instead of using a hard-coding value. > > Attached is a patch > Applied to 8493, thanks! JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Help with blitting bug with subplots and markers
On Sat, Jul 3, 2010 at 11:53 AM, Ryan May wrote: > On Sat, Jul 3, 2010 at 1:11 AM, Ryan May wrote: >> Alright, before I go to bed, I found the following line in >> src/_backend_agg.cpp at line 709 (in draw_markers()) makes all the >> difference: >> >> set_clipbox(gc.cliprect, rendererBase); >> >> Commenting out this line fixes my problem. I'm not sure why it's a >> problem, (maybe a missing restore to previous state somewhere?). I'll >> look into this tomorrow, but it would probably be a lot easier with >> someone familiar with the code. > > Following up again, it seems like the problem is that draw_marker is > calling set_clipbox() on the rendererBase instead of theRasterizer, > which is done at 7 other places in the code (as opposed to only one > other location for rendererBase). Since rendererBase is used for > restore_region, this makes sense as to why it would fix my problem. I > can confirm making the change fixes my problem and doesn't cause any > other issues in my (admittedly brief so far) testing. > > (If this isn't the proper fix, an alternative is to call > rendererBase.reset_clipping(true), but I really think this is working > around the issue). > > Can someone more familiar with the agg backend weigh in here? I'm > pretty comfortable with the fix, but don't want to be responsible for > breaking pretty much all of matplotlib. Does marker clipping still work with the proposed change? The only thing that is special about marker drawing is we use cached marker rasters to make drawing many of them efficient, but I don't recall anymore whether this required special clipping treatment. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Typo in mplconf
On Sun, Jul 4, 2010 at 9:24 PM, John Hunter wrote: > On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root wrote: >> Hello, >> >> I came across a typo in mplconfig.py that results in an error when >> processing the matplotlib configurations. Attached is a patch. > > I can apply this patch because it is a simple fix, but the larger > question is whether we want to distribute/support the traited config > at all. It seems like this development branch is mostly abandoned. > Any comments Darren, or others? > > But in any case as long as we *do* currently have it it is good to fix > these bugs, so thanks for the patch. The traited config stuff was never supported, and has to be turned on by setting a global in the source code. So I don't think it makes sense to distribute it. I'm too busy these days to try to support this feature and make it the default, plus there were issues with additional overhead due to pkg_resources, traits, and configobj. I wouldn't be offended if the code was removed from the trunk. (sniffs) Darren -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Typo in mplconf
On Sun, Jul 4, 2010 at 8:24 PM, John Hunter wrote: > On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root wrote: > > Hello, > > > > I came across a typo in mplconfig.py that results in an error when > > processing the matplotlib configurations. Attached is a patch. > > I can apply this patch because it is a simple fix, but the larger > question is whether we want to distribute/support the traited config > at all. It seems like this development branch is mostly abandoned. > Any comments Darren, or others? > > But in any case as long as we *do* currently have it it is good to fix > these bugs, so thanks for the patch. > > JDH > Thanks for applying that patch. I should also note that I am still in the process of tracking down another bug that seems to be related to tconfig. One can trigger it using the pydoc utility on a local build and install of matplotlib from svn. An exception gets raised when searching for "mpl_toolkits.mplot3d.axes3d" from the pydoc graphical gui, which seems to do a brute-force examination of the documentation. So it might be triggering unmaintained code. Ben Root -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Typo in mplconf
On Sun, Jul 4, 2010 at 9:43 PM, Darren Dale wrote: > On Sun, Jul 4, 2010 at 9:24 PM, John Hunter wrote: > > On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root wrote: > >> Hello, > >> > >> I came across a typo in mplconfig.py that results in an error when > >> processing the matplotlib configurations. Attached is a patch. > > > > I can apply this patch because it is a simple fix, but the larger > > question is whether we want to distribute/support the traited config > > at all. It seems like this development branch is mostly abandoned. > > Any comments Darren, or others? > > > > But in any case as long as we *do* currently have it it is good to fix > > these bugs, so thanks for the patch. > > The traited config stuff was never supported, and has to be turned on > by setting a global in the source code. So I don't think it makes > sense to distribute it. I'm too busy these days to try to support this > feature and make it the default, plus there were issues with > additional overhead due to pkg_resources, traits, and configobj. I > wouldn't be offended if the code was removed from the trunk. (sniffs) > > Darren > Do you guys still want a bug report for the tconfig issue, just in case it might be related to Traits in general (I have no clue where the issue is happening)? Ben -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
