[pypy-dev] Yet another trace tool!

Armin Rigo arigo at tunes.org
Fri Aug 27 10:34:35 CEST 2004


Hello Richard,

On Tue, Aug 24, 2004 at 12:12:51AM +0100, Richard Emslie wrote:
> To run go to translator/tool and run flowtrace.py ! There is a debug flag 
> to FlowTracer which will give you some idea what is actully being traced!

It uses the earthenware package, about which I can't seem to find more info
with Google...

> Well - back to gencpp.py then. :-)

I am still struggling to find a reasonably clean way to have genc.py emit
typed C code.  I was wondering about using C++'s overloaded functions:  
gencpp.py could write an operation as a call like z=op_add(x,y), which the C++
compiler would resolve into a call to one of the predefined overloaded
implementations of op_add().  The compiler would also insert automatic
conversions with some C++ class trickery.  I'm a bit hesitant to go into that
direction for two reasons: we could get C++ compile errors in the presence of
ambiguities (i.e. when two overloaded functions could equally well be used for
a call); and gcc generates suboptimal code when we use structs or classes with
just one or two fields, like this one:

class PyObjectRef {
    PyObject* p;
  public:
    explicit PyObjectRef(PyObject* np) { p = np; } // constructor, consumes 
                                                   // reference
    ~PyObjectRef() { Py_DECREF(p); }      // destructor
    PyObjectRef(int n) { p = PyInt_FromLong(n); }   // conversion constructor
};

int op_add(int a, int b) { return a+b; }
PyObjectRef op_add(PyObjectRef &a, PyObjectRef &b) {
    return PyObjectRef(PyNumber_Add(a.p, b.p));
}

The conversion constructor from int to PyObjectRef is applied automatically by
the compiler, so it is quite nice, but you get a program that handles pointers
to PyObjectRefs (which are pointers to PyObject*, i.e. PyObject**) instead of
just PyObject*.  There might be a way to fix that, but that starts to be 
hackish.

Maybe Boost.Python already solves all these problems?

Well, is it a good idea to -- again -- target a high-level language and then
have to work around some of its concepts when they are not fully suited to our
low-level needs...?


Armin



More information about the Pypy-dev mailing list