matplotlib-users Mailing List for matplotlib (Page 1376)

John Hunter wrote:
> 
> I'm able to download it from the sf site -- perhaps it's your download
> client?

I've tried a number of approaches on Linux and XP, including remote desktop into 
another box on the other side of the country, but all approaches failed. The 
only commonality between the 2 setups is we are both using IPCop as a firewall 
and are in Australia.

Robert

Cindy Hodgins Burian wrote:
>  If I 
> change "BUILD_GTKAGG = 0" it compiles with some complaints like

This will keep it form building the GTKAGG back end...do you need that?

>  >>> import pylab

>    from _gtkagg import agg_to_gtk_drawable

You're getting this error because you don't have the GTKAGG back end, 
which makes sense, as you told setup.py not to build it.

The problem is that your matplotlibrc file sets gtkagg as the default 
back end. First, try this:

 >>> import matplotlib
 >>> matplotlib.use('Agg')
 >>> import pylab

If that works, then you seem to have a working matplotlib with the Agg 
back end. If you generating plots that you want to save as PNG and use 
ion a wed site or something, you're done. You should also be able to use 
it with wxPython. Tkinter may also work. If you do need the PyGTK back 
end, I can't help you, except to say that make sure you have PyGTK 
working first.

To change the default back end, edit matplotlibrc:

http://matplotlib.sf.net/.matplotlibrc

Good luck,

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

John Hunter wrote:

> >>>>> "Teemu" == Teemu Rinne <Tee...@he...> writes:
>
>
>     Teemu> How to do this?  Do I have to combine the RGB values of the
>     Teemu> two images 'manually'?
>
> Basically what you are talking about is adding an alpha channel to the
> color map, and setting it to be transparent for image values less than
> a certain value.  Perry Greenfield is the colormap implementer and
> resident expert.
>
> Perry -- how hard would it be to either subclass or extend the current
> framework to include an alpha channel?  I think it could be done in
> just a few lines of code actually.  Eg, something like
>
>    self._alpha_lut  = makeMappingArray(self.N,
>                      self._segmentdata.get('blue', [1.0, 1.0])
>
> and then modifying
>
>     def __call__(self, X, alpha=1.0):
>
> to deal with it.
>
> Perry do you have time to take a crack at this?  I think this would be
> very useful.
>
Offhand it doesn't look like it should be a problem, but I need to clarify
some things about your suggestion and the user interface.

Should self._alpha_lut always copy the blue segment data (or are you showing
what the user would have to do?) I would have guessed that it would default
to being always 1 (I think that's the intent above but how does one then
define it independently outside of the class definition.

Secondly, this example asks for a threshold based on prenormalized data
values (i.e., image value of 30). To get what the user wants, the user must
either define the alpha map to match the normalized value of 30 or normalize
the data to match 30 to the alpha map threshold. It's not so obvious to me
how this is best handled. A fancier normalization function that uses
data-based thresholds to map to color map thresholds? Otherwise, it may be
fairly painful to apply in practice. A convenient way to define a color map
based on data values and how the data will be normalized?

But maybe I'm suffering from flu-induced confusion.

Perry

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
    Fernando> Well, the funny thing about my sometimes-odd results, is
    Fernando> that in python 2.3, list.sort _is_ stable:

    Fernando> http://py-stablesort.sourceforge.net/doc/2002_07_28_pythonowns_archive.html
    Fernando> http://mail.python.org/pipermail/python-list/2003-April/160326.html

    Fernando> So I'm not quite sure why I get odd results in a few
    Fernando> cases.  And I can't seem to find a reliable way to
    Fernando> repeat the behavior.

Hmm, I hesitate to say this, but I wonder if it's a bug in the stable
sort.  I also see the behavior you describe in ipython --
intermittently the order is wrong.  But when I add the extra ind to
the axes dsu sort, I never get it.

Changes in CVS.  Make sure you have revision - CHANGELOG 1.270

    Fernando> But thanks for the clarification on the zorder argument,
    Fernando> that's enough for me to get the behavior I need.

    Fernando> I'll update the zorder_demo example with a more explicit
    Fernando> docstring so others don't fall into the same confusion.


Thanks.

JDH

I'm having some problems compiling matplotlib 0.7.1 on solaris 8.  I 
believe I have all the prerequisites there.  If I try to compile with 
setup.py as it is originally, immediately it complains with "sh: 
pkg-config: not found", and finally dies after working a while.  If I 
change "BUILD_GTKAGG = 0" it compiles with some complaints like

/usr/local/pkg/python/include/python2.3/pyconfig.h:856:1: warning: 
"_XOPEN_SOURCE" redefined
<command line>:1:1: warning: this is the location of the previous definition

But seems to work.

When I try to import it I get:

ghia{chodgins}120: python
Python 2.3 (#1, Sep 12 2003, 16:47:52)
[GCC 3.0.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pylab
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/pkg/python/lib/python2.3/site-packages/pylab.py", 
line 1, in ?
    from matplotlib.pylab import *
  File 
"/usr/local/pkg/python/lib/python2.3/site-packages/matplotlib/pylab.py", 
line 191, in ?
    from backends import new_figure_manager, error_msg, \
  File 
"/usr/local/pkg/python/lib/python2.3/site-packages/matplotlib/backends/__init__.py", 
line 20, in ?
    globals(),locals(),[backend_name])
  File 
"/usr/local/pkg/python/lib/python2.3/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 16, in ?
    from _gtkagg import agg_to_gtk_drawable
ImportError: No module named _gtkagg
 >>>

I'm not sure how to proceed from here.  I also am not a python 
programmer, just a system administrator trying to get this installed.  
Any help or fingers pointing me in a direction are greatly appreciated.  
Thanks.

Cindy
 

John Hunter wrote:
> Hmm, seems to work for me -- you didn't specify the colors in your
> example which makes it hard to test, so I'll add them

Weird.  I ran this a ton of times, and in _most_ cases I get your same 
results.  And yet a _few_ times, and only when I pasted the code in an 
interactive window, the horizontal line ends below the sine/cosine plots. 
Very, very strange.

> Well the zorder kwarg is your friend -- did you see
> examples/zorder_demo.py ?  Eg
> 
>   plot(x,y, zorder=100)  # I'm on top!

I did read it, but I guess I misunderstood the docstring on top.  I understood 
it as meaning that you could only reorder classes of objects relative to one 
another (lines, text, patches), but not individual lines within the class of 
all lines.

> Now, if I recall correctly, python sort doesn't guarantee preserving
> order for equal element.  Since the order in the respective list
> (patches, lines, etc) *is* determined by the order of the plot
> commands, we might be better off with 
> 
>         dsu = [ (a.zorder, i, a) for i, a in enumerate(artists)]
>         dsu.sort()
>         
>         for zorder, i, a in dsu:
>             a.draw(renderer)
> 
> to guarantee relative order for artists with the same zorder.
> 
> Or is sort relative order preserving for equal elements?

Well, the funny thing about my sometimes-odd results, is that in python 2.3, 
list.sort _is_ stable:

http://py-stablesort.sourceforge.net/doc/2002_07_28_pythonowns_archive.html
http://mail.python.org/pipermail/python-list/2003-April/160326.html

So I'm not quite sure why I get odd results in a few cases.  And I can't seem 
to find a reliable way to repeat the behavior.

But thanks for the clarification on the zorder argument, that's enough for me 
to get the behavior I need.

I'll update the zorder_demo example with a more explicit docstring so others 
don't fall into the same confusion.

Cheers,

f

>>>>> "Robert" == Robert Leftwich <ro...@le...> writes:

    Robert> I'm unable to successfully download the user guide, it
    Robert> keeps bombing out at about 3MB (other downloads are
    Robert> fine). Google doesn't turn up any alternate sources and I
    Robert> was wondering if there is another site (as yet
    Robert> undiscovered by the Googlebots) to download it from?

I'm able to download it from the sf site -- perhaps it's your download
client?

JDH

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> Hi all, I am having a bit of a problem with the order
    Fernando> things get drawn.  I looked at the zorder example and
    Fernando> the docs, but I can't seem to find a solution.  Here's
    Fernando> an illustration:

    Fernando> http://amath.colorado.edu/faculty/fperez/tmp/zorder_prob.png

    Fernando> The red wiggly line is drawn first, by a loglog() call,
    Fernando> and then the green one is an axhline() call.  However,
    Fernando> the green line ends up below the red one.  It turns out
    Fernando> that in cases where the range of the red stuff is above
    Fernando> the green cutoff, this causes the green line to be
    Fernando> totally obscured.  And for my plots, it's important that
    Fernando> the green line is clearly visible always.

    Fernando> My naive expectation was that whatever was called last
    Fernando> on the plot would end up on top, but that doesn't seem
    Fernando> to be the case.  I did a few experiments:

    Fernando> x=frange(0,2*pi,npts=100) figure()
    Fernando> plot(x,sin(x),x,cos(x),linewidth=10)
    Fernando> plot(x,sin(2*x),linewidth=10) axhline(0,linewidth=10)

Hmm, seems to work for me -- you didn't specify the colors in your
example which makes it hard to test, so I'll add them

    from pylab import *
    x=frange(0,2*pi,npts=100)
    figure()
    plot(x,sin(x),x,cos(x),linewidth=10, color='red')
    plot(x,sin(2*x),linewidth=10, color='green')
    axhline(0,linewidth=10, color='blue')
    show()

with results at http://matplotlib.sf.net/jdh.png

    Fernando> And I can't really figure out what determines the zorder
    Fernando> of all the line objects.

Well the zorder kwarg is your friend -- did you see
examples/zorder_demo.py ?  Eg

  plot(x,y, zorder=100)  # I'm on top!

I think I have an idea of what may be causing the plot order problem
you are experiencing

From axes.py draw method

        artists = []
        artists.extend(self.collections)
        artists.extend(self.patches)
        artists.extend(self.lines)
        artists.extend(self.texts)

        dsu = [ (a.zorder, a) for a in artists]
        dsu.sort()
        
        for zorder, a in dsu:
            a.draw(renderer)

Now, if I recall correctly, python sort doesn't guarantee preserving
order for equal element.  Since the order in the respective list
(patches, lines, etc) *is* determined by the order of the plot
commands, we might be better off with 

        dsu = [ (a.zorder, i, a) for i, a in enumerate(artists)]
        dsu.sort()
        
        for zorder, i, a in dsu:
            a.draw(renderer)

to guarantee relative order for artists with the same zorder.

Or is sort relative order preserving for equal elements?


JDH

Hi all,

I am having a bit of a problem with the order things get drawn.  I looked at 
the zorder example and the docs, but I can't seem to find a solution.  Here's 
an illustration:

http://amath.colorado.edu/faculty/fperez/tmp/zorder_prob.png

The red wiggly line is drawn first, by a loglog() call, and then the green one 
is an axhline() call.  However, the green line ends up below the red one.  It 
turns out that in cases where the range of the red stuff is above the green 
cutoff, this causes the green line to be totally obscured.  And for my plots, 
it's important that the green line is clearly visible always.

My naive expectation was that whatever was called last on the plot would end 
up on top, but that doesn't seem to be the case.  I did a few experiments:

x=frange(0,2*pi,npts=100)
figure()
plot(x,sin(x),x,cos(x),linewidth=10)
plot(x,sin(2*x),linewidth=10)
axhline(0,linewidth=10)

And I can't really figure out what determines the zorder of all the line objects.

Is there a way to control this?  Would it make sense to make the default 
behavior something more like what hand-drawing would cause?  I mean: you draw 
on the canvas as if it were paper, and newly drawn lines appear on top of 
older ones.

Maybe there's a good reason for the current design, and I'm just missing the 
proper incantation.  I'd be very grateful for a pointer in the right direction.

Cheers,

f

Try this:

a=arange(10)
l1,err = errorbar(a,a,sqrt(a))
legend((l1,),('it works',))


On Wednesday 09 February 2005 10:05 am, Bryan Cole wrote:
> Hi,
>
> When I try to add a legend to an errorbar plot, each individual errorbar
> gets added to the legend (without a label). With ~2000 points in my
> plot, I end up with >2000 entries in my legend: not good.
>
> Can anyone suggest a work-around for this?
>
> thanks,
> Bryan
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 

Darren

Hi,

When I try to add a legend to an errorbar plot, each individual errorbar
gets added to the legend (without a label). With ~2000 points in my
plot, I end up with >2000 entries in my legend: not good.

Can anyone suggest a work-around for this?

thanks,
Bryan

Hello,

I have a problem with the interactive zooming function of the matplotlib
"figure" Object.
I plotted a set of data as a line (simulated data) and a set of data
(measured data) as points. They are both in a subplot to show the
differences:
    plot (X1, Y1, color=(r1,g1,b1),linewidth=1.0)
    plot (X2, Y2, 'ro',markersize=2)

Problem:
Zooming is only possible in parts of the graph, where there is only the data
(X1, Y1) printed.


Does someone can help me?

Thanks in advance.

Christoph

-- 
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl

I have a requirement to generate a scatter plot with the background divided into 
4 equal rectangular regions, each a different colour/shade indicating a 
particular characteristic of the points in that region. What is the best way to 
do this in matplotlib?

Robert

PS I apologise in advance if this is answered in the user guide, but I'm unable 
to download it atm for some strange reason.

I'm unable to successfully download the user guide, it keeps bombing out at 
about 3MB (other downloads are fine). Google doesn't turn up any alternate 
sources and I was wondering if there is another site (as yet undiscovered by the 
Googlebots) to download it from?

Robert

A little roll reversal today.  Rather than you asking me how to use
matplotlib interactively on win32, I'll ask you...

The reason: a former adviser of mine is teaching a biomath course, and
is using python with Numeric and matplotlib for the computational
part.  Almost all of his students are windows XP users, and are
struggling a little bit with the impoverished command shell.  I've
recommended ipython to them, and sent a zip file with all the prereqs,
but even this may be a bit much for some typical windows users who
came of age in the post DOS era -- for one thing they still need a
code editor.

Is anyone using matplotlib robustly a GUI IDE in win32?  By robustly,
I mean, generating plots from the command shell and files, editing the
files with an integrated editor, running them from there,
interactively opening and closing windows, switching between command
line interaction and file mode, without crashes and freezes?

If so, please advise, with info about your configuration and
suggestions.

idle was my first inclination, despite the fact that it is rather
impoverished GUI, but with all the recent matplotlib changes in
tkagg's PYTHONINSPECT setting with or w/o idle -n I am not sure how
robust it is currently.

Thanks!
JDH

>>>>> "Teemu" == Teemu Rinne <Tee...@he...> writes:


    Teemu> How to do this?  Do I have to combine the RGB values of the
    Teemu> two images 'manually'?

Basically what you are talking about is adding an alpha channel to the
color map, and setting it to be transparent for image values less than
a certain value.  Perry Greenfield is the colormap implementer and
resident expert.

Perry -- how hard would it be to either subclass or extend the current
framework to include an alpha channel?  I think it could be done in
just a few lines of code actually.  Eg, something like

   self._alpha_lut  = makeMappingArray(self.N,
                     self._segmentdata.get('blue', [1.0, 1.0]) 

and then modifying

    def __call__(self, X, alpha=1.0):

to deal with it.  

Perry do you have time to take a crack at this?  I think this would be
very useful.

Thanks,
JDH

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:

    Chris> I'd vote for Agg. Postscript is not the native format on
    Chris> OS-X that it is on other unices.

    Chris> Is there a way to make the default back-end system
    Chris> dependent on install?

For a src distribution, you could write a postinstall script that does
try/except on various GUIs and writes an rc file based on what it
finds.  This is basically what setup.py does in trying to figure out
which backend to build, but doesn't transmit that information to rc --
perhaps it should.  Although this would be fairly easy in a src
distro, it would be fairly hard in the binary installer which you are
trying to build.

Alternatively, the backend importer could be a little smarter, and
first try the default rc param and then loop over available backends
trying to find a match, and issue a verbose report saying "dear
newbie, I cannot import your default backend, please see http://blah."
but still go ahead and launch something.  I have mixed feelings about
this -- the more magic we do the more complex it is to debug
problems.  Also, you have to be careful not to swallow tracebacks, eg
pygtk import can fail even if pygtk has been installed on the system,
and the user needs to know about this.  But I am not totally opposed
to it.

In fact, I would definitely include it if it was an rc option.  Eg,
binary package makers like yourself could turn it on since you don't
know the user configuration, and src distributors like me could turn
it off, assuming people who build their own code can configure it like
they like it.

Power users want as little magic going on as possible -- new users
usually want maximal magic.


The function to look at is __init__.py in the main matplotlib tree.
Currently we do


def get_backend():
    return rcParams['backend']


you would want to add an rc param, something like

backend     : ['TkAgg']
# try these if default fails
backend.try = ['GTKAgg, 'WXAgg', 'Agg', 'PS]

and then modify get_backend to iterate over these backends, trying to
import something to test if it is available, issuing reports if the
default backend fails.  

In the src distro, I always have the option of making backend.try the
empty list, which would be the same as the current behavior.

and 
JDH

Hi,

Looking at the Matplotlib Mailing list, I wonder if you=20
already started working in this direction?

Nicolas


Le Jeudi 19 Ao=FBt 2004 13:58, John Hunter a =E9crit=A0:
> >>>>> "Sigve" =3D=3D Sigve Tjora <pu...@tj...> writes:
>
>     Sigve> Hi everyone, Is there any planned support for
> a Qt-backend? Sigve> We are using Qt in our project, and
> I would like to use Sigve> Matplot lib for plotting.
>
>     Sigve> If there is not any support for Qt how hard
> would it be to Sigve> make it myself? Would it be best to
> base it on the Agg Sigve> backend, or should I make a
> native Qt backend? What is the Sigve> least work? Is it
> possible to write the whole backend in Sigve> Python or
> should I use C++ in addition?
>
> Currently there is no QT backend, or one in the works,
> but it would be nice.  It is definitely much easier to
> base it on the agg backend and is in fact *strongly
> encouraged* as that minimizes the amount of maintenance
> required.
>
> Using C/C++ is an optional step.  TkAgg and GTKAgg use it
> to get the optimal transfer speed from the agg image to
> the GUI canvas.  WXAgg and FLTKAgg do not use it, and
> Gregory reports great performance for FLTKAgg.  WXAgg
> uses string methods to transfer the image and FLTKAgg
> uses a python buffer object.  I encourage you to try and
> use a python buffer object (or string method) as opposed
> to extension code in the beginning since it's easier to
> write and maintain, it will introduce no extra compile
> time dependencies, and in the event that you find it too
> slow and want to write an extension to speed things up,
> you'll have the pure python method to fall back on for
> users who can't get the extension compiled.
>
> matplotlib.backends.backend_template contains the basic
> documentation for backend writers.  But this code does a
> lot more than you need, since agg will be doing the
> drawing; ie you don't need to implement a renderer or
> graphics context.  I recommend you give it a read
> through, and then follow the lead of backend_fltkagg.  I
> also advise you not to implement the classic navigation
> toolbar (at least not until later) because the new
> toolbar design is not only better (in my opinion), it's
> currently the default and most importantly, is much
> easier to implement since all the work is done for you in
> backend bases.  You basically need to load up some images
> into a toolbar and get the signal connections right.
>
> In the event you need a different pixel format to
> transfer the agg image to the qt canvas, that will be no
> problem.  I will be glad to add it for you or you can add
> it yourself to backend_agg.
>
> The only thing I ask of submitters is that if you want
> your backend to be included with the matplotlib
> distribution, please be responsible for testing it across
> the major platforms the GUI should run on (eg linux,
> win32, and OSX), provide some install instructions,
> version dependencies, etc, for the documentation, and
> monitor the mailing lists to handle questions about your
> backend.  In a nutshell, I need you to maintain it.  If
> you don't have the time to maintain it but want to write
> one anyway for your own work, I would be happy to provide
> a link to it with a disclaimer that users are on their
> own.
>
> Good luck if you decide to do it, and let me know if I
> can help.
>
> JDH
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price
> on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk
> Sonic DVD+R for only $33 Save 50% off Retail on Ink &
> Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-u
>sers

=2D-=20



=2D--------------------------------------------------------
=2D Nicolas DUBUIT
=2D CEA Cadarache DSM/DRFC/SCCP/GTTM
=2D (Groupe Turbulence, Transport et MHD)
=2D du...@dr...
=2D--------------------------------------------------------

Chris Fonnesbeck wrote:
> On Mon, 07 Feb 2005 10:47:51 -0800, Chris Barker <Chr...@no...> wrote:
>>John Hunter wrote
>>>    Chris> I am wondering if it would be worthwhile making TkAgg the
>>>    Chris> default backend in an OSX binary, since the current default
>>>    Chris> kills the python process:
>>>Yes, that is what I do for win32.
>>Except that Tk is not installed by default in OS-X either. It is
>>probably more common than GTK, however.
> Right, maybe PS would be a more sensible default, although I'm willing
> to bet most users end up using Tk.

I'd vote for Agg. Postscript is not the native format on OS-X that it is 
on other unices.

Is there a way to make the default back-end system dependent on install?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

kristen kaasbjerg wrote:

>Hola
>
>When i try to fit a polynomial of order 4 to 5 data
>points, I get an answer far from what I would expect.
>  
>
If I run your script and print out the polynomial coefficients, they are 
very large and alternate in sign:

In [166]: p
Out[166]:
array([ -1779.1645838 ,   7613.24170642, -12137.79572888,
         8529.6429996 ,  -2239.34146635])

This means that the problem is ill posed.  In general, high order 
polynomial fitting is a bad idea;  if you just want an interpolant and 
don't care about coefficients, use a cubic spline.

Hi,

I recently got matplotlib working on OSX (only agg so far) and am now 
trying to create a picture with two overlayed images so that only a certain 
range of values of the top-most figure are blended with the bottom one.

The first image would be plotted with the gray palette:
im_bottom=figimage(bottom_data,xo=0, yo=0,cmap=cm.gray)

The second image would be in colors:
im_top=figimage(top_data,xo=0, yo=0,cmap=cm.hot)

I would like to 'threshold' the top figure so that only values, say, 
greater than 30 are plotted with 'hot' colors and elsewhere the gray 
im_bottom is shown (without blending it with the colors of im_top).

I was hoping that I could do something easy like this:
im_top=figimage(where(less(data_top,30),do_not_plot_this_value,data_top),xo=0,yo=0,cmap=cm.hot,alpha=0.5)

How to do this?
Do I have to combine the RGB values of the two images 'manually'?


Cheers,


--
Teemu Rinne

John Hunter wrote:
>     Chris> I am wondering if it would be worthwhile making TkAgg the
>     Chris> default backend in an OSX binary, since the current default
>     Chris> kills the python process:
> 
> Yes, that is what I do for win32.

Except that Tk is not installed by default in OS-X either. It is 
probably more common than GTK, however.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

>>>>> "Chris" == Chris Fonnesbeck <fon...@gm...> writes:

    Chris> I am wondering if it would be worthwhile making TkAgg the
    Chris> default backend in an OSX binary, since the current default
    Chris> kills the python process:

Yes, that is what I do for win32.

JDH

I am wondering if it would be worthwhile making TkAgg the default
backend in an OSX binary, since the current default kills the python
process:

Python 2.3 (#1, Sep 13 2003, 00:49:11) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylab
No module named pygtk
PyGTK version 1.99.16 or greater is required to run the GTK Matplotlib backends

Hi folks-

I have had matplotlib working on OS X (Panther) for a while.  However,
I haven't used it heavily yet, so I don't know if there are problems
hiding under the covers.  I do know that I ran many of the demos
without any problems, both with TkAgg and wx; of course, those that
require GTK would not run.  

By the way, don't try to get it and scipy to work under Jaguar.
I spent several days attempting this, with lots of back and forth
with the scipy and macpython list folks, with no luck.  The $100
upgrading to Panther was a small price compared to the time lost
trying to get it all working on Jaguar.

Unfortunately I'm swamped and can't offer any significant assitance
with the OS-X binary issue at the moment.  But I thought one
observation might be useful.  Though I have some Fink stuff on
my Mac, it is only a few things (xfig and gv are the only Fink
things I use).  In particular, I believe the version of Freetype
that my matplotlib is using is not from Fink, but rather one
I installed with the TeX/LaTeX OS X "i-Installer" which can
install a number of useful binary packages besides TeX in a
pretty painless way (freetype2, jpeg/png/tiff libraries,
ghostscript...).  There is more about it here:

http://www.rna.nl/ii.html

I don't think its usefulness beyond TeX is appreciated as
well as it should be, though it certainly is confusing to
have all these different installation mechanims (OS X package
installers, i-Installer packages, setup.py, configure/make...).

-Tom