matplotlib-devel Mailing List for matplotlib

On Thu, Jul 31, 2008 at 10:37 AM, Michael Droettboom <md...@st...> wrote:
> Yes, it looks like _ttconv.cpp is the culprit here.  Sloppy reference
> handling (and I say that as the author of that file...)  I've committed some
> changes to SVN that seem to remove the leaks with memleak_hawaii3.py and the
> PDF and PS backends.

initial tests look good on my end.  thanks!

JDH

Yes, it looks like _ttconv.cpp is the culprit here.  Sloppy reference 
handling (and I say that as the author of that file...)  I've committed 
some changes to SVN that seem to remove the leaks with 
memleak_hawaii3.py and the PDF and PS backends.

Cheers,
Mike

Michael Droettboom wrote:
> I'm just getting back from vacation and will add this to my TODO list.  
> I have some thoughts...
>
> Cheers,
> Mike
>
> Eric Firing wrote:
>   
>> John Hunter wrote:
>>   
>>     
>>> On Sat, Jul 26, 2008 at 7:20 PM, Eric Firing <ef...@ha...> wrote:
>>>
>>>     
>>>       
>>>> The attached script gives a quick and simple illustration of the pdf backend
>>>> memory leak noted earlier by Paul Kienzle.  It seems to be entirely related
>>>> to rendering text.  Adding axes, lines, and images does not seem to matter,
>>>> except insofar as adding an axes will trigger the rendering of text for the
>>>> tick labels.  The leak per loop is roughly proportional to the number of
>>>> *different* characters being rendered--about 100 bytes per character.
>>>>
>>>> I don't think I could find the leak in any reasonable time; I hope someone
>>>> else who is more familiar with the pdf backend and more clever at such
>>>> things will be able to track it down ASAP.
>>>>       
>>>>         
>>> In the past, if I recall correctly, these leaks have been in ttconv,
>>> which is Michael's area of expertise, so let's see if he has any
>>> flashes of insight Monday...  If this is the case it would likely
>>> affect ps and pdf but not the other backends.
>>>
>>> JDH
>>>     
>>>       
>> The ps backend leak with this test is about 70 bytes/loop, and the same 
>> with either 20 or 10 characters, so it may have a different origin than 
>> the pdf leak; with no suptitle at all, the ps backend leak is 0.  svg 
>> and agg are both 0 in this test (with suptitle included).
>>
>> Eric
>>
>> -------------------------------------------------------------------------
>> 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

On Thu, Jul 31, 2008 at 10:05 AM, Michael Droettboom <md...@st...> wrote:
> No, you didn't screw up.  It's just hard to arrive home to a pile of 1000's
> of e-mails... ;)

well, you are pressing through them with a remarkable terminator like
efficiency.

welcome back :-)

JDH

No, you didn't screw up.  It's just hard to arrive home to a pile of 
1000's of e-mails... ;)

Cheers,
Mike

John Hunter wrote:
> On Thu, Jul 31, 2008 at 9:33 AM, Michael Droettboom <md...@st...> wrote:
> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
>   
>>>> line 1072, in transform_point
>>>>     assert len(point) == self.input_dims
>>>>
>>>>         
>> I can't reproduce this here.  Has this been resolved in the meantime?
>>     
>
> Yes, I fixed it -- it was a bug in ticker.py that was calling
> transform_point rather than transform.  I meant to update the list,
> sorry if I screwed up the send button
>
> JDH
>   

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

Aha -- here from John (in another thread) is why those lines were 
commented out:

""""

On Sun, Jul 27, 2008 at 4:24 PM, John Hunter <jd...@gm...> wrote:


> >        if midPoint:
> >            if self.gridOn:
> >                self.gridline.draw(renderer)
> >            if self.tick1On:
> >                self.tick1line.draw(renderer)
> >            if self.tick2On:
> >                self.tick2line.draw(renderer)
>   

For a little extra color on what is going on here -- we don't want to
automatically clip the tick lines to the axes bounding box because
someone might choose the tick direction 'out'.  Since we can't use
graphical clipping, this test is trying to make sure the tick location
is in the view interval before drawing it.  You may want to consider a
overridable method 'is_draw_tick' or something along those lines,
which defaults to::

  mtransforms.interval_contains(self.get_view_interval(), self.get_loc())


""""

So, I suppose we'll need to find another solution other than graphical 
clipping, or a way to do it only when needed to solve the problem at 
hand (in this thread).

Cheers,
Mike

Michael Droettboom wrote:
> (Just back from vacation)
>
> That change was long enough ago that I don't remember the reason -- it 
> may have just been a debugging hack that made its way into the code. 
> Let's leave it uncommented until someone notices breakage... ;)
>
> Cheers,
> Mike
>
> Ryan May wrote:
>   
>> Eric Firing wrote:
>>   
>>     
>>>> Anyone have any ideas?
>>>>       
>>>>         
>>> I don't, but it appears that the set_clip_path method was introduced in 
>>> 4817 by Mike D., complete with the commented-out lines.
>>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?annotate=5651 
>>>
>>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?view=diff&r1=4816&r2=4817 
>>>     
>>>       
>> Uncommenting them doesn't seem to break anything and it solves my 
>> problem as well.  I guess there could be performance impacts so I'll 
>> wait for Mike to weigh in.
>>
>> Ryan
>>
>>   
>>     
>
>   

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

John Hunter wrote:
> On Sat, Jul 26, 2008 at 6:26 PM, John Hunter <jd...@gm...> wrote:
>
>   
>>>  stix_fonts_demo: error
>>>    UnicodeDecodeError: 'rawunicodeescape' codec can't decode
>>>    bytes in position 39-0: \Uxxxxxxxx out of range
>>>       
>
> I'm pretty sure this is the result of a python build that does not
> have support for wide unicode characters (this is a build time
> configuration issue).  It is not really an mpl bug, but I am going to
> comment out the wide unicode line and add the example the
> backend_driver (Michael, is there a way to check and see if the python
> build has support for wide unicode at runtime so this line is included
> conditionally?)
>   
One can use sys.maxunicode.  I've added a check to stix_fonts_demo.py
>   
>>>  symlog_demo: rendering causes the following error
>>>    File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
>>> line 1072, in transform_point
>>>      assert len(point) == self.input_dims
>>>       
>
> I created a ticket on sf
> (http://sourceforge.net/tracker/index.php?func=detail&aid=2029141&group_id=80706&atid=560720)
> and assigned it to Michael since this is his baby.  I also added the
> demo to backend driver (currently failing)
Thanks.  Your fix mentioned in the bug report looks fine.  The reason it 
broke is pretty subtle but I think that's right.  I'll close the bug.

Cheers,
Mike

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

On Thu, Jul 31, 2008 at 9:33 AM, Michael Droettboom <md...@st...> wrote:
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
>>> line 1072, in transform_point
>>>     assert len(point) == self.input_dims
>>>
>
> I can't reproduce this here.  Has this been resolved in the meantime?

Yes, I fixed it -- it was a bug in ticker.py that was calling
transform_point rather than transform.  I meant to update the list,
sorry if I screwed up the send button

JDH

I'm just getting back from vacation and will add this to my TODO list.  
I have some thoughts...

Cheers,
Mike

Eric Firing wrote:
> John Hunter wrote:
>   
>> On Sat, Jul 26, 2008 at 7:20 PM, Eric Firing <ef...@ha...> wrote:
>>
>>     
>>> The attached script gives a quick and simple illustration of the pdf backend
>>> memory leak noted earlier by Paul Kienzle.  It seems to be entirely related
>>> to rendering text.  Adding axes, lines, and images does not seem to matter,
>>> except insofar as adding an axes will trigger the rendering of text for the
>>> tick labels.  The leak per loop is roughly proportional to the number of
>>> *different* characters being rendered--about 100 bytes per character.
>>>
>>> I don't think I could find the leak in any reasonable time; I hope someone
>>> else who is more familiar with the pdf backend and more clever at such
>>> things will be able to track it down ASAP.
>>>       
>> In the past, if I recall correctly, these leaks have been in ttconv,
>> which is Michael's area of expertise, so let's see if he has any
>> flashes of insight Monday...  If this is the case it would likely
>> affect ps and pdf but not the other backends.
>>
>> JDH
>>     
>
> The ps backend leak with this test is about 70 bytes/loop, and the same 
> with either 20 or 10 characters, so it may have a different origin than 
> the pdf leak; with no suptitle at all, the ps backend leak is 0.  svg 
> and agg are both 0 in this test (with suptitle included).
>
> Eric
>
> -------------------------------------------------------------------------
> 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

John Hunter wrote:
>>  symlog_demo: rendering causes the following error
>>    File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
>> line 1072, in transform_point
>>      assert len(point) == self.input_dims
>>     
I can't reproduce this here.  Has this been resolved in the meantime?

Cheers,
Mike

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

Paul Kienzle wrote:
> Hi,
>
> I fixed some of the contains() methods so at least the simple
> cases work.
>
> Degenerate rectangles cause problems in axes_demo:
>
>   
>>>> import matplotlib.patches
>>>> r = matplotlib.patches.Rectangle((0,0),1,0)   
>>>> r.get_transform().inverted()
>>>>         
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py", line 1338, in inverted
>     self._inverted = Affine2D(inv(mtx))
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1.1.0-py2.5-macosx-10.3-fat.egg/numpy/linalg/linalg.py", line 332, in inv
>     return wrap(solve(a, identity(a.shape[0], dtype=a.dtype)))
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1.1.0-py2.5-macosx-10.3-fat.egg/numpy/linalg/linalg.py", line 235, in solve
>     raise LinAlgError, 'Singular matrix'
> numpy.linalg.linalg.LinAlgError: Singular matrix
>   
I see how this works with your example code, but how does this relate to 
axes_demo.py?  I suppose the contains method will have to check for a 
singular matrix and just return False.
   
> I've only gone through the a*.py samples, but there are a few other glitches
> such as not detecting axhline/axvline, not handling rotated text properly,
> and not doing very well on polar plots.  These will have to wait for another
> release.
>   
Agreed.  Though if you can believe it, things are much better than they 
once were, particularly for polygons.

Cheers,
Mike

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

John Hunter wrote:
> I'm not too keen on having general math in one module and matlab
> compatible math in another, in part because this will be confusing to
> folks not too familiar with matlab, and as time passes (I never use it
> anymore) that is starting to include me.  I think we could avoid some
> confusion by simply fixing the docstring in mlab.  So I'd rather put
> all the math stuff in mlab, and possibly pull the geometry specific
> stuff into a separate module.
>   
FWIW, there are also a number of C++ geometry functions in _path.cpp 
that perhaps should be considered in this reorg.

(But I'm just catching up on thousands of e-mails today, so I won't 
comment on the reorg itself <wink>)

Cheers,
Mike

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

There was a thread on this a few weeks ago (which unfortunately I can't 
find).  Supporting wx 2.6 is not a goal for the Wx backend in 0.98.x.  
It is impossible to support matplotlib's new drawing API (which includes 
Bezier curves and alpha transparency) with the old wx API.  If you need 
to use wx 2.6, however, you can use the WxAgg backend, which has the 
added bonus of being faster.

Unfortunately, throwing an exception/warning when using the wx backend 
with wx2.6 fell through the cracks.  I'll add that to SVN.

Cheers,
Mike

David Kaplan wrote:
> Hi,
>
> I am still getting crashes using the WX backend with the latest SVN.
> For example:
>
> In [1]: figure()
> ------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
> line 1092, in _onSize
>     self.draw()
>   File
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
> line 892, in draw
>     self.figure.draw(self.renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
> 724, in draw
>     if self.frameon: self.patch.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
> 257, in draw
>     gc = renderer.new_gc()
>   File
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
> line 366, in new_gc
>     self.gc = GraphicsContextWx(self.bitmap, self)
>   File
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py",
> line 463, in __init__
>     gfx_ctx = wx.GraphicsContext.Create(dc)
> <type 'exceptions.AttributeError'>: 'module' object has no attribute
> 'GraphicsContext'
>
> It appears that this GraphicsContext either isn't in my version of
> wxPython or isn't initialized properly.  Updating to wxPython 2.8 fixed
> the problem, but I think that breaks other things on my system (like
> system tools on Ubuntu that I need to use).  For now I will just use
> 2.8, but I may have to revert.  Is supporting wx 2.6 a goal?
>
> Cheers,
> David
>
> On Thu, 2008-07-24 at 11:55 -0400, Paul Kienzle wrote:
>   
>> On Thu, Jul 24, 2008 at 05:14:42PM +0200, David Kaplan wrote:
>>     
>>> Hi,
>>>
>>> No, it doesn't appear to work with or without my changes.  Also, it
>>> looks to me like the following code is now misplaced in backend_wx.py:
>>>
>>> # Event binding code changed after version 2.5
>>> if wx.VERSION_STRING >= '2.5':
>>>     def bind(actor,event,action,**kw):
>>>         actor.Bind(event,action,**kw)
>>> else:
>>>     def bind(actor,event,action,id=None):
>>>         if id is not None:
>>>             event(actor, id, action)
>>>         else:
>>>             event(actor,action)
>>>
>>> It now appears after some functions not in the class.  Is this OK?
>>>       
>> This code is not part of any class.  Anyway, I moved it to the top
>> of the file.
>>
>>     
>>> Also, I noticed that this defines bind, while elsewhere in the class
>>> self.Bind is used.  Is this correct?  If so, should these other
>>> references perhaps take advantage of your abstraction?
>>>       
>> I've committed a change so that all functions now use 
>>
>>     bind(self, wx.EVT, callback, id=id)
>>
>> rather than
>>
>>     if wx.VERSION_STRING >= '2.5':
>>         self.Bind(wx.EVT,callback,id=id)
>>     else:
>>         wx.EVT(self, id, callback)
>>
>> I'm not set up to test against wx < 2.5, though given its age
>> and the small user base of matplotlib wx, I'm not sure that
>> it is relevant anymore.
>>
>>
>> - Paul
>>
>>     

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

What's happening here is that the Hammer projection uses interpolation 
to make the lines follow the curve of the projection.  Obviously with 
markers, we don't want that interpolation.  The fix is to just use 
transform_points rather than transform_path with markers.  This is now 
fixed in SVN r5934.

Cheers,
Mike

Jae-Joon Lee wrote:
> I forgot to attach the patch.
>
> -JJ
>
>
> On Fri, Jul 25, 2008 at 2:39 AM, Jae-Joon Lee <lee...@gm...> wrote:
>   
>> Hi,
>>
>> While playing a little bit with "custom_projection_example.py", I
>> found that "plot" command with projection="hammer" plots too many
>> markers.
>>
>> For example,
>>
>>    subplot(111, projection="hammer")
>>    grid(True)
>>    p = plot([-1, 1, 1], [-1, -1, 1], "o")
>>    show()
>>
>> plots more than 100 circles, instead of 3. And I presume that this is
>> a bug not a feature.
>> This seems to be because the draw() method of the Line2D class  uses
>> self._transformed_path for plotting Markers, but  number of vertices
>> in the _transformed_path increases in the curved coordinate system as
>> in the example.
>>
>> A patch to fix this is attached. It defines a new property
>> "self._transformed_path_mark" in the recache() method as follows
>>
>>        tr = self.get_transform()
>>        self._transformed_path = TransformedPath(self._path, tr)
>>        self._transformed_path_mark =
>> Path(tr.transform_non_affine(self._path.vertices))
>>
>>
>> and draw() method uses this for plotting markers.
>>
>>                tpath, affine = self._transformed_path_mark, \
>>                                self.get_transform().get_affine()
>>
>> As I'm not 100% sure about how the transform things work, I may have
>> missed something. But I got correct results for cases I tried.
>> So I hope this patch is reviewed and applied.
>>
>> Regards,
>>
>> -JJ
>>
>>     
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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

Arrays are not supported with the built-in math engine. You'll need to 
set math.usetex to True.

Cheers,
Mike

Nils Wagner wrote:
> Hi all,
>
> Is there a way to use
>
> title(r'$ M= I_3 K=\left[\begin{array}{rrr} 2\,k & -k & 0 
> \\ -k & 2\,k+p & -(k+p) \\ 0 & -(k+p) & 
> k+p\end{array}\right]$')
>
> It currently fails with
>
> Exception in Tkinter callback
> Traceback (most recent call last):
>    File 
> "/data/home/nwagner/local/lib/python2.5/lib-tk/Tkinter.py", 
> line 1403, in __call__
>      return self.func(*args)
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
> line 202, in resize
>      self.show()
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
> line 205, in draw
>      FigureCanvasAgg.draw(self)
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 261, in draw
>      self.figure.draw(self.renderer)
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/figure.py", 
> line 759, in draw
>      for a in self.axes: a.draw(renderer)
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/axes.py", 
> line 1514, in draw
>      a.draw(renderer)
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/text.py", 
> line 297, in draw
>      bbox, info = self._get_layout(renderer)
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/text.py", 
> line 197, in _get_layout
>      line, self._fontproperties, 
> ismath=self.is_math_text(line))
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 135, in get_text_width_height_descent
>      self.mathtext_parser.parse(s, self.dpi, prop)
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mathtext.py", 
> line 2735, in parse
>      box = self._parser.parse(s, font_output, fontsize, 
> dpi)
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mathtext.py", 
> line 2208, in parse
>      self._expression.parseString(s)
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 1048, in parseString
>      loc, tokens = self._parse( instring, 0 )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 981, in _parseCache
>      value = self._parseNoCache( instring, loc, doActions, 
> callPreParse )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 924, in _parseNoCache
>      loc,tokens = self.parseImpl( instring, preloc, 
> doActions )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 2559, in parseImpl
>      return self.expr._parse( instring, loc, doActions, 
> callPreParse=False )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 981, in _parseCache
>      value = self._parseNoCache( instring, loc, doActions, 
> callPreParse )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 924, in _parseNoCache
>      loc,tokens = self.parseImpl( instring, preloc, 
> doActions )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 2307, in parseImpl
>      loc, exprtokens = e._parse( instring, loc, doActions 
> )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 981, in _parseCache
>      value = self._parseNoCache( instring, loc, doActions, 
> callPreParse )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 924, in _parseNoCache
>      loc,tokens = self.parseImpl( instring, preloc, 
> doActions )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 2672, in parseImpl
>      loc, tokens = self.expr._parse( instring, loc, 
> doActions, callPreParse=False )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 981, in _parseCache
>      value = self._parseNoCache( instring, loc, doActions, 
> callPreParse )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 924, in _parseNoCache
>      loc,tokens = self.parseImpl( instring, preloc, 
> doActions )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 2307, in parseImpl
>      loc, exprtokens = e._parse( instring, loc, doActions 
> )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 981, in _parseCache
>      value = self._parseNoCache( instring, loc, doActions, 
> callPreParse )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 924, in _parseNoCache
>      loc,tokens = self.parseImpl( instring, preloc, 
> doActions )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 2416, in parseImpl
>      ret = e._parse( instring, loc, doActions )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 981, in _parseCache
>      value = self._parseNoCache( instring, loc, doActions, 
> callPreParse )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 950, in _parseNoCache
>      tokens = fn( instring, tokensStart, retTokens )
>    File 
> "/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mathtext.py", 
> line 1963, in raise_error
>      raise ParseFatalException(msg + "\n" + s)
> ParseFatalException: Expected end of math '$'
>
> -------------------------------------------------------------------------
> 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

(Just back from vacation)

That change was long enough ago that I don't remember the reason -- it 
may have just been a debugging hack that made its way into the code. 
Let's leave it uncommented until someone notices breakage... ;)

Cheers,
Mike

Ryan May wrote:
> Eric Firing wrote:
>   
>>> Anyone have any ideas?
>>>       
>> I don't, but it appears that the set_clip_path method was introduced in 
>> 4817 by Mike D., complete with the commented-out lines.
>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?annotate=5651 
>>
>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?view=diff&r1=4816&r2=4817 
>>     
>
> Uncommenting them doesn't seem to break anything and it solves my 
> problem as well.  I guess there could be performance impacts so I'll 
> wait for Mike to weigh in.
>
> Ryan
>
>   

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

(Sorry for the delay, just back from vacation).

I don't have access to that version of gcc on Solaris to test. However, 
if you find a preprocessor workaround that works for you, I'm happy to 
test it on Linux/Mac/Windows and commit.

Cheers,
Mike

Peter C. Norton wrote:
> On solaris with gcc-4.3.1, the macro __cplusplus is not defined to
> 199711L. This is a long-standing issue with solaris. This doesn't much
> matter on some platforms, but for matplotlib, what is happening to me
> is that through a series of defines and conditionals, the method
> putchar, as used here:
>
> ./ttconv/ttutil.cpp:void TTStreamWriter::putchar(int val)
>
> gets tokenized by the preprocessor into putc by
> /usr/include/iso/stdio_iso.h, here on line 350:
>
> #define putchar(x)      putc((x), stdout)
>
> This only happens if __cplusplus is < 199711L. I'm avoiding this by
> building using the studio C compiler, but I thought I'd mention this
> in case it's possible to detect this during the configuration stage,
> and perhaps wrap with something like:
>
> #ifdef
> #if  __cplusplus <= 199711L
> #undef putchar
> #endif
> #endif
>
> However, I haven't tested this yet. Has anyone else thought about
> this?
>
> Thanks,
>
> -Peter
>
>
>
>
>   

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

On Wed, Jul 30, 2008 at 4:31 PM, Eric Bruning <eri...@gm...> wrote:
> I tried with the Tk backend, and I'm seeing the same problem as Eric F
> has with GTK. The problem seems to be with idle_event not getting
> triggered on some of the backends.
>
> The checkins having to do with idle_event from the end of June
> indicate that idle_event is still somewhat experimental.
>
> What's the current status of idle_event? Can I help in some way?

I was working on idle event, to make a backend neutral api for idle
processing, animation, etc...  There was a particularly nasty problem
with tk since I had to do the threading calls myself and I am no
threading guru, so I reverted some of the changes, mainly because of
the problem of cross thread signal handling blocked the CTRL-C
interrupts.  These changes were added in r5652

  r5652 | jdh2358 | 2008-06-23 16:39:11 -0500 (Mon, 23 Jun 2008) | 1 line

  draft idle/timeout api

and subsequent refactoring

  r5653 | jdh2358 | 2008-06-23 23:17:21 -0500 (Mon, 23 Jun 2008) | 1 line

  replaced idle handler with idle event

but then reverted when Nils reported the CTRL-C bug in

  r5655 | jdh2358 | 2008-06-24 08:56:55 -0500 (Tue, 24 Jun 2008) | 1 line

  removed idle support from tkagg until I figure out interrupts

So the implementation is incomplete and tkagg needs to most work,
since for other GUIs it is fairly easy to pass through the native
enent handling.  I am not sure what the problem is with GTK right now,
and haven't had a chance to look at it.

JDH

I tried with the Tk backend, and I'm seeing the same problem as Eric F
has with GTK. The problem seems to be with idle_event not getting
triggered on some of the backends.

The checkins having to do with idle_event from the end of June
indicate that idle_event is still somewhat experimental.

What's the current status of idle_event? Can I help in some way?

If idle_event can't be made robust, I'll need to look for another
method to address the following problem. When I close off the polygon,
I determined that I needed to fall back to the idle state to be able
to see the closed polygon. My code, itself triggered off a right mouse
click, was apparently blocking drawing to the screen.  It is desirable
to see the closed polygon on screen before the polygon callback in the
event that the callback takes a long time.

Thanks,
Eric

On Wed, Jul 30, 2008 at 10:58 AM, Nils Wagner
<nw...@ia...> wrote:

> Sorry for the delay and thank you for your patience.
> Here is the output of the "never-ending story"

Could you try again with r5932

On Tue, 29 Jul 2008 16:43:42 -0500
  "John Hunter" <jd...@gm...> wrote:
> On Tue, Jul 29, 2008 at 4:38 PM, Paul Kienzle 
><pki...@ni...> wrote:
> 
>> Okay, how about
>>    if not hasattr(self,'IsVisible'):
>>        self.IsVisible = lambda self: True
>> in __init__
>>
>> That way it will always think it is visible.
> 
> OK, Nils, I committed a minor variant of that in r5926. 
> Test again...
> 
> JDH

Hi John,

Sorry for the delay and thank you for your patience.
Here is the output of the "never-ending story"

Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
line 1099, in _onPaint
     self.draw(drawDC=drawDC)
   File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
line 64, in draw
     self.gui_repaint(drawDC=drawDC)
   File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
line 1000, in gui_repaint
     if self.IsShownOnScreen():
TypeError: <lambda>() takes exactly 1 argument (0 given)
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
line 1101, in _onPaint
     self.gui_repaint(drawDC=drawDC)
   File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
line 1000, in gui_repaint
     if self.IsShownOnScreen():
TypeError: <lambda>() takes exactly 1 argument (0 given)
  
BTW, the entries are identical for both revisions.
Is that intended ?

r5923 | jdh2358 | 2008-07-29 20:01:16 +0200 (Di, 29 Jul 
2008) | 1 line

special case contains test for degenerate rectangle
------------------------------------------------------------------------
r5922 | jdh2358 | 2008-07-29 19:47:50 +0200 (Di, 29 Jul 
2008) | 1 line

special case contains test for degenerate rectangle

On Tue, Jul 29, 2008 at 11:12 PM, Eric Firing <ef...@ha...> wrote:
> Eric Bruning wrote:
>>
>> On Tue, Jul 29, 2008 at 10:53 PM, Eric Firing <ef...@ha...> wrote:
>>>
>>> Eric Bruning wrote:
>
>>> I gave it a quick try with gtk backend.  The polygon is drawn based on
>>> clicks, but nothing gets printed.  Is this expected?
>>
>> That is unexpected. The callback should change the color of the
>> lassoed dots (from green to blue, for my default colormap) and print
>> the verts, the coords of the lassoed points, and the 'charge' array.
>>
>> Try adding a print in do_callback. One possibility is that the trigger
>> on idle_event isn't working.
>
> do_callback is not getting run.
>
> Eric

On Wed, Jul 30, 2008 at 5:40 AM, Mark Bakker <ma...@gm...> wrote:
> Hello Eric -
>
> I am interested. I wouldn't mind seeing it in mpl, but before we get there
> is there a chance you may want to share the code with me? I presume it is
> not long.

Hi Mark,

The code was attached to the original post. If you can't dig it out of
the archive, I'll send it personally. Let me know.

> My other question is: why do you want to click a polygon? Wouldn't drawing a
> rectangular box be less stress on your carpal tunnel?

My use case requires selecting from a set of points that are
distributed in a way that is unsuitable for selection with a
rectangle.

(cc'ing the mpl-dev list)
-Eric B

Eric Bruning wrote:
> I wanted something more precise (and easier on the carpal tunnel) than
> the included Lasso widget. Inspired by the existing Lasso, I forked
> out an alternate approach that creates a polygon with mouse clicks and
> returns a list of vertices to a callback function.
> 
> See the attached for a demo. It's been tested with WxAgg running off
> recent svn. I'm using idle_event, which isn't mentioned in the docs
> for the released version.
> 
> If there's interest, I'll put together a patch to add this to widgets.py.

Yes, there is interest--we should have this functionality if it can work 
on all interactive backends.

I gave it a quick try with gtk backend.  The polygon is drawn based on 
clicks, but nothing gets printed.  Is this expected?

Eric

> 
> Thanks,
> Eric B
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

I wanted something more precise (and easier on the carpal tunnel) than
the included Lasso widget. Inspired by the existing Lasso, I forked
out an alternate approach that creates a polygon with mouse clicks and
returns a list of vertices to a callback function.

See the attached for a demo. It's been tested with WxAgg running off
recent svn. I'm using idle_event, which isn't mentioned in the docs
for the released version.

If there's interest, I'll put together a patch to add this to widgets.py.

Thanks,
Eric B

On Tue, Jul 29, 2008 at 4:38 PM, Paul Kienzle <pki...@ni...> wrote:

> Okay, how about
>    if not hasattr(self,'IsVisible'):
>        self.IsVisible = lambda self: True
> in __init__
>
> That way it will always think it is visible.

OK, Nils, I committed a minor variant of that in r5926.  Test again...

JDH

On Tue, Jul 29, 2008 at 08:39:10PM +0200, Nils Wagner wrote:
> On Tue, 29 Jul 2008 13:01:04 -0500
>   "John Hunter" <jd...@gm...> wrote:
> > On Tue, Jul 29, 2008 at 11:19 AM, Nils Wagner
> > <nw...@ia...> wrote:
> > 
> >> Is that correct ?
> >>
> >> I will try it asap.
> >>
> >> Thanks in advance
> > 
> > OK, I just added a compatibility method for 
> >isShownOnScreen.  Can you
> > give svn another test drive with your wx version, Nils?
> > 
> > Thanks,
> > JDH
>   
> Hi John,
> 
> My wxpython version (2.5.3.1) seems to be outdated.
> 
> Anyway, is there any workaround ?
> 
> 
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
> line 2237, in spy
>      b = ishold()
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
> line 466, in ishold
>      return gca().ishold()
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
> line 566, in gca
>      ax =  gcf().gca(**kwargs)
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
> line 270, in gcf
>      return figure()
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
> line 247, in figure
>      FigureClass=FigureClass,
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
> line 125, in new_figure_manager
>      frame = FigureFrameWxAgg(num, fig)
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
> line 1346, in __init__
>      self.canvas = self.get_canvas(fig)
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
> line 32, in get_canvas
>      return FigureCanvasWxAgg(self, -1, fig)
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
> line 701, in __init__
>      self.IsShownOnScreen = self.IsVisible
> AttributeError: 'FigureCanvasWxAgg' object has no 
> attribute 'IsVisible'

Okay, how about
    if not hasattr(self,'IsVisible'):
        self.IsVisible = lambda self: True
in __init__

That way it will always think it is visible.

	- Paul