matplotlib-devel Mailing List for matplotlib

>>>>> "Vinj" == Vinj Vinj <vin...@ya...> writes:

    Vinj> I recently upgraded from 0.8 to 0.83 and now the x labels do
    Vinj> not rotate.
    ...snip...
    Vinj> When I revert back to 0.8 the labels are correctly
    Vinj> displayed. I use the following code for formatting the
    Vinj> xlabels:

Not sure why you are having trouble.
htdocs/screenshots/finance_work2.py is working for me with matplotlib
CVS, 0.83.2 and 0.83

Can you test the finance_work2.py example so at least we're working
with the same code?  And since there were a few releases in the 0.83
series, it might help if you post the result of running your code with
the --verbose-helpful example so I know which bugfix release you are
working with.  Here's what I get:

peds-pc311:~/python/projects/htdocs/screenshots> python
finance_work2.py -dTkAgg --verbose-helpful
matplotlib data path /usr/share/matplotlib
$HOME=/home/jdhunter
loaded rc file
/home/jdhunter/python/projects/htdocs/screenshots/matplotlibrc
matplotlib version 0.83
verbose.level helpful
interactive is False
platform is linux2
numerix numarray 1.1.1
font search path ['/usr/share/matplotlib']
CONFIGDIR=/home/jdhunter/.matplotlib
loaded ttfcache file /home/jdhunter/.matplotlib/ttffont.cache
backend TkAgg version 8.4


JDH

>>>>> "Helge" == Helge Avlesen <he...@gm...> writes:

    Helge> Hi, this is a very useful option, similar to that of the
    Helge> "axis image" of matlab. a small wish from me: is it also
    Helge> possible to let the option "freeze" the aspect ratio of the
    Helge> figure(s) in question when the window is resized?  this is
    Helge> like the matlab behaviour for "axis image", e.g.  when the
    Helge> window is enlarged in such a way that the aspect ratio of
    Helge> the window changes, the aspect ratio of the figure(s)
    Helge> remains the same while the increase.

Hey Helge,

This would be useful, but is nontrivial.  To make it work, matplotlib
needs to expose the "resize event" across backends so that the Axes
code can connect to it and update itself during the resize.  Please
file a support request on the sf site at
http://sourceforge.net/tracker/?group_id=80706&atid=560721

Thanks,
JDH

>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes:

    Jeff> Here's a patch against 0.83.2 that modifies colorbar to use
    Jeff> contourf instead of imshow (so that only those colors used
    Jeff> by contourf are shown on the colorbar).  It also adds a few
    Jeff> keyword options to colorbar to 1) allow for linear spacing
    Jeff> of colors on the colorbar (even if the contour levels are
    Jeff> not linear), and 2) draw lines on the colorbar between the
    Jeff> individual colors. Eric and Jim: I think you have both been
    Jeff> hacking on colorbar, perhaps we could merge your changes
    Jeff> into this patch?  Otherwise, if no one has any objections,
    Jeff> I'll commit this to CVS later this week.

I haven't tested this but I did read over it and have one minor
comment

I tend to avoid catching all exceptions as in

+        try:
+        # mappable image is from contourf
+            clevs = array(mappable.levels.tolist() + [mappable.level_upper])
+            iscontourf = True
+        except:
+        # from imshow or pcolor.
+            iscontourf = False
+            norm = mappable.norm
+            if norm.vmin is None or norm.vmax is None:
+                mappable.autoscale()
+            cmin = norm.vmin
+            cmax = norm.vmax
+            clevs = linspace(cmin, cmax, cmap.N)

because they can lead to hard to track bugs.  I suggest either
catching an AttributeError or testing explicitly for ContourMappable,
eg

if isinstance(mappable, ContourMappable):
   # do something
elif isinstance(mappable, ScalarMappable):
   # do something else
else:
   Raise TypeError("don't know how to handle type %s"%type(mappable))

Thanks,
JDH

Here's a patch against 0.83.2 that modifies colorbar to use contourf 
instead of imshow (so that only those colors used by contourf are shown 
on the colorbar).  It also adds a few keyword options to colorbar to 1) 
allow for linear spacing of colors on the colorbar (even if the contour 
levels are not linear), and 2) draw lines on the colorbar between the 
individual colors. 

Eric and Jim:  I think you have both been hacking on colorbar, perhaps 
we could merge your changes into this patch?  Otherwise, if no one has 
any objections, I'll commit this to CVS later this week.

Attached also is a test script to exercise the new colorbar features.  
The default behavior should be the same as before.

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/CDC  R/CDC1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Charles Moad wrote:
> 	I still get an even more random segfault when using the ipython -pylab option. 
>   Here is about the closest thing I can do to reproduce (most of the time).
> 
> plot(rand(100))
> f = get_current_fig_manager()
> f.canvas.get_width_height()
> s = f.canvas.tostring_rgb()
> f.canvas.<tab>Segmentation fault
> 
> Here is more verbosity if it helps.

What backend are you using?  Can you try with different ones (ipython -pylab 
adapts automatically, just change your default backend in your 
~/.matplotlib/matplotlibrc file).   What version of matplotlib are you using?

Here's what I get, using matplotlib 0.83.2 (official release):

- TkAgg, QtAgg, WXAgg: no problem, can't reproduce your crash, works normally.

- GTKAgg: instant crash on my box (even before getting to where it crashes for 
you):

In [1]: plot(rand(100))
---------------------------------------------------------------------------
exceptions.SystemError                               Traceback (most recent 
call last)


SystemError: Objects/moduleobject.c:48: bad argument to internal function
Segmentation fault


I won't worry about this one, as it may be that I screwed something up in the 
build, and I don't use GTK ever anyway.

But knowing what backends trigger your crash will help narrow things down.

Cheers,

f

	I still get an even more random segfault when using the ipython -pylab option. 
  Here is about the closest thing I can do to reproduce (most of the time).

plot(rand(100))
f = get_current_fig_manager()
f.canvas.get_width_height()
s = f.canvas.tostring_rgb()
f.canvas.<tab>Segmentation fault

Here is more verbosity if it helps.

.....
In [4]:f.canvas.get_width_height
------>f.canvas.get_width_height()
Out[4]:(640, 480)

In [5]:f.canvas.
Display all 294 possibilities? (y or n) <typed "n">

In [5]:f.canvas.to
f.canvas.tostring_argb  f.canvas.tostring_rgb

In [5]:s = f.canvas.tostring_rgb()

In [6]:f.canvas.Segmentation fault


Thanks,
	Charlie