Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Giles Thomas]

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

[Curt Hagenlocher]

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

[Giles Thomas]

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]

On 10/19/07 Giles Thomas 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 can use a struct that contains all the needed delegates and pass
that on the p/invoke call.

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

[Curt Hagenlocher]

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

[Giles Thomas]

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

[Tony Djordjevski]

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

[Paolo Molaro]

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

[Tony Djordjevski]

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

[Paolo Molaro]

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

[Curt Hagenlocher]

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

[Giles Thomas]

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

[Paolo Molaro]

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

[Paolo Molaro]

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

[Curt Hagenlocher]

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

[Giles Thomas]

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

[Giles Thomas]

Curt Hagenlocher wrote:
> 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.

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?


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

[Curt Hagenlocher]

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

[Giles Thomas]

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.


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

[Curt Hagenlocher]

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

[Paolo Molaro]

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

[Davy Mitchell]

>  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

[Giles Thomas]

Hmmm, we didn't really want to get the feeling of oldness or rottenness 
- it was just side-effect of a terrible pun on C/sea.  If the pun not 
only is really bad but also falls flat, then it's definitely a bad name ;-)


OxyPython sounds much cooler; but Python's definitely not required as 
part of the name. 



Sidnei da Silva wrote:

On 10/15/07, Giles Thomas <[EMAIL PROTECTED]> wrote:
  

One further question for this list, before I create a repository and mailing list 
elsewhere for the project - what should the project be called?  The best one we've come 
up with in-house is "RustPython" (IronPython, *C* extensions, you get the 
picture) and I'd be really grateful if someone could come up with a less appalling pun...



Ah, naming. My preferred subject. ;)

Ok, you want it to imply a sense of 'old' or 'rough' or 'rotten' or
'crude', and yet have a cool name. Is 'Python' required to be part of
the name?

The first cool name that came to my mind was 'Monera'. It is a cool
name because it refers (mostly) to prokaryotic organisms (organisms
without a nucleus). It also resembles a bit 'Mono', which might be an
useful association (Monera -> Mono, ah, so this is some thing related
to .NET!).

Another idea would be 'OxyPython', since it's the combination of
Oxygen + Iron is that forms Rust. :)

  


--
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

[Sidnei da Silva]

On 10/15/07, Giles Thomas <[EMAIL PROTECTED]> wrote:
> One further question for this list, before I create a repository and mailing 
> list elsewhere for the project - what should the project be called?  The best 
> one we've come up with in-house is "RustPython" (IronPython, *C* extensions, 
> you get the picture) and I'd be really grateful if someone could come up with 
> a less appalling pun...

Ah, naming. My preferred subject. ;)

Ok, you want it to imply a sense of 'old' or 'rough' or 'rotten' or
'crude', and yet have a cool name. Is 'Python' required to be part of
the name?

The first cool name that came to my mind was 'Monera'. It is a cool
name because it refers (mostly) to prokaryotic organisms (organisms
without a nucleus). It also resembles a bit 'Mono', which might be an
useful association (Monera -> Mono, ah, so this is some thing related
to .NET!).

Another idea would be 'OxyPython', since it's the combination of
Oxygen + Iron is that forms Rust. :)

-- 
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
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

[Michael Foord]

Matt Clinton wrote:
>
> NumPy is largely about speed, and going through extra interop layers 
> can really bite into that (my $0.02).
>

The reason that Numpy is much faster is because most of the work happens 
inside the C code, so a minor performance hit on the way in and out 
isn't necessarily a problem.

> 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?
>
Possibly.
>
> Wrapping the plain-C in COM would be a good way to test implementation 
> compatibility,
>
I'm not sure that COM is the way to go (because it does seem to insert 
an extra layer into the equation) - but it is certainly on the table.

> if your plan is to ported raw C to C++,
>
That wasn't at all the *original* plan. :-)

> 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?
>

No - our application is currently a .NET only (not Mono) application, 
with a heavy dependency on .NET for the user interface layer. So back 
porting the whole app. to CPython is not on the cards (for business 
reasons as well - getting the finance sector to install new technology 
is difficult, so a .NET based application will more easily be accepted 
by companies than a CPython one).

> For some purposes, it really makes sense, but a NumPy implementation 
> for IPy for Mono?
>
We are not talking particularly about a new implementation, but finding 
a way of getting the current implementation to work.

> 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!
>
RustPython is one of the possible names (what happens when you introduce 
Iron to the Sea... Moray would be another one - a kind of Python that 
lives in the sea... better names solicited...) :-)

Michael
http://www.manning.com/foord

> 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] <mailto:[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
>   

___
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

[Matt Clinton]

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

[Giles Thomas]

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

Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Giles Thomas]

Curt Hagenlocher wrote:
 > My two cents would be this: using Managed C++, try for source 
compatibility first. 

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.

Does anyone know how this would impact the potential for Mono compatibility?

Keith J. Farmer wrote:
 > NumPy would be cool :)

That looks like a pretty popular choice generally - quite a few people have 
posted off-list saying the same.  I'll get in touch with the NumPy developers.

One further question for this list, before I create a repository and mailing 
list elsewhere for the project - what should the project be called?  The best 
one we've come up with in-house is "RustPython" (IronPython, *C* extensions, 
you get the picture) and I'd be really grateful if someone could come up with a 
less appalling pun...


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

[Hernan M Foffani]

Definetly it's a huge work.

> 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?

NumPy is already big. I'd start with a very small project like the
sample at http://docs.python.org/ext/simpleExample.html. Sort of a
proof of concept.
Have you evaluated that you may need to port a big portion of the Python
C API (Py* functions and macros.)?

> 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 :-)

As someone else already said, you ought to consider COM too.

Another aproach is to completly forget the *CPython* extension. Pick
the domain C code core and add a .NET wrapper. Swig can you help here:
http://www.swig.org/tutorial.html

In these two approaches a Python compatibility layer API will be needed.
Thus, the programmer can use the same API from IronPython that she
used to use from CPython.

> Is there anything else we should be thinking about to get this started?

Hummm... I'm tempted to add a silly joke here but I'm going to refrain
myself now. ;)

Regards,
-Hernán.
___
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]

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

-- 
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

[Simon Dahlbacka]

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

[Dino Viehland]

+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

Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Curt Hagenlocher]

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

[Keith J. Farmer]

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
<>___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Giles Thomas]

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

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com