You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
1
(5) |
2
(23) |
3
(17) |
4
(14) |
5
(12) |
6
(2) |
7
(3) |
8
(7) |
9
(13) |
10
(19) |
11
(24) |
12
(28) |
13
(9) |
14
(5) |
15
(7) |
16
(17) |
17
(17) |
18
(15) |
19
(6) |
20
|
21
(7) |
22
(20) |
23
(6) |
24
(4) |
25
(5) |
26
(11) |
27
(1) |
28
(2) |
29
(14) |
30
(7) |
|
|
|
|
From: Marc P. <pet...@ya...> - 2010-11-16 14:27:07
|
Hi, is there a solution for using matplotlib within pyside like it is possible with pyqt4? Greetz Marc |
From: Michael D. <md...@st...> - 2010-11-16 14:03:55
|
Thanks. With this new script, I get only one failure: xpdf_False This is on RHEL5 x86_64: gs 8.15.2 gv 3.6.8 pdftops 3.00 Cheers, Mike On 11/16/2010 06:54 AM, Jae-Joon Lee wrote: > On Mon, Nov 15, 2010 at 11:29 PM, Michael Droettboom<md...@st...> wrote: > >> How do I verify if the bbox is correct? Displaying them with gs, some of them have the plot centered on what looks to be a letter-sized page, and others are at the bottom, but none of them seem to be cropped. I'm happy to give a full detailed report, just not sure what I'm looking for in terms of right/wrong ;) >> >> Thanks, >> Mike >> >> > Michael, > > Here is a slightly modified example. > > import matplotlib.pyplot as plt > > fig = plt.figure() > plt.plot([0, 1, 1, 0], [0, 0, 1, 1], "ro", ms=10, transform=fig.transFigure, > clip_on=False) > > for distiller in ["False", "xpdf", "ghostscript"]: > for usetex in ["True", "False"]: > plt.rcParams["ps.usedistiller"]=distiller > plt.rcParams["text.usetex"]=usetex > > plt.savefig("test_bbox_%s_%s.eps" % (distiller, usetex)) > > With this, you should see four red circles (a quadrant of a circle) at > the four corner of page boundaries. > I don't think "gs" is a right tool to test if the bbox is correct. My > experience is that it often ignores the bbox. On linux, you may use > "gv", "evince", or "okular". > > Regards, > > JJ > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA |
From: Ian B. <ib...@pu...> - 2010-11-16 01:52:08
|
All, I have experience getting MPL working with wx backend with py2exe, and I have sucessfully packaged and delivered py2exe executables (email me if you would like a copy of the setup.py file that worked for me). I have decided to switch my main development from wx to GTK since Glade is so much easier to use (and get support for) than wxGlade. Now my main problem is getting GTK to play nicely with MPL and py2exe. So far Ive had no luck. The program runs perfectly when not packaged into an executable FWIW. I copied my setup.py file at the end of the email. Perhaps someone has an idea. I import MPL with import matplotlib matplotlib.use('GTKAgg') which immediately spits out an error: (GTKAPP.exe:4188): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file 'gtk-2.0\gdk-pixbuf.loaders': No such file or directory I tried to follow the recommendations of http://www.py2exe.org/index.cgi/Py2exeAndPyGTK with moving the etc, share, lib folders to the dist folder and I even in desperation added the etc, share and lib folders to the path prior to importing MPL. No dice. Any thoughts? My setup.py that doesn't work with GTKAgg: from distutils.core import setup import py2exe excludes = ['_tkagg', '_wxagg','_wx','_cocoaagg','_fltkagg','bsddb', 'curses', 'pywin.debugger', 'pywin.debugger.dbgcon', 'pywin.dialogs', 'tcl', 'Tkconstants', 'Tkinter', 'pydoc', 'doctest', 'test', 'sqlite3', 'projections','Tcl','PyQT4','qt','backend_qt','backend_qt4','backend_qt4agg', 'backend_qtagg','backend_cairo','backend_cocoaagg','wx','scipy.sparse' ] dll_excludes = ['QTGui4.dll','QtCore4.dll','tk85.dll','tcl85.dll'] data_files=['CurveFit.ui',] packages = ['pygtk','matplotlib','encodings','gtk'] includes = ['cairo','pangocairo','atk','gobject','pango'] import matplotlib as mpl data_files += mpl.get_py2exe_datafiles() setup( name = 'FitTool', description = 'CurveFittingTool', version = '0.1', console = [ { 'script': 'GTKAPP.py', } ], options = {"py2exe": {"compressed": 2, "optimize": 2, "excludes": excludes, "packages": packages, "includes": includes, "dll_excludes": dll_excludes, # using 2 to reduce number of files in dist folder # using 1 is not recommended as it often does not work "bundle_files": 2, "dist_dir": 'dist', "xref": False, "skip_archive": False, "ascii": False, "custom_boot_script": '', } }, # using zipfile to reduce number of files in dist zipfile = r'libFiles\library.zip', data_files=data_files ) ---- Ian Bell Graduate Research Assistant Herrick Labs Purdue University email: ib...@pu... cell: (607)227-7626 |
From: Jae-Joon L. <lee...@gm...> - 2010-11-16 00:40:06
|
You may use annotate. annotate("Test", xy=(0.5, 0.3), xycoords=("axes fraction", "data"), ha="center") This requires v1.0 of matplotlib. http://matplotlib.sourceforge.net/users/annotations_guide.html#using-complex-coordinate-with-annotation Regards, -JJ |
From: Benjamin R. <ben...@ou...> - 2010-11-16 00:27:56
|
On Mon, Nov 15, 2010 at 1:40 PM, <dav...@ub...> wrote: > Hi > > > > I’d like to place a piece of text that shows the start of some data so I > want data coords in the x direction and axis coords in the y – e.g. float > with a particular x value and center in the screen on the y. > > > > Do I need to implement a new object or can I mix transforms in this manner? > > > > Many thx > > > > David > > I believe "Blended" transformations is what you are looking for: http://matplotlib.sourceforge.net/users/transforms_tutorial.html#blended-transformations Haven't tried it myself, but the description seems right. Ben Root |
From: Filipe P. A. F. <oc...@gm...> - 2010-11-15 23:02:25
|
Since you are using OpenSuse, (and If you are brave enough) you can add my REPO and use the latest version of matplolib: http://download.opensuse.org/repositories/home:/ocefpaf/openSUSE_11.3/ I compile the svn version every week there. Filipe. On Mon, Nov 15, 2010 at 13:45, Michael Droettboom <md...@st...> wrote: > Since their package is crashing, I would report this bug against OpenSUSE's python-matplotlib package. > > If that doesn't get you any response, it would be helpful to get a better idea of where it is failing. Can you provide a gdb backtrace? > > Mike > > ------------------------------------------------------------------------------ > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > client virtualization framework. Read more! > http://p.sf.net/sfu/dell-eql-dev2dev > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > |
From: Chloe L. <ch...@be...> - 2010-11-15 20:10:48
|
I think the pretty-fying done in the Colorbar class will make this harder; at least, twiny on an existing colorbar doesn't work (overwrites original ticks); having two colorbars works fine but wastes space; and adding a spine had surprising side-effects (changed the color range!). I would guess that you want a custom Colorbar class, with a different offset for a second set of ticks. note that in colorbar.py, there's some code specific to CountourSets. &C On Nov 15, 2010, at 15 Nov, 8:22 AM, Daniel Welling wrote: > Greetings. > > I am making some contour plots and in my field for this particular > value, there are two widely used units. As such, it is very useful > to have both units listed on the colorbar. To clarify: the > colorbar's normal ticks would be facing to the right and labeled > with Unit Type 1, which was the units that the data were in when > they were plotted. Unit Type 2 is simply a factor of X different > than unit type two. It would be nice if I could add a second set of > ticks to the color bar using a different locator and have them face > left. Is this possible? Is there another way to display two values > for each tick such that the colorbar shows both units? > > Thanks. > -dw > ------------------------------------------------------------------------------ > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > client virtualization framework. Read more! > http://p.sf.net/sfu/dell-eql-dev2dev_______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users Chloe Lewis Ecosystem Sciences, Policy and Management, UC Berkeley 137 Mulford Hall Berkeley, CA 94720-3114 http://nature.berkeley.edu/~chlewis |
From: <dav...@ub...> - 2010-11-15 19:40:50
|
Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS Limited is a company limited by shares incorporated in the United Kingdom registered in England and Wales with number 2035362. Registered office: 1 Finsbury Avenue, London EC2M 2PP. UBS Limited is authorised and regulated by the Financial Services Authority. UBS AG is a public company incorporated with limited liability in Switzerland domiciled in the Canton of Basel-City and the Canton of Zurich respectively registered at the Commercial Registry offices in those Cantons with Identification No: CH-270.3.004.646-4 and having respective head offices at Aeschenvorstadt 1, 4051 Basel and Bahnhofstrasse 45, 8001 Zurich, Switzerland. Registered in the United Kingdom as a foreign company with No: FC021146 and having a UK Establishment registered at Companies House, Cardiff, with No: BR 004507. The principal office of UK Establishment: 1 Finsbury Avenue, London EC2M 2PP. In the United Kingdom, UBS AG is authorised and regulated by the Financial Services Authority. UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases. |
From: Michael D. <md...@st...> - 2010-11-15 18:45:32
|
Since their package is crashing, I would report this bug against OpenSUSE's python-matplotlib package. If that doesn't get you any response, it would be helpful to get a better idea of where it is failing. Can you provide a gdb backtrace? Mike |
From: Kurt M. <kur...@su...> - 2010-11-15 18:28:48
|
Hi, Since upgrading to SUSE 11.3 matplotlib simply craches (segfault on dlopen("/usr/lib/python2.6/site-packages/matplotlib/_path.so", 2); > python -V Python 2.6.5 > uname -a Linux mcp20 2.6.34.7-0.5-default #1 SMP 2010-10-25 08:40:12 +0200 i686 i686 i386 GNU/Linux I did a 1-Click Installation from http://software.opensuse.org. http://software.opensuse.org/search/download?base=openSUSE%3A11.3&file=devel%3A%2Flanguages%3A%2Fpython%2FopenSUSE_11.3%2Fi586%2Fpython-matplotlib-1.0.0-2.9.i586.rpm&query=python-matplotlib So I have python-matplotlib-1.0.0-2.9.i586.rpm When I do: python -v -c "import matplotlib.figure" ... import matplotlib.docstring # precompiled from /usr/lib/python2.6/site-packages/matplotlib/docstring.pyc # /usr/lib/python2.6/site-packages/matplotlib/transforms.pyc matches /usr/lib/python2.6/site-packages/matplotlib/transforms.py import matplotlib.transforms # precompiled from /usr/lib/python2.6/site-packages/matplotlib/transforms.pyc dlopen("/usr/lib/python2.6/site-packages/matplotlib/_path.so", 2); Speicherzugriffsfehler (means "Segfault") The same is when I do: python -v -c "from pylab import *" mport matplotlib.docstring # precompiled from /usr/lib/python2.6/site-packages/matplotlib/docstring.pyc # /usr/lib/python2.6/site-packages/matplotlib/transforms.pyc matches /usr/lib/python2.6/site-packages/matplotlib/transforms.py import matplotlib.transforms # precompiled from /usr/lib/python2.6/site-packages/matplotlib/transforms.pyc dlopen("/usr/lib/python2.6/site-packages/matplotlib/_path.so", 2); Speicherzugriffsfehler I googled around. Some Chaco users seems to have similar problems. But for now I have no idea what to do next. Please, somebody be so kind and give me some hint. Have a nice day. -- Kurt Müller, mu...@pr... |
From: Daniel W. <dan...@gm...> - 2010-11-15 16:23:07
|
Greetings. I am making some contour plots and in my field for this particular value, there are two widely used units. As such, it is very useful to have both units listed on the colorbar. To clarify: the colorbar's normal ticks would be facing to the right and labeled with Unit Type 1, which was the units that the data were in when they were plotted. Unit Type 2 is simply a factor of X different than unit type two. It would be nice if I could add a second set of ticks to the color bar using a different locator and have them face left. Is this possible? Is there another way to display two values for each tick such that the colorbar shows both units? Thanks. -dw |
From: Guy G. <guy...@re...> - 2010-11-15 10:14:50
|
On Friday 12 Nov 2010 15:20:43 Ryan May wrote: > On Fri, Nov 12, 2010 at 8:40 AM, Benjamin Root <ben...@ou...> wrote: > > On Fri, Nov 12, 2010 at 5:11 AM, Guy Griffiths > > <guy...@re...> > > > > wrote: > >> Hi, > >> > >> I've been using matplotlib for a while for plotting scientific data, and > >> recently upgraded from version 0.99.1.1 to 1.0.0. Primarily I use > >> pcolor to > >> produce plots of concentration in 2D space. I use reasonably fine > >> meshes, and > >> in v0.99.1.1 the output looked great. > >> > >> In v1.0.0, all of my plots (using the same code) have faint gridlines > >> visible. > >> Since the mesh I am using is quite fine, this makes the plots look > >> terrible > >> (i.e. more gridlines than actual data). This seems to be controlled by > >> the > >> "edgecolors" keyword, but even when set to 'none' they are still there. > >> Is > >> there any way to remove them completely without reverting back to > >> 0.99.1.1 (which I'd prefer not to do, since some of the API changes are > >> really useful > >> for creating very polished graphs suitable for publication)? > >> > >> imshow seems to have closer results to what I want (i.e. no gridlines), > >> but > >> with imshow, the axes denote the pixel position, and there is no option > >> to display on polar axes (which is essential). > >> > >> Any help would be much appreciated. > >> > >> Regards, > >> > >> Guy Griffiths > > > > Guy, I have noticed something similar a few months ago with pcolor, but I > > am not certain if it is the same problem as yours. First, which backend > > are you using? Second, are you seeing the grid lines in both the figure > > window and the saved output? Also, what format are you saving your > > output to? Lastly, which pcolor function are you using (pcolor(), > > pcolormesh(), pcolorfast())? > > > > If you could include a screenshot or the saved file, I could see if it is > > similar to my problem. > > Yeah, I had noticed a problem with pcolor too. You can see the problem > I've been seeing here: > > http://matplotlib.sourceforge.net/examples/pylab_examples/pcolor_demo.html > > Calling pcolor with antialiased=False removes the lines, but that's > just a workaround, not a solution. I'm not really sure where to start > to track this down, so if anyone has a suggestion, I'm all ears. > > Ryan Hi, Thanks for the help. The problem I'm seeing is as Ryan describes (same effect as in the screenshot, but let me know if you still want me to provide an example), and appears in both the figure window and saved output (at least png and pdf). The backend I am using is Qt/Agg. I was using pcolor(), but it appears that pcolormesh() doesn't (always) have this problem. Setting antialiased=False removes some of the problems. In summary: pcolor(), antialiased=True - lines on screen, png, pdf pcolor(), antialiased=False - lines on pdf, fine on png/screen pcolormesh() - lines on pdf, fine on png/screen Regards, Guy |
From: Kornél J. <kja...@gm...> - 2010-11-14 23:18:04
|
Hello, I would like to plot the polarization state of a two-dimensional vector field (linear, circular or generally elliptic), similarly to that seen on this ZEMAX plot: http://www.zemax.com/UserFiles/Image/UI/pol_pupil.gif It looks like some kind of enhanced quiver plot: a small line with arrows at both ends points out the local direction of linear polarization, while a directed ellipse with a given orientation of its axes depicts local elliptical polarization state (which becomes a circle for circular polarization). I am a novice matplotlib user, please give me some advice on how to start with implementing such a plot (what to read, API examples to look at etc.) Thanks, Kornel JAHN |
From: Benjamin R. <ben...@ou...> - 2010-11-14 02:59:33
|
On Sat, Nov 13, 2010 at 7:58 PM, Michiel de Hoon <mjl...@ya...>wrote: > Thanks for your reply. > > Regarding your first question, how exactly does it disrupt your workflow? > Is it because the drawing takes too much time? Or because the focus switches > from the terminal window to the figure window? Or because the figure takes > up screen space? > > It is partly because the focus switches from the terminal window to the figure window (at least, at fiirst it does), but mostly because there isn't enough screen real estate for both to co-exist. Therefore, I would be alt-tabbing a lot if I am in interactive mode. Anyway, I mostly work from the perspective of running scripts and larger programs to generate publication quality figures and to perform data analyses. My focus is not on messing around with my figures. The only time I am doing that is when I am developing and testing a new script or feature, in which case I might go into interactive mode to figure out what settings and such make my figures look nice, or maybe not. It is nice to have the option to suit my needs. More often than not, I am in non-interactive mode. I see no reason to remove this feature as it puts matplotlib ahead of other systems like Matlab. Choice is a good thing... Ben Root |
From: Michiel de H. <mjl...@ya...> - 2010-11-14 01:58:36
|
Thanks for your reply. Regarding your first question, how exactly does it disrupt your workflow? Is it because the drawing takes too much time? Or because the focus switches from the terminal window to the figure window? Or because the figure takes up screen space? Regarding the OP, my understanding is that the original issue is that with interactive=False, the MacOSX backend pops up a window while the other backends do not. It doesn't make a difference in running time, but anyway the different backends should behave the same way, so something needs to be done here. --Michiel. --- On Sat, 11/13/10, Benjamin Root <ben...@ou...> wrote: I would like to cast a vote of support for the "interactive=False" setting. I often do work on my netbook, and having a figure window pop up while I am testing out some commands disrupts my workflow. ... On the issue about the OP, I am a little bit confused as to what the exact issue is at hand. Is it that a figure window pops up in macosx backend regardless of the interactive setting? Or is it that non-macosx backends are not behaving the same way on a mac as they do on other systems? Is the issue that the plot window is blank on the macosx backend until the script finishes? I guess I am a little confused here. |
From: Michiel de H. <mjl...@ya...> - 2010-11-14 01:50:34
|
Thanks for your reply. --- On Sat, 11/13/10, Eric Firing <ef...@ha...> wrote: > In the gtk backend, draw_idle calls gobject.idle_add > > Thus, "idle" means the gui event loop has no higher > priority events. Is > this condition reached only at the end of the script? With Python, there is only one thread (running both Python and the GUI). So the GUI event loop won't start until the end of the script, so there is no inadvertent redrawing regardless of interactive being True or False. With ipython, I am not sure if they are using one thread, or one thread for Python and one thread for the GUI. But in practice, in ipython I also don't find any evidence of inadvertent redrawing. For example, this script: import matplotlib matplotlib.use("gtkagg") import matplotlib.pyplot as plt import numpy x = numpy.random.random(400000) y = x + numpy.random.random(400000) plt.figure() plt.hexbin(x, y, gridsize=300) for i in range(1000): plt.xlabel('a label') plt.show() both with python and ipython take an equal amount of time regardless of interactive being True or False. If there were any redrawing after each call to plt.xlabel, this script would take forever. > Reminder: the interactive setting controls > draw_if_interactive, which is > what we are talking about here, but also whether or not > show() blocks. > So we may not need draw_if_interactive, but unless we can > dispense with > show entirely, we will still need an interactive setting. If matplotlib were always interactive, then I don't see a good reason for non-blocking show(). > Returning to the issue raised by the OP, however, the > question is > whether the present MacOSX behavior (windows pop up) or the > non-MacOSX > behavior (they don't in non-interactive mode until/unless > show() is > called) is what we really want. It seems to me that > we should preserve > some way of getting this second behavior. I agree. For example, if a user wants to make a figure for the sole purpose of creating a PNG file, there should be a way to do this without the figure popping up as a window. --Michiel. |
From: Benjamin R. <ben...@ou...> - 2010-11-14 00:12:00
|
On Sat, Nov 13, 2010 at 12:06 PM, Eric Firing <ef...@ha...> wrote: > On 11/13/2010 06:16 AM, Michiel de Hoon wrote: > > --- On Sat, 11/13/10, John Hunter<jd...@gm...> wrote: > >> Ie if we have a script like > >> > >> # some plotting commands > >> ... > >> > >> # some expensive non GUI computation > >> ... > >> > >> # some update to plot above > >> ... > >> > >> Would we not run the risk that the GUI is idle in the non > >> GUI computation and therefore trigger a draw in it's thread, > >> and then do redraws again after the update code? > > > > In the MacOSX backend, everything is single-threaded, so this won't > occur. > > > > I am not sufficiently familiar with the non-MacOSX backends to give a > detailed answer, but with multiple threads the "idle" refers to the Python > thread being idle rather than the GUI thread being idle. In other words, > when there are no more Python commands left to be handled, the GUI thread is > notified that it should start redrawing. > > > > In the gtk backend, draw_idle calls gobject.idle_add > > http://www.pygtk.org/pygtk2reference/gobject-functions.html#function-gobject--idle-add > > Thus, "idle" means the gui event loop has no higher priority events. Is > this condition reached only at the end of the script? > > > >> Are you proposing that we can get rid of the interactive setting > >> entirely, always call draw on pyplot commands, and let the > >> idle handler save us from doing repeated draws? > > Reminder: the interactive setting controls draw_if_interactive, which is > what we are talking about here, but also whether or not show() blocks. > So we may not need draw_if_interactive, but unless we can dispense with > show entirely, we will still need an interactive setting. > > Returning to the issue raised by the OP, however, the question is > whether the present MacOSX behavior (windows pop up) or the non-MacOSX > behavior (they don't in non-interactive mode until/unless show() is > called) is what we really want. It seems to me that we should preserve > some way of getting this second behavior. > > Eric > > > > > Yes (I assume you mean to always call draw_idle on pyplot commands). If > there are then still cases where we do get repeated draws, then that is a > bug. > > > > Best, > > --Michiel. > > > > I would like to cast a vote of support for the "interactive=False" setting. I often do work on my netbook, and having a figure window pop up while I am testing out some commands disrupts my workflow. When I want to see all my figures, I will call show() when I am good and ready. And just as I often do work on my netbook, I also do plenty of work on my workstation which sports a large screen. In many cases on that machine, I would like to see my figures while I am working on them, and having an easy option to turn that on and off is valuable to me. interactive : False was one of several reasons why I switched from Matlab to matplotlib. On the issue about the OP, I am a little bit confused as to what the exact issue is at hand. Is it that a figure window pops up in macosx backend regardless of the interactive setting? Or is it that non-macosx backends are not behaving the same way on a mac as they do on other systems? Is the issue that the plot window is blank on the macosx backend until the script finishes? I guess I am a little confused here. Ben Root |
From: Eric F. <ef...@ha...> - 2010-11-13 18:06:47
|
On 11/13/2010 06:16 AM, Michiel de Hoon wrote: > --- On Sat, 11/13/10, John Hunter<jd...@gm...> wrote: >> Ie if we have a script like >> >> # some plotting commands >> ... >> >> # some expensive non GUI computation >> ... >> >> # some update to plot above >> ... >> >> Would we not run the risk that the GUI is idle in the non >> GUI computation and therefore trigger a draw in it's thread, >> and then do redraws again after the update code? > > In the MacOSX backend, everything is single-threaded, so this won't occur. > > I am not sufficiently familiar with the non-MacOSX backends to give a detailed answer, but with multiple threads the "idle" refers to the Python thread being idle rather than the GUI thread being idle. In other words, when there are no more Python commands left to be handled, the GUI thread is notified that it should start redrawing. > In the gtk backend, draw_idle calls gobject.idle_add http://www.pygtk.org/pygtk2reference/gobject-functions.html#function-gobject--idle-add Thus, "idle" means the gui event loop has no higher priority events. Is this condition reached only at the end of the script? >> Are you proposing that we can get rid of the interactive setting >> entirely, always call draw on pyplot commands, and let the >> idle handler save us from doing repeated draws? Reminder: the interactive setting controls draw_if_interactive, which is what we are talking about here, but also whether or not show() blocks. So we may not need draw_if_interactive, but unless we can dispense with show entirely, we will still need an interactive setting. Returning to the issue raised by the OP, however, the question is whether the present MacOSX behavior (windows pop up) or the non-MacOSX behavior (they don't in non-interactive mode until/unless show() is called) is what we really want. It seems to me that we should preserve some way of getting this second behavior. Eric > > Yes (I assume you mean to always call draw_idle on pyplot commands). If there are then still cases where we do get repeated draws, then that is a bug. > > Best, > --Michiel. > |
From: Michiel de H. <mjl...@ya...> - 2010-11-13 16:16:39
|
--- On Sat, 11/13/10, John Hunter <jd...@gm...> wrote: > Ie if we have a script like > > # some plotting commands > ... > > # some expensive non GUI computation > ... > > # some update to plot above > ... > > Would we not run the risk that the GUI is idle in the non > GUI computation and therefore trigger a draw in it's thread, > and then do redraws again after the update code? In the MacOSX backend, everything is single-threaded, so this won't occur. I am not sufficiently familiar with the non-MacOSX backends to give a detailed answer, but with multiple threads the "idle" refers to the Python thread being idle rather than the GUI thread being idle. In other words, when there are no more Python commands left to be handled, the GUI thread is notified that it should start redrawing. > Are you proposing that we can get rid of the interactive setting > entirely, always call draw on pyplot commands, and let the > idle handler save us from doing repeated draws? Yes (I assume you mean to always call draw_idle on pyplot commands). If there are then still cases where we do get repeated draws, then that is a bug. Best, --Michiel. |
From: John H. <jd...@gm...> - 2010-11-13 15:49:03
|
On Sat, Nov 13, 2010 at 9:23 AM, Michiel de Hoon <mjl...@ya...> wrote: > Thanks for your reply. > But nowadays drawing is done through draw_idle, so we don't trigger additional drawing even if interactive is True. In your example, if run as a script, there is no drawing until a call to show() is made, regardless of whether interactive is True or False. I see. I wasn't appreciating your point and had neglected to consider the idle drawing handling. Are we sure this will save us. Ie if we have a scirpt like # some plotting commands ... # some expensive non GUI computation ... # some update to plot above ... Would we not run the risk that the GUI is idle in the non GUI computation and therefore trigger a draw in it's thread, and then do redraws again after the update code? I did run some tests and confirmed what you said, that with the idle handling the repeat calls to pyplot commands did not generate extra calls (except in qtagg in which I suspect the idle handling has not been implemented. Are you proposing that we can get rid of the interactive setting entirely, always call draw on pyplot commands, and let the idle handler save us from doing repeated draws? |
From: Michiel de H. <mjl...@ya...> - 2010-11-13 15:23:29
|
Thanks for your reply. But nowadays drawing is done through draw_idle, so we don't trigger additional drawing even if interactive is True. In your example, if run as a script, there is no drawing until a call to show() is made, regardless of whether interactive is True or False. Best, --Michiel. --- On Sat, 11/13/10, John Hunter <jd...@gm...> wrote: > From: John Hunter <jd...@gm...> > Subject: Re: [Matplotlib-users] Mac OSX backend > To: "Michiel de Hoon" <mjl...@ya...> > Cc: "mdekauwe" <mde...@gm...>, mat...@li... > Date: Saturday, November 13, 2010, 9:22 AM > On Sat, Nov 13, 2010 at 7:46 AM, > Michiel de Hoon <mjl...@ya...> > wrote: > > OK, thanks. With your example, I see a difference > between the Mac OS X backend and the TKAgg/GtkAgg backend > but only if interactive is False in matplotlibrc. If > interactive is True, both the Mac OS X backend and the TkAgg > backend open windows. Is this really the desired behavior? > It seems counterintuitive that such a global parameter can > determine whether a figure is opened or not. > > > > While we're on the topic, is this interactive > parameter still needed in matplotlib? In my understanding, > in older versions of matplotlib, interactive=False could > significantly speed up some plots. But are there still any > such cases with the current organization of the drawing code > in matplotlib? > > > Yes, this is the desired behavior. The interactive : > True parameter > is useful when working interactively from the shell, when > want to do > > plt.figure() > plt.plot([1,2,3]) > plt.xlabel('a label') > > and have the figure show up on the figure call and update > on the plot > and xlabel call. This is most definitely not what you > want to do in a > script, because you don't want to pay for the draw until > the end (when > a call to show is made). This is discussed at > > http://matplotlib.sourceforge.net/users/shell.html > > JDH > |
From: John H. <jd...@gm...> - 2010-11-13 14:22:48
|
On Sat, Nov 13, 2010 at 7:46 AM, Michiel de Hoon <mjl...@ya...> wrote: > OK, thanks. With your example, I see a difference between the Mac OS X backend and the TKAgg/GtkAgg backend but only if interactive is False in matplotlibrc. If interactive is True, both the Mac OS X backend and the TkAgg backend open windows. Is this really the desired behavior? It seems counterintuitive that such a global parameter can determine whether a figure is opened or not. > > While we're on the topic, is this interactive parameter still needed in matplotlib? In my understanding, in older versions of matplotlib, interactive=False could significantly speed up some plots. But are there still any such cases with the current organization of the drawing code in matplotlib? Yes, this is the desired behavior. The interactive : True parameter is useful when working interactively from the shell, when want to do plt.figure() plt.plot([1,2,3]) plt.xlabel('a label') and have the figure show up on the figure call and update on the plot and xlabel call. This is most definitely not what you want to do in a script, because you don't want to pay for the draw until the end (when a call to show is made). This is discussed at http://matplotlib.sourceforge.net/users/shell.html JDH |
From: Michiel de H. <mjl...@ya...> - 2010-11-13 13:46:13
|
OK, thanks. With your example, I see a difference between the Mac OS X backend and the TKAgg/GtkAgg backend but only if interactive is False in matplotlibrc. If interactive is True, both the Mac OS X backend and the TkAgg backend open windows. Is this really the desired behavior? It seems counterintuitive that such a global parameter can determine whether a figure is opened or not. While we're on the topic, is this interactive parameter still needed in matplotlib? In my understanding, in older versions of matplotlib, interactive=False could significantly speed up some plots. But are there still any such cases with the current organization of the drawing code in matplotlib? Thanks, --Michiel. --- On Fri, 11/12/10, John Hunter <jd...@gm...> wrote: > From: John Hunter <jd...@gm...> > Subject: Re: [Matplotlib-users] Mac OSX backend > To: "Michiel de Hoon" <mjl...@ya...> > Cc: "mdekauwe" <mde...@gm...>, mat...@li... > Date: Friday, November 12, 2010, 9:06 AM > On Thu, Nov 11, 2010 at 7:32 PM, > Michiel de Hoon <mjl...@ya...> > wrote: > > For this example, I am finding the exact same behavior > with the Mac OS X backend as with the gtkcairo and gtkagg > backends (on Mac OS X and Cygwin). If this is a bug, then > which backend can we use as an example of the correct > behavior for this code? > > On a quick test, the following script > > import matplotlib.pyplot as plt > for i in range(4): > fig = plt.figure() > > > (no show) run with -dTkAGG and -dGTKAgg, does not raise a > figure > window in svn HEAD. I thought the OP was complaining > that the figure > was being raised w/o a call to show in macosx (don't have > ready access > to test on an osx box right now) > > JDH > |
From: Michiel de H. <mjl...@ya...> - 2010-11-13 11:36:04
|
I wasn't able to replicate this bug with the MacOS backend. --Michiel On Sat Nov 13th, 2010 1:15 AM EST Jae-Joon Lee wrote: >I cannot reproduce this with agg, ps and pdf backend. >Maybe this bug is specific to the Mac oS X backend? > >Regards, > >-JJ > > >On Sat, Nov 13, 2010 at 5:19 AM, Bror Jonsson <br...@bi...> wrote: >> >> Dear all, >> >> I must be doing something wrong, but it seems like the backgroundcolor statement for text just stopped working. I am using matplotlib 1.0.0 with MacOSX as backend on two different machines. If I run >> >> ipython -pylab >> >> text(0,0,'Kalle',backgroundcolor='0.6') >> >> I get this result: >> >> >> >> (The problem is that the text color switches to pale grey). This worked fine before. Does anyone else get this problem, and do you have any idea about how to trouble shoot it? >> >> Regards, >> >> Bror Jonsson >> ------------------------------------------------------------------------------ >> Centralized Desktop Delivery: Dell and VMware Reference Architecture >> Simplifying enterprise desktop deployment and management using >> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end >> client virtualization framework. Read more! >> http://p.sf.net/sfu/dell-eql-dev2dev >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> >> > >------------------------------------------------------------------------------ >Centralized Desktop Delivery: Dell and VMware Reference Architecture >Simplifying enterprise desktop deployment and management using >Dell EqualLogic storage and VMware View: A highly scalable, end-to-end >client virtualization framework. Read more! >http://p.sf.net/sfu/dell-eql-dev2dev >_______________________________________________ >Matplotlib-users mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
From: Jae-Joon L. <lee...@gm...> - 2010-11-13 06:15:55
|
I cannot reproduce this with agg, ps and pdf backend. Maybe this bug is specific to the Mac oS X backend? Regards, -JJ On Sat, Nov 13, 2010 at 5:19 AM, Bror Jonsson <br...@bi...> wrote: > > Dear all, > > I must be doing something wrong, but it seems like the backgroundcolor statement for text just stopped working. I am using matplotlib 1.0.0 with MacOSX as backend on two different machines. If I run > > ipython -pylab > > text(0,0,'Kalle',backgroundcolor='0.6') > > I get this result: > > > > (The problem is that the text color switches to pale grey). This worked fine before. Does anyone else get this problem, and do you have any idea about how to trouble shoot it? > > Regards, > > Bror Jonsson > ------------------------------------------------------------------------------ > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > client virtualization framework. Read more! > http://p.sf.net/sfu/dell-eql-dev2dev > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > |