Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Curt Hagenlocher wrote: Hypothetically, you could muck about with the unmanaged interfaces to the managed code execution engine and pull in the information that way. How much of the MSCOREE-exposed functionality does Mono implement? Mind you, I don't actually think this is a good idea. It does sound risky. Perhaps just going with a struct as lupus suggested is the simplest cross-platform solution, even if it does require an initialisation function of some sort. Cheers, 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] Announcement: Project to get some CPython C extensions running under IronPython
On 10/19/07, Giles Thomas [EMAIL PROTECTED] wrote: Paolo Molaro wrote: You can use a struct that contains all the needed delegates and pass that on the p/invoke call. I guess that's a bit cleaner, as is Curt's COM version. But I was really hoping to be able to avoid the init call from the managed side entirely. Hypothetically, you could muck about with the unmanaged interfaces to the managed code execution engine and pull in the information that way. How much of the MSCOREE-exposed functionality does Mono implement? Mind you, I don't actually think this is a good idea. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Paolo Molaro wrote: You can use a struct that contains all the needed delegates and pass that on the p/invoke call. I guess that's a bit cleaner, as is Curt's COM version. But I was really hoping to be able to avoid the init call from the managed side entirely. 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] Announcement: Project to get some CPython C extensions running under IronPython
Paolo Molaro wrote: or 3, the easiest of all: using function pointers in the C code which the runtimes will generate automatically when passing a delegate to a p/invoked method. Besides being trivial compared to both 1 and 2, it works on Mono and it works on the MS CLR. I'm glad you mentioned that; we use it in our P/Invoked code (for the callback when iteration over windows), and it works just fine; I was beginning to worry that it might not work on Mono. A question - if we were trying to produce something that, at a source level, looked like the CPython extensions API, is there any easy way that we could get that to be able to call back to IronPython? I can imagine something like an init() function on the managed side that could pass a number of delegates over to the unmanaged code so that they could be called back at a later point, but is there a more elegant solution? Cheers, 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] Announcement: Project to get some CPython C extensions running under IronPython
On 10/19/07, Giles Thomas [EMAIL PROTECTED] wrote: A question - if we were trying to produce something that, at a source level, looked like the CPython extensions API, is there any easy way that we could get that to be able to call back to IronPython? I can imagine something like an init() function on the managed side that could pass a number of delegates over to the unmanaged code so that they could be called back at a later point, but is there a more elegant solution? You could define a COM / COM-like interface (or set of interfaces), implement them in C# and pass them to the C code. This is definitely cleaner but has the disadvantage of a tighter binding between the two parts and a potentially much more painful versioning story. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
On 10/17/07 Tony Djordjevski wrote: You do need to write C code as the API is a C API. I didn't list in the last mail because the C implementation of these functions is not a difference between the C# impl and the C++ impl of the rest of the code. The dllimport declarations I mentioned above would pinvoke to these C functions. Those C functions you speak about will need to execute managed code. So, either way, what needs to be done is to allow Reverse P/Invoke or some form of DllExport. Assuming this project is successful, native C/C++ will have to, at some point, execute managed code. There are only two ways that I know of that you can accomplish this in .NET: 1. C++ Interop 2. Modifying a compiled assembly or 3, the easiest of all: using function pointers in the C code which the runtimes will generate automatically when passing a delegate to a p/invoked method. Besides being trivial compared to both 1 and 2, it works on Mono and it works on the MS CLR. 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
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Paolo Molaro wrote: On 10/17/07 Tony Djordjevski wrote: You do need to write C code as the API is a C API. I didn't list in the last mail because the C implementation of these functions is not a difference between the C# impl and the C++ impl of the rest of the code. The dllimport declarations I mentioned above would pinvoke to these C functions. Those C functions you speak about will need to execute managed code. So, either way, what needs to be done is to allow Reverse P/Invoke or some form of DllExport. Assuming this project is successful, native C/C++ will have to, at some point, execute managed code. There are only two ways that I know of that you can accomplish this in .NET: 1. C++ Interop 2. Modifying a compiled assembly or 3, the easiest of all: using function pointers in the C code which the runtimes will generate automatically when passing a delegate to a p/invoked method. Besides being trivial compared to both 1 and 2, it works on Mono and it works on the MS CLR. Happy hacking! lupus You're right. I actually forgot about that one, hence my post. Best Regards, Tony ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
On 10/15/07 Giles Thomas wrote: Curt Hagenlocher wrote: My two cents would be this: using Managed C++, try for source compatibility first. As python extensions use a C API, I don't see how Managed C++ would provide source compatibility. Managed C++ would be an ill-advided method, IMHO. Binary compatibility would be a great thing in the long term - after all, we don't want to run the risk of branching the target library's codebase! - but my gut feeling is that you're right, Curt: it would be much easier, at least as an exploratory first stage, to target source compatibility only. So perhaps we should start off in that direction. I agree you should aim for source compatibility first, it's not like people commonly use binary proprietary python modules (and if they do it's the same people that wrote them and so can recompile). Binary compatibility is harder to prove correct, anyway and you'll have already your share of issues to overcome:) Does anyone know how this would impact the potential for Mono compatibility? A Managed C++ implementation would be pretty useless for a mono port, but I think it would be pretty useless for the .net runtime, as you need to expose a C API anyway. You'd have two components: the C API headers and some C code (this is required in any case) is the first. Then you need an assembly that translates from the C API to the IronPython model. You can write this in nice C# + a few dllimports or with the ugly managed C++ (assuming managed C++ can actually consume the python headers). 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
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
On 10/17/07, Paolo Molaro [EMAIL PROTECTED] wrote: As python extensions use a C API, I don't see how Managed C++ would provide source compatibility. Managed C++ would be an ill-advided method, IMHO. [...] You'd have two components: the C API headers and some C code (this is required in any case) is the first. Then you need an assembly that translates from the C API to the IronPython model. You can write this in nice C# + a few dllimports or with the ugly managed C++ (assuming managed C++ can actually consume the python headers). MC++ lets you create a single module that contains both normal machine code and MSIL, and takes care of the transitions between the two. There's no reason you can't compile the existing C code and link it directly with the MC++ wrapper -- which is exactly what I originally meant. A Managed C++ implementation would be pretty useless for a mono port, but I think it would be pretty useless for the .net runtime, as you need to expose a C API anyway. Of course, if Managed C++ isn't supported by Mono, that's probably a sufficiently good reason not to take this approach. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Curt Hagenlocher wrote: On 10/17/07, *Paolo Molaro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: As python extensions use a C API, I don't see how Managed C++ would provide source compatibility. Managed C++ would be an ill-advided method, IMHO. [...] You'd have two components: the C API headers and some C code (this is required in any case) is the first. Then you need an assembly that translates from the C API to the IronPython model. You can write this in nice C# + a few dllimports or with the ugly managed C++ (assuming managed C++ can actually consume the python headers). MC++ lets you create a single module that contains both normal machine code and MSIL, and takes care of the transitions between the two. There's no reason you can't compile the existing C code and link it directly with the MC++ wrapper -- which is exactly what I originally meant. Curt - how does MC++ relate to using P/Invoke? That is, is it P/Invoke plus some clever packaging stuff to allow you to produce a single assembly with both machine code and MSIL, or is there more to it than that? Or is it something completely different? 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] Announcement: Project to get some CPython C extensions running under IronPython
On 10/17/07, Giles Thomas [EMAIL PROTECTED] wrote: Curt - how does MC++ relate to using P/Invoke? That is, is it P/Invoke plus some clever packaging stuff to allow you to produce a single assembly with both machine code and MSIL, or is there more to it than that? Or is it something completely different? I'd guess they share some internals -- why write the same thunking code twice, after all. But their usage patterns are sufficiently different that I'd argue the internals don't really matter. P/Invoke requires you to declare everything explicitly, while the goal for MC++ is to make interop as transparent as possible. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Davy Mitchell wrote: Are Resolver Users looking to reuse their existing code in spreadsheets or just have the same facilities? If the latter then SWIG for Dotnet seems a better option than COM and is more Mono friendly. I think having the same facilities is vital, but having the same interface is very important. If I understand it correctly, the problem with SWIG is that it relies on there already existing a solid, well-designed C API which can be wrapped - which is the case for NumPy, but isn't for C extensions in general AFAIK. 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] Announcement: Project to get some CPython C extensions running under IronPython
On 10/17/07, Giles Thomas [EMAIL PROTECTED] wrote: I must admit I'd also misunderstood how a MC++ option would work, in the same way as Paolo Molaro, but this sounds really useful. Is there any particular resource you'd recommend for learning more about it? Perhaps you should read this link first: http://www.mono-project.com/CPlusPlus I've obviously given the impression that I have quite a bit more experience with MC++ than is actually the case. Although I spent some time studying the technology for possible use, my real-world experience with it is pretty limited. A good friend made extensive use of it at his previous job. They reported lots of problems under 1.0 and 1.1, but were quite happy with the robustness and syntactical improvements made for 2.0. He says that -- for integrating a legacy C or C++ codebase into the CLR environment -- he would use it again in a heartbeat. But I would expect that Mono-compatibility is especially critical for this project. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
On 10/17/07 Curt Hagenlocher wrote: On 10/17/07, Paolo Molaro [EMAIL PROTECTED] wrote: As python extensions use a C API, I don't see how Managed C++ would provide source compatibility. Managed C++ would be an ill-advided method, IMHO. [...] You'd have two components: the C API headers and some C code (this is required in any case) is the first. Then you need an assembly that translates from the C API to the IronPython model. You can write this in nice C# + a few dllimports or with the ugly managed C++ (assuming managed C++ can actually consume the python headers). MC++ lets you create a single module that contains both normal machine code and MSIL, and takes care of the transitions between the two. There's no reason you can't compile the existing C code and link it directly with the MC++ wrapper -- which is exactly what I originally meant. 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. The rest of the code is likely in the order of 50 K lines, so now ask yourself: would you rather write a) 50 K lines of nice C# code + 200 lines of trivial declarations or b) 50 K lines of orrible C++ code? I know what I would answer:) The managed C++ discussion is focused on avoiding the 200 lines of trivial declarations, when the issue is the 50 KLOC. Managed C++ might make sense if you have lots of legacy C++ code you need to integrate (at least until MS itself will pull the plug on it). For new code like this case, managed C++ is the wrong tool, IMHO. 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
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
On 10/17/07 Giles Thomas wrote: I must admit I'd also misunderstood how a MC++ option would work, in the same way as Paolo Molaro, but this sounds really useful. Is there any I don't think I misunderstood anything:) I said that there are two modules, the C one and the one that bridges the C code to the ironpython world. That the two modules can be combined into the same binary image doesn't change the fact that they are two different things, it's just an implementation detail. Thanks! 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
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Sounds like I misunderstood you too, then :-) Paolo Molaro wrote: On 10/17/07 Giles Thomas wrote: I must admit I'd also misunderstood how a MC++ option would work, in the same way as Paolo Molaro, but this sounds really useful. Is there any I don't think I misunderstood anything:) I said that there are two modules, the C one and the one that bridges the C code to the ironpython world. That the two modules can be combined into the same binary image doesn't change the fact that they are two different things, it's just an implementation detail. Thanks! lupus -- 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] Announcement: Project to get some CPython C extensions running under IronPython
On 10/17/07, Paolo Molaro [EMAIL PROTECTED] 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.
I'm having trouble understanding what you mean by this. Let's say I've got
an extension method that looks like this:
PyObject * ModifyColumns(PyObject * self, PyObject * args)
{
PyObject * columns;
if (!PyArg_ParseTuple(args, O, columns))
{
return NULL;
}
if (!PySequence_Check(columns))
{
PyErr_SetString(PyExc_ValueError, parameter must be a sequence);
return NULL;
}
PyObject * result = PyTuple_New(PySequence_Length(columns));
for (int i = 0; i PySequence_Length(columns); i++)
{
PyObject * value = PySequence_GetItem(sequence, i);
// Do something to value
// And make sure you don't screw up the reference count
PySequence_SetItem(result, i, value);
}
return result;
}
In order to use this extension from IronPython, I need C implementations of
each of those API functions. The PySequence_ methods should to be able to
understand CLR arrays or any other IEnumerable-like object. I'm not sure
what PyTuple_New should return, but whatever it is will need to have
PyObject*-like semantics.
How does DllImport fit into this picture? How can I avoid implementing all
these functions in C or C++?
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
On 10/17/07 Curt Hagenlocher wrote:
On 10/17/07, Paolo Molaro [EMAIL PROTECTED] 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.
I'm having trouble understanding what you mean by this. Let's say I've got
an extension method that looks like this:
PyObject * ModifyColumns(PyObject * self, PyObject * args)
{
[...]
In order to use this extension from IronPython, I need C implementations of
each of those API functions. The PySequence_ methods should to be able to
understand CLR arrays or any other IEnumerable-like object. I'm not sure
what PyTuple_New should return, but whatever it is will need to have
PyObject*-like semantics.
How does DllImport fit into this picture? How can I avoid implementing all
these functions in C or C++?
You do need to write C code as the API is a C API. I didn't list in the
last mail because the C implementation of these functions is not a
difference between the C# impl and the C++ impl of the rest of the code.
The dllimport declarations I mentioned above would pinvoke to these C
functions.
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
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Paolo Molaro wrote:
On 10/17/07 Curt Hagenlocher wrote:
On 10/17/07, Paolo Molaro [EMAIL PROTECTED] 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.
I'm having trouble understanding what you mean by this. Let's say I've got
an extension method that looks like this:
PyObject * ModifyColumns(PyObject * self, PyObject * args)
{
[...]
In order to use this extension from IronPython, I need C implementations of
each of those API functions. The PySequence_ methods should to be able to
understand CLR arrays or any other IEnumerable-like object. I'm not sure
what PyTuple_New should return, but whatever it is will need to have
PyObject*-like semantics.
How does DllImport fit into this picture? How can I avoid implementing all
these functions in C or C++?
You do need to write C code as the API is a C API. I didn't list in the
last mail because the C implementation of these functions is not a
difference between the C# impl and the C++ impl of the rest of the code.
The dllimport declarations I mentioned above would pinvoke to these C
functions.
Those C functions you speak about will need to execute managed code.
So, either way, what needs to be done is to allow Reverse P/Invoke or
some form of DllExport. Assuming this project is successful, native
C/C++ will have to, at some point, execute managed code.
There are only two ways that I know of that you can accomplish this in .NET:
1. C++ Interop
2. Modifying a compiled assembly
Option 1 has the disadvantage of not working in Mono (for now), but I
think is a cleaner solution.
Option 2 requires a post build event and I have no idea how that will
affect Mono, as I don't use Mono or ever tried this approach. This
article briefly discusses the method:
http://www.codeproject.com/useritems/DllExport.asp
The Cecil project might help with this, though I'm not sure:
http://www.mono-project.com/Cecil
PostSharp might be able to do this as well (again, I've never used it):
http://www.postsharp.org/
Regards,
Tony
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
What would the issues be with NumPy - just the size of the API that I was most concerned with data types (and converting) which for statistical based computing needs to be exact. It is a great plus for DotNet to have common types between languages. After working for years in mixed VB6/C++ COM applications I really appreciate that :-) Are Resolver Users looking to reuse their existing code in spreadsheets or just have the same facilities? If the latter then SWIG for Dotnet seems a better option than COM and is more Mono friendly. Cheers, Davy On 10/15/07, Giles Thomas [EMAIL PROTECTED] wrote: Davy, What would the issues be with NumPy - just the size of the API that would have to be wrapped? I must admin that my biggest concern with this would be getting everything running under Mono... Cheers, Giles Davy Mitchell wrote: On 10/12/07, Giles Thomas [EMAIL PROTECTED] wrote: Python and .NET, but also the existing CPython C extensions. Hi Giles, Sounds like a good idea and the approaches mentioned seemed solid. One strategy I was considering for a port of my Mood News site to Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM object using the win32 stuff and getting it into .Net via the COM interop support. Maybe not practical for Numpy :-) Does have the advantage of not having to modify the original lib... Cheers, Davy -- 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 -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
NumPy is largely about speed, and going through extra interop layers can really bite into that (my $0.02). I think the suggestion for a smaller module to start with was about learning about compatibility with a more manageable chunk of code than the many, many lines of deep number-crunching that NumPy has accumulated, but maybe a few sections of compatibility there (i.e. limited part of the API) would be a similarly tractable goal? Wrapping the plain-C in COM would be a good way to test implementation compatibility, if your plan is to ported raw C to C++, so that the DLR/CLR can get some hooks in and go-quicka: the COM-wrapped CPy extensions may be faster to develop, if not performing as quickly, and if your C++ ports behave the same, you have pretty good confidence. Along the way, they'll help point out what's the framework and what's your code, especially if you can run the same test-cases through straight CPy. Wrapping all the way back through Mono seems an odd goal - isn't IPy compatible enough with CPy in source that your business apps would be light to port back to Cpy-land, if you're on Posix already anyway? For some purposes, it really makes sense, but a NumPy implementation for IPy for Mono? Seem to me that going that deep this soon will make you a valuable contributor to low-level compatibility testing... but I don't have the whole picture of where you're going. If you're going to alloy FePy, would that make a type of SteelPython? - a happier compound than Rust! Cheers, -- Matt From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giles Thomas Sent: Monday, October 15, 2007 9:17 AM To: Discussion of IronPython Subject: Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython Davy, What would the issues be with NumPy - just the size of the API that would have to be wrapped? I must admin that my biggest concern with this would be getting everything running under Mono... Cheers, Giles Davy Mitchell wrote: On 10/12/07, Giles Thomas [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Python and .NET, but also the existing CPython C extensions. Hi Giles, Sounds like a good idea and the approaches mentioned seemed solid. One strategy I was considering for a port of my Mood News site to Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM object using the win32 stuff and getting it into .Net via the COM interop support. Maybe not practical for Numpy :-) Does have the advantage of not having to modify the original lib... Cheers, Davy -- 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] Announcement: Project to get some CPython C extensions running under IronPython
On 10/13/07, Dino Viehland [EMAIL PROTECTED] wrote: +1 on the MC++, this seems like an ideal use of it. Just a little nitpick, hopefully were talking about C++/CLI and not the antique Managed Extensions for C++ regards, Simon *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher *Sent:* Friday, October 12, 2007 11:38 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython On 10/12/07, *Giles Thomas* [EMAIL PROTECTED] wrote: What is the best architecture? We're thinking of this as being a bit of C# managed code to interface with the C extension, and a thin Python wrapper on top. The module's existing C extension and Python code would sandwich this layer. Let us know if this is a silly idea :-) My two cents would be this: using Managed C++, try for source compatibility first. It will almost certainly be less work than binary compatibility -- especially given your restricted test case -- and you're not likely to do much coding that wouldn't be needed for binary compatibility anyway. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
NumPy would be cool :) And it probably gives you a few different data structures to figure out marshalling, no? From: [EMAIL PROTECTED] on behalf of Giles Thomas Sent: Fri 10/12/2007 10:00 AM To: Discussion of IronPython Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython At Resolver Systems, we started building our core products with the view that most of our clients would want to use them to connect spreadsheet data and designs, Python code, and .NET objects. This was the right decision; lots of people do want to do just that, and we've been working with them so far. However, as we've spoken to more potential clients over the last months, we've learned something new - that there's a lot of interest out there in using a tool like Resolver One to plug together not just spreadsheets, Python and .NET, but also the existing CPython C extensions. Solving the general problem - plugging an arbitrary C extension into IronPython - is a huge project, and we're not even sure we could work out *how much work it is* without a lot of investigation. What we intend to do is to solve a specific problem, to integrate just one extension, and to use that project as a testbed to examine the possibilities for getting other extensions working - and perhaps, in the long term, solving the general problem. We think that any solution like this will be valuable not just to us, but to the IronPython community as a whole. And so, we want to make it Open Source. Right now, we'd particularly like to hear from people about the following: * Who wants to get involved? We're really keen on working with people on this. * Which module should we go for? NumPy looks like a good start, as it gives us a start on getting SciPy working. But perhaps there are better choices. * Should this be a new project, or should we be talking to other people about getting it into other projects? * Which license? If we're to work on it with a view to building it into Resolver One, then it will need to be commercial-software-friendly. Apart from that - we have no view. * What is the best architecture? We're thinking of this as being a bit of C# managed code to interface with the C extension, and a thin Python wrapper on top. The module's existing C extension and Python code would sandwich this layer. Let us know if this is a silly idea :-) * Is there anything else we should be thinking about to get this started? 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 winmail.dat___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
On 10/12/07, Giles Thomas [EMAIL PROTECTED] wrote: What is the best architecture? We're thinking of this as being a bit of C# managed code to interface with the C extension, and a thin Python wrapper on top. The module's existing C extension and Python code would sandwich this layer. Let us know if this is a silly idea :-) My two cents would be this: using Managed C++, try for source compatibility first. It will almost certainly be less work than binary compatibility -- especially given your restricted test case -- and you're not likely to do much coding that wouldn't be needed for binary compatibility anyway. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
+1 on the MC++, this seems like an ideal use of it. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Friday, October 12, 2007 11:38 AM To: Discussion of IronPython Subject: Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython On 10/12/07, Giles Thomas [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: What is the best architecture? We're thinking of this as being a bit of C# managed code to interface with the C extension, and a thin Python wrapper on top. The module's existing C extension and Python code would sandwich this layer. Let us know if this is a silly idea :-) My two cents would be this: using Managed C++, try for source compatibility first. It will almost certainly be less work than binary compatibility -- especially given your restricted test case -- and you're not likely to do much coding that wouldn't be needed for binary compatibility anyway. -- Curt Hagenlocher [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
