Re: [matplotlib-devel] symlog problem
I ran into the same problem independently on an Intel Mac (I didn't read these messages until now) and came up with the first part of Jae-Joon Lee's fix. It does fix the problem, at least for me - I suspect the difference may not actually be in the platform but in the exact version of numpy (I have 1.1.0). I also committed the other part of the fix. This does seem to fix the problem, but I think we should wait for confirmation from John before releasing the code. -- Jouni K. Seppänen http://www.iki.fi/jks John Hunter <[EMAIL PROTECTED]> writes: > Unfortunately, today is a crazy day for me so I can't test until late > tonight at the earliest. But Charlie, I do think we should hold the > release until we resolve this. We should be able to fix and test this > by tomorrow afternoon so perhaps Monday night for the release if > everything is in order by then and you still have time. > > Sent from my iPhone > > On Dec 7, 2008, at 1:55 PM, "Jae-Joon Lee" <[EMAIL PROTECTED]> wrote: > >> John, >> >> I can't reproduce the error on my intel macbook. >> Anyhow, it seems to me a bug in the code and bugs in numpy. >> (I'm using numpy version 1.1.1, and I'm not sure these bugs are fixed >> in newer numpy. ) >> Can you try the patch below and see if this fix your problem? >> >> -JJ >> >> >> >> Index: lib/matplotlib/scale.py >> === >> --- lib/matplotlib/scale.py (revision 6487) >> +++ lib/matplotlib/scale.py (working copy) >> @@ -301,7 +301,8 @@ >> self._linadjust = (np.log(linthresh) / self._log_base) / >> linthre >> >> def transform(self, a): >> -sign = np.sign(np.asarray(a)) >> +a = np.asarray(a) >> +sign = np.sign(a) >> masked = ma.masked_inside(a, -self.linthresh, >> self.linthresh, co False) >> log = sign * ma.log(np.abs(masked)) / self._log_base >> if masked.mask.any(): >> @@ -328,6 +329,7 @@ >> self._linadjust = linthresh / (np.log(linthresh) / >> self._log_bas >> >> def transform(self, a): >> +a = np.asarray(a) >> return np.where(a <= self._log_linthresh, >> np.where(a >= -self._log_linthresh, >> >> >> >> -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] using new in axes.hist
On Sun, Dec 7, 2008 at 2:55 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > I just committed the change. Although the change is trivial, I didn't > tested it in the numpy 1.2 or the svn version. I tested on numpy svn on a couple of platforms (OS X and linux) and this looks OK from my end. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] symlog problem
On Mon, Dec 8, 2008 at 6:37 AM, Jouni K. Seppänen <[EMAIL PROTECTED]> wrote: > I ran into the same problem independently on an Intel Mac (I didn't read > these messages until now) and came up with the first part of Jae-Joon > Lee's fix. It does fix the problem, at least for me - I suspect the > difference may not actually be in the platform but in the exact version > of numpy (I have 1.1.0). I also committed the other part of the fix. > > This does seem to fix the problem, but I think we should wait for > confirmation from John before releasing the code. This is looking good on my end -- thanks Jae-Joon and Jouni for the patches. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] symlog problem
Just getting to this thread now. Since you asked for my insight -- I can't reproduce the bug on my Linux box, but the patch looks innocent enough if it fixes it for others. Mike John Hunter wrote: > On Mon, Dec 8, 2008 at 6:37 AM, Jouni K. Seppänen <[EMAIL PROTECTED]> wrote: > >> I ran into the same problem independently on an Intel Mac (I didn't read >> these messages until now) and came up with the first part of Jae-Joon >> Lee's fix. It does fix the problem, at least for me - I suspect the >> difference may not actually be in the platform but in the exact version >> of numpy (I have 1.1.0). I also committed the other part of the fix. >> >> This does seem to fix the problem, but I think we should wait for >> confirmation from John before releasing the code. >> > > This is looking good on my end -- thanks Jae-Joon and Jouni for the patches. > > JDH > > -- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] image pixel border bug
I don't think it's a rendering bug. The entire first row of data is 0.0 and -0.0, which maps to red. The real solution would be to map 0 and -0.0 to different colors, but that's insane ;) The rendering bug that bothers me, however, is the misalignment of the ticks to the colors in the color bar. I'm sure it's somehow related to the pixel-rounding in the Agg backend. I'll see if I can find an obvious fix for this. If it looks questionable, I'll wait until after the release. Cheers, Mike John Hunter wrote: > In the examples/pylab_examples/custom_cmap.py example, I am seeing a > pixel red border, eg colored red on the top border of the middle > subplot, where it looks like it should be blue. Image attached. Is > this an artifact of the breakpoint of the colormap, or a true > rendering bug? > > JDH > > > > > > > -- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > > > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] using new in axes.hist
John Hunter <[EMAIL PROTECTED]> writes: > I think the version check is a good idea, so people won't get the > annoying warning. Could you add this? > > Sent from my iPhone > > On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <[EMAIL PROTECTED]> wrote: > > > I'm currently using numpy 1.1.1 and np.histogram behave differently > > depending on the "new" value. > > ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that > > this different behavior is still there. > > So, as far as we're going to support numpy 1.1 and later, we may > > better not to drop the "new" silently. Debian lenny (which is currently in freeze and will be the next stable) has numpy 1.1 at present. It is possible that the package maintainers will try to get a later version in - but you should check before relying on it. Chris -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] image pixel border bug
On Mon, Dec 8, 2008 at 8:16 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > I don't think it's a rendering bug. The entire first row of data is 0.0 and > -0.0, which maps to red. The real solution would be to map 0 and -0.0 to > different colors, but that's insane ;) > > The rendering bug that bothers me, however, is the misalignment of the ticks > to the colors in the color bar. I'm sure it's somehow related to the > pixel-rounding in the Agg backend. I'll see if I can find an obvious fix > for this. If it looks questionable, I'll wait until after the release. Since this would be a bug-fix, I prefer to get it in before the release, if possible:-) So if you have time to look at it, that would be great. Charlie doesn't usually have time during the day to do the builds, so it would be tonight at the earliest, which should give us a little time to test any changes. Thanks, JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] New legend borders -- fuzzy???
I think Jae-Joon's new figure refactoring is really great, and is a huge improvement over the old code. I do, however, have one concern. Since the legend border is no longer a simple rectangle, the Agg backend's auto-pixel-alignment routine is no longer kicking in, and the border ends up looking fairly fuzzy. It's particularly striking when the axes rectangle is always so clean and sharp now. As nice as the rounded edges are, the fuzziness makes it feel like a bit of a regression to me. Aesthetically, I also feel it's a bit out of place to use rounded corners in one case but not elsewhere in a document (typical LaTeX templates, for instance, don't use rounded corners.) Should it perhaps be a regular rectangle by default, with rounded corners as an option? This may also be an argument for finally making the auto-pixel-alignment code programmatic, rather than automatic. As it works now, it automatically pixel-aligns when there are a) no curves and b) only rectilinear axis-aligned line segments. If the pixel alignment was instead controlled from Python as a flag, then the legend code could explicitly say it wants the legend patch to be pixel-aligned, even if it has rounded corners. But that's perhaps too deep of a change to make for the impending release and should have to wait for next time. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New legend borders -- fuzzy???
On Mon, Dec 8, 2008 at 9:13 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > I think Jae-Joon's new figure refactoring is really great, and is a huge > improvement over the old code. > > I do, however, have one concern. Since the legend border is no longer a > simple rectangle, the Agg backend's auto-pixel-alignment routine is no > longer kicking in, and the border ends up looking fairly fuzzy. It's > particularly striking when the axes rectangle is always so clean and > sharp now. As nice as the rounded edges are, the fuzziness makes it > feel like a bit of a regression to me. Aesthetically, I also feel it's > a bit out of place to use rounded corners in one case but not elsewhere > in a document (typical LaTeX templates, for instance, don't use rounded > corners.) > > Should it perhaps be a regular rectangle by default, with rounded > corners as an option? I'm inclined to agree with you -- this could also be an rc option, so those who like the rounding can get them by default. I would be happy to have rectangle by default, with liberal use of rounding in the gallery example code so people can easily find how to turn them on. A legend section for the docs is still on my list of things to do. I'll implement the rc param "legend.fancybox" and make False (rectangle) the default, and we can always change the after default if JJ weighs in. > This may also be an argument for finally making the auto-pixel-alignment > code programmatic, rather than automatic. As it works now, it > automatically pixel-aligns when there are a) no curves and b) only > rectilinear axis-aligned line segments. If the pixel alignment was > instead controlled from Python as a flag, then the legend code could > explicitly say it wants the legend patch to be pixel-aligned, even if it > has rounded corners. But that's perhaps too deep of a change to make > for the impending release and should have to wait for next time. This sounds fairly benign (gc param?) so I could go either way: before or after. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New legend borders -- fuzzy???
John Hunter wrote: > On Mon, Dec 8, 2008 at 9:13 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > >> This may also be an argument for finally making the auto-pixel-alignment >> code programmatic, rather than automatic. As it works now, it >> automatically pixel-aligns when there are a) no curves and b) only >> rectilinear axis-aligned line segments. If the pixel alignment was >> instead controlled from Python as a flag, then the legend code could >> explicitly say it wants the legend patch to be pixel-aligned, even if it >> has rounded corners. But that's perhaps too deep of a change to make >> for the impending release and should have to wait for next time. >> > > This sounds fairly benign (gc param?) so I could go either way: before or > after. > The gc param would be the easy part -- I was thinking the difficult would be going through all the cases and making sure it's doing the right thing, and making sure axes and ticks etc. still look nice. Though I suppose having the flag be yes/no/auto (where auto is the current behavior) would be the easiest route. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New legend borders -- fuzzy???
On Mon, Dec 8, 2008 at 9:39 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > The gc param would be the easy part -- I was thinking the difficult would be > going through all the cases and making sure it's doing the right thing, and > making sure axes and ticks etc. still look nice. Though I suppose having > the flag be yes/no/auto (where auto is the current behavior) would be the > easiest route. I wasn't thinking clearly. I was thinking you would be applying the fix only for the legend implementation, but there is no clean way to do this since the backends don't know anything about legends. Yes, doing this for all the artists is definitely too ambitious at this stage of the release. JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] image pixel border bug
This should now be fixed in SVN. Couldn't see any regressions in the documentation examples, but may be worth another set of eyes before the release. Mike John Hunter wrote: > On Mon, Dec 8, 2008 at 8:16 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > >> I don't think it's a rendering bug. The entire first row of data is 0.0 and >> -0.0, which maps to red. The real solution would be to map 0 and -0.0 to >> different colors, but that's insane ;) >> >> The rendering bug that bothers me, however, is the misalignment of the ticks >> to the colors in the color bar. I'm sure it's somehow related to the >> pixel-rounding in the Agg backend. I'll see if I can find an obvious fix >> for this. If it looks questionable, I'll wait until after the release. >> > > Since this would be a bug-fix, I prefer to get it in before the > release, if possible:-) So if you have time to look at it, that would > be great. Charlie doesn't usually have time during the day to do the > builds, so it would be tonight at the earliest, which should give us a > little time to test any changes. > > Thanks, > JDH > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New legend borders -- fuzzy???
John Hunter wrote: > On Mon, Dec 8, 2008 at 9:39 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > >> The gc param would be the easy part -- I was thinking the difficult would be >> going through all the cases and making sure it's doing the right thing, and >> making sure axes and ticks etc. still look nice. Though I suppose having >> the flag be yes/no/auto (where auto is the current behavior) would be the >> easiest route. >> > > I wasn't thinking clearly. I was thinking you would be applying the > fix only for the legend implementation, but there is no clean way to > do this since the backends don't know anything about legends. Yes, > doing this for all the artists is definitely too ambitious at this > stage of the release. > I think this also dovetails nicely with another update I've been meaning to make -- to use a GC (or something like it) for images and collections as well. As it stands now, any new property to collections needs to be added as a new argument to every backend (as was recently done for hyperlink support). Stuffing everything in an object should make it more easily extensible. But that's not before the release... ;) Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New legend borders -- fuzzy???
On Mon, Dec 8, 2008 at 10:27 AM, John Hunter <[EMAIL PROTECTED]> wrote: > > I'm inclined to agree with you -- this could also be an rc option, so > those who like the rounding can get them by default. I would be happy > to have rectangle by default, with liberal use of rounding in the > gallery example code so people can easily find how to turn them on. > A legend section for the docs is still on my list of things to do. > I'll implement the rc param "legend.fancybox" and make False > (rectangle) the default, and we can always change the after default if > JJ weighs in. > legend.fancybox=False as the default is good. Just in case, the legend class still creates FancyBboxPatch(but with a rectangle style) even if fancybox=False. But, I presume that the auto-pixel-alignment works in this case. On the other hand, I think it would also good if we allow a dictionary for the "fancybox" argument, like "bbox" in text. But maybe not in this release. Regards, -JJ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New legend borders -- fuzzy???
On Mon, Dec 8, 2008 at 10:49 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > On the other hand, I think it would also good if we allow a dictionary > for the "fancybox" argument, like "bbox" in text. But maybe not in > this release. I would prefer not to change the meaning of the fancybox once we release it, if we can help it. The best two choices are: * add support now for the dict before the release (handling the rc to accept a dict may require a little extra work) * keeping fancybox as is but adding an optional fancyprops dict later I can go either way, but I am disinclined to intentionally change the semantics of fancybox once we have released it we can help it -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New legend borders -- fuzzy???
On Mon, Dec 8, 2008 at 12:30 PM, John Hunter <[EMAIL PROTECTED]> wrote: > On Mon, Dec 8, 2008 at 10:49 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > >> On the other hand, I think it would also good if we allow a dictionary >> for the "fancybox" argument, like "bbox" in text. But maybe not in >> this release. > > I would prefer not to change the meaning of the fancybox once we > release it, if we can help it. The best two choices are: > > * add support now for the dict before the release (handling the rc > to accept a dict may require a little extra work) > > * keeping fancybox as is but adding an optional fancyprops dict later > > I can go either way, but I am disinclined to intentionally change the > semantics of fancybox once we have released it we can help it > I see your point. Let's keep it simple and leave it as is. I guess there might not be much need of customization as most of users will be happy with the default behavior. Regards, -JJ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] CHANGELOG tabs
Hi, It looks like some tabs have crept into the CHANGELOG file. Is anyone opposed to me changing them to the equivalent (8) spaces? It messes up my editor, which is set to display them as 4 spaces, and makes it think that tabs are the proper way to indent. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] CHANGELOG tabs
Ryan May wrote: > Hi, > > It looks like some tabs have crept into the CHANGELOG file. Is anyone > opposed to > me changing them to the equivalent (8) spaces? It messes up my editor, which > is > set to display them as 4 spaces, and makes it think that tabs are the proper > way > to indent. > > Ryan > By all means, tabs are bugs, kill them dead! Eric -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] dashtick.py example broken
Hi, Was just looking through the examples and noticed that pylab_examples/dashtick.py does not work here for me on SVN head. Traceback (most recent call last): File "dashtick.py", line 61, in test_dashticklabel() File "dashtick.py", line 40, in test_dashticklabel fontsize=FONTSIZE, File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 162, in setp ret = _setp(*args, **kwargs) File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/artist.py", line 982, in setp func = getattr(o,funcName) AttributeError: 'Text' object has no attribute 'set_dashrotation' I'm clueless on this code, so this is just an FYI. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] CHANGELOG tabs
On Mon, Dec 8, 2008 at 4:29 PM, Ryan May <[EMAIL PROTECTED]> wrote: > Hi, > > It looks like some tabs have crept into the CHANGELOG file. Is anyone > opposed to > me changing them to the equivalent (8) spaces? It messes up my editor, which > is > set to display them as 4 spaces, and makes it think that tabs are the proper > way > to indent. > > Ryan > I'm afraid that most of those tabs (if not all) are inserted by me. I somehow presumed my editor (emacs with change-log-mode) automatically convert tabs to equivalent number of spaces. And, yes, go ahead. -JJ -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] dashtick.py example broken
On Mon, Dec 8, 2008 at 4:19 PM, Ryan May <[EMAIL PROTECTED]> wrote: > Hi, > > Was just looking through the examples and noticed that > pylab_examples/dashtick.py > does not work here for me on SVN head. > > Traceback (most recent call last): > File "dashtick.py", line 61, in > test_dashticklabel() > File "dashtick.py", line 40, in test_dashticklabel > fontsize=FONTSIZE, > File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyplot.py", > line 162, in setp > ret = _setp(*args, **kwargs) > File "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/artist.py", > line 982, in setp > func = getattr(o,funcName) > AttributeError: 'Text' object has no attribute 'set_dashrotation' > > I'm clueless on this code, so this is just an FYI. TextWithDash is still used on the maintenance branch for tick labels, but no longer on the trunk. I suspect it did not work with the arbitrary projections Michael developed support for and he removed it, but Michael can confirm. The code is poorly maintained, so I am happy to see it no longer in the core tick labeling. I have removed the example from svn. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release? no, this time really I mean it
On Thu, Dec 4, 2008 at 12:38 PM, Charlie Moad <[EMAIL PROTECTED]> wrote: > Works for me. Let's aim for Saturday night so we have Sunday to test > it out. Doable? I've been working on a number of docstring fixes, and several other changes and last-minute bug fixes have been coming in. I think we need to give these a day to settle, so let's hold off until tomorrow before trying to push out the release, so we can do further testing/ Thanks, JDH -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
