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
(4) |
2
(8) |
3
(3) |
4
(4) |
5
|
|
6
|
7
(3) |
8
(8) |
9
(6) |
10
(8) |
11
(5) |
12
(2) |
|
13
(4) |
14
(2) |
15
(12) |
16
(11) |
17
(3) |
18
|
19
(1) |
|
20
|
21
(2) |
22
(13) |
23
(4) |
24
(6) |
25
|
26
(2) |
|
27
|
28
(2) |
29
(8) |
30
(2) |
|
|
|
|
From: Jin-chung H. <hs...@st...> - 2004-06-08 21:30:50
|
I have a few comments which may help to improve the matplotlib functionality:
(1) When the data values are large (or small), the mantissas are rounded off
in the scientific notation of the x- or y-tick labels. For example:
>>> plot([1.e9,2.e9,4.e9])
In fact, this is a generally harder problem. In the following contrived and
unlikely situation, it shows the similar problem:
>>> x=1.
>>> y=1.e-8
>>> plot([x,x+y,x+3*y,x+6*y])
This example has another curious problem. The tick labels are overploted in
some places and missing in others.
(2) Right now, hist() can only plot filled "bar charts". It will be
nice if it can also plot not-filled bar charts, bars without gaps in between,
filled with color of choice, and histogram with only the top bar, without
the vertical bars, except at the ends.
(3) For asymmetric error bars, the x(y)err's first array is for the "-" and
the second for the "+". Will it be more intuitive to have that reversed?
(4) When symbols are plotted (e.g. "o" or "x"), the legend shows a bunch (4)
of them. Will it be better to just plot one?
Thanks,
JC Hsu
|
|
From: John H. <jdh...@ac...> - 2004-06-08 14:17:48
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> There does seem to be a memory problem when using Python
Steve> and GTK+. Have you seen the pygtk FAQ 8.4 "Is there a
Steve> resource leak? Why do I run out of memory using Pixbuf?"
I submitted a patch to fix a pygtk memory leak in get_image that was
incorporated into pygtk 2.2.
http://bugzilla.gnome.org/show_bug.cgi?id=133681
Which version are you using? Do you still see a problem with pygtk
2.2 or later?
I'll take a look at incorporating your changes, in an case.
But as Kirill pointed out, there is a separate problem with Agg that I
have to track down.
JDH
|
|
From: Todd M. <jm...@st...> - 2004-06-08 13:04:43
|
On Mon, 2004-06-07 at 22:17, Kirill Lapshin wrote: > TkAgg -- works fine from console, but if ran from IDLE or PythonWin it > creates a window border only, does not populate it with plot. If I try > to move the plot window whole python session crashes with generic > runtime error message (windows error message box with a single Ok button). Try running with "idle -n" rather than just "idle" by changing the properties of a copy of the idle shortcut. TkAgg is know to work with: python idle -n IPython TkAgg is know not to work with: SciTE pythonw Pythonwin idle Regards, Todd Miller |
|
From: Steve C. <ste...@ya...> - 2004-06-08 09:53:44
|
There does seem to be a memory problem when using Python and GTK+. Have
you seen the pygtk FAQ 8.4 "Is there a resource leak? Why do I run out
of memory using Pixbuf?"
>From looking at matplotlib/backends/backend_gtk.py I noticed every
FigureCanvasGTK.draw() operation allocates memory for a new pixmap and a
new graphics context. So looping 200 times in your first test script
allocates memory for 200 pixmaps and 200 graphics contexts, yet the
pixmap size has not changed and the graphics context has not changed. I
think it would be more memory efficient to create a pixmap and continue
using it until a larger pixmap is required. The graphics context does
not change its default settings, so it does little, but is required for
the GDK calls, again it looks to me like it would be better to create
one and reuse it.
Here are some changes I made to matplotlib/backends/backend_gtk.py I
estimate saves around 10% of the memory leak.
However I can't check that it plots correctly properly because I
currently get a plot of a black rectangle in GTK mode (GTKAgg works OK),
which I think was mentioned as a numarray problem with the latest
matplotlib release.
FigureCanvasGTK.__init__(self,figure): # add the following line
self.pixmap_width, self.pixmap_height = -1, -1 # new
FigureCanvasGTK.draw(self): # replace with this:
def draw(self):
if not self._doplot: return
drawable = self.window
if drawable is None: return
width = int(self.figure.bbox.width())
height = int(self.figure.bbox.height())
if width > self.pixmap_width or height > self.pixmap_height:
self._gpixmap = gtk.gdk.Pixmap(drawable, width, height)
self.pixmap_width = width
self.pixmap_height = height
self.figure.draw( RendererGTK(self, self._gpixmap,
self.figure.dpi) )
drawable.draw_drawable(self._ggc, self._gpixmap, 0, 0, 0, 0,
width, height)
FigureCanvasGTK.realize(self, widget): # add the following line:
self._ggc = self.window.new_gc()
Regards
Steve
|
|
From: Kirill L. <ki...@la...> - 2004-06-08 03:10:12
|
Barry Drake wrote:
>I've recently returned to Matplotlib and Scipy (and
>happy to be back!!!). I had the same problem and
>solved it by putting the lines
>
>import matplotlib
>matplotlib.use('WXAgg')
>
>before the usual import
>
>from matplotlib.matlab import *
>
>
Barry, thanks a lot for your input, however I did try WXAgg, as well as
WX and TkAgg and none of them works for me. One thing I forgot to
mention in my previous e-mail though. I am using interactive mode. I
just tried the same experiment in non-interactive mode, and WX works
fine. However we are mostly interested in interactive mode, because we
mostly use plotting for debugging purposes.
--Kirill
|
|
From: Barry D. <bl...@ad...> - 2004-06-08 02:50:44
|
Kirill,
I've recently returned to Matplotlib and Scipy (and
happy to be back!!!). I had the same problem and
solved it by putting the lines
import matplotlib
matplotlib.use('WXAgg')
before the usual import
from matplotlib.matlab import *
This worked for all of the example code.
If you don't have the examples, which are not included
in the Windows installer, go back to the download page
again and grab the .zip file. This includes numerous
examples that you should be able to run with the two
lines mentioned above.
Hope this helps.
Barry Drake
--- Kirill Lapshin wrote:
> Hello,
>
> I am a newbie to Matplotlib and all Python
numeric
> stuff, so sorry if it
> is a FAQ.
>
> I've installed NumPy 23.1, SciPy 0.3 and
Matplotlib
> 54.1. Python is
> 2.3.4. The problem I have is that none of
backends
> works properly.
>
> TkAgg -- works fine from console, but if ran from
> IDLE or PythonWin it
> creates a window border only, does not populate
it
> with plot. If I try
> to move the plot window whole python session
crashes
> with generic
> runtime error message (windows error message box
> with a single Ok button).
>
> WX/WXAgg -- both don't work from console -- show
> empty window, cursor
> turns in hourglass when it is over plot window.
From
> GUI app
> (IDLE/PythonWin) it seems to work at first glance
--
> plot gets created,
> but the plot window can not be closed with either
> Alt-F4 or mouse. It
> just does not react on close command. Moreover,
> python objects
> corresponding to window seems to get destroyed
when
> I try to close
> window, because if I do few plots commands
without
> trying to close the
> window, new plots appear in first window, however
as
> soon as I try to
> close the window (it won't close, remember?), new
> plots will open new
> window. That second window can be closed, but
first
> one still remain
> unclosable.
>
> GTK/GTKAgg -- can't really try that one, because
it
> requires compiling
> GTK, and we don't have compiler yet.
>
>
> Any ideas how that can be fixed, work arounded,
> debugged? I am pretty
> comfortable with debugging Python code, but as I
> said I don't have C
> compiler yet, so can't debug extensions.
>
> This behavior observed on brand new computer with
> freshly installed Win
> XP. The same behavior I am observing on my a bit
old
> Win XP laptop.
>
> --Kirill
>
>
>
-------------------------------------------------------
> This SF.Net email is sponsored by: GNOME
Foundation
> Hackers Unite! GUADEC: The world's #1 Open
Source
> Desktop Event.
> GNOME Users and Developers European Conference,
> 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
>
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
|
|
From: Kirill L. <ki...@la...> - 2004-06-08 02:17:27
|
Hello, I am a newbie to Matplotlib and all Python numeric stuff, so sorry if it is a FAQ. I've installed NumPy 23.1, SciPy 0.3 and Matplotlib 54.1. Python is 2.3.4. The problem I have is that none of backends works properly. TkAgg -- works fine from console, but if ran from IDLE or PythonWin it creates a window border only, does not populate it with plot. If I try to move the plot window whole python session crashes with generic runtime error message (windows error message box with a single Ok button). WX/WXAgg -- both don't work from console -- show empty window, cursor turns in hourglass when it is over plot window. From GUI app (IDLE/PythonWin) it seems to work at first glance -- plot gets created, but the plot window can not be closed with either Alt-F4 or mouse. It just does not react on close command. Moreover, python objects corresponding to window seems to get destroyed when I try to close window, because if I do few plots commands without trying to close the window, new plots appear in first window, however as soon as I try to close the window (it won't close, remember?), new plots will open new window. That second window can be closed, but first one still remain unclosable. GTK/GTKAgg -- can't really try that one, because it requires compiling GTK, and we don't have compiler yet. Any ideas how that can be fixed, work arounded, debugged? I am pretty comfortable with debugging Python code, but as I said I don't have C compiler yet, so can't debug extensions. This behavior observed on brand new computer with freshly installed Win XP. The same behavior I am observing on my a bit old Win XP laptop. --Kirill |
|
From: Eric F. <ef...@km...> - 2004-06-08 01:38:55
|
John, I would like to use matplotlib in data acquisition and processing software for a shipboard acoustic Doppler current profiler (ADCP), and I am presently at sea on the University of Hawaii Research Vessel Kilo Moana (25S, 175W). Until June 17 or 18, when I arrive in Honolulu, I will not have access to the mailing list via my normal email address, ef...@ha..., but mail sent to me on the ship, ef...@km..., will be transferred about 3 times per day. I am working with a Linux machine, Mandrake 10.0, 2.6 kernel, pygtk 2.2. I suspect that the memory-monitoring parts of the scripts I have attached are Linux-specific. The attached scripts illustrate what seem to be pervasive memory leaks when doing repeated plots, using GTK or GTKAgg to plot to the screen, or using Agg to make png files only. I have tried several variations--all result in fairly steady increase in memory consumption. Memory usage increase can also be seen by running the pcolor_demo.py, and repeatedly raising and lowering the window, thereby forcing redraws. Do you expect that such leakage is inevitable with matplotlib? I hope not; matplotlib is by far the most promising plotting package I have found as a prospective Matlab replacement. On another topic: I believe I saw in earlier mailing list correspondence a request for transparent plotting of data with NaNs in it--that is, a NaN in a line should cause the line to be broken and a symbol omitted, in pcolor should cause simply an empty (white, black, or transparent) cell, etc., as in Matlab. I would like to second this request. In physical oceanography, bad or missing measurements are ubiquitous, and Matlab's treatment of NaNs enormously reduces the pain of dealing with such glitches. Ideally, this sort of thing would be done equivalently with NaNs in a numarray or with the mask in a masked array, so that one could use either approach. Thanks for the excellent work you have already done. Eric Firing ef...@km... until June 17 ef...@ha... thereafter |