[GiNaC-list] Python bindings to GiNaC (problem solved)

[Jonathan Brandmeyer]

On Tue, 2005-01-11 at 21:24 +0200, Matti Peltomäki wrote:
> Hi, 
> 
> >> I wanted to check out the use of lsolve() inspired by check/exam_lsolve.cpp
> > See also bin/check_lsolve.py in the PyGiNaC source tree.  It's basically
> > a straight pythonization of the C++ code.
> 
> Yes. Thanks for the pointer.
> 
> >> Below is a short example showing what I did and which errors I got. I run 
> >> python as './run python2.3' in the root of pyginac source tree after having
> >> succesfully built it with scons. 
> > I've got basically (exactly?) the same configuration as you, but I get
> > this result instead:
> 
> So do I now. The problem turned out be my fault. I had upgraded GiNaC from 
> 1.2.4 to 1.3.0 in the process of compiling PyGiNaC (after realising that it 
> was indeed needed) with the result that objects built against the earlier 
> version were left around. Without doing the same mistake again, I cannot
> reproduce the odd behaviour anymore. 

I'll add a check for this that gets run at import time.

For the GiNaC folks: Is there any guarantee that the values for the
tinfo constants will not change between tiny versions of GiNaC?  Phrased
differently: are the tinfo constants considered part of the external
ABI?

Thanks,
-Jonathan Brandmeyer