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.
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
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
--
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
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()
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
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
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.
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
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
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
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
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
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
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
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:)
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
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
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
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 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
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
: 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
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
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
+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
26 matches
Mail list logo
