Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root wrote: > Dude, that just blew my mind! > > Awesome idea! By the way, I don't know if it was clear, but this wasn't just an idea, it's already implemented: http://fperez.org/tmp/ip-multiclient.png The two windows are talking to the same kernel, the one at the top issues the plot command, and the one at the bottom then just does 'show()' and it gets the same figure. Notice how they share a global prompt counter, since that number lives kernel-side. They're both on the same computer, but it makes no difference if they run on different hosts. This isn't anywhere near production-quality yet, but it does work. We're busy finishing the core pieces so we can spend some time polishing it for user testing. Cheers, 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Uniform GUI support across matplotlib, ets and ipython
> 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? 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. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Custom-sized and spanning subplots
Is there any development in this project. I was searching for the ways to change the subplot sizes, but could not find any easy or nicer way. -- View this message in context: http://old.nabble.com/Custom-sized-and-spanning-subplots-tp20485188p29580203.html Sent from the matplotlib - devel mailing list archive at Nabble.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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Mon, Aug 30, 2010 at 9:59 PM, Fernando Perez wrote: > On Mon, Aug 30, 2010 at 7:24 AM, Benjamin Root wrote: >> Dude, that just blew my mind! >> > > Glad you like it :) > > And needless to say, once the dust settles and someone is willing, the > obvious thing to do is to put a zeromq-http bridge and make a web > browser-based client, so you can use ipython/matplotlib from your > android/iphone/netbook/whatever. > > We've been scrupulously careful not to introduce any python > assumptions client-side, so that in principle frontends can be written > in any language or toolkit (e.g. html/javascript), the entire system > is specified by its messaging protocol: > > http://ipython.scipy.org/doc/nightly/html/development/messaging.html That'd be great. I think I either want to use regular terminal, or a worksheet in the browser. Ondrej -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Tue, Aug 31, 2010 at 1:21 PM, Ondrej Certik wrote: > > That'd be great. I think I either want to use regular terminal, or a > worksheet in the browser. You may change your mind when you start playing with the new Qt terminal :) It feels very much like a terminal, except with a ton of little useful touches that make it very effective. It still has a lot of rough edges, but Evan has done a phenomenal job there. I'm now using it as my regular ipython instead of the normal one, dogfooding enough that we hit all the key usability quirks quickly, and act on them. Cheers, 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Tue, Aug 31, 2010 at 1:25 PM, Fernando Perez wrote: > On Tue, Aug 31, 2010 at 1:21 PM, Ondrej Certik wrote: >> >> That'd be great. I think I either want to use regular terminal, or a >> worksheet in the browser. > > You may change your mind when you start playing with the new Qt > terminal :) It feels very much like a terminal, except with a ton of > little useful touches that make it very effective. It still has a lot > of rough edges, but Evan has done a phenomenal job there. I'm now > using it as my regular ipython instead of the normal one, dogfooding > enough that we hit all the key usability quirks quickly, and act on > them. Ok, I'll give it a shot then. Ondrej -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for Qt4 backend for IPython GUI
On Tue, Aug 31, 2010 at 1:55 PM, Ondrej Certik wrote: > Ok, I'll give it a shot then. As I mentioned elsewhere, getting it going is a bit rough right now. So unless you really want to play with real bleeding edge code, give us a couple of weeks. It will be much nicer then. Cheers, 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Custom-sized and spanning subplots
On Tue, Aug 31, 2010 at 2:38 AM, imsc wrote: > > Is there any development in this project. I was searching for the ways to > change the subplot sizes, but could not find any easy or nicer way. > > > -- > View this message in context: > http://old.nabble.com/Custom-sized-and-spanning-subplots-tp20485188p29580203.html > Sent from the matplotlib - devel mailing list archive at Nabble.com. > > > matplotlib version 1.0 now has a few different tools that could help you. There is GridSpec, http://matplotlib.sourceforge.net/api/gridspec_api.html# There is also AxesGrid1: http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/index.html#toolkit-axesgrid-index Maybe one of these could be what you are looking for? Ben Root -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] ANN: ThinWrap and ReMap
Hello, I have been working on a couple of interesting concoctions for matplotlib. The first is a wrapper class called "ThinWrap" that, essentially, provides a way to create objects that are linked to a given object. These objects can then be subclassed for some very interesting behaviors. Which leads me to my ReMap class. The ReMap class is designed to be a wrapper around a Colormap object, and the __call__ function is overloaded so that some other defined function can modify the rgba values that comes from a call to the original colormap object. All of this is done without modifying the original colormap. In addition, a ReMap object can wrap another ReMap object, allowing for stacking. As an example, I have created a ToGrayscale() ReMap class. For your reviewing pleasure, there are two patch files. The first, thinwrap.patch, adds the ThinWrap class to cbook.py. The second, remap.patch, creates a new file "remap.py" that holds the ReMap class and the ToGrayscale class. In addition, in order for things to work, a few changes had to be made to other code: cm.py: get_cmap() could finish the function without returning anything. I modified it to remove the "isinstance" check that would cause non-Colormap/non-string objects to fall into a black hole. We are gonna have to follow duck-typing here... colors.py: The Colormap class needs to be a new-style class for ReMap to work properly contour.py: Commented out code that did a isinstance() check on the cmap that would cause ReMaps on contours to fail. I have also included an example script to demonstrate how this wrapper class works and the ToGrayscale() class works. Let me know what you think! Ben Root diff --git a/lib/matplotlib/cbook.py b/lib/matplotlib/cbook.py index 7c90867..19a078a 100644 --- a/lib/matplotlib/cbook.py +++ b/lib/matplotlib/cbook.py @@ -1783,6 +1783,106 @@ def is_math_text(s): return even_dollars +class ThinWrap(object) : +""" +The ThinWrap class is a way to produce modified interfaces +to an object while still maintaining the original object. + +An example use case is the ReMap class in colors.py. The ReMap +class takes a colormap object and intercepts its __call__() function. +This allows for a remapping function to modify the returned rgba values. +Meanwhile, any access to the attributes and functions of the original +colormap object through the wrapper will just get passed onto the +original colormap. + +So long as the code honors duck-typing, you can pass this ThinWrapper +class down into the code and it will be none the wiser. +""" +def __init__(self, origobj) : +""" +Create a thin wrapper around `origobj`. +`origobj` must be a new style python class object (or must have +__getattribute__ defined. +""" +# We have to use the baseclass's get and set to avoid recursion. +object.__setattr__(self, '_origobj', origobj) + +def __getattr__(self, attr) : +""" +Any attribute request/function request that can't be found +by normal means will come to this function. +Those requests will be passed along to the _origobj. +""" +return object.__getattribute__(self, '_origobj').__getattribute__(attr) + + +def __getattribute__(self, attr) : +""" +Other methods of accessing an attribute uses __getattribute__. +In this case, we will attempt to access the attribute in this +object. Upon failing, we then fall back to accessing the attribute +in the _origobj. +This is necessary for subclassed objects that have their own functions +that need to be used, I believe. +""" +try : +return object.__getattribute__(self, attr) +except AttributeError : +return object.__getattribute__(self, '_origobj').__getattribute__(attr) + + +def __setattr__(self, attr, value) : +""" +Any request for setting an attribute will first be checked +to see if the attribute already exist in the dictionary. +If it isn't in there, then it will pass along the set +request to the _origobj. + +To help understand the idea, consider the following: + +>>> class Foo(object) : +>>> def __init__(self, x, y) : +>>> self.x = x +>>> self.y = y +>>> +>>> a = Foo(22, 'bar') +>>> b = ThinWrap(a) +>>> print "a attribs - x: %dy: %s" % (a.x, a.y) +'a attribs - x: 22y: bar' +>>> print "b attribs - x: %dy: %s" % (b.x, b.y) +'b attribs - x: 22y: bar' +>>> +>>> b.x = 42 +>>> print "a attribs - x: %dy: %s" % (a.x, a.y) +'a attribs - x: 42y: bar' +>>> print "b attribs - x: %dy: %s" % (b.x, b.y) +'b attribs - x: 22y: bar' +>>> +>>> a.y = 'foo' +>>> print "a
Re: [matplotlib-devel] Apparent bug with EPS files using Liberation fonts
On Mon, Aug 30, 2010 at 10:48 AM, Stan West wrote: > Greetings. The attached script saves three EPS files (also attached) of a > figure containing a text object using the Liberation Sans font. In the three > EPS files, the text object contains no spaces, a normal space, and a > non-breaking space, respectively. Ghostscript handles the first and third > files but not the second, for which it gives the message "Error: /undefined > in --get--" at the Postscript "show" instruction for the text. I noticed > that the second file embeds a character for the non-breaking space "uni00A0" > but not the normal space, so I suppose that's why the error is occurring. I > tried a few other fonts and did not see any problems. I have matplotlib v. > 1.0.0, Python 2.6.5, and Liberation fonts 1.06.0.20100721. Would someone > kindly look into whether this might be a bug with matplotlib or the > Liberation fonts? Many thanks! > > I can confirm that evince also has a problem with the second image, but not the first or the third images. This is using the latest matplotlib from svn. The error from evince is very non-descriptive: undefined -21 ** (evince:3597): WARNING **: Error rendering thumbnail undefined -21 Ben Root -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
