Menu
▾
▴
matplotlib-devel — matplotlib developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
| 2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
| 2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
| 2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
| 2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
| 2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
| 2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
| 2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
| 2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
| 2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
| 2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
| 2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Federico A. <ari...@gm...> - 2014-01-28 16:05:59
|
@tacaswell I modified the wiki reflecting the changes and trying to answer the questions. Please let me know if I answered your questions/concerns. We can iterate as muchs as needed on this, I have no problem modifying the names or functionnality. Sorry for the long email Here a list of things that I changed ToolBase description = '': Small description of the tool persistent = False: If True, the instance of the Tool is registered with Navigation for reuse. This is needed because some tools are keept alive in the background, for example SubplotTool. position = None: Where is it positionned in the toolbar?. -1 = at the end, None = Not in the toolbar. The default tools are all ordered by their position in the Navigation _default_tools array. This argument is mainly used by User created tools that are added after the Toolbar creation. My idea was that for the user created tools, the user could set the position without having to subclass the Navigation class. So this information has to be included in the Tool. activate(self, event): This is the main method of the Tool, it is called when the Tool is triggered by: * Toolbar button click * keypress associated with the Tool Keymap * Call to navigation.click_tool(name) ToolPersistentBase unregister(self, *args): ... Because ToolBase is intened for single use, there is no need of registration for the instances, persistent tools, need to be registered so __init__ is called only onece during the first trigger NavigationBase locks.... I tend to agree with you. The idea that I had in mind, and maybe was more complex than expected. Was to redirect the events to the tool without need to call the mpl_connect within the tool. So I provided the methods to handle those events directly. This is also from the idea that if we implement the MultiFigureManager, when there is a change on the 'active_figure' Navigation knows about the change and changes the event handlers, in this case the Tools don't need to do anything. It was just to simplify the Tool creation eliminating the need for basic event connection in case of figure changes. Even if we remove the locks we need two locks: canvaslock (for the input) keypress lock, to give the tool the option to absorb the keypress completely. (Tool for anotations comes to mind) I didn't remove the comment for the locks, because I am not sure what is the best option. ToolbarBase I tried to clarify the use of the methods. Most of the methods that you mentionned, are for internal use only but are mandatory for backend implementation. Also I updated the wiki with the "_" that was missing from the private methods. On Mon, Jan 27, 2014 at 9:12 PM, Thomas A Caswell <tca...@uc...> wrote: > I left some comments on the wiki (in []). Not sure what the best way > to leave comments is. > > On Mon, Jan 27, 2014 at 5:04 PM, Federico Ariza > <ari...@gm...> wrote: >> Hello everybody >> >> I just added "click_tool" to simulate a click programatically. >> https://github.com/matplotlib/matplotlib/pull/2759 >> >> Is there anything missing or that you want to change? >> I'm saturated so I don't see anything anymore. >> >> I would like to have some input specially in the `ToolbarBase` class. >> I am ready to start the implementation on the other backends, and this >> is the "new class" that have to be implemented for all the backends. >> `Navigation` is mostly copy paste from existing toolbar >> >> Thanks >> Federico >> >> On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson <pel...@gm...> wrote: >>> Hi Federico, >>> >>> I just wanted to say that I've been a little busy lately, but your MEP is >>> really shaping up - I really like the concepts that are being proposed and >>> think it will make a huge difference to people who want to implement custom >>> UIs. >>> >>> Keep up the great work, and continue trying to get feedback from all of us >>> on this! >>> >>> Thanks, >>> >>> Phil >>> >>> >>> On 24 January 2014 18:43, Federico Ariza <ari...@gm...> wrote: >>>> >>>> Hello everybody >>>> >>>> I just added some documentation for the MEP22 new classes and methods. >>>> Please take a look https://github.com/matplotlib/matplotlib/pull/2759 >>>> >>>> I ran into some problems, when trying to decide if some methods where >>>> public or not. >>>> >>>> If the method was used only for backend implementation pourposes I put >>>> it as private (name starts with underscore) but still documented them >>>> in the Notes section of the class. >>>> I don't know if this is the correct way to do it, but I couldn't decide. >>>> If you prefer any other way to do it, please let me know. >>>> >>>> Thank you >>>> Federico >>>> >>>> >>>> -- >>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? >>>> >>>> -- Antonio Alducin -- >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For >>>> Critical Workloads, Development Environments & Everything In Between. >>>> Get a Quote or Start a Free Trial Today. >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Matplotlib-devel mailing list >>>> Mat...@li... >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >>> >> >> >> >> -- >> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? >> >> -- Antonio Alducin -- >> >> ------------------------------------------------------------------------------ >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > -- > Thomas A Caswell > PhD Candidate University of Chicago > Nagel and Gardel labs > tca...@uc... > jfi.uchicago.edu/~tcaswell > o: 773.702.7204 -- Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? -- Antonio Alducin -- |
|
From: Ian T. <ian...@gm...> - 2014-01-28 08:59:30
|
Hi Nathan, To deal with your immediate problem of not wanting to see the deprecation warnings you can continue to use matplotlib.delaunay and suppress the warnings using e.g. http://docs.python.org/2/library/warnings.html#temporarily-suppressing-warnings. This will be OK for a year or two, but eventually we will completely remove matplotlib.delaunay. It will however give you time to come up with a solution. The short answer is 1) replace all use of matplotlib.delaunay.Triangulation with matplotlib.tri.Triangulation, and 2) use some other form of interpolation than natural neighbour! Matplotlib has linear and cubic triangular grid interpolators ( http://matplotlib.org/dev/api/tri_api.html); if these are acceptable your code changes should be minimal. scipy.interpolate has a few more options (but no natural neighbour) which will be a little more work. Even if you were to like the natgrid approach I would steer you away from it as I can see us removing it completely from matplotlib sometime in the future. Alternatively you could incorporate the matplotlib.delaunay code into your project and hence carry on using it as you are, but this would be madness as you would have to deal with the building of a C python extension, plus the delaunay code is 'not very robust'. You will no doubt have observed this to be the case, and it is the reason why matplotlib and scipy have moved away from it to use qhull instead. I expect we will add more triangular grid interpolators to matplotlib in due course and I am happy to receive suggestions on this. However, this will not include natural neighbour. Natural neighbour interpolation is specific to delaunay triangulation, and as we also support user-specified triangulations I am only interested in interpolation that covers all triangulations. I hope this has been of some help, but I fear not... Ian Thomas |
|
From: Thomas A C. <tca...@uc...> - 2014-01-28 02:12:22
|
I left some comments on the wiki (in []). Not sure what the best way to leave comments is. On Mon, Jan 27, 2014 at 5:04 PM, Federico Ariza <ari...@gm...> wrote: > Hello everybody > > I just added "click_tool" to simulate a click programatically. > https://github.com/matplotlib/matplotlib/pull/2759 > > Is there anything missing or that you want to change? > I'm saturated so I don't see anything anymore. > > I would like to have some input specially in the `ToolbarBase` class. > I am ready to start the implementation on the other backends, and this > is the "new class" that have to be implemented for all the backends. > `Navigation` is mostly copy paste from existing toolbar > > Thanks > Federico > > On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson <pel...@gm...> wrote: >> Hi Federico, >> >> I just wanted to say that I've been a little busy lately, but your MEP is >> really shaping up - I really like the concepts that are being proposed and >> think it will make a huge difference to people who want to implement custom >> UIs. >> >> Keep up the great work, and continue trying to get feedback from all of us >> on this! >> >> Thanks, >> >> Phil >> >> >> On 24 January 2014 18:43, Federico Ariza <ari...@gm...> wrote: >>> >>> Hello everybody >>> >>> I just added some documentation for the MEP22 new classes and methods. >>> Please take a look https://github.com/matplotlib/matplotlib/pull/2759 >>> >>> I ran into some problems, when trying to decide if some methods where >>> public or not. >>> >>> If the method was used only for backend implementation pourposes I put >>> it as private (name starts with underscore) but still documented them >>> in the Notes section of the class. >>> I don't know if this is the correct way to do it, but I couldn't decide. >>> If you prefer any other way to do it, please let me know. >>> >>> Thank you >>> Federico >>> >>> >>> -- >>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? >>> >>> -- Antonio Alducin -- >>> >>> >>> ------------------------------------------------------------------------------ >>> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>> Learn Why More Businesses Are Choosing CenturyLink Cloud For >>> Critical Workloads, Development Environments & Everything In Between. >>> Get a Quote or Start a Free Trial Today. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > > > > -- > Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? > > -- Antonio Alducin -- > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Thomas A Caswell PhD Candidate University of Chicago Nagel and Gardel labs tca...@uc... jfi.uchicago.edu/~tcaswell o: 773.702.7204 |
|
From: Nathan G. <nat...@gm...> - 2014-01-27 22:49:46
|
Hi all, I'm writing regarding an issue I'm having porting the yt package to properly handle some of the changes in matplotlib 1.4. yt is a python library for analysis and visualization of volumetric data, with a focus on astrophysical simulation datasets. We use matplotlib heavily for visualization tasks. For a while now, we've been using the natural neighbor interpolation in matplotlib.delaunay to generate contour plots from image data. See for example, this function: https://bitbucket.org/yt_analysis/yt/src/84b551a47ac462d646963f0b13e4dd0e85bd9751/yt/visualization/plot_modifications.py?at=yt#cl-311 In this example, self.triang is an instance of matplotlib.delaunay.triangulate.Triangulation. The bug report I opened regarding this issue might also be informative: https://bitbucket.org/yt_analysis/yt/issue/764/matplotlibdelaunay-deprecated-in I'm writing because it seems that matplotlib.delaunay was deprecated recently. This means users who import the yt plotting code will see a DeprecationWarning if they are running the upcoming matplotlib 1.4 release -- definitely an undesirable situation. Unfortunately, it looks like the workaround for this issue is to use natgrid to generate the interpolation. This is undesirable from our point of view since we have no way in general to control how users build their matplotlib installation. I'm curious whether any of the matplotlib developers have alternate ideas for how to do deal with this. Thanks for your help! -Nathan Goldbaum |
|
From: Federico A. <ari...@gm...> - 2014-01-27 22:05:02
|
Hello everybody I just added "click_tool" to simulate a click programatically. https://github.com/matplotlib/matplotlib/pull/2759 Is there anything missing or that you want to change? I'm saturated so I don't see anything anymore. I would like to have some input specially in the `ToolbarBase` class. I am ready to start the implementation on the other backends, and this is the "new class" that have to be implemented for all the backends. `Navigation` is mostly copy paste from existing toolbar Thanks Federico On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson <pel...@gm...> wrote: > Hi Federico, > > I just wanted to say that I've been a little busy lately, but your MEP is > really shaping up - I really like the concepts that are being proposed and > think it will make a huge difference to people who want to implement custom > UIs. > > Keep up the great work, and continue trying to get feedback from all of us > on this! > > Thanks, > > Phil > > > On 24 January 2014 18:43, Federico Ariza <ari...@gm...> wrote: >> >> Hello everybody >> >> I just added some documentation for the MEP22 new classes and methods. >> Please take a look https://github.com/matplotlib/matplotlib/pull/2759 >> >> I ran into some problems, when trying to decide if some methods where >> public or not. >> >> If the method was used only for backend implementation pourposes I put >> it as private (name starts with underscore) but still documented them >> in the Notes section of the class. >> I don't know if this is the correct way to do it, but I couldn't decide. >> If you prefer any other way to do it, please let me know. >> >> Thank you >> Federico >> >> >> -- >> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? >> >> -- Antonio Alducin -- >> >> >> ------------------------------------------------------------------------------ >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? -- Antonio Alducin -- |
|
From: Phil E. <pel...@gm...> - 2014-01-27 16:07:43
|
Hi Federico, I just wanted to say that I've been a little busy lately, but your MEP is really shaping up - I really like the concepts that are being proposed and think it will make a huge difference to people who want to implement custom UIs. Keep up the great work, and continue trying to get feedback from all of us on this! Thanks, Phil On 24 January 2014 18:43, Federico Ariza <ari...@gm...> wrote: > Hello everybody > > I just added some documentation for the MEP22 new classes and methods. > Please take a look https://github.com/matplotlib/matplotlib/pull/2759 > > I ran into some problems, when trying to decide if some methods where > public or not. > > If the method was used only for backend implementation pourposes I put > it as private (name starts with underscore) but still documented them > in the Notes section of the class. > I don't know if this is the correct way to do it, but I couldn't decide. > If you prefer any other way to do it, please let me know. > > Thank you > Federico > > > -- > Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? > > -- Antonio Alducin -- > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Phil E. <pel...@gm...> - 2014-01-27 16:00:02
|
Looks like there could be some white space around that block, as you say. ( https://raw.github.com/matplotlib/matplotlib/master/doc/contents.rst and https://github.com/matplotlib/matplotlib/blob/master/doc/contents.rst). Have you ever built the mpl docs? Are you interested in trying to fix this and submitting a PR? I'd happily review and merge in time for the v1.4 release. Phil On 8 January 2014 09:21, Pierre Haessig <pie...@cr...> wrote: > Hi, > > On the main doc page http://matplotlib.org/contents.html the "Examples" > section is misaligned (because it gets surrounded by a blockquote tag). > I guess it relates to the special treatment it gets in content.rst > (https://raw2.github.com/matplotlib/matplotlib/master/doc/contents.rst). > I don't know what magic is required to put it right (I always make > alignment errors myself with Sphinx...). Maybe just add or remove one > space ? > > best, > Pierre > > (beyond this alignment issue, I feel like this small Examples link is a > bit lost. It may deserve a stronger visual presence) > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
|
From: Phil E. <pel...@gm...> - 2014-01-27 15:56:01
|
Sadly I wont be - it is a bit of a long way for a non-scientific conference. Hoping to be able to attend SciPy again this year - there was a strong mpl contingent and we had some really successful introductory sprints held. Cheers, On 10 January 2014 14:49, Federico Ariza <ari...@gm...> wrote: > Hello everybody > > Is anybody going to pycon 2014 in Montreal. > Is there a sprint planned for that conference? > > Thanks > Federico > > -- > Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? > > -- Antonio Alducin -- > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Phil E. <pel...@gm...> - 2014-01-27 15:54:14
|
I've only just seen this, but thanks for sharing! The blog post was well thought out and very interesting. I really liked the "latest" style idea - I think that is something that gives us a bit of flexibility to change our minds about styles and continue to keep everybody moving forward with enhanced output. Out of interest, have you submitted your style to mpl master? I haven't seen anything go by, and can't see any reason why it can't be included in master, even if it isn't enabled by default. Essentially, I think Tony Yu et al.'s good work needs to be stretched in this way to ensure we are making the most of the new functionality, so please do submit PRs if there is something that can be improved! Cheers, On 13 January 2014 19:58, Chris Beaumont <bea...@ha...> wrote: > Hi Everyone, > > I found some time to look at the votes from the "Plot or Not?" experiment > Adrian Price-Whelan and I ran during SciPy last summer. You can take a look > at my summary at > http://datarazzi.wordpress.com/2014/01/13/plot-or-not-voting-results/, or > explore for yourself at http://plotornot.chrisbeaumont.org . > > Plot or Not was mostly a tongue-in-cheek idea, but there is nonetheless > some interesting information about style preferences in these data. I'm > happy to share the raw vote data if anyone is interested in digging further. > > Cheers, > Chris Beaumont > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
|
From: Federico A. <ari...@gm...> - 2014-01-24 18:44:15
|
Hello everybody I just added some documentation for the MEP22 new classes and methods. Please take a look https://github.com/matplotlib/matplotlib/pull/2759 I ran into some problems, when trying to decide if some methods where public or not. If the method was used only for backend implementation pourposes I put it as private (name starts with underscore) but still documented them in the Notes section of the class. I don't know if this is the correct way to do it, but I couldn't decide. If you prefer any other way to do it, please let me know. Thank you Federico -- Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? -- Antonio Alducin -- |
|
From: Michael D. <md...@st...> - 2014-01-24 16:34:59
|
matplotlib is not able to use .otf format fonts. We bundle a version where they have been converted to .ttf. We could update our code to use .otf fonts but it's considerable work, involving writing code on top of freetype to convert and subset our fonts, rather than the 15-year-old ttconv code we use now. Mike On 01/23/2014 06:00 PM, Paulo César Pereira de Andrade wrote: > Hi, > > I asked for a bundling exception in Fedora, see > > https://fedorahosted.org/fpc/ticket/381 > > But I should only be able to get a temporary one, > and that based on any feedback I receive here :-) > > Problem is, matplotlib bundles stix fonts 1.0, and > fedora, since fedora 18 ships stix fonts 1.1, that are > not "really" compatible with 1.0. > > I got things working for Fedora 18 by using > "USE_FONTCONFIG = True", but, every other distro, > probably sans Fedora spins bundles fonts and does > not use fontconfig. > > From fedora 18 to 20 several updates were made to > fix side effects of using fontconfig, then, ultimately, > fedora 20 was shipped with my patch to use fontconfig > removed, because the patch was (apparently) upstreamed > 95% workarounds to side effects of using fontconfig, but > the change to use fontconfig removed by mistake... So, > there is also a kind of chicken and egg problem, no > bundling policy, and no patching (or as few as possible and > with a good reason) policy. > > I would like to have any suggestion of a very good > reason to bundle stix fonts, or, some idea of how to > handle it, if matplotlib cannot use fontconfig by default > on Linux and *BSD. > > Thanks, > Paulo > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
|
From: Philippe Mallet-L. <phi...@ce...> - 2014-01-24 13:03:57
|
I want to apologies because, as some of you noted, I sent some e-mails to this list in which they were not destined for. It was a bad configuration of my mail client that I just corrected now so I hope it won't happen again. Please, sorry for the inconvenience. -- Philippe Mallet-Ladeira CEMES, UPR-8011 CNRS Groupe NanoMat Tél.: +33 [0]5 62 25 79 38 BP 94347 (29 Rue Jeanne Marvig) E-mail : phi...@ce... F-31055 Toulouse Cedex 4 France |
|
From: Paulo C. P. de A. <pau...@gm...> - 2014-01-23 23:00:48
|
Hi, I asked for a bundling exception in Fedora, see https://fedorahosted.org/fpc/ticket/381 But I should only be able to get a temporary one, and that based on any feedback I receive here :-) Problem is, matplotlib bundles stix fonts 1.0, and fedora, since fedora 18 ships stix fonts 1.1, that are not "really" compatible with 1.0. I got things working for Fedora 18 by using "USE_FONTCONFIG = True", but, every other distro, probably sans Fedora spins bundles fonts and does not use fontconfig. From fedora 18 to 20 several updates were made to fix side effects of using fontconfig, then, ultimately, fedora 20 was shipped with my patch to use fontconfig removed, because the patch was (apparently) upstreamed 95% workarounds to side effects of using fontconfig, but the change to use fontconfig removed by mistake... So, there is also a kind of chicken and egg problem, no bundling policy, and no patching (or as few as possible and with a good reason) policy. I would like to have any suggestion of a very good reason to bundle stix fonts, or, some idea of how to handle it, if matplotlib cannot use fontconfig by default on Linux and *BSD. Thanks, Paulo |
|
From: Federico A. <ari...@gm...> - 2014-01-22 14:39:39
|
Hello What if instead of removing the NavigationToolbar stuff, we add a rcParams['navigation'] to signal the use of the new classes insted of the old ones? This way we can add deprecation warnings to the old classes to smooth the transition. Personally I don't like the idea, this adds too many if/else patches. Federico -- Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? -- Antonio Alducin -- |
|
From: Federico A. <ari...@gm...> - 2014-01-21 17:31:57
|
Hello everybody I just updated the implmentation part of https://github.com/matplotlib/matplotlib/wiki/Mep22 to reflect what is already in place, should be clearer than navigate through the code The example should be working examples/navigation.py I know it is confusing, and there are better ways to do many of the things that I try to do. Please ask questions, make comments and give your opinion. For the time being I only implented the changes in GTK3, but if I see that you are happy with the shape this is going, I will do it for the other backends (where I know how to do it) and will ask for help (where I don't know how to do it) Thanks Federico -- Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? -- Antonio Alducin -- |
|
From: Philippe Mallet-L. <phi...@ce...> - 2014-01-21 11:31:16
|
Le mardi 21 janvier 2014 12:27:58 Nicolas Ratel-Ramond a écrit : > Salut Philippe, > > Pourrais-tu m'écrire noir sur blanc les infos que tu recherches dans les > fichiers TOPAS, afin que j'en fasse la demande auprès de mon collégue du > CIRIMAT? > En te remerciant, > Nicolas Salut Nicolas, alors, je veux l’aire des pics qui composent la raie 10 / 100. Il y en a plusieurs normalement. Mais s’il s’agit de faire un copier-coller, peut-être qu’il est possible de copier tous les paramètres de tous les pics? -- Philippe Mallet-Ladeira CEMES, UPR-8011 CNRS Groupe NanoMat Tél.: +33 [0]5 62 25 79 38 BP 94347 (29 Rue Jeanne Marvig) E-mail : phi...@ce... F-31055 Toulouse Cedex 4 France |
|
From: David R. <dav...@gm...> - 2014-01-19 17:31:48
|
I've implemented a new feature called shade_color which will either brighten or darken a color based on a certain percentage. Compare URL is here: https://github.com/dvreed77/matplotlib/compare/master...shade_color |
|
From: Mauricio C. <moc...@gm...> - 2014-01-18 19:16:02
|
Hi
I would like to know whether it is possible to save a simple (or complex,
for that matter) figure in 2 files, such that one of them contains, for
instance, the lines or points or surfaces ("graphics") typically in pdf
format and the other contains the whole text of the figure (labels,
numbers, title, annotations, etc). This is achievable in gnuplot via its
epslatex terminal and is highly convenient, in the sense that the fonts of
the figure match exactly the fonts (size, family, etc) of the main text in
which it will be embedded; even if we resize the figure, the corresponding
text, in perfect beautiful Latex, will match the surrounding main body text
of the master document. This is also possible with Inkscape and its
PDF+Latex saving option.
Is this possible with matplotlib or are there any workarounds?
--
#######################################
Prof. Mauricio Ortiz Calvao
Federal University of Rio de Janeiro
Institute of Physics, P O Box 68528
CEP 21941-972 Rio de Janeiro, RJ
Brazil
Email: or...@if...
Phone: (55)(21)25627483
Homepage: http://www.if.ufrj.br/~orca
#######################################
|
|
From: Philippe Mallet-L. <phi...@ce...> - 2014-01-17 16:37:27
|
Merci pour ce retour. Ce colloque avait l’air intéressant. Peut-être qu’inviter des journalistes à ce genre d’événements pourrait être intéressant pour l’image du CNRS auprès du grand publique (et des politiques). Surtout que pour le coup, l’actualité s’y prêtait bien. Je n’y était pas donc je ne peux savoir, mais peut-être était-ce le cas. Pour le GFEC, je n’en ai pas encore parlé avec Marc, mais j’aurai fini mon contrat donc il est fort probable que je n’y soit pas. En tout cas, je te souhaite une bonne présidence, Le vendredi 17 janvier 2014 10:29:29 Roland Pellenq a écrit : > Hello Philippe, > > Meilleurs voeux également, > > J'ai co-organisé il ya 3 jours une journée gaz/ et huiles de schistes au > siège du CNRS pour faire le trou dans le CNRS des problématiques > scientifiques et verrous technos. On a eu des séminaires d'excellent niveau > couvrant tous les aspect depuis la géole, les ressources (en France), la > sismique, le transport en milieu poreux, la fracturation, le cimentage des > puits, la texture et la poromécanique des kérogènes etc.. . Tu peux voir le > programme et les présentations (bientôt en ligne) sur le site de la mission > pour l'interdisciplinarité du CNRS. Pour faire court,on a tout mis sur la > table sans restriction montrant que le CNRS est l'organisme qui couvre > tous les > champs de recherche et technos si un jour on devait considérer de mener une > étude quantitative de la faisabilité de schistes. Bref le CNRS est prêt et a > toutes les ressources pour ça. Le CEMES était représenté par Marc et > Pascal. > > Revenant à la position de l'UE: je ne suis pas surpris vu les enjeux et la > diversités de position des pays membres ne serait-ce qu'en matière de droit > du sol et de législation minière. je ne suis pas surpris non plus que le UK > ne veule pas de régulation vu que les US n'en ont pas encore (le rapport du > US-EPA est prévu pour le printemps 2014 et devraient fixer les bonnes > pratiques). > Les 2 vrais enjeux techniques cf l'environnement sont le traitement de > l'eau qui > remonte, et les fuites de gaz dû et à la misère du cimentage des puits. > > Au plaisir de te voir (au colloque du GFEC en mai prochain ?) > > Roland > > Philippe Mallet-Ladeira <phi...@ce...> a écrit : > > Bonjour Roland et bonne année, > > > > je viens de voir dans le monde l’article suivant: > > L'UE renonce à encadrer l’exploitation du gaz de schiste[1] > > > > sous la pression du Royaume-Uni (entre autres), ils ont préféré donner > > uniquement des recommandations. > > > > En tant qu’expert, quel est ton avis: > > - enfin! > > ou: > > - enfin, mais pas comme ça ! > > > > Cordialement, > > > > -- > > Philippe Mallet-Ladeira > > > > CEMES, UPR-8011 CNRS > > Groupe NanoMat Tél.: +33 [0]5 62 25 79 38 > > BP 94347 (29 Rue Jeanne Marvig) E-mail : phi...@ce... > > F-31055 Toulouse Cedex 4 > > France > > > > > > -------- > > [1] > > http://www.lemonde.fr/planete/article/2014/01/17/bruxelles-renonce-a-encad > > rer-l-exploitation-du-gaz-de-schiste_4349808_3244.html -- Philippe Mallet-Ladeira CEMES, UPR-8011 CNRS Groupe NanoMat Tél.: +33 [0]5 62 25 79 38 BP 94347 (29 Rue Jeanne Marvig) E-mail : phi...@ce... F-31055 Toulouse Cedex 4 France |
|
From: Benjamin R. <ben...@ou...> - 2014-01-17 14:33:38
|
So that's how you do it?! That has been driving me nuts! On Thu, Jan 16, 2014 at 9:35 PM, Tony Yu <ts...@gm...> wrote: > > > > On Thu, Jan 16, 2014 at 7:30 AM, Michael Droettboom <md...@st...>wrote: > >> Yes, there's room. >> >> This is the link that Google gives me for the calendar: >> >> >> https://www.google.com/calendar/feeds/79hk8jhvlks8jn8ds4ri1e6q4g%40group.calendar.google.com/public/basic >> >> Let me know whether that works... >> >> Mike >> >> > My bad: I expected clicking the link to add the calendar to my GCal > account. I didn't realize I had to copy the address to the "Add by URL" > dialog under "Other Calendars". So primitive :P > > Thanks for letting me lurk during the meeting, > -Tony > > |
|
From: Tony Yu <ts...@gm...> - 2014-01-17 02:36:28
|
On Thu, Jan 16, 2014 at 7:30 AM, Michael Droettboom <md...@st...> wrote: > Yes, there's room. > > This is the link that Google gives me for the calendar: > > > https://www.google.com/calendar/feeds/79hk8jhvlks8jn8ds4ri1e6q4g%40group.calendar.google.com/public/basic > > Let me know whether that works... > > Mike > > My bad: I expected clicking the link to add the calendar to my GCal account. I didn't realize I had to copy the address to the "Add by URL" dialog under "Other Calendars". So primitive :P Thanks for letting me lurk during the meeting, -Tony |
|
From: Michael D. <md...@st...> - 2014-01-16 13:56:05
|
The developer hangout is starting in 5 minutes... https://plus.google.com/events/co10krvm0qm1tb8s2jau50t4iq0 -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
|
From: Michael D. <md...@st...> - 2014-01-16 13:35:45
|
Yes, there's room. This is the link that Google gives me for the calendar: https://www.google.com/calendar/feeds/79hk8jhvlks8jn8ds4ri1e6q4g%40group.calendar.google.com/public/basic Let me know whether that works... Mike On 01/15/2014 11:42 PM, Tony Yu wrote: > Is there room for a lurker in the hangout? If so, is there a link for > joining the hangout? (I tried using the hangout calendar link from > awhile back, but I couldn't get my google calendar to recognize it.) > > Cheers, > -Tony > > > On Wed, Jan 15, 2014 at 9:57 AM, Michael Droettboom <md...@st... > <mailto:md...@st...>> wrote: > > On 01/14/2014 03:49 PM, Chris Beaumont wrote: >> I have another long-simmering feature request along these lines: >> if Matplotlib were to evolve a formal DOM-like figure structure >> like mentioned above, it would be cool if this structure retained >> more semantic information about the visualization itself. By >> this, I mean that many high-level commands like hist, scatter, >> etc. spawn a bunch of low level artists like rectangles and >> circles. After these methods exit, it's hard/impossible to >> introspect a Figure and diagnose that it, for example, is a >> histogram and not a bar chart. > > I agree, this would be very nice to have, but is (obviously) a > much bigger step from what we currently have in matplotlib. Along > those lines, if the "frontend" (i.e. the pylab interface and even > the OO interface) basically generate a tree, then you could > serialize that tree (here XML would be a great fit, don't knock > it), and even non-Python based tools could transform it into > something else. > > >> >> Retaining a better high-level description of a plot (which >> probably amounts to creating more compound artist types) would >> make it easier to build tools like mpld3 and other cool things >> that involve runtime editing or optimization of tree-like data >> structures. > > Agreed. > > No argument against this at all from me -- but knowing how much > work this would be, the obstacle there is just finding the time to > do it. It would be a significant rewrite... > > Mike > > >> >> chris >> >> >> On Tue, Jan 14, 2014 at 3:34 PM, Jacob Vanderplas >> <ja...@cs... <mailto:ja...@cs...>> wrote: >> >> On Tue, Jan 14, 2014 at 12:04 PM, Michael Droettboom >> <md...@st... <mailto:md...@st...>> wrote: >> >> >> I hope all of the above makes sense... >> >> >> Definitely makes sense: what I've built-up in mpld3 is >> essentially something that mimics this sort of visitor >> pattern, though it misses some things because of the >> draw-time difficulties you mention. >> I think a two-stage draw() would be a _very_ helpful >> restructure. Currently, I'm forced to achieve this result by >> writing a png to a throwaway byte-stream... >> Jake >> >> >> Mike >> >> >> On 01/14/2014 01:30 PM, Jacob Vanderplas wrote: >>> Thanks - we'll make it happen at some point. >>> >>> Perhaps I can give the seed for a discussion: the stuff >>> I've been doing with mpld3 is a lot of fun, but it's >>> fundamentally limited by the fact that I have to dig >>> around the internals of the figure object to find the >>> relevant information to construct a plot representation. >>> I may be able to do the same thing by creating a >>> backend, but the problem is that the draw() methods of >>> most objects call the renderer with no reference to >>> whether the points lie in the data space or figure >>> space: that is, paths and points are usually specified >>> in figure/pixel coordinates or some transformed version >>> thereof, which makes it near impossible to construct >>> interactive representations absent Python kernel callbacks. >>> >>> What I'd love to see is some enhancement of the backend >>> framework where there are some extra flags and >>> information passed to the renderer: i.e. for each draw >>> command, we need to know whether the drawn object should >>> be linked to static figure coordinates or to dynamic >>> axes/data coordinates. >>> >>> I've been in touch with Cyrille Rossant from the vispy >>> team, Chris Beaumont from the Glue team, and Matt >>> Sundwuist from the plotly team, all of whom asked if >>> there might be a way to use what I've done with mpld3 to >>> enable matplotlib to export into their own front-end >>> format. I didn't start mpld3 with that sort of >>> extensibility in mind, but I'm starting to invest some >>> time thinking about how to design that. >>> >>> With the current matplotlib package, I think there are >>> two ways to accomplish it: one is to create a general >>> backend-like interface based on the figure introspection >>> that mpld3 currently uses. The artist elements in each >>> figure contain enough information to be able to infer >>> whether the elements should move & zoom with the axes or >>> not. The problem is, a lot of elements (like legends, >>> axes aspects, etc.) are not fully established until the >>> draw() command is called, so there are a few ugly hacks >>> required to make it happen. >>> >>> The other option is to use an even uglier hack, and wrap >>> the current backend framework with an object that >>> somehow links back into the figure and infers from the >>> draw_*() commands whether the path/point/marker/etc. >>> should be drawn in static figure coordinates or in >>> dynamic axes coordinates. I've started a simple >>> prototype backend translator which has a renderer class >>> that uses ``inspect`` back-trace the stack and >>> accomplish this: It's really ugly, and I'm not >>> particularly proud about it, but I think it's the >>> current best way to accomplish the desired behavior. >>> >>> Ugly hacks aside, I think all of this points to a >>> general desire for a new type of backend-like hook that >>> can export dynamic plot elements in data coordinates, >>> and static plot elements in figure coordinates. An >>> enhancement in that direction could pave the way for a >>> lot of interesting interactive front-ends to matplotlib >>> figures. >>> >>> Anyway - if any of you have suggestions or responses to >>> this, I'd love to hear them! Thanks, >>> Jake >>> >>> >>> On Tue, Jan 14, 2014 at 9:11 AM, Michael Droettboom >>> <md...@st... <mailto:md...@st...>> wrote: >>> >>> Jake: I'd definitely like to get you into one of >>> these calls at some point. If you're able to pop in >>> late, that would still be great -- or we can save >>> that for another date. Trying to get Japan, three >>> NA timezones and the UK all together is challenging ;) >>> >>> In any event, with Thomas, Ben, Michiel and myself >>> confirmed, I think that's enough to go ahead, and >>> hopefully others who have yet to respond can join as >>> well. >>> >>> Mike >>> >>> >>> On 01/14/2014 11:57 AM, Jacob Vanderplas wrote: >>>> I'll probably not be able to swing 6am on the west >>>> coast, but other folks are more important for this >>>> call, I think :) >>>> Jake >>>> >>>> >>>> On Tue, Jan 14, 2014 at 8:51 AM, Benjamin Root >>>> <ben...@ou... <mailto:ben...@ou...>> wrote: >>>> >>>> That would actually work a little bit better >>>> for me... I just have to remember to get into >>>> work a little bit earlier. >>>> >>>> Ben >>>> >>>> On Tue, Jan 14, 2014 at 11:36 AM, Michael >>>> Droettboom <md...@st... >>>> <mailto:md...@st...>> wrote: >>>> >>>> I'm fine with starting the meeting an hour >>>> early. How about others? >>>> >>>> Mike >>>> >>>> On 01/14/2014 04:57 AM, Michiel de Hoon wrote: >>>> > I can join this Thursday if we start with >>>> the discussion on timers. >>>> > If we can start 1 hour earlier (14:00 >>>> UTC, 9 am ET, 23:00 in Japan) that would be >>>> even better. >>>> > -Michiel. >>>> > >>>> > >>>> > >>>> > -------------------------------------------- >>>> > On Mon, 1/13/14, Michael Droettboom >>>> <md...@st... <mailto:md...@st...>> >>>> wrote: >>>> > >>>> > Subject: [matplotlib-devel] Meeting...? >>>> > To: >>>> "mat...@li... >>>> <mailto:mat...@li...>" >>>> <mat...@li... >>>> <mailto:mat...@li...>> >>>> > Date: Monday, January 13, 2014, 11:36 AM >>>> > >>>> > It's probably a good time to schedule >>>> > another matplotlib Google Hangout. >>>> > >>>> > Is this Thursday at 1500 UTC (10 am ET) >>>> too short notice for >>>> > the usual >>>> > candidates? >>>> > >>>> > I know there was discussion of getting >>>> Michiel de Hoon on >>>> > today (which I >>>> > just saw, unfortunately). Is there >>>> another time in the >>>> > future that >>>> > works for you, Michiel? >>>> > >>>> > Mike >>>> > >>>> > -- >>>> > >>>> > _ >>>> > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ >>>> > _ ._ _ >>>> > | ||(_| |(_|(/_| |_/|(_)(/_|_ >>>> |_|_)(_)(_)| | | >>>> > >>>> > http://www.droettboom.com >>>> > >>>> > >>>> > >>>> ------------------------------------------------------------------------------ >>>> > CenturyLink Cloud: The Leader in >>>> Enterprise Cloud Services. >>>> > Learn Why More Businesses Are Choosing >>>> CenturyLink Cloud >>>> > For >>>> > Critical Workloads, Development >>>> Environments & >>>> > Everything In Between. >>>> > Get a Quote or Start a Free Trial Today. >>>> > >>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>>> > >>>> _______________________________________________ >>>> > Matplotlib-devel mailing list >>>> > Mat...@li... >>>> <mailto:Mat...@li...> >>>> > >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>> > >>>> >>>> >>>> -- >>>> _ >>>> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ >>>> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >>>> >>>> http://www.droettboom.com >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> CenturyLink Cloud: The Leader in Enterprise >>>> Cloud Services. >>>> Learn Why More Businesses Are Choosing >>>> CenturyLink Cloud For >>>> Critical Workloads, Development >>>> Environments & Everything In Between. >>>> Get a Quote or Start a Free Trial Today. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Matplotlib-devel mailing list >>>> Mat...@li... >>>> <mailto:Mat...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> CenturyLink Cloud: The Leader in Enterprise >>>> Cloud Services. >>>> Learn Why More Businesses Are Choosing >>>> CenturyLink Cloud For >>>> Critical Workloads, Development Environments & >>>> Everything In Between. >>>> Get a Quote or Start a Free Trial Today. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Matplotlib-devel mailing list >>>> Mat...@li... >>>> <mailto:Mat...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>> >>>> >>> >>> >>> -- >>> _ >>> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ >>> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >>> >>> http://www.droettboom.com >>> >>> >> >> >> -- >> _ >> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ >> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >> >> http://www.droettboom.com >> >> >> >> ------------------------------------------------------------------------------ >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In >> Between. >> Get a Quote or Start a Free Trial Today. >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> <mailto:Mat...@li...> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> >> >> >> -- >> ************************************ >> Chris Beaumont >> Graduate Student >> Institute for Astronomy >> University of Hawaii at Manoa >> 2680 Woodlawn Drive >> Honolulu, HI 96822 >> www.ifa.hawaii.edu/~beaumont <http://www.ifa.hawaii.edu/%7Ebeaumont> >> ************************************ > > > -- > _ > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | > > http://www.droettboom.com > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
|
From: Tony Yu <ts...@gm...> - 2014-01-16 04:42:58
|
Is there room for a lurker in the hangout? If so, is there a link for joining the hangout? (I tried using the hangout calendar link from awhile back, but I couldn't get my google calendar to recognize it.) Cheers, -Tony On Wed, Jan 15, 2014 at 9:57 AM, Michael Droettboom <md...@st...> wrote: > On 01/14/2014 03:49 PM, Chris Beaumont wrote: > > I have another long-simmering feature request along these lines: if > Matplotlib were to evolve a formal DOM-like figure structure like mentioned > above, it would be cool if this structure retained more semantic > information about the visualization itself. By this, I mean that many > high-level commands like hist, scatter, etc. spawn a bunch of low level > artists like rectangles and circles. After these methods exit, it's > hard/impossible to introspect a Figure and diagnose that it, for example, > is a histogram and not a bar chart. > > > I agree, this would be very nice to have, but is (obviously) a much bigger > step from what we currently have in matplotlib. Along those lines, if the > "frontend" (i.e. the pylab interface and even the OO interface) basically > generate a tree, then you could serialize that tree (here XML would be a > great fit, don't knock it), and even non-Python based tools could transform > it into something else. > > > > Retaining a better high-level description of a plot (which probably > amounts to creating more compound artist types) would make it easier to > build tools like mpld3 and other cool things that involve runtime editing > or optimization of tree-like data structures. > > > Agreed. > > No argument against this at all from me -- but knowing how much work this > would be, the obstacle there is just finding the time to do it. It would > be a significant rewrite... > > Mike > > > > chris > > > On Tue, Jan 14, 2014 at 3:34 PM, Jacob Vanderplas < > ja...@cs...> wrote: > >> On Tue, Jan 14, 2014 at 12:04 PM, Michael Droettboom <md...@st...>wrote: >> >>> >>> I hope all of the above makes sense... >>> >> >> Definitely makes sense: what I've built-up in mpld3 is essentially >> something that mimics this sort of visitor pattern, though it misses some >> things because of the draw-time difficulties you mention. >> I think a two-stage draw() would be a _very_ helpful restructure. >> Currently, I'm forced to achieve this result by writing a png to a >> throwaway byte-stream... >> Jake >> >> >>> >>> Mike >>> >>> >>> On 01/14/2014 01:30 PM, Jacob Vanderplas wrote: >>> >>> Thanks - we'll make it happen at some point. >>> >>> Perhaps I can give the seed for a discussion: the stuff I've been >>> doing with mpld3 is a lot of fun, but it's fundamentally limited by the >>> fact that I have to dig around the internals of the figure object to find >>> the relevant information to construct a plot representation. I may be able >>> to do the same thing by creating a backend, but the problem is that the >>> draw() methods of most objects call the renderer with no reference to >>> whether the points lie in the data space or figure space: that is, paths >>> and points are usually specified in figure/pixel coordinates or some >>> transformed version thereof, which makes it near impossible to construct >>> interactive representations absent Python kernel callbacks. >>> >>> What I'd love to see is some enhancement of the backend framework >>> where there are some extra flags and information passed to the renderer: >>> i.e. for each draw command, we need to know whether the drawn object should >>> be linked to static figure coordinates or to dynamic axes/data coordinates. >>> >>> I've been in touch with Cyrille Rossant from the vispy team, Chris >>> Beaumont from the Glue team, and Matt Sundwuist from the plotly team, all >>> of whom asked if there might be a way to use what I've done with mpld3 to >>> enable matplotlib to export into their own front-end format. I didn't >>> start mpld3 with that sort of extensibility in mind, but I'm starting to >>> invest some time thinking about how to design that. >>> >>> With the current matplotlib package, I think there are two ways to >>> accomplish it: one is to create a general backend-like interface based on >>> the figure introspection that mpld3 currently uses. The artist elements in >>> each figure contain enough information to be able to infer whether the >>> elements should move & zoom with the axes or not. The problem is, a lot of >>> elements (like legends, axes aspects, etc.) are not fully established until >>> the draw() command is called, so there are a few ugly hacks required to >>> make it happen. >>> >>> The other option is to use an even uglier hack, and wrap the current >>> backend framework with an object that somehow links back into the figure >>> and infers from the draw_*() commands whether the path/point/marker/etc. >>> should be drawn in static figure coordinates or in dynamic axes >>> coordinates. I've started a simple prototype backend translator which has a >>> renderer class that uses ``inspect`` back-trace the stack and accomplish >>> this: It's really ugly, and I'm not particularly proud about it, but I >>> think it's the current best way to accomplish the desired behavior. >>> >>> Ugly hacks aside, I think all of this points to a general desire for a >>> new type of backend-like hook that can export dynamic plot elements in data >>> coordinates, and static plot elements in figure coordinates. An >>> enhancement in that direction could pave the way for a lot of interesting >>> interactive front-ends to matplotlib figures. >>> >>> Anyway - if any of you have suggestions or responses to this, I'd love >>> to hear them! Thanks, >>> Jake >>> >>> >>> On Tue, Jan 14, 2014 at 9:11 AM, Michael Droettboom <md...@st...>wrote: >>> >>>> Jake: I'd definitely like to get you into one of these calls at some >>>> point. If you're able to pop in late, that would still be great -- or we >>>> can save that for another date. Trying to get Japan, three NA timezones >>>> and the UK all together is challenging ;) >>>> >>>> In any event, with Thomas, Ben, Michiel and myself confirmed, I think >>>> that's enough to go ahead, and hopefully others who have yet to respond can >>>> join as well. >>>> >>>> Mike >>>> >>>> >>>> On 01/14/2014 11:57 AM, Jacob Vanderplas wrote: >>>> >>>> I'll probably not be able to swing 6am on the west coast, but other >>>> folks are more important for this call, I think :) >>>> Jake >>>> >>>> >>>> On Tue, Jan 14, 2014 at 8:51 AM, Benjamin Root <ben...@ou...> wrote: >>>> >>>>> That would actually work a little bit better for me... I just have to >>>>> remember to get into work a little bit earlier. >>>>> >>>>> Ben >>>>> >>>>> On Tue, Jan 14, 2014 at 11:36 AM, Michael Droettboom <md...@st...>wrote: >>>>> >>>>>> I'm fine with starting the meeting an hour early. How about others? >>>>>> >>>>>> Mike >>>>>> >>>>>> On 01/14/2014 04:57 AM, Michiel de Hoon wrote: >>>>>> > I can join this Thursday if we start with the discussion on timers. >>>>>> > If we can start 1 hour earlier (14:00 UTC, 9 am ET, 23:00 in Japan) >>>>>> that would be even better. >>>>>> > -Michiel. >>>>>> > >>>>>> > >>>>>> > >>>>>> > -------------------------------------------- >>>>>> > On Mon, 1/13/14, Michael Droettboom <md...@st...> wrote: >>>>>> > >>>>>> > Subject: [matplotlib-devel] Meeting...? >>>>>> > To: "mat...@li..." < >>>>>> mat...@li...> >>>>>> > Date: Monday, January 13, 2014, 11:36 AM >>>>>> > >>>>>> > It's probably a good time to schedule >>>>>> > another matplotlib Google Hangout. >>>>>> > >>>>>> > Is this Thursday at 1500 UTC (10 am ET) too short notice for >>>>>> > the usual >>>>>> > candidates? >>>>>> > >>>>>> > I know there was discussion of getting Michiel de Hoon on >>>>>> > today (which I >>>>>> > just saw, unfortunately). Is there another time in the >>>>>> > future that >>>>>> > works for you, Michiel? >>>>>> > >>>>>> > Mike >>>>>> > >>>>>> > -- >>>>>> > >>>>>> > _ >>>>>> > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ >>>>>> > _ ._ _ >>>>>> > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >>>>>> > >>>>>> > http://www.droettboom.com >>>>>> > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------------------------ >>>>>> > CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>>>>> > Learn Why More Businesses Are Choosing CenturyLink Cloud >>>>>> > For >>>>>> > Critical Workloads, Development Environments & >>>>>> > Everything In Between. >>>>>> > Get a Quote or Start a Free Trial Today. >>>>>> > >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>>>>> > _______________________________________________ >>>>>> > Matplotlib-devel mailing list >>>>>> > Mat...@li... >>>>>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>>> > >>>>>> >>>>>> >>>>>> -- >>>>>> _ >>>>>> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ >>>>>> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >>>>>> >>>>>> http://www.droettboom.com >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>>>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For >>>>>> Critical Workloads, Development Environments & Everything In Between. >>>>>> Get a Quote or Start a Free Trial Today. >>>>>> >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Matplotlib-devel mailing list >>>>>> Mat...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For >>>>> Critical Workloads, Development Environments & Everything In Between. >>>>> Get a Quote or Start a Free Trial Today. >>>>> >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Matplotlib-devel mailing list >>>>> Mat...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>>> >>>>> >>>> >>>> >>>> -- >>>> _ >>>> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ >>>> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >>>> http://www.droettboom.com >>>> >>>> >>> >>> >>> -- >>> _ >>> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ >>> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >>> http://www.droettboom.com >>> >>> >> >> >> ------------------------------------------------------------------------------ >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > > > -- > ************************************ > Chris Beaumont > Graduate Student > Institute for Astronomy > University of Hawaii at Manoa > 2680 Woodlawn Drive > Honolulu, HI 96822 > www.ifa.hawaii.edu/~beaumont <http://www.ifa.hawaii.edu/%7Ebeaumont> > ************************************ > > > > -- > _ > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | > http://www.droettboom.com > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
|
From: Michael D. <md...@st...> - 2014-01-15 16:02:00
|
On 01/14/2014 03:49 PM, Chris Beaumont wrote: > I have another long-simmering feature request along these lines: if > Matplotlib were to evolve a formal DOM-like figure structure like > mentioned above, it would be cool if this structure retained more > semantic information about the visualization itself. By this, I mean > that many high-level commands like hist, scatter, etc. spawn a bunch > of low level artists like rectangles and circles. After these methods > exit, it's hard/impossible to introspect a Figure and diagnose that > it, for example, is a histogram and not a bar chart. I agree, this would be very nice to have, but is (obviously) a much bigger step from what we currently have in matplotlib. Along those lines, if the "frontend" (i.e. the pylab interface and even the OO interface) basically generate a tree, then you could serialize that tree (here XML would be a great fit, don't knock it), and even non-Python based tools could transform it into something else. > > Retaining a better high-level description of a plot (which probably > amounts to creating more compound artist types) would make it easier > to build tools like mpld3 and other cool things that involve runtime > editing or optimization of tree-like data structures. Agreed. No argument against this at all from me -- but knowing how much work this would be, the obstacle there is just finding the time to do it. It would be a significant rewrite... Mike > > chris > > > On Tue, Jan 14, 2014 at 3:34 PM, Jacob Vanderplas > <ja...@cs... <mailto:ja...@cs...>> wrote: > > On Tue, Jan 14, 2014 at 12:04 PM, Michael Droettboom > <md...@st... <mailto:md...@st...>> wrote: > > > I hope all of the above makes sense... > > > Definitely makes sense: what I've built-up in mpld3 is essentially > something that mimics this sort of visitor pattern, though it > misses some things because of the draw-time difficulties you mention. > I think a two-stage draw() would be a _very_ helpful restructure. > Currently, I'm forced to achieve this result by writing a png to > a throwaway byte-stream... > Jake > > > Mike > > > On 01/14/2014 01:30 PM, Jacob Vanderplas wrote: >> Thanks - we'll make it happen at some point. >> >> Perhaps I can give the seed for a discussion: the stuff I've >> been doing with mpld3 is a lot of fun, but it's fundamentally >> limited by the fact that I have to dig around the internals >> of the figure object to find the relevant information to >> construct a plot representation. I may be able to do the >> same thing by creating a backend, but the problem is that the >> draw() methods of most objects call the renderer with no >> reference to whether the points lie in the data space or >> figure space: that is, paths and points are usually specified >> in figure/pixel coordinates or some transformed version >> thereof, which makes it near impossible to construct >> interactive representations absent Python kernel callbacks. >> >> What I'd love to see is some enhancement of the backend >> framework where there are some extra flags and information >> passed to the renderer: i.e. for each draw command, we need >> to know whether the drawn object should be linked to static >> figure coordinates or to dynamic axes/data coordinates. >> >> I've been in touch with Cyrille Rossant from the vispy team, >> Chris Beaumont from the Glue team, and Matt Sundwuist from >> the plotly team, all of whom asked if there might be a way to >> use what I've done with mpld3 to enable matplotlib to export >> into their own front-end format. I didn't start mpld3 with >> that sort of extensibility in mind, but I'm starting to >> invest some time thinking about how to design that. >> >> With the current matplotlib package, I think there are two >> ways to accomplish it: one is to create a general >> backend-like interface based on the figure introspection that >> mpld3 currently uses. The artist elements in each figure >> contain enough information to be able to infer whether the >> elements should move & zoom with the axes or not. The >> problem is, a lot of elements (like legends, axes aspects, >> etc.) are not fully established until the draw() command is >> called, so there are a few ugly hacks required to make it happen. >> >> The other option is to use an even uglier hack, and wrap the >> current backend framework with an object that somehow links >> back into the figure and infers from the draw_*() commands >> whether the path/point/marker/etc. should be drawn in static >> figure coordinates or in dynamic axes coordinates. I've >> started a simple prototype backend translator which has a >> renderer class that uses ``inspect`` back-trace the stack and >> accomplish this: It's really ugly, and I'm not particularly >> proud about it, but I think it's the current best way to >> accomplish the desired behavior. >> >> Ugly hacks aside, I think all of this points to a general >> desire for a new type of backend-like hook that can export >> dynamic plot elements in data coordinates, and static plot >> elements in figure coordinates. An enhancement in that >> direction could pave the way for a lot of interesting >> interactive front-ends to matplotlib figures. >> >> Anyway - if any of you have suggestions or responses to this, >> I'd love to hear them! Thanks, >> Jake >> >> >> On Tue, Jan 14, 2014 at 9:11 AM, Michael Droettboom >> <md...@st... <mailto:md...@st...>> wrote: >> >> Jake: I'd definitely like to get you into one of these >> calls at some point. If you're able to pop in late, that >> would still be great -- or we can save that for another >> date. Trying to get Japan, three NA timezones and the UK >> all together is challenging ;) >> >> In any event, with Thomas, Ben, Michiel and myself >> confirmed, I think that's enough to go ahead, and >> hopefully others who have yet to respond can join as well. >> >> Mike >> >> >> On 01/14/2014 11:57 AM, Jacob Vanderplas wrote: >>> I'll probably not be able to swing 6am on the west >>> coast, but other folks are more important for this call, >>> I think :) >>> Jake >>> >>> >>> On Tue, Jan 14, 2014 at 8:51 AM, Benjamin Root >>> <ben...@ou... <mailto:ben...@ou...>> wrote: >>> >>> That would actually work a little bit better for >>> me... I just have to remember to get into work a >>> little bit earlier. >>> >>> Ben >>> >>> On Tue, Jan 14, 2014 at 11:36 AM, Michael Droettboom >>> <md...@st... <mailto:md...@st...>> wrote: >>> >>> I'm fine with starting the meeting an hour >>> early. How about others? >>> >>> Mike >>> >>> On 01/14/2014 04:57 AM, Michiel de Hoon wrote: >>> > I can join this Thursday if we start with the >>> discussion on timers. >>> > If we can start 1 hour earlier (14:00 UTC, 9 >>> am ET, 23:00 in Japan) that would be even better. >>> > -Michiel. >>> > >>> > >>> > >>> > -------------------------------------------- >>> > On Mon, 1/13/14, Michael Droettboom >>> <md...@st... <mailto:md...@st...>> wrote: >>> > >>> > Subject: [matplotlib-devel] Meeting...? >>> > To: "mat...@li... >>> <mailto:mat...@li...>" >>> <mat...@li... >>> <mailto:mat...@li...>> >>> > Date: Monday, January 13, 2014, 11:36 AM >>> > >>> > It's probably a good time to schedule >>> > another matplotlib Google Hangout. >>> > >>> > Is this Thursday at 1500 UTC (10 am ET) too >>> short notice for >>> > the usual >>> > candidates? >>> > >>> > I know there was discussion of getting >>> Michiel de Hoon on >>> > today (which I >>> > just saw, unfortunately). Is there another >>> time in the >>> > future that >>> > works for you, Michiel? >>> > >>> > Mike >>> > >>> > -- >>> > >>> > _ >>> > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ >>> > _ ._ _ >>> > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >>> > >>> > http://www.droettboom.com >>> > >>> > >>> > >>> ------------------------------------------------------------------------------ >>> > CenturyLink Cloud: The Leader in Enterprise >>> Cloud Services. >>> > Learn Why More Businesses Are Choosing >>> CenturyLink Cloud >>> > For >>> > Critical Workloads, Development Environments & >>> > Everything In Between. >>> > Get a Quote or Start a Free Trial Today. >>> > >>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>> > _______________________________________________ >>> > Matplotlib-devel mailing list >>> > Mat...@li... >>> <mailto:Mat...@li...> >>> > >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> > >>> >>> >>> -- >>> _ >>> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ >>> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >>> >>> http://www.droettboom.com >>> >>> >>> ------------------------------------------------------------------------------ >>> CenturyLink Cloud: The Leader in Enterprise >>> Cloud Services. >>> Learn Why More Businesses Are Choosing >>> CenturyLink Cloud For >>> Critical Workloads, Development Environments & >>> Everything In Between. >>> Get a Quote or Start a Free Trial Today. >>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Mat...@li... >>> <mailto:Mat...@li...> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> CenturyLink Cloud: The Leader in Enterprise Cloud >>> Services. >>> Learn Why More Businesses Are Choosing CenturyLink >>> Cloud For >>> Critical Workloads, Development Environments & >>> Everything In Between. >>> Get a Quote or Start a Free Trial Today. >>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Mat...@li... >>> <mailto:Mat...@li...> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >>> >> >> >> -- >> _ >> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ >> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >> >> http://www.droettboom.com >> >> > > > -- > _ > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | > > http://www.droettboom.com > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > -- > ************************************ > Chris Beaumont > Graduate Student > Institute for Astronomy > University of Hawaii at Manoa > 2680 Woodlawn Drive > Honolulu, HI 96822 > www.ifa.hawaii.edu/~beaumont <http://www.ifa.hawaii.edu/%7Ebeaumont> > ************************************ -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
127 messages has been excluded from this view by a project administrator.
