matplotlib-devel Mailing List for matplotlib

>>>>> "Michael" == Michael Nandris <sui...@ya...> writes:

    Michael> Well, Xandros ship a python with no distutils.
    Michael> Hmmmmmmmmmm, usefull.

Install distutils rather than trying to work around them.  For
example, all the configure, gcc, make stuff you attempted is
unnecessary if you simply use distutils with 'python setup.py build'..

Everything else you are trying will result in a fragmented and
corrupted source.  The standard installation techinques will work on
Xandros, I'm willing to wager, and will result in a cleaner, better
system that trying to hack the install.  This isn't always true
(solaris and perhaps os x spring to mind) but I have some confidence
that it will be true for your install

    Michael> Anyway, I have a clean reinstall now; but both mpl deb's
    Michael> are broken (see below).

Did you do what I suggested in my last post.  Step by step, what was
the output?  For example, to the suggested commands

  >>> import matplotlib
  >>> print matplotlib.__version__

What was the output of the apt-get commands?  Did you follow the
instructions in the response I sent to matplotlib-users?  Did you try a
different GUI backend?

JDH

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:

    Gregory> Hi John, Hi the list, I almost have finished updating the
    Gregory> fltkAgg, to add the new subplot formatter and the blit
    Gregory> method for fast animation. Everything seems to work fine,
    Gregory> but I still need to do some code clean-up, and before
    Gregory> commiting the changes I have to ask what you think about
    Gregory> the method I used:

Hi Gregory,  Great news.  Ken McIvor just emailed me this morning that
he completed the same with a _wxagg module that he will post shortly.
That means we have (or will soon have) blit methods for all GUIs
except Qt and Cocoa (gentle reminder).

    Gregory> Instead of writing a special method taking account of the
    Gregory> bbox for bliting, similar to the agg_to_gtk_drawable, or
    Gregory> a aggcanvas->str conversion like the proposed
    Gregory> aggcanvas.as_rgba_str(bbox), I just changed the method
    Gregory> that I introduced for normal draw in fltkAdd, that rely
    Gregory> on pytho buffer objects to transfer the agg buffer to the
    Gregory> fltk library.

    Gregory> The old method of the Agg backend that was used to get
    Gregory> the buffer object was:

    ....snip...
    Gregory> As fltkAgg is able to use an image source with a pixel
    Gregory> stride (skipping the a of the rgba quatuor) and a line
    Gregory> stride (taking a part of wide w1 from an image of wide
    Gregory> w2), no copy or special method is needed with the new
    Gregory> version of RendererAgg::buffer_rgba...

    Gregory> Now I checked and other backends (qtagg, cocoaagg) now
    Gregory> use RendererAgg::buffer_rgba. If this is ok, I will
    Gregory> update all the calls to pass (0,0) instead of no
    Gregory> arguments, but I wonder if the new methods could not
    Gregory> simplify things for those backends too...

Yep, this all looks right.  I will look into this for gtkagg as well
tomorrow.  It may make rendering to a bbox even faster because gtkagg
and tkagg may both make an unnecessary copy that your method avoids.


    Gregory> Another remarks is that the animation code seems quite
    Gregory> fragile for the moment: if one do a resize of the output
    Gregory> window, the background copy is not updated correctly and
    Gregory> one have a very interresting effect ;) Well, at leat I
    Gregory> observe that under fltkAgg (my local version supporting
    Gregory> blit) and GTKAgg. tkagg does not do this..because it is
    Gregory> not possible to resize the window during animation (well,
    Gregory> window is resizable but the size of the inside canvas
    Gregory> does not change during this resize...).

    Gregory> I think some extra steps should be performed to make
    Gregory> resize and anim play nicely together (like freezing the
    Gregory> anim during resize, and restarting afterwards with the
    Gregory> correct background...)

What I do is connect to the new 'draw_event' which is called at the
end of Figure.draw (no GUI specific event handling required).  If you
set the animated property of the Artist,  and then connect your
background saver to the 'draw_event', it should handle this case.
Additionally you want to make sure your draw events are processed in
an idle queue on resizes, etc.

Check out widgets.Cursor for a complete example using draw_event
background cacheing, the guts of which are 
    
     
    def __init__(self, ax, useblit=False, **lineprops):
        ...snip
        self.canvas.mpl_connect('draw_event', self.clear)

    def clear(self, event):
        'clear the cursor'
        if self.useblit:
            self.background = self.canvas.copy_from_bbox(self.ax.bbox)


Does this work for you in GTKAGG and/or FLTK?  If everything looks
good, you may want to update the canonical animation examples in the
examples directory and on the wiki.

JDH

Well, Xandros ship a python with no distutils.
Hmmmmmmmmmm, usefull. 

Anyway, I have a clean reinstall now; but both mpl
deb's are broken (see below).

I am (reasonably) confident distutils will fine for
installing mpl, but I think there are 2 final hurdles:

1) agg 	
2) mpl build requires pygtk
	
1) Marcus Gruendler kindly supplied a line for
compiling agg from that list:

	gcc -c -O2 src/*.cpp -Iinclude && ar rc
libantigrain2.a *.o
	
	... after which i assume 'make', 'make install' will
work.

2) ./configure works for pygtk (see below). 

I have stopped here for a rest. phew.
 
I am hoping 'make', 'make install' will ensure pygtk
is picked up when I build matplotlib - any pitfalls? 

... and I only want matplotlib to draw pretty pictures
:)

regards

michael 
 
 

============================= deb files on xandros and
elsewhere are broken ?
====================================================

ONE:
altered /etc/apt/sources.list by adding 

	deb http://anakonda.altervista.org/debian packages/
	deb-src http://anakonda.altervista.org/debian
sources/
	
apt-get update						
apt-get install python-matplotlib
python-matplotlib-doc

apt-get install python-matplotlib
python-matplotlib-doc
Reading Package Lists... Done
Building Dependency Tree... Done
Some packages could not be installed. This may mean
that you have
requested an impossible situation or if you are using
the unstable
distribution that some required packages have not yet
been created
or been moved out of Incoming.
The following information may help to resolve the
situation:

The following packages have unmet dependencies:
  python-matplotlib: Depends: python2.3-matplotlib (=
0.82-1) but it is not going to be installed
E: Broken packages

TWO:
looked for python2.3-matplotlib on xandros networks:

	found python2.3-matplotlib on xandros: package size
is 2.21 MB
	
	After selecting 'install', the xandos dialog box is
visibly broken, and no installation happens. This
happens consistently for all mpl related debs. 
	
	There is a python2.4-matplotlib (albeit with the same
broken dependancy) but no way of upgrading to python
2.4! I *paid* good English pounds
exchanged-at-an-artificially-favourable-rate for
xandros, so I will email them.
	 
================================================================================================================



=========================== output of ./configure for
pygtk is ok
===============================================

maia:/home/mik/src/pygtk-2.4.1# ./configure
checking for a BSD-compatible install...
/usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name...
a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler...
yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none
needed
checking dependency style of gcc... gcc3
checking for bind_textdomain_codeset... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for some Win32 platform... no
checking for native Win32... no
checking for a sed that does not truncate output...
/bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object
files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries...
pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler...
yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77
compiler... no
checking whether  accepts -g... no
checking the maximum length of command line
arguments... 32768
checking command to parse /usr/bin/nm -B output from
gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag  works... yes
checking if gcc supports -fno-rtti -fno-exceptions...
no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports
shared libraries... yes
checking whether -lc should be explicitly linked in...
no
checking dynamic linker characteristics... GNU/Linux
ld.so
checking how to hardcode library paths into
programs... immediate
checking whether stripping libraries is possible...
yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports
shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports
shared libraries... yes
checking dynamic linker characteristics... GNU/Linux
ld.so
checking how to hardcode library paths into
programs... immediate
checking whether stripping libraries is possible...
yes
appending configuration tag "F77" to libtool
checking for a Python interpreter with version >=
2.3... python
checking for python... /usr/bin/python
checking for python version... 2.3
checking for python platform... linux2
checking for python script directory...
${prefix}/lib/python2.3/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python2.3/site-packages
checking for headers required to compile python
extensions... found
checking for python module thread... yes
checking whether to enable threading in pygtk... yes
checking for pkg-config... /usr/bin/pkg-config
checking for GLIB - version >= 2.4.0... yes (version
2.6.3)
checking for atk >= 1.0.0... yes
checking ATK_CFLAGS... -I/usr/include/atk-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
checking ATK_LIBS... -Wl,--export-dynamic -latk-1.0
-lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
checking for pango >= 1.4.0... yes
checking PANGO_CFLAGS... -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
checking PANGO_LIBS... -lpango-1.0 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0
checking for pkg-config... (cached)
/usr/bin/pkg-config
checking for GTK+ - version >= 2.4.0... yes (version
2.6.2)
checking for GTK+ 2.4... found (version 2.6.2)
checking for libglade-2.0 >= 2.3.6... Package
libglade-2.0 was not found in the pkg-config search
path.
Perhaps you should add the directory containing
`libglade-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libglade-2.0' found
checking for Numeric/arrayobject.h... no
checking whether gcc understands -Wall... yes
checking whether gcc understands -std=c9x... yes
checking whether gcc understands
-fno-strict-aliasing... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating pygtk-2.0.pc
config.status: creating codegen/Makefile
config.status: creating gobject/Makefile
config.status: creating gtk/Makefile
config.status: creating docs/Makefile
config.status: creating examples/Makefile
config.status: creating tests/Makefile
config.status: creating codegen/pygtk-codegen-2.0
config.status: creating pygtk.spec
config.status: creating PKG-INFO
config.status: creating config.h
config.status: executing depfiles commands
maia:/home/mik/src/pygtk-2.4.1#


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Hi John, Hi the list,

I almost have finished updating the fltkAgg, to add the new subplot
formatter and the blit method for fast animation. Everything seems to
work fine, but I still need to do some code clean-up, and before
commiting the changes I have to ask what you think about the method I
used:

Instead of writing a special method taking account of the bbox for
bliting, similar to the agg_to_gtk_drawable, or a aggcanvas->str
conversion like the proposed aggcanvas.as_rgba_str(bbox), I just changed
the method that I introduced for normal draw in fltkAdd, that rely on
pytho buffer objects to transfer the agg buffer to the fltk library.

The old method of the Agg backend that was used to get the buffer object
was:

Py::Object 
RendererAgg::buffer_rgba(const Py::Tuple& args) {
  //"expose the rendered buffer as Python buffer object";
  
  _VERBOSE("RendererAgg::buffer_rgba");
  
  args.verify_length(0);  
  int row_len = width*4; 
  return Py::asObject(PyBuffer_FromMemory( pixBuffer, row_len*height));
} 

and I just extended it to use only part of the buffer:

Py::Object 
RendererAgg::buffer_rgba(const Py::Tuple& args) {
  //"expose the rendered buffer as Python buffer object, starting from
postion x,y";
  
  _VERBOSE("RendererAgg::buffer_rgba");
  
  args.verify_length(2); 
  int startw = Py::Int(args[0]);   
  int starth = Py::Int(args[1]);  
  int row_len = width*4; 
  int start=row_len*starth+startw*4;
  return Py::asObject(PyBuffer_FromMemory( pixBuffer+start,
row_len*height-start));
} 

As fltkAgg is able to use an image source with a pixel stride (skipping
the a of the rgba quatuor) and a line stride (taking a part of wide w1
from an image of wide w2), no copy or special method is needed with the
new version of  RendererAgg::buffer_rgba...

The draw code calls 

Fltk.fl_draw_image(self._source.buffer_rgba(0,0),0,0,int(w),int(h),4,0)

and the blit code 

Fltk.fl_draw_image(self._source.buffer_rgba(x,y),x,y,int(w),int(h),4,int(wo)*4)

Now I checked and other backends (qtagg, cocoaagg) now use
RendererAgg::buffer_rgba. If this is ok, I will update all the calls to
pass (0,0) instead of no arguments, but I wonder if the new methods
could not simplify things for those backends too...

Another remarks is that the animation code seems quite fragile for the
moment: if one do a resize of the output window, the background copy is
not updated correctly and one have a very interresting effect ;) Well,
at leat I observe that under fltkAgg (my local version supporting blit)
and GTKAgg. tkagg does not do this..because it is not possible to resize
the window during animation (well, window is resizable but the size of
the inside canvas does not change during this resize...).

I think some extra steps should be performed to make resize and anim
play nicely together (like freezing the anim during resize, and
restarting afterwards with the correct background...)


Regards,

Greg.