matplotlib-devel Mailing List for matplotlib (Page 4)

Hi,

Just wanted to note that I committed to SVN a fix to the clabel/ginput
issues previously identified, plus a few more changes I have worked on
along the way.

clabel and ginput now allow you to use the keyboard for selecting,
erasing and ending point input.

I also moved a bunch of functions having to do with numerics and
geometry from cbook and mlab into a separate file called
numerical_methods.py as was discussed a while back.  This is fairly easy
to undo if a problem, but this seems logical to me.

Cheers,
David

-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Hey all -

I'm having some trouble building and installing matplotlib on my  
Macbook Pro running OS X 10.5.4.
I don't understand exactly what the errors are trying to tell me...any  
help is much appreciated!

i686-apple-darwin9-gcc-4.0.1: -framework: linker input file unused  
because linking not done
i686-apple-darwin9-gcc-4.0.1: Tcl: linker input file unused because  
linking not done
i686-apple-darwin9-gcc-4.0.1: -framework: linker input file unused  
because linking not done
i686-apple-darwin9-gcc-4.0.1: Tk: linker input file unused because  
linking not done
powerpc-apple-darwin9-gcc-4.0.1: -framework: linker input file unused  
because linking not done
powerpc-apple-darwin9-gcc-4.0.1: Tcl: linker input file unused because  
linking not done
powerpc-apple-darwin9-gcc-4.0.1: -framework: linker input file unused  
because linking not done
powerpc-apple-darwin9-gcc-4.0.1: Tk: linker input file unused because  
linking not done
g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g - 
bundle -undefined dynamic_lookup build/temp.macosx-10.3-fat-2.5/src/ 
_tkagg.o build/temp.macosx-10.3-fat-2.5/CXX/cxx_extensions.o build/ 
temp.macosx-10.3-fat-2.5/CXX/cxxsupport.o build/temp.macosx-10.3- 
fat-2.5/CXX/IndirectPythonInterface.o build/temp.macosx-10.3-fat-2.5/ 
CXX/cxxextensions.o -L/usr/local/lib -L/usr/lib -L/sw/lib -L/usr/X11R6/ 
lib -L/usr/local/lib -L/usr/lib -L/sw/lib -L/usr/X11R6/lib -lstdc++ - 
lm -lfreetype -lz -lstdc++ -lm -o build/lib.macosx-10.3-fat-2.5/ 
matplotlib/backends/_tkagg.so -framework Tcl -framework Tk
ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libPng.dylib,  
file is not of required architecture for architecture ppc
collect2: ld returned 1 exit status
lipo: can't open input file: /var/folders/U8/U8oYQjnOFIi8el0mQQiHaU++ 
+TI/-Tmp-//ccyj53Iw.out (No such file or directory)
error: command 'g++' failed with exit status 1

Thanks
-Adrian

On Thu, Sep 11, 2008 at 5:49 PM, Ted Drain <ted...@jp...> wrote:
> Mike,
> Thanks for the info.  I noticed in plot_directive.py that ipython seems to
> be required to build the docs.  Is that absolutely needed or is it a
> holdover from doing something else?  I'm asking because we would like to
> build the docs locally but don't currently install ipython.  I could change
> that but it's just an artifact of something else it might be better to
> remove that dependency.

I replaced the ipython shell magic_run functionality with the basic
code.InteractiveConsole.runsource function.  This works fine -- we may
lose some of ipython's nice traceback functionality so if we want we
can have a switch that uses ipython if available and falls back on the
default code module, but for now I have simply removed the ipython
dependency.

For some reason runsource prints the intro docstring to the console
from files passed to runsource -- not sure how suppress this but it is
a minor nuisance.

JDH

On Fri, Sep 12, 2008 at 2:46 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Thanks John,
>
> I think I'd better use a sf patch initially so that you or others can
> review and improve it. I'll definitely need some help with
> documentation as my English can be horrible sometime. On the other
> hand, it would be much easier for me to do some maintenance work if I
> can commit the changes directly. So, my sf id is "leejjoon" and it
> will be great if you add me as a developer.

OK, I added you as a developer, but you continue posting your patches
here and we will be happy to review and comment on them as we have
time.


>  I guess this fancy box thing can be used with other artist objects
> also, although the legend object is an only object I can think of now.
> And my personal inclination is put those support code into patches.py
> and have a patch class around it, i.e., a FancyBoxPatch class which is
> initialized with bbox-like object and draw a fancy box around the
> given bbox. And let the Text and the Legend class use this
> FancyBoxPatch. In the current matplotlib, both the Text and the Legend
> class uses the Patch class for drawing a bbox. So how do you think?

Yes, if you can generalize it to a Patch instance this will be more
useful and then matplotlib.patches will be the place for it.
I notice that your current TextBoxArtist does not actually derive from
matplotlib.artist.Artist.  If you intend it to be an Artist, you
should explictly inherit and implement draw and other required methods
(eg get_children if your Artist contains other artists)

> What I also want to see in matplotlib is a fancy annotation. I have
> some working code (although I'm planning some major code
> reorganization) and willing to contribute it if there is an interest
> (see the attached example). As you can easily guess, the fancy
> annotation share some of its core with the fancy box. So if you're
> also willing to include the fancy annotation things in matplotlib,
> I'll put some more effort in the code reorganization so that it can
> nicely fit in the current matplotlib classes.

These examples look very nice too!  Send in a patch when you have
everything organized.

JDH

Jae-Joon Lee wrote:
>  I guess this fancy box thing can be used with other artist objects
> also, although the legend object is an only object I can think of now.
> And my personal inclination is put those support code into patches.py
> and have a patch class around it, i.e., a FancyBoxPatch class which is
> initialized with bbox-like object and draw a fancy box around the
> given bbox. And let the Text and the Legend class use this
> FancyBoxPatch. In the current matplotlib, both the Text and the Legend
> class uses the Patch class for drawing a bbox. So how do you think?
>   
I like this suggestion.  I can see this being generally useful.
> What I also want to see in matplotlib is a fancy annotation. I have
> some working code (although I'm planning some major code
> reorganization) and willing to contribute it if there is an interest
> (see the attached example). As you can easily guess, the fancy
> annotation share some of its core with the fancy box. So if you're
> also willing to include the fancy annotation things in matplotlib,
> I'll put some more effort in the code reorganization so that it can
> nicely fit in the current matplotlib classes.
>   
Looking forward to it.
> ps. I just wanted to mention that implementing these fancy boxes
> became possible with the bezier path support in matplotlib.  So my
> thanks to Michael.
>   
You're welcome.  It's nice to see others picking this stuff up and 
running with it.

Cheers,
Mike
>
> On Fri, Sep 12, 2008 at 11:45 AM, John Hunter <jd...@gm...> wrote:
>   
>> On Thu, Sep 11, 2008 at 4:19 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>     
>>> Thanks John,
>>>
>>> I'm afraid that I'm not quite sure what you're suggesting, and will be
>>> grateful if you describe it more specifically.
>>>       
>> Sorry Jae-Joon -- I was in a big hurry yesterday (in the financial
>> industry we're a bit busy these days) and I forgot that the
>> mind_reader module had not yet been committed to svn.
>>
>> First, I'd like to say that these boxes look really nice, and I think
>> they enhance presentation charts in many contexts (eg business
>> presentations) so thanks a lot for contributing them.
>>
>> I think the best organization is to put all of this functionality
>> (including the textbox code) into text.py and have the default text
>> instance support both the standard text box (Rectangle) and the
>> enhanced ones you have provided.   So basically, just your text.py
>> patch and move all the support code into text.py.  I'd also like to
>> put your example file in the pylab examples directory and add it to
>> examples/tests/backend_driver.py.
>>
>> If you can do all that and submit it as a sf patch, that would be
>> great.  Alternatively, if you would like to send me your sf id, I can
>> add you as a developer and you can contribute it directly.
>>
>> Thanks again,
>> JDH
>>
>> JDH
>>
>>     
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>     

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Thanks John,

I think I'd better use a sf patch initially so that you or others can
review and improve it. I'll definitely need some help with
documentation as my English can be horrible sometime. On the other
hand, it would be much easier for me to do some maintenance work if I
can commit the changes directly. So, my sf id is "leejjoon" and it
will be great if you add me as a developer.

 I guess this fancy box thing can be used with other artist objects
also, although the legend object is an only object I can think of now.
And my personal inclination is put those support code into patches.py
and have a patch class around it, i.e., a FancyBoxPatch class which is
initialized with bbox-like object and draw a fancy box around the
given bbox. And let the Text and the Legend class use this
FancyBoxPatch. In the current matplotlib, both the Text and the Legend
class uses the Patch class for drawing a bbox. So how do you think?

What I also want to see in matplotlib is a fancy annotation. I have
some working code (although I'm planning some major code
reorganization) and willing to contribute it if there is an interest
(see the attached example). As you can easily guess, the fancy
annotation share some of its core with the fancy box. So if you're
also willing to include the fancy annotation things in matplotlib,
I'll put some more effort in the code reorganization so that it can
nicely fit in the current matplotlib classes.

Regards,

-JJ

ps. I just wanted to mention that implementing these fancy boxes
became possible with the bezier path support in matplotlib.  So my
thanks to Michael.


On Fri, Sep 12, 2008 at 11:45 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Sep 11, 2008 at 4:19 PM, Jae-Joon Lee <lee...@gm...> wrote:
>> Thanks John,
>>
>> I'm afraid that I'm not quite sure what you're suggesting, and will be
>> grateful if you describe it more specifically.
>
> Sorry Jae-Joon -- I was in a big hurry yesterday (in the financial
> industry we're a bit busy these days) and I forgot that the
> mind_reader module had not yet been committed to svn.
>
> First, I'd like to say that these boxes look really nice, and I think
> they enhance presentation charts in many contexts (eg business
> presentations) so thanks a lot for contributing them.
>
> I think the best organization is to put all of this functionality
> (including the textbox code) into text.py and have the default text
> instance support both the standard text box (Rectangle) and the
> enhanced ones you have provided.   So basically, just your text.py
> patch and move all the support code into text.py.  I'd also like to
> put your example file in the pylab examples directory and add it to
> examples/tests/backend_driver.py.
>
> If you can do all that and submit it as a sf patch, that would be
> great.  Alternatively, if you would like to send me your sf id, I can
> add you as a developer and you can contribute it directly.
>
> Thanks again,
> JDH
>
> JDH
>

On Thu, Sep 11, 2008 at 4:19 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Thanks John,
>
> I'm afraid that I'm not quite sure what you're suggesting, and will be
> grateful if you describe it more specifically.

Sorry Jae-Joon -- I was in a big hurry yesterday (in the financial
industry we're a bit busy these days) and I forgot that the
mind_reader module had not yet been committed to svn.

First, I'd like to say that these boxes look really nice, and I think
they enhance presentation charts in many contexts (eg business
presentations) so thanks a lot for contributing them.

I think the best organization is to put all of this functionality
(including the textbox code) into text.py and have the default text
instance support both the standard text box (Rectangle) and the
enhanced ones you have provided.   So basically, just your text.py
patch and move all the support code into text.py.  I'd also like to
put your example file in the pylab examples directory and add it to
examples/tests/backend_driver.py.

If you can do all that and submit it as a sf patch, that would be
great.  Alternatively, if you would like to send me your sf id, I can
add you as a developer and you can contribute it directly.

Thanks again,
JDH

JDH

Hi,

Yes, I have fixed the problem in my version of matplotlib, but I haven't
had the time to look over all of my changes and commit them to SVN.
Next week things should get better.  If you are really in a hurry, you
can try applying the attached patch set to SVN, but better to wait and
let me make sure it is all kosher.

Cheers,
David


On Fri, 2008-09-12 at 11:29 +0200, Mark Bakker wrote:
> Hello David -
> 
> Sorry for the late reply. I am back from vacation.
> 
> Any luck on solving the problem of the disappearing contour lines when
> labelling? It works fine when you don't use the 'inline', but the
> picture is of course not as nice, as the labels are not in-line
> anymore. Maybe that gives a clue to what goes wrong?
> 
> Thanks, Mark
> 
> On Wed, Sep 3, 2008 at 12:47 PM, David M. Kaplan <Dav...@ir...>
> wrote:
>         Hi,
>         
>         Back from vacation.  The problem with not being able to end
>         point
>         selection is easy to fix - allow keyboard clicks to also
>         select points
>         and enter to also exit (this is the solution matlab uses).
>          This is easy
>         to add and I will try to work on it sometime over the next
>         couple of
>         weeks.
>         
>         I will try your example sometime soon and see what happens.
>          It sounds
>         like the problem has something to do with what happens when
>         the label
>         covers the entire contour - currently the contour gets deleted
>         entirely,
>         but this seems to be doing something strange in your case.
>         
>         Cheers,
>         David
>         
>         
>         
>         On Thu, 2008-08-21 at 16:02 +0200, Mark Bakker wrote:
>         > David -
>         >
>         > Enjoy your vacation.
>         >
>         > I tried the contour_label_demo and it works fine, but my
>         problem
>         > remains.
>         >
>         > I suggest you try the example I provided below, and notice
>         the
>         > difference between labeling with inline=True and
>         inline=False. When
>         > inline=True the contours in the middle part (which don't get
>         labeled,
>         > presumably because there isn't enough room) get erased.
>         >
>         > I figured out the manual input problem. The trick is that
>         you require
>         > to press the middle button to end (I'll do a post to the
>         user's list).
>         > Many laptops don't have a middle button. Although
>         suggestions are
>         > found on the web that pushing both buttons simultaneously
>         works, I
>         > have never seen it work. What you have to do is configure
>         your
>         > touchpad such that a corner acts as the middle button. Once
>         I figured
>         > that out, I could end manually selecting the labels. Very
>         nice. If I
>         > may, I strongly recommend you change the code such that
>         pushing the
>         > right button ends the manual input. Is there any reason not
>         to use the
>         > right button for that?
>         >
>         > I hope you can fix the inline problem. Thanks for all the
>         other new
>         > cool features,
>         >
>         > Mark
>         >
>         > On Tue, Aug 19, 2008 at 4:06 PM, <ka...@mp...> wrote:
>         >         Hi,
>         >
>         >         I am currently on vacation, so I can´t be of much
>         help - back
>         >         beginning of next month.  It would be useful if
>         >         you could try the clabel and ginput demo scripts and
>         send
>         >         images of the resulting figures so that we can
>         determine
>         >         exactly what things work and don´t work.
>         >
>         >         Thanks,
>         >         David
>         >
>         >
>         >
>         >         Mark Bakker <ma...@gm...> ha escrito:
>         >
>         >
>         >
>         >                 Hello David and the developers list-
>         >
>         >                 I have had little luck on the mailing list,
>         so sorry
>         >                 for writing you
>         >                 directly (David may be on vacation).
>         >
>         >                 I have two problems labeling contour lines
>         in 0.98.3.
>         >
>         >                 First, when I call clabel, it removes all
>         contours
>         >                 that are not labeled
>         >                 (because the label doesn't fit on the
>         section of
>         >                 contour, I presume).
>         >                 This seems like a bug to me (or a really odd
>         feature).
>         >                 It doesn't do this
>         >                 when inline = False, but I don't think it
>         should do it
>         >                 either when inline =
>         >                 True
>         >                 Easy example:
>         >
>         >                                         x,y =
>         >
>         meshgrid( linspace(-10,10,50),
>         >
>         linspace(-10,10,50) )
>         >                                         z = log(x**2 + y**2)
>         >                                         cobj =
>         contour(x,y,z) # Note
>         >                                         that there are 8
>         contours
>         >                                         levels (11
>         >                 contour sections in all)
>         >                                         cobj.clabel()
>         >                 <a list of 8 text.Text objects>
>         >                                         draw()  # Now only 5
>         contours
>         >                                         are drawn; the ones
>         in the
>         >                                         middle are
>         >                 removed.
>         >
>         >                 Second, when using the new manual labeling
>         of contour
>         >                 labels (which is
>         >                 pretty neat!), how do I end this feature?
>         >                 The doc string says: right click, or
>         potentially click
>         >                 both mouse buttons
>         >                 together (which already worries me).
>         >                 Neither works for me on win32, mpl 0.98.3,
>         TkAgg
>         >                 backend, interactive mode.
>         >                 Does anybody have a solution?
>         >
>         >                 Thanks, Mark
>         >
>         >
>         >
>         >
>         >
>         >
>         ----------------------------------------------------------------
>         >         This message was sent using IMP, the Internet
>         Messaging
>         >         Program.
>         >
>         >
>         >
>         
>         --
>         **********************************
>         David M. Kaplan
>         Charge de Recherche 1
>         Institut de Recherche pour le Developpement
>         Centre de Recherche Halieutique Mediterraneenne et Tropicale
>         av. Jean Monnet
>         B.P. 171
>         34203 Sete cedex
>         France
>         
>         Phone: +33 (0)4 99 57 32 27
>         Fax: +33 (0)4 99 57 32 95
>         http://www.ur097.ird.fr/team/dkaplan/index.html
>         **********************************
>         
>         
> 
> 
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

> Hi,
>    I think there is bug in get_xticklabels(). According to the doc it 
> should return a list of Text instances, instead it returns a list of 
> TextWithDash instances. This also makes the following impossible (which 
> should work of course):
> 
> xtl = ax.get_xticklabels()
> ax.set_xticklabels(xtl)
> 
> Manuel

I just opened a bug #2107138 report to make sure that this is not 
forgotten. I currently have no time to look at this myself :-(

Hello David -

Sorry for the late reply. I am back from vacation.

Any luck on solving the problem of the disappearing contour lines when
labelling? It works fine when you don't use the 'inline', but the picture is
of course not as nice, as the labels are not in-line anymore. Maybe that
gives a clue to what goes wrong?

Thanks, Mark

On Wed, Sep 3, 2008 at 12:47 PM, David M. Kaplan <Dav...@ir...>wrote:

> Hi,
>
> Back from vacation.  The problem with not being able to end point
> selection is easy to fix - allow keyboard clicks to also select points
> and enter to also exit (this is the solution matlab uses).  This is easy
> to add and I will try to work on it sometime over the next couple of
> weeks.
>
> I will try your example sometime soon and see what happens.  It sounds
> like the problem has something to do with what happens when the label
> covers the entire contour - currently the contour gets deleted entirely,
> but this seems to be doing something strange in your case.
>
> Cheers,
> David
>
>
> On Thu, 2008-08-21 at 16:02 +0200, Mark Bakker wrote:
> > David -
> >
> > Enjoy your vacation.
> >
> > I tried the contour_label_demo and it works fine, but my problem
> > remains.
> >
> > I suggest you try the example I provided below, and notice the
> > difference between labeling with inline=True and inline=False. When
> > inline=True the contours in the middle part (which don't get labeled,
> > presumably because there isn't enough room) get erased.
> >
> > I figured out the manual input problem. The trick is that you require
> > to press the middle button to end (I'll do a post to the user's list).
> > Many laptops don't have a middle button. Although suggestions are
> > found on the web that pushing both buttons simultaneously works, I
> > have never seen it work. What you have to do is configure your
> > touchpad such that a corner acts as the middle button. Once I figured
> > that out, I could end manually selecting the labels. Very nice. If I
> > may, I strongly recommend you change the code such that pushing the
> > right button ends the manual input. Is there any reason not to use the
> > right button for that?
> >
> > I hope you can fix the inline problem. Thanks for all the other new
> > cool features,
> >
> > Mark
> >
> > On Tue, Aug 19, 2008 at 4:06 PM, <ka...@mp...> wrote:
> >         Hi,
> >
> >         I am currently on vacation, so I can´t be of much help - back
> >         beginning of next month.  It would be useful if
> >         you could try the clabel and ginput demo scripts and send
> >         images of the resulting figures so that we can determine
> >         exactly what things work and don´t work.
> >
> >         Thanks,
> >         David
> >
> >
> >
> >         Mark Bakker <ma...@gm...> ha escrito:
> >
> >
> >
> >                 Hello David and the developers list-
> >
> >                 I have had little luck on the mailing list, so sorry
> >                 for writing you
> >                 directly (David may be on vacation).
> >
> >                 I have two problems labeling contour lines in 0.98.3.
> >
> >                 First, when I call clabel, it removes all contours
> >                 that are not labeled
> >                 (because the label doesn't fit on the section of
> >                 contour, I presume).
> >                 This seems like a bug to me (or a really odd feature).
> >                 It doesn't do this
> >                 when inline = False, but I don't think it should do it
> >                 either when inline =
> >                 True
> >                 Easy example:
> >
> >                                         x,y =
> >                                         meshgrid( linspace(-10,10,50),
> >                                         linspace(-10,10,50) )
> >                                         z = log(x**2 + y**2)
> >                                         cobj = contour(x,y,z) # Note
> >                                         that there are 8 contours
> >                                         levels (11
> >                 contour sections in all)
> >                                         cobj.clabel()
> >                 <a list of 8 text.Text objects>
> >                                         draw()  # Now only 5 contours
> >                                         are drawn; the ones in the
> >                                         middle are
> >                 removed.
> >
> >                 Second, when using the new manual labeling of contour
> >                 labels (which is
> >                 pretty neat!), how do I end this feature?
> >                 The doc string says: right click, or potentially click
> >                 both mouse buttons
> >                 together (which already worries me).
> >                 Neither works for me on win32, mpl 0.98.3, TkAgg
> >                 backend, interactive mode.
> >                 Does anybody have a solution?
> >
> >                 Thanks, Mark
> >
> >
> >
> >
> >
> >         ----------------------------------------------------------------
> >         This message was sent using IMP, the Internet Messaging
> >         Program.
> >
> >
> >
> --
> **********************************
> David M. Kaplan
> Charge de Recherche 1
> Institut de Recherche pour le Developpement
> Centre de Recherche Halieutique Mediterraneenne et Tropicale
> av. Jean Monnet
> B.P. 171
> 34203 Sete cedex
> France
>
> Phone: +33 (0)4 99 57 32 27
> Fax: +33 (0)4 99 57 32 95
> http://www.ur097.ird.fr/team/dkaplan/index.html
> **********************************
>
>
>

Hi,

I just tried ginput with the latest SVN (gtkagg backend) and it seemed
to work fine.  I recently have had problems with numpy, scipy,
matplotlib and/or wx getting out of sync in terms of binary
compatibility.  Perhaps a rebuild of one or more of those will fix
things for you?

Cheers,
David

On Thu, 2008-09-11 at 11:13 -0700,
mat...@li... wrote:
> Message: 2
> Date: Tue, 9 Sep 2008 17:18:05 +0200
> From: " St?fan van der Walt " <st...@su...>
> Subject: [matplotlib-devel] Ginput bug
> To: mat...@li...
> Message-ID:
>         <945...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi all,
> 
> I noticed that `ginput` no longer works (tested with SVN trunk).  Is
> this a known problem?
> 
> Kind regards,
> St?fan
> 
> ---------------------------------------------------------------------------
> PyDeadObjectError                         Traceback (most recent call
> last)
> 
> /Users/stefan/<ipython console> in <module>()
> 
> /Users/stefan/lib/python2.5/site-packages/matplotlib/pyplot.pyc in
> ginput(*args, **kwargs)
>     353     If *timeout* is negative, does not timeout.
>     354     """
> --> 355     return gcf().ginput(*args, **kwargs)
>     356 if Figure.ginput.__doc__ is not None:
>     357     ginput.__doc__ = dedent(Figure.ginput.__doc__)
> 
> /Users/stefan/lib/python2.5/site-packages/matplotlib/figure.pyc in
> ginput(self, n, timeout, show_clicks)
>    1039         blocking_mouse_input = BlockingMouseInput(self)
>    1040         return blocking_mouse_input(n=n, timeout=timeout,
> -> 1041                                     show_clicks=show_clicks)
>    1042
>    1043     def waitforbuttonpress(self, timeout=-1):
> 
> /Users/stefan/lib/python2.5/site-packages/matplotlib/blocking_input.pyc
> in __call__(self, n, timeout, show_clicks)
>     235         self.clicks      = []
>     236         self.marks       = []
> --> 237         BlockingInput.__call__(self,n=n,timeout=timeout)
>     238
>     239         return self.clicks
> 
> /Users/stefan/lib/python2.5/site-packages/matplotlib/blocking_input.pyc
> in __call__(self, n, timeout)
>     105         finally: # Run even on exception like ctrl-c
>     106             # Disconnect the callbacks
> --> 107             self.cleanup()
>     108
>     109         # Return the events in this case
> 
> /Users/stefan/lib/python2.5/site-packages/matplotlib/blocking_input.pyc
> in cleanup(self)
>     222                 mark.remove()
>     223             self.marks = []
> --> 224             self.fig.canvas.draw()
>     225
>     226         # Call base class to remove callbacks
> 
> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core.pyc
> in __getattr__(self, *args)
>   14312         if not hasattr(self, "_name"):
>   14313             self._name = "[unknown]"
> > 14314         raise PyDeadObjectError(self.attrStr % self._name)
>   14315
>   14316     def __nonzero__(self):
> 
> PyDeadObjectError: The C++ part of the FigureCanvasWxAgg object has
> been deleted, attribute access no longer allowed.
> 
> 
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Mike,
Thanks for the info.  I noticed in plot_directive.py that ipython seems to
be required to build the docs.  Is that absolutely needed or is it a
holdover from doing something else?  I'm asking because we would like to
build the docs locally but don't currently install ipython.  I could change
that but it's just an artifact of something else it might be better to
remove that dependency.

Ted

> -----Original Message-----
> From: Michael Droettboom [mailto:md...@st...]
> Sent: Thursday, September 11, 2008 5:50 AM
> To: Ted Drain
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] Question about sphinx doc extensions
> 
> Ted Drain wrote:
> > We're in the process of converting our documentation from doxygen
> (parsing C++ and post processing w/ many huge regexp's to make it look
> like python) to using sphinx.  I was curious about the equation
> formatting extension that you guys wrote and how it compares to the one
> (or is it two?) that come with sphinx.
> Sphinx can a) use jsmath to render math directly in the browser, b) use
> latex/dvipng to generate images that are included in the HTML.
> Matplotlib's mplmath extension uses matplotlib itself to generate
> images
> of the math to include in the HTML.  All of them have pros and cons,
> mostly related to environment/installation concerns.  The extensions
> are
> generally interchangable (you should be able to use any one of them on
> the same reST source code), however the mplmath extension is currently
> lagging behind the Sphinx ones in some optional features at the moment.
> But our goal is to try to not break compatibility with the Sphinx
> built-in ones so they remain interchangeable.
> >   What didn't work about the sphinx math extensions that caused you
> to write a new one?
> When we wrote ours, a Sphinx math extension didn't exist.  Also, for
> us,
> generating math expressions using our own system is a form of
> regression
> testing.
> >  Are there any plans to incorporate some of the MPL extensions into
> sphinx?
> >
> We've submitted all of our generally useful ones to Sphinx.  For math,
> Sphinx decided to go another way (which makes sense to avoid a
> dependency on matplotlib).
> 
> The inheritance diagram submission seems to have stalled -- there are a
> few people with slightly different views on the problem creating a bit
> of a logjam, but I don't think it's insurmountable.
> 
> Lastly, the ipython syntax-highlighting work we did is in Pygments
> repository and primed for the next release.
> > We'll definitely need latex equations, testing of examples (maybe
> some combination of the MPL plot and doctest like functions), and
> inheritance diagrams so we might just use the MPL sphinx extensions for
> these.
> >
> > We're also planning on making some custom html templates to make our
> output more like doxygen (especially having a class summary showing all
> the methods at the top of the screen).  We may also look at processing
> our users guide, our python module, matplotlib, python, and any other
> 3rd party package we install that uses sphinx (and maybe some that
> don't) to create a single set of docs showing all the python modules we
> deliver that has a common look to it.
> >
> I'd like to hear about your experiences doing this kind of integration
> work.  It's something we all want more of.
> 
> Cheers,
> Mike
> 
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
> 
> Checked by AVG - http://www.avg.com
> Version: 8.0.169 / Virus Database: 270.6.20/1666 - Release Date:
> 9/11/2008 7:03 AM

Thanks John,

I'm afraid that I'm not quite sure what you're suggesting, and will be
grateful if you describe it more specifically.

As of now, textbox.py has two classes (+Text class which is not needed
with text.py patch).

 TextBoxBase and its derivatives : despite its name (which could be a
poor choice), the whole purpose of this class is to produce a Path
around any given square box (like bbox).

 TextBoxArtist : The instance of this class a callable object which
creates a PathPatch object and draw it around the given Text instance.
This is to simulate the patches.bbox_artist() function.

So, could you elaborate how you want things arranged?

Regards,

-JJ







On Thu, Sep 11, 2008 at 4:07 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Sep 11, 2008 at 1:13 PM, Jae-Joon Lee <lee...@gm...> wrote:
>
>> It would be good if these can be included in the matplotlib. At least,
>> can the patch for the text.py be applied?
>
> I am happy to include this functionality, but let's build it into the
> standard bbox rather than introduce a new subclass.  I see no reason
> why they need to be separated.
>
> JDH
>

On Thu, Sep 11, 2008 at 1:13 PM, Jae-Joon Lee <lee...@gm...> wrote:

> It would be good if these can be included in the matplotlib. At least,
> can the patch for the text.py be applied?

I am happy to include this functionality, but let's build it into the
standard bbox rather than introduce a new subclass.  I see no reason
why they need to be separated.

JDH

Hello,

The attached are a small subclass of matplotlib.text.Text I have
created which draws a (somewhat) fancy box around the text (see the
attached example ). This is similar to the current implementation of
bbox drawing in matpliotlib.text.Text class. A few differences are,

 * how the rotation is handled. The box is also rotated
 * optional shadow.

I also attach a small patch to text.py, which enables a use of a
custom bbox_artist.

A simple example,

    from textbox import Text, TextBoxArtist, RoundBox

    t = Text(0., 0., "test", size=20, rotation=30.,
                bbox = dict(artist=TextBoxArtist(RoundBox()))
                )
    gca().add_artist(t)

With the text.py patch, you may do

    from textbox import TextBoxArtist, RoundBox

    gca().text(0., 0., "test", size=20, rotation=30.,
                bbox = dict(artist=TextBoxArtist(RoundBox()))
                )

More examples are found in the example file attached. And with some
creativity, you can make your own fancy box.

It would be good if these can be included in the matplotlib. At least,
can the patch for the text.py be applied?
Regards,

-JJ

Hi guys-
I'm sure you all have seen this so this information is nothing new. I've
been playing with Art Of Illusion and it occurred to me that it's *very
easy* to script/manipulate 3d objects in this environment, and that they
have also implemented a very elegant way of mapping data into colors
graphically using procedural textures or materials. When it comes time I
will figure out how to get my data into this program so I can have 3-d shiny
landscapes like matlab makes for all the stm images.

But when that happens it will be a total hack job that won't be usable to
most people (probably exporting an image file from python and importing it
to AOI). :)

Anyway, AOI is open source, so I thought if someone was passionate about
this functionality they could write an interface into matplotlib.

Cheers!
Jack

Ted Drain wrote:
> We're in the process of converting our documentation from doxygen (parsing C++ and post processing w/ many huge regexp's to make it look like python) to using sphinx.  I was curious about the equation formatting extension that you guys wrote and how it compares to the one (or is it two?) that come with sphinx.
Sphinx can a) use jsmath to render math directly in the browser, b) use 
latex/dvipng to generate images that are included in the HTML.  
Matplotlib's mplmath extension uses matplotlib itself to generate images 
of the math to include in the HTML.  All of them have pros and cons, 
mostly related to environment/installation concerns.  The extensions are 
generally interchangable (you should be able to use any one of them on 
the same reST source code), however the mplmath extension is currently 
lagging behind the Sphinx ones in some optional features at the moment.  
But our goal is to try to not break compatibility with the Sphinx 
built-in ones so they remain interchangeable.
>   What didn't work about the sphinx math extensions that caused you to write a new one? 
When we wrote ours, a Sphinx math extension didn't exist.  Also, for us, 
generating math expressions using our own system is a form of regression 
testing.
>  Are there any plans to incorporate some of the MPL extensions into sphinx?
>   
We've submitted all of our generally useful ones to Sphinx.  For math, 
Sphinx decided to go another way (which makes sense to avoid a 
dependency on matplotlib). 

The inheritance diagram submission seems to have stalled -- there are a 
few people with slightly different views on the problem creating a bit 
of a logjam, but I don't think it's insurmountable. 

Lastly, the ipython syntax-highlighting work we did is in Pygments 
repository and primed for the next release.
> We'll definitely need latex equations, testing of examples (maybe some combination of the MPL plot and doctest like functions), and inheritance diagrams so we might just use the MPL sphinx extensions for these.
>
> We're also planning on making some custom html templates to make our output more like doxygen (especially having a class summary showing all the methods at the top of the screen).  We may also look at processing our users guide, our python module, matplotlib, python, and any other 3rd party package we install that uses sphinx (and maybe some that don't) to create a single set of docs showing all the python modules we deliver that has a common look to it.
>   
I'd like to hear about your experiences doing this kind of integration 
work.  It's something we all want more of.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

We're in the process of converting our documentation from doxygen (parsing C++ and post processing w/ many huge regexp's to make it look like python) to using sphinx.  I was curious about the equation formatting extension that you guys wrote and how it compares to the one (or is it two?) that come with sphinx.  What didn't work about the sphinx math extensions that caused you to write a new one?  Are there any plans to incorporate some of the MPL extensions into sphinx?

We'll definitely need latex equations, testing of examples (maybe some combination of the MPL plot and doctest like functions), and inheritance diagrams so we might just use the MPL sphinx extensions for these.

We're also planning on making some custom html templates to make our output more like doxygen (especially having a class summary showing all the methods at the top of the screen).  We may also look at processing our users guide, our python module, matplotlib, python, and any other 3rd party package we install that uses sphinx (and maybe some that don't) to create a single set of docs showing all the python modules we deliver that has a common look to it.

Thanks,
Ted

Michael Droettboom <md...@st...> writes:

> One small note -- the PDF output was broken for acroread (but strangely 
> not for xpdf), since it was outputting 8 values rather than 6 for the 
> converted quadratic curves.  I've fixed this in SVN.

Thanks for fixing this -- Apple's Preview also showed the broken files
with no problems.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi all,

I noticed that `ginput` no longer works (tested with SVN trunk).  Is
this a known problem?

Kind regards,
Stéfan

---------------------------------------------------------------------------
PyDeadObjectError                         Traceback (most recent call last)

/Users/stefan/<ipython console> in <module>()

/Users/stefan/lib/python2.5/site-packages/matplotlib/pyplot.pyc in
ginput(*args, **kwargs)
    353     If *timeout* is negative, does not timeout.
    354     """
--> 355     return gcf().ginput(*args, **kwargs)
    356 if Figure.ginput.__doc__ is not None:
    357     ginput.__doc__ = dedent(Figure.ginput.__doc__)

/Users/stefan/lib/python2.5/site-packages/matplotlib/figure.pyc in
ginput(self, n, timeout, show_clicks)
   1039         blocking_mouse_input = BlockingMouseInput(self)
   1040         return blocking_mouse_input(n=n, timeout=timeout,
-> 1041                                     show_clicks=show_clicks)
   1042
   1043     def waitforbuttonpress(self, timeout=-1):

/Users/stefan/lib/python2.5/site-packages/matplotlib/blocking_input.pyc
in __call__(self, n, timeout, show_clicks)
    235         self.clicks      = []
    236         self.marks       = []
--> 237         BlockingInput.__call__(self,n=n,timeout=timeout)
    238
    239         return self.clicks

/Users/stefan/lib/python2.5/site-packages/matplotlib/blocking_input.pyc
in __call__(self, n, timeout)
    105         finally: # Run even on exception like ctrl-c
    106             # Disconnect the callbacks
--> 107             self.cleanup()
    108
    109         # Return the events in this case

/Users/stefan/lib/python2.5/site-packages/matplotlib/blocking_input.pyc
in cleanup(self)
    222                 mark.remove()
    223             self.marks = []
--> 224             self.fig.canvas.draw()
    225
    226         # Call base class to remove callbacks

/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core.pyc
in __getattr__(self, *args)
  14312         if not hasattr(self, "_name"):
  14313             self._name = "[unknown]"
> 14314         raise PyDeadObjectError(self.attrStr % self._name)
  14315
  14316     def __nonzero__(self):

PyDeadObjectError: The C++ part of the FigureCanvasWxAgg object has
been deleted, attribute access no longer allowed.

Me, too, now as well.

John Hunter wrote:
> On Tue, Sep 9, 2008 at 7:43 AM, Michael Droettboom <md...@st...> wrote:
>   
>> I'm getting a 404 error from http://matplotlib.sf.net/
>>
>> Is this just Sourceforge suffering an outage or did the content
>> accidentally get removed?
>>     
>
> It seems like a blip because it is up (for me) now
>
> JDH
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, Sep 9, 2008 at 7:43 AM, Michael Droettboom <md...@st...> wrote:
> I'm getting a 404 error from http://matplotlib.sf.net/
>
> Is this just Sourceforge suffering an outage or did the content
> accidentally get removed?

It seems like a blip because it is up (for me) now

JDH

I'm getting a 404 error from http://matplotlib.sf.net/

Is this just Sourceforge suffering an outage or did the content 
accidentally get removed?

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Thanks for taking this on.  That was completely my bad -- I put that 
code in there as a reasonable approximation and meant to go back and fix 
it, but it fell through the cracks.

One small note -- the PDF output was broken for acroread (but strangely 
not for xpdf), since it was outputting 8 values rather than 6 for the 
converted quadratic curves.  I've fixed this in SVN.

Cheers,
Mike

Jouni K. Seppänen wrote:
> "Jae-Joon Lee" <lee...@gm...> writes:
>
>   
>> I'm attaching a patch (for pdf and ps backends) which I believe
>> correctly handle this.
>> I hope this patch is reviewed and applied. Note that the function
>> _quad2cubic is duplicated in both backends. This function might be
>> moved to some common place.
>>     
>
> Looks good. I applied this, with the quad2cubic function moved to
> cbook.py and your test case included in the examples directory. Thanks!
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,

I apologize for the false alarm - the problem seems to have been somehow
due to my versions of numpy, scipy and matplotlib getting out of sync.
It now appears to be fixed.

Cheers,
David



On Mon, 2008-09-08 at 13:04 -0400, Jae-Joon Lee wrote:
> >
> > I am getting errors any time I try to plot with markers for the points
> > (using the GTKAgg backend).  My SVN repo copy has a lot of my own
> > changes in it, but I don't think these errors are associated with those
> > changes.  Can someone confirm this is a bug?  Example below.
> 
> I also don't see that error.
> Is your matplotlib code up to date?
> There has been a bug which might be related with yours (at least the
> raised Exception is same), but this has been fixed in the current SVN.
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=6e8d907b0808181233g4657bd05ybbc2fe8caf8fe68e%40mail.gmail.com&forum_name=matplotlib-devel
> 
> -JJ
> 
> 
> 
> 
> 
> 
> 
> >
> > Thanks,
> > David
> >
> > In [16]: clf(),plot([1,2],[1,2],'--')
> > Out[16]: (None, [<matplotlib.lines.Line2D object at 0x9522d4c>])
> >
> > In [17]: clf(),plot([1,2],[1,2],'--o')
> > ------------------------------------------------------------
> > Traceback (most recent call last):
> >  File
> > "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py",
> > line 333, in expose_event
> >    self._render_figure(self._pixmap, w, h)
> >  File
> > "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", line 75, in _render_figure
> >    FigureCanvasAgg.draw(self)
> >  File
> > "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
> > line 261, in draw
> >    self.figure.draw(self.renderer)
> >  File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
> > 759, in draw
> >    for a in self.axes: a.draw(renderer)
> >  File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1525,
> > in draw
> >    a.draw(renderer)
> >  File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 439,
> > in draw
> >    markerFunc(renderer, gc, tpath, affine.frozen())
> >  File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 752,
> > in _draw_circle
> >    rgbFace)
> > <type 'exceptions.ValueError'>: Codes array is wrong length
> >
> > Out[17]: (None, [<matplotlib.lines.Line2D object at 0x95b1dcc>])
> >
> > --
> > **********************************
> > David M. Kaplan
> > Charge de Recherche 1
> > Institut de Recherche pour le Developpement
> > Centre de Recherche Halieutique Mediterraneenne et Tropicale
> > av. Jean Monnet
> > B.P. 171
> > 34203 Sete cedex
> > France
> >
> > Phone: +33 (0)4 99 57 32 27
> > Fax: +33 (0)4 99 57 32 95
> > http://www.ur097.ird.fr/team/dkaplan/index.html
> > **********************************
> >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************