matplotlib-devel Mailing List for matplotlib (Page 2)

I believe this is the right list, since the question deals with
compiling, rather than using, matplotlib.  Hope that's OK.

I just dl'ed, and after setting the TkAgg flag to 1 in setup.py,
did a python setup.py install. (Note that I had done
a previous install without the TkAgg flag set.) On my system,
this is producing a bunch of errors related to the Tk headers:

...
running build_ext
building 'matplotlib.backends._tkagg' extension
creating build/temp.darwin-7.3.0-Power_Macintosh-2.3
creating build/temp.darwin-7.3.0-Power_Macintosh-2.3/src
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp  
-mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall  
-Wstrict-prototypes -I/usr/local/include -I/usr/local/include/freetype2  
-Isrc -Iagg2/include  
-I/System/Library/Frameworks/Python.framework/Versions/2.3/include/ 
python2.3 -c src/_tkagg.cpp -o  
build/temp.darwin-7.3.0-Power_Macintosh-2.3/src/_tkagg.o
In file included from src/_tkagg.cpp:18:
/Library/Frameworks/Tk.framework/Headers/tk.h:96:29: X11/Xlib.h: No  
such file or directory
In file included from src/_tkagg.cpp:18:
/Library/Frameworks/Tk.framework/Headers/tk.h:572: error:  
`Tk_ClassCreateProc'
    was not declared in this scope
/Library/Frameworks/Tk.framework/Headers/tk.h:573: error: type specifier
    omitted for parameter `Window'
/Library/Frameworks/Tk.framework/Headers/tk.h:573: error: parse error  
before `,
    ' token
/Library/Frameworks/Tk.framework/Headers/tk.h:573: error: typedef  
`Window' is
    initialized (use __typeof__ instead)
/Library/Frameworks/Tk.framework/Headers/tk.h:576: error: type specifier
    omitted for parameter `XEvent'
...

and so on, for a very long time.

I have done some messing around with Tk--I'm currently running  
AquaTcl/Tk, not the
X11 version--but don't have a good handle on how to deal with the  
above. Any
ideas? I'd really like to start using matplotlib!

Thanks,
Ken McDonald

On Fri, 2004-04-16 at 08:09, John Hunter wrote:
> I think now is a good time to start implementing some GUI neutral
> event handling and wanted to bounce some ideas off the list.  The idea
> is for matplotlib to define its own event handler in matplotlib.events
> and each of the GUIs trigger these events.  Users could register with
> the event handler using an observer pattern.  In user space, you could
> do something like the following and expect it to work across Tk, Wx
> and GTK::
> 
>     import matplotlib.events as events
> 
>     def key_press(event):
>         print event.key
> 
>     events.connect('key_press', key_press)
> 
>     def button_press_press(event):
>         print event.button
> 
>     events.connect('button_press', button_press)
> 
> Each of the GUIs would call matplotlib.events.notify.  The backends
> would have to map the GUI constants, eg LEFT_BUTTON, to the
> appropriate matplotlib.event constant and handle things like flip y
> inversion since the matplotlib coordinate system is 0,0 = lower, left.
> 
> This would also lay the groundwork for generalizing things like
> examples/object_picker.py, writing generic measure tools, and so on.
> You could write a GUI neutral axes resize tool where the user could
> click on an axes and drag the size.  So it would be useful for the
> users who want to define some GUI interaction and or the developers
> who want to add features across backends w/o having to know all the
> widget sets.
> 
> My questions are
> 
>   * Does this look like a good framework?

The meaning of the coords_demo_gtk was clear and easy to emulate.  The
meaning of the events interface above (in the context of multiple figure
managers) is not so clear.

>   * Does someone want to implement the interface matplotlib.events?
> 
>   * Do the GUI maintainers for Tk (Todd), Wx (Jeremy) and GTK (Me)
>     have time to do the mapping?  If not can we get another volunteer?

I'm not imagining this as a major time sink so I'm pretty sure I'll be
able to support this.

>   * What events do we want to define?  The ones I use a lot are::
> 
>         key_press_event
>         key_release_event
>         motion_notify_event
>         button_press_event
>         button_release_event
> 
>     If these basic events are implemented at the backend level, we
>     could catch them and trigger more complicated events like
>     'drag_rectangle' in matplotlib.events.  Ie, catch press, mouse
>     move, and release, and then trigger drag_rectangle with start and
>     end locations in event.start and event.end.
> 
>   * There is the issue of coords.  x, y can be given in data, axes
>     (0-1) or data coords.  Probably best to give all three
> 
>       event.xdata, event.ydata, 
>       event.xaxis, event.yaxis,
>       event.xdisplay, event.ydisplay
> 
>     See examples/coords_demo_gtk.py for an example of connecting to a
>     GTK event and mapping the display coords to data space.  Jeremy
>     and Todd, this would be a good example to implement as stage 1 for
>     the event handling.

I implemented the coords demo for TkAgg this morning (just replace GTK
with TkAgg in the demo).  I did this by implementing connect() for
FigureCanvasTkAgg... very simple so far. 

> 
> Of course, there is no end to how far you could go with this, defining
> a basic cross GUI widget API for dialog boxes, entry boxes and so on.
> A meta-wx, if you will. But that is an issue for another day.

I can see the utility of GUI neutrality and I'm in favor of it, but I'm
also inclined to keep it as simple as possible.  I think it would be
easy to go overboard and start worrying about creating a meta-GUI
instead of a plotter.  If we drive the backend development with demos
and concrete applications (rather than some abstract idea of universal
GUI substitutability) I think the idea will turn out well.

Regards,
Todd

-- 
Todd Miller <jm...@st...>

I can't really comment on the framework (sounds OK but I have no experience
in this area), but you might want to add mouse wheel events and maybe both
single and double-click mouse button events.

Gary

*********** REPLY SEPARATOR  ***********

On 16/04/2004 at 07:09 John Hunter wrote:

<snip>
>   * What events do we want to define?  The ones I use a lot are::
> 
>         key_press_event
>         key_release_event
>         motion_notify_event
>         button_press_event
>         button_release_event

I think now is a good time to start implementing some GUI neutral
event handling and wanted to bounce some ideas off the list.  The idea
is for matplotlib to define its own event handler in matplotlib.events
and each of the GUIs trigger these events.  Users could register with
the event handler using an observer pattern.  In user space, you could
do something like the following and expect it to work across Tk, Wx
and GTK::

    import matplotlib.events as events

    def key_press(event):
        print event.key

    events.connect('key_press', key_press)

    def button_press_press(event):
        print event.button

    events.connect('button_press', button_press)

Each of the GUIs would call matplotlib.events.notify.  The backends
would have to map the GUI constants, eg LEFT_BUTTON, to the
appropriate matplotlib.event constant and handle things like flip y
inversion since the matplotlib coordinate system is 0,0 = lower, left.

This would also lay the groundwork for generalizing things like
examples/object_picker.py, writing generic measure tools, and so on.
You could write a GUI neutral axes resize tool where the user could
click on an axes and drag the size.  So it would be useful for the
users who want to define some GUI interaction and or the developers
who want to add features across backends w/o having to know all the
widget sets.

My questions are

  * Does this look like a good framework?

  * Does someone want to implement the interface matplotlib.events?

  * Do the GUI maintainers for Tk (Todd), Wx (Jeremy) and GTK (Me)
    have time to do the mapping?  If not can we get another volunteer?

  * What events do we want to define?  The ones I use a lot are::

        key_press_event
        key_release_event
        motion_notify_event
        button_press_event
        button_release_event

    If these basic events are implemented at the backend level, we
    could catch them and trigger more complicated events like
    'drag_rectangle' in matplotlib.events.  Ie, catch press, mouse
    move, and release, and then trigger drag_rectangle with start and
    end locations in event.start and event.end.

  * There is the issue of coords.  x, y can be given in data, axes
    (0-1) or data coords.  Probably best to give all three

      event.xdata, event.ydata, 
      event.xaxis, event.yaxis,
      event.xdisplay, event.ydisplay

    See examples/coords_demo_gtk.py for an example of connecting to a
    GTK event and mapping the display coords to data space.  Jeremy
    and Todd, this would be a good example to implement as stage 1 for
    the event handling.

Of course, there is no end to how far you could go with this, defining
a basic cross GUI widget API for dialog boxes, entry boxes and so on.
A meta-wx, if you will. But that is an issue for another day.

JDH 

From: "John Hunter" <jdh...@ac...>

> >>>>> "Gary" == Gary Pajer <pa...@in...> writes:
>
>     Gary> I've been using the cvs version on Mandrake, but I'll need
>     Gary> to be working in WinXP and using the "embedded TkAgg"
>     Gary> facility.  I looked into compiling on WinXP, but that looks
>     Gary> like something I'd like to avoid.
>
>     Gary> Is it too much to ask for an upgrade to the Windows
>     Gary> installer?  Alternatively, tell me that compiling is not as
>     Gary> bad as it looks, and that it actually goes rather smoothly.
>
> setupext.py points you to
> http://matplotlib.sourceforge.net/win32_static.tar.gz which is
> required.  There is a README in that dir that contains detailed build
> instructions.
>
> If this proves too much of a pain, I'm sure Todd or I could provide a
> build for you in the not-too-distant future.

Yes, I've seen the pointer along with the word "masochist", and the
instructions.
If 0.53 is coming in a few weeks, I'll wait.  I have enough to do fixing OSX
X11.

-thanks,  gary

On Apr 12, 2004, at 6:33 PM, Daishi Harada wrote:

> On mac os x, I was going to use fink for the dependencies, and so
> I modified setupext.py as follows:
>
> (snipped diff output)
>
> Do most of the users of matplotlib on os x not use fink?

Because I often build extensions for others, I try to stay away from 
fink as much as possible in this step.  Not because I don't like it, 
but  because I'm reluctant to require yet another dependency. For 
someone without fink, it's probably easier to just install freetype 
than fink and freetype. Furthermore, I think it should be possible to 
compile matplotlib against the a static freetype library that gets 
installed directly with matplotlib, thus not relying on any external 
dependency.

I think I can share some of the credit/blame Mac OS X-specific build 
stuff, and I certainly didn't want to make fink a requirement.

For the fink-inclined, I think the best thing to do is to make 
fink-based matplotlib distribution which is built against the other 
fink stuff.

> The stumper
> for me is that I have been unable to build scipy/numpy for the python
> that is bundled with os x - has anyone been successful with this?
> (is this process documented anywhere?)

I have an old build that just worked from mid-2003, and I haven't had 
much success in the few times I've tried to update since then.  Sorry, 
I can't be much help here.  But why do you include numpy in your 
statement?  There's no problem with this one.  I think it's even 
included with the PackageManager stuff, and I'd be surprised if fink 
didn't include it, too.

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:

    Gary> I've been using the cvs version on Mandrake, but I'll need
    Gary> to be working in WinXP and using the "embedded TkAgg"
    Gary> facility.  I looked into compiling on WinXP, but that looks
    Gary> like something I'd like to avoid.

    Gary> Is it too much to ask for an upgrade to the Windows
    Gary> installer?  Alternatively, tell me that compiling is not as
    Gary> bad as it looks, and that it actually goes rather smoothly.

setupext.py points you to
http://matplotlib.sourceforge.net/win32_static.tar.gz which is
required.  There is a README in that dir that contains detailed build
instructions.

If this proves too much of a pain, I'm sure Todd or I could provide a
build for you in the not-too-distant future.

Paul, do you have an estimate on when the remaining font issues (eg
the font size setting problem) will be cleared up?  I think we're due
for the 0.53 release.

JDH

Hi John,

I'm trying to finish off the basic features of the font manager module, so we 
can get the next release out.  I'm currently working on the fonts_demo.py 
example, which has brought to light some deficiencies in the basic 
implementation of font_manager.  I would like to get your opinion on the 
following issues:

1. Currently, the relative font size strings ('smaller' and 'larger') are not 
implemented.  This is because these sizes depend on the parent font size: a 
feature which is not yet implemented.  Note that the font_manager only has a 
default_size, which is used by the absolute font size strings (xx-small, 
x-small, small, medium, etc.).

For this to work, it would seem that each FontProperties instance would need a 
pointer to its parent FontProperties instance.  When get_size_in_points() is 
called, it would asks its parent font what size it is in order to determine its 
absolute size.  If the parent is also a relative size, then the parent would ask 
its parent what size it is, etc.  This would handle the case where set_size() is 
called twice using a relative font size.

What do you think of this approach?  It has its problems, mainly with the 
possibility of circular references, but checks for such situations could be 
added in later.  If this feature (of relative font sizes) isn't that important, 
then we could defer it until after the release.

2. The above problem has also highlighted an issue with the current font manager 
design.  Currently, the fontManager class has attributes of default_size and 
default_weight that are set at initialization.  If we pulled these attributes 
out of the class and replaced them with a default FontProperties instance, then 
this instance could be used as the root parent FontProperties instance.  What do 
you think?

Also, since there is often only one instance of the fontManager class, this 
class could be eliminated and be replace with some initialization code and a 
findfont() function, unless you think that several instances of this class might 
be used in future versions of matplotlib.

3. Finally, Perry and I were discussing how one might use Traits in matplotlib. 
  The Traits module is being used in the Chaco plotting package for checking the 
type and value of class attributes, such as the color and size of fonts or the 
color and width of lines.  (See the Chaco page at the ScyPy web site for an 
overview.)  It would appear that matplotlib's rcParams has a similar purpose, 
though on a more limited scale than Traits.  I think it should still be possible 
to have the matplotlibrc file for customization, and to feed this information to 
the Traits module on start up.  Traits may not be able to handle the link 
attribute problem discussed above, but this can probably be implemented 
separately if necessary.

Note that all these issues are not critical and could be deferred until after 
the release.

Cheers,
Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

I've been using the cvs version on Mandrake, but I'll need to be working in
WinXP and using the "embedded TkAgg" facility.  I looked into compiling on
WinXP, but that looks like something I'd like to avoid.

Is it too much to ask for an upgrade to the Windows installer?
Alternatively, tell me that compiling is not as bad as it looks, and that it
actually goes rather smoothly.

Thanks,
Gary

Great timing. I've just been struggling with the os x build, and had gotten
as far as the fontweight problem.  A warning about X11 on 10.2.8:  My Apple
X11 beta system was working perfectly, but I decided to fix it anyway and
upgrade to a newer Xfree86 X11.  This causes some kind of compatibility
problem with freetype, and numerous headaches for me, not yet solved.
Attempts to back up to the Apple beta have failed.  I have other ideas, but
that's not for this list.

On os x I use the fink python exclusively.  The reason is that I use Vpython
which has been ported only to the fink python system.  Until I "fixed" it,
everything worked perfectly smoothly.  I use the fink scipy.  I seem to
remember that someone has gotten the cvs compiled; check the scipy archives.

On Mandrake 10.0 cvs compiles smoothly.

-gary

Hi,

I just built matplotlib from CVS on debian/linux and mac os x,
and had to modify some things. I thought the information might
be useful to others, and that people on this list might advise me
if there were better fixes.

On debian, I had to make the following modification to setupext.py:

---
Index: setupext.py
===================================================================
RCS file: /cvsroot/matplotlib/matplotlib/setupext.py,v
retrieving revision 1.30
diff -c -r1.30 setupext.py
*** setupext.py 31 Mar 2004 14:29:35 -0000      1.30
--- setupext.py 13 Apr 2004 00:39:54 -0000
***************
*** 169,177 ****
       else:
         tk.withdraw()
         o.tcl_lib = os.path.join((tk.getvar('tcl_library')), '../')
-       o.tcl_inc = os.path.join((tk.getvar('tcl_library')), 
'../../include')
         o.tk_lib = os.path.join((tk.getvar('tk_library')), '../')
         o.tkv = str(Tkinter.TkVersion)[:3]
       return o


--- 169,177 ----
       else:
         tk.withdraw()
         o.tcl_lib = os.path.join((tk.getvar('tcl_library')), '../')
         o.tk_lib = os.path.join((tk.getvar('tk_library')), '../')
         o.tkv = str(Tkinter.TkVersion)[:3]
+       o.tcl_inc = os.path.join((tk.getvar('tcl_library')), 
'../../include/tcl'+o.tkv)
       return o
---

I'm using a fairly mixed stable/testing/unstable version of debian, so
maybe that's the reason for my needing to make this change.

On mac os x, I was going to use fink for the dependencies, and so
I modified setupext.py as follows:

---
Index: setupext.py
===================================================================
RCS file: /cvsroot/matplotlib/matplotlib/setupext.py,v
retrieving revision 1.30
diff -c -r1.30 setupext.py
*** setupext.py 31 Mar 2004 14:29:35 -0000      1.30
--- setupext.py 13 Apr 2004 00:46:31 -0000
***************
*** 36,42 ****
       'win32' : 'win32_static',
       'linux2' : '/usr',
       'linux'  : '/usr',
!     'darwin' : '/usr/local',
       'sunos5' : os.getenv('MPLIB_BASE') or '/usr/local'
   }

--- 36,43 ----
       'win32' : 'win32_static',
       'linux2' : '/usr',
       'linux'  : '/usr',
!     #'darwin' : '/usr/local',
!     'darwin' : '/sw',
       'sunos5' : os.getenv('MPLIB_BASE') or '/usr/local'
   }

***************
*** 92,99 ****
--- 93,105 ----
       inc = os.path.join(basedir[sys.platform], 'include')
       module.include_dirs.append(inc)
       module.include_dirs.append(os.path.join(inc, 'freetype2'))
+     if sys.platform == 'darwin':
+         
module.include_dirs.append(os.path.join(basedir[sys.platform], 
'lib/freetype2/include'))
+         
module.include_dirs.append(os.path.join(basedir[sys.platform], 
'lib/freetype2/include/freetype2'))

       module.library_dirs.append(os.path.join(basedir[sys.platform], 
'lib'))
+     if sys.platform == 'darwin':
+         
module.library_dirs.append(os.path.join(basedir[sys.platform], 
'lib/freetype2/lib'))

       if sys.platform == 'win32':
           module.libraries.append('gw32c')
---

Do most of the users of matplotlib on os x not use fink? The stumper
for me is that I have been unable to build scipy/numpy for the python
that is bundled with os x - has anyone been successful with this?
(is this process documented anywhere?)

For both debian and os x, I found that I would get the following error:

---
   File 
"...../lib/python2.3/site-packages/matplotlib/backends/backend_wx.py", 
line 611, in get_wx_font
     self.fontweights[t.get_fontweight()], # Weight
KeyError
---

where t.get_fontweight() seems to be returning None. I "fixed" this by
adding

---
Index: backends/backend_gtk.py
===================================================================
RCS file: 
/cvsroot/matplotlib/matplotlib/matplotlib/backends/backend_gtk.py,v
retrieving revision 1.81
diff -c -r1.81 backend_gtk.py
*** backends/backend_gtk.py     12 Apr 2004 13:32:05 -0000      1.81
--- backends/backend_gtk.py     13 Apr 2004 01:08:20 -0000
***************
*** 89,94 ****
--- 89,95 ----
                      'normal' : pango.WEIGHT_NORMAL,
                      'ultrabold' : pango.WEIGHT_ULTRABOLD,
                      'ultralight' : pango.WEIGHT_ULTRALIGHT,
+                    None : pango.WEIGHT_NORMAL
                      }
       fontangles = {
           'italic': pango.STYLE_ITALIC,
Index: backends/backend_wx.py
===================================================================
RCS file: 
/cvsroot/matplotlib/matplotlib/matplotlib/backends/backend_wx.py,v
retrieving revision 1.51
diff -c -r1.51 backend_wx.py
*** backends/backend_wx.py      5 Apr 2004 12:58:54 -0000       1.51
--- backends/backend_wx.py      13 Apr 2004 01:08:20 -0000
***************
*** 338,344 ****
                      'heavy'      : wxBOLD,
                      'light'      : wxLIGHT,
                      'ultrabold'  : wxBOLD,
!                    'ultralight' : wxLIGHT }

       fontangles = { 'italic'  : wxITALIC,
                      'normal'  : wxNORMAL,
--- 338,346 ----
                      'heavy'      : wxBOLD,
                      'light'      : wxLIGHT,
                      'ultrabold'  : wxBOLD,
!                    'ultralight' : wxLIGHT,
!                    None : wxNORMAL
!                    }

       fontangles = { 'italic'  : wxITALIC,
                      'normal'  : wxNORMAL,
---

but there is probably a better/cleaner way to solve this problem...

d

On Mon, 2004-04-05 at 18:32, John Hunter wrote:
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> 
>     Todd> Confusingly, the explicit call to nonzero() is not what is
>     Todd> causing the numarray problem.  The problem is an implicit
>     Todd> call to NumArray.__nonzero__() resulting from the range
>     Todd> expression.  I found I could "fix" the numarray exception by
>     Todd> adding parens to the range expression:
> 
>     Todd> nonzero((ticklocs >= 10.0**ymin) * (ticklocs <= 10.0**ymax))
> 
> 
> I wasn't able to replicate your problem in ticklocs.py on my system
> (could be a version issue?).

Reproducing the exception requires using numarray-0.9.  Also, 
ticklocs.py is coded to demonstrate the unexpected Numeric results
rather than the numarray exception to there is a try/except block which
passes the numarray exception on to parenthesized code.

>  Ie, the following works fine for me; I
> assume it generated a RuntimeError for you based on your example code.
> 
> 
> ______________________________________________________________________
> In any case, in general I try to avoid using multiplication for
> logical arrays because it sometimes produces surprising results.  I
> think here we want
> 
>             ind = nonzero(logical_and(ticklocs>=10.0**vmin ,
>                                       ticklocs<=10.0**vmax))
> 

This is clearer and unambiguous.

> 
>     Todd> Lastly, assuming the parens are correct, there is still a
>     Todd> problem with the log functions which I haven't looked at
>     Todd> yet:
> 
>     >>>> loglog(arange(2,800))
> 
> Here's what's going on under the hood
> 
> You are using the single arg form of plot with log scaling for both
> axes.  The y values are arange(2,800) and the x values are implicit:
> arange(len(y)).  Since this starts with 0, when take the log of zero
> in loglog, you are in a world of pain.  The current version of
> matplotlib warns but then tries to go ahead, which generates the
> error.  Specifically, it took the positive parts of x but left y
> alone, resulting in the unequal sized array problem.
> 
> I changed the code to raise rather than warn.  You now get the more
> helpful error message
> 
>   ValueError: Cannot take log of negative data
> 

Makes sense.  Thanks for the explanation.

> Both changes in CVS.
> 
> JDH

Regards,
Todd

-- 
Todd Miller <jm...@st...>

Hi,

JC Hsu reported that loglog() was broken with numarray and was raising
an exception due to an "illegal" call to __nonzero__().  

>>> from matplotlib.matlab import *
>>> loglog(arange(2,800))
[<matplotlib.lines.Line2D instance at 0x41e0ae8c>]
>>> show()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", line 57, in show
    manager.show()
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", line 163, in show
    self.canvas.show()
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", line 115, in show
    FigureCanvasAgg.draw(self)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py", line 353, in draw
    self.figure.draw(self.renderer)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/artist.py",
line 88, in draw
    self._draw(renderer, *args, **kwargs)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/figure.py",
line 89, in _draw
    for a in self.axes: a.draw(renderer)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/artist.py",
line 88, in draw
    self._draw(renderer, *args, **kwargs)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/axes.py",
line 531, in _draw
    self.xaxis.draw(renderer)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/artist.py",
line 88, in draw
    self._draw(renderer, *args, **kwargs)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/axis.py",
line 378, in _draw
    locs = self.get_ticklocs()
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/axis.py",
line 596, in get_ticklocs
    ind = nonzero(ticklocs>=10.0**vmin * ticklocs<=10.0**vmax)
  File
"/home/jmiller/work/lib/python2.3/site-packages/numarray/generic.py",
line 474, in __nonzero__
    raise RuntimeError("An array doesn't make sense as a truth value. 
Use sometrue(a) or alltrue(a).")
RuntimeError: An array doesn't make sense as a truth value.  Use
sometrue(a) or alltrue(a).

Confusingly, the explicit call to nonzero() is not what is causing the
numarray problem.  The problem is an implicit call to
NumArray.__nonzero__() resulting from the range expression.  I found I
could "fix" the numarray exception by adding parens to the range
expression:

nonzero((ticklocs >= 10.0**ymin) * (ticklocs <= 10.0**ymax))

Evaluating using the attached script,  I got the impression that while
numarray was raising an exception,  Numeric was giving an unintended /
wrong answer.    Anyway,  I wanted to get a second opinion before
committing anything since it smacks of hacking matplotlib to work around
numarray limitations.

Lastly,  assuming the parens are correct,  there is still a problem with
the log functions which I haven't looked at yet:

>>> loglog(arange(2,800))
[<matplotlib.lines.Line2D instance at 0x41e0ae8c>]
>>> show()
opened /home/jmiller/work/share/matplotlib/Vera.ttf
log iterable warning, non-positive data ignored
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", line 57, in show
    manager.show()
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", line 163, in show
    self.canvas.show()
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", line 115, in show
    FigureCanvasAgg.draw(self)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py", line 353, in draw
    self.figure.draw(self.renderer)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/artist.py",
line 88, in draw
    self._draw(renderer, *args, **kwargs)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/figure.py",
line 89, in _draw
    for a in self.axes: a.draw(renderer)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/artist.py",
line 88, in draw
    self._draw(renderer, *args, **kwargs)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/axes.py",
line 541, in _draw
    line.draw(renderer)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/artist.py",
line 88, in draw
    self._draw(renderer, *args, **kwargs)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/lines.py",
line 184, in _draw
    self._lineFunc(renderer, gc, xt, yt)
  File
"/home/jmiller/work/lib/python2.3/site-packages/matplotlib/lines.py",
line 308, in _draw_solid
    renderer.draw_lines(gc, xt,yt)
ValueError: x and y must be equal length sequences



Regards,
Todd

I just committed a wxagg backend.  Jeremy and others may want to give
it a test drive.  I use fromstring / tostring methods to transfer the
image data to the wx bitmap.  This has the advantage of requiring no
wx specific extension code but obviously implies a performance hit.

This is just a first pass implementation so I tried to keep the
framework as close to the current wx setup as possible, in order to
reuse as much of backend_wx as possible.  I think though that the
bitmap is not necessary since I am rendering to agg.  Jeremy, can we
transfer the wxImage created in FigureCanvasWXAgg.draw directly to the
DC w/o going through the bitmap?

On my system, however, the performance is quite good.  Even when/if we
have an extension solution in place, it will be nice to preserve the
string methods as a fallback for those who can't compile the extension
for some reason.

There are a couple of unrelated wx issues that need attention:

  * The toolbar seems not to work on Mac OS X, either for wx or
    wxagg.  Not sure why.  It doesn't even showup in the window

  * I got this email this morning

        From: Srijit Kumar Bhadra <sr...@ya...>
        Subject: Matplotlib 0.52 and wxpython 2.5.1
        To: jdh...@ac...
        Date: Mon, 5 Apr 2004 00:21:45 -0700 (PDT)

        Hi, This is to inform you that Matplotlib 0.52 does not work
        with wxpython 2.5.1.  The corresponding code is available
        below.

        It works correctly with the previous version 2.4 of wxpython.

That's all for now,  
JDH

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:


    Paul> This was an easy change to the font manager.  You should see
    Paul> it in CVS later today.

Great.

An unrelated bug I found in testing with one of my apps

In the font_manager

    def get_size_in_points(self, parent_size=None):
        """Convert text to point size"""
        if isinstance(self.__size, str):
            if   self.__size == 'larger':
                size = int(self.__parent_size*1.2)
            elif self.__size == 'smaller':
                size = int(self.__parent_size/1.2)
            else:
                defsize = fontManager.get_default_size()
                size = defsize*font_scalings[self.__size]
            return size
        else:
            return self.__size

I sometimes get key error on font_scalings[self.__size] when
self.__size is a number, eg 10.  From the code, it looks like you
intend self.__size to always be a relative size.  I did a temporary
workaround along the lines of

            else:
                try: size = float(self.__size)
                except ValueError:
                    defsize = fontManager.get_default_size()
                    size = defsize*font_scalings[self.__size]
            return size

but this hack may be masking another bug so I thought you'd want to
look into it.

    Paul> On a related issue, I noticed that the sizes of PS plots are
    Paul> different depending on which backend is used first.  If I
    Paul> send a plot directly to the PS backend, I get a nice plot
    Paul> (see the attachment simple_plot_PS.ps).  Whereas, if I first
    Paul> display the plot using TkAgg and then save it to PS, I get a
    Paul> plot that is much larger than the display area (see the
    Paul> attachment simple_plot.ps).  The text size in both plots
    Paul> appears to be the same size, this would indicate an
    Paul> incorrect scaling factor somewhere.

backend_tkagg needs to override FigureCanvasTkAgg.print_figure
following the lead of backend_gtkagg.  The critical point is that dpi
must be set to 72 for backend_ps.  Even though ps doesn't use DPI,
this value is used by the figure to compute the canvas size as
width*dpi and height*dpi, and this does affect backend_ps.

In FigureCanvaseGTKAgg.print_figure I save the orig dpi, set the
figure dpi to 72, print the figure, and then reset.  I do the same
with other figure properties (eg, background color, so you can have a
different color background for printing and GUI).

It should be mostly a cut and paste from backend_gtkagg.

JDH

John Hunter wrote:
> 
> Another concern I have is that if I am reading the code correctly all
> the afm files are being parsed at load time, even for non-postscript
> backends.  Some users have hundreds of afm files in their path, and on
> a slowish machine this can impose a substantial performance hit.  In
> the past, I deferred parsing the afm files for the non-ps backends
> until they were called for, eg, until a call to
> savefig('somefile.ps').  Don't know if this is easy or possible to
> incorporate in the current design, but it's something to think about.

Hi John,

This was an easy change to the font manager.  You should see it in CVS later today.

On a related issue, I noticed that the sizes of PS plots are different depending 
on which backend is used first.  If I send a plot directly to the PS backend, I 
get a nice plot (see the attachment simple_plot_PS.ps).  Whereas, if I first 
display the plot using TkAgg and then save it to PS, I get a plot that is much 
larger than the display area (see the attachment simple_plot.ps).  The text size 
in both plots appears to be the same size, this would indicate an incorrect 
scaling factor somewhere.

  -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218