You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
| 2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
| 2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
| 2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
| 2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
| 2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
| 2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
| 2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
| 2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
| 2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
| 2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
| 2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
|
2
(1) |
3
(8) |
4
(4) |
5
|
6
(2) |
|
7
(1) |
8
(7) |
9
(2) |
10
(3) |
11
(14) |
12
(3) |
13
|
|
14
|
15
(6) |
16
(4) |
17
(3) |
18
(1) |
19
|
20
(1) |
|
21
|
22
|
23
|
24
(1) |
25
|
26
(2) |
27
|
|
28
|
29
|
30
(1) |
31
|
|
|
|
|
From: Darren D. <dd...@co...> - 2007-01-11 21:45:20
|
On Thursday 11 January 2007 16:12, Darren Dale wrote:
> $ ipython
>
> In [1]: __import__('matplotlib.backends.backend_ps', globals(),\
> locals(),['backend_ps'])
>
> output:
> ---------------------------------------------------------------------------
> exceptions.AttributeError Traceback (most recent
> call last)
>
> /home/darren/<ipython console>
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py
> 54
> 55 # a hack to keep old versions of ipython working with mpl
> 56 if 'IPython.Shell' in sys.modules:
> ---> 57 new_figure_manager, draw_if_interactive, show = pylab_setup()
> 58
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py in
> pylab_setup()
> 24 time.sleep(1)
> 25 backend_mod = __import__('matplotlib.backends.'+backend_name,
> ---> 26 globals(),locals(),[backend_name])
> 27
> 28 # Things we pull in from all backends
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
> 7 import cairo.gtk
> 8
> ----> 9 import matplotlib.backends.backend_cairo as be_cairo
> 10 from matplotlib.backends.backend_gtk import *
> 11
>
> AttributeError: 'module' object has no attribute 'backends'
I found a workaround, and committed it. I don't understand what the root of
the problem was, probably because the AttributeError at the end of the
Traceback is misleading. Changing this:
import matplotlib.backends.backend_cario as be_cairo
to this:
from matplotlib.backends import backend_cairo
and updating references to be_cairo was all that was needed. The fix is in svn
2979.
Darren
|
|
From: Rich S. <rsh...@ap...> - 2007-01-11 21:26:36
|
On Thu, 11 Jan 2007, Rich Shepard wrote: > When I ran the script with -dWXAgg, it segfaulted. But, when I run with -dWX, it completes and displays the plot. Ergo, there's something wrong with Agg here, I suppose. Thanks, Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863 |
|
From: Rich S. <rsh...@ap...> - 2007-01-11 21:23:24
|
On Thu, 11 Jan 2007, Rich Shepard wrote: The last output files are attached. Thanks, Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863 |
|
From: Rich S. <rsh...@ap...> - 2007-01-11 21:22:07
|
On Thu, 11 Jan 2007, Rich Shepard wrote: On Thu, 11 Jan 2007, John Hunter wrote: > python simple_plot.py --verbose-debug -dAgg >& runagg.out > python simple_plot.py --verbose-debug -dPS >& runps.out > python simple_plot.py --verbose-debug -dGTK >& rungtk.out These three ran to completion. The last produced a window displaying the output. When I ran the script with -dWXAgg, it segfaulted. Two output files attached; original message bounced because the size was too large. Thanks, Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863 |
|
From: Darren D. <dd...@co...> - 2007-01-11 21:13:28
|
On Thursday 11 January 2007 02:01, Fernando Perez wrote:
> On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> > On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
> > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcair
> > >o.py", line 11, in ?
> > > import matplotlib.backends.backend_cairo as be_cairo
> > > AttributeError: 'module' object has no attribute 'backends'
> >
> > The original matplotlib code is correct, you should be editing IPython
> > and correcting their bug!
>
> Well, I'd be delighted to correct the ipython bug, if only I
> understood exactly what the problem was... As far as I can see, that
> code in ipython is simply calling
>
> # Initialize matplotlib to interactive mode always
> import matplotlib
> from matplotlib import backends
>
> inside a function (the _matplotlib_config method). I don't see a bug
> in that, but if you provide some pointers, I'll be happy to fix any
> issues that are on ipython's side of the fence.
I've been looking at this, but haven't made much progress. Try this with
backend:gtkcairo in matplotlibrc:
$ python
>>> __import__('matplotlib.backends.backend_ps', globals(),\
locals(),['backend_ps'])
output:
<module 'matplotlib.backends.backend_ps'
from '/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_ps.pyc'>
$ ipython
In [1]: __import__('matplotlib.backends.backend_ps', globals(),\
locals(),['backend_ps'])
output:
---------------------------------------------------------------------------
exceptions.AttributeError Traceback (most recent
call last)
/home/darren/<ipython console>
/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py
54
55 # a hack to keep old versions of ipython working with mpl
56 if 'IPython.Shell' in sys.modules:
---> 57 new_figure_manager, draw_if_interactive, show = pylab_setup()
58
/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py in
pylab_setup()
24 time.sleep(1)
25 backend_mod = __import__('matplotlib.backends.'+backend_name,
---> 26 globals(),locals(),[backend_name])
27
28 # Things we pull in from all backends
/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
7 import cairo.gtk
8
----> 9 import matplotlib.backends.backend_cairo as be_cairo
10 from matplotlib.backends.backend_gtk import *
11
AttributeError: 'module' object has no attribute 'backends'
If you change backend:gtkagg in matplotlibrc, then ipython doesnt complain.
Very strange.
|
|
From: John H. <jdh...@ac...> - 2007-01-11 15:56:13
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> This is the official definition from the manual:
Steve> CAIRO_FORMAT_ARGB32 each pixel is a 32-bit quantity, with
Steve> alpha in the upper 8 bits, then red, then green, then
Steve> blue. The 32-bit quantities are stored
Steve> native-endian. Pre-multiplied alpha is used. (That is, 50%
Steve> transparent red is 0x80800000, not 0x80ff0000.)
Steve> What I think this means is: cairo ARGB32 is stored not as 4
Steve> 8-bit quantities, but as one 32-bit int. On big-endian
Steve> systems the byte order is ARGB, as you would expect, but on
Steve> little-endian systems (like a PC) the byte order is BGRA.
Steve> I imagine the reason is that its easier/faster to
Steve> read/write one 32-bit int than it is to read/write four
Steve> bytes.
OK, I see the source of my confusion. argb determines the order but
it doesn't determine whether the most significant bit is first or
last....
I added a method buffer_bgra32 to the image backend. I'm not sure
this is the right way to deal with the endianness bit it's easy and
will probably work. I'll leave it to you guys to fix the cairo
backend to selectively call the right method and test it across
platforms, or propose a better solution if you don't like this one...
JDH
|
|
From: Steve C. <ste...@ya...> - 2007-01-11 15:37:41
|
On Thu, 2007-01-11 at 08:50 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > > Steve> On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: > >> I only had a short time to work with backend_gtkcairo, but a > >> couple of things caught my attention. mathtext support seemed > >> to need some improvement, it looked like it was rendered as an > >> image rather than as text. Also, imshow(rand(100,100)) looked > >> very different with gtkcairo and gtkagg, (maybe because the > >> rgba ordering is different in agg and cairo? I'm not sure this > >> is even the case, I'm taking a stab in the dark.) > > Steve> cairo mathtext uses a method copied from gdk/gtk and does > Steve> render an image. It needs updating to render text. > > Steve> imshow does look different on cairo and agg, and yes, It > Steve> looks like an image format problem. cairo uses ARGB32 with > Steve> pre-multiplied alpha, and the ARGB order depends on whether > Steve> the machine is little- of big-endian. > > I am confused by what you mean about the ARGB order depending on > endianess. ARGB defines the order, and each color is one byte, so > where is the ambiguity? Do you mean that depending on endianness, > cairo will use other orderings than ARGB? > > In _image.cpp we provide a few buffer methods for various pixel > orderings, eg buffer_argb32. We may need to provide additional > orderings for cairo, and call the right one depending on the platform. This is the official definition from the manual: CAIRO_FORMAT_ARGB32 each pixel is a 32-bit quantity, with alpha in the upper 8 bits, then red, then green, then blue. The 32-bit quantities are stored native-endian. Pre-multiplied alpha is used. (That is, 50% transparent red is 0x80800000, not 0x80ff0000.) What I think this means is: cairo ARGB32 is stored not as 4 8-bit quantities, but as one 32-bit int. On big-endian systems the byte order is ARGB, as you would expect, but on little-endian systems (like a PC) the byte order is BGRA. I imagine the reason is that its easier/faster to read/write one 32-bit int than it is to read/write four bytes. Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: Peter W. <pw...@en...> - 2007-01-11 15:14:44
|
On Jan 11, 2007, at 12:55 AM, Steve Chaplin wrote:
>> I have never run into a problem with relative imports, though I don't
>> object to removing them. Why are they bad style and what is the
>> danger?
>
> Its because you can unwittingly end up with module name clashes. There
> can be two different modules in two different directories with the
> same
> name and you import the wrong module by mistake.
Just wanted to chime in here --
with python 2.5, you can have your cake and eat it too:
from .localpkg import Symbol1, Symbol2
from . import localpkg
This disambiguates the "calendar.py" problem that you had (and that
about 90% of python coders have had at least once in their lives). :)
-Peter
|
|
From: Darren D. <dd...@co...> - 2007-01-11 15:05:24
|
On Thursday 11 January 2007 09:42, John Hunter wrote: > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> I had to alter the following lines from backend_gtkcairo, > Darren> from > > Darren> import matplotlib.backends.backend_cairo as be_cairo from > Darren> matplotlib.backends.backend_gtk import * > > Darren> > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py >", Darren> line 11, in ? import matplotlib.backends.backend_cairo as > Darren> be_cairo AttributeError: 'module' object has no attribute Darren> > 'backends' > > > My guess is that you were running your test code in which there was a > "matplotlib" dir that was not *the* matplotlib install dir. > > Possible? It wouldn't have been the first time I made that mistake, but that doesn't seem to be the problem. |
|
From: John H. <jdh...@ac...> - 2007-01-11 14:50:23
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
>> I only had a short time to work with backend_gtkcairo, but a
>> couple of things caught my attention. mathtext support seemed
>> to need some improvement, it looked like it was rendered as an
>> image rather than as text. Also, imshow(rand(100,100)) looked
>> very different with gtkcairo and gtkagg, (maybe because the
>> rgba ordering is different in agg and cairo? I'm not sure this
>> is even the case, I'm taking a stab in the dark.)
Steve> cairo mathtext uses a method copied from gdk/gtk and does
Steve> render an image. It needs updating to render text.
Steve> imshow does look different on cairo and agg, and yes, It
Steve> looks like an image format problem. cairo uses ARGB32 with
Steve> pre-multiplied alpha, and the ARGB order depends on whether
Steve> the machine is little- of big-endian.
I am confused by what you mean about the ARGB order depending on
endianess. ARGB defines the order, and each color is one byte, so
where is the ambiguity? Do you mean that depending on endianness,
cairo will use other orderings than ARGB?
In _image.cpp we provide a few buffer methods for various pixel
orderings, eg buffer_argb32. We may need to provide additional
orderings for cairo, and call the right one depending on the platform.
JDH
|
|
From: John H. <jdh...@ac...> - 2007-01-11 14:43:02
|
>>>>> "Darren" == Darren Dale <dd...@co...> writes:
Darren> I had to alter the following lines from backend_gtkcairo,
Darren> from
Darren> import matplotlib.backends.backend_cairo as be_cairo from
Darren> matplotlib.backends.backend_gtk import *
Darren> "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
Darren> line 11, in ? import matplotlib.backends.backend_cairo as
Darren> be_cairo AttributeError: 'module' object has no attribute
Darren> 'backends'
My guess is that you were running your test code in which there was a
"matplotlib" dir that was not *the* matplotlib install dir.
Possible?
JDH
|
|
From: Steve C. <ste...@ya...> - 2007-01-11 14:08:30
|
On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: > I only had a short time to work with backend_gtkcairo, but a couple of things > caught my attention. mathtext support seemed to need some improvement, it > looked like it was rendered as an image rather than as text. Also, > imshow(rand(100,100)) looked very different with gtkcairo and gtkagg, (maybe > because the rgba ordering is different in agg and cairo? I'm not sure this is > even the case, I'm taking a stab in the dark.) cairo mathtext uses a method copied from gdk/gtk and does render an image. It needs updating to render text. imshow does look different on cairo and agg, and yes, It looks like an image format problem. cairo uses ARGB32 with pre-multiplied alpha, and the ARGB order depends on whether the machine is little- of big-endian. Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: Fernando P. <fpe...@gm...> - 2007-01-11 07:01:22
|
On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
> > I had to alter the following lines from backend_gtkcairo, from
> >
> > import matplotlib.backends.backend_cairo as be_cairo
> > from matplotlib.backends.backend_gtk import *
> >
> > to
> >
> > import backend_cairo as be_cairo
> > from backend_gtk import *
> >
> > in order to prevent the following traceback:
> >
> > Traceback (most recent call last):
> > File "/usr/bin/ipython", line 27, in ?
> > IPython.Shell.start().mainloop()
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in
> > start
> > return shell(user_ns = user_ns)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in
> > __init__
> > shell_class=MatplotlibMTShell)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in
> > __init__
> > on_kill=[mainquit])
> > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in
> > make_IPython
> > embedded=embedded,**kw)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in
> > __init__
> > user_ns,b2 = self._matplotlib_config(name,user_ns)
> > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in
> > _matplotlib_config
> > from matplotlib import backends
> > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > line 55, in ?
> > new_figure_manager, draw_if_interactive, show = pylab_setup()
> > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > line 23, in pylab_setup
> > globals(),locals(),[backend_name])
> >
> > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
> > line 11, in ?
> > import matplotlib.backends.backend_cairo as be_cairo
> > AttributeError: 'module' object has no attribute 'backends'
>
> The original matplotlib code is correct, you should be editing IPython
> and correcting their bug!
Well, I'd be delighted to correct the ipython bug, if only I
understood exactly what the problem was... As far as I can see, that
code in ipython is simply calling
# Initialize matplotlib to interactive mode always
import matplotlib
from matplotlib import backends
inside a function (the _matplotlib_config method). I don't see a bug
in that, but if you provide some pointers, I'll be happy to fix any
issues that are on ipython's side of the fence.
Cheers,
f
|
|
From: Steve C. <ste...@ya...> - 2007-01-11 05:56:04
|
On Wed, 2007-01-10 at 11:55 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > > Steve> Matplotlib does use a lot of relative imports which I think > Steve> is bad style. > > Steve> See PEP 8 "Style Guide for Python Code" > Steve> http://www.python.org/dev/peps/pep-0008/ > > Steve> - Relative imports for intra-package imports are highly > Steve> discouraged. Always use the absolute package path for all > Steve> imports. Even now that PEP 328 [7] is fully implemented in > Steve> Python 2.5, its style of explicit relative imports is > Steve> actively discouraged; absolute imports are more portable > Steve> and usually more readable. > > I have never run into a problem with relative imports, though I don't > object to removing them. Why are they bad style and what is the danger? Its because you can unwittingly end up with module name clashes. There can be two different modules in two different directories with the same name and you import the wrong module by mistake. It happened to me once when I created a 'calendar.py' module and didn't realize that Python already has a calendar module. Its hard to debug because you get a traceback which makes no sense. >From PEP328 http://www.python.org/dev/peps/pep-0328/ Rationale for Absolute Imports In Python 2.4 and earlier, if you're reading a module located inside a package, it is not clear whether import foo refers to a top-level module or to another module inside the package. As Python's library expands, more and more existing package internal modules suddenly shadow standard library modules by accident. It's a particularly difficult problem inside packages because there's no way to specify which module is meant. To resolve the ambiguity, it is proposed that foo will always be a module or package reachable from sys.path. This is called an absolute import. Steve Send instant messages to your online friends http://au.messenger.yahoo.com |