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 i

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

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

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

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

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

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 y

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 dllimpo

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 mentio

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

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 und

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 sa

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

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

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 A

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 th

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 in

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

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

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 co

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

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

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

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.

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 a

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

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 o

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

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

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

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

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

uld 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] Ann

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]> wrote:

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

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

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

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

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

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 wr

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

: > [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, *Gile

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

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

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

: 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

[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