Hi there, I just read about this on the PyPy status blog and find myself wondering about the strategies you considered before settling on the Reflex approach. I've had an extension to ctypes in mind for quite some time that involves simply leaving the debugging segments present in a shared library in order to be able to introspect them and provide type-safe access to the code within. The idea is simple: implement a DWARF/stabs/etc. interpreter that can construct Python types and function proxies to represent what is present in the shared library. Initially I wanted this for C, so that a Python programmer needn't manually declare structs using quirky ctypes class definitions, but I can't see why a (rather more complex) implementation couldn't reconstruct C++ classes with their associated class/member functions. The obvious benefit is that a C/C++ library need not be modified at all in order to benefit, other than not being stripped of debugging information during its build. Linux distributions are slowly gaining infrastructure that makes this almost zero cost (e.g. the Debian python-dbg package). I've had the DWARF specification sitting on my desktop for about 2 months now, waiting for me to validate my idea. I'm wondering if you've considered this approach, and if so, why you discarded it. Thanks, David.
On Tue, Oct 14, 2008 at 6:39 PM, David Wilson <dw@botanicus.net> wrote:
Hi there,
I just read about this on the PyPy status blog and find myself wondering about the strategies you considered before settling on the Reflex approach.
We're not settling on it. It's rather "first to try".
I've had an extension to ctypes in mind for quite some time that involves simply leaving the debugging segments present in a shared library in order to be able to introspect them and provide type-safe access to the code within.
The idea is simple: implement a DWARF/stabs/etc. interpreter that can construct Python types and function proxies to represent what is present in the shared library. Initially I wanted this for C, so that a Python programmer needn't manually declare structs using quirky ctypes class definitions, but I can't see why a (rather more complex) implementation couldn't reconstruct C++ classes with their associated class/member functions.
The problem with such approach is usually that this is too low level. Gaining back lost abstraction level is usually hard and sometimes impossible. I cannot say exactly that this approach is not worth following - I'll just try to use reflex first as it seems people are using it to do complex tasks. Of course feel free to prove that I'm wrong, right now I'm more thinking about possibilities (hence questions on blog to people to provide input), than settling on anything.
The obvious benefit is that a C/C++ library need not be modified at all in order to benefit, other than not being stripped of debugging information during its build. Linux distributions are slowly gaining infrastructure that makes this almost zero cost (e.g. the Debian python-dbg package).
I've had the DWARF specification sitting on my desktop for about 2 months now, waiting for me to validate my idea.
I'm wondering if you've considered this approach, and if so, why you discarded it.
The answer is simple: we didn't consider it yet :-)
Hi David, David Wilson wrote:
I just read about this on the PyPy status blog and find myself wondering about the strategies you considered before settling on the Reflex approach.
I've had an extension to ctypes in mind for quite some time that involves simply leaving the debugging segments present in a shared library in order to be able to introspect them and provide type-safe access to the code within.
The idea is simple: implement a DWARF/stabs/etc. interpreter that can construct Python types and function proxies to represent what is present in the shared library. Initially I wanted this for C, so that a Python programmer needn't manually declare structs using quirky ctypes class definitions, but I can't see why a (rather more complex) implementation couldn't reconstruct C++ classes with their associated class/member functions.
The obvious benefit is that a C/C++ library need not be modified at all in order to benefit, other than not being stripped of debugging information during its build. Linux distributions are slowly gaining infrastructure that makes this almost zero cost (e.g. the Debian python-dbg package).
I've had the DWARF specification sitting on my desktop for about 2 months now, waiting for me to validate my idea.
I'm wondering if you've considered this approach, and if so, why you discarded it.
One problem of this approach (in addition to what Maciek mentioned) is that the debug information is quite large. It contains much more information that what is needed for doing language bindings, e.g. also detailed information about the inside of functions ("when the PC is this, these variables are in those registers"). The Reflex information should be rather small in size, compared to that. Cheers, Carl Friedrich
participants (3)
-
Carl Friedrich Bolz -
David Wilson -
Maciej Fijalkowski