matplotlib-devel Mailing List for matplotlib

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