[matplotlib-devel] small patch for trunk/matplotlib/lib/matplotlib/axis.py
This is a small patch to enable get_gridlines to be able to get the grid lines for the minor ticks as well. 1052c1052 < def get_gridlines(self): --- > def get_gridlines(self,minor=False): 1054c1054,1055 < ticks = self.get_major_ticks() --- > if minor: ticks = self.get_minor_ticks() > else: ticks = self.get_major_ticks() -- Daniel Hyams [email protected] -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] small patch for trunk/matplotlib/lib/matplotlib/axis.py
Sure:
--- axis.py 2010-08-18 09:59:25.0 -0400
+++ axis.py.orig2010-08-18 09:58:13.0 -0400
@@ -1049,12 +1049,9 @@
def _get_offset_text(self):
raise NotImplementedError('Derived must override')
-def get_gridlines(self,minor=False):
+def get_gridlines(self):
'Return the grid lines as a list of Line2D instance'
-if minor:
- ticks = self.get_minor_ticks()
-else:
- ticks = self.get_major_ticks()
+ticks = self.get_major_ticks()
return cbook.silent_list('Line2D gridline', [tick.gridline for tick
in ticks])
def get_label(self):
On Wed, Aug 18, 2010 at 1:05 PM, Ryan May wrote:
> On Wed, Aug 18, 2010 at 9:25 AM, Daniel Hyams wrote:
> > This is a small patch to enable get_gridlines to be able to get the grid
> > lines for the minor ticks as well.
> > 1052c1052
> > < def get_gridlines(self):
> > ---
> >> def get_gridlines(self,minor=False):
> > 1054c1054,1055
> > < ticks = self.get_major_ticks()
> > ---
> >> if minor: ticks = self.get_minor_ticks()
> >> else: ticks = self.get_major_ticks()
>
> Thanks for the contribution. Can you regenerate using: diff -u
> so we can easily apply to the tree?
>
> Thanks,
>
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>
--
Daniel Hyams
[email protected]
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Release schedule for version 1.0.1?
On Mon, Oct 25, 2010 at 4:15 PM, Russell E. Owen wrote: > In article <[email protected]>, > Michael Droettboom > wrote: > > > On 10/22/2010 05:45 PM, Russell E. Owen wrote: > > > I'm curious when the next release of matplotlib is due. > > > > > > My application is suffering badly from the issue that an incorrect font > > > cache will cause matplotlib to fail (the application mysteriously exits > > > partway through startup until the user deletes the font cache). > > > > > > That problem is allegedly fixed on the trunk and I'm trying to decide > > > how best to deal with it. Depending on the timing of 1.0.1 I can decide > > > whether it's worth putting in my own workaround, bundling a prerelease > > > version of matplotlib or just waiting for the official release. > > I'm not sure what the timeframe is on 1.0.1. > > > > What problem with the cache are you referring to? I'm aware of a > > problem where if some fonts are moved or removed after the cache is > > created matplotlib will crash (and this problem is fixed in the trunk), > > but is that really a problem in everyday practice? I'm just curious -- > > if there's another issue with the cache that I'm not aware of, I'd like > > to fix it. > > The known problem what I am referring to. Fortunately. > > It has proven to be a very serious problem in practice. I bundle > matplotlib into a Mac application and for a significant number of my > users it crashes at startup due to problems with the matplotlib cache > files. The fix is always the same: delete the cache. > > Some reasons this has happened > - The user first runs the application from the distribution dmg file > before copying to /Applications > - The user installs it and runs it, but then moves or renames it for > some reason...boom > - The user had an older version of matplotlib installed but then deleted > it for some reason. > > Fortunately the fix from the trunk will do the job. > > That said, it still seems risky to me that matplotlib insists on using a > shared directory for its cache and matplotlibrc file: that there's no > way to tell matplotlib to put that data somewhere else (e.g. inside the > application bundle). With bundled applications it is quite likely the > user may run multiple versions of matplotlib without even knowing it. If > any of that data is version-dependent then this is a recipe for > mysterious problems. > > It doesn't really insist on it right? There are MATPLOTLIBDIR and MPLCONFIGDIR environment variables. The former is for the location of mpl-data, and is not really documented well (that I could find, anyway, but I found it in the source code), and MPLCONFIGDIR specifies where your configuration files for matplotlib are. This is where your font cache will be, as well as your matplotlibrc. You can set these env variables within your code, before import of matplotlib via os.environment. -- Daniel Hyams [email protected] -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Release schedule for version 1.0.1?
Right, I was referring specifically to MATPLOTLIBDIR ;) I was just pleased as punch to find it in the source code, documented or no :) On Mon, Oct 25, 2010 at 5:06 PM, John Hunter wrote: > On Mon, Oct 25, 2010 at 3:41 PM, Daniel Hyams wrote: > > > It doesn't really insist on it right? There are MATPLOTLIBDIR and > > MPLCONFIGDIR environment variables. The former is for the location of > > mpl-data, and is not really documented well (that I could find, anyway, > but > > I found it in the source code), and MPLCONFIGDIR specifies where your > > configuration files for matplotlib are. This is where your font cache > will > > be, as well as your matplotlibrc. > > > > You can set these env variables within your code, before import of > > matplotlib via os.environment. > > They should be better documented, but the MPLCONFIGDIR is in the FAQ > > > > http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#matplotlib-directory-location > -- Daniel Hyams [email protected] -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] putting a legend in its place
I mailed this to the matplotlib-users list, but it never showed, so I'm trying this one. Apologies if it shows up in both places :( What I'm trying to do can be boiled down to the following: I'm trying to place a legend precisely, using the top left corner of legend as the "sticky" point. In other words, if I want to place the legend here: +-+---+ | | | | | legend | | | | | The plot... |---+ | | | | | | | | | | | | | | +-+ I would have thought that I would set bbox_to_anchor = (0,0,1,1), and loc = (1,1). I found out quickly, though, that this places the legend like this: +---+ | | | legend | | | +-+---+ | | | | | | | The plot... | | | | | | | | | | | | | | | +-+ Which makes perfect sense from matplotlib's perspective. So all I need to do is figure out how tall the legend is, and subtract that off the y coordinate before passing 'loc' off to matplotlib's legend. I just can't seem to figure out how to get that number. I tried self.ax.get_legend().get_frame().get_height(), but that just returns 1 all the time. I browsed all through the legend object (a live one) and just can't find any numbers at all that look like the legend width/height, in any coordinate system. I hope I'm missing something obvious! Ascii art is fun! :) -- Daniel Hyams [email protected] -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] putting a legend in its place
I mailed this to the matplotlib-users list, but it never showed, so I'm trying this one. Apologies if it shows up in both places :( What I'm trying to do can be boiled down to the following: I'm trying to place a legend precisely, using the top left corner of legend as the "sticky" point. In other words, if I want to place the legend here: +-+---+ | | | | | legend | | | | | The plot... |---+ | | | | | | | | | | | | | | +-+ I would have thought that I would set bbox_to_anchor = (0,0,1,1), and loc = (1,1). I found out quickly, though, that this places the legend like this: +---+ | | | legend | | | +-+---+ | | | | | | | The plot... | | | | | | | | | | | | | | | +-+ Which makes perfect sense from matplotlib's perspective. So all I need to do is figure out how tall the legend is, and subtract that off the y coordinate before passing 'loc' off to matplotlib's legend. I just can't seem to figure out how to get that number. I tried self.ax.get_legend().get_frame().get_height(), but that just returns 1 all the time. I browsed all through the legend object (a live one) and just can't find any numbers at all that look like the legend width/height, in any coordinate system. I hope I'm missing something obvious! Ascii art is fun! :) -- Daniel Hyams [email protected] -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] small bug report
In backend_wx.py, function Copy_To_Clipboard. A call to wx.TheClipboard.Flush() should follow wx.TheClipboard.Close(). If not, the data put on the clipboard does not persist after the wx application is closed. -- Daniel Hyams [email protected] -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] blurry images at native resolution with images.BboxImage: patch to fix
I was playing around with images.BboxImage, and found that if I displayed,
say a 100x100 image at its native resolution (exactly 100x100 pixels on the
plotting window), it was blurred. This is because of the interpolation
jumping in and interpolating when it is not needed.
This might not be the best way to fix, but it does workin matplotlib
1.0.0, it is image.py around line 1102 (this is BboxImage.make_image). Just
after numrows and numcols is set in that routine, do
if (r-l) == numcols and (t-b) == numrows:
im.set_interpolation(0)
As you can see, all this does is just flip the interpolation off if the size
of the image is the same size that it is about to be rendered as...and the
regular interpolation is used otherwise.
I do apologize for the lack of a proper patch, but for little things like
this I think a word description works as well or better; I need to sit down
and both learn git and set of a development environment for matplotlib, but
after reading through the docs on the web site about it, decided that would
take me more time than I had at the moment.
In context:
def make_image(self, renderer, magnification=1.0):
if self._A is None:
raise RuntimeError('You must first set the image array or the
image attribute')
if self._imcache is None:
if self._A.dtype == np.uint8 and len(self._A.shape) == 3:
im = _image.frombyte(self._A, 0)
im.is_grayscale = False
else:
if self._rgbacache is None:
x = self.to_rgba(self._A, self._alpha)
self._rgbacache = x
else:
x = self._rgbacache
im = _image.fromarray(x, 0)
if len(self._A.shape) == 2:
im.is_grayscale = self.cmap.is_gray()
else:
im.is_grayscale = False
self._imcache = im
if self.origin=='upper':
im.flipud_in()
else:
im = self._imcache
# image input dimensions
im.reset_matrix()
im.set_interpolation(self._interpd[self._interpolation])
im.set_resample(self._resample)
l, b, r, t = self.get_window_extent(renderer).extents #bbox.extents
widthDisplay = (round(r) + 0.5) - (round(l) - 0.5)
heightDisplay = (round(t) + 0.5) - (round(b) - 0.5)
widthDisplay *= magnification
heightDisplay *= magnification
numrows, numcols = self._A.shape[:2]
if (r-l) == numcols and (t-b) == numrows:# <-
add this
im.set_interpolation(0)
#<-- and this
# resize viewport to display
rx = widthDisplay / numcols
ry = heightDisplay / numrows
#im.apply_scaling(rx*sx, ry*sy)
im.apply_scaling(rx, ry)
#im.resize(int(widthDisplay+0.5), int(heightDisplay+0.5),
# norm=self._filternorm, radius=self._filterrad)
im.resize(int(widthDisplay), int(heightDisplay),
norm=self._filternorm, radius=self._filterrad)
return im
--
Daniel Hyams
[email protected]
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] blurry images at native resolution with images.BboxImage: patch to fix
> > > imshow() does take an "interpolation" kwarg, where you can specify > "nearest" for pre v1.1.0 versions and "none" (not None) in the recent > release. "nearest" would be close to what you want, while "none" is exactly > what you want. > > Personally, I don't think it would be a good idea to automatically turn > interpolation off on such a specific set of conditions, but I could be > wrong. I would rather have the user explicitly state their interpolation > intentions. > > Ben Root Hello Ben, Isn't the purpose of interpolation to handle situations where the image is being displayed at a different size than its native resolution? It seems appropriate to me to turn interpolation off in such a case. Just some context of what I was up to when I ran into this oneI'm trying to allow the user to paste images (either from file or clipboard) onto a matplotlib canvas and be able to drag and resize them, very similar to the way powerpoint works. So I wanted to work with the appropriate image object in matplotlib, and BboxImage was the best I found after digging in the code for a bit; imshow() is too tied to the axisthese are supposed to be just free floating images. What I ran into was that, on initial paste (where I am sizing the BboxImage the same width/height as the incoming picture), the image was very blurry (because of the interpolation). I still want the interpolation on so that the image looks nice when it is resized by the user with the grab handles, but in the specific case where no interpolation is needed, this patch turns it off. The pasting/dragging/resizing has actually turned out pretty well...once I get it cleaned up and working how I want it to, I'll submit it to you guys for inclusion into matplotlib if you want it. I was hoping to formulate it as a mixin that will work for any artist (not just BboxImage) within reasonable limits. -- Daniel Hyams [email protected] -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] blurry images at native resolution with images.BboxImage: patch to fix
Ah yes, I forget :/ I was focused on images as being "pure" things that should be displayed, and forgot about the image processing angle. So would the solution be a keyword argument that tells imshow/BboxImage and friends not to interpolate when at native resolution, which is set to the current behavior as default? If that's not an acceptable solution, I can just leave the patch in my own personal code and not worry about any further...I thought that I was fixing a bug there :) I guess the main difference is whether the image is treated as sacred and should be displayed perfectly when possible, versus the ability to modify the picture on purpose via the interpolations, for whatever reason the user wants. Understandably, matplotlib has taken the latter approach, because the context has always been (as far as I can tell from the examples) displaying the pixels for a scientific purpose. However, when you want to display an image for a annotational type purpose, the former approach should be taken, in my opinion. On Thu, Oct 13, 2011 at 11:13 AM, John Hunter wrote: > On Thu, Oct 13, 2011 at 10:06 AM, Daniel Hyams wrote: > > > Isn't the purpose of interpolation to handle situations where the image > is > > being displayed at a different size than its native resolution? It seems > > Not solely, it can also be used to do local average of noisy images to > get a smoother view, eg bilinear or bicubic averaging of neighboring > pixels. > -- Daniel Hyams [email protected] -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] draw() in Figure does not obey get_animated()
This could be intentional...I don't know much about the history of matplotlib, so it's hard to guess at these things. Anyway, the figure container does not care about the "animated" state of its artists when it does its drawing. To fix this, in the Figure.draw routine (in figure.py), add the following line just before dsu.sort(): dsu = [x for x in dsu if not x[1].im_self.get_animated()] -- Daniel Hyams [email protected] -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] RFC: double click support in matplotlib
matplotlib doesn't support double clicks, and I was wondering if that was a design decision, or something that had been relegated to the "to do" box for someday. Hoping that it was still in the "todo" box, I think I can put most of it in without too much trouble, and supply you with a patch. The changes would be: 1) an extra flag MouseEvent, so that in a button_press_event handler, you can can tell if the press was a result of a double click or not, and 2) code in the backends to catch and set the double click flag properly I looked through the backends, and it was clear what to do in order to support double clicks for all but backend_macosx.py. I might be able to deduce what to do there, but will likely need some support from someone in order to get that one done. To support the double clicks, I would rather not create a new event like 'button_doubleclick_event', for backwards compatibility. I believe that if we just stick with 'button_press_event' and set an extra flag within the MouseEvent, any existing mpl code will still work properly, because the normal sequence of events on a double click are; DOWN, UP, DBLCLICK, UP. In current versions of matplotlib, the DBLCLICK event is treated as a DOWN, and the strategy of just adding a extra flag in MouseEvent would mean that existing mpl code would still see the double click event as a DOWN. Anyway, I want to "throw a feeler" out there, and ask if the patch would be accepted were I to go ahead and do it. I didn't want to spend the time working on it if a decision had already been made a while back to not ever support double clicks. -- Daniel Hyams [email protected] -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC: double click support in matplotlib
I added double click support in, here in the following issue report: https://github.com/matplotlib/matplotlib/issues/550 I did use the extra flag in MouseEvent, but I can change this to a separate event if all think that it is appropriate; I still favor the flag for backwards compatibility. All backends are done except for cocoagg; see the issue report above for details. On Sat, Oct 22, 2011 at 10:57 PM, Benjamin Root wrote: > > > On Saturday, October 22, 2011, Daniel Hyams wrote: >> matplotlib doesn't support double clicks, and I was wondering if that >> was a design decision, or something that had been relegated to the "to >> do" box for someday. Hoping that it was still in the "todo" box, I >> think I can put most of it in without too much trouble, and supply you >> with a patch. >> >> The changes would be: >> 1) an extra flag MouseEvent, so that in a button_press_event >> handler, you can can tell if the press was a result of a double click >> or not, and >> 2) code in the backends to catch and set the double click flag properly >> >> I looked through the backends, and it was clear what to do in order to >> support double clicks for all but backend_macosx.py. I might be able >> to deduce what to do there, but will likely need some support from >> someone in order to get that one done. >> >> To support the double clicks, I would rather not create a new event >> like 'button_doubleclick_event', for backwards compatibility. I >> believe that if we just stick with 'button_press_event' and set an >> extra flag within the MouseEvent, any existing mpl code will still >> work properly, because the normal sequence of events on a double click >> are; DOWN, UP, DBLCLICK, UP. In current versions of matplotlib, the >> DBLCLICK event is treated as a DOWN, and the strategy of just adding a >> extra flag in MouseEvent would mean that existing mpl code would still >> see the double click event as a DOWN. >> >> Anyway, I want to "throw a feeler" out there, and ask if the patch >> would be accepted were I to go ahead and do it. I didn't want to spend >> the time working on it if a decision had already been made a while >> back to not ever support double clicks. >> > > My vote would be yes, but I think i would want it as a separate event. > Consider some of the widgets like lasso and the zoom bbox. If one were to > attach a button_press_event for the purpose of detecting double clicks, I > would imagine that there may exist conflicts (or those widget codes would > have to be adjusted to exclusively respond only to single clicks). Would > existing widgets also fire even if a double-click occured? > > My 2 cents, > Ben Rootl -- Daniel Hyams [email protected] -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC: double click support in matplotlib
Ben: In current versions of matplotlib, the double click event is always just bound to the same handler as a single press. Such as the following code in backends/backend_wx.py: bind(self,wx.EVT_LEFT_DOWN,self._onLeftButtonDown) bind(self,wx.EVT_LEFT_DCLICK,self._onLeftButtonDown) bind(self,wx.EVT_LEFT_UP,self._onLeftButtonUp) so when someone double clicks on a canvas, the events sent would be (except in the case of gtk*) DOWN, UP, DOWN, UP. If a new event is created for the double click, the sequence of events generated would be DOWN,UP,DCLICK,UP. If you use a flag with in MouseEvent to signify the double click, the sequence of events would be DOWN,UP,DOWN.DCLICK,UP basically. This means that old code that relies on double clicks generating a DOWN event would still work, and newer code that wants to use double clicks need only query the MouseEvent.dblclick flag to see if a press was a double click or not. * for gtk, the event sequence for a double click is currently DOWN,UP,DOWN,DOWN,UP. That's the only backend that I've seen that does it this way. With the patch, the event sequence would be DOWN,UP,DOWN,DOWN.DCLICK,UP. On Sun, Oct 23, 2011 at 9:13 PM, Benjamin Root wrote: > > > On Sunday, October 23, 2011, Daniel Hyams wrote: >> I added double click support in, here in the following issue report: >> >> https://github.com/matplotlib/matplotlib/issues/550 >> >> I did use the extra flag in MouseEvent, but I can change this to a >> separate event if all think that it is appropriate; I still favor the >> flag for backwards compatibility. All backends are done except for >> cocoagg; see the issue report above for details. > > Thanks, I will look deeper into it tommorow. I am curious about what you > mean by backwards compatibility? How do you see having a new event type > cause issues? > > Ben Root > -- Daniel Hyams [email protected] -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Possible bug in matplotlib.cbook.CallbackRegistry
lick on red sqaure again > > > > > > > > > > -- > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Daniel Hyams [email protected] -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] which to fork from?
For small bugfixes, am I supposed to fork from v1.1.x, or master? -- Daniel Hyams [email protected] -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] How to properly use git to implement a feature
I was wanting to add a feature to matplotlib...one that I would use in my application. I also want to contribute the feature back. I'm personally using version 1.1.1 of matplotlib. Disclaimer...I only know enough about git to be dangerous. So is it best to branch from v1.1.1, implement the feature, and then try to rebase to master? Or is it best to branch from master, implement the feature, and then (somehow) backport the patch to the v1.1.1 tagged version? Whatever the best choice is, what would the procedure look like to accomplish this? -- Daniel Hyams [email protected] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to properly use git to implement a feature
Thanks Eric; this is what I was looking for, and it's a shame that there seems to be no way to accomplish this without cherrypicking a commit or range of commits. It seems that since v1.1.1 and master can be traced back to some common ancestry, that git should be able to rewind and replay the changes so that cherrypicking or reimplementing wouldn't be necessary. I've archived this email, though, so that I can use it at the appropriate time. For the immediate need, I was going to add the keyword 'bbox_size' to Annotations, so that the user can optionally specify the box size around an annotation...also was going to add additional boxstyles for Annotations, so that one could use a circle, ellipse, or any other type of patch to enclose the annotation. This would be useful for flowcharting and any other use where the user wants a "patch with text inside". As it stands, though I can only get 95% of this done...I can't seem to get the placement of the patch correct when the text is rotated, unless ha='center' and va='center', or if rotation_mode='anchor'. So since I would cause a regression here, I guess it's off the table. On Sun, Aug 12, 2012 at 11:23 PM, Eric Firing wrote: > On 2012/08/12 3:34 PM, Daniel Hyams wrote: > > > > I was wanting to add a feature to matplotlib...one that I would use in > > my application. I also want to contribute the feature back. I'm > > personally using version 1.1.1 of matplotlib. Disclaimer...I only know > > enough about git to be dangerous. > > > > So is it best to branch from v1.1.1, implement the feature, and then try > > to rebase to master? Or is it best to branch from master, implement the > > feature, and then (somehow) backport the patch to the v1.1.1 tagged > version? > > Mike answered for the case where you are making a bugfix that really > does go in v1.1.x. I think that even there, what he is recommending is > a bit different from what you have in mind: he is saying to branch from > an up-to-date v1.1.x, not from v1.1.1. Similarly, for the case you have > in mind, the pull request should be for a change relative to a recent > enough point on the master branch that it can be merged cleanly, and > with no unexpected side-effects. > > It sounds like what you are trying to do is maintain your own branch off > of the v1.1.1 tagged version, with only your own features added. > > I don't think there is any single best way to do this; it depends on how > you work, and on what sorts of changes you are making. > > Developing your change in your feature branch off of v1.1.1 is perfectly > reasonable, since that is where you are normally working, and that is > where you need it to work. To propagate it upstream, you do need to > either cherry-pick it, or reimplement it, relative to recent master. > Re-implementing it can be simpler in some cases--easier to see what is > going on! > > I had been thinking "rebase", but this is not correct; you don't want to > *remove* your commits from your branch off of v1.1.1, you want to > *reproduce* them, or their net effect, in a *new* topic branch off of > up-to-date master. > > It would go something like this. Assume "upstream" is the remote > pointing to the main mpl repo, and "origin" is your github repo. Assume > your changes are in a topic branch called "dh_topic_stable", off of > v1.1.1. Find the commit numbers in dh_topic_stable that you need to > propagate, say "a0b123fed" and "df237abc". > > git fetch upstream > git checkout -b dh_topic upstream/master > git cherry-pick a0b123fed df237abc > # build and test; maybe add documentation and test commits > git push origin dh_topic > > Then make your pull request against mpl master. > > For seeing what is in a repo, and what happens at each step of the way, > I find qgit helpful. Invoke as "qgit --all". You need to hit the > refresh button after each command-line git call. > > Eric > > > > > > Whatever the best choice is, what would the procedure look like to > > accomplish this? > > > > -- > > Daniel Hyams > > [email protected] <mailto:[email protected]> > > > > > > > -- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > > > &g
[matplotlib-devel] MEP9: interactivity
I'm not sure where to say that I just posted up a new MEP, but here it is: https://github.com/matplotlib/matplotlib/wiki/MEP9 and I suppose we discuss it here... -- Daniel Hyams [email protected] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP9: interactivity
On Fri, Aug 17, 2012 at 10:52 AM, Drain, Theodore R (343P) < [email protected]> wrote: > OK - I'll start the ball rolling... > > > > One feature that would be nice to have is positioning options that are not > pixel based. See the annotate function for some possibilities: > Note that the get_pixel_position_ll() and such functions (in the MEP9 proposal) are only for internal use by the interactive manager. Items can still be placed by the script wherever necessary, and if the position (in one or multiple transformations) is necessary, one can record that in the on_select_end callback for that artist. In fact, one of the things that must be done in the set_position_and_size() call (every artist will have to do this) is to set that artist's appropriate parameters for its position and size, based on its current transformation, that fits it within the bounding box that the user just finished moving and dragging around. Sorry, I know that's hard to see without some straw-man code that I intend to post soon...I was a little ashamed to post it in its current state ;) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP9: interactivity
On Fri, Aug 17, 2012 at 2:25 PM, Michael Droettboom wrote: > Here's my initial thoughts: > > There are a few examples in the event_handling that are going to be much > simplified by this new infrastructure. They should be updated to point > people in the direction of this new/better/easier way. > > How do the *select* methods relate to the existing pick functionality? > Does it replace or complement? Are there any inconsistencies in usage > between the two? > I think that in most use cases that I can think of, a user would want to either use the picking mechanism, which fires an event, or go "whole hog" and use the interactive manager. Not bothif I remember correctly, I do call set_picker() in the interactive manager, so that I can set a reasonable tolerance around the artist for containment purposes...otherwise it's too hard to point exactly at a line, for example. So there is some potential for interference there that would need to be looked after in the new code. As an aside, all of the on_* methods really encourage the user to use matplotlib in object oriented way, which I really like, but probably most people won't. As a bridge for the functional-style users of mpl, we could just implement all of the on_* methods in the artist.Artist class by default by having them fire an event. Then if someone overrides the method, fine, but if they don't, there is an event fired. > Other than that, I'm not seeing any obvious issues with the MEP. I'd love > to see the code when it's ready. > I'll probably have an example code, still in its mix-in form, in a branch for you to look at soon. This way, the discussion can turn more concrete. The example code will also be a runnable sample so that you can play with the interactivity. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP9: interactivity
I was planning to just create my own branch to start putting code in, but would it be better for an admin to create a branch off of master in the main matplotlib repo (say MEP9)? Then whoever wants to help out with MEP9 can branch from that and issue pull requests against it? On Fri, Aug 17, 2012 at 2:42 PM, Daniel Hyams wrote: > > > On Fri, Aug 17, 2012 at 2:25 PM, Michael Droettboom wrote: > >> Here's my initial thoughts: >> >> There are a few examples in the event_handling that are going to be much >> simplified by this new infrastructure. They should be updated to point >> people in the direction of this new/better/easier way. >> >> How do the *select* methods relate to the existing pick functionality? >> Does it replace or complement? Are there any inconsistencies in usage >> between the two? >> > > I think that in most use cases that I can think of, a user would want to > either use the picking mechanism, which fires an event, or go "whole hog" > and use the interactive manager. Not bothif I remember correctly, I do > call set_picker() in the interactive manager, so that I can set a > reasonable tolerance around the artist for containment purposes...otherwise > it's too hard to point exactly at a line, for example. So there is some > potential for interference there that would need to be looked after in the > new code. > > As an aside, all of the on_* methods really encourage the user to use > matplotlib in object oriented way, which I really like, but probably most > people won't. As a bridge for the functional-style users of mpl, we could > just implement all of the on_* methods in the artist.Artist class by > default by having them fire an event. Then if someone overrides the > method, fine, but if they don't, there is an event fired. > > >> Other than that, I'm not seeing any obvious issues with the MEP. I'd >> love to see the code when it's ready. >> > > I'll probably have an example code, still in its mix-in form, in a branch > for you to look at soon. This way, the discussion can turn more concrete. > The example code will also be a runnable sample so that you can play with > the interactivity. > > -- Daniel Hyams [email protected] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP9: interactivity
On Fri, Aug 17, 2012 at 3:24 PM, Eric Firing wrote: > On 2012/08/17 8:45 AM, Daniel Hyams wrote: > > I was planning to just create my own branch to start putting code in, > > but would it be better for an admin to create a branch off of master in > > the main matplotlib repo (say MEP9)? Then whoever wants to help out > > with MEP9 can branch from that and issue pull requests against it? > > People can already do that by forking your repo (which you forked from > master), and issuing pull requests against your MEP9 branch within it. > The difference is that in the latter case, you are the only one who can > merge a pull request. I think this will have some advantages, including > giving you more freedom to do things like rebase and force-push, which > we would not want to do in the main repo. > > Eric OK, thanks Eric. I'll try my best not to let my git-ignorance "git" in the way too much ;) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP9: interactivity
OK, I have a sample code for people to run if they want to. I've dumped all of the interactive manager code and some sample usage (of the mix-in way of doing it) in the following branch: https://github.com/dhyams/matplotlib/tree/MEP9 in the directory examples/user_interfaces/imanager.py Just run that script, and it should give a little demo plot. I do apologize and disclaim all messiness in the code...it's not the prettiest thing anyway, and I cobbled it together very quickly so that you could see what it does. Sort of a straw man to beat on, I guess. On Fri, Aug 17, 2012 at 3:38 PM, Daniel Hyams wrote: > > > On Fri, Aug 17, 2012 at 3:24 PM, Eric Firing wrote: > >> On 2012/08/17 8:45 AM, Daniel Hyams wrote: >> > I was planning to just create my own branch to start putting code in, >> > but would it be better for an admin to create a branch off of master in >> > the main matplotlib repo (say MEP9)? Then whoever wants to help out >> > with MEP9 can branch from that and issue pull requests against it? >> >> People can already do that by forking your repo (which you forked from >> master), and issuing pull requests against your MEP9 branch within it. >> The difference is that in the latter case, you are the only one who can >> merge a pull request. I think this will have some advantages, including >> giving you more freedom to do things like rebase and force-push, which >> we would not want to do in the main repo. >> >> Eric > > > > OK, thanks Eric. I'll try my best not to let my git-ignorance "git" in > the way too much ;) > > -- Daniel Hyams [email protected] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Is anyone using make.osx?
I do, but I'm not wedded to it; I'll use whatever is there. The convenience of it is that it downloaded dependencies and built them for you. Will setup.py do the same? On Fri, Sep 7, 2012 at 12:32 PM, Michael Droettboom wrote: > There is a discussion in a pull request about whether it is still needed. > > https://github.com/matplotlib/matplotlib/issues/751 > > It would be nice to have one obvious way to build on OS-X, so it makes > sense to remove this file in that case. However, I thought it might be > worth casting this question out before doing so. > > Cheers, > Mike > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Daniel Hyams [email protected] -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
