Mailman 3 June 2008 - capi-sig

ANNOUNCE: PyBindGen 0.8
by Gustavo Carneiro March 10, 2022

March 10, 2022

The other day I released PyBindGen 0.8. Main news is that it features a new experimental header file scanner based on pygccxml (i.e., it's similar to py++ in scope, if not in maturity, but does not use boost.pythonunderneath). == What == PyBindGen is a Python module that is geared to generating C/C++ code that binds a C/C++ library for Python. It does so without extensive use of either C++ templates or C pre-processor macros. It has modular handling of C/C++ types, and can be easily extended with Python plugins. The generated code is almost as clean as what a human programmer would write, and does not depend on any library or header files besides Python itself. == Where == https://launchpad.net/pybindgen/ == NEWS == - Support C++ instance attributes through getter/setter methods - Support functions as methods of C++ classes - Support the PyObject* type - Support unsigned int, C strings (char*) (from Mark Lee) - Add basic support for enum types - New experimental automatic module generator based on C/C++ header file scanner and annotations in comments, using pygccxml - Some bug fixes -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert

2 1

Re: [capi-sig] Segfault when using own C-written module and exiting python
by Laurent Gautier June 8, 2008

June 8, 2008

2008/6/7 Stefan Behnel <stefan_ml(a)behnel.de>: > Hi, > > laurent wrote: >> On Fri, 2008-06-06 at 13:23 +0200, Stefan Behnel wrote: >>> If the existing code base isn't too large yet, consider switching to Cython >>> instead of C. >> >> The C part is only a little more than 2000 lines of source so far >> (and with no plan to go much beyond that, it's about feature-complete >> for a first release). > > This might be a good read then: > > http://permalink.gmane.org/gmane.comp.python.cython.devel/1965 > > >> The CPython project looks very nice. > > Cython. CPython is the name commonly used for the standard Python implementation. > Yes. It was just a freudian slip, I suppose. >> However, there are potentially dark corners I have to work around (and >> so far I am not completely successful at it, as my post suggests > > Then you should really consider letting Cython give you a hand with the ugly > things (like garbage collection or class definition), so that you can > concentrate on the more interesting stuff. Yes, I have read the mailing reference in the beginning of your mail... and I'll stick to C given the nature of what I have to do (especially since this is now working ;-) ). > Stefan > >

1 0

Segfault when using own C-written module and exiting python
by Laurent Gautier June 8, 2008

June 8, 2008

Dear List, I am having trouble with some of the use-cases for a C-written module of my own (if curious, I am working on Python-R interface... this is open source so I can provide the whole source if needed). Everything is working just fine and as expected... until the python process exits. When running my test script through gdb and with the '-v' flag for Python, it ends with --- # cleanup __main__ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7dde8c0 (LWP 19670)] 0x080f3d08 in PyObject_GC_UnTrack () --- I have looked for information on the internet... but have not found much. Would this kind of error be familiar to anyone ? Thanks, Laurent

4 5

Re: [capi-sig] Segfault when using own C-written module and exiting python
by Stefan Behnel June 7, 2008

June 7, 2008

Hi, laurent wrote: > On Fri, 2008-06-06 at 13:23 +0200, Stefan Behnel wrote: >> If the existing code base isn't too large yet, consider switching to Cython >> instead of C. > > The C part is only a little more than 2000 lines of source so far > (and with no plan to go much beyond that, it's about feature-complete > for a first release). This might be a good read then: http://permalink.gmane.org/gmane.comp.python.cython.devel/1965 > The CPython project looks very nice. Cython. CPython is the name commonly used for the standard Python implementation. > However, there are potentially dark corners I have to work around (and > so far I am not completely successful at it, as my post suggests Then you should really consider letting Cython give you a hand with the ugly things (like garbage collection or class definition), so that you can concentrate on the more interesting stuff. Stefan

1 0