[matplotlib-devel] Interactive wx/pylab with no threads (PyOS_InputHook)
IPython and matplotlib devs,
Over the weekend I have been playing around to see if it is possible
to do interactive GUI work with wx from IPython *without using
threads*. The idea here is to use PyOS_InputHook. Currently, recent
versions of PyQt4 and PyGTK do this and if we can get wx working, we
can probably get rid of IPython's subtle threaded shells that
currently allow interactive GUIs to work.
I am attaching a Cython module that mostly works. Here is a simple
example that works in IPython (without the -wthread option!)
In [1]: import pyximport
In [2]: pyximport.install()
In [3]: import inputhook
In [4]: inputhook.set_input_hook()
In [5]: import wx
In [6]: app = wx.PySimpleApp()
In [7]: app.MainLoop()
In [8]: f = wx.Frame(None,-1,"Look mom, no threads!")
In [9]: f.Show()
Out[9]: True
The docstring of the module also has a matplotlib example. This
really does work and I am pretty sure it will also work in plain
vanilla python as well. There are a few issues to work out:
* When frame are closed by clicking the red button or the "X", the
Windows don't close. In addition, in matplotlib, this causes further
problems.
* In the current matplotlib backend wx.Yield() is called in a way that
is not safe as far as protecting against recursive calls to Yield. I
think it should be called in this way:
app = wx.GetApp()
if app is not None:
app.Yield(True)
* I don't think that interupts work yet, but I haven't tested this
thoroughly yet.
I don't have any more time to work on this right now, but I at least
wanted to share my findings with both IPython and matplotlib devs. It
would be great if someone familiar with wx could try to figure out the
remaining issues. If there are no takers here, I might eventually see
if wxpython itself is interested in this code (that is probably where
it really belongs anyway).
Cheers,
Brian
#include
static PyThreadState *event_tstate = NULL;
static void set_input_hook_c(int (*f)(void))
{
event_tstate = PyThreadState_Get();
PyOS_InputHook = f;
}
static void clear_input_hook_c(void)
{
PyOS_InputHook = NULL;
}
inputhook.pyx
Description: Binary data
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Interactive wx/pylab with no threads (PyOS_InputHook)
Michiel, Thanks for jumping into the discussion. > I wrote the code in PyGTK that uses PyOS_InputHook for interactivity, as well > as the Mac OS X native backend for matplotlib that uses PyOS_InputHook in > exactly the same way. PyQT and Tkinter also use PyOS_InputHook, though the > code is a bit kludgy on Windows. So I definitely agree that PyOS_InputHook is > the right way to go. Great, I was wondering how the Mac OS X backend works - now I know. I will have a look at the code for both PyGTK and OS X. Hopefully that will show me more of the best way of handling this. > Your current code should work, but there's a better way to do it. If I > understand the code correctly, you rely on the fact that PyOS_InputHook is > called repeatedly by readline, and you use PyOS_InputHook to process wx > events that need to be processed at that time. Yes, at least that is my understanding. I put in some debug statements and you could see that it was being called repeatedly. A better way is to use PyOS_InputHook to start the wx event loop, but have this event loop check stdin. As soon as some input is available on stdin, you exit the event loop, which means that PyOS_InputHook returns, and Python can proceed to handle the command that was just entered by the user on stdin. > > Essentially, think of wx's event loop as sitting in a call to select(), > waiting for the next wx event to arrive. You want to add fileno(stdin) to the > set of file descriptors watched by select(). I have seen that this is how the PyQt4 implementation handles it. > There are two advantages to this approach. First, it does not rely on > readline calling PyOS_InputHook repeatedly. This is important, since Python > may not be using readline at all, and if it is, depending on the Python > version and how readline was installed it may call PyOS_InputHook only once. OK, I was wondering about this. But, what happens if PyOS_InputHook is called repeatedly. Are you not then starting the event loop multiple times. Can you say more about what happens in this case? Second, this approach is more efficient (not wasting processor cycles going back and forth between readline and PyOS_InputHook), and gives a better response time (essentially immediate). That would be very nice as my implementation is less responsive. > The best place to put this code is in wxPython. Hopefully (I haven't checked > this), wx exposes enough of the event loop to allow you to have it watch > stdin. This may be an issue, since for example qt4 does not on Windows, which > is why the event loop is kludgy with PyQT on Windows. You could have a look > at the PyOS_InputHook code in PyGTK (you'll need to get the developer's > version of PyGTK, since this code is not yet in an official release). It's > actually quite straightforward and you may be able to modify it directly for > wx. Yes, I fully agree with this. I might end up contacting the wx devs to get their help on this. I actually don't know wx at all, so I am amazed that I got this far. I will have a look at the PyGTK implementation. > It's actually unfortunate that we have to use PyOS_InputHook; all this would > be a lot easier if Python itself supported event loops. Yes, that would be nice!!! Cheers, Brian > --Michiel > > --- On Sun, 2/8/09, Brian Granger wrote: > >> From: Brian Granger >> Subject: [matplotlib-devel] Interactive wx/pylab with no threads >> (PyOS_InputHook) >> To: matplotlib-devel@lists.sourceforge.net, "IPython Development list" >> >> Date: Sunday, February 8, 2009, 7:08 PM >> IPython and matplotlib devs, >> >> Over the weekend I have been playing around to see if it is >> possible >> to do interactive GUI work with wx from IPython *without >> using >> threads*. The idea here is to use PyOS_InputHook. >> Currently, recent >> versions of PyQt4 and PyGTK do this and if we can get wx >> working, we >> can probably get rid of IPython's subtle threaded >> shells that >> currently allow interactive GUIs to work. >> >> I am attaching a Cython module that mostly works. Here is >> a simple >> example that works in IPython (without the -wthread >> option!) >> >> In [1]: import pyximport >> >> In [2]: pyximport.install() >> >> In [3]: import inputhook >> >> In [4]: inputhook.set_input_hook() >> >> In [5]: import wx >> >> In [6]: app = wx.PySimpleApp() >> >> In [7]: app.MainLoop() >> >> In [8]: f = wx.Frame(None,-1,"Look mom, no >> threads!") >> >> In [9]: f.Show() >> Out[9]: True >> >> The docstring of the module also has a matplotlib example.
[matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."
Hello all, [sent to mpl-dev, enthought-dev and ipython-dev] This summer, we are doing some major refactoring of IPython's core. One of the things I am working on is changing how IPython's works with GUI toolkits. These changes will have a significant impact (hopefully for the better) on your project, so I wanted to open a discussion about this issue. Here is the current situation: currently, IPython uses threads to allow GUI event loops. This code lives in IPython.Shell and is extremely subtle, hard to maintain and fragile. Fernando and John Hunter have done a fantastic job in developing this code, but in the long run we need a more robust approach. Here is the proposal: Python has an obscure hook called PyOS_InputHook. By using this hook, GUI toolkits can interleave their event loop with a command line program *without threads*. Even though PyOS_InputHook is not well known, this is how Python's built-in integration with Tk works. The good news is that other GUI toolkits are starting to support PyOS_InputHook: * PyGTK 2.15.1 has this. * The mpl MacOSX backend works this way * Recent versions of PyQT 4 have this. * I am working with Robin Dunn to implement this in wxPython 2.8 and 2.9 Bottom line: once people are using these recent/upcoming versions of the GUI toolkits, IPython will no longer need to maintain the code in Shell.py and IPython won't need to have -pylab/-wthread/etc options. So, how does affect your project? * People will be able to use your project interactive from the regular python prompt. * You will need to make small changes to your GUI toolkits initialization code. * All of us will need to coordinate version transitions to make sure that there is a clean transition to this new approach. * I need help testing the new approach (especially with wxPython) to make sure that your project actually works with the new approach. What needs to be done at this point? * I would like to discuss how the transition should be made in terms of versions. * I need help testing this new approach in the various toolkits - especially with wx. * I want to see if there are other issues related to this that I am missing. Cheers, Brian -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."
On Thu, Jul 16, 2009 at 10:20 AM, Gael Varoquaux < gael.varoqu...@normalesup.org> wrote: > On Thu, Jul 16, 2009 at 10:04:33AM -0700, Brian Granger wrote: > >So, how does affect your project? > > >* People will be able to use your project interactive from the regular > >python prompt. > >* You will need to make small changes to your GUI toolkits > initialization > >code. > >* All of us will need to coordinate version transitions to make sure > that > >there is a clean transition to this new approach. > >* I need help testing the new approach (especially with wxPython) to > make > >sure that your project actually works with the new approach. > > Would it be possible for IPython to expose both solutions for a while > (say 6 month to a year), so that we all have time to adapt? > Yes and no. In the short term, this is definitely possible. Also, as Ville mentions, the new approach will also work with *any* older version of IPython. However, one of the main things that needs to be refactored in IPython is the threading model. This is needed for a variety of reasons, but the bottom line is this - a number of projects are using IPython as if it were thread safe (including IPython itself) - but it is not. When I fix these things (which will be soon), I am not sure (I am doubtful) that the threaded Shell.py code will continue to work. But, this is something that I can look into. But, at some point, we will have to say "if you want the old threaded shells, you will have to use an older version of IPython". We just have to figure out what the transition looks like. Cheers, Brian > Gaël > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."
Good question Gael, > So, ... I am dumb, and I haven't been following things well enough (not > enough time). Concretely, what do I need to do to be able to launch > IPython, and pop up a wx dialog not blocking IPython with the new > technology? > If you have a patched version of wx (that Robin and I are working on) you just do the following (from either ipython or python!): >>> import wx >>> app = wx.IApp(clearSigInt=False) # for interactive app then you are off to the races (you don't even need to start the mainloop) With current versions of mpl, you can do: >>> import wx >>> app = wx.IApp(clearSigInt=False) >>> from matplotlib import pyplot as plt >>> plt.interactive(True) the everything just works... Obviously, the creation of the IApp object should be put into the GUI toolkit initialization code in mpl/mayavi/etc. I will work with Robin to get a version of wx posted that has the patched applied so people can begin to test this. Cheers, Brian -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."
This is a great project and I'm sure we're all looking forward to having > "just one way to do it". > > However, do not overestimate how up-to-date these packages will be, > particularly in managed environments. For instance the RHEL4 boxes we run > at my employer still have pygtk 2.4. (Yes, that is 4 years old!) It would > be unfortunate if our users couldn't update matplotlib without the pain of > recompiling a large part of the gtk stack underneath. > I am fully aware that some environments upgrade things like GUI toolkits over very long time scales. More important - there isn't a released version of wx that has these capabilities in it. It will be a long time before everyone is running the needed versions of wx/gtk/qt. In the meantime, we will do everything we can to make sure that people running older versions of GUI toolkits can continue to use IPython (and mpl). On the mpl side of things, there will probably have to be some changes to the GUI toolkit initialization code that detects which way things are being run (old/new) and then does the right thing. If we coordinate this well, that should allow newer versions of mpl to work with both new and old versions of IPython and the GUI toolkits. However *at some point*, we will have to make a clean break. > So just a plea to keep the old code paths working -- perhaps surrounded in > big flashing "REMOVE ME LATER" comments. I understand that maintaining code > that fewer and fewer users will be running is like a time bomb. This is especially true of the threaded Shells in IPython. Honestly, even with thousands of people using it (as is currently the case) it is a time bomb. > Maybe we could raise a deprecation warning if a user has an old version of > a toolkit, so at least when the bomb finally goes off the user has a first > guess as to why. But I think dropping all support for these older versions > in one step would be a mistake. > Yes, there will definitely have to be some sort of transition. One possibility is that during the transition, the old threaded Shells would slowly loose features that become impossible to maintain (such as interrupt handling in the threaded shells). With our very limited IPython manpower, we have a very fine line to walk between moving forward and maintaining backwards compatibility. Cheers, Brian > Cheers, > Mike > > Brian Granger wrote: > >> Hello all, >> >> [sent to mpl-dev, enthought-dev and ipython-dev] >> >> This summer, we are doing some major refactoring of IPython's core. One >> of the things I am working on is changing how IPython's works with GUI >> toolkits. These changes will have a significant impact (hopefully for the >> better) on your project, so I wanted to open a discussion about this issue. >> >> Here is the current situation: currently, IPython uses threads to allow >> GUI event loops. This code lives in IPython.Shell and is extremely subtle, >> hard to maintain and fragile. Fernando and John Hunter have done a >> fantastic job in developing this code, but in the long run we need a more >> robust approach. >> >> Here is the proposal: Python has an obscure hook called PyOS_InputHook. >> By using this hook, GUI toolkits can interleave their event loop with a >> command line program *without threads*. Even though PyOS_InputHook is not >> well known, this is how Python's built-in integration with Tk works. The >> good news is that other GUI toolkits are starting to support PyOS_InputHook: >> >> * PyGTK 2.15.1 has this. >> * The mpl MacOSX backend works this way >> * Recent versions of PyQT 4 have this. >> * I am working with Robin Dunn to implement this in wxPython 2.8 and 2.9 >> >> Bottom line: once people are using these recent/upcoming versions of the >> GUI toolkits, IPython will no longer need to maintain the code in Shell.py >> and IPython won't need to have -pylab/-wthread/etc options. >> So, how does affect your project? >> >> * People will be able to use your project interactive from the regular >> python prompt. >> * You will need to make small changes to your GUI toolkits initialization >> code. >> * All of us will need to coordinate version transitions to make sure that >> there is a clean transition to this new approach. >> * I need help testing the new approach (especially with wxPython) to make >> sure that your project actually works with the new approach. >> >> What needs to be done at this point? >> >> * I would like to discuss how the transition should be made in terms of >> versions. >> * I need help testing this new approach in the various toolkits - >>
Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."
> OK, that's great. It enlightens me. So, it seems you guys are on the > right track. I'll just wait for the new versions of wx to come out. You > are doing great work on that. > Thanks. > One piece of warning: Wx has a terrible upgrade path. Upgrading it breaks > stuff. As a consequence, people don't upgrade it often, and my experience > is that we have to maintain compatibility with old version for years (at > least 3 years: in Ubuntu, latest release, installing SPE drags along > wxPython 2.6, and thus people find themselves importing this version > without realizing it). > This is good to know. Cheers, Brian > > Gaël > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."
Yes, this is also a possibility that we need to pursue as it would greatly help the transition. I do have a Cython prototype that works. But, we are currently testing all of this on wx trunk. I am not sure if what we are doing will work on previous versions. I plan on looking into this. Cheers, Brian On Thu, Jul 16, 2009 at 11:11 AM, Ville M. Vainio wrote: > On Thu, Jul 16, 2009 at 9:06 PM, Brian Granger > wrote: > > > I am fully aware that some environments upgrade things like GUI toolkits > > over very long time scales. More important - there isn't a released > version > > of wx that has these capabilities in it. It will be a long time before > > I thought you were able to make wx work with a cython-based > PyOS_InputHook extension. Possibly a C-based extension could fix this > issue for users of old wx versions? > > -- > Ville M. Vainio > http://tinyurl.com/vainio > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."
I tried ctypes first, but with no luck. Here is what I tried: >>> import readline >>> import ctypes >>> ctypes.pythonapi.PyOS_InputHook <_FuncPtr object at 0x76420> >>> def my_callback(): ... print "In am here" ... return 0 ... >>> cbf = ctypes.CFUNCTYPE(ctypes.c_int)(my_callback) >>> cbf >>> ctypes.pythonapi.PyOS_InputHook = cbf Do you see anything wrong with this? I should probably try it again to see if I can make it work though. Cheers, Brian On Thu, Jul 16, 2009 at 11:35 AM, Robert Kern wrote: > On 2009-07-16 13:11, Ville M. Vainio wrote: > > On Thu, Jul 16, 2009 at 9:06 PM, Brian Granger > wrote: > > > >> I am fully aware that some environments upgrade things like GUI toolkits > >> over very long time scales. More important - there isn't a released > version > >> of wx that has these capabilities in it. It will be a long time before > > > > I thought you were able to make wx work with a cython-based > > PyOS_InputHook extension. Possibly a C-based extension could fix this > > issue for users of old wx versions? > > Or even just a bit of ctypes? > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma > that is made terrible by our own mad attempt to interpret it as though it > had > an underlying truth." > -- Umberto Eco > > ___ > IPython-dev mailing list > ipython-...@scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."
OK, I just found this thread that shows how to set PyOS_InputHook from ctypes: http://osdir.com/ml/python.ctypes/2006-12/msg00045.html I tried it and it works fine. This will simplify the transition a lot. I will develop some pure ctypes prototypes for the various toolkits and then folks can begin to try this out. Cheers, Brian On Thu, Jul 16, 2009 at 12:13 PM, Brian Granger wrote: > I tried ctypes first, but with no luck. Here is what I tried: > > >>> import readline > >>> import ctypes > >>> ctypes.pythonapi.PyOS_InputHook > <_FuncPtr object at 0x76420> > >>> def my_callback(): > ... print "In am here" > ... return 0 > ... > >>> cbf = ctypes.CFUNCTYPE(ctypes.c_int)(my_callback) > >>> cbf > > >>> ctypes.pythonapi.PyOS_InputHook = cbf > > Do you see anything wrong with this? > > I should probably try it again to see if I can make it work though. > > Cheers, > > Brian > > > On Thu, Jul 16, 2009 at 11:35 AM, Robert Kern wrote: > >> On 2009-07-16 13:11, Ville M. Vainio wrote: >> > On Thu, Jul 16, 2009 at 9:06 PM, Brian Granger >> wrote: >> > >> >> I am fully aware that some environments upgrade things like GUI >> toolkits >> >> over very long time scales. More important - there isn't a released >> version >> >> of wx that has these capabilities in it. It will be a long time before >> > >> > I thought you were able to make wx work with a cython-based >> > PyOS_InputHook extension. Possibly a C-based extension could fix this >> > issue for users of old wx versions? >> >> Or even just a bit of ctypes? >> >> -- >> Robert Kern >> >> "I have come to believe that the whole world is an enigma, a harmless >> enigma >> that is made terrible by our own mad attempt to interpret it as though it >> had >> an underlying truth." >> -- Umberto Eco >> >> ___ >> IPython-dev mailing list >> ipython-...@scipy.org >> http://mail.scipy.org/mailman/listinfo/ipython-dev >> > > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."
After playing a bit more, I have a ctypes based prototype that can set PyOS_InputHook in an appropriate way for wx 2.9 (trunk). I think it is possible to have a ctypes based version that would work for all the major GUI toolkits that we could ship with IPython until the transition is over (i.e., everyone is using a GUI toolkits recent enough). BUT. I need to begin to narrow the GUI toolkits and versions that we will support. The total number of possibilities (for testing, etc.) is approximately: (number of OSs~3) x (number of GUI toolkits~qt4/wx/gtk) x (number of supported versions of each GUI) Because the first 2 terms are pretty fixed, I want to bring sanity to the picture by keeping the 3rd term as small as possible. So, here is a question. What versions of what GUI toolkits do we realistically need to support moving forward (today and beyond)? By this, I mean that: "unsupported" = older versions of GUIs toolkits that will have to use older versions of IPython. "supported" = versions of GUIS that will be able to use the PyOS_InputHook approach in newer releases of IPython. Cheers, Brian -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] IPython proposal: getting rid of "ipython -pylab\-wthread\etc."
> For Wx, we would obviously need to support 2.8. We can toy with the idea > of not supporting 2.6, I believe. A lot of people are starting to feel > that 2.6 is depreciated. > Yes, 2.8 is latest stable, so we should support it. How many people would complain if 2.6 were not supported? I take it that all of ETS is 2.8 based? Cheers, Brian > > Gaël > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
Hi, I am attaching a working ctypes based prototype of a module that allows wx to be used interactively from *both* python and ipython. It uses PyOS_InputHook and has been tested on wx 2.8 and 2.9 (trunk) on Mac OS X (python 2.5). It can be used with an existing wx install and all versions of ipython, but ***don't use the -pylab or -wthread flag***. At this point, I need help testing the heck out of this (window and linux users esp). I have run most matplotlib pylab_examples and they work fine. I also need people to try out things like ETS/Mayavi. The current plan is to replace the existing threaded shells in IPython with this (much simpler) code. Cheers, Brian inputhook.py Description: Binary data -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
Robert, Thanks for testing this so quickly. Performance is one of the big issues that I am concerned about. I will work on a Cython based version to see if that solves the problem. Cheers, Brian > Works for me with wx 2.8.8.1 on OS X 10.5 and Chaco. Pan and zoom > interactions are substantially chunky, though. I do not see such > chunkiness with -wthread. It would be worth exploring a Cython > alternative to see if it is just ctypes and general Python overhead to > blame. > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma that is made terrible by our own mad attempt to interpret it as > though it had an underlying truth." > -- Umberto Eco > ___ > IPython-dev mailing list > ipython-...@scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
Michiel, Thanks for the reply, this will help us to find a better approach. According to one of the wx devs, Robin Dunn, wx currently does not have the ability to monitor stdin in its even loop without polling. I guess there is a GSoC project to add this capability, but it is not there yet. Any thoughts on how this could be done without monitoring stdin. I will give the polling stdin approach a try though. Cheers, Brian > The chunkiness probably comes from the fact that inputhook_wx is called > repeatedly. This is different from how PyOS_InputHook is being used in > Tkinter, PyGTK, and the Mac OS X backend. > > Schematically, this is how the Tkinter/PyGTK/MacOSX event loops work: > > 1) PyOS_InputHook is called when Python is waiting for the user to type in > the next Python command. > > 2) The hook function sets up the event loop such that stdin is being > monitored while the event loop is running. > > 3) The hook function then starts the event loop. > > 4) When input is available on stdin, the hook function exits the event > loop, and returns. > > This is how the proposed Wx event loop currently works: > > 1) PyOS_InputHook is called when Python is waiting for the user to type in > the next Python command. > > 2) The hook function processes whatever events are available at the time. > > 3) The hook function returns. > > 4) If still no input is available on stdin, Python calls the hook function > again via PyOS_InputHook after a timeout. > > I believe the timeout is 0.1 seconds by default. However, Python may not > call PyOS_InputHook repeatedly at all; this depends on which Python version > is being used, and the version of the readline library. In some > configurations (particularly on Windows), PyOS_InputHook is called only > once, so wx will freeze between Python commands. > > I am not familiar with wx, but there hopefully there is some way to monitor > stdin while the event loop is running? > > --Michiel. > > > --- On Thu, 7/16/09, Brian Granger wrote: > > > From: Brian Granger > > Subject: Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes > based prototype of PyOS_InputHook for wx 2.8 and 2.9 > > To: "Robert Kern" > > Cc: enthought-...@enthought.com, "matplotlib development list" < > matplotlib-devel@lists.sourceforge.net>, "IPython Development list" < > ipython-...@scipy.org> > > Date: Thursday, July 16, 2009, 6:57 PM > > Robert, > > > > Thanks for testing this so quickly. Performance is one of > > the big issues that I am concerned about. I will work on a > > Cython based version to see if that solves the problem. > > > > Cheers, > > > > Brian > > > > > > > > > > Works for me with wx 2.8.8.1 on OS X 10.5 and > > Chaco. Pan and zoom > > > > interactions are substantially chunky, though. I do not see > > such > > > > chunkiness with -wthread. It would be worth exploring a > > Cython > > > > alternative to see if it is just ctypes and general Python > > overhead to > > > > blame. > > > > > > > > -- > > > > Robert Kern > > > > > > > > "I have come to believe that the whole world is an > > enigma, a harmless > > > > enigma that is made terrible by our own mad attempt to > > interpret it as > > > > though it had an underlying truth." > > > > -- Umberto Eco > > > > ___ > > > > IPython-dev mailing list > > > > ipython-...@scipy.org > > > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > > > > > > > > -Inline Attachment Follows- > > > > > -- > > Enter the BlackBerry Developer Challenge > > This is your chance to win up to $100,000 in prizes! For a > > limited time, > > vendors submitting new applications to BlackBerry App > > World(TM) will have > > the opportunity to enter the BlackBerry Developer > > Challenge. See full prize > > details at: http://p.sf.net/sfu/Challenge > > -Inline Attachment Follows- > > > > ___ > > Matplotlib-devel mailing list > > Matplotlib-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
Michiel, Thanks for the ideas. I have implemented both of the approaches you describe and I am attaching a file that has all 3 approaches. At this point, all 3 approaches work on OS X, Python 2.5 with wx 2.8/2.9. What I most need to to find strenuous test cases that can probe which of these has the best performance? Robert, could you run the Chaco test again with approaches 2 and 3 and try tuning the parameters (see the docstrings)? Cheers, Brian On Thu, Jul 16, 2009 at 11:32 PM, Michiel de Hoon wrote: > > Without monitoring stdin, you could do the following: > > while True: >run the event loop for a specified duration (say, 0.1 seconds) >check for input on stdin; if there is any: break > > But you can only do this if wx has such a time-out capability. If not, you > can do the following: > > while True: >handle all accumulated events >check for input on stdin; if there is any: break >sleep for 0.1 seconds > > The sleep is important, otherwise the CPU is busy 100% of the time, which > will drain your battery. > > This loop is essentially what you are doing in your current code, except > that you're using Python/readline for the repeated calls into the hook > function. It's better to have this loop explicitly inside your hook > function, because of the variation in PyOS_InputHook behavior between > different versions of Python/readline. > > --Michiel > > --- On Fri, 7/17/09, Brian Granger wrote: > > > From: Brian Granger > > Subject: Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes > based prototype of PyOS_InputHook for wx 2.8 and 2.9 > > To: "Michiel de Hoon" > > Cc: "Robert Kern" , enthought-...@enthought.com, > "matplotlib development list" , > "IPython Development list" > > Date: Friday, July 17, 2009, 12:59 AM > > Michiel, > > > > Thanks for the reply, this will help us to find a better > > approach. According to one of the wx devs, Robin Dunn, wx > > currently does not have the ability to monitor stdin in its > > even loop without polling. I guess there is a GSoC project > > to add this capability, but it is not there yet. Any > > thoughts on how this could be done without monitoring > > stdin. I will give the polling stdin approach a try > > though. > > > > > > Cheers, > > > > Brian > > > > > > > > > > The chunkiness probably comes from the fact that > > inputhook_wx is called repeatedly. This is different from > > how PyOS_InputHook is being used in Tkinter, PyGTK, and the > > Mac OS X backend. > > > > > > > > Schematically, this is how the Tkinter/PyGTK/MacOSX event > > loops work: > > > > > > > > 1) PyOS_InputHook is called when Python is waiting for the > > user to type in the next Python command. > > > > > > > > 2) The hook function sets up the event loop such that stdin > > is being monitored while the event loop is running. > > > > > > > > 3) The hook function then starts the event loop. > > > > > > > > 4) When input is available on stdin, the hook function > > exits the event loop, and returns. > > > > > > > > This is how the proposed Wx event loop currently works: > > > > > > > > 1) PyOS_InputHook is called when Python is waiting for the > > user to type in the next Python command. > > > > > > > > 2) The hook function processes whatever events are > > available at the time. > > > > > > > > 3) The hook function returns. > > > > > > > > 4) If still no input is available on stdin, Python calls > > the hook function again via PyOS_InputHook after a timeout. > > > > > > > > I believe the timeout is 0.1 seconds by default. However, > > Python may not call PyOS_InputHook repeatedly at all; this > > depends on which Python version is being used, and the > > version of the readline library. In some configurations > > (particularly on Windows), PyOS_InputHook is called only > > once, so wx will freeze between Python commands. > > > > > > > > > > I am not familiar with wx, but there hopefully there is > > some way to monitor stdin while the event loop is running? > > > > > > > > --Michiel. > > > > > > > > > > > > --- On Thu, 7/16/09, Brian Granger wrote: > > > > > > > > > From: Brian Granger > > > > > Subject: Re: [matplotlib-devel] [IPython-dev] > > [Enth
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
Ondrej and Robert, Thanks for testing this. Some comments: 2) We can speed up pasting and general keyboard response by changing the polling time. Pasting is slow very slow at the original setting of 50. But if you make it smaller pasting becomes faster (although still not instant). 3) We can speed up the GUI response by decreasing the time.sleep interval. The setting of 0.01 works pretty well. Why not decrease the polling or sleep times even further? As you descrease either of these times, the idle CPU load starts to go up. Here is what I observe on my MacBook pro (both 2 and 3 show the same result): polling/sleep time of 1 (ms) gives about 13% CPU load polling/sleep time of 5 (ms) gives about 3% CPU load polling/sleep time of 10 (ms) gives about 1.5% CPU load In summary, method 3 with a time of 10 ms seems like the best overall approach. However, I am going to leave in the other methods and make it easy to set the time intervals. That way, if people want to optimize their performance for particular usage cases they can. Now, onto testing for Windows. Can anyone help with that? Thanks, Brian On Fri, Jul 17, 2009 at 1:13 PM, Ondrej Certik wrote: > On Fri, Jul 17, 2009 at 2:07 PM, Ondrej Certik wrote: > > On Fri, Jul 17, 2009 at 1:57 PM, Robert Kern wrote: > >> On Fri, Jul 17, 2009 at 14:48, Brian Granger > wrote: > >>> Michiel, > >>> > >>> Thanks for the ideas. I have implemented both of the approaches you > >>> describe and I am attaching a file that has all 3 approaches. At this > >>> point, all 3 approaches work on OS X, Python 2.5 with wx 2.8/2.9. What > I > >>> most need to to find strenuous test cases that can probe which of these > has > >>> the best performance? Robert, could you run the Chaco test again with > >>> approaches 2 and 3 and try tuning the parameters (see the docstrings)? > >> > >> #2 was pretty good out-of-box. #3 was slightly better than #1 but > >> still noticeably chunky. Reducing the sleep down to 0.01 instead of > >> 0.05 made things appreciably smooth. I thought I noticed a tiny bit of > >> chunkiness, but I certainly didn't do a double-blind trial. > > > > Exactly the same observation on Linux. E.g. #1 the slowest, #3 quite > > good, #2 perfect. However: > > > > with #2, if I did copy and paste of some command into the python > > terminal, I could see how ipython was putting the command letter by > > letter on the prompt, e.g. by pasting "inputhook.remove_inputhook()" I > > could literally see: > > > > i > > in > > inp > > inpu > > ... > > > > (everything on one line, e.g. like if there was sleep(0.05) between each > letter) > > > > with #1 and #3, pasting was immediate. > > so I also reduced the sleep in #3 from 0.05 to 0.01 and then #3 is > absolutely smooth for me and also pasting to ipython is immediate e.g. > this looks like a perfect solution to me. > > Ondrej > ___ > IPython-dev mailing list > ipython-...@scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-Dev] [IPython-dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
Gael, Polling at 100Hz is a horrendous solution from a technical point of view. > I typical have a dozen IPython instances opened, where I have been > working a while ago, but not doing anything right now, because I am > planning to come back to it. Having these all poll at a 100Hz wil keep my > laptop hot, make it switch context all the time, and drain the battery. > Adobe Flash works that way. I use it as seldom as possible. > I agree that polling is a non-optimal approach. But, until wx supports monitoring stdin from within the event loop, we are stuck with polling. Because of usage cases like yours, I think it is important that users be able to tune these things. For example, slower polling intervals work just fine for many things (like basic matplotlib plots) and have essentially 0 load of the CPU. It also depends on what type of compromises you are wlling to make. If you don't mind slightly slower keyboard response, but you want super fast GUI responses, then approach 2 will work great. Likewise, if you don't mind slow GUI response, but want fast keyboard, then approach 3 is best. Bottom line = we are into a position of compromise because of wx. The good news is that I think we can offer users a very flexible way of tuning all these things. > > One trick I play sometimes when I am developping software that needs to > poll and cannot be event-driven, is to unable polling when there is > activity, but turn it off when there is None. I am not sure how you can > adapt the idea here, though. > I will think about this. Cheers, Brian > > Gaël > ___ > Enthought-Dev mailing list > enthought-...@enthought.com > https://mail.enthought.com/mailman/listinfo/enthought-dev > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
Can you describe the patch you are putting together for wxPython? or > is it wxWidgets? Perhaps there is a way for us to monkeypatch the same > approach into old versions. > There is *very* little difference between my ctypes prototype and the patch for wxPython. The only real differences are these: * A few lines of C code that sets PyOS_InputHook and handles threading * A wx.App subclass called IApp that turns on the capability and has the implementation of the inputhook. We could definitely monkey patch wx with this IApp class. Cheers, Brian > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma that is made terrible by our own mad attempt to interpret it as > though it had an underlying truth." > -- Umberto Eco > ___ > IPython-dev mailing list > ipython-...@scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] [Enthought-Dev] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
The current patch for wxpython is based on approach 1, but that is obviously going to change after what we are seeing performance wise. Once I have a ctypes version that is really well tested (also on Win32 and Linux) I will help create a patch for wx that implements that approach. Cheers, Brian On Fri, Jul 17, 2009 at 3:40 PM, Robert Kern wrote: > On Fri, Jul 17, 2009 at 17:31, Brian Granger > wrote: > > > > > >> Can you describe the patch you are putting together for wxPython? or > >> is it wxWidgets? Perhaps there is a way for us to monkeypatch the same > >> approach into old versions. > > > > There is *very* little difference between my ctypes prototype and the > patch > > for wxPython. > > Which approach? #1? > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless > enigma that is made terrible by our own mad attempt to interpret it as > though it had an underlying truth." > -- Umberto Eco > ___ > IPython-dev mailing list > ipython-...@scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Ctypes based prototype of PyOS_InputHook for wx 2.8 and 2.9
All, I have an improved prototype of my ctypes based inputhook for wx. In this version I have: * Added and tested Ondrej's patch. It seems to improve both responsiveness and idle GPU load. Thanks Ondrej! * Tested on Win32 * Small changes related to the GIL. Robert and Gael, can you test this version (with approach 3) to see if it is satisfactory in terms of performance AND idle CPU load. On my system MacBook Pro, the idle load is now below 1%. Cheers and thanks, Brian inputhook.py Description: Binary data -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] New spines capabilities question
Hi, Congrats on the latest matplotlib release. Looks like there are some *really* impressive new things in there. I was just looking at the spines docs: http://matplotlib.sourceforge.net/examples/pylab_examples/spine_placement_demo.html And I noticed that on spines that are range limited (to the data) in the y direction, the blueish line of the graph is actually cut off near the limit. It is not obvious, but one you see it, you notice it in all the examples (look at the peaks and troughs of the sin curve). Is this a known issue or can this be prevented? Cheers, Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] New spines capabilities question
> I think this happens in all mpl graphs, you just don't see it. The > axis limits are set to -2..2, and the sine is draw from -2..2. The > linewidth extends beyond 2, so it is clipped by the axes clipping to > the bounding rectangle. Normally you don't see this, because visually > it is under the surrounding axes black edge. Yes, I saw that it looks like it happens under the axes clipping. > You can either set the > ylimits wider: > ax.set_ylim(-2.1, 2.1) > But would this also make the spine have the larger limits? Basically, I want know if the spines can be used to create Tufte-style range-frames. Am I correct in thinking that these spines provide that? Or is there another way to get a range-frame? > or turn clipping off > > ax.plot(x,y, clip_on=False) > This looks hopeful and I will give it a shot. Cheers, Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] IPython (likely) dropping Python 2.4 support
Hello all, While at SciPy this year, the IPython devs began discussing dropping Python 2.4 support. Or rational is this: * New generator features in 2.5 would dramatically simplify our testing of our Twisted using components. * Being able to use absolute imports would simplify the packaging of some external deps. * The faster we get rid of 2.4 and 2.5 support (we are not getting rid of 2.5 yet) the faster we can transition to py3k. But, this would mean that pylab mode for matplotlib would require either: * Using IPython v 0.10 or below * Using Python 2.5/2.6 We know that there are people still using Python 2.4, but at this point, we feel the benefits outweight the costs. How do the matplotlib devs feel about this? As a side note, as of IPython 0.11, the IPython threaded shells (pylab stuff) will be completely refactored. This will require matplotlib to make some moderate changes to support the new interface. Thus, even if we don't drop 2.4 support, matplotlib will have to decide how to handle the IPython 0.10->0.11 transition. Cheers, Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] New GUI integration in IPython
Hello all, This email is being sent out to to the lists of users+devs who regularly use IPython's "pylab" mode or "-wthread", "-qthread", "-gthread", etc. threaded shells. As of today, in IPython's trunk, we have a completely new implementation of our GUI event loop integration that dramatically improves the stability of using the TERMINAL BASED IPython with GUI applications. This does not affect attempts to embed IPython into GUI applications. At this point, we need developers to begin to try out the new stuff and adapt their projects to use the new capabilities. Here are some things you will get: * Stability and robustness have been improved greatly. * KeyboardInterrupts should work on all platforms reliably. * No more command line flags - instead everything can be activated/de-activated/switched at runtime. This should allow projects like matplotlib to enable reliable backend switching. See the new %gui magic for more information on this. * We have a new developer module for working with these features (IPython.lib.inputhook). * Unless someone complains very loudly *and* steps up to the plate to maintain them, the old threaded shells will be removed in the next release of IPython. Here are some starting points for documentation on the new features: http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/docs/source/interactive/reference.txt#L1375 http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/lib/inputhook.py http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/core/magic.py#L3542 Please let us know if you have questions - we are more than willing to help you get started with all of this. Cheers, Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] Testing matplotlib on IPython trunk
You also may need to do:
plt.interactive(True)
Cheers,
Brian
On Tue, Sep 8, 2009 at 12:45 PM, Gökhan Sever wrote:
> Hello,
>
> The thread switches will be gone by the release of the new IPython. I am
> assuming that some extra work needs to be done on both sides in preparation
> to the new release. See the following test cases:
>
>
> ### This one locks the IPython unless the figure window is killed. If you
> do an additional plt.show() without a figure is up then you get a complete
> lock-up of the shell.
>
> I[1]: import matplotlib.pyplot as plt
>
> I[2]: %gui qt
>
> I[3]: plt.plot(range(10))
> O[3]: []
>
> I[4]: plt.show()
>
>
>
>
> ### The following cannot resolve that issue
>
> I[5]: %gui #disable event loops
>
> I[6]: %gui -a qt
> O[6]:
>
> I[7]: plt.plot(range(10))
> O[7]: []
>
> I[8]: plt.show()
>
>
>
> ### In a new IPython, these lines work --no locking after plt.show() "-a"
> makes the difference.
>
> I[1]: import matplotlib.pyplot as plt
>
> I[2]: %gui -a qt
> O[2]:
>
> I[3]: plt.plot(range(10))
> O[3]: []
>
> I[4]: plt.show()
>
>
>
>
>
> Platform :
> Linux-2.6.29.6-217.2.3.fc11.i686.PAE-i686-with-fedora-11-Leonidas
> Python : ('CPython', 'tags/r26', '66714')
> IPython : 0.11.bzr.r1205
> NumPy : 1.4.0.dev
> Matplotlib : 1.0.svn
>
>
>
> --
> Gökhan
>
> ___
> IPython-dev mailing list
> ipython-...@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] preparing for 0.99.1
Thinking about 1.0 Has anyone looked at the new gui integration stuff in the IPython trunk? Cheers, Brian On Thu, Sep 10, 2009 at 6:08 PM, John Hunter wrote: > We've had a significant number of bug-fixes in the release branch, so > this weekend I'm going to try and put out a release candidate for > 0.99.1, and perhaps this will be the last release of this branch but > time will tell. I'll build the tarball and OSX binaries for the > release candidate, and perhaps Christoph can build the win32 binaries > for testing. If all goes well we can proceed with the release later > next week. > > So please take some time to work though bugs and patches on the sf > site -- if 0.99.1 is stable enough, we can live with that until we get > the 1.0 trunk out with the new docstrings, testing, etc... > > http://sourceforge.net/tracker/?group_id=80706&atid=560720 > http://sourceforge.net/tracker/?group_id=80706&atid=560722 > > JDH > > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] SciPy 2010 Tutorials: brainstorming and call for proposals
Greetings everyone, This year, there will be two days of tutorials (June 28th and 29th) before the main SciPy 2010 conference. Each of the two tutorial tracks (intro, advanced) will have a 3-4 hour morning and afternoon session both days, for a total of 4 intro sessions and 4 advanced sessions. The main tutorial web page for SciPy 2010 is here: http://conference.scipy.org/scipy2010/tutorials.html We are currently in the process of planning the tutorial sessions. You can help us in two ways: Brainstorm/vote on potential tutorial topics To help us plan the tutorials, we have setup a web site that allow everyone in the community to brainstorm and vote on tutorial ideas/topics. The website for brainstorming/voting is here: http://conference.scipy.org/scipy2010/tutorialsUV.html The tutorial committee will use this information to help select the tutorials. Please jump in and let us know what tutorial topics you would like to see. Tutorial proposal submissions = We are now accepting tutorial proposals from individuals or teams that would like to present a tutorial. Tutorials should be focused on covering a well defined topic in a hands on manner. We want to see tutorial attendees coding! We are pleased to offer tutorial presenters stipends this year for the first time: * 1 Session: $1,000 (half day) * 2 Sessions: $1,500 (full day) Optionally, part of this stipend can be applied to the presenter's registration costs. To submit a tutorial proposal please submit the following materials to 2010tutori...@scipy.org by April 15: * A short bio of the presenter or team members. * Which track the tutorial would be in (intro or advanced). * A short description and/or outline of the tutorial content. * A list of Python packages that attendees will need to have installed to follow along. Cheers, Brian Granger SciPy 2010, Tutorial Chair -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] SciPy 2010 Tutorials: brainstorming and call for proposals
Greetings everyone, This year, there will be two days of tutorials (June 28th and 29th) before the main SciPy 2010 conference. Each of the two tutorial tracks (intro, advanced) will have a 3-4 hour morning and afternoon session both days, for a total of 4 intro sessions and 4 advanced sessions. The main tutorial web page for SciPy 2010 is here: http://conference.scipy.org/scipy2010/tutorials.html We are currently in the process of planning the tutorial sessions. You can help us in two ways: Brainstorm/vote on potential tutorial topics To help us plan the tutorials, we have setup a web site that allow everyone in the community to brainstorm and vote on tutorial ideas/topics. The website for brainstorming/voting is here: http://conference.scipy.org/scipy2010/tutorialsUV.html The tutorial committee will use this information to help select the tutorials. Please jump in and let us know what tutorial topics you would like to see. Tutorial proposal submissions = We are now accepting tutorial proposals from individuals or teams that would like to present a tutorial. Tutorials should be focused on covering a well defined topic in a hands on manner. We want to see tutorial attendees coding! We are pleased to offer tutorial presenters stipends this year for the first time: * 1 Session: $1,000 (half day) * 2 Sessions: $1,500 (full day) Optionally, part of this stipend can be applied to the presenter's registration costs. To submit a tutorial proposal please submit the following materials to 2010tutori...@scipy.org by April 15: * A short bio of the presenter or team members. * Which track the tutorial would be in (intro or advanced). * A short description and/or outline of the tutorial content. * A list of Python packages that attendees will need to have installed to follow along. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Patch for Qt4 backend for IPython GUI
Hi, We are in the process of getting our new Qt IPython GUI working with matplotlib. One problem we have found is that the matplotlib qt4 backend always creates a QApplication. This is problematic in situations where another part of an application has already created a QApplication. The fix is to have matplotlib first see if a QApplication already exists and then use that one. The attached patch implements this fix. If needed, Fernando can help test this, but I think the change is minor enough that it should be good to go. Cheers, Brian 0001-Qt4-backend-now-checks-for-preexisting-QApplication.patch Description: Binary data -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
Eric, On Fri, Aug 27, 2010 at 12:15 AM, Eric Firing wrote: > On 08/26/2010 05:13 PM, Brian Granger wrote: >> Hi, >> >> We are in the process of getting our new Qt IPython GUI working with >> matplotlib. One problem we have found is that the matplotlib qt4 >> backend always creates a QApplication. This is problematic in >> situations where another part of an application has already created a >> QApplication. The fix is to have matplotlib first see if a >> QApplication already exists and then use that one. The attached patch >> implements this fix. If needed, Fernando can help test this, but I >> think the change is minor enough that it should be good to go. > > I committed it. Thanks! I am going to post another msg soon about our thoughts on a new and consistent way of detecting existing apps and running event loops. > I suspect the most recent changes to ipython may require changes to > show, but they can wait until things settle down a bit. Very likely, we will be in touch. Brian > Eric > >> >> Cheers, >> >> Brian > > -- > 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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
On Sat, Aug 28, 2010 at 8:12 PM, Michiel de Hoon 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 wrote: > >> From: Brian Granger >> Subject: [matplotlib-devel] Uniform GUI support across matplotlib, ets and >> ipython >> To: matplotlib-devel@lists.sourceforge.net, "IPython Development list" >> , enthought-...@enthought.com, "Evan Patterson" >> >> 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 >>
Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
On Mon, Aug 30, 2010 at 7:10 AM, Michiel de Hoon wrote: > Hi Brian, > Thanks for your reply. I agree that integrating multiple event loops is not > essential for most users. But if you are not integrating multiple event > loops, then why do you need poll? In the two process kernel we do currently integrate two event loops: 1. Our networking event loop that is based on zeromq/pyzmq 2. A single GUI event loop from wx, qt4, etc. We do this by triggering an iteration of our networking event loop on a periodic GUI timer. So we definitely have to face multiple event loop integration, but it is much simpler when you only have 1 GUi event loop involved. Cheers, Brian > Best, > --Michiel. > > > --- On Sun, 8/29/10, Brian Granger wrote: > >> From: Brian Granger >> Subject: Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets >> and ipython >> To: "Michiel de Hoon" >> Cc: matplotlib-devel@lists.sourceforge.net, "IPython Development list" >> , enthought-...@enthought.com, "Evan Patterson" >> >> Date: Sunday, August 29, 2010, 3:24 PM >> On Sat, Aug 28, 2010 at 8:12 PM, >> Michiel de Hoon >> 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 >> wrote: >> > >> >> From: Brian Granger >> >> Subject: [matplotlib-devel] Uniform GUI support >> across matplotlib, ets and ipython >> >> To: matplotlib-devel@lists.sourceforge.net, >>
Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
On Tue, Aug 31, 2010 at 7:02 AM, Michiel de Hoon wrote: >> 1. Our networking event loop that is based on zeromq/pyzmq >> 2. A single GUI event loop from wx, qt4, etc. >> >> We do this by triggering an iteration of our networking >> event loop on a periodic GUI timer. > > So right now you're in a loop in which you let qt4 (or wx) watch the file > descriptors qt4 needs, then zeromq the file descriptors that zeromq needs, > and so on? ZMQ sockets are not really sockets in that they do not have a file descriptor interface. That is something that is being worked on in the zeromq development, but it is not there yet. Also, I don't think the API will be fully compatible, so I am not sure how it will play with what Qt is expecting. > Just use the qt4 event loop to watch both the file descriptors zeromq wants > to watch, in addition to whatever events qt4 needs. Qt4 already has the API > that allows you to do this (QSocketNotifier et al.). I am not familiar with > zeromq, but if there is a way to determine which file descriptors it wants to > watch then you're almost done. If not, you could discuss this with the zeromq > developers. Then you won't need to poll, you'll get better response times, > and the code will be scalable too. > > Best, > --Michiel. > > > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
Michiel, On Fri, Sep 3, 2010 at 9:22 AM, Michiel de Hoon wrote: > --- On Wed, 9/1/10, Brian Granger wrote: >> > So right now you're in a loop in which you let qt4 (or >> wx) watch the file descriptors qt4 needs, then zeromq the >> file descriptors that zeromq needs, and so on? >> >> ZMQ sockets are not really sockets in that they do not have >> a file descriptor interface. > > That may be, but at the bottom of the ZMQ event loop is a call to select(), > which expects a pair of ordinary file descriptors. At the same time, at the > bottom of the qt4 event loop is also a call to select(), also using a set of > file descriptors. What you are saying is mostly right. ZMQ uses the best polling mechanism for the platform (select/poll/epoll/kqueue/etc). In some cases, there are actual file descriptors in the internals of zeromq. As I understand it: * Zeromq runs on other transports other than TCP and not all of those transports have file descriptors. * Even if zeromq is using TCP for transport, a single zeromq socket may be implemented with many low level sockets during its lifetime. These sockets are not in any way exposed in the public zeromq API. * zeromq sockets are connectionless. If you were able to get those low level file descriptors, the model would become leaky because you would need to start handling the connection related events. Thus, it is currently not an option to get those low level file descriptors and do what you are proposing. > Currently your event loop works approximately as follows: > > 1) Run the qt4 event loop, which calls select() inside qt4, watching the file > descriptors that qt4 knows about. > 2) Interrupt the qt4 event loop, and enter the ZMQ event loop, which calls > select() inside ZMQ to watch the file descriptors ZMQ knows about. > 3) If none if the ZMQ file descriptors have been signaled, go to 1). > > Ideally, you would want to call select() only once, and have it watch both > the file descriptors qt4 knows about, as well as the file descriptors ZMQ > knows about. > > So how to implement this? > > Think about just the ZMQ event loop for now. Just before entering the ZMQ > event loop, ZMQ knows which file descriptors it should watch when it calls > select(). Which means that ZMQ maintains in some form or another a list of > file descriptors to watch. Now I don't know the details of ZMQ, but I suppose > there is some function inside ZMQ that effectively adds one file descriptor > to the ZMQ list of file descriptors to watch. Now, instead of this function, > call an ipython-specific function that effectively adds this file descriptor > to the list of file descriptors that qt should watch for (probably using > QSocketNotifier). Now you don't need to enter the ZMQ event loop at all: When > you enter the qt event loop, and there is any activity on one of the ZMQ file > descriptors, the qt event loop will notice and take the appropriate action. > > Does this make sense? Definitely, it makes total sense, it is just not possible today with how zeromq is implemented. The zeromq devs are working on a file descriptor interface, but it will not be fully compatible with the usual one in that you won't be able to distinguish between read, write and error events with only the file descriptor. I am not sure the file descriptor interface that zeromq will eventually have will actually work with what qt is expecting. The other issue is one of maintainability. Currently the GUI code and zeromq event loop code is completely separate and orthogonal. We can easily change one without affecting the other. If we were to combine the event loops, we would loose that nice separation that makes our code more robust, stable and maintainable. Also, I should mention that the current approach functions perfectly well. Both the GUI and IPython remain extremely responsive at all times. I should also mention that the help we need with matplotlib right now is *completely* independent of these issues of how we integrate the two event loops. Thanks for the ideas though. Cheers, Brian > --Michiel. > > > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx
Hello all, I would like to submit the following branch on github for review and merging into matplotlib trunk: http://github.com/ellisonbg/matplotlib/commits/guisupport This branch implements the logic needed for the qt4 and wx backends to fully work with the upcoming IPython 0.11 release. In our testing we have run many of the mpl examples (including the new animation examples) in both qt4/wx in both the terminal based IPython and the new IPython Qt GUI. For background on these changes please see this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTik2SNtXMaezCc0UiMnCYg6LxwEL1eN9YASnmOua%40mail.gmail.com&forum_name=matplotlib-devel It is important to note that we have not updated the other matplotlib backends (gtk, tk, etc.) to have this logic. This is mainly because we know almost nothing about these toolkits and could really use some help from folks who are experts at the respective toolkits. We have done some minimal testing and these other backends do work for simple examples in the terminal IPython, but they won't work in all cases and will definitely not work in the new IPython Qt based GUI. We would love feedback and help testing as these changes are significant (even though only a few lines of code). To test this stuff you will need to grab the following IPython development branch: http://github.com/ipython/ipython/tree/newkernel You should be able to run the examples in regular ipython: ipython --pylab qt4|wx Or the new GUI ipythonqt --pylab qt4|wx Cheers, Brian -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx
Eric, Looks like you are on Linux. If so, you will have to make sure you do two things before doing python setup.py install on pyzmq: 1. Edit the setup.cfg (copy the template) to point to your zeromq install. 2. Use the --rpath option: python setup.py build_ext --rpath=/opt/zeromq-dev/lib --inplace Alternatively, you can set the LD_LIBRARY_PATH to point to your zeromq lib path. Also, for now, we suggest using the stable 2.0.7 releases of both pyzmq and zeromq. Sorry about the hitches, parts of this are definitely still rough and we hope to iron out these things. I should mention that zeromq/pyzmq are only required for the new Qt gui, the old terminal ipython doesn't require them. Let us know if you run into any other issues. Cheers, Brian On Fri, Sep 3, 2010 at 6:57 PM, Eric Firing wrote: > On 09/03/2010 12:37 PM, Brian Granger wrote: >> Hello all, >> >> I would like to submit the following branch on github for review and >> merging into matplotlib trunk: >> >> http://github.com/ellisonbg/matplotlib/commits/guisupport >> >> This branch implements the logic needed for the qt4 and wx backends to >> fully work with the upcoming IPython 0.11 release. In our testing we >> have run many of the mpl examples (including the new animation >> examples) in both qt4/wx in both the terminal based IPython and the >> new IPython Qt GUI. For background on these changes please see this >> thread: >> >> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTik2SNtXMaezCc0UiMnCYg6LxwEL1eN9YASnmOua%40mail.gmail.com&forum_name=matplotlib-devel >> >> It is important to note that we have not updated the other matplotlib >> backends (gtk, tk, etc.) to have this logic. This is mainly because >> we know almost nothing about these toolkits and could really use some >> help from folks who are experts at the respective toolkits. We have >> done some minimal testing and these other backends do work for simple >> examples in the terminal IPython, but they won't work in all cases and >> will definitely not work in the new IPython Qt based GUI. >> >> We would love feedback and help testing as these changes are >> significant (even though only a few lines of code). To test this >> stuff you will need to grab the following IPython development branch: >> >> http://github.com/ipython/ipython/tree/newkernel >> >> You should be able to run the examples in regular ipython: >> >> ipython --pylab qt4|wx >> >> Or the new GUI >> >> ipythonqt --pylab qt4|wx >> > > Brian and others, > > It's not quite that simple. After some initial thrashing around, I > installed zmq from source, and then pyzmq--but I can't import zmq: > > In [1]: import zmq > --- > ImportError Traceback (most recent call last) > /home/efiring/ in () > > /usr/local/lib/python2.6/dist-packages/zmq/__init__.py in () > 24 > #- > > 25 > ---> 26 from zmq import _zmq > 27 from zmq._zmq import * > 28 > > ImportError: libzmq.so.0: cannot open shared object file: No such file > or directory > > But it is right where it should be: > > efir...@manini:~/programs/py/ipython/pyzmq_git$ ll /usr/local/lib/libzmq* > -rw-r--r-- 1 root root 4736930 2010-09-03 14:35 /usr/local/lib/libzmq.a > -rwxr-xr-x 1 root root 825 2010-09-03 14:35 /usr/local/lib/libzmq.la > lrwxrwxrwx 1 root root 15 2010-09-03 14:35 /usr/local/lib/libzmq.so > -> libzmq.so.0.0.0 > lrwxrwxrwx 1 root root 15 2010-09-03 14:35 > /usr/local/lib/libzmq.so.0 -> libzmq.so.0.0.0 > -rwxr-xr-x 1 root root 1993116 2010-09-03 14:35 > /usr/local/lib/libzmq.so.0.0.0 > > And it looks like the extension was built OK, complete with linking: > > gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall > -Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include/python2.6 > -c zmq/_zmq.c -o build/temp.linux-x86_64-2.6/zmq/_zmq.o > zmq/_zmq.c:1995: warning: ‘__pyx_doc_3zmq_4_zmq_7Message___len__’ > defined but not used > gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions > build/temp.linux-x86_64-2.6/zmq/_zmq.o -L/usr/local/lib -lzmq -o > build/lib.linux-x86_64-2.6/zmq/_zmq.so > > > I'm stumped. > > Eric > >> Cheers, >> >> Brian > > > -- > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. >
Re: [matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx
Eric, Sorry about the delay, I was on vacation last week...comments inline below... On Tue, Sep 7, 2010 at 2:26 PM, Eric Firing wrote: > On 09/07/2010 11:07 AM, Fernando Perez wrote: >> Hi Eric, >> >> On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing wrote: >>> >>> I have been doing a little testing with ipython 0.10 versus >>> ipython-newkernel, both modes, and with mpl svn versus your guisupport. >>> There are so many possible modes of operation and combinations of >>> versions and backends that all this will take some time to sort out. >>> >>> Can you give me simple examples of what does *not* work correctly when >>> you use mpl *svn* with ipython-newkernel, in either or both of the >>> console or gui modes, but *does* work with your guisupport version? >> >> Thanks for your testing, Eric. >> >> With matplotlib *alone*, I can't find a way to crash/lock/whatever the >> combo of matplotlib(svn)+ipython-newkernel. >> >> The reason, i believe, is that guisupport.py is available in ipython >> itself, and it goes out of its way to avoid creating a second main qt >> app, letting matplotlib create it. Since that main app is alive all >> the time, there's only one app and one event loop and life is good. >> But if I were to open another library that uses Qt and makes a new >> main qApp unconditionally, we'd have problems. >> >> Brian and Evan have recently just added the guisupport.py patch to >> Enthought's ETS, so that now it probably will be pretty hard to >> actually see the problem: if both ipython and ets go out of their way >> to avoid the nested main app issue, mpl can get away with making one >> unconditionally and things will probably work OK. >> >> But the idea is for all of us (ipython, ets, mpl, etc) to agree on a >> collaborative protocol with a simple api: check for one special >> '_in_event_loop' flag in the main toolkit before making one. That >> will make it easier to have interactive code that uses Wx or Qt from >> more than one library coexisting in the same process. > > Fernando, > There are two parts to guisupport: ensure a single main app, and ensure > no more than one call to the mainloop. Yes, that is a good summary. > The first makes perfect sense, > and cannot cause any problems that I can see. The second one is the one > that I think may be both unnecessary and undesirable. The reason is > that the gui toolkit mainloop functions or methods are designed for > nested calls. This permits blocking within a running mainloop, and > allows show() to block when pyplot is not in interactive mode. This is > what is lost with the guisupport mods. Some changes to mainloop logic > may well be needed, but I don't think that prohibiting nested calls to > the underlying toolkit mainloop function is necessary or desirable. This is a very good point and is something that we have thought carefully about. You are very correct, that the functions in guisupport cannot be used to do a nested mainloop. Nested calls to the mainloop should be done in the usual manner by simply calling the appropriate gui toolkit method for doing so. We probably need to clarify this point, but the focus of the functions in guisupport are *only* the first and main invocation of the event loop. Basically, we want to ensure that: * Projects don't accidentally do nested mainloops because there were not aware that the outermost eventloop was already running. * Projects start the outermost eventloop in a manner that other projects will be able to reliably detect. I should mention the other approach that we have tried, but that failed: * Have IPython startup, create an app and start the main loop. * Then monkeypatch the gui toolkit so that the mainloop calls are no-ops. * Further monkeypatch the gui toolkit so that it appears that the mainloop is running (even when it may not be because of PyOS_InputHook magic). This allowed us to do everything, BUT obviously, nested mainloops failed. Thus, making sure that nested mainloops still work was the main reason we have created guisupport. We should better document these details though. Cheers, Brian > Eric > >> >> I'll let Brian fill in with more details when he has some >> availability, but I think that's the gist of it. >> >> Regards, >> >> f > > > -- > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- Start uncovering the many advantages of virtual appliances an
Re: [matplotlib-devel] [IPython-dev] IPython (new) + matplotlib report: happy news
Fernando, On Mon, Sep 13, 2010 at 1:58 PM, Fernando Perez wrote: > Hi folks, > > [ sorry for the cross-post, but devs on both lists will care about this] > > I just went through the exercise of pasting 100 randomly chosen > examples from the gallery into the new ipython console with inline > graphics. Report: > > - 98 worked perfectly: the figures I got were identical to those on the > website. That is a pretty significant test of the new console100 is a lot of copying and pasting. > - 1 had minor visual differences: > http://matplotlib.sourceforge.net/examples/pylab_examples/quadmesh_demo.html: > in the SVG render, the masked region > appears black instead of transparent. > > - One produced an error: > http://matplotlib.sourceforge.net/examples/axes_grid/simple_axisline4.html > > ... > ...: plt.draw() > ...: plt.show() > ...: > Received invalid plot data. > > But when I save the file and try to load it into firefox, it seems to > indeed be bad SVG: > > XML Parsing Error: mismatched tag. Expected: . > Location: file:///home/fperez/ipython/ipython/bad.svg > Line Number 287, Column 3: > --^ > > In summary: we can run pretty much any MPL example by straight > copy/paste, and the only two glitches I see are in the SVG data > itself. Once the other two buglets I reported earlier get fixed up, > this will be a very nice way to interact with MPL. > > One small request: is it possible/easy to add to the MPL examples a > little 'copy to clipboard' button or link? Now that one can > copy/paste wholesale examples into an interactive session to explore > them, it feels annoying to have to highlight the whole text box and > then do Ctrl-C or menu->copy. It would be really nice to have a > one-click 'copy to clipboard'... But I have no idea if that's easy or > hard in HTML... +1 to this! Cheers, Brian > Anyway, I think we're starting to be in pretty good shape! > > Cheers, > > f > ___ > IPython-dev mailing list > ipython-...@scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx
On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing wrote: > On 09/03/2010 12:37 PM, Brian Granger wrote: >> Hello all, >> >> I would like to submit the following branch on github for review and >> merging into matplotlib trunk: >> >> http://github.com/ellisonbg/matplotlib/commits/guisupport >> >> This branch implements the logic needed for the qt4 and wx backends to >> fully work with the upcoming IPython 0.11 release. In our testing we >> have run many of the mpl examples (including the new animation >> examples) in both qt4/wx in both the terminal based IPython and the >> new IPython Qt GUI. For background on these changes please see this >> thread: >> >> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTik2SNtXMaezCc0UiMnCYg6LxwEL1eN9YASnmOua%40mail.gmail.com&forum_name=matplotlib-devel >> >> It is important to note that we have not updated the other matplotlib >> backends (gtk, tk, etc.) to have this logic. This is mainly because >> we know almost nothing about these toolkits and could really use some >> help from folks who are experts at the respective toolkits. We have >> done some minimal testing and these other backends do work for simple >> examples in the terminal IPython, but they won't work in all cases and >> will definitely not work in the new IPython Qt based GUI. >> >> We would love feedback and help testing as these changes are >> significant (even though only a few lines of code). To test this >> stuff you will need to grab the following IPython development branch: >> >> http://github.com/ipython/ipython/tree/newkernel >> >> You should be able to run the examples in regular ipython: >> >> ipython --pylab qt4|wx >> >> Or the new GUI >> >> ipythonqt --pylab qt4|wx > > Brian, Fernando, > > I have been doing a little testing with ipython 0.10 versus > ipython-newkernel, both modes, and with mpl svn versus your guisupport. > There are so many possible modes of operation and combinations of > versions and backends that all this will take some time to sort out. > > Can you give me simple examples of what does *not* work correctly when > you use mpl *svn* with ipython-newkernel, in either or both of the > console or gui modes, but *does* work with your guisupport version? The problems are when matplotlib and enthought.traits/pyface/mayavi stuff are used together. There are two types of problems: * Multiple apps are created. The enthought stuff used to not check for existing apps, but that has been fixed. * Event loop is started multiple times. This one is more subtle and on some toolkits the error is not fatal. This problem shows up when IPython is run in terminal mode and event loop integration is handled through PyOS_InputHook. In these situations, if matplotlib or ets start the event loop themselves, IPython will hang. Unfortunately, I am having trouble getting an install of both matplotlib svn and ets svn on the same machine, so I can't reproduce any of the failures ATM. I am trying to get things installed so I can reproduce the problems. Cheers, Brian > Thanks. > > Eric > >> >> Cheers, >> >> Brian >> > > -- > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx
On Tue, Sep 14, 2010 at 12:59 AM, Eric Firing wrote: > On 09/13/2010 05:46 PM, Brian Granger wrote: >> >> On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing wrote: >>> >>> On 09/03/2010 12:37 PM, Brian Granger wrote: >>>> >>>> Hello all, >>>> >>>> I would like to submit the following branch on github for review and >>>> merging into matplotlib trunk: >>>> >>>> http://github.com/ellisonbg/matplotlib/commits/guisupport >>>> >>>> This branch implements the logic needed for the qt4 and wx backends to >>>> fully work with the upcoming IPython 0.11 release. In our testing we >>>> have run many of the mpl examples (including the new animation >>>> examples) in both qt4/wx in both the terminal based IPython and the >>>> new IPython Qt GUI. For background on these changes please see this >>>> thread: >>>> >>>> >>>> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTik2SNtXMaezCc0UiMnCYg6LxwEL1eN9YASnmOua%40mail.gmail.com&forum_name=matplotlib-devel >>>> >>>> It is important to note that we have not updated the other matplotlib >>>> backends (gtk, tk, etc.) to have this logic. This is mainly because >>>> we know almost nothing about these toolkits and could really use some >>>> help from folks who are experts at the respective toolkits. We have >>>> done some minimal testing and these other backends do work for simple >>>> examples in the terminal IPython, but they won't work in all cases and >>>> will definitely not work in the new IPython Qt based GUI. >>>> >>>> We would love feedback and help testing as these changes are >>>> significant (even though only a few lines of code). To test this >>>> stuff you will need to grab the following IPython development branch: >>>> >>>> http://github.com/ipython/ipython/tree/newkernel >>>> >>>> You should be able to run the examples in regular ipython: >>>> >>>> ipython --pylab qt4|wx >>>> >>>> Or the new GUI >>>> >>>> ipythonqt --pylab qt4|wx >>> >>> Brian, Fernando, >>> >>> I have been doing a little testing with ipython 0.10 versus >>> ipython-newkernel, both modes, and with mpl svn versus your guisupport. >>> There are so many possible modes of operation and combinations of >>> versions and backends that all this will take some time to sort out. >>> >>> Can you give me simple examples of what does *not* work correctly when >>> you use mpl *svn* with ipython-newkernel, in either or both of the >>> console or gui modes, but *does* work with your guisupport version? >> >> The problems are when matplotlib and enthought.traits/pyface/mayavi >> stuff are used together. There are two types of problems: >> >> * Multiple apps are created. The enthought stuff used to not check >> for existing apps, but that has been fixed. > > That one is easy. > >> * Event loop is started multiple times. This one is more subtle and >> on some toolkits the error is not fatal. This problem shows up when >> IPython is run in terminal mode and event loop integration is handled >> through PyOS_InputHook. In these situations, if matplotlib or ets >> start the event loop themselves, IPython will hang. > > So, this can be checked with nothing but IPython and mpl. I think I may have > seen this with some combination of configurations, though not with what I > typically use. > >> >> Unfortunately, I am having trouble getting an install of both >> matplotlib svn and ets svn on the same machine, so I can't reproduce >> any of the failures ATM. I am trying to get things installed so I can >> reproduce the problems. > > At least twice in the last couple of years I have tried to get mayavi > compiled and running, without fouling up my development versions of numpy > and mpl. I never succeeded. Granted, I didn't allocate much time and > mental energy to it. Yes, it can be a challenge, we will see how far I get... > In any case, with the help of your recent explanations, I expect we can make > mpl play by your suggested rules without sacrificing anything. Part of the > change for mpl 1.0 was to factor all of the show logic out into > backend_bases.py, leaving only the core mainloop call in the specific > backends. I hope we can keep that aspect, retaining the ability to work > with earlier ipython (0.10) and the ability for show to b
[matplotlib-devel] Latex to svg using mathtext
Hi, I need to generate svg (for web browser display) from latex using mathtext. I see that mathtext.MathTextParser has a to_png method. Is there a way of doing the equivalent of to_svg? I see there is an svg Mathtext backend, but it is not clear what it produces. Thanks! Brian -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Simple animation test
Hi, I am trying to do a simple animation examples similar to the one here: http://www.scipy.org/Cookbook/Matplotlib/Animations#head-e50abcca4333d3d76b3f2bb66ef00f15c6b4dbbc But it does not work. I have tried with different backends, plain python, within ipython. I am using ipython 0.10 and matplotlib 0.99.3 from EPD. I have used this approach in the past, but no luck this time. If I add a show() early on, the first plot shows OK, but it sits and waits until I close the plot window before moving on. Any ideas? Cheers, Brian -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Simple animation test
Is the old method (just using draw/set_xdata, etc.) not supported? I am working with a student and I want to keep is dead simple. Brian On Wed, Mar 2, 2011 at 10:22 AM, Benjamin Root wrote: > > > On Wed, Mar 2, 2011 at 7:44 AM, John Hunter wrote: >> >> On Wed, Mar 2, 2011 at 12:27 AM, Brian Granger >> wrote: >> > Hi, >> > >> > I am trying to do a simple animation examples similar to the one here: >> > >> > >> > http://www.scipy.org/Cookbook/Matplotlib/Animations#head-e50abcca4333d3d76b3f2bb66ef00f15c6b4dbbc >> > >> > But it does not work. I have tried with different backends, plain >> > python, within ipython. I am using ipython 0.10 and matplotlib 0.99.3 >> > from EPD. I have used this approach in the past, but no luck this >> > time. If I add a show() early on, the first plot shows OK, but it >> > sits and waits until I close the plot window before moving on. Any >> > ideas? >> >> If you are running mpl from the development tree on github, I suggest >> you use the new animations API, which hides much of the complexity. >> See >> >> https://github.com/matplotlib/matplotlib/tree/master/examples/animation >> >> If you are running a released mpl, you can simply drop the >> animation.py file into your PYTHONPATH and use it directly >> >> >> https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/animation.py >> >> Hope this helps, >> JDH >> > > I don't think that is necessarily true. If I remember correctly, Ryan May > introduced some other API changes (I think they made it to the 1.0.x branch) > in order to facilitate his animations. > > Ben Root > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Simple animation test
>> Is the old method (just using draw/set_xdata, etc.) not supported? I >> am working with a student and I want to keep is dead simple. > > The old method is subject to the problems you're encountering now > because you're working outside the GUI's event loop. The new method > was created to be "dead simple" and yet work reliably. If there's some > kind of unintuitive/hard part of the new animation API, I'd love to > know about it. The main issue I have is that I am working with undergraduate students who have no experience installing things from scratch. In this context I am stuck with whatever is in EPD. Currently EPD is at 1.0.1, which does not have animation. Will this file "just work" with 1.0.1 or 0.99.3? I don't have any aversion to using animation.py, I just need to be able to use it within a stock recent EPD. Cheers, Brian > Ryan > >> >> Brian >> >> On Wed, Mar 2, 2011 at 10:22 AM, Benjamin Root wrote: >>> >>> >>> On Wed, Mar 2, 2011 at 7:44 AM, John Hunter wrote: >>>> >>>> On Wed, Mar 2, 2011 at 12:27 AM, Brian Granger >>>> wrote: >>>> > Hi, >>>> > >>>> > I am trying to do a simple animation examples similar to the one here: >>>> > >>>> > >>>> > http://www.scipy.org/Cookbook/Matplotlib/Animations#head-e50abcca4333d3d76b3f2bb66ef00f15c6b4dbbc >>>> > >>>> > But it does not work. I have tried with different backends, plain >>>> > python, within ipython. I am using ipython 0.10 and matplotlib 0.99.3 >>>> > from EPD. I have used this approach in the past, but no luck this >>>> > time. If I add a show() early on, the first plot shows OK, but it >>>> > sits and waits until I close the plot window before moving on. Any >>>> > ideas? >>>> >>>> If you are running mpl from the development tree on github, I suggest >>>> you use the new animations API, which hides much of the complexity. >>>> See >>>> >>>> https://github.com/matplotlib/matplotlib/tree/master/examples/animation >>>> >>>> If you are running a released mpl, you can simply drop the >>>> animation.py file into your PYTHONPATH and use it directly >>>> >>>> >>>> https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/animation.py >>>> >>>> Hope this helps, >>>> JDH >>>> >>> >>> I don't think that is necessarily true. If I remember correctly, Ryan May >>> introduced some other API changes (I think they made it to the 1.0.x branch) >>> in order to facilitate his animations. >>> >>> Ben Root >>> >>> >> >> >> >> -- >> Brian E. Granger, Ph.D. >> Assistant Professor of Physics >> Cal Poly State University, San Luis Obispo >> bgran...@calpoly.edu >> elliso...@gmail.com >> >> -- >> Free Software Download: Index, Search & Analyze Logs and other IT data in >> Real-Time with Splunk. Collect, index and harness all the fast moving IT data >> generated by your applications, servers and devices whether physical, virtual >> or in the cloud. Deliver compliance at lower cost and gain new business >> insights. http://p.sf.net/sfu/splunk-dev2dev >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > -- > Ryan May > Graduate Research Assistant > School of Meteorology > University of Oklahoma > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
> 3. Traits. We (Brian and I) have gone back and forth a lot on Traits, > and we've come very close to just making them a dependency. The only > real issue holding us back is that ipython so far has exactly *zero* > extension code, which is a plus in terms of ease of > installation/deployment. Having said that, as far as extension code > is concerned, Traits is light and clean, and nowhere near the kinds of > complexities that MPL deals with. But since anything is more than > zero, it is a bit of an issue for us. We may tip over though, I'm > just stating what our reasoning so far has been. > > In terms of Traits, point (2) above makes them even more attractive. > The delegation aspect of Traits is a very appealing way of combining > validation with additional action for the runtime modification of an > object. For example: > > ipython.color_scheme = "foo" > > If color_scheme were a Trait, the above could simply: > > a) validate that "foo" was acceptable as a value > b) trigger the chain of other trait updates (dependent color schemes > for exceptions, prompts, etc). At some level though, configuration is a very different thing than an application's runtime API. While they may be related (by exposing common functionality), not everything that can be configured would appear in a runtime API and vice-versa. Also, some events that need to happen when an attribute is changed at runtime can't happen at config time as the application might not yet be up and running yet. Using Traits in the runtime API is an entirely different ballgame than simply using it for type validation in configuration: When using Traits for validation+configuration, the objects that inherit from HasTraits are simply bunch/dict like objects that do type validation - but they don't contain any application logic. The actually application logic is contained in classes that aren't traited themselves, but that consume traited config objects to configure themselves at startup. If traited objects are exposed in a runtime API, all of a sudden the application logic moves to the traited classes themselves. Then, the entire application (any object that needs config or has a runtime API) is built upon traits at its core. This is very from the previous case where traited classes are used as a minor implementation detail of the config system. I am not saying that it is bad to build an application with traits at its core, but only that that is very different from the path that ipython and matplotlib have taken thus far. Also, it makes the commitment level to traits much higher than if it is used merely as a component in the config system - which could easily be swapped out if desired. Brian > All of this can obviously be done with python properties, but before I > write Traits again, poorly (I'm no David Morrill) I'd rather ride > Enthought's back. > > This approach via Traits (or something like them) also ensures that > the work done in ensuring the consitency/robustness of an object's > *runtime* configuration API becomes automatically useful to users, and > it simplifies the init-time config API, since it gives us the option > to defer more complicated tasks to runtime. > > > So this is a summary of where we stand. It's surprising that the > 'simple question' of configuring an application can turn out to be > such a can of worms, but for us it has proven to be. Input/ideas from > you all would be very welcome, as it's quite likely we've missed > possible solutions. > > I'd love to get out of this discussion some ideas, clarity and > ultimately a plan for how to proceed in the long haul. If in addition > this means that ipython, mpl and others end up uniformizing further > our approach to this problem, even better! Having our end users find > familiar configuration mechanisms across their various libraries would > only be a good thing in the long run. > > Cheers, > > Brian and f. > > > ps - I debated on having this discussion on ipython-dev, but for now > I'm going to not cross-post. The MPL team is attentive to the issue > now, so I'd rather collect your wisdom here, and I'll take it upon > myself to summarize our conclusions on ipython-dev later. I just want > to avoid list cross-posting. > -- Brian E. Granger, Ph.D. Research Scientist Tech-X Corporation phone: 720-974-1850 [EMAIL PROTECTED] [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rcParams and validation
> Damn, that is really cool. So you can generate default config files from the > MPLConfig instance. We create a default matplotlibrc file from a template, > setting default backend and numerix values based on what is available on the > users system. It looks like it would be even easier with your scheme: import > MPLConfig in setup.py, set the attributes, dump to a default config file. My thought for IPython is to have defaults set in the traited config class itself so you wouldn't even have to do the second step. Just import MPLConfig and dump to a file. I too think this is one of the really nice benefits of this approach. Generating the default config file for IPython1 was becoming a real problem. > [...] > > In summary, I'm fairly happy with the results, and I think the benefit > > is enough to convince me of falling in the embrace of the gods of > > Traits. It seems John is going for Traits as well, so perhaps we can > > use this little config setup across our systems, and even make it > > something that others use in the future. I think there's value for > > end users in having common, uniform configuration systems across the > > various parts of the scientific python 'ecosystem'. > > I agree. It looks really elegant. What about the circular dependencies you > mentioned in a previous email, is that still a potential problem? The circular dependency problem goes away in the following way. The config files and config objects will only consist of basic types (int, strings, float, lists, dicts, etc) - not executable python code. If you need to specify python code (the name of a class that implements some behavior for example) that would be specified as a string. During the initial parts of the configuration process, that would remain a string, thus avoiding the circular dependency problem. Only after it is safe to execute/import, would the string be exec'd. > Darren > -- Brian E. Granger, Ph.D. Research Scientist Tech-X Corporation phone: 720-974-1850 [EMAIL PROTECTED] [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] Interactive Matplotlib in the browser
It is not clear to me that the stream of PNGs will win in the end. If you make a single static plot of a large data set, that is way better than trying to send the data to the browser and rendering it there. But if you have to send hundreds or thousands of PNGs to get interactivity, that benefit may be washed out. Especially if you have multiple users interacting with plots - the server could quickly grind to a halt. I think we should do tests to see how bad it gets, taking into account the multiple user question. The one performance benefit that I can think of is that you can tune the level of interactivity to limit the data that comes back. For large data sets, users might be willing to settle for less interactivity. That option doesn't exist when you send all the data back. Cheers, Brian On Thu, Oct 11, 2012 at 2:49 PM, Michael Droettboom wrote: > I have a proof-of-concept way to make interactive plots in the browser work > using transparent PNGs described here: > > http://mdboom.github.com/blog/2012/10/11/matplotlib-in-the-browser-its-coming/ > > No PRs yet, because this is miles from ready for that, but it would be > helpful to get some feedback about how this works in different > browsers/platforms/network environments etc. > > Mike > > ___ > IPython-dev mailing list > ipython-...@scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] [JOB] Work full time on Project Jupyter/IPython
Hi all, I wanted to let the community know that we are currently hiring 3 full time software engineers to work full time on Project Jupyter/IPython. These positions will be in my group at Cal Poly in San Luis Obispo, CA. We are looking for frontend and backend software engineers with lots of Python/JavaScript experience and a passion for open source software. The details can be found here: https://www.calpolycorporationjobs.org/postings/736 This is an unusual opportunity in a couple of respects: * These positions will allow you to work on open source software full time - not as a X% side project (aka weekends and evenings). * These are fully benefited positions (CA state retirement, health care, etc.) * You will get to work and live in San Luis Obispo, one of the nicest places on earth. We are minutes from the beach, have perfect year-round weather and are close to both the Bay Area and So Cal. I am more than willing to talk to any who interested in these positions. Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Question about getters and setters.
We (ipython/jupyter) have been talking some more about integrating matplotlilb in deeper ways with the interactive widgets framework. That only thing that would be required to make this *trivial* is having a traitlet's based API for matplotlib. I have even started to look at wrapping the existing mpl OO API using traitlets to start to explore this. Once this was done, it would be quite easy to autogenerate UIs for any aspect of Matplotlib. Now that traitlets is a standalone pure python package: https://github.com/ipython/traitlets this would be much easier to pull off. If there is interest in this, we might even be able to help do some of the work. Let us know if there is enough interest to discuss this further. Cheers, Brian On Wed, May 13, 2015 at 9:36 PM, Eric Firing wrote: > On 2015/05/13 5:47 PM, Neil Girdhar wrote: > > You're right. My angle is I just want the setters and getters. Writing > > set_ and get_ feels like the C++ prison I thought I had escaped :) > > > John Hunter once commented that if he were doing it over again he would > not have put in all the set_ and get_; they were a legacy of his origins > as a C++ programmer. I think he would have started with simple > attributes, which would have been adequate in the early stages. > Properties were very new--only introduced in Python 2.2, at the end of > 2001. > > Eric > > > -- > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Question about getters and setters.
I should note that *all* of ipython is based on traitlets, so by now it is very stable, battle tested (also actively developed). For base layers like this, I think that is important. On Wed, May 13, 2015 at 11:27 PM, Neil Girdhar wrote: > This is very exciting! traitlets looks really nice. (Imho better than > params from my cursory look.) > > On Thu, May 14, 2015 at 1:45 AM, Brian Granger > wrote: > >> We (ipython/jupyter) have been talking some more about integrating >> matplotlilb in deeper ways with the interactive widgets framework. That >> only thing that would be required to make this *trivial* is having a >> traitlet's based API for matplotlib. I have even started to look at >> wrapping the existing mpl OO API using traitlets to start to explore this. >> Once this was done, it would be quite easy to autogenerate UIs for any >> aspect of Matplotlib. >> >> Now that traitlets is a standalone pure python package: >> >> https://github.com/ipython/traitlets >> >> this would be much easier to pull off. >> >> If there is interest in this, we might even be able to help do some of >> the work. Let us know if there is enough interest to discuss this further. >> >> Cheers, >> >> Brian >> >> On Wed, May 13, 2015 at 9:36 PM, Eric Firing wrote: >> >>> On 2015/05/13 5:47 PM, Neil Girdhar wrote: >>> > You're right. My angle is I just want the setters and getters. >>> Writing >>> > set_ and get_ feels like the C++ prison I thought I had escaped :) >>> > >>> John Hunter once commented that if he were doing it over again he would >>> not have put in all the set_ and get_; they were a legacy of his origins >>> as a C++ programmer. I think he would have started with simple >>> attributes, which would have been adequate in the early stages. >>> Properties were very new--only introduced in Python 2.2, at the end of >>> 2001. >>> >>> Eric >>> >>> >>> -- >>> One dashboard for servers and applications across Physical-Virtual-Cloud >>> Widest out-of-the-box monitoring support with 50+ applications >>> Performance metrics, stats and reports that give you Actionable Insights >>> Deep dive visibility with transaction tracing using APM Insight. >>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>> ___ >>> Matplotlib-devel mailing list >>> Matplotlib-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >> >> >> >> -- >> Brian E. Granger >> Cal Poly State University, San Luis Obispo >> @ellisonbg on Twitter and GitHub >> bgran...@calpoly.edu and elliso...@gmail.com >> >> >> -- >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Question about getters and setters.
Great, that is exciting. What do you think is the best way forward? Should I open an issue on the matplotlib repo about this? Would there be interest in doing a Google+ hangout about this at some point? On Wed, May 13, 2015 at 11:57 PM, Eric Firing wrote: > On 2015/05/13 7:45 PM, Brian Granger wrote: > >> We (ipython/jupyter) have been talking some more about integrating >> matplotlilb in deeper ways with the interactive widgets framework. That >> only thing that would be required to make this *trivial* is having a >> traitlet's based API for matplotlib. I have even started to look at >> wrapping the existing mpl OO API using traitlets to start to explore >> this. Once this was done, it would be quite easy to autogenerate UIs for >> any aspect of Matplotlib. >> >> Now that traitlets is a standalone pure python package: >> >> https://github.com/ipython/traitlets >> >> this would be much easier to pull off. >> >> If there is interest in this, we might even be able to help do some of >> the work. Let us know if there is enough interest to discuss this further. >> > > No question about it: there is more than enough interest. > > Eric > > >> Cheers, >> >> Brian >> >> On Wed, May 13, 2015 at 9:36 PM, Eric Firing > <mailto:efir...@hawaii.edu>> wrote: >> >> On 2015/05/13 5:47 PM, Neil Girdhar wrote: >> > You're right. My angle is I just want the setters and getters. >> Writing >> > set_ and get_ feels like the C++ prison I thought I had escaped :) >> > >> John Hunter once commented that if he were doing it over again he >> would >> not have put in all the set_ and get_; they were a legacy of his >> origins >> as a C++ programmer. I think he would have started with simple >> attributes, which would have been adequate in the early stages. >> Properties were very new--only introduced in Python 2.2, at the end >> of 2001. >> >> Eric >> >> >> -- >> One dashboard for servers and applications across >> Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable >> Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> <mailto:Matplotlib-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> >> >> >> -- >> Brian E. Granger >> Cal Poly State University, San Luis Obispo >> @ellisonbg on Twitter and GitHub >> bgran...@calpoly.edu <mailto:bgran...@calpoly.edu> and >> elliso...@gmail.com <mailto:elliso...@gmail.com> >> > > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Question about getters and setters.
OK i have the MEP for this on my todo list... On Thu, May 14, 2015 at 5:47 AM, Benjamin Root wrote: > You could start up a Pull Request describing a MEP that would outline how > traitlets would be used. The discussion can go on there to flesh out the > concepts and the guidance documentation. Once that is agreed upon, that PR > would get merged, and we can then start up a new PR actually implementing > the MEP. > > On Thu, May 14, 2015 at 3:03 AM, Brian Granger > wrote: > >> Great, that is exciting. What do you think is the best way forward? >> Should I open an issue on the matplotlib repo about this? Would there be >> interest in doing a Google+ hangout about this at some point? >> >> On Wed, May 13, 2015 at 11:57 PM, Eric Firing wrote: >> >>> On 2015/05/13 7:45 PM, Brian Granger wrote: >>> >>>> We (ipython/jupyter) have been talking some more about integrating >>>> matplotlilb in deeper ways with the interactive widgets framework. That >>>> only thing that would be required to make this *trivial* is having a >>>> traitlet's based API for matplotlib. I have even started to look at >>>> wrapping the existing mpl OO API using traitlets to start to explore >>>> this. Once this was done, it would be quite easy to autogenerate UIs for >>>> any aspect of Matplotlib. >>>> >>>> Now that traitlets is a standalone pure python package: >>>> >>>> https://github.com/ipython/traitlets >>>> >>>> this would be much easier to pull off. >>>> >>>> If there is interest in this, we might even be able to help do some of >>>> the work. Let us know if there is enough interest to discuss this >>>> further. >>>> >>> >>> No question about it: there is more than enough interest. >>> >>> Eric >>> >>> >>>> Cheers, >>>> >>>> Brian >>>> >>>> On Wed, May 13, 2015 at 9:36 PM, Eric Firing >>> <mailto:efir...@hawaii.edu>> wrote: >>>> >>>> On 2015/05/13 5:47 PM, Neil Girdhar wrote: >>>> > You're right. My angle is I just want the setters and getters. >>>> Writing >>>> > set_ and get_ feels like the C++ prison I thought I had escaped :) >>>> > >>>> John Hunter once commented that if he were doing it over again he >>>> would >>>> not have put in all the set_ and get_; they were a legacy of his >>>> origins >>>> as a C++ programmer. I think he would have started with simple >>>> attributes, which would have been adequate in the early stages. >>>> Properties were very new--only introduced in Python 2.2, at the end >>>> of 2001. >>>> >>>> Eric >>>> >>>> >>>> -- >>>> One dashboard for servers and applications across >>>> Physical-Virtual-Cloud >>>> Widest out-of-the-box monitoring support with 50+ applications >>>> Performance metrics, stats and reports that give you Actionable >>>> Insights >>>> Deep dive visibility with transaction tracing using APM Insight. >>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>>> ___ >>>> Matplotlib-devel mailing list >>>> Matplotlib-devel@lists.sourceforge.net >>>> <mailto:Matplotlib-devel@lists.sourceforge.net> >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>>> >>>> >>>> >>>> >>>> -- >>>> Brian E. Granger >>>> Cal Poly State University, San Luis Obispo >>>> @ellisonbg on Twitter and GitHub >>>> bgran...@calpoly.edu <mailto:bgran...@calpoly.edu> and >>>> elliso...@gmail.com <mailto:elliso...@gmail.com> >>>> >>> >>> >> >> >> -- >> Brian E. Granger >> Cal Poly State University, San Luis Obispo >> @ellisonbg on Twitter and GitHub >> bgran...@calpoly.edu and elliso...@gmail.com >> >> >> -- >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performa
Re: [matplotlib-devel] RFC: candidates for a new default colormap
I prefer C, but am not too fond of any of them :( I wonder if it would be beneficial to give up a little on the quantitative properties of the cm in favor of moving towards something that is a bit more aesthetic and pleasant to look at. On Wed, Jun 3, 2015 at 1:47 PM, Paul Hobson wrote: > A brief poll of my office gave > 3 A's and a B. > > One of the A's came from someone who can't remember their distinct flavor > of color blindness, but definitely gets tripped up by reds and greens. > -p > > On Wed, Jun 3, 2015 at 1:29 PM, Arnd Baecker wrote: > >> In our group I also recieved quite mixed responses: >> - C B A (2 x) >> - B A C >> - A B C >> - C >> - B >> >> One collegue having anomalous color vision >> (something between protanomaly and protanopia) >> called *all* three versions "harsh" to his eye (like looking into a cars >> lights at night) and rather unpleasant. >> He considered C as the least unpleasant, but not that easy to look at. >> >> Moreover, he stated that, the parula may be flawed, but at least it >> doesn’t make one want to look away immediately. >> >> Best, Arnd >> >> >> >> >> -- >> >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > > > -- > > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Moving color overhaul forward
Great to hear this! > - re-order feature release/style change if needed >- can focus sprint effort at scipy on new features >- release order may be 2.0 -> 2.1 or 1.5 -> 2.0 > - keep style change-only release plan > - start adding color maps as named maps on master > - color map >- D seems to be leader, maybe variation on theme >- stefan is working on circular color maps > - other style changes >- adopt most of seaborn as defaults ? I think it would be good to have a set of core stylesheets in mpl that include * Slight modifications of the existing mpl theme (outward ticks?, different default cmap and color cycle) * The default seaborn style that closely follows that of ggplot2 * Stylesheets that mimic the "contexts" of seaborn I would also like to see a few more style helper methods such as despine, ticks_out/in, etc. >- start putting in style sheets as soon as possible >- may not be worth big drawn out decision, just change them >- line color cycle > - need to do something, maybe related to circular color maps > - use something from seaborn > - get time for style BoF at scipy I would love to participate in any mpl BoFs at SciPy. Also, I have a student working for me this summer and one of his focus areas will be visualization. I can likely have him work on some of the stylesheet+traitlets+nbagg stuff as part of this work. He will also be at SciPy. Cheers, Brian > > Any feed back is welcome. > > Tom > > > -- > > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] scipy sprints
I will be around and would love to participate. On Mon, Jun 22, 2015 at 5:39 AM, Thomas Caswell wrote: > Who will be around for the sprints? We should start to come up with a list > what we want to work on. There are a number of issues tagged as > 'hack-a-thon' which are good candidates for novice contributors. > > A few major projects that need attention are: > > - sorting out how to reliably find freetype everywhere (we should probably > pull in someone from enthought on this if possible as they are one of the > problem cases). This might be solved by using pkg-config everywhere? > - through review of MEP27 and the extension of MEP22 to the rest of the > interactive backends > - discussions with IPython folks about what rolling traitlets into Artist > would look like > > Tom > > -- > Monitor 25 network devices or servers for free with OpManager! > OpManager is web-based network management software that monitors > network devices and physical & virtual servers, alerts via email & sms > for fault. Monitor 25 devices for free with no restriction. Download now > http://ad.doubleclick.net/ddm/clk/292181274;119417398;o > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Important thread on IPython-dev
Thanks Eric! A bunch of us will be at SciPy this week and it would be great to talk more about this stuff with the mpl devs that are around. Cheers, Brian On Mon, Jul 6, 2015 at 12:18 PM, Eric Firing wrote: > There is a long thread on IPython-dev discussing how to make matplotlib > "just work" in a notebook without requiring "%matplotlib inline" or any > other such magic at the top. As a side topic in the thread, there are > comments as to how useful "%pylab" still is for real work. > > http://article.gmane.org/gmane.comp.python.ipython.devel/15434 > > Eric > > -- > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Running test suite with out image comparisons
Hi folks, Is it possible to run the matplotlib test suite without the image comparisons? Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Dev build on matplotlib with conda
Hi all, I am trying to get a dev build of matplotlib working with the anaconda python. Any advice on getting matplotlib to detect and use any of the libpng/freetypes: * Those installed with anaconda python. * Those from homebrew * Those that ship with OS X Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Dev build on matplotlib with conda
No I am fine linking against the stuff that ships with conda - just not clear on how to get the setup.py logic to look in the right place. On Wed, Jul 22, 2015 at 11:20 AM, Phil Elson wrote: > Are you wanting to link against anything other than that installed with > conda? > The output of setup.py is normally pretty helpful at letting you know which > library it has found to build against. > > On 20 July 2015 at 01:54, Brian Granger wrote: >> >> Hi all, >> >> I am trying to get a dev build of matplotlib working with the anaconda >> python. >> >> Any advice on getting matplotlib to detect and use any of the >> libpng/freetypes: >> >> * Those installed with anaconda python. >> * Those from homebrew >> * Those that ship with OS X >> >> Cheers, >> >> Brian >> >> -- >> Brian E. Granger >> Cal Poly State University, San Luis Obispo >> @ellisonbg on Twitter and GitHub >> bgran...@calpoly.edu and elliso...@gmail.com >> >> >> -- >> Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Dev build on matplotlib with conda
Thanks Mike. I haven't had a chance to investigate further, but when I do I will look at pkg-config... On Fri, Jul 31, 2015 at 2:26 PM, Michael Droettboom wrote: > Sorry for the delayed response. > > I had a discussion thread with Aaron Meurer last year about adding > pkg-config support to anaconda so that matplotlib would build > out-of-the-box, but I don't think that's gone anywhere. That would allow > the extensive patches in the anaconda matplotlib recipe (and probably many > other recipes for C and Unixy packages) to go away. (Note that the > "pkgconfig" Python package in Anaconda is just the Python wrapper to the > underlying Unix tool which is not present in Anaconda). > > Mike > > > On 07/22/2015 07:52 PM, Nathan Goldbaum wrote: > > One way to do this is to build a Conda package using the matplotlib recipe: > > https://github.com/conda/conda-recipes/tree/master/matplotlib > > Looking at the Conda recipe might give you some hints about how it locates > png.h as well, although I haven't checked in detail. > > On Wednesday, July 22, 2015, Brian Granger wrote: >> >> No I am fine linking against the stuff that ships with conda - just >> not clear on how to get the setup.py logic to look in the right place. >> >> On Wed, Jul 22, 2015 at 11:20 AM, Phil Elson wrote: >> > Are you wanting to link against anything other than that installed with >> > conda? >> > The output of setup.py is normally pretty helpful at letting you know >> > which >> > library it has found to build against. >> > >> > On 20 July 2015 at 01:54, Brian Granger wrote: >> >> >> >> Hi all, >> >> >> >> I am trying to get a dev build of matplotlib working with the anaconda >> >> python. >> >> >> >> Any advice on getting matplotlib to detect and use any of the >> >> libpng/freetypes: >> >> >> >> * Those installed with anaconda python. >> >> * Those from homebrew >> >> * Those that ship with OS X >> >> >> >> Cheers, >> >> >> >> Brian >> >> >> >> -- >> >> Brian E. Granger >> >> Cal Poly State University, San Luis Obispo >> >> @ellisonbg on Twitter and GitHub >> >> bgran...@calpoly.edu and elliso...@gmail.com >> >> >> >> >> >> >> >> -- >> >> Don't Limit Your Business. Reach for the Cloud. >> >> GigeNET's Cloud Solutions provide you with the tools and support that >> >> you need to offload your IT needs and focus on growing your business. >> >> Configured For All Businesses. Start Your Cloud Today. >> >> https://www.gigenetcloud.com/ >> >> ___ >> >> Matplotlib-devel mailing list >> >> Matplotlib-devel@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > >> > >> >> >> >> -- >> Brian E. Granger >> Cal Poly State University, San Luis Obispo >> @ellisonbg on Twitter and GitHub >> bgran...@calpoly.edu and elliso...@gmail.com >> >> >> -- >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > -- > > > > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > -- > > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgran...@calpoly.edu and elliso...@gmail.com -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New Employer
Congrats Mike! Sent from my iPhone > On Sep 30, 2015, at 8:18 AM, Michael Droettboom wrote: > > Just a heads up to the matplotlib developer team: > > I'm leaving Space Telescope for a new position at Continuum Analytics > starting next week. This position will be primarily to work on > matplotlib, so I should have much more time to participate than I have > in recent years. Thomas Caswell and I have already met to discuss how > we can best share some of the mountains of work that he's been doing and > help me transition to being more involved again. > > I think it bears saying, just to be clear, that Continuum in no way > change how matplotlib is run by their support of my time. It will > remain an open community project where anyone with a good idea can > participate and contribute. It is very important to me that it remains > that way, and it is very important to Continuum's leadership as well. > > Let me know if you have any questions. I really look forward to being > more involved with all the great work that's going on here! > > Cheers, > Mike > > -- > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
