Re: [matplotlib-devel] [IPython-dev] Uniform GUI support across matplotlib, ets and ipython
Hi folks,
On Sat, Aug 28, 2010 at 12:42 PM, Brian Granger wrote:
> 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.
I just wanted to ping back with this topic, both to update you a
little and to ask for help...
Brian is now using Andrew's git repo and made an mpl branch for
experimenting with the guisupport work:
http://github.com/ellisonbg/matplotlib/tree/guisupport
For now there's just one commit, but at any point in time, this URL
will easily let you compare what's new vs Andrew's trunk (which I'm
considering the canonical reference on github):
http://github.com/ellisonbg/matplotlib/compare/astraw:trunk...guisupport
Basically we're a bit stumped with GTK, and also partly with Tk. With
Tk things *seem* to work ok in light testing, but it's possible that
problems lurk. It's just that we do get something 'for free' because
python itself manages the Tk event loop.
But for GTK, no clue...
This type of code will be needed to support the multiprocess
capabilities we're developing with ipython, and for qt, wx and
(apparently, but only by chance) tk, matplotlib with the guisupport
added, works right now on IPython:
- 0.10.1 with the old -Xthread flags (just like always, rather fragile
and brittle but useful for a lot of things).
- trunk at the command-line, using --pylab {qt, wx, tk}: this uses
PyOSInputHook, which is more reliable than the --Xthread flags.
- our 'newkernel' branch with the fancy Qt widget and two process control.
So we're doing pretty good: Qt and Wx seem solid, Tk so far is cutting
us slack. But GTK is simply hosed. Brian tried and got lost, and I
don't have the foggiest clue.
So if anyone here can help us out solidify the GTK solution, as well
as point out anything that might be needed for Tk and any possible
flaws in the code for Wx/Qt, we'd be immensely grateful.
We're very, very excited about the possibilities the code we're
building in ipython opens up. But we don't want to have the massive
regression of breaking GTK support for matplotlib, and we're a bit
stuck.
Once the code in Brian's branch is tested/fixed/approved by you guys,
we'd like to propose it for merging into matplotlib. The idea is that
MPL would carry its own copy of this guisupport file, enabling it to
cooperate well with IPython or anyone else who supports this approach
(and we've talked with the IEP author --http://code.google.com/p/iep,
enthought for the Traits machinery, etc). But it would NOT create an
ipython dependency on matplotlib, nor should it break any embedded
uses in a GUI application, etc.
This stuff is hard, and Brian and I are both pretty ignorant when it
comes to GUIs, s
Re: [matplotlib-devel] [Matplotlib-users] bug? line misses points with negative coordinates
CC to matplotlib-devel & matplotlib-users 2010/9/3 Tony S Yu : > On Sep 3, 2010, at 4:33 AM, Sébastien Barthélemy wrote: > >> Hello, >> >> While using sage [1], I got problems drawing a line: for some reason, >> the points with negative coordinates are not plotted (or are plotted >> on top of others due to an offset problem and thus I cannot see them). >> I can only reproduce the bug with specific data sets. >> >> [1] www.sagemath.org >> >> I think I could track down the bug to matplotlib, which sage uses to >> render 2d plots. >> >> I included a sage script which generates the data set (in a pickle >> file), and a python script which draws the faulty line. >> >> Usage is : >> >> $ sage generate_data.sage >> $ python test_mpl.py >> >> I also included the pickled data, thus you don't need sage at all. >> I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport). >> >> Could somebody here confirm the problem, and give me a hint about what >> is going on? > > I can confirm the issue. Great, thank you. I filed a bug: https://sourceforge.net/tracker/?func=detail&aid=3058804&group_id=80706&atid=560720 > This appears to be a drawing bug: when I pan the drawing so that the negative > data touches the edge of the axes frame, the rest of the line is drawn. So > the line object is being created, but for some reason it's not being drawn > correctly. > > The bug is really finicky: if I plot starting from the 3rd value of your data > (i.e. slice xdata, ydata with [2:]), the line is drawn completely. The > strange thing is that the first 100 or so data points defines the exact same > point, so there's noting special about those first two points. (but this > overlaying of data may be related to the bug) > > I've reproduced the issue on TkAgg, Qt4Agg, and MacOSX backends, so maybe the > bug is in backend_bases. (Note: unlike Agg backends, MacOSX backend doesn't > show line even after panning the plot) > > I don't really know how to debug drawing errors like this; so this is as far > as can get. -- 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
--- 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. 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? --Michiel. -- 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
Re: [matplotlib-devel] [Matplotlib-users] bug? line misses points with negative coordinates
On Sep 3, 2010, at 10:23 AM, Sébastien Barthélemy wrote:
> CC to matplotlib-devel & matplotlib-users
>
> 2010/9/3 Tony S Yu :
>> On Sep 3, 2010, at 4:33 AM, Sébastien Barthélemy wrote:
>>
>>> Hello,
>>>
>>> While using sage [1], I got problems drawing a line: for some reason,
>>> the points with negative coordinates are not plotted (or are plotted
>>> on top of others due to an offset problem and thus I cannot see them).
>>> I can only reproduce the bug with specific data sets.
>>>
>>> [1] www.sagemath.org
>>>
>>> I think I could track down the bug to matplotlib, which sage uses to
>>> render 2d plots.
>>>
>>> I included a sage script which generates the data set (in a pickle
>>> file), and a python script which draws the faulty line.
>>>
>>> Usage is :
>>>
>>> $ sage generate_data.sage
>>> $ python test_mpl.py
>>>
>>> I also included the pickled data, thus you don't need sage at all.
>>> I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport).
>>>
>>> Could somebody here confirm the problem, and give me a hint about what
>>> is going on?
>>
>> I can confirm the issue.
>
> Great, thank you. I filed a bug:
> https://sourceforge.net/tracker/?func=detail&aid=3058804&group_id=80706&atid=560720
>
>> This appears to be a drawing bug: when I pan the drawing so that the
>> negative data touches the edge of the axes frame, the rest of the line is
>> drawn. So the line object is being created, but for some reason it's not
>> being drawn correctly.
>>
>> The bug is really finicky: if I plot starting from the 3rd value of your
>> data (i.e. slice xdata, ydata with [2:]), the line is drawn completely. The
>> strange thing is that the first 100 or so data points defines the exact same
>> point, so there's noting special about those first two points. (but this
>> overlaying of data may be related to the bug)
>>
>> I've reproduced the issue on TkAgg, Qt4Agg, and MacOSX backends, so maybe
>> the bug is in backend_bases. (Note: unlike Agg backends, MacOSX backend
>> doesn't show line even after panning the plot)
>>
>> I don't really know how to debug drawing errors like this; so this is as far
>> as can get.
I'm not sure if I should respond to this email or the bug report, but since I
made the claim here, I'll correct myself here: The bug is not in the drawing
code as I had suggested.
The bug is related to path simplification. If you turn off path simplification
(e.g. plt.rc('path', simplify=False), the line is drawn in its entirety. This
also explains why the bug disappeared when I trimmed the first two points: path
simplification is triggered from data sets with atleast 128 points (your data
has 129, so trimming two points turned off path simplification).
I just wanted to correct my earlier comments.
-T
--
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] [Matplotlib-users] bug? line misses points with negative coordinates
On 09/03/2010 09:14 AM, Tony S Yu wrote:
>
> On Sep 3, 2010, at 10:23 AM, Sébastien Barthélemy wrote:
>
>> CC to matplotlib-devel& matplotlib-users
>>
>> 2010/9/3 Tony S Yu:
>>> On Sep 3, 2010, at 4:33 AM, Sébastien Barthélemy wrote:
>>>
Hello,
While using sage [1], I got problems drawing a line: for some reason,
the points with negative coordinates are not plotted (or are plotted
on top of others due to an offset problem and thus I cannot see them).
I can only reproduce the bug with specific data sets.
[1] www.sagemath.org
I think I could track down the bug to matplotlib, which sage uses to
render 2d plots.
I included a sage script which generates the data set (in a pickle
file), and a python script which draws the faulty line.
Usage is :
$ sage generate_data.sage
$ python test_mpl.py
I also included the pickled data, thus you don't need sage at all.
I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport).
Could somebody here confirm the problem, and give me a hint about what
is going on?
>>>
>>> I can confirm the issue.
>>
>> Great, thank you. I filed a bug:
>> https://sourceforge.net/tracker/?func=detail&aid=3058804&group_id=80706&atid=560720
>>
>>> This appears to be a drawing bug: when I pan the drawing so that the
>>> negative data touches the edge of the axes frame, the rest of the line is
>>> drawn. So the line object is being created, but for some reason it's not
>>> being drawn correctly.
>>>
>>> The bug is really finicky: if I plot starting from the 3rd value of your
>>> data (i.e. slice xdata, ydata with [2:]), the line is drawn completely. The
>>> strange thing is that the first 100 or so data points defines the exact
>>> same point, so there's noting special about those first two points. (but
>>> this overlaying of data may be related to the bug)
>>>
>>> I've reproduced the issue on TkAgg, Qt4Agg, and MacOSX backends, so maybe
>>> the bug is in backend_bases. (Note: unlike Agg backends, MacOSX backend
>>> doesn't show line even after panning the plot)
>>>
>>> I don't really know how to debug drawing errors like this; so this is as
>>> far as can get.
>
> I'm not sure if I should respond to this email or the bug report, but since I
> made the claim here, I'll correct myself here: The bug is not in the drawing
> code as I had suggested.
>
> The bug is related to path simplification. If you turn off path
> simplification (e.g. plt.rc('path', simplify=False), the line is drawn in its
> entirety. This also explains why the bug disappeared when I trimmed the first
> two points: path simplification is triggered from data sets with atleast 128
> points (your data has 129, so trimming two points turned off path
> simplification).
>
> I just wanted to correct my earlier comments.
>
Tony,
Thanks--it's in a comment added to the bug report. Also, this is the
same problem as reported earlier by Jens Nie. The bug is in
path_converters.h. I think I found part of it, but a real solution may
require more than a changed line or two, and I can't spend more time on
it at the moment. Mike D. could figure it out quickly, but I think he
is not available right now.
Eric
> -T
>
>
>
> --
> 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
--
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
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. 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] clf(), Axes3D and add_subplot
On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root wrote: > I think there are multiple issues here. Primarially, there is the issue > that Axes3D is attaching itself to a figure. However, in the interest of > backwards-compatibility, we can't just fix this outright. There is also the > issue that there are multiple places in the Figure class that are adding > axes to the figure object. Ideally, shouldn't we have a single function > that performs proper checks and adds an axes? Then that function should be > used in the other class functions to perform this action. In my opinion, > there is too much duplicated code here. While I agree that we need to do something with the duplicated code, I think our priority should be fixing a bug. The easiest solution (that is backward compatible) seems to be registering an Axes class that does not add itself to the figure. For example, class Axes3DBase(Axes): # All of the original Axes3D stuff, but do not add itself to the figure during the initialization class Axes3D(Axes3DBase): def __init__(self, ...) Axes3DBase.__init__(self, ...) self.fig.add_axes(self) # And register Axes3DBase instead of Axes3D import matplotlib.projections as proj proj.projection_registry.register(Axes3DBase) Regards, -JJ -- 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. > 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 -- This SF.net D
Re: [matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx
On Fri, Sep 3, 2010 at 6:57 PM, Eric Firing wrote: > 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: > Mhh, sorry to see you burn up on this, Eric. Brian is the zmq expert, not me, but it *may* be a version compatibility issue, perhaps? I am using these versions of zmq/pyzmq: - zmq 2.0.8: http://www.zeromq.org/local--files/area:download/zeromq-2.0.8.tar.gz - pyzmq 2.0.7: http://github.com/downloads/zeromq/pyzmq/pyzmq-2.0.7.tar.gz These two worked fine for me, with: - for zmq: ./configure --prefix=$HOME/usr/opt make && make install note that $HOME/usr/opt/lib is in my LD_LIBRARY_PATH, and the include/ dir in my include path, etc. - for pyzmq: python setup.py install --prefix=$HOME/usr/opt And at that point it just worked. A few questions: - is it possible that you did a build from the head of either zmq/pyzmq git tree? that might cause an incompatibility. - could it be that /usr/local/lib isn in your LD_LIBRARY_PATH? I'll be available over the weekend and will be more than happy to try and help sort this out. Regards, and sorry for the hassle 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
