Re: [IronPython] My takes on C Extensions for IronPython
Seo Sanghyeon wrote: > The discussion is getting very confusing, > It is indeed! > The good news is that this part is already developed, debugged, and pretty > much finished -- for Python 2.3 to 2.6, and for wide and narrow unicode > builds of Python. Get it here (~ 1600 lines): > http://pythonnet.svn.sourceforge.net/svnroot/pythonnet/trunk/pythonnet/src/runtime/runtime.cs > > Assuming that ZPL (which is OSI-certified) is okay, it would be strange not > to use this. > I'm a bit confused here... Unless I'm completely misunderstanding the code, it looks like it's a set of DllImports allowing you to access the CPython C extensions API from managed code. This let's you write managed code that extends CPython - which I assume is the Python.NET developers' intention - but we're trying to write unmanaged code to extend IronPython. Am I missing some obvious way in which we could use it? I guess it would work as a template to follow when writing the equivalent for calling into IronPython...? 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] My takes on C Extensions for IronPython
2007/10/18, Paolo Molaro <[EMAIL PROTECTED]>: > My point still stands: interoperating with the C code is not an issue. Agreed. > Also the gcc CLI backend > is not really complete and even if it were it doesn't mean that C++/CLI > would be any easier to implement on top of it. I'm not interested in C++/CLI, and I don't think it's needed for CPython anyway. -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] My takes on C Extensions for IronPython
I'll just reply here and try to summarize some things. On 10/18/07 Seo Sanghyeon wrote: > It's certainly more than 200 lines, and it's not completely trivial > because some parts of Python/C API are C macros, not C functions. > (Reference counting is the most important, but also getting > type(=vtable) of Python objects and like.) > > The good news is that this part is already developed, debugged, and > pretty much finished -- for Python 2.3 to 2.6, and for wide and narrow > unicode builds of Python. Get it here (~ 1600 lines): That code has each dllimport method spanning 5 lines of code. I don't consider a cut and pasted [DllImport()] attribute as something that is hard to write:) So this complete work that covers 4 major versions of python is less than 200 p/invokes. It's missing a few structure definitions. Nothing an intern can't write in an afternoon. My point still stands: interoperating with the C code is not an issue. > I understand MC++ or Managed C++ is used to refer related > technologies, but in the narrow sense it is a compiler that shipped > with .NET 1.x which produced mix of managed and x86 code. I > believe .NET 2.x compiler, i.e. C++/CLI is what is currently > discussed. Yes, Managed C++ referes to the old broken and already abandoned technology, but it's sometimes used also to refer to the new C++/CLI lanaguage, likely because C++/CLI is not a really good name:) > It would be nice to be able to compile without Microsoft tools, but I > don't think it's essential. If assembly compiled with C++/CLI / > clr:pure can be made to run on Mono that's fine. First, someone should investigate if clr:pure actually provides seamless integration with C code. I doubt it works, but I'll wait for someone using windows to confirm this. The issue then is that, even if the above would work, the MS C++/CLI compiler will emit code that depends on the windows ABI (specifically always considering long to be 32 bits, they even put this in the standard, sigh). What this means for people not familiar with low-level details, is that such code is not portable and hence won't work on Linux 64 bit systems (this is always assuming the interoperability with C code works at all even on 32 bit systems). So, while it's not essential that this code be built with non-Microsoft tools, only the MS tools are able to compile that code and they compile it incorrectly (and as the C++/CLI standard requires, sadly, so there is no chance this will be ever fixed). > Also Mono page doesn't mention this, but GCC backend to emit CLI code > *is* complete and working. It's available right now from GCC SVN. But > it's yet another project, not Google Summer of Code attempts. This > project is backed by STMicroelectronics, a big corporation, probably > for its own use. > http://gcc.gnu.org/projects/cli.html > > Remember, Mono doesn't need to be the sole provider of non-Microsoft > CLI tools. :) I believe GCC/CLI can be made to help this project. See above for the portability issues: they'd have to either not follow the standard or to produce non-working code. Also the gcc CLI backend is not really complete and even if it were it doesn't mean that C++/CLI would be any easier to implement on top of it. My estimate is that C++/CLI on top of gcc will require at least 4-5 years, if someone implements it at all (there is not much demand for it, there are the portability and standard issues I mentioned above and by that time Mono will have an extension to semalessly dllimport C++ code, lowering demand for C++/CLI even more). In 4-5 years Microsoft itself will pull the plug on C++/CLI, so I think basing a new design on it is a mistake. Anyway, I'm not the one who's going to write the code, so more power to people that will, I just wanted to make people aware that using managed C++ or C++/CLI will prevent the sw to work on anything but windows with the .net runtime. Happy hacking! lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] My takes on C Extensions for IronPython
The discussion is getting very confusing, so here are some of my takes on the issues. On the issue of P/Invoke declarations for Python/C API, Paolo Molaro wrote: "The python API requires a couple dozen structure definitions plus a few dozen dllimport declarations. This can be about 200 lines of trivial to write declarative stuff." It's certainly more than 200 lines, and it's not completely trivial because some parts of Python/C API are C macros, not C functions. (Reference counting is the most important, but also getting type(=vtable) of Python objects and like.) The good news is that this part is already developed, debugged, and pretty much finished -- for Python 2.3 to 2.6, and for wide and narrow unicode builds of Python. Get it here (~ 1600 lines): http://pythonnet.svn.sourceforge.net/svnroot/pythonnet/trunk/pythonnet/src/runtime/runtime.cs Assuming that ZPL (which is OSI-certified) is okay, it would be strange not to use this. On the issue of compiling C or C++ to CLI, Keith J. Famer wrote: "My impression was that they're working under the assumption that you cannot get C++ code to compile to pure managed (False, use C++/CLI as recommended on the Mono site), and that it must *compile* under Mono (laudable, but I doubt it's necessary -- I've never bothered to recompile the Python Libraries)." Readers not familiar with the issue should read Mono documentation mentioned: http://www.mono-project.com/CPlusPlus I understand MC++ or Managed C++ is used to refer related technologies, but in the narrow sense it is a compiler that shipped with .NET 1.x which produced mix of managed and x86 code. I believe .NET 2.x compiler, i.e. C++/CLI is what is currently discussed. It would be nice to be able to compile without Microsoft tools, but I don't think it's essential. If assembly compiled with C++/CLI / clr:pure can be made to run on Mono that's fine. Also Mono page doesn't mention this, but GCC backend to emit CLI code *is* complete and working. It's available right now from GCC SVN. But it's yet another project, not Google Summer of Code attempts. This project is backed by STMicroelectronics, a big corporation, probably for its own use. http://gcc.gnu.org/projects/cli.html Remember, Mono doesn't need to be the sole provider of non-Microsoft CLI tools. :) I believe GCC/CLI can be made to help this project. Okay, enough said for this mail... -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
