We've created a Google Group to discuss this project, and if anyone's interested in contributing or advising, you're very welcome to sign up: <http://groups.google.com/group/c-extensions-for-ironpython/>
My replies to everyone's comments below: David Cournapeau wrote: > Giles, maybe you could see with the pypy people if they can give you some advice, too Thanks for the pointer - I'd heard of PyPy, but it hadn't occurred to me that they have valuable knowledge about how to do this kind of thing - obvious now you point it out :-). I'll get in touch with them. > According to pypy developers, the best way to extend python in C is to use ctypes: There was an effort to get ctypes working with IronPython a while back - the CPython Reflector by Sanghyeon Seo that Albert Strasheim mentioned - Seo has just joined our mailing list, so we'll certainly start a discussion about that. > Christopher Barker wrote: > > Is there a C# <-> C (or, I guess, really a .net <-> C ) binding > > mechanism? Like JNI for Java? > I don't know much about the whole .Net thing (CLR, in this case), but > there is the p-invoke mechanism for that P/Invoke is indeed the normal way to link C# with C; we use it in our software on those (luckily rare) occasions when we have to step outside the .NET world and talk to the basic Win32 APIs. It's pretty easy to do, and our initial thoughts about the best way to integrate IronPython with NumPy were that we would use P/Invoke to call into the C library (I agree with Travis E. Oliphant that trying to convert the existing C to C# would be a Bad Idea). Using P/Invoke would give us a very rough-and-ready .NET API, which we could then wrap with a Python library that <handwaving>interfaced with the existing CPython library in some manner</handwaving>. > I don't know the performance impact. I don't think P/Invoke slows down the running of the C code, but of course calls from .NET to native code are quite slow. My expectation so far has been with most Python code using NumPy, the number-crunching will happen at the native code level, with relatively few switches between languages - that is, it is a "chunky" rather than a "chatty" API. Is that a reasonable assumption? > The best would be of course a solution which enables interop, > so that if later, people want to use the work gone into numpy > for IronPython, people do not have to start everything from > scratch for say Jython or something else. But maybe this is > too big of a task. We're aiming to try to solve the "simple" case of one Python implementation, one C extension to start off with. Our intention was to then look at handling a couple of other extensions, to broaden the solution more toward a general solution for loading C extensions into IronPython - I agree that we could usefully also broaden it to handle other Python implementations. Regards, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
