Nope, the types we generate aren't your typical every day types. For example
in the code you created we don't generate any .NET types - instead the class is
represented by an instance of OldClass (IronPython.Runtime.Types.OldClass) and
when you create an instance of this we create an instance of a OldInstance
(IronPython.Runtime.Types.OldInstance). The OldInstance has a reference to its
class (and that can change if you change the __class__ property on the
instance) and the OldClass has a reference to all of its bases (in this case,
there aren't any).
The function does of course get created as a real .NET method - but that method
is either generated as a DynamicMethod (which the GC can collect and doesn't
live on a type) or it gets generated as a method in a module type (if this is
getting compiled as part of a module) with a name like Bar$f0.
If you create new style classes, eg:
class foo(object):
def Bar(self, args): print args
we will generate a real type, but that real type will be
"IronPython.NewTypes.System.Object_0" (or some other _number depending on how
many new types we've generated). That type also has a reference to a class
object (__class__) but this time it's a UserType
(IronPython.Runtime.Types.UserType). And that type will also be shared for all
types which inherit from object - so if you then do:
class baz(object):
def Foo(self, args): print args
then:
import clr
baz().GetType() == foo().GetType()
So to get anything like the Foo or Bar method you'll actually need to go to the
__class__ field, and ask the class for the method (and here the method is
stored in the classes dictionary).
So unfortunately reflection & IronPython classes don't mix.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc-André
Belzile
Sent: Thursday, August 31, 2006 9:00 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython interop problem
Could the .NET reflection mechanism be an alternative to hosting PythonEngine ?
E.g.
def class foo:
def Bar(self,args):
print args;
// C# host
Assembly asm = Assembly.Load(assemblyName); Type t = asm.GetType("foo", true,
true); MethodInfo m = t.GetMethod("Bar"); m.Invoke( null, args );
thanks
-mab
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Dino Viehland
Sent: August 29, 2006 4:10 PM
To: Dino Viehland; Discussion of IronPython
Subject: Re: [IronPython] IronPython interop problem
Sorry, pressed send too soon...
The good news is that very soon we'll have full documentation on the hosting
APIs which might make it a little more obvious about where to look for these
things :).
-----Original Message-----
From: Dino Viehland
Sent: Tuesday, August 29, 2006 1:09 PM
To: Discussion of IronPython
Subject: RE: [IronPython] IronPython interop problem
We hadn't really considered this and haven't had any requests to do this yet.
The problem here is of course that once a type is COM visible you're never
allowed to add anything to that type as it'll break the COM clients.
What I would imagine we might do in the future would be to define an interface
(e.g. IPythonEngine) and then expose that to COM rather than exposing the
PythonEngine class to COM clients. That would allow COM clients to interact w/
the engine and allow us to version the interface by adding an
IPythonEngine2/IPythonEngineEx interface.
One of the best ways we have for interacting w/ delegates is with the
CreateMethod and CreateLambda APIs. These allow you to pass in a body of code
and get a .NET delegate back out. That .NET delegate for your purposes could
be converted into an unmanaged function pointer and called directly from your
native code (no COM needed! :) ). You can combine these w/ ExecuteFile which
will allow you to use the delegates to call into a module which contains some
pre-baked script code if you don't want to pass all the code into this API.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc-André
Belzile
Sent: Monday, August 28, 2006 1:25 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython interop problem
Dino,
Do you have plans in the future to make IP assemblies COM visible? This would
allow us to support .NET assemblies in a uniform manner without having to do a
special case for IP.
As for the approach you are proposing, it's not obvious how I can use
PythonEngine for my scenario. Our plug-ins need to expose a set of functions
known by the main app. These functions are called by the app with SDK objects
arguments (i.e ActiveX), these objects are used by the callback to perform some
actions. I don't see any methods in PythonEngine that would allow me to do such
things.
Eg
PtyhonEngine engine = new PtyhonEngine
engine.ExecuteFile("MyModule.ps")
ArrayList args;
args.Add( obj1 );
args.Add( obj2 );
Boolean retVal;
engine.Execute( "Foo", args, retVal );
etc..
Foo would be defined as
def Foo( arg0, arg1 ):
arg0.SomeMethod()
arg1.SomeOtherMethod()
return true
Are these kind of things possible to do with the current implementation of IP ?
Thanks.
-mab
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Dino Viehland
Sent: August 25, 2006 3:47 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython interop problem
The problem you're running into is that we won't expose the Python type by the
names you compile it as - this is the weirdness you're seeing versus a C#
compiled assembly.
There's a couple of ways to deal with this. One is to host IronPython and use
the PythonEngine interfaces to expose objects, create instances, etc... This
is the preferred mechanism - for your scenario you may need to make a small
shim in C# that enables access to the IronPython engine because we don't mark
the type as being ComVisible (and we explicitly turn off COM visibility for all
types in the assembly unless they opt-in). I'm actually not certain if our
types that get created on the fly are COM visible, but even if they are
IDispatch currently won't know about the way we plug-in here.
We also have a HIGHLY EXPERIMENTAL static type compiler - unfortunately there
is plenty of valid Python code that can't be compiled by it yet so I'd suggest
you go with the 1st route.
This is a very interesting scenario though and we'll probably want to look at
what we can do in the future to make this better. If you want to let us know
more about what you're trying to accomplish in the end it might help us ensure
this meets your needs in the future.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc-André
Belzile
Sent: Friday, August 25, 2006 11:11 AM
To: users@lists.ironpython.com
Subject: [IronPython] IronPython interop problem
Hello,
I'm hosting the CLR (.NET 2.0) in an unmanaged C++ app in order to access
objects from .NET assemblies with IDispatch. This is working fine for C#
assemblies but failed for IP assemblies.
The call to _AppDomain.CreateInstance below returns this error: 80131522, which
I couldn't find in the doc.
My unmanaged code:
CComPtr<_AppDomain> spAppDomain;
HRESULT hr = pDomain->QueryInterface( &spAppDomain.p );
assert( !hr );
CComPtr<_ObjectHandle> spHandle;
CComBSTR assyname("IronPythonPlugin");
CComBSTR classname("MyClass");
hr = spAppDomain->CreateInstance( assyname,classname,&spHandle );
My test class in
class MyClass:
def Foo():
pass
I compiled the PI assbly with VS2005 using the IDE prototype. The IL code looks
rather odd though compared to a C# assbly.
___[MOD]
S:\Rayflex\Sdk\si3dobjectmodel\IronPythonPlugin\bin\Debug\IronPythonPlugin.dll
| M A N I F E S T
|___[CLS] Class
| | .class public auto ansi
| | extends [IronPython]IronPython.Runtime.CustomDict
| |___[STF] ExtraKeysCache : public static string[]
| |___[STF] MyClass : public static object
| |___[STF] __doc__ : public static object
| |___[STF] __name__ : public static object
| |___[STF] myModule__py : public static class
[IronPython]IronPython.Runtime.PythonModule
| |___[STM] .cctor : void()
| |___[MET] .ctor : void()
| |___[STM] Foo$f4 : object(class
[IronPython]IronPython.Runtime.FunctionEnvironment4)
| |___[MET] GetExtraKeys : object[]()
| |___[MET] Initialize : void()
| |___[STM] Main : int32()
| | MyClass$maker4 : class
[mscorlib]System.Collections.Generic.IDictionary`2<object,object>(class
[IronPython]IronPython.Runtime.FunctionEnvironment,class
[IronPython]IronPython.Runtime.ICallerContext)
| |___[MET] TryGetExtraValue : bool(object,object&)
| |___[MET] TrySetExtraValue : bool(object,object)
|
Is this a known limitation ? Or maybe there is another way of getting at IP
classes from unmanaged code ?
thanks for your help!
Marc-André BELZILE - sdk software engineer, softimage|xsi
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
