matplotlib-devel Mailing List for matplotlib

On Mon, Sep 13, 2010 at 2:22 PM, Gökhan Sever <gok...@gm...> wrote:
>
> Either in Firefox or Chrome you could use extensions [Auto Copy] to copy
> text selections into clipboard.
Thanks, that's good to know. But I'm mostly thinking of teaching
situations, so it would be nice to have this in the source: it's not
for my use but for the benefit of students who may be in a lab where
they can't install extensions. But I don't know if that can even be
done in html in the first place.
Cheers,
f

On Tue, Aug 31, 2010 at 9:08 PM, Benjamin Root <ben...@ou...> wrote:
> 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
>
Just reping-ing this. I haven't heard anything negative and got a few
positive comments off-list. I haven't committed this yet because I am
concerned about the implications of my changes to cm.py, colors.py and
contour.py. However, if I don't hear any concerns over the next couple of
days, shall I assume that it is ok to go ahead and commit?
Ben Root

Hi Fernando,
On Mon, Sep 13, 2010 at 3:58 PM, Fernando Perez <fpe...@gm...>wrote:
> Hi folks,
>
> 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...
>
Either in Firefox or Chrome you could use extensions [Auto Copy] to copy
text selections into clipboard.
-- 
Gökhan

Fernando,
On Mon, Sep 13, 2010 at 1:58 PM, Fernando Perez <fpe...@gm...> 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 console....100 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: </g>.
> Location: file:///home/fperez/ipython/ipython/bad.svg
> Line Number 287, Column 3:</svg>
> --^
>
> 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
> IPy...@sc...
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...

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.
- 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: </g>.
Location: file:///home/fperez/ipython/ipython/bad.svg
Line Number 287, Column 3:</svg>
--^
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...
Anyway, I think we're starting to be in pretty good shape!
Cheers,
f

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 <ef...@ha...> wrote:
> On 09/07/2010 11:07 AM, Fernando Perez wrote:
>> Hi Eric,
>>
>> On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing<ef...@ha...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgr...@ca...
ell...@gm...