matplotlib-devel Mailing List for matplotlib (Page 2)

John,
I have someone fixing the last items (status bar and error handling) from 
the Qt backend and I had a few questions.  You said:

>   * If you try to save to an unsupported output type (eg pdf) the
>     entire window closes -- a bit extreme

This seems to happen on the TkAgg backend as well.  The culprit seems to be 
this code (backend_tkagg.py):

         try:
             self.canvas.print_figure(fname)
         except IOError, msg:
             err = '\n'.join(map(str, msg))
             msg = 'Failed to save %s: Error msg was\n\n%s' % (
                 fname, err)
             error_msg_tkpaint(msg)

The exception (at least for trying to save a pdf file) is not an IOError so 
the message get's propagated up and you exit the event loop (which is what 
causes the window to disappear).

I think the problem is that backend_agg.py is calling error_msg() that it 
COPYS from backend_bases.py.  The default action from backend_bases.py is 
to print a message and call sys.exit() which is what is generating this 
message.  I assume that somewhere you're trapping the exit call to send an 
exception?

On the surface (i.e. w/o knowing the design decisions that were made), this 
seems like a bad idea.  It seems like exceptions should be used and that 
sys.exit() should exit the program.  Changing the behavior of a standard 
call like sys.exit() (if that's what is really happening) seems like a bad 
idea since it changes global behavior.

Also, I'm a little confused about the backends use of the 'error_msg' 
function.   Many of the backends import this function from backend_bases 
but then change that names definition to a local copy (see backend_gtk, 
backend_template, backend_wx).  This seems wrong or at least more confusing 
that it needs to be.  I don't think a script should explicitly import 
something with one name and then change the name to point to a local variable.

Is the idea that the backends should overload the error_msg function that 
all the code uses?  If that's the case it would be a simple change to do 
something like this:

import backend_bases
backend_bases.error_msg = error_msg_tkpaint

Ted
Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

The following script generates an errant line in backend_ps

    from pylab import *

    x=arange(10)

    a=plot(x,x**2,'bo')
    b=plot(x,90-x**2,'rs')

    fl=figlegend((a,b),('curve 1','curve 2'),'lower center')
    fl.draw_frame(False)

    savefig('figlegend_bug')

but not in agg.  It only happens when the legend frame is off.

This is sf bug
https://sourceforge.net/tracker/?func=detail&atid=560720&aid=1122041&group_id=80706

JDH

John Hunter wrote:

> http://jdh.uchicago.edu/share/Traits2_UM.pdf
> 
> but there appears to be an OSX font problem with it...

It's more of a "non-Adobe Reader font problem," I think. It looks fine 
in Adobe Reader.

However, I just re-exported it to PDF using NeoOffice/J (the 
Java/Aqua/Mac version of OpenOffice). It seems to load fine in 
Preview.app, Adobe Reader, and Schubert|it's PDF plugin. Dunno about 
other platforms.

http://starship.python.net/crew/kernr/Traits2_UM_mac.pdf

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:

    Abraham> Wow, that makes life much easier! I'll get started on
    Abraham> re-porting the new style config library to use your
    Abraham> modified Traits2.

OK, great, just be aware that the directory organization will likely
change a bit over the next couple of weeks as I try to synchronize my
quick port with the enthought core tree.  But this change will be
localized to the one or two lines where the import occurs.

Eric Jones suggests we use continue to place traits under an enthought
basedir so it will be easier to keep our tree synched with theirs.  So
it will probably either matplotlib.enthought.traits or simply
enthought.traits depending on how things shake out.  He is also
interested in maintaining python2.2 compatibility so that bodes well
for us being able to work from their un/lightly-modified code base.

JDH

On Feb 13, 2005, at 1:00 PM, John Hunter wrote:

>>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
>     Andrew> Any other comments/questions?
>
> Hey Andrew, just did a quick read through the diff and have a few
> meandering comments meant solely to confuse and perplex :-)

No, I like your suggestions...

> Rather than all this cruft in rc
> <snip>
> How about
>
>   xaxis.spine1 = 0
>   xaxis.spine2 = 0
>   yaxis.spine1 = 0
>   yaxis.spine2 = 0
>
> Or xaxis spine1 is left and spine2 is right; for yaxis bottom and top.
> Use None to turn the spine off.  Otherwise use a floating point value
> to represent the pad.

Yes, I like your suggestion.

> You would  need a new rc method none_or_float, which will eventually
> become a trait.  Some care would have to be taken with this approach
> though.  If the text locations and tick line locations are using
> *delegation*, None could cause some trouble.  But if we use observer,
> then we could simply toggle the visibility to off upon setting None.
> This would work pretty well.

I think we might want a spine position variable separate from a spine 
visibility variable.  It's conceivable, although seemingly unlikely, 
that people would want to move the spine but have it invisible such 
that the tick origins are offset...

> In the midst of this refactor, it would be nice to support three tick
> position (inside, outside, center) rather than use the tick1inward
> boolean you suggest.  As you know we already have TICKUP, TICKDOWN
> TICKLEFT and TICKRIGHT line styles.  It would be trivial to add
> TICK_HORIZONTAL_CENTER and TICK_VERTICAL_CENTER to support these three
> tick placement schemes.  We then do away with inward and outward and
> simply use the tick line-style to indicate it's position.  The trick
> for doing label placement would be to query the tick line for top,
> left, bottom and right.  Then the only other param we need is the pad
> in points that separates the label from the tick, right?

Yes, and then another step where I think we'd need the bounding boxes 
for the ticklabels to get the pad for the axis label (axis title).

> Hmm, the project is growing.  I think there is something to be said
> for doing this axis refactor once, generally, and right, though.

Agreed.  I was fantasizing this morning about how, if we push the 
transforms into the backend, generalizing the whole thing to 3D and, 
for example, making an OpenGL backend wouldn't be the daunting task it 
once might've seemed. MPL's (2D) transforms now seem to be an example 
of parallel evolution to OpenGL's (3D) transforms. Furthermore, we 
could maybe support 3D in the frontend while allowing backends to 
implement at their own pace, throwing a NotImplementedError when the z 
transform becomes non-identity and if z values are non-zero...  Maybe 
we could write a middle-layer (wrapper) backend which handles the 
3D->2D transforms for the pure 2D backends.  This would handle the 
projective transformation but preserve zorder. Anyhow, just a fantasy 
for the moment, but tantalizing.

> You also have to be a little careful here
>
>       self._tick1PadPixels = 
> self.figure.dpi*Value(tick1Pad)*Value(1/72.0)
>
> because changes to tick11pad will not be reflected in
> self._tick1PadPixels.  Compare with
>
>       self.tick1Pad = Value(tick1Pad)
>       self._tick1PadPixels = 
> self.figure.dpi*self.tick1Pad*Value(1/72.0)
>
> Then if later on you do self.tick1Pad.set(7) the tick1padPixels attr
> is automagically updated

Yeah, I was running out of steam last night at 3 in the morning and got 
lazy, just wanting to get the thing to work. I knew about this...

> A lot of things I tried to solve with lazy values are addressed by
> delegation and observers in traits though, so we may want to go for a
> more traity impl.

Agreed.

> On a related note, it would be really nice to develop a layout object
> that was easy to use that was trait and mpl transform aware, so you
> could rather easily say
>
>   val = to_the_right_of(x, 5*points)
>
> Lazy values take you part of the way -- we'd also need all objects to
> report their extent (pretty easy, but can be expensive for some artist
> styles).  With get_extent implemented for all artists, you could build
> something like this will lazy values, but the syntax of constructing
> these things is a bit awkward, and matplotlib doesn't allow you to use
> lazy values and float interchangeably, which would be nice for example
> when creating text instances.  So a bit of redesign to support this
> kind of layout would make your job a lot easier.

This would really cool. It's beyond my brain capacity right now to 
think about implementation...

> Anyway, more sketchy thoughts that concrete ideas.... Thanks for the
> preliminary attempt!

I think moving to traits would be a wise first step, so I'll hold off 
for now until we get traits implemented.  What needs to happen first to 
implement traits? Change rcParams to be traits aware?  I've been 
ignoring the threads about re-vamping the rcParams format and reader, 
so I'm clueless about what's going on in that department.  Anyhow, I'm 
in no great hurry to get detachable axis spines working (as you know!), 
so I can happily return to this later.

Cheers!
Andrew

John Hunter wrote:

>On Friday, I found and fixed the last remaining known bug in the new
>log handling.  I've upload the 0.72 release candidate to 
>
>  http://jdh.uchicago.edu/share/matplotlib-0.72rc1.tar.gz
>
>so you can test it out.
>  
>
So far it passes my simple tests.  Whether I have time to do anything 
serious with it depends on how much I get done on this grant proposal 
I'm writing.

Thanks, John!

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:


    Andrew> The online documentation for traits seems pretty sparse.
    Andrew> Here's the best I could track down, Dave Morrill's scipy
    Andrew> '04 lightning talk:
    Andrew> http://www.scipy.org/wikis/scipy04/presentations2004/
    Andrew> scipy_conference_2004.pdf

No, the documentation is great -- it's just hard to find.  You have to
get the PDF from the enthought subversion tree, in the
branches/converge/traits/doc directory.  I put a copy of the latest
subversion pdf from that directory on my server,

http://jdh.uchicago.edu/share/Traits2_UM.pdf

but there appears to be an OSX font problem with it...

JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
    Andrew> Any other comments/questions?

Hey Andrew, just did a quick read through the diff and have a few
meandering comments meant solely to confuse and perplex :-)

Rather than all this cruft in rc

  axes.spineLeftOn    : True
  axes.spineRightOn   : True
  axes.spineBottomOn  : True
  axes.spineTopOn     : True
  axes.spineLeftPad   : 0
  axes.spineRightPad  : 0
  axes.spineBottomPad : 0
  axes.spineTopPad    : 0

How about  

  xaxis.spine1 = 0
  xaxis.spine2 = 0
  yaxis.spine1 = 0
  yaxis.spine2 = 0

Or xaxis spine1 is left and spine2 is right; for yaxis bottom and top.
Use None to turn the spine off.  Otherwise use a floating point value
to represent the pad.

You would  need a new rc method none_or_float, which will eventually
become a trait.  Some care would have to be taken with this approach
though.  If the text locations and tick line locations are using
*delegation*, None could cause some trouble.  But if we use observer,
then we could simply toggle the visibility to off upon setting None.
This would work pretty well.

In the midst of this refactor, it would be nice to support three tick
position (inside, outside, center) rather than use the tick1inward
boolean you suggest.  As you know we already have TICKUP, TICKDOWN
TICKLEFT and TICKRIGHT line styles.  It would be trivial to add
TICK_HORIZONTAL_CENTER and TICK_VERTICAL_CENTER to support these three
tick placement schemes.  We then do away with inward and outward and
simply use the tick line-style to indicate it's position.  The trick
for doing label placement would be to query the tick line for top,
left, bottom and right.  Then the only other param we need is the pad
in points that separates the label from the tick, right?

  xaxis.tick.alignment = 'inside'  # inside | outside | center
  xaxis.tick.labelpad = 5          # distance from tickline in points


Hmm, the project is growing.  I think there is something to be said
for doing this axis refactor once, generally, and right, though.

You also have to be a little careful here

      self._tick1PadPixels = self.figure.dpi*Value(tick1Pad)*Value(1/72.0)

because changes to tick11pad will not be reflected in
self._tick1PadPixels.  Compare with

      self.tick1Pad = Value(tick1Pad)
      self._tick1PadPixels = self.figure.dpi*self.tick1Pad*Value(1/72.0)

Then if later on you do self.tick1Pad.set(7) the tick1padPixels attr
is automagically updated

A lot of things I tried to solve with lazy values are addressed by
delegation and observers in traits though, so we may want to go for a
more traity impl.

On a related note, it would be really nice to develop a layout object
that was easy to use that was trait and mpl transform aware, so you
could rather easily say

  val = to_the_right_of(x, 5*points)
  
Lazy values take you part of the way -- we'd also need all objects to
report their extent (pretty easy, but can be expensive for some artist
styles).  With get_extent implemented for all artists, you could build
something like this will lazy values, but the syntax of constructing
these things is a bit awkward, and matplotlib doesn't allow you to use
lazy values and float interchangeably, which would be nice for example
when creating text instances.  So a bit of redesign to support this
kind of layout would make your job a lot easier.

Anyway, more sketchy thoughts that concrete ideas.... Thanks for the
preliminary attempt!

JDh

JDH wrote:

>  I think now is a good time to introduce traits into matplotlib.

The online documentation for traits seems pretty sparse.  Here's the  
best I could track down, Dave Morrill's scipy '04 lightning talk:  
http://www.scipy.org/wikis/scipy04/presentations2004/ 
scipy_conference_2004.pdf

The gist is encapsulated in the following basic usage example.  Whee,  
what fun, strong types with notification in Python!

import traits2

class Person(traits2.HasTraits):
     weight = traits2.Float
     volume = traits2.Range(0.0, 11.0, default=5.0)
     stock = traits2.Trait(None, 0, 1, 2, 3, 'many') # enumerated list
     name = traits2.Str
     # method signatures not included in this example...

joe = Person()
joe.weight = 120.0

def joes_weight_changed(  what, new ):
     print what, 'changed to', new

joe.on_trait_change( joes_weight_changed, 'weight' )
joe.weight = 200.0

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:
    Stephen> Any idea when anonymous CVS from Sourceforge for projects
    Stephen> beginning with m might be available again? I was hoping
    Stephen> you might have "inside information."  At the moment, it
    Stephen> _looks_ like it's working, but in fact an apparently
    Stephen> successful CVS checkout gets 0.72 as of 9 February.

I have no idea when sourceforge will get itself sorted out....

On Friday, I found and fixed the last remaining known bug in the new
log handling.  I've upload the 0.72 release candidate to 

  http://jdh.uchicago.edu/share/matplotlib-0.72rc1.tar.gz

so you can test it out.

Let me know if you see anything unexpected...

JDH

John Hunter wrote:

>I'll probably
>roll out 0.72 tomorrow...
>
Any idea when anonymous CVS from Sourceforge for projects beginning with 
m might be available again? I was hoping you might have "inside 
information."  At the moment, it _looks_ like it's working, but in fact 
an apparently successful CVS checkout gets 0.72 as of 9 February.

Steve

A long winding road out of beta

  Once considered the final stage of software development, beta
  versions are taking on a life of their own, as companies tinker
  endlessly with their products in public.

  Underscoring the trend, Google co-founder Larry Page on Wednesday
  told investors that the beta, or test, stage for its products would
  last as long as its engineers expected to make major changes to
  them--a process that has already taken years, in some cases.

  "It's kind of an arbitrary thing," Page said. "We could take beta
  off all of our products tomorrow, and we wouldn't actually have
  accomplished anything...If it's on there for five years because we
  think we're going to make major changes for five years, that's
  fine. It's really a messaging and branding thing."

Rest of story at http://news.zdnet.com/2100-9588_22-5571590.html

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> However, it looks like onetrue() is never used and
    Steve> alltrue() is used in lines.py and backend_ps.py, but is
    Steve> imported from numerix not cbook - so can these cookbook
    Steve> functions be deleted?

Since we have no way of knowing if code outside matplotlib is using
these, it seems like the path of least resistance is simply to fix the
bug.

JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

    Andrew> So... any takers at performing open-heart surgery on
    Andrew> matplotlib and replacing several of the most critical
    Andrew> parts with (Trait-based) replacements?  (C'mon, John, this
    Andrew> should be easy for neuro-surgery types! :) Or should I
    Andrew> press ahead with the dumb version? ("If you're gonna be
    Andrew> dumb, you gotta be tough")

    Andrew> Any other comments/questions?

I wonder if the current design of an Axis containing a list of ticks
is the best one.  Eg, in the current design each xticklabel can have
it's own color, own y position and own rotation.  In real life these
attributes should be shared, or should be a property of the xaxis.
But rather than refactor this containment relationship which is
documented and is used external code, your idea to use traits is
probably the right way.  Eg, this is a natural place for delegation --
eg the tick line and label locations should delegate to an axis trait.

The rate-limiting step here has not been the application of traits to
matplotlib, it is getting the latest traits package out of the
envisage tree.  I spent some time working on this this morning, and
succeeded in getting the core traits minus the UI component as a
standalone package using plain-ol distutils rather than
scipy_distutils.  I put the tarball here

  http://jdh.uchicago.edu/share/traits2-1.0.2.tar.gz

if you want to play with it.  Also, Abraham, you may want to see if
you can get your config file stuff working with this core.  I think
now is a good time to introduce traits into matplotlib.  I'll probably
roll out 0.72 tomorrow, and am pretty busy this week with real work,
but then we can look into porting all mpl properties to traits.  A
good start would be for you and Abraham to break the ground in your
respective patches and test my traits port.

I posted my port to envisage-dev -- I had to make only a few minor
changes to the traits src to get this to work under python2.2 and to
work w/o the UI package.  I suspect there will be a number of
iterations before we can get a package fully synchronized with
enthought traits, but my guess is that this will not be too long since
they seem receptive to making traits more accessible.  Robert Kern had
the good idea of providing a null UI interface so that the existing
code which uses the UI component would not have to be altered.

Let me know how it goes...

JDH

Hi mplibbies,

I've made a preliminary stab at implementing detachable axis spines, 
and I include a set of patches here.  This is not in a state ready for 
prime-time yet, but is presented here only as a report of progress. The 
biggest question I see is whether now would be a good time to jump to a 
Traits-like mechanism. Things are getting pretty messy in the 
axis.draw() method, and I've really only implemented a fraction of 
what's really desired.  For example, I've hand-coded propagation of the 
axis spine's location to the origin of the ticks, but I haven't 
continued down the chain to the tick labels or the axis label.  
Although I haven't played around with Traits, my feeling is that this 
sort of daisy-chained dependency could be much more easily handled with 
them.

To get this ready for prime time in its current form (without going to 
what I imagine Traits to be), I think it would be a simple but tedious 
and error-prone effort to propagate display coordinates down the 
spine->ticks->ticklabels->axislabel chain in the event of something 
like "gca().xaxis.spineBottomPad=10".  I think I could bite this off in 
the next few days for inclusion into CVS, although I'd be the first to 
agree that it doesn't appear to be the ideal solution that something 
based on Traits does.

So... any takers at performing open-heart surgery on matplotlib and 
replacing several of the most critical parts with (Trait-based) 
replacements?  (C'mon, John, this should be easy for neuro-surgery 
types! :) Or should I press ahead with the dumb version? ("If you're 
gonna be dumb, you gotta be tough")

Any other comments/questions?

Cheers!
Andrew

Here's the code from cbook.py

def alltrue(seq):
    #return true if all elements of seq are true.  If seq is empty return false
    if not len(seq): return False
    for val in seq:
        if not seq: return False
    return True

def onetrue(seq):
    #return true if one elements of seq are true.  If seq is empty return false
    if not len(seq): return False
    for val in seq:
        if seq: return True
    return False

They do not work as intended, for example:
>>> alltrue([False])
True
>>> onetrue([False])
True

I think they should be
        if not val: return False
        if val: return True

However, it looks like onetrue() is never used and alltrue() is used in 
lines.py and backend_ps.py, but is imported from numerix not cbook - so 
can these cookbook functions be deleted?

Regards
Steve

I've got an issue with the font specification for the SVG backend. I'm
not 100% sure it's a bug so I'm posting it for comment. Looking at the
SVG backend code, it should be simple to fix (once the correct answer is
known!). 

I'm using Bitstream Vera Sans as my default font. This gets encoded in
the SVG file as

<text style="font-size: 10.000000; font-family: BitstreamVeraSans-Roman;
stroke-width: 0.5; stroke: #000000; fill: #000000;" x="445.650013"
y="63.225600" >
  My Text Item
</text>

The font-family "Bitstream Vera Sans" is combined with the font-style
"Roman". This doesn't conform to the SVG spec: see
http://www.w3.org/TR/SVG/fonts.html#SVGFonts

it should read something like "... font-family: BitstreamVeraSans; font-
style: roman ..."

When the file is rendered (using either rsvg or inkscape), the actual
font used appears to be "Sans" (similar, but not quite identical to
BitstreamVeraSans).

My second issue is the use of white space & <CR> around the text
characters. When Inkscape renders this, the white space is included and
the carriage return results in a nasty white box character at the end of
each text item. However, rsvg doesn't render this box so things look
OK. 

I can't find anything in the svg spec to indicate that whitespace should
be ignored so I think the <CR>/<LF> and spaces should be removed.
Comments?

Bryan

John Hunter wrote:
>>>>>>"Bryan" == Bryan Cole <bry...@te...> writes:
> 
> 
>     Bryan> The SVG backend, as called from the GUI frame on (GTKAgg),
>     Bryan> doesn't properly close it's file object after writing the
>     Bryan> data.
> 
>     Bryan> I've been wondering why only half my svg-figures are saved
>     Bryan> ... the write-cache wasn't being flushed until the python
>     Bryan> process died.
> 
> It was my understanding that file handles close when they go out of
> scope.

No, this is NOT guaranteed behavior of Python, is implementation dependent (I 
think Jython behaves differently), and I've seen stern warnings from some core 
developers against relying on it.  Matplotlib should explicitly close ALL open 
filehandles, everywhere.

> Is it enough
> to do 
> 
>   svgwriter.close()

Yes, but this should be applied across all file handling operations in the 
codebase.  Otherwise, it's a timebomb waiting to go off (and it will).

Best,

f

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John> Anyone going to pycon?  I'll be giving a talk on matplotlib
    John> on Wednesday --
    John> http://www.python.org/pycon/2005/schedule.html -- and would
    John> enjoy attaching faces to all these posts....

OK, we're official.  We have a wiki!

  http://www.python.org/moin/MatplotlibSprint

Add your name to the list of participants if you want to come!  Even
if you don't think you're ready to contribute code, stop by and say
hello.

JDH

Anyone going to pycon?  I'll be giving a talk on matplotlib on
Wednesday -- http://www.python.org/pycon/2005/schedule.html -- and
would enjoy attaching faces to all these posts....

A sprint might be fun.  It turns out that Monday is the only day I can
do a sprint.  We could do something general purpose like picking goals
off the http://matplotlib.sf.net/goals.html page, or highly focused.
A few ideas, but please throw out more ideas

  * contribute to the user's guide

  * support arbitrary clipping paths

  * gradient fills for polygons

  * provide mathtext fonts that don't have the licensing restrictions
    of bakoma, eg the umbellek fonts

  * unicode support / internationalization
 
  * expose latex/tex when available for mathtext rendering

  * expose agg drawing primitives (paths, etc) directly.  

JDH

>>>>> "Bryan" == Bryan Cole <bry...@te...> writes:

    Bryan> The SVG backend, as called from the GUI frame on (GTKAgg),
    Bryan> doesn't properly close it's file object after writing the
    Bryan> data.

    Bryan> I've been wondering why only half my svg-figures are saved
    Bryan> ... the write-cache wasn't being flushed until the python
    Bryan> process died.

It was my understanding that file handles close when they go out of
scope.  Did you apply a patch that fixed your problem?  Is it enough
to do 

  svgwriter.close()

Is there any chance you are running this app from a threaded shell, eg
ipython in the -pylab mode or -gthread mode?

JDH

The SVG backend, as called from the GUI frame on (GTKAgg), doesn't
properly close it's file object after writing the data.

I've been wondering why only half my svg-figures are saved ... the
write-cache wasn't being flushed until the python process died.

Bryan

Stephen Walton wrote:
> John Hunter wrote:
> 
> 
>>So you're saying you get a segfault on CVS with tkagg?
>>
>>Would you be willing to try a few things
>>
>>* rm -rf site-packages/matplotlib and your build subdir and do a
>>  clean build.  Do you still see the problem?
>> 
>>
> 
> I did both this and rm -rf /usr/share/matplotlib.  This fixed the 
> problem.  I had done 'rpm -U' after "setup.py bdist_rpm" to replace 0.71 
> with 0.72.  I may try to go back and duplicate the problem, but not today.

Don't bother, I doubt you'll be able to.  It was most likely caused by a clash 
with old extension code.  I'm pounding on the TkAgg backend heavily, with 
multiple plot figures open concurrently with multiple MayaVi windows (which 
have VTK render windows embedded), and I don't have any problems (other than a 
VTK window destruction bug John is fixing at this very moment :)

Best,

f

John Hunter wrote:

>So you're saying you get a segfault on CVS with tkagg?
>
>Would you be willing to try a few things
>
> * rm -rf site-packages/matplotlib and your build subdir and do a
>   clean build.  Do you still see the problem?
>  
>
I did both this and rm -rf /usr/share/matplotlib.  This fixed the 
problem.  I had done 'rpm -U' after "setup.py bdist_rpm" to replace 0.71 
with 0.72.  I may try to go back and duplicate the problem, but not today.

John Hunter wrote:
>>>>>>"Stephen" == Stephen Walton <ste...@cs...> writes:
> 
> 
>     Stephen> I appreciate the effort.  It works fine provided I delete
>     Stephen> the line "backend: TkAgg" which I'd had in my
>     Stephen> ~/.matplotlibrc file.  Otherwise I get a core dump.  I
>     Stephen> don't recall why I was using this instead of the default
>     Stephen> GTKAgg backend.
> 
> So you're saying you get a segfault on CVS with tkagg?
> 
> Would you be willing to try a few things
> 
>  * rm -rf site-packages/matplotlib and your build subdir and do a
>    clean build.  Do you still see the problem?

Alternatively, (and this allows you to keep a 'safe' matplotlib in-place, or 
switch to it as needed), my stategy is:

1. Rename site-packages/matplotlib to .ori, and symlink to the CVS tree:

root@planck[site-packages]# d -d matplotlib*
/usr/lib/python2.3/site-packages
lrwxrwxrwx  1 root     51 Feb  7 16:57 matplotlib -> 
/usr/local/installers/src/matplotlib/lib/matplotlib/
drwxr-xr-x  4 fperez 4096 Feb  4 10:01 matplotlib.ori/

2. In the CVS tree, manually symlink all the shared libraries to the path of 
the build dir:

root@planck[matplotlib]# dl
/usr/local/installers/src/matplotlib/lib/matplotlib
lrwxrwxrwx  1 fperez     83 Feb  7 16:59 ft2font.so -> 
/usr/local/installers/src/matplotlib/build/lib.linux-i686-2.3/matplotlib/ft2font.so*
lrwxrwxrwx  1 fperez     87 Feb  7 16:58 _nc_contour.so -> 
/usr/local/installers/src/matplotlib/build/lib.linux-i686-2.3/matplotlib/_nc_contour.so*
lrwxrwxrwx  1 fperez     85 Feb  7 16:58 _nc_image.so -> 
/usr/local/installers/src/matplotlib/build/lib.linux-i686-2.3/matplotlib/_nc_image.so*
lrwxrwxrwx  1 fperez     90 Feb  7 16:58 _nc_transforms.so -> 
/usr/local/installers/src/matplotlib/build/lib.linux-i686-2.3/matplotlib/_nc_transforms.so*


root@planck[matplotlib]# dl backends
/usr/local/installers/src/matplotlib/lib/matplotlib
lrwxrwxrwx  1 fperez    92 Feb  7 16:58 _gtkagg.so -> 
/usr/local/installers/src/matplotlib/build/lib.linux-i686-2.3/matplotlib/backends/_gtkagg.so*
lrwxrwxrwx  1 fperez   100 Feb  9 14:55 _nc_backend_agg.so -> 
/usr/local/installers/src/matplotlib/build/lib.linux-i686-2.3/matplotlib/backends/_nc_backend_agg.so*
lrwxrwxrwx  1 fperez    91 Feb  7 16:58 _tkagg.so -> 
/usr/local/installers/src/matplotlib/build/lib.linux-i686-2.3/matplotlib/backends/_tkagg.so*


These symlinks can be established in 10 seconds with md anc C-x-s.

3. When you do a CVS update in the mpl top-level dir, simply do

rm -rf build
python setup.py build

This will rebuild all the needed extensions, and your symlinks will pick them 
up automagically.

If you ever need to go back to the released mpl, simply repoint the matplotlib 
symlink in site-packages to .ori.


This is the simplest setup I've been able to find to handle transparently CVS 
python code with extensions.  It only breaks if the CVS code springs a new 
extension module (or renames one), but that is fixed in a second with the 
proper new symlink.

Cheers,

f