From sans at clinton.com  Mon Aug  4 16:59:35 2003
From: sans at clinton.com (Anderi Smiranov)
Date: Mon, 4 Aug 2003 16:59:35 -0400
Subject: [SciPy-dev] [Q] MLab module (in quadpack.py)??
Message-ID: <FMEKLNNKOMHJGEKCABJCKEFBCAAA.sans@clinton.com>

hi

i've built SciPy, SciPy-0.2.0_alpha_200.4161_src.tar.gz, Python 2.2.2,
Numeric 23. This is great stuff!

one question though: in scipy/Lib/integrate/quadpack.py i've found the line:

import MLab

besides the fact it breaks the import of quadpack: what is that? Some
interface to MatLab from Python?

Regards,
Andrei Smirnov



From a.schmolck at gmx.net  Tue Aug  5 10:18:12 2003
From: a.schmolck at gmx.net (Alexander Schmolck)
Date: 05 Aug 2003 15:18:12 +0100
Subject: [SciPy-dev] [Q] MLab module (in quadpack.py)??
In-Reply-To: <FMEKLNNKOMHJGEKCABJCKEFBCAAA.sans@clinton.com>
References: <FMEKLNNKOMHJGEKCABJCKEFBCAAA.sans@clinton.com>
Message-ID: <yfs4r0wdw7v.fsf@black132.ex.ac.uk>

"Anderi Smiranov" <sans at clinton.com> writes:

> hi
> 
> i've built SciPy, SciPy-0.2.0_alpha_200.4161_src.tar.gz, Python 2.2.2,
> Numeric 23. This is great stuff!
> 
> one question though: in scipy/Lib/integrate/quadpack.py i've found the line:
> 
> import MLab
> 
> besides the fact it breaks the import of quadpack: what is that? Some
> interface to MatLab from Python?

nope, just a couple of matlab-like functions (eig, diag etc.) implemented on
top of Numeric. If you need a MatLab interface, I got one.

'as



From pearu at scipy.org  Thu Aug  7 04:47:32 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 7 Aug 2003 11:47:32 +0300 (EEST)
Subject: [SciPy-dev] Re: [f2py] Debian packages of scipy and f2py
In-Reply-To: <20030714225737.GB1869@prometeu>
Message-ID: <Pine.LNX.4.21.0308071035150.26119-100000@cens.kybi>

[Sorry for a delayed response.]

On Mon, 14 Jul 2003, [iso-8859-15] Jos? Fonseca wrote:

> I've make Debian packages of scipy and f2py. They are available from my
> apt-get repository at:
> 
>   http://jrfonseca.dyndns.org/debian/
> 
> I referred to Joe Reinhardt's packages http://people.debian.org/~jmr/
> but have done these packages from scratch. These come for all python
> versions in debian unstable (2.1, 2.2 and 2.3).

Great!

> I've run the standard tests successfully but I'd appreciate that
> problems with these packages to be reported to me [privately] as I'd
> like to have these on Debian proper at some time.
> 
> One tricky issue I'd like to address with the scipy and f2py maintainers
> is the the scipy_distutils. Both scipy and f2py attempt to install to
> /usr/lib/python*/site-packages/scipy_distutils and at least on Debian
> this is not admissible so the packages conflict with each other and are
> mutually exclusive. This is particularly even more annoying for me,
> since for building scipy f2py is needed, so I need to install and
> uninstall them as a maniac. Is there any solution that allow both these
> packages to happily co-exist in a tree without overlapping?

This is a long lasting issue and several solutions have been proposed, see
scipy mailing archives.

The current solution for package installation of scipy,f2py,etc
would be the following:

1) Get scipy,f2py and their dependencies from CVS:

  export CVSROOT=:pserver:anonymous at scipy.org:/home/cvsroot
  cvs co scipy_core
  cvs co -d scipy world/scipy

  export CVSROOT=:pserver:anonymous at cens.ioc.ee:/home/cvs
  cvs co f2py2e

2) Disable chaco (for simplicity), scipy_core packages in
scipy/setup.py file by commenting out the following lines:

  separate_packages += core_packages
  separate_packages += chaco_packages

3) Disable scipy_distutils checkout in f2py2e/setup.py file by replacing
the line

  if 'sdist' in sys.argv and not os.path.exists('other/scipy_distutils'):

with

  if 0:

4) Create source tar-balls

  cd scipy_core
  python setup.py sdist
  cp dist/Scipy_core-*.tar.gz ..
  cd ..

  cd f2py2e
  cp dist/F2PY-*.tar.gz ..
  cd ..

  cd scipy
  python setup.py sdist
  cp dist/SciPy-*.tar.gz ..
  cd ..

5) Install scipy_core, f2py2e, scipy in the given order (now there are no 
overlaps in software installations):

  Unpack tar-ball sources.

  cd Scipy_core-*
  python setup.py install
  cd ..

  cd F2PY-*
  python setup.py install
  cd ..

  cd SciPy-*
  python setup.py install
  cd ..

Let us know if such an approach is acceptable for debianizing scipy,f2py
then we can consider simplifying steps 1-3).
Other suggestions are welcome.

Regards,
	Pearu



From lawnmowerman_0 at yahoo.com  Wed Aug 13 15:31:40 2003
From: lawnmowerman_0 at yahoo.com (Jun Sung)
Date: Wed, 13 Aug 2003 12:31:40 -0700 (PDT)
Subject: [SciPy-dev] strange error with win32 build for py21
Message-ID: <20030813193140.25875.qmail@web42003.mail.yahoo.com>

Dear experts:
 
I am getting very strange error with SciPy-0.2.0-alpha.
All multiplication involving array (array*scalar) coerces fractions into 0's.
I have tracked the error down to fastumath module in scipy_base.
 
For example:
>>> import Numeric
>>> x=Numeric.arange(11.)
>>> x*.5
array([ 0. ,  0.5,  1. ,  1.5,  2. ,  2.5,  3. ,  3.5,  4. ,  4.5,  5. ])
>>> import scipy_base.fastumath
>>> x*.5
array([ 0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.])
 
 
Furthermore, as seen in "scipy_base/limits.py" , when two arrays with float typecodes
are multiplied, Python throws an ArithmeticError: Integer overflow in multiply.
 
Should I bother with the C code or is there an obvious clue I need to get.
Thanks, in advance.
/js


---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20030813/d5c5ff1f/attachment.html>

From nwagner at mecha.uni-stuttgart.de  Fri Aug 15 03:32:39 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Fri, 15 Aug 2003 09:32:39 +0200
Subject: [SciPy-dev] Problems during build process of latest cvs
Message-ID: <3F3C8C97.2BB0A9FA@mecha.uni-stuttgart.de>

Hi all,

python setup.py build failed with the following error message....


agg_scanline_u8.h:144: error:
                 
agg::scanline_u8::iterator::iterator(agg::scanline_u8&)
error: command 'gcc' failed with exit status 1

Nils



From nwagner at mecha.uni-stuttgart.de  Fri Aug 15 05:16:05 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Fri, 15 Aug 2003 11:16:05 +0200
Subject: [SciPy-dev] Complex matrices in linalg.lu
Message-ID: <3F3CA4D5.EB47137C@mecha.uni-stuttgart.de>

Hi all,

I wonder if there is any progress in resolving the problem of complex
matrices within linalg.lu ?
Thanks in advance.


Nils



From eric at enthought.com  Fri Aug 15 13:33:21 2003
From: eric at enthought.com (eric jones)
Date: Fri, 15 Aug 2003 12:33:21 -0500
Subject: [SciPy-dev] ANN: Job posting -- developer position available
Message-ID: <00a001c36353$55c9f4c0$8901a8c0@ERICDESKTOP>

Hey group,

We have a developer position open here at Enthought, and I thought I'd
see if anyone is interested.  The posting is below.  There is also a
tech writer and HCI opening listed on the website:

http://www.enthought.com/careers.html

thanks!

eric

Position:  Python Developer
Type:  Full-Time

Enthought, Inc. is a technology startup in the Austin, TX area that is
looking for a motivated Python Developer to join our development team.
Responsibilities include developing and deploying scientific
applications within the Fortune 500.  Our size and prospects provide
significant opportunity for growth and advancement for Enthought
employees.

Candidates should have the following qualifications:
	- BS or MS in Computer Science or Engineering or other
scientific field
	- 3+ years experience in the software industry
	- Experience developing solutions in the following languages:
		- Python
		- C/C++
	- User interface design experience
	- Developing and deploying custom solutions for clients
	- Excellent verbal and written communication skills

Ideal candidates will also demonstrate the following skills:
	- Use of the wxPython user interface library
	- Experience with Geophysics applications
	- Experience in the fields of statistics, linear algebra and
calculus

Please send resumes to jobs at enthought.com.

----------------------------------------------
eric jones                    515 Congress Ave
www.enthought.com             Suite 1614
512 536-1057                  Austin, Tx 78701 






From delphiro at zonnet.nl  Fri Aug 15 16:24:02 2003
From: delphiro at zonnet.nl (delphiro)
Date: Fri, 15 Aug 2003 22:24:02 +0200
Subject: [SciPy-dev] Re: [Scipy-chaco] ANN: Job posting -- developer position
 available
Message-ID: <5.2.1.1.0.20030815214706.009eb560@pop3.zonnet.nl>

Hi Eric,

> Ideal candidates will also demonstrate the following skills:
> - Use of the wxPython user interface library
> - Experience with Geophysics applications
> - Experience in the fields of statistics, linear algebra and
> calculus

How much closer can you get ;-)
Yes, I am a geotechnical engineer, yes I did work for GeoDelft (*the* company for geophysics in Holland and developers of the widly used MSerie (settlement, stability, foundations, groundwaterflow etc. etc.)), yes I have Python and 3+ years of programming experience (mostly Delphi and C++).. and yes.. uhm.. I do write English :-)

And most of all; my current project (eating up my spare time) http://pyciv.sourceforge.net is a 'geophysical' project. I never thought anyone else would think of writing a geophysical tool with Python.

But then... No.. I do not live anywhere near Austin..

Why do these things only happen in the USA :-)

Good luck with the candidates,
Rob

ps. I realy hope your application will be open source. It is about time we get some good open source engineering tools.
pps. Thanks for chaco and scipy. I use them in pyciv and they make calculations easy and graphical output of the results look very smooth indeed. 



From lawnmowerman_0 at yahoo.com  Mon Aug 18 17:41:06 2003
From: lawnmowerman_0 at yahoo.com (Jun Sung)
Date: Mon, 18 Aug 2003 14:41:06 -0700 (PDT)
Subject: [SciPy-dev] strange error with win32 build for py21
Message-ID: <20030818214106.29093.qmail@web42006.mail.yahoo.com>

Dear experts:
?
I am getting very strange error with
SciPy-0.2.0-alpha.
All multiplication involving array (array*scalar)
coerces fractions into 0's.
I have tracked the error down to fastumath module in
scipy_base.
?
For example:
>>> import Numeric
>>> x=Numeric.arange(11.)
>>> x*.5
array([ 0. ,? 0.5,? 1. ,? 1.5,? 2. ,? 2.5,? 3. ,?
3.5,? 4. ,? 4.5,? 5. ])
>>> import scipy_base.fastumath
>>> x*.5
array([ 0.,? 0.,? 0.,? 0.,? 0.,? 0.,? 0.,? 0.,? 0.,?
0.,? 0.])
?
?
Furthermore,?as seen in?"scipy_base/limits.py" , when
two arrays with float typecodes
are multiplied,?Python throws an ArithmeticError:
Integer overflow in multiply.
?
Should I bother with the C code or is there an obvious
clue I need to get.
Thanks, in advance.
/js



__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



From nwagner at mecha.uni-stuttgart.de  Tue Aug 19 03:32:50 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 19 Aug 2003 09:32:50 +0200
Subject: [SciPy-dev] Further problems with build
Message-ID: <3F41D2A2.DAEB0EAB@mecha.uni-stuttgart.de>

Hi all,

Again, I have some problems in building scipy from latest cvs. 

Python 2.1.2
Numeric 23.0
Atlas available
f2py 2.35.229-1505


This is the output

Any suggestion ?

Nils

building 'kiva.agg._kiva' extension
gcc -g -O2 -Wstrict-prototypes -fPIC
-I/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include
-I/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/include
-I/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src
-I/export/home/wagner/cvs/scipy/Lib/weave
-I/export/home/wagner/cvs/scipy/Lib/weave/scxx
-I/usr/local/include/python2.1 -c
/export/home/wagner/cvs/scipy/_kiva.cpp -o
build/temp.linux-i686-2.1/_kiva.o
/export/home/wagner/cvs/scipy/_kiva.cpp:5:39:
agg_renderer_bgra32_basic.h: Datei oder Verzeichnis nicht gefunden 
(file not found)
/export/home/wagner/cvs/scipy/_kiva.cpp:6:39:
agg_renderer_rgba32_basic.h: Datei oder Verzeichnis nicht gefunden
/export/home/wagner/cvs/scipy/_kiva.cpp:8:31: agg_renderer_util.h: Datei
oder Verzeichnis nicht gefunden
/export/home/wagner/cvs/scipy/_kiva.cpp:12:28: agg_rasterizer.h: Datei
oder Verzeichnis nicht gefunden
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_agg.h:7,
                 from /export/home/wagner/cvs/scipy/_kiva.cpp:14:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:19:39:
agg_renderer_bgra32_basic.h: Datei oder Verzeichnis nicht gefunden
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:20:28:
agg_rasterizer.h: Datei oder Verzeichnis nicht gefunden
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_agg.h:7,
                 from /export/home/wagner/cvs/scipy/_kiva.cpp:14:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:149:
error: syntax
   error before `;' token
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:150:
error: `
   scanline_u8' undeclared in namespace `agg'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:150:
error: syntax
   error before `;' token
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:191:
error: `
   line_join_e' was not declared in this scope
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:191:
error: parse
   error before `)' token
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:196:
error: `
   line_cap_e' was not declared in this scope
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:196:
error: parse
   error before `)' token
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:274:
error: `
   text_draw_mode_e' was not declared in this scope
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:274:
error: parse
   error before `)' token
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:279:
error: semicolon
   missing after declaration of `kiva::graphics_context_bitmap'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   constructor
`kiva::graphics_context_bitmap::graphics_context_bitmap()':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:154:
error: class
   `kiva::graphics_context_bitmap' does not have any field named
`renderer'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   constructor
`kiva::graphics_context_bitmap::graphics_context_bitmap(unsigned
   char*, int, int, int)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:164:
error: class
   `kiva::graphics_context_bitmap' does not have any field named
`renderer'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   member function `void
kiva::graphics_context_bitmap::set_line_join(...)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:193:
error: `
   value' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:193:
error: (Each
   undeclared identifier is reported only once for each function it
appears
   in.)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   member function `void
kiva::graphics_context_bitmap::set_line_cap(...)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:198:
error: `
   value' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   member function `void
kiva::graphics_context_bitmap::set_line_dash(double*,
   int, double)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:203:
error: `
   dash_type' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
At
   global scope:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:279:
error: `
   font_type' was not declared in this scope
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:279:
error: `
   font' was not declared in this scope
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:280:
error: ISO
   C++ forbids defining types within return type
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:280:
error: two
   or more data types in declaration of `set_font'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:280:
error: syntax
   error before `{' token
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:284:
error: syntax
   error before `&' token
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   function `void save_state()':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:294:
error: `
   state_stack' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:294:
error: `
   state' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:295:
error: `
   path' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   function `void curve_to(double, double, double, double, double,
double)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:390:
error: calling
   type `agg::curve4' like a method
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   function `void quad_curve_to(double, double, double, double)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:396:
error: calling
   type `agg::curve3' like a method
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   function `void rect(double, double, double, double)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:426:
error: calling
   type `agg::rect' like a method
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
At
   global scope:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:434:
error: parse
   error before `)' token
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   function `void clip_to_rect(double, double, double, double)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:468:
error: `
   buf' undeclared (first use this function)
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_agg.h:7,
                 from /export/home/wagner/cvs/scipy/_kiva.cpp:14:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   function `void _stroke_path()':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:494:
error: `
   final_stroke_path' undeclared (first use this function)
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_agg.h:7,
                 from /export/home/wagner/cvs/scipy/_kiva.cpp:14:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   function `void final_stroke_path(agg::conv_stroke<agg::path_storage,
   agg::null_markers>&)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:517:
error: `
   void final_stroke_path(agg::conv_stroke<agg::path_storage,
   agg::null_markers>&)' used prior to declaration
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:525:
error: `
   renderer' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:533:
error: `
   CAP_ROUND' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:535:
error: `
   CAP_BUTT' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:537:
error: `
   CAP_SQUARE' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:542:
error: `
   JOIN_MITER' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:544:
error: `
   JOIN_ROUND' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:546:
error: `
   JOIN_BEVEL' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:551:
error: `
   rasterizer' undeclared (first use this function)
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_agg.h:7,
                 from /export/home/wagner/cvs/scipy/_kiva.cpp:14:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
At
   global scope:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:594:
error: `
   filling_rule_e' undeclared in namespace `agg'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:594:
error: parse
   error before `)' token
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   function `void _fill_path(...)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:597:
error: `
   rule' undeclared (first use this function)
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_agg.h:7,
                 from /export/home/wagner/cvs/scipy/_kiva.cpp:14:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   function `void fill_path()':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:622:
error: `
   fill_non_zero' undeclared in namespace `agg'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   function `void eof_fill_path()':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:628:
error: `
   fill_even_odd' undeclared in namespace `agg'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
At
   global scope:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:632:
error: `
   draw_mode_e' was not declared in this scope
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:632:
error: parse
   error before `=' token
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
In
   function `void draw_path(...)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:634:
error: `
   mode' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:636:
error: `
   FILL' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:637:
error: `
   fill_non_zero' undeclared in namespace `agg'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:639:
error: `
   EOF_FILL' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:640:
error: `
   fill_even_odd' undeclared in namespace `agg'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:642:
error: `
   STROKE' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:645:
error: `
   FILL_STROKE' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:646:
error: `
   fill_non_zero' undeclared in namespace `agg'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:649:
error: `
   EOF_FILL_STROKE' undeclared (first use this function)
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:650:
error: `
   fill_even_odd' undeclared in namespace `agg'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:
At
   global scope:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_graphics_context.h:693:
error: parse
   error before `}' token
In file included from /usr/local/include/python2.1/Python.h:24,
                 from /export/home/wagner/cvs/scipy/_kiva.cpp:15:
/usr/local/include/python2.1/config.h:165:1: warning: "_POSIX_THREADS"
redefined
In file included from /usr/include/unistd.h:175,
                 from
/usr/include/g++/i486-suse-linux/bits/gthr-default.h:38,
                 from /usr/include/g++/i486-suse-linux/bits/gthr.h:98,
                 from /usr/include/g++/i486-suse-linux/bits/c++io.h:37,
                 from /usr/include/g++/bits/fpos.h:44,
                 from /usr/include/g++/iosfwd:49,
                 from /usr/include/g++/ios:44,
                 from /usr/include/g++/ostream:45,
                 from /usr/include/g++/iostream:45,
                 from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_compiled_path.h:4,
                 from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/src/kiva_agg.h:6,
                 from /export/home/wagner/cvs/scipy/_kiva.cpp:14:
/usr/include/bits/posix_opt.h:70:1: warning: this is the location of the
previous definition
In file included from /usr/include/g++/complex:49,
                 from /export/home/wagner/cvs/scipy/_kiva.cpp:18:
/usr/include/g++/bits/cpp_type_traits.h:80: error: `__is_void' is not a
   template
/usr/include/g++/bits/cpp_type_traits.h:104: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:113: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:122: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:131: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:141: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:151: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:160: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:169: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:178: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:187: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:196: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:205: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:214: error: `__is_integer' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:236: error: `__is_floating' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:245: error: `__is_floating' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:254: error: `__is_floating' is
not a
   template
/usr/include/g++/bits/cpp_type_traits.h:269: error: parse error before
`>'
   token
/usr/include/g++/bits/cpp_type_traits.h:270: error: missing ';' before
right
   brace
/usr/include/g++/bits/cpp_type_traits.h:281: error: parse error before
`>'
   token
/usr/include/g++/bits/cpp_type_traits.h:282: error: missing ';' before
right
   brace
/usr/include/g++/bits/cpp_type_traits.h:283: error: parse error before
`}'
   token
/usr/include/g++/bits/cpp_type_traits.h:297: error: parse error before
`}'
   token
In file included from /usr/include/g++/complex:51,
                 from /export/home/wagner/cvs/scipy/_kiva.cpp:18:
/usr/include/g++/sstream:62: error: parse error before `<' token
/usr/include/g++/sstream:67: error: syntax error before `;' token
/usr/include/g++/sstream:70: error: syntax error before `;' token
/usr/include/g++/sstream:72: error: `traits_type' is not a class or
namespace
/usr/include/g++/sstream:72: error: `int_type' is not a class or
namespace
/usr/include/g++/sstream:72: error: using `typename' outside of template
/usr/include/g++/sstream:72: error: `traits_type' fails to be a typedef
or
   built in type
/usr/include/g++/sstream:73: error: `traits_type' is not a class or
namespace
/usr/include/g++/sstream:73: error: `pos_type' is not a class or
namespace
/usr/include/g++/sstream:73: error: using `typename' outside of template
/usr/include/g++/sstream:73: error: `traits_type' fails to be a typedef
or
   built in type
/usr/include/g++/sstream:74: error: `traits_type' is not a class or
namespace
/usr/include/g++/sstream:74: error: `off_type' is not a class or
namespace
/usr/include/g++/sstream:74: error: using `typename' outside of template
/usr/include/g++/sstream:74: error: `traits_type' fails to be a typedef
or
   built in type
/usr/include/g++/sstream:82: error: `char_type' was not declared in this
scope
/usr/include/g++/sstream:82: error: `traits_type' was not declared in
this
   scope
/usr/include/g++/sstream:82: error: syntax error before `;' token
/usr/include/g++/sstream:83: error: `char_type' was not declared in this
scope
/usr/include/g++/sstream:83: error: `_Traits' was not declared in this
scope
/usr/include/g++/sstream:83: error: `_Alloc' was not declared in this
scope
/usr/include/g++/sstream:83: error: syntax error before `;' token
/usr/include/g++/sstream:84: error: `__string_type' is not a class or
namespace
/usr/include/g++/sstream:84: error: `size_type' is not a class or
namespace
/usr/include/g++/sstream:84: error: using `typename' outside of template
/usr/include/g++/sstream:87: error: parse error before `protected'
/usr/include/g++/sstream:119: error: parse error before `&' token
/usr/include/g++/sstream:121: error: only declarations of constructors
can be
   `explicit'
/usr/include/g++/sstream: In function `int basic_stringbuf(...)':
/usr/include/g++/sstream:121: error: only constructors take base
initializers
/usr/include/g++/sstream:121: error: `__str' undeclared (first use this
   function)
/usr/include/g++/sstream:122: confused by earlier errors, bailing out
error: command 'gcc' failed with exit status 1
wagner at lisa:~/cvs/scipy>



From nwagner at mecha.uni-stuttgart.de  Thu Aug 21 05:35:08 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 21 Aug 2003 11:35:08 +0200
Subject: [SciPy-dev] cannot build scipy with latest cvs
Message-ID: <3F44924C.BE5F6804@mecha.uni-stuttgart.de>

Dear experts,

I cannot build scipy with latest cvs

Any help would be appreciated...

Nils

In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_markers.h:24,
                 from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/agg_wrap.cxx:680:
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:54:
warning: `
   agg::renderer_primitives<PixelRenderer>::color_type' is implicitly a
   typename
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:54:
warning: implicit
   typename is deprecated, please see the documentation for details
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:55:
warning: `
   agg::renderer_primitives<PixelRenderer>::color_type' is implicitly a
   typename
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:55:
warning: implicit
   typename is deprecated, please see the documentation for details
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:56:
warning: `
   agg::renderer_primitives<PixelRenderer>::color_type' is implicitly a
   typename
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:56:
warning: implicit
   typename is deprecated, please see the documentation for details
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:57:
warning: `
   agg::renderer_primitives<PixelRenderer>::color_type' is implicitly a
   typename
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:57:
warning: implicit
   typename is deprecated, please see the documentation for details
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:207:
warning: `
   agg::renderer_primitives<PixelRenderer>::color_type' is implicitly a
   typename
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:207:
warning: implicit
   typename is deprecated, please see the documentation for details
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:208:
warning: `
   agg::renderer_primitives<PixelRenderer>::color_type' is implicitly a
   typename
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_primitives.h:208:
warning: implicit
   typename is deprecated, please see the documentation for details
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/agg_wrap.cxx:680:
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_markers.h:640:
warning: `
   agg::renderer_markers<PixelRenderer>::color_type' is implicitly a
typename
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_markers.h:640:
warning: implicit
   typename is deprecated, please see the documentation for details
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_markers.h:667:
warning: `
   agg::renderer_markers<PixelRenderer>::color_type' is implicitly a
typename
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_markers.h:667:
warning: implicit
   typename is deprecated, please see the documentation for details
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_markers.h:667:
warning: `
   agg::renderer_markers<PixelRenderer>::color_type' is implicitly a
typename
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_markers.h:667:
warning: implicit
   typename is deprecated, please see the documentation for details
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/agg_wrap.cxx:681:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_image_enums.h:38:7:
warning: no newline at end of file
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:45,
                 from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/agg_wrap.cxx:982:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_font_type.h:28:7:
warning: no newline at end of file
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:46,
                 from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/agg_wrap.cxx:982:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_dash_type.h:53:7:
warning: no newline at end of file
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:47,
                 from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/agg_wrap.cxx:982:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_state.h:56:7:
warning: no newline at end of file
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_image.h:32,
                 from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:49,
                 from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/agg_wrap.cxx:982:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_text_image.h:116:2:
warning: no newline at end of file
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:49,
                 from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/agg_wrap.cxx:982:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_image.h:
In
   constructor
`kiva::variable_color_alpha::variable_color_alpha(double)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_image.h:48:
warning: initialization
    to `int' from `double'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_image.h:48:
warning: argument
    to `int' from `double'
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:49,
                 from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/agg_wrap.cxx:982:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_image.h:390:7:
warning: no newline at end of file
In file included from
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/agg_wrap.cxx:982:
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:
In
   member function `void
   kiva::graphics_context::_draw_image_final(render_type&,
   agg::rendering_buffer&, const transform_type&, agg::path_storage&)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:864:
error: to
   refer to a type member of a template parameter, use `typename
   render_type::attr_type'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:
In
   member function `int
kiva::graphics_context::draw_marker_at_points(double*,
   int, int, agg::marker_e)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:980:
error: could
   not convert `kiva::graphics_context::get_ctm()()' to
`agg::affine_matrix&'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:64:
error: in
   passing argument 1 of `int
kiva::only_translation(agg::affine_matrix&)'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:993:
error: could
   not convert `kiva::graphics_context::get_ctm()()' to
`agg::affine_matrix&'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:72:
error: in
   passing argument 1 of `void
kiva::get_translation(agg::affine_matrix&,
   double*, double*)'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:997:
warning: passing
   `double' for argument 1 of `void
   agg::renderer_markers<PixelRenderer>::marker(int, int, int,
agg::marker_e)
   [with PixelRenderer = agg::pixfmt_bgra32]'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:997:
warning: passing
   `double' for argument 2 of `void
   agg::renderer_markers<PixelRenderer>::marker(int, int, int,
agg::marker_e)
   [with PixelRenderer = agg::pixfmt_bgra32]'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:
In
   member function `void
kiva::graphics_context::draw_path_at_points(double*,
   int, kiva::compiled_path&, kiva::draw_mode_e)':
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:1041:
error: could
   not convert `kiva::graphics_context::get_ctm()()' to
`agg::affine_matrix&'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:54:
error: in
   passing argument 1 of `int kiva::is_identity(agg::affine_matrix&)'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:1052:
error: could
   not convert `kiva::graphics_context::get_ctm()()' to
`agg::affine_matrix&'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:64:
error: in
   passing argument 1 of `int
kiva::only_translation(agg::affine_matrix&)'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/agg_wrap.cxx:1137:33:
numeric/arrayobject.h: Datei oder Verzeichnis nicht gefunden
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_text_image.h:
In
   member function `void kiva::pixel_formats_rgba32_text_nn<Order,
   Attribute>::span(int8u*, int, int, unsigned int, const int8u*,
   SpanInterpolator&) [with SpanInterpolator =
   agg::span_null_interpolator<kiva::alpha_text_type>::interpolator,
Order =
   agg::order_bgra32, Attribute = kiva::alpha_text_type]':
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_renderer_scanline.h:100:  
instantiated from `void agg::renderer_scanline<SpanInterpolator,
PixelRenderer>::render(const Scanline&) [with Scanline =
agg::scanline_u8, SpanInterpolator =
agg::span_null_interpolator<kiva::alpha_text_type>, PixelRenderer =
kiva::pixfmt_bgra32_text_nn<kiva::alpha_text_type>]'
/export/home/wagner/cvs/scipy/Lib_chaco/agg2/include/agg_rasterizer_scanline_aa.h:371:  
instantiated from `void agg::rasterizer_scanline_aa<Scanline,
GammaFunction>::render(Renderer&, int, int) [with Renderer =
agg::renderer_scanline<agg::span_null_interpolator<kiva::alpha_text_type>,
kiva::pixfmt_bgra32_text_nn<kiva::alpha_text_type> >, Scanline =
agg::scanline_u8, GammaFunction = agg::null_gamma]'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:870:  
instantiated from `void
kiva::graphics_context::_draw_image_final(render_type&,
agg::rendering_buffer&, const transform_type&, agg::path_storage&) [with
render_type = kiva::pixfmt_bgra32_text_nn<kiva::alpha_text_type>,
transform_type = kiva::alpha_text_type]'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_graphics_context.h:948:  
instantiated from here
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_text_image.h:32:
warning: assignment
    to `int' from `double'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_text_image.h:32:
warning: argument
    to `int' from `double'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_text_image.h:33:
warning: assignment
    to `int' from `double'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_text_image.h:33:
warning: argument
    to `int' from `double'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_text_image.h:34:
warning: assignment
    to `int' from `double'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_text_image.h:34:
warning: argument
    to `int' from `double'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_text_image.h:35:
warning: assignment
    to `int' from `double'
/export/home/wagner/cvs/scipy/Lib_chaco/kiva/agg/swig_src/kiva_text_image.h:35:
warning: argument
    to `int' from `double'
error: command 'gcc' failed with exit status 1



From nwagner at mecha.uni-stuttgart.de  Thu Aug 21 04:41:12 2003
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 21 Aug 2003 10:41:12 +0200
Subject: [SciPy-dev] ylabel disappears in the eps file
Message-ID: <3F4485A8.EBF8E60B@mecha.uni-stuttgart.de>

Dear experts,

When I redirect the output pf xplt.plot to an eps file via xplt.eps
the ylabel disappears in the eps file. A small example is illustrating
this
behaviour.

Any idea ?

Thanks in advance.

                         Nils


from scipy import *
from scipy.xplt import *
import gui_thread
x = arange(0,pi,0.1)
xplt.plot(x,sin(x),'dot',x,sin(x),'dash''r')
xplt.xlabel('x')
xplt.ylabel('y')
xplt.eps('somefile')



From dmorrill at enthought.com  Thu Aug 21 15:47:04 2003
From: dmorrill at enthought.com (David C. Morrill)
Date: Thu, 21 Aug 2003 14:47:04 -0500
Subject: [SciPy-dev] New release of Python 2.2.3 (Enthought Edition) available
Message-ID: <002701c3681d$0360c640$8201a8c0@dellbert>

Just thought we would give everyone a head's up that a new release of Python 2.2.3 (Enthought Edition) is available for download at:

http://www.enthought.com

The main changes in this release are improvements to the chaco and kiva packages. In particular, this is the first release of chaco that uses the new kiva "agg" (Anti_Grain) driver that supports:

- Faster rendering speeds.
- Anti-aliasing of lines and text.
- Alpha channel support for colors (i.e. transparency).
- Improved chaco and traits documentation formatting (generated using the new pydoh package).

Enjoy!

The Python guys at enthought
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20030821/8926b5b9/attachment.html>

From fperez at colorado.edu  Thu Aug 21 16:03:45 2003
From: fperez at colorado.edu (Fernando Perez)
Date: Thu, 21 Aug 2003 14:03:45 -0600
Subject: [SciPy-dev] Blitz++, NumArray...
Message-ID: <3F4525A1.3040701@colorado.edu>

Hi all,

as some of you know, I'm a big fan of weave.inline() for the ease of 
development it offers.  Essentially C++ becomes a scripting part of python, 
with only the occasional recompile overhead (but this is transparent to the 
users).

inline() makes heavy use of the blitz++ library, to represent numpy arrays as 
blitz arrays and therefore index them as Arr(i,j,k...).  This seems to me like 
a very sound decision, as the blitz library was specifically written to 
provide simultaneously fortran-like performance with high-level object 
orientation.

With this in mind, I have a few questions:

- Is there anything in Numarray's design which prevents this same trick from 
being used?  The core of getting a Numpy array into a blitz one is simply a 
call to:

// Convert a Numpy array to a blitz one, using the original's data (no copy)
template<class T, int N>
static blitz::Array<T,N> py_to_blitz(PyArrayObject *arr_obj)
{
     blitz::TinyVector<int,N> shape(0);
     blitz::TinyVector<int,N> strides(0);

     for (int i=0;i<N;i++) {
         shape[i] = arr_obj->dimensions[i];
         strides[i] = arr_obj->strides[i]/sizeof(T);
     }
     return blitz::Array<T,N>((T*) arr_obj->data,shape,strides,
                              blitz::neverDeleteData);
}


I would not be surprised if something much like this would work for Numarrays, 
but I'd like to know for sure.

- If the above is indeed possible for Numarray, do you guys feel that blitz 
should be considered an integral part of python's low-level arsenal, or not? 
I view its advantages especially in the field of an extremely clean, simple 
syntax (compared to the low-level Numpy API, I'm not familiar with Numarray 
yet).  I've seen examples where a numpy algorithm can be recoded using blitz 
in a _far_ smaller amount of code, and with performance gains to boot (in some 
cases, not all).

Please note that I am NOT second-guessing any of the design decisions made by 
the Numarray crowd. I just want to clarify if it's possible to have a C++ API 
which gives access to numarray with the simplest, highest-level syntax and 
behavior which is reasonable.  This is important for teams where not everyone 
is an expert on C pointer manipulation details, but they may be perfectly ok 
with writing loops over things which can be indexed as A(i,j,k).

- If any of this seems worthy of more detailed discussion, I told Eric Jones 
that I'd be happy to coordinate something along these lines at Scipy'03.  If 
there's time in the schedule I'd be glad to do it officially, otherwise we can 
just try to keep it in mind for a lunch/dinner meeting.

Documenting a 'Best Practices for low-level numerical work in python' would 
probably be a beneficial thing to do for the community.  Right now there are 
so many options that I'm sure I'm not the only one to feel a bit confused.

- If Blitz++ is indeed deemed a worthy piece of this puzzle, I wonder if we 
could contact some of its developers to bring them into this discussion.  I 
worry a bit that activity on its mailing lists seems rather slow, but I 
noticed that an apparently central guy, Julian C. Cummings, is at 
CACR/Caltech.  Perhaps he could stop by and let us know what the future for 
blitz looks like.  I can fire off an email to him if there is interest in the 
blitz thing.

Anyway, I'm just trying to 'pre-soak' a few ideas for discussion at scipy'03 
on these topics.

Best regards,

Fernando.



From perry at stsci.edu  Thu Aug 21 16:36:45 2003
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 21 Aug 2003 16:36:45 -0400
Subject: [SciPy-dev] Blitz++, NumArray...
In-Reply-To: <3F4525A1.3040701@colorado.edu>
Message-ID: <CEELJPECNGEGKFNDLHFFGEHBCAAA.perry@stsci.edu>

> Behalf Of Fernando Perez
> Subject: [SciPy-dev] Blitz++, NumArray...
>
[...]
> as some of you know, I'm a big fan of weave.inline() for the ease of
> development it offers.  Essentially C++ becomes a scripting part
> of python,
> with only the occasional recompile overhead (but this is
> transparent to the
> users).
>
> inline() makes heavy use of the blitz++ library, to represent
> numpy arrays as
> blitz arrays and therefore index them as Arr(i,j,k...).  This
> seems to me like
> a very sound decision, as the blitz library was specifically written to
> provide simultaneously fortran-like performance with high-level object
> orientation.
>
> With this in mind, I have a few questions:
>
> - Is there anything in Numarray's design which prevents this same
> trick from
> being used?  The core of getting a Numpy array into a blitz one
> is simply a
> call to:
>
Unfortunately, I'm neither knowledgeable (yet, anyway) about
blitz++ nor am I a C++ expert. On the other hand, with some
caveats, I would be very surprised if it isn't nearly as easy to do
the same in numarray as in numpy. Most of the C-API is identical so
it is possible that very few changes are necessary. On the other
hand, we aren't yet at the point of trying to deal with weave so
it would be a little while before we had time to tackle that
issue (at the moment, we are porting the MA package). After our
1.0 release, getting scipy to work with numarray becomes one of
our top priorities.

As for caveats, the primary one is that numarray allows some
flexibility in array storage that numpy doesn't. In particular
it allows data that is byteswapped from the normal processor order,
and arrays that are not aligned with the processor's address (both
to facilitate accessing memory mapped data and arrays of records).
For such arrays it is likely that weave will require a copy so
that the array elements may be accessed in the usual way. Since
such arrays are not permitted in numpy, this is in no way a
narrowing of capabilities.

[...]
> - If any of this seems worthy of more detailed discussion, I told
> Eric Jones
> that I'd be happy to coordinate something along these lines at
> Scipy'03.  If
> there's time in the schedule I'd be glad to do it officially,
> otherwise we can
> just try to keep it in mind for a lunch/dinner meeting.
>
Sure, but let us know what issues you think need to be worked out
in light of what I've already said. This may be a good opportunity
to get all those knowledgeable about the various components (Blitz++,
weave, and numarray) together to discuss what is needed.

> Documenting a 'Best Practices for low-level numerical work in
> python' would
> probably be a beneficial thing to do for the community.  Right
> now there are
> so many options that I'm sure I'm not the only one to feel a bit confused.
>
That's assuming that we know them all already :-) For our part we have been
concentrating on adding all the core numpy functionality and haven't yet
been able to address all issue. Over the next few months we will be
moving more into the scipy area and will be able to understand more of
the wider issues.

Perry



From fperez at colorado.edu  Fri Aug 22 10:15:42 2003
From: fperez at colorado.edu (Fernando Perez)
Date: Fri, 22 Aug 2003 08:15:42 -0600
Subject: [SciPy-dev] CVS trouble at scipy?
Message-ID: <3F46258E.6090702@colorado.edu>

Hi all,

today I'm seeing some problems when I commit code to CVS.  The commits seem to 
go through fine, but at the end something email-related is tripping.

Here's the error that I see:

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

cvs -f commit -l -m 'Clean up code for avoiding auto-call triggering on [] 
access.' 'IPython/iplib.py' 2>&1

Checking in IPython/iplib.py;

/home/cvsroot/world/ipython/IPython/iplib.py,v
new revision: 1.19; previous revision: 1.18

done

Traceback (innermost last):

File "/home/cvsroot/CVSROOT/syncmail", line 329, in ?

main()

File "/home/cvsroot/CVSROOT/syncmail", line 322, in main

blast_mail(subject, people, specs[1:], contextlines, fromhost)

File "/home/cvsroot/CVSROOT/syncmail", line 226, in blast_mail

domain = fromhost or getfqdn()

File "/home/cvsroot/CVSROOT/syncmail", line 93, in getfqdn

byaddr = socket.gethostbyaddr(socket.gethostbyname(hostname))

socket.error: host not found

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


No big deal for me, but I figured at some point somebody may want to look into 
  it.

Cheers,

f.



From joe at enthought.com  Fri Aug 22 10:43:21 2003
From: joe at enthought.com (Joe Cooper)
Date: Fri, 22 Aug 2003 09:43:21 -0500
Subject: [SciPy-dev] CVS trouble at scipy?
In-Reply-To: <3F46258E.6090702@colorado.edu>
References: <3F46258E.6090702@colorado.edu>
Message-ID: <3F462C09.8040001@enthought.com>

Fernando Perez wrote:
> Hi all,

> No big deal for me, but I figured at some point somebody may want to 
> look into  it.

Thanks for the heads up, Fernando, I'm looking into it.



From Chris.Barker at noaa.gov  Fri Aug 22 12:43:30 2003
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Fri, 22 Aug 2003 09:43:30 -0700
Subject: [SciPy-dev] Re: [Numpy-discussion] Blitz++, NumArray...
References: <3F4525A1.3040701@colorado.edu>
Message-ID: <3F464832.839785B5@noaa.gov>

Fernando Perez wrote:

> - Is there anything in Numarray's design which prevents this same trick from
> being used?

It's not entirely clear to me what you have in mind. ARE you proposing
that Blitz++ arrays be the low-level implimentaiton of Numarray?, or
just that there be an easy way to switch between them.

In the first case, it was considered a coupl eof years ago, and rejected
(as far as I could tell) mainly for reasons of portability: Blitz++
makes heavy use of templates, which are not well supported by the very
wide variety of compilers that Python is supported on. One of the goals
of Numarray is to make it into the Python standard library, and use of
C++ and templates would preclude that, at least in the foreseeable
future.

Here's one discussion about it:

http://www.geocrawler.com/mail/thread.php3?subject=%5BNumpy-discussion%5D+Meta%3A+too+many+numerical+libraries+doing+the&list=1329

If that url doesn't work, I found it by searching google for:

Numpy-discussion blitz++

If you are proposing the second: that there could be an easy bridge
between Numarray and Blitz++ (maybe using Boost Python somehow?) so that
Blitz++ arrays could be used to write Numarray extensions, I'm all for
it! I think the community would gain a great deal from an easier to use
API for writing compiled Numarray functions. Besides making it easier
for those of us that find the need for custom extensions, it would make
it much easier for people to write and contibute high performance
general purpose code--resulting in a much expanded library for Numarray
and SciPy.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov



From fperez at colorado.edu  Fri Aug 22 14:00:32 2003
From: fperez at colorado.edu (Fernando Perez)
Date: Fri, 22 Aug 2003 12:00:32 -0600
Subject: [SciPy-dev] Re: [Numpy-discussion] Blitz++, NumArray...
In-Reply-To: <3F464832.839785B5@noaa.gov>
References: <3F4525A1.3040701@colorado.edu> <3F464832.839785B5@noaa.gov>
Message-ID: <3F465A40.8080508@colorado.edu>

Chris Barker wrote:
> Fernando Perez wrote:
> 
> 
>> - Is there anything in Numarray's design which prevents this same trick
>> from being used?
> 
> 
> It's not entirely clear to me what you have in mind. ARE you proposing that
> Blitz++ arrays be the low-level implimentaiton of Numarray?, or just that
> there be an easy way to switch between them.

Well, it was a bit of both. I'm glad to have been ambiguous, since you 
answered both :)

> In the first case, it was considered a coupl eof years ago, and rejected 
> (as far as I could tell) mainly for reasons of portability: Blitz++ makes
> heavy use of templates, which are not well supported by the very wide
> variety of compilers that Python is supported on. One of the goals of
> Numarray is to make it into the Python standard library, and use of C++ and
> templates would preclude that, at least in the foreseeable future.

I sort of suspected this, so while this option sounds very nice in theory, I
didn't expect it to be a realistic possibility.

> If you are proposing the second: that there could be an easy bridge between
> Numarray and Blitz++ (maybe using Boost Python somehow?) so that Blitz++
> arrays could be used to write Numarray extensions, I'm all for it! I think
> the community would gain a great deal from an easier to use API for writing
> compiled Numarray functions. Besides making it easier for those of us that
> find the need for custom extensions, it would make it much easier for
> people to write and contibute high performance general purpose
> code--resulting in a much expanded library for Numarray and SciPy.

This is more realistic, and in fact today it _is_ a reality.  As I posted
before, making a blitz array out of a numpy one is trivial, and you get
fast, easy to read C++.  I initially learned how to do it by
reverse-engineering weave.inline's auto-generated C++ files, but once that
got me off the ground, it was trivial to write my own extension modules.
And now that I'm starting to learn a bit more about the capabilities of the
blitz library, I'm very excited.

To indirectly answer Perry's email in this same thread: after his comments,
it seems to me that the Numarray->blitz operation would work just as easily
as the example I showed for Numpy->blitz.  Perry says that in memory,
numarrays are very similar to Numpys, so this shouldn't be a problem.

Which means we are already quite a ways there!  I think to some extent, it's
more a matter of making better known to people that this approach exists,
and how easy to use it is.  I only learned about it after being impressed
with inline's super-simple syntax as compared to the horrors of handling
numpy arrays by hand.  But the more I read the blitz manual, the more I see
that blitz arrays behave _a lot_ like numpy arrays even inside the C++ code.

So the bridge approach, as long as the constructor call is very cheap, seems
like a perfectly reasonable balance between aesthetic purity and real-world
practicality to me.  This doesn't mean that there are no issues to be
discussed, so I'll try to outline the ones that come to mind (as per Perry's
request).  Perhaps others can add to this list.

1- Cheap constructors:  For a rank-N array, the current constructor still
requires the creation of 2 TinyVector blitz arrays of size N (shape and
strides).  It would be great if these copies could be avoided and the
existing shape & strides data from the Numpy array could be used directly.
The Numpy-> blitz functions would then be almost zero-overhead operations.

2- Access to fortran libraries:  I don't know how easy it is to use say BLAS
with objects defined in C++ (and with row-major memory layout).   This is
just my ignorance, but I'd like to clarify this point, since it would be
nice to be able to use BLAS/LAPACK from within the C++ code with blitz
arrays with no transposition overhead.

3- Benchmark:  I think it would be valuable to draft a small but reasonable
set of benchmarks comparing the raw numeric/numarray C api, the blitz
version and fortran versions of some common algorithms.  Blitz relies
heavily on templates and C++ compilers are getting better, so it would be
nice to know where things stand.  I have a preliminary version of this, which 
I've posted here, but it only covers innerproduct().

As part of that testing, I found more numerical discrepancy than seemed 
reasonable to me.  I would really need to understand the origin of this before 
feeling comfortable with the blitz approach for production codes.

4- Multiple precision:  For a certain class of problems, beign able to work 
with Numerical arrays whose precision goes beyond double is critical.  At 
http://crd.lbl.gov/~dhbailey/mpdist/index.html there is a good example of a 
modern, C++ library for extended precision which offers a very simple syntax. 
  I wonder how easy (or not) it would be for Numarray to offer optional 
support for this kind of arrays.

This last topic is a bit more ambitious than the others (which I think seem to 
be very reasonabl).  However, I hope that we can at least discuss it, since 
there is a class of problems where it is a really important issue.


There may be more things I can't think of now, but hopefully this may serve as 
a first outline for a discussion, both on the mailing list and in person, at 
scipy.

Best,

f



From eric at enthought.com  Mon Aug 25 18:31:01 2003
From: eric at enthought.com (Eric Jones)
Date: Mon, 25 Aug 2003 17:31:01 -0500 (CDT)
Subject: [SciPy-dev] ANN: SciPy'03 is getting close!
Message-ID: <20030825223101.1280D1057@www.enthought.com>

Hey Group,

Just wanted to send out another reminder about SciPy'03 which will be held at Cal Tech on September 11th and 12th.  Information about the workshop is available on its home page:

    http://www.scipy.org/site_content/scipy03/

The schedule for the workshop is available at:

    http://www.scipy.org/site_content/scipy03/scipy03sched.htm

Online registration is also open:

    https://www.enthought.com/scipy03/ 

Currently, their are around 50 people registered.  Please register as soon as possible if you plan on attending so that we have an accurate count for food, etc.

thanks!
eric

From joe at enthought.com  Thu Aug 28 15:55:04 2003
From: joe at enthought.com (Joe Cooper)
Date: Thu, 28 Aug 2003 14:55:04 -0500
Subject: [SciPy-dev] scipy.org mail server going down for upgrades
Message-ID: <3F4E5E18.5010108@enthought.com>

Hi all,

The scipy mail server will be taken down in just a few minutes for a 
system upgrade.  Service should resume in under an hour, assuming no 
problems.

Thanks!



From joe at enthought.com  Thu Aug 28 19:28:42 2003
From: joe at enthought.com (Joe Cooper)
Date: Thu, 28 Aug 2003 18:28:42 -0500
Subject: [SciPy-dev] SciPy.org upgrades complete
Message-ID: <3F4E902A.4000807@enthought.com>

Hi all,

The work on scipy.org is complete, and everything should be back up and 
running normally.  If you spot problems with mail, Zope, or the roundup 
bug tracker, let me know.

Thanks!