matplotlib-devel Mailing List for matplotlib (Page 496)

> the next thing to try would be to change
>
>  > +        if self.gtk.pygtk_version >=3D (2,4,0):
>  > +            import gobject
>  > +            gobject.idle_add(self.on_timer)
>
> into
>
>          if self.gtk.pygtk_version >=3D (2,4,0):
>              import gobject
>              gobject.timeout_add(self.TIMEOUT, self.on_timer)

Yup, that does it.

Thanks,
     Charlie

[ moving over to the mpl list, this isn't really ipython-user material]

Fernando Perez wrote:
> Charlie Moad wrote:
> 
>>Works fine with 0.6.15, but it spins with 0.7.0.  It does work with
>>0.7.0, but it just busy waits.  0.6.15 gives a warning:
> 
> 
> Aha!  This is very, very good.  I tried 0.6.15 on my box to see if the 
> segfault also went away, but no luck there.  So we're stuck with debug-by-proxy.
> 
> I've attached the diff for the relevant file, Shell.py, between .6.15 and 
> .7.0.  It's kind of big, but the part that I think matters is only this:
> 
> 
> 
> -    def mainloop(self):
> +    def mainloop(self,sys_exit=0,banner=None):
> +
> +        self._banner = banner
> 
> -        self.gtk.timeout_add(self.TIMEOUT, self.on_timer)
> +        if self.gtk.pygtk_version >= (2,4,0):
> +            import gobject
> +            gobject.idle_add(self.on_timer)
> +        else:
> +            self.gtk.idle_add(self.on_timer)
> 
> 
> See if you can revert back to the timeout_add method and if that helps.

Furthermore, keeping the warning you got in mind:

/usr/lib/python2.4/site-packages/ipython-0.6.15-py2.4.egg/IPython/Shell.py:627:
GtkDeprecationWarning: gtk.timeout_add is deprecated, use
gobject.timeout_add instead
   self.gtk.timeout_add(self.TIMEOUT, self.on_timer)

the next thing to try would be to change

 > +        if self.gtk.pygtk_version >= (2,4,0):
 > +            import gobject
 > +            gobject.idle_add(self.on_timer)

into

         if self.gtk.pygtk_version >= (2,4,0):
             import gobject
             gobject.timeout_add(self.TIMEOUT, self.on_timer)

that might do it.

Cheers,

f

Charlie Moad wrote:
> Works fine with 0.6.15, but it spins with 0.7.0.  It does work with
> 0.7.0, but it just busy waits.  0.6.15 gives a warning:

Aha!  This is very, very good.  I tried 0.6.15 on my box to see if the 
segfault also went away, but no luck there.  So we're stuck with debug-by-proxy.

I've attached the diff for the relevant file, Shell.py, between .6.15 and 
.7.0.  It's kind of big, but the part that I think matters is only this:



-    def mainloop(self):
+    def mainloop(self,sys_exit=0,banner=None):
+
+        self._banner = banner

-        self.gtk.timeout_add(self.TIMEOUT, self.on_timer)
+        if self.gtk.pygtk_version >= (2,4,0):
+            import gobject
+            gobject.idle_add(self.on_timer)
+        else:
+            self.gtk.idle_add(self.on_timer)


See if you can revert back to the timeout_add method and if that helps.

If so, we can try to understand better what the right call to make should be.

Cheers,

f

Hi Fernando, Charlie,

I just updated my svn checkout, and can confirm this behavior with the gtkagg 
backend. If I fall back to ipython 0.6.15, cpu usage remains normal.

Darren

On Wednesday 04 January 2006 13:29, Fernando Perez wrote:
> [ I'm cc-ing the matplotlib list here, in case anyone can help us with this
> one.  The context is: testing the new ipython release candidate from
>
> http://ipython.scipy.org/dist/testing/
>
> Charlie is havig problems with -pylab and the gtk backend.]
>
>
> Hi Charlie,
>
> Charlie Moad wrote:
> >      First of all, thanks as always.  I can't remember the last time I
> > have used the vanilla python shell.
> >      I am trying the rc, and I get 100% cpu usage just by running
> > ipython -pylab.  This is on ubuntu/mpl-cvs/gtkagg.
>
> This has been reported before, and I am not yet sure if the problem is
> ipython or matplotlib.  Unfortunately, on all of my boxes,
> matplotlib/gtkagg just segfaults instantly, so I can't even debug this one.
>
> Help me a little: can you please test back and forth ipython 0.6.15 and
> 0.7.0.rc, without changing anything else?  Is the problem ONLY with 0.7.0?
>
> If that is the case, then I can try to track down what the threading call
> causing the problem might be.  IPython has no C code in it, it only
> initializes the threads system for GTK, but perhaps I'm making an incorrect
> call there.
>
> Any help here would be very welcome.
>
> Cheers,
>
> f
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

Works fine with 0.6.15, but it spins with 0.7.0.  It does work with
0.7.0, but it just busy waits.  0.6.15 gives a warning:

/usr/lib/python2.4/site-packages/ipython-0.6.15-py2.4.egg/IPython/Shell.py:=
627:
GtkDeprecationWarning: gtk.timeout_add is deprecated, use
gobject.timeout_add instead
  self.gtk.timeout_add(self.TIMEOUT, self.on_timer)

I will try to look into it some more.

- Charlie

On 1/4/06, Fernando Perez <Fer...@co...> wrote:
> [ I'm cc-ing the matplotlib list here, in case anyone can help us with th=
is
> one.  The context is: testing the new ipython release candidate from
>
> http://ipython.scipy.org/dist/testing/
>
> Charlie is havig problems with -pylab and the gtk backend.]
>
>
> Hi Charlie,
>
> Charlie Moad wrote:
> >      First of all, thanks as always.  I can't remember the last time I
> > have used the vanilla python shell.
> >      I am trying the rc, and I get 100% cpu usage just by running
> > ipython -pylab.  This is on ubuntu/mpl-cvs/gtkagg.
>
> This has been reported before, and I am not yet sure if the problem is ip=
ython
> or matplotlib.  Unfortunately, on all of my boxes, matplotlib/gtkagg just
> segfaults instantly, so I can't even debug this one.
>
> Help me a little: can you please test back and forth ipython 0.6.15 and
> 0.7.0.rc, without changing anything else?  Is the problem ONLY with 0.7.0=
?
>
> If that is the case, then I can try to track down what the threading call
> causing the problem might be.  IPython has no C code in it, it only
> initializes the threads system for GTK, but perhaps I'm making an incorre=
ct
> call there.
>
> Any help here would be very welcome.
>
> Cheers,
>
> f
>

[ I'm cc-ing the matplotlib list here, in case anyone can help us with this 
one.  The context is: testing the new ipython release candidate from

http://ipython.scipy.org/dist/testing/

Charlie is havig problems with -pylab and the gtk backend.]


Hi Charlie,

Charlie Moad wrote:
>      First of all, thanks as always.  I can't remember the last time I
> have used the vanilla python shell.
>      I am trying the rc, and I get 100% cpu usage just by running
> ipython -pylab.  This is on ubuntu/mpl-cvs/gtkagg.

This has been reported before, and I am not yet sure if the problem is ipython 
or matplotlib.  Unfortunately, on all of my boxes, matplotlib/gtkagg just 
segfaults instantly, so I can't even debug this one.

Help me a little: can you please test back and forth ipython 0.6.15 and 
0.7.0.rc, without changing anything else?  Is the problem ONLY with 0.7.0?

If that is the case, then I can try to track down what the threading call 
causing the problem might be.  IPython has no C code in it, it only 
initializes the threads system for GTK, but perhaps I'm making an incorrect 
call there.

Any help here would be very welcome.

Cheers,

f

Hi Darren,

Darren Dale <dd...@co...> writes:
>On Tuesday 03 January 2006 10:48, Chris Walker wrote:
>>Darren Dale <dd...@co...> writes:
>>
>>>However, mpl uses a latex package called PSFrag to
>>>render the text in an intermediate postscript file, which is not
>>>compatible with pdflatex. Unfortunately, if you embed that intermediate
>>>postscript file in a new document, the text will frequently be upside
>>>down, because PSFrag uses some commands that are illegal in embedded
>>>documents. So by default, mpl uses ghostscript to "distill" the
>>>intermediate postscript file, converting the fonts to outlines and
>>>circumventing the problem.
>>
>>I attach a patch against matplotlib 0.85 that uses a picture
>>environment to position text instead of using psfrag.
>>
>>It isn't complete, and therefore probably shouldn't be applied just yet,
>>but may be a useful starting point. In particular, I haven't taken out
>>the distill code, but suspect that it could be replaced by using the
>>right options to dvips.

It looks like the right command is 'dvips -E'

>>
>>If I had the right dvips command instead of the ghostscript distilling
>>process, would this result in a legal eps file? Ie is this worth pursuing?
>
>Here is a post from way back describing the embedding issue: 
>http://sourceforge.net/mailarchive/message.php?msg_id=12030448
>
>"PSFrag was not designed to do what I am trying to do: 
> generate an eps file that can later be embedded in a document. It uses a 
> number of PostScript operators that are illegal in an eps file: setglobal, 
> statusdict and userdict. Here is the blurb from PostScript Language 
> Reference, Second Edition, Appendix I: setglobal disrupts page independence 
> and nesting of included documents. [...] Creation and modification of global 
> objects are uneffected by save-restore operators."
>
>So, to answer your question, if you need to use a PostScript operator that is 
>illegal in an eps file, it is not worth pursuing. 

Unfortunately, dvips -E always seems to generate files with illegal
operators (see below).

> I think your patched 
>backend_ps.py still generates a .tex file that uses the PSFrag package, which 
>will unavoidably end up using illegal PostScript operators. Is this correct?
>

No. I don't use PSFrag at all (the aim was to avoid the problems you
mention above).

I am however unable to generate a file from tex without statusdict or
userdict in it.

Take the following trivial tex file:

	\documentclass{article}
	\pagestyle{empty}
	\begin{document}
	foo
	\end{document}

If I run

latex
dvips -E

then it still uses statusdict and userdict, though not setglobal:

$ grep statusdict 20d9640a1b4e20b0a71da122eaf41ca7.ps
statusdict/manualfeed true put}B/@copies{/#copies X}B/FMat[1 0 0 -1 0 0]
/Ry X/Rx X V}B statusdict begin/product where{pop false[(Display)(NeXT)


$grep userdict 20d9640a1b4e20b0a71da122eaf41ca7.ps
}if put/ctr ctr 1 add N}B/I{cc 1 add D}B/bop{userdict/bop-hook known{
SI restore userdict/eop-hook known{eop-hook}if showpage}N/@start{
userdict/start-hook known{start-hook}if pop/VResolution X/Resolution X
userdict /end-hook known{end-hook}if


Both are in the section beginning /TeXDict.

In which case, trying to use dvips -E to generate an eps file seems
doomed to failure. Perhaps I have misunderstood the restrictions on 
using statusdict and userdict - if they are really a problem, then what 
is the point of dvips -E?


Chris

Hi all,

as always, in threaded mode ipython creates crash reports for exceptions in 
threads.  I think the one below belongs in the matplotlib court.

Cheers,

f

ps - for ipython 0.7.0 I changed things, so now exceptions in threads will get 
nicely formatted on-screen (including pdb support) instead of dumping these 
bogus crash reports.



-------- Original Message --------
Subject: IPython Crash Report
Date: Tue, 3 Jan 2006 16:55:10 -0500
From: Yoshua Bengio <be...@ir...>
To: fp...@co...

***************************************************************************

IPython post-mortem report

IPython version: 0.6.15

Platform info  : os.name -> posix, sys.platform -> linux2

***************************************************************************

Current user configuration structure:

{'Version': 0,
  'alias': [],
  'args': [],
  'autocall': 1,
  'autoindent': 1,
  'automagic': 1,
  'banner': 1,
  'c': '',
  'cache_size': 1000,
  'classic': 0,
  'color_info': 1,
  'colors': 'Linux',
  'confirm_exit': 1,
  'debug': 0,
  'deep_reload': 0,
  'editor': 'emacs -nw',
  'execfile': [],
  'execute': [''],
  'gthread': 0,
  'help': 0,
  'ignore': 0,
  'import_all': [],
  'import_mod': [],
  'import_some': [[]],
  'include': [],
  'ipythondir': '/u/bengioy/.ipython',
  'log': 0,
  'logfile': '',
  'logplay': '',
  'magic_docstrings': 0,
  'messages': 1,
  'multi_line_specials': 1,
  'nosep': 0,
  'opts': Struct({'pylab': 1}),
  'pdb': 0,
  'pprint': 1,
  'profile': '',
  'prompt_in1': 'In [\\#]: ',
  'prompt_in2': '   .\\D.: ',
  'prompt_out': 'Out[\\#]: ',
  'prompts_pad_left': 1,
  'pylab': 1,
  'qthread': 0,
  'quick': 0,
  'rcfile': 'ipythonrc',
  'readline': 1,
  'readline_merge_completions': 1,
  'readline_omit__names': 0,
  'readline_parse_and_bind': ['tab: complete',
                              '"\\C-l": possible-completions',
                              'set show-all-if-ambiguous on',
                              '"\\C-o": tab-insert',
                              '"\\M-i": "    "',
                              '"\\M-o": "\\d\\d\\d\\d"',
                              '"\\M-I": "\\d\\d\\d\\d"',
                              '"\\C-r": reverse-search-history',
                              '"\\C-s": forward-search-history',
                              '"\\C-p": history-search-backward',
                              '"\\C-n": history-search-forward',
                              '"\\e[A": history-search-backward',
                              '"\\e[B": history-search-forward'],
  'readline_remove_delims': '-/~',
  'screen_length': -2,
  'separate_in': '\n',
  'separate_out': '',
  'separate_out2': '',
  'system_verbose': 0,
  'tk': 0,
  'upgrade': 0,
  'wthread': 0,
  'xmode': 'Context'}

***************************************************************************

Crash traceback:

---------------------------------------------------------------------------
exceptions.TypeError                                     Python 2.4.1: 
/usr/bin/python
                                                    Tue Jan  3 16:55:02 2006
A problem occured executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.

/u/lisa/local/linux-x86_64/lib/python2.3/site-packages/matplotlib/backends/backend_gtk.py 
in expose_event(self=<FigureCanvasGTKAgg object (GtkDrawingArea)>, 
widget=<FigureCanvasGTKAgg object (GtkDrawingArea)>, event=<GdkEvent>)
     262         self._renderer._set_width_height (width, height)
     263         self.figure.draw (self._renderer)
     264
     265
     266     def expose_event(self, widget, event):
     267         """Expose_event for all GTK backends
     268         Should not be overridden.
     269         """
     270         if DEBUG: print 'FigureCanvasGTK.%s' % fn_name()
     271
     272         if not GTK_WIDGET_DRAWABLE(self):
     273             return False
     274
     275         if self._draw_pixmap:
     276             width, height = self.allocation.width, self.allocation.height
--> 277             self._render_figure(width, height)
         self._render_figure = <bound method FigureCanvasGTKAgg._render_figure 
of <FigureCanvasGTKAgg object (GtkDrawingArea) at 0x2aaab2488f00>>
         width = 640
         height = 480
     278             self.window.set_back_pixmap (self._pixmap, False)
     279             self.window.clear()  # draw pixmap as the gdk.Window's bg
     280             self._draw_pixmap = False
     281         else: # workaround pygtk 2.6 problem - bg not being redrawn
     282             self.window.clear_area (event.area.x, event.area.y,
     283                                     event.area.width, event.area.height)
     284
     285         return False # allow signal to propagate further
     286
     287
     288     def print_figure(self, filename, dpi=150, facecolor='w', 
edgecolor='w',
     289                      orientation='portrait'):
     290         # TODO - use gdk print figure?
     291         root, ext = os.path.splitext(filename)
     292         ext = ext[1:]

/u/lisa/local/linux-x86_64/lib/python2.3/site-packages/matplotlib/backends/backend_gtkagg.py 
in _render_figure(self=<FigureCanvasGTKAgg object (GtkDrawingArea)>, 
width=640, height=480)
      76         create_pixmap = False
      77         if width > self._pixmap_width:
      78             # increase the pixmap in 10%+ (rather than 1 pixel) steps
      79             self._pixmap_width  = max (int (self._pixmap_width  * 
1.1), width)
      80             create_pixmap = True
      81
      82         if height > self._pixmap_height:
      83             self._pixmap_height = max (int (self._pixmap_height * 
1.1), height)
      84             create_pixmap = True
      85
      86         if create_pixmap:
      87             if DEBUG: print 'FigureCanvasGTK._render_figure new pixmap'
      88             self._pixmap = gtk.gdk.Pixmap (self.window, 
self._pixmap_width,
      89                                            self._pixmap_height)
      90
---> 91         FigureCanvasAgg.draw(self)
         global FigureCanvasAgg.draw = <unbound method FigureCanvasAgg.draw>
         self = <FigureCanvasGTKAgg object (GtkDrawingArea) at 0x2aaab2488f00>
      92         agg_to_gtk_drawable(self._pixmap, self.renderer._renderer)
      93
      94     def blit(self):
      95         agg_to_gtk_drawable(self._pixmap, self.renderer._renderer)
      96         self.window.set_back_pixmap (self._pixmap, False)
      97         self.window.clear()  # draw pixmap as the gdk.Window's bg
      98         self._draw_pixmap = False
      99
     100     def print_figure(self, filename, dpi=150,
     101                      facecolor='w', edgecolor='w',
     102                      orientation='portrait'):
     103         if DEBUG: print 'FigureCanvasGTKAgg.print_figure'
     104         # delete the renderer to prevent improper blitting after print
     105
     106         root, ext = os.path.splitext(filename)

/u/lisa/local/linux-x86_64/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py 
in draw(self=<FigureCanvasGTKAgg object (GtkDrawingArea)>)
     354     The canvas the figure renders into.  Calls the draw and print fig
     355     methods, creates the renderers, etc...
     356
     357     Public attribute
     358
     359       figure - A Figure instance
     360     """
     361
     362     def draw(self):
     363         """
     364         Draw the figure using the renderer
     365         """
     366         if __debug__: verbose.report('FigureCanvasAgg.draw', 
'debug-annoying')
     367
     368         renderer = self.get_renderer()
--> 369         self.figure.draw(renderer)
         self.figure.draw = <bound method Figure.draw of 
<matplotlib.figure.Figure instance at 0x2aaab248d8c0>>
         renderer = <matplotlib.backends.backend_agg.RendererAgg instance at 
0x2aaab2661e18>
     370
     371     def get_renderer(self):
     372         l,b,w,h = self.figure.bbox.get_bounds()
     373         key = w, h, self.figure.dpi.get()
     374         try: self._lastKey, self.renderer
     375         except AttributeError: need_new_renderer = True
     376         else:  need_new_renderer = (self._lastKey != key)
     377
     378         if need_new_renderer:
     379             self.renderer = RendererAgg(w, h, self.figure.dpi)
     380             self._lastKey = key
     381         return self.renderer
     382
     383     def tostring_rgb(self):
     384         if __debug__: verbose.report('FigureCanvasAgg.tostring_rgb', 
'debug-annoying')

/u/lisa/local/linux-x86_64/lib/python2.3/site-packages/matplotlib/figure.py in 
draw(self=<matplotlib.figure.Figure instance>, 
renderer=<matplotlib.backends.backend_agg.RendererAgg instance>)
     483             # list of (_image.Image, ox, oy)
     484             if not allequal([im.origin for im in self.images]):
     485                 raise ValueError('Composite images with different 
origins not supported')
     486             else:
     487                 origin = self.images[0].origin
     488
     489             ims = [(im.make_image(), im.ox, im.oy) for im in self.images]
     490             im = _image.from_images(self.bbox.height(), 
self.bbox.width(), ims)
     491             im.is_grayscale = False
     492             l, b, w, h = self.bbox.get_bounds()
     493             renderer.draw_image(0, 0, im, origin, self.bbox)
     494
     495
     496
     497         # render the axes
--> 498         for a in self.axes: a.draw(renderer)
         a = <matplotlib.axes.Subplot instance at 0x2aaab248dab8>
         self.axes = [<matplotlib.axes.Subplot instance at 0x2aaab248dab8>]
         a.draw = <bound method Subplot.draw of <matplotlib.axes.Subplot 
instance at 0x2aaab248dab8>>
         renderer = <matplotlib.backends.backend_agg.RendererAgg instance at 
0x2aaab2661e18>
     499
     500         # render the figure text
     501         for t in self.texts: t.draw(renderer)
     502
     503         for legend in self.legends:
     504             legend.draw(renderer)
     505
     506         self.transFigure.thaw()  # release the lazy objects
     507         renderer.close_group('figure')
     508
     509     def get_axes(self):
     510         return self.axes
     511
     512     def legend(self, handles, labels, loc, **kwargs):
     513         """

/u/lisa/local/linux-x86_64/lib/python2.3/site-packages/matplotlib/axes.py in 
draw(self=<matplotlib.axes.Subplot instance>, 
renderer=<matplotlib.backends.backend_agg.RendererAgg instance>)
    1363
    1364
    1365
    1366         artists = []
    1367         artists.extend(self.collections)
    1368         artists.extend(self.patches)
    1369         artists.extend(self.lines)
    1370         artists.extend(self.texts)
    1371
    1372         # keep track of i to guarantee stable sort for python 2.2
    1373         dsu = [ (a.zorder, i, a) for i, a in enumerate(artists)
    1374                 if a not in self.animated]
    1375         dsu.sort()
    1376
    1377         for zorder, i, a in dsu:
-> 1378             a.draw(renderer)
         a.draw = <bound method Text.draw of <matplotlib.text.Text instance at 
0x2aaab2496200>>
         renderer = <matplotlib.backends.backend_agg.RendererAgg instance at 
0x2aaab2661e18>
    1379
    1380         self.title.draw(renderer)
    1381         if 0: bbox_artist(self.title, renderer)
    1382         # optional artists
    1383         for a in self.artists:
    1384             a.draw(renderer)
    1385
    1386
    1387         if self.legend_ is not None:
    1388             self.legend_.draw(renderer)
    1389
    1390
    1391         for table in self.tables:
    1392             table.draw(renderer)
    1393

/u/lisa/local/linux-x86_64/lib/python2.3/site-packages/matplotlib/text.py in 
draw(self=<matplotlib.text.Text instance>, 
renderer=<matplotlib.backends.backend_agg.RendererAgg instance>)
     319                 w, h = renderer.get_text_width_height(
     320                     s, self._fontproperties, ismath)
     321
     322                 renderx, rendery = thisx, thisy
     323                 if renderer.flipy():
     324                     canvasw, canvash = renderer.get_canvas_width_height()
     325                     rendery = canvash-rendery
     326
     327                 renderer.draw_text(gc, renderx, rendery, s,
     328                                    self._fontproperties, angle,
     329                                    ismath)
     330                 thisx += w
     331
     332
     333             return
--> 334         bbox, info = self._get_layout(renderer)
         bbox = undefined
         info = undefined
         self._get_layout = <bound method Text._get_layout of 
<matplotlib.text.Text instance at 0x2aaab2496200>>
         renderer = <matplotlib.backends.backend_agg.RendererAgg instance at 
0x2aaab2661e18>
     335
     336         if ismath=='TeX':
     337             canvasw, canvash = renderer.get_canvas_width_height()
     338             for line, wh, x, y in info:
     339                 x, y = self._transform.xy_tup((x, y))
     340                 if renderer.flipy():
     341                     y = canvash-y
     342                 renderer.draw_tex(gc, x, y, line,
     343                                   self._fontproperties, angle)
     344             return
     345
     346         for line, wh, x, y in info:
     347             x, y = self._transform.xy_tup((x, y))
     348             #renderer.draw_arc(gc, (1,0,0),
     349             #                  x, y, 2, 2, 0.0, 360.0)

/u/lisa/local/linux-x86_64/lib/python2.3/site-packages/matplotlib/text.py in 
_get_layout(self=<matplotlib.text.Text instance>, 
renderer=<matplotlib.backends.backend_agg.RendererAgg instance>)
     147         'Copy properties from t to self'
     148         Artist.update_from(self, other)
     149         self._color = other._color
     150         self._multialignment = other._multialignment
     151         self._verticalalignment = other._verticalalignment
     152         self._horizontalalignment = other._horizontalalignment
     153         self._fontproperties = other._fontproperties.copy()
     154         self._rotation = other._rotation
     155
     156
     157     def _get_layout(self, renderer):
     158
     159         # layout the xylocs in display coords as if angle = zero and
     160         # then rotate them around self._x, self._y
     161
--> 162         key = self.get_prop_tup()
         key = undefined
         self.get_prop_tup = <bound method Text.get_prop_tup of 
<matplotlib.text.Text instance at 0x2aaab2496200>>
     163         if self.cached.has_key(key): return self.cached[key]
     164
     165         horizLayout = []
     166         pad =2
     167         thisx, thisy = self._transform.xy_tup( (self._x, self._y) )
     168         width = 0
     169         height = 0
     170
     171         xmin, ymin = thisx, thisy
     172         if self.is_math_text():
     173             lines = [self._text]
     174         else:
     175             lines = self._text.split('\n')
     176
     177         whs = []

/u/lisa/local/linux-x86_64/lib/python2.3/site-packages/matplotlib/text.py in 
get_prop_tup(self=<matplotlib.text.Text instance>)
     406         return self._horizontalalignment
     407
     408     def get_position(self):
     409         "Return x, y as tuple"
     410         return self._x, self._y
     411
     412     def get_prop_tup(self):
     413         """
     414         Return a hashable tuple of properties
     415
     416         Not intended to be human readable, but useful for backends who
     417         want to cache derived information about text (eg layouts) and
     418         need to know if the text has changed
     419         """
     420
--> 421         x, y = self._transform.xy_tup((self._x, self._y))
         x = undefined
         y = undefined
         self._transform.xy_tup = <built-in method xy_tup of tuple object at 
0x2aaab24c0a28>
         self._x = 1
         self._y = [2, 3]
     422         return (x, y, self._text, self._color,
     423                 self._verticalalignment, self._horizontalalignment,
     424                 hash(self._fontproperties), self._rotation)
     425
     426     def get_text(self):
     427         "Get the text as string"
     428         return self._text
     429
     430     def get_va(self):
     431         'alias for getverticalalignment'
     432         return self.get_verticalalignment()
     433
     434     def get_verticalalignment(self):
     435         "Return the vertical alignment as string"
     436         return self._verticalalignment

TypeError: float() argument must be a string or a number

***************************************************************************

History of session input:
from plot_representation import *
from plot_representation import *
embeddings = [[1,2],[2,3],[1,4]]
names = ['ab','cde','fgh']
classes = [0,1,2]
plot_representation(embeddings,names,classes)

*** Last line of input (may not be in above history):

Hi Chris,

On Tuesday 03 January 2006 10:48, Chris Walker wrote:
> This was originally on Matplotlib-users, but -devel seems more appropriate.
[...]
> Darren Dale <dd...@co...> writes:
> > However, mpl uses a latex package called PSFrag to
> >render the text in an intermediate postscript file, which is not
> > compatible with pdflatex. Unfortunately, if you embed that intermediate
> > postscript file in a new document, the text will frequently be upside
> > down, because PSFrag uses some commands that are illegal in embedded
> > documents. So by default, mpl uses ghostscript to "distill" the
> > intermediate postscript file, converting the fonts to outlines and
> > circumventing the problem.
>
> I attach a patch against matplotlib 0.85 that uses a picture
> environment to position text instead of using psfrag.
>
> It isn't complete, and therefore probably shouldn't be applied just yet,
> but may be a useful starting point. In particular, I haven't taken out
> the distill code, but suspect that it could be replaced by using the
> right options to dvips.
>
> If I had the right dvips command instead of the ghostscript distilling
> process, would this result in a legal eps file? Ie is this worth pursuing?

Here is a post from way back describing the embedding issue: 
http://sourceforge.net/mailarchive/message.php?msg_id=12030448

"PSFrag was not designed to do what I am trying to do: 
 generate an eps file that can later be embedded in a document. It uses a 
 number of PostScript operators that are illegal in an eps file: setglobal, 
 statusdict and userdict. Here is the blurb from PostScript Language 
 Reference, Second Edition, Appendix I: setglobal disrupts page independence 
 and nesting of included documents. [...] Creation and modification of global 
 objects are uneffected by save-restore operators."

So, to answer your question, if you need to use a PostScript operator that is 
illegal in an eps file, it is not worth pursuing. I think your patched 
backend_ps.py still generates a .tex file that uses the PSFrag package, which 
will unavoidably end up using illegal PostScript operators. Is this correct?

Darren

This was originally on Matplotlib-users, but -devel seems more appropriate.


Darren Dale <dd...@co...> writes:
>>On Wednesday 07 December 2005 08:41, Christian Kristukat wrote:
>>
>>Darren Dale wrote:
>>
>>>On Tuesday 06 December 2005 10:03, Christian Kristukat wrote:
>>>
>>>>Darren Dale wrote:
>>>>
>>>>>On Tuesday 06 December 2005 09:10, Alex Gontmakher wrote:
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I'm trying to use matplotlib solely for my plotting needs.
>>>>>>Problem is, the fonts are embedded in each EPS file, and
>>>>>>when I import several plots (I have tens of them...) into a
>>>>>>single Latex, the resulting file is HUGE.
>>>>>>
>>>>>>Any suggestions?
>>>>>
>>>>>There are currently two options: you can either set ps.useafm = True, or
>>>>>you can set text.usetex = True in your rc settings. Since you are
>>>>>importing figures into latex, I suggest the usetex option. That way,
>>>>>your figure fonts can be the same as your text fonts. You'll take a bit
>>>>>of a speed hit with the latter option, but in my opinion, its the only
>>>>>way to go for generating plots for publication.
>>>>
>>>>When using tex for font rendering I noticed that parts of the text are
>>>>not converted to polygons but embedded as bitmaps. That makes the files
>>>>big again. Do you now how to avoid that? E.g. using the r'$C_{12}$ will
>>>>produce two images for the numbers and a polygon for the 'C'.
>>>
>>>I made a wiki entry a while back about how to work around this problem,
>>>but it looks like someone deleted it in mid-November, and I dont have a
>>>backup copy. My solution requires ghostview and xpdf, which is why we
>>>dont include it in mpl by default.
>>
>>Thanks!
>>Has using pdflatex for tex labels been considered? Or is that too much
>>dependency? It could possibly even be faster.
>
>I'm guessing pdflatex is provided by default by every up-to-date latex 
>installation out there.

I believe that the latest version of tetex even uses the same binary for 
latex and pdflatex.

> However, mpl uses a latex package called PSFrag to 
>render the text in an intermediate postscript file, which is not compatible 
>with pdflatex. Unfortunately, if you embed that intermediate postscript file 
>in a new document, the text will frequently be upside down, because PSFrag 
>uses some commands that are illegal in embedded documents. So by default, mpl 
>uses ghostscript to "distill" the intermediate postscript file, converting 
>the fonts to outlines and circumventing the problem.

I attach a patch against matplotlib 0.85 that uses a picture 
environment to position text instead of using psfrag.

It isn't complete, and therefore probably shouldn't be applied just yet, 
but may be a useful starting point. In particular, I haven't taken out 
the distill code, but suspect that it could be replaced by using the 
right options to dvips.

If I had the right dvips command instead of the ghostscript distilling 
process, would this result in a legal eps file? Ie is this worth pursuing?


>
>The code I posted last time replaces the distilling step with a ridiculous 
>renormalization step (converting the file to pdf using ghostscript, and then 
>converting back to eps using xpdf) which generates a new eps file that can be 
>embedded in another document. This seems to be pretty robust, convoluted 
>though it is. I generated all the figures in my dissertation this way.
>
>A side note, if you intend to compile a document with pdflatex, you can 
>convert mpl's eps files with epstopdf, which is included in recent versions 
>of TeTeX.
>

My .tex file does seem to be able to be compiled with pdflatex - if you 
include a .pdf rather than .eps graphic. Whether this is useful or not, 
I'm not sure.

Chris

ps While doing this, I noticed that \paperheight is set to the paper 
width, and vice versa.

>>>>> "Tom" == Tom Loredo <lo...@as...> writes:
    Tom> updating scipy_core.  So I suspect either you'll have to find
    Tom> a more clever way of importing ffts that maintains
    Tom> compatibility across recent inconsistent scipy_core releases,
    Tom> or you'll have to require mpl users to update scipy_core.  A
    Tom> bit of a mess....

I don't see that as a problem -- people who want to use scipy core
should expect to have to update often for the next while, since it is
a new package.

JDH

John Hunter wrote:

> I know there has been some recent discussion and work on the scipy dev
> list about a new package loading scheme, but am not sure what the
> current status is (still in flux, finished).  Robert or Travis, please
> advise about the status of this module, and when you expect a scipy
> release which has the new package loading scheme out.

I think we'll be going through one more iteration, but I won't be able to attend
to it until Jan 3. If we follow my plan, then you would do

  from scipy.corefft import *

No weird import tricks are involved.

-- 
Robert Kern
rob...@gm...

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

> In [4]: import scipy.fftpack
> ------------------------------------------------------------
> Traceback (most recent call last):
>   File "<console>", line 1, in ?
> ImportError: No module named fftpack
> 
> Although scipy.fftpack is defined in 0.8.4, you can't import from it
> like a normal module.

Yes, this has been the subject of attention in the last week
(see e.g. the scipy-dev threads on the location of the random
module, and on "fftpack issues").  They decided to abandon
some of the delayed import magic, and the current SVN checkout
reflects this.  You can now import fftpack as before.  I 
suspect there will be a new release soon after the holiday
reflecting this fix.  Even after such a release, there will
be a problem with folks updating mpl without also updating
scipy_core.  So I suspect either you'll have to find a more
clever way of importing ffts that maintains compatibility
across recent inconsistent scipy_core releases, or you'll
have to require mpl users to update scipy_core.  A bit of
a mess....

-Tom

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    >>  For others trying to use things as they are now, the following
    >> quick fix gets most things to work: Just change __init__.py in
    >> site-packages/matplotlib/numerix/fft from: elif which[0] ==
    >> "scipy": from scipy.basic.fft import * to: elif which[0] ==
    >> "scipy": # from scipy.basic.fft import * from
    >> scipy.basic.fftpack import *
    >> 

    Eric> John,

    Eric> It looks like this could be handled in CVS mpl with:

    Eric> elif which[0] == "scipy": from scipy.fftpack import *

    Eric> scipy itself imports basic.fft (released version) or
    Eric> basic.fftpack (SVN) as fftpack, so there is no need to go to
    Eric> scipy.basic.  Correct?

    Eric> I haven't tested it yet, though.  If no one gets to it
    Eric> sooner, I may be able to take a closer look this evening.

I don't think this works with the latest release

In [2]: import scipy
In [3]: scipy.__core_version__
Out[3]: '0.8.4'
In [4]: import scipy.fftpack
------------------------------------------------------------
Traceback (most recent call last):
  File "<console>", line 1, in ?
ImportError: No module named fftpack

Although scipy.fftpack is defined in 0.8.4, you can't import from it
like a normal module.

JDH

> 
> For others trying to use things as they are now, the following quick
> fix gets most things to work:  Just change __init__.py in 
> site-packages/matplotlib/numerix/fft from:
> 
> elif which[0] == "scipy":
>     from scipy.basic.fft import *
> to: 
> 
> elif which[0] == "scipy":
>     # from scipy.basic.fft import *
>     from scipy.basic.fftpack import *
> 

John,

It looks like this could be handled in CVS mpl with:

elif which[0] == "scipy":
     from scipy.fftpack import *

scipy itself imports basic.fft (released version) or basic.fftpack (SVN) 
as fftpack, so there is no need to go to scipy.basic.  Correct?

I haven't tested it yet, though.  If no one gets to it sooner, I may be 
able to take a closer look this evening.

Eric

John,

Thanks for the clarification---and for responding so close to
the holiday!

> It seems like matplotlib should track released scipy rather than scipy
> svn, but I can see arguments for both sides (matplotlib cvs perhaps
> should track scipy svn, but then we can't do a release until scipy
> does...).

I understand the issue, and it does seem to me you should track
the release.

> I know there has been some recent discussion and work on the scipy dev
> list about a new package loading scheme, but am not sure what the
> current status is (still in flux, finished).

At least part of it was given up on, and I believe Pearu and Travis
checked in those changes a few days ago.  It does sound like it's
time for a new release, provided the scheme has settled.

For others trying to use things as they are now, the following quick
fix gets most things to work:  Just change __init__.py in 
site-packages/matplotlib/numerix/fft from:

elif which[0] == "scipy":
    from scipy.basic.fft import *
to: 

elif which[0] == "scipy":
    # from scipy.basic.fft import *
    from scipy.basic.fftpack import *

Do it in site-packages and not in the distribution, so your
distribution stays in sync with its CVS version.  (I'm not
sure if this matters.)

I don't know if this does all that is required for pylab's fft
stuff (I only use it for plotting), but it does get *most*
examples to plot (I tried a random assortment of them).
However, a few examples do have problems, some trivial, others
perhaps not so.  Some examples:

% pythonw specgram_demo.py 
Traceback (most recent call last):
  File "specgram_demo.py", line 24, in ?
    Pxx, freqs, bins, im = specgram(x, NFFT=NFFT, Fs=Fs, noverlap=900)
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/pylab.py", line 
2206, in specgram
    ret =  gca().specgram(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/axes.py", line 3379, 
in specgram
    window, noverlap)
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/mlab.py", line 1120, 
in specgram
    if x.typecode()==Complex: numFreqs = NFFT
AttributeError: 'scipy.ndarray' object has no attribute 'typecode' 

scipy_core has changed how typecodes are handled so I suspect this
is an inconsistency that will survive revisions.  I don't know what
else in mpl it may affect.

% pythonw boxplot_demo.py 
Traceback (most recent call last):
  File "boxplot_demo.py", line 17, in ?
    boxplot(data)
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/pylab.py", line 
1745, in boxplot
    ret =  gca().boxplot(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/axes.py", line 1061, 
in boxplot
    widths = distance * min(0.15, 0.5/distance)
ZeroDivisionError: float division

I don't know what's behind this.

% pythonw anim.py
The animated plot appears to work fine---what I could see of it!
Its window can't be brought to the front, and won't respond to
clicks on the close button.  I believe this has always happened
and is unrelated to scipy; it's an OS X GUI issue (I'm using TkAgg).

%pythonw dannys_example.py
This failed for me because it is written to explicitly
use Numeric.  A simple change at the top to 
"import matplotlib.numerix as Numeric" has it plot fine with scipy.
Someone should check it with numarray and if it survives, make
the change.

Many other examples worked just fine, with images, contour plots,
histograms, TeX labels, axis tricks, interactivity, etc..  So perhaps 
the only scipy_core changes that are significant for mpl are the fft
module move and the typecode change.

-Tom


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

>>>>> "Tom" == Tom Loredo <lo...@as...> writes:

    Tom> Hi folks,

    Tom> I just installed the latest svn/cvs scipy_core, scipy, and
    Tom> mpl on OS 10.3.9, Py 2.4.1.  There has been some shuffling
    Tom> around of packages and package names in scipy in the last
    Tom> week or two, and finally core+scipy is working without import
    Tom> complaints (though 10 of the fftpack tests fail).  However,
    Tom> now NOTHING requiring pylab works---every attempt to import
    Tom> pylab eventually fails with something like:

    Tom>   File
    Tom> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/
    Tom> __init__.py", line 143, in ?  __import__('fft', g, l) File
    Tom> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/fft/
    Tom> __init__.py", line 8, in ?  from scipy.basic.fft import *
    Tom> ImportError: No module named fft

That is a bit of a problem, since this is correct with the last
released version of scipy

In [1]: import scipy

In [2]: scipy.__core_version__
Out[2]: '0.8.4'

In [3]: from scipy.basic.fft import *

It seems like matplotlib should track released scipy rather than scipy
svn, but I can see arguments for both sides (matplotlib cvs perhaps
should track scipy svn, but then we can't do a release until scipy
does...).

I know there has been some recent discussion and work on the scipy dev
list about a new package loading scheme, but am not sure what the
current status is (still in flux, finished).  Robert or Travis, please
advise about the status of this module, and when you expect a scipy
release which has the new package loading scheme out.

JDH

Hi folks,

I just installed the latest svn/cvs scipy_core, scipy, and mpl
on OS 10.3.9, Py 2.4.1.  There has been some shuffling around
of packages and package names in scipy in the last week or two,
and finally core+scipy is working without import complaints
(though 10 of the fftpack tests fail).  However, now NOTHING
requiring pylab works---every attempt to import pylab eventually
fails with something like:

  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/
__init__.py", line 143, in ?
    __import__('fft', g, l)
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/fft/
__init__.py", line 8, in ?
    from scipy.basic.fft import *
ImportError: No module named fft

Indeed, checking scipy verifies that scipy.basic.fft is now a 
*function* (ifft also); the module is fftpack (or fftpack_lite),
not fft:

>>> import scipy
>>> dir(scipy.basic)
['ScipyTest', '__builtins__', '__doc__', '__file__', '__name__', '__path__', 'fft', 'fftpack', 'fftpack_lite', 
'helper', 'ifft', 'lapack_lite', 'linalg', 'rand', 'randn', 'random', 'test']
>>> scipy.basic.fft
<function fft at 0x515470> 

I don't know who has to sort this out, scipy or mpl developers,
but I sure hope it can be done soon!

Thanks,
Tom


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Oops; evidently tex_demo.py is supposed to *create* the .png
file---my bad.  I was just having permission problems!!

Sorry for the distraction.

-Tom

Hi folks,

Just checked out mpl from CVS; tex_demo.py fails because it
cannot find tex_demo.png, which I know was in there a day or
so ago.  Browsing on the SourceForge CVS portal, it isn't
shown there, so I don't think my CVS ignorance is behind this.
But it may be---let me know if you think so!

-Tom

Jouni K Seppanen <jk...@ik...> writes:

> #include <math.h>
> template<typename T> int mpl_isnan(T arg) { return isnan(arg); }
> #include <cmath>

Nah, that also effectively assumes the GNU libraries. Here's a better
idea:

#include <math.h>
int mpl_isnan_f(float f)        { return isnan(f); }
int mpl_isnan_d(double f)       { return isnan(f); }
int mpl_isnan_ld(long double f) { return isnan(f); }

Compile this as C(99), not C++, and put

extern "C" {
  int mpl_isnan_f(float);
  int mpl_isnan_d(double);
  int mpl_isnan_ld(long double);
}

in the C++ file.

-- 
Jouni

Tom Loredo <lo...@as...> writes:

> I'll try reinstalling the latest TeTeX; if anyone else has had such
> problems, I'd be grateful to know how you fixed them.

FWIW, I've had no problems with Gerben Wierda's i-Installer version of
TeX described at <http://ii2.sourceforge.net/tex-index.html>. I found
the installer program somewhat idiosyncratic, but once you figure that
out, you get a really nice TeX installation.

-- 
Jouni

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

> extern "C" {
> int isnan(double);
> }
>
>>Apparently, the upshot is that isnan is a C99 feature and C++ does not
>>incorporate C99.
>>
> So, does that mean the above should work on most C++ compilers?  (Do
> they implement C99 mode when in extern "C" mode?)  

What extern "C" does is it disables the C++ name-mangling so you can
refer to C functions. The presence of isnan is a header/library issue,
and apparently the cmath header file in some systems makes sure to
hide isnan. It seems that C99 defines an isnan _macro_, and the above
is assuming that an isnan _function_ exists in the library. The isnan
manual page on OS X states:

| HISTORY
|      3BSD introduced isinf() and isnan() functions, which accepted double
|      arguments; these have been superseded by the macros described above.

I don't know how widespread these functions are. GNU libc and OS X
have them, and all the world's either Linux or a Mac, right? :-)

I think we could use the system's isnan macro in a fairly clean way by
performing the following dance (untested, and I don't have an OS X
10.3 system to test on):

#include <math.h>
template<typename T> int mpl_isnan(T arg) { return isnan(arg); }
#include <cmath>

Is it possible in distutils to do autoconf-style compilation tests at
configuration time? 

-- 
Jouni

Andrew,

Thanks for the new patch.  It works fine on OS 10.3.9/Python 2.4,
as far as I can tell.  Cool!

My tex problem that originally motivated
the reinstall appears to be due to problems with my TeTeX 
install (dvipng is not finding mktex.opt and thus creating
blank PNGs, though ).  I'll try reinstalling the latest TeTeX; if
anyone else has had such problems, I'd be grateful to know how
you fixed them.

-Tom


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Referring to this:

>/ #include <math.h>
/32a34,37
>/ extern "C" {
/>/ int isnan(double);
/>/ }

/Jouni K Seppanen wrote:

>I suppose that would work, but then you will take a slight performance
>hit when calling isnan. It's probably not too bad; depends on how
>often it gets called.
>  
>
The code that makes use of isnan is not called enough to be worried 
about a minor speed hit.

>Apparently, the upshot is that isnan is a C99 feature and C++ does not
>incorporate C99.
>
So, does that mean the above should work on most C++ compilers?  (Do 
they implement C99 mode when in extern "C" mode?)  If so, I'm all for 
that approach as abandoning the isnan64 macro I borrowed from numarray. 
I'd rather take the minor speed hit than have all that intricate C 
coding currently in the MPL_isnan.h file.