SourceForge logo
SourceForge logo
Menu

matplotlib-devel — matplotlib developers

You can subscribe to this list here.

2003 Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
(1)
Nov
(33)
Dec
(20)
2004 Jan
(7)
Feb
(44)
Mar
(51)
Apr
(43)
May
(43)
Jun
(36)
Jul
(61)
Aug
(44)
Sep
(25)
Oct
(82)
Nov
(97)
Dec
(47)
2005 Jan
(77)
Feb
(143)
Mar
(42)
Apr
(31)
May
(93)
Jun
(93)
Jul
(35)
Aug
(78)
Sep
(56)
Oct
(44)
Nov
(72)
Dec
(75)
2006 Jan
(116)
Feb
(99)
Mar
(181)
Apr
(171)
May
(112)
Jun
(86)
Jul
(91)
Aug
(111)
Sep
(77)
Oct
(72)
Nov
(57)
Dec
(51)
2007 Jan
(64)
Feb
(116)
Mar
(70)
Apr
(74)
May
(53)
Jun
(40)
Jul
(519)
Aug
(151)
Sep
(132)
Oct
(74)
Nov
(282)
Dec
(190)
2008 Jan
(141)
Feb
(67)
Mar
(69)
Apr
(96)
May
(227)
Jun
(404)
Jul
(399)
Aug
(96)
Sep
(120)
Oct
(205)
Nov
(126)
Dec
(261)
2009 Jan
(136)
Feb
(136)
Mar
(119)
Apr
(124)
May
(155)
Jun
(98)
Jul
(136)
Aug
(292)
Sep
(174)
Oct
(126)
Nov
(126)
Dec
(79)
2010 Jan
(109)
Feb
(83)
Mar
(139)
Apr
(91)
May
(79)
Jun
(164)
Jul
(184)
Aug
(146)
Sep
(163)
Oct
(128)
Nov
(70)
Dec
(73)
2011 Jan
(235)
Feb
(165)
Mar
(147)
Apr
(86)
May
(74)
Jun
(118)
Jul
(65)
Aug
(75)
Sep
(162)
Oct
(94)
Nov
(48)
Dec
(44)
2012 Jan
(49)
Feb
(40)
Mar
(88)
Apr
(35)
May
(52)
Jun
(69)
Jul
(90)
Aug
(123)
Sep
(112)
Oct
(120)
Nov
(105)
Dec
(116)
2013 Jan
(76)
Feb
(26)
Mar
(78)
Apr
(43)
May
(61)
Jun
(53)
Jul
(147)
Aug
(85)
Sep
(83)
Oct
(122)
Nov
(18)
Dec
(27)
2014 Jan
(58)
Feb
(25)
Mar
(49)
Apr
(17)
May
(29)
Jun
(39)
Jul
(53)
Aug
(52)
Sep
(35)
Oct
(47)
Nov
(110)
Dec
(27)
2015 Jan
(50)
Feb
(93)
Mar
(96)
Apr
(30)
May
(55)
Jun
(83)
Jul
(44)
Aug
(8)
Sep
(5)
Oct
Nov
(1)
Dec
(1)
2016 Jan
Feb
Mar
(1)
Apr
May
Jun
(2)
Jul
Aug
(3)
Sep
(1)
Oct
(3)
Nov
Dec
2017 Jan
Feb
(5)
Mar
Apr
May
Jun
Jul
(3)
Aug
Sep
(7)
Oct
Nov
Dec
2018 Jan
Feb
Mar
Apr
May
Jun
Jul
(2)
Aug
Sep
Oct
Nov
Dec
S M T W T F S
1
(2)
2
(2)
3
(4)
4
(3)
5
6
(3)
7
(1)
8
9
(7)
10
(8)
11
(14)
12
(11)
13
(14)
14
(2)
15
16
(4)
17
(4)
18
(9)
19
(2)
20
21
(2)
22
23
(3)
24
(7)
25
(15)
26
(2)
27
(8)
28
(4)
29
(2)
30
(5)
31
(8)




Showing 2 results of 2

From: Brian G. <ell...@gm...> - 2010年08月29日 19:24:18
On Sat, Aug 28, 2010 at 8:12 PM, Michiel de Hoon <mjl...@ya...> wrote:
> I implemented an event loop in the MacOSX backend and the PyOS_ImportHook event loop in PyGTK, so I've been interested in this topic.
Yes, and you were quite helpful last summer when i was trying to
understand the PyOS_InputHook logic. I appreciated that greatly!
> If I understand guisupport.py correctly, IPython runs the backend-specific event loop. Have you considered to implement an event loop in IPython and to run that instead of a backend-specific event loop? Then you won't have to iterate the event loop, and you can run multiple GUI backends (PyGTK, PyQT, Tkinter, ...) at the same time. The latter may work with the current guisupport.py, but is fragile, because running one of the backend-specific event loops may inadvertently run code from a different backend.
Yes, we do run the native event loops of the GUI toolkit requested.
There are a few reasons we haven't gone the direction you are
mentioning (although it has crossed our minds):
1. We are not *that* passionate about GUI event loops. I would say
our philosophy with event loops is "the simplest solution possible
that is robust."
2. While it might be nice to be able to run multiple event loops, in
most cases users can survive fine without this feature. This is
especially true with more and more people migrating to Qt because of
the license change.
3. We are just barely at the point of getting the new PyOS_InputHook
and two process kernel GUI support working robustly with
matplotlib/traits/mayavi/etc. It is an 2xNxMxP testing nightmare with
2 ways IPython can run the event loop x N toolkits x M projects x P
platforms. Simply installing all possible combinations would probably
take a couple of weeks time, let alone debugging it all. I envy
matlab developers that simple have to test their plotting on a few
platforms. We will be lucky to cover matplotlib/traits/mayavi on just
qt4/wx on Mac/Linux/windows for the 0.11 release.
4. Integrating multiple event loops is either 1) super subtle and
difficult (if you actually start all the event loops involved) or 2)
tends to create solutions that busy poll or consume non-trivial CPU
power. The wx based PyOS_Inputhook and our two process GUI support
are already great examples of this. We have to work pretty hard to
create things that are responsive but that don't consume 100% of the
CPU. To reduce the CPU usage of the wx PyOS_InputHook we actually
dynamically scale back the polling time depending on how often the
user is triggering GUI events.
5. It is not just about integrating GUI event loops. We also have
multiple other event loops in our apps that handle networking.
Cheers,
Brian
> --Michiel.
>
> --- On Sat, 8/28/10, Brian Granger <ell...@gm...> wrote:
>
>> From: Brian Granger <ell...@gm...>
>> Subject: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
>> To: mat...@li..., "IPython Development list" <ipy...@sc...>, ent...@en..., "Evan Patterson" <epa...@en...>
>> Date: Saturday, August 28, 2010, 3:42 PM
>> Hi all,
>>
>> As you may know, this summer we have been working on
>> a new two
>> process IPython that has a beautiful Qt frontend GUI and a
>> ZMQ based
>> messaging layer between that GUI and the new IPython
>> kernel. Many
>> thanks to Enthought for funding this effort!
>>
>> We are currently in the process of adding GUI event loop
>> integration
>> to the ipython kernel so users can do interactive plotting
>> like they
>> can with the regular ipython. You may also remember
>> that last summer
>> we implemented a new PyOs_InputHook based GUI integration
>> for the
>> regular ipython. This has not been released yet, but
>> all of this will
>> be released in the upcoming 0.11 release.
>>
>> I am emailing everyone because we see that there is a need
>> for all of
>> us to agree on two things:
>>
>> 1. How to detect if a GUI application object has been
>> created by someone else.
>> 2. How to detect if a GUI event loop is running.
>>
>> Currently there is code in both ETS and matplotlib that
>> fails to
>> handle these things properly in certain cases. With
>> IPython 0.10,
>> this was not a problem because we used to
>> hijack/monkeypatch the GUI
>> eventloops after we started them. In 0.11, we will no
>> longer be doing
>> that. To address these issues, we have created a
>> standalone module
>> that implements the needed logic:
>>
>> http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py
>>
>> This module is heavily commented and introduces a new
>> informal
>> protocol that all of use can use to detect if event
>> loops are
>> running. This informal protocol is inspired by how
>> some of this is
>> handled inside ETS. Our idea is that all projects
>> will simply copy
>> this module into their code and ship it. It is
>> lightweight and does
>> not depend on IPython or other top-level imports. As
>> you will see, we
>> have implemented the logic for wx and qt4, we will need
>> help with
>> other toolkits. An important point is that matplotlib
>> and ets WILL
>> NOT WORK with the upcoming release of IPython unless
>> changes are made
>> to their respective codebases. We consider this a
>> draft and are more
>> than willing to modify the design or approach as
>> appropriate. One
>> thing that we have not thought about yet is how to continue
>> to support
>> 0.10 within this model.
>>
>> The good news amidst all of this is that the quality and
>> stability of
>> the GUI support in IPython is orders of magnitude better
>> than that in
>> the 0.10 series.
>>
>> Cheers,
>>
>> Brian
>>
>> PS: If you are curious, here is a bit of background
>> on the issues
>> related to the PyOS_Inputhook stuff:
>>
>> http://mail.scipy.org/pipermail/ipython-dev/2010-July/006330.html
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm)
>> Developer Program
>> Be part of this innovative community and reach millions of
>> netbook users
>> worldwide. Take advantage of special opportunities to
>> increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...
From: Michiel de H. <mjl...@ya...> - 2010年08月29日 03:12:39
I implemented an event loop in the MacOSX backend and the PyOS_ImportHook event loop in PyGTK, so I've been interested in this topic.
If I understand guisupport.py correctly, IPython runs the backend-specific event loop. Have you considered to implement an event loop in IPython and to run that instead of a backend-specific event loop? Then you won't have to iterate the event loop, and you can run multiple GUI backends (PyGTK, PyQT, Tkinter, ...) at the same time. The latter may work with the current guisupport.py, but is fragile, because running one of the backend-specific event loops may inadvertently run code from a different backend.
--Michiel.
--- On Sat, 8/28/10, Brian Granger <ell...@gm...> wrote:
> From: Brian Granger <ell...@gm...>
> Subject: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
> To: mat...@li..., "IPython Development list" <ipy...@sc...>, ent...@en..., "Evan Patterson" <epa...@en...>
> Date: Saturday, August 28, 2010, 3:42 PM
> Hi all,
> 
> As you may know, this summer we have been working on
> a new two
> process IPython that has a beautiful Qt frontend GUI and a
> ZMQ based
> messaging layer between that GUI and the new IPython
> kernel. Many
> thanks to Enthought for funding this effort!
> 
> We are currently in the process of adding GUI event loop
> integration
> to the ipython kernel so users can do interactive plotting
> like they
> can with the regular ipython. You may also remember
> that last summer
> we implemented a new PyOs_InputHook based GUI integration
> for the
> regular ipython. This has not been released yet, but
> all of this will
> be released in the upcoming 0.11 release.
> 
> I am emailing everyone because we see that there is a need
> for all of
> us to agree on two things:
> 
> 1. How to detect if a GUI application object has been
> created by someone else.
> 2. How to detect if a GUI event loop is running.
> 
> Currently there is code in both ETS and matplotlib that
> fails to
> handle these things properly in certain cases. With
> IPython 0.10,
> this was not a problem because we used to
> hijack/monkeypatch the GUI
> eventloops after we started them. In 0.11, we will no
> longer be doing
> that. To address these issues, we have created a
> standalone module
> that implements the needed logic:
> 
> http://github.com/ipython/ipython/blob/newkernel/IPython/lib/guisupport.py
> 
> This module is heavily commented and introduces a new
> informal
> protocol that all of use can use to detect if event
> loops are
> running. This informal protocol is inspired by how
> some of this is
> handled inside ETS. Our idea is that all projects
> will simply copy
> this module into their code and ship it. It is
> lightweight and does
> not depend on IPython or other top-level imports. As
> you will see, we
> have implemented the logic for wx and qt4, we will need
> help with
> other toolkits. An important point is that matplotlib
> and ets WILL
> NOT WORK with the upcoming release of IPython unless
> changes are made
> to their respective codebases. We consider this a
> draft and are more
> than willing to modify the design or approach as
> appropriate. One
> thing that we have not thought about yet is how to continue
> to support
> 0.10 within this model.
> 
> The good news amidst all of this is that the quality and
> stability of
> the GUI support in IPython is orders of magnitude better
> than that in
> the 0.10 series.
> 
> Cheers,
> 
> Brian
> 
> PS: If you are curious, here is a bit of background
> on the issues
> related to the PyOS_Inputhook stuff:
> 
> http://mail.scipy.org/pipermail/ipython-dev/2010-July/006330.html
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm)
> Developer Program
> Be part of this innovative community and reach millions of
> netbook users 
> worldwide. Take advantage of special opportunities to
> increase revenue and 
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
 

Showing 2 results of 2

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /