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
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
1
|
2
|
3
|
4
|
5
|
6
(3) |
7
|
8
(2) |
9
|
10
(1) |
11
|
12
|
13
(6) |
14
(11) |
15
(2) |
16
(3) |
17
(3) |
18
(1) |
19
(1) |
20
(1) |
21
(2) |
22
(1) |
23
(1) |
24
(3) |
25
|
26
|
27
(6) |
28
(4) |
29
(5) |
30
|
31
(2) |
|
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 #######################################
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
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 > >
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
The developer hangout is starting in 5 minutes... https://plus.google.com/events/co10krvm0qm1tb8s2jau50t4iq0 -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com
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
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 > >
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
On 01/14/2014 03:43 PM, Cyrille Rossant wrote: >> 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. > +1. It would also be nice to have the possibility to bypass dynamic > data transformations performed by matplotlib. A potential GPU-based > backend would be the most efficient if it was granted the right to > perform all data transformations by itself (for example when panning > and zooming). > In the specific case of data transformations, this is already the case. The backends are sent the raw data + a transformation. This allows file formats to write out untransformed data and have the renderer of that format do the transformation. Unfortunately, all of the backends end up doing the transformation in software anyway, since all of them scale the line width along with the path data, which is never what you want for plotting. (The exception to this is the SVG spec, which now contains a flag for this, but that spec is so new we can't use it because it isn't widely implemented). Mike -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com
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. 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. 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 ************************************
> 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. +1. It would also be nice to have the possibility to bypass dynamic data transformations performed by matplotlib. A potential GPU-based backend would be the most efficient if it was granted the right to perform all data transformations by itself (for example when panning and zooming). Cyrille
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 > >
I'm sure it's obvious, but the backend API was never really designed with this in mind. It was designed for "dumb" things like screens and printers that know about simple primitives like lines and text, but not much else. From that, I don't think it makes much sense to change or even extend that API, as the current targets of the backends are not going to suddenly get any smarter. You also have to remember that the drawing commands that matplotlib emits to a backend are essentially a stream -- they don't have the necessary structure (in all cases) to write out to something like d3. You really want tree traversal, IMHO, not a stream of commands. For a long time, I've felt what is needed is a standard way to navigate over the tree that makes up the figure -- something like a DOM. So you would start at the root (the "figure") and drill down through all of the objects, getting their properties such as location, data and drawing styles and convert into some other format as you go. Your code wouldn't have to care about what coordinate space the data is in -- it would have access to the raw data and any custom transformations the user specified etc., and it could handle accordingly. There's two major pieces that make this hard right now. One is that each class has some arbitrary set of "children", and there's no uniform way to iterate over them. If each Artist had a children method that returns a list of its children, you could write a "Visitor" pattern [1] class over the tree that would let you write out your output format. The second problem, as you point out, is that some things aren't really calculated until draw time. In some cases, we could just be doing more in the constructor. In other cases, we can't calculate the final locations of things until we know things like font size etc., but hopefully those aren't the cases a tool to write d3 would care about. I could also imagine doing drawing in two phases, if necessary, one to just finalize things, and the other to actually write to a "dumb" backend. A d3 converter would only do the first phase, and then iterate over the tree to generate its output. [1] See Python's ast module or docutils for great examples of this pattern. docutils is a particular good analogy because it converts text in one complex logical structure (reStructuredText) to n different other logical structures (including HTML and LaTeX etc.) I hope all of the above makes sense... 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
On 1/14/14, 1:30 PM, Jacob Vanderplas wrote: > 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. A *very* big +1. I'm really excited about doing IPython widgets these days, and this would make a matplotlib IPython widget pretty exciting. Thanks, Jason
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 > >
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
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 > >
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 >
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
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
On 2014年01月13日 9:58 AM, Chris Beaumont 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 . Chris, Thanks for that nice summary. I'm in favor of a mechanism to make it easy to shift to better default styles, while also making it easy for legacy applications to stick with the original as desired. Eric > > 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 >
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
On 2014年01月13日 5:11 AM, Michael Droettboom wrote: > This looks quite good to me. > And to me. If the implementation works out well, this will be a very nice and much needed refactoring. Eric > I'd like some feedback from Thomas Caswell, who's looked at this part of > the code much more than I have lately, but assuming he's ok, you have my > go ahead to start the implementation. > > Cheers, > Mike > > On 01/08/2014 10:55 AM, Federico Ariza wrote: >> Hello everybody. >> >> I just created a new >> MEPhttps://github.com/matplotlib/matplotlib/wiki/Mep22 that is open >> for discussion and destruction. >> >> Background: >> >> In my way to get a MultiFigureManager PR >> https://github.com/matplotlib/matplotlib/pull/2465 we came to the >> conclusion that the work has to be splitted in smaller PRs. >> >> One of the goals of my PR was to "Be able to easily modify the toolbar >> adding and removing toolitems." This mostly breakes the existing >> infrastructure of Toolbar. >> >> Working on a smaller PR https://github.com/matplotlib/matplotlib/pull/2557 >> to address this point, it became clear that a more radical change was >> needed to have a clean interface for "User Interaction tools" >> >> To make it easier to discuss, I created the MEP22 proposing a >> separation of powers (insert political joke here). It is open to all >> kind of modifications so don't be shy. >> >> As reference, there are a couple of previous PRs relating to this >> https://github.com/matplotlib/matplotlib/pull/1849 and >> https://github.com/matplotlib/matplotlib/pull/2557 >> Both of these don't address the problem of reconfiguration >> >> Thank you >> Federico >> > >
I can do Thursday. Tom On Mon, Jan 13, 2014 at 10:36 AM, Michael Droettboom <md...@st...> wrote: > 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 -- Thomas Caswell tca...@gm...
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