[IronPython] Silverlight 4 and RichTextBox
Hello all, I'm trying to use the new RichTextBox from Silverlight 4 with IronPython. I have IronPython 2.6.1 RC and Silverlight 4 RC installed (Windows). It fails with a SystemError: Specified method is not supported when instantiating the RichTextBox. The code is: from System.Windows import Application from System.Windows.Controls import Canvas, RichTextBox canvas = Canvas() text = RichTextBox() text.Text = 'Hello World from IronPython' canvas.Children.Add(text) Application.Current.RootVisual = canvas Any ideas? All the best, Michael Foord -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Silverlight 4 and RichTextBox
On 12/04/2010 13:33, Michael Foord wrote: Hello all, I'm trying to use the new RichTextBox from Silverlight 4 with IronPython. I have IronPython 2.6.1 RC and Silverlight 4 RC installed (Windows). It fails with a SystemError: Specified method is not supported when instantiating the RichTextBox. If I attempt to create the RichTextBox from xaml instead of code the error is: SystemError: AG_E_UNKNOWN_ERROR [Line: 5 Position: 25] The xaml is: Canvas x:Class=System.Windows.Controls.Canvas xmlns=http://schemas.microsoft.com/client/2007; xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml; RichTextBox x:Name=text / /Canvas All the best, Michael The code is: from System.Windows import Application from System.Windows.Controls import Canvas, RichTextBox canvas = Canvas() text = RichTextBox() text.Text = 'Hello World from IronPython' canvas.Children.Add(text) Application.Current.RootVisual = canvas Any ideas? All the best, Michael Foord -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.6.1 for .NET 4.0 RC targeting Silverlight
Jimmy, I'm having trouble finding the source code for the 2.6.1 .NET 4.0 release on Codeplex. Can you point me to it? Thanks. On Sat, Apr 10, 2010 at 2:22 PM, Jimmy Schementi jimmy.scheme...@microsoft.com wrote: To embed IronPython (CLR2 SL build) in a Silverlight 4 app, you have to add a reference to Microsoft.Scripting.ExtensionAttribute.dll to make sure types defined in both System.Core.dll and Microsoft.Scripting.Core.dll are used from the latter assembly. Again, Keep in mind the dynamic type in C# won't work in this case; you'll need to build IronPython against SL4 from source to to get that functionality. Let me know if this works for you. ~Jimmy On Apr 9, 2010, at 3:46 PM, David Matson dmat...@gmail.com wrote: Just for clarity's sake here are the 5 warnings and 1 error I receive. Warning 1 The predefined type 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client\System.Core.dll' Warning 2 The predefined type 'System.Runtime.InteropServices.DefaultParameterValueAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client\System.dll' Warning 3 The predefined type 'System.Runtime.CompilerServices.CallSiteBinder' is defined in multiple assemblies in the global alias; using definition from 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client\System.Core.dll' Warning 4 The predefined type 'System.Runtime.CompilerServices.CallSite' is defined in multiple assemblies in the global alias; using definition from 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client\System.Core.dll' Warning 5 The predefined type 'System.Runtime.CompilerServices.CallSite' is defined in multiple assemblies in the global alias; using definition from 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client\System.Core.dll' Error 6 The type 'System.Dynamic.ExpandoObject' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client\System.Core.dll' and '\IronPythonDlls\Microsoft.Scripting.Core.dll' On Fri, Apr 9, 2010 at 4:40 PM, David Matson dmat...@gmail.com wrote: Jimmy, I was using the DLLs from the .NET 2.0 release and that worked fine albeit there are several warnings regarding types existing in both the .NET and the IronPython assemblies. However, I tried to use an ExpandoObject and now I get the error: The type 'System.Dynamic.ExpandoObject' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client\System.Core.dll' and '\IronPythonDlls\Microsoft.Scripting.Core.dll' On Fri, Apr 9, 2010 at 4:33 PM, Jimmy Schementi jimmy.scheme...@microsoft.com wrote: The MSI I downloaded from the link in my previous posts installs to the following: C:\Program Files (x86)\IronPython 2.6 for .NET 4.0 RC\ There is no Silverlight folder as there is in the 2.6.1 download for .NET 2.0. If I try to add the dlls in the root of that folder I get the following message: You can't add a reference to IronPython.dll as it was not built against the Silverlight runtime. Silverlight projects will only work with Silverlight assemblies. Am I missing something? Thanks for your help. Since the current stable version of Silverlight is Silverlight 3, which is a subset of .NET 3.5, we only include Silverlight binaries in the version of IronPython for .NET 2.0: http://ironpython.codeplex.com/releases/view/40144. When Silverlight 4 is considered the stable version, which is a subset of .NET 4, IronPython for .NET 4.0 will contain binaries build against Silverlight 4. Note that those Silverlight binaries will run on Silverlight 4, they just aren't built against Silverlight 4, so any .NET 4.0 specific features (like dynamic interop) are not available, but normal app development works. ~Jimmy ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- David Matson dmat...@gmail.com -- David Matson dmat...@gmail.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
Re: [IronPython] IronPython.Runtime.Types.PythonType Is not marked as Serializable Exception
Sorry for the delay - I was taking a couple of days off last week and I didn't
get a chance to respond before disappearing.
The problem here is that you're trying to return the objects from the remote
domain into the local domain. ObjectOperations actually has a set of overloads
which take ObjectHandles and has some other methods which return ObjectHandles
for working with objects in a remote app domain. If I change your modified
code to the code below and add a using System.Runtime.Remoting this works
again:
var subClass = scope.GetVariableHandle(C);
// get back a handle
var instance = ops.Invoke(subClass, new ObjectHandle[0]);
// invoke the handle to create an instance
mbr = instance.Unwrap() as MbrBase;
// now we know we have an MBR and we can unwrap it to our
local side
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of mohammad mustaq
Sent: Saturday, April 10, 2010 6:51 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython.Runtime.Types.PythonType Is not marked as
Serializable Exception
Hi Dino,
Is there any update on this. Should you need more details let me know.
thanks,
Mustaq
On Wed, Apr 7, 2010 at 10:40 AM, mohammad mustaq
mustaq2...@gmail.commailto:mustaq2...@gmail.com wrote:
Hi Dino,
If have tweaked your code to reproduce the exception that I am facing. Let me
know if you need more details.
thanks,
Mustaq
using System;
using Microsoft.Scripting;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
class Foo
{
public static void Main(string[] args)
{
AppDomain ad = AppDomain.CreateDomain(foo);
var engine = Python.CreateEngine(ad);
engine.Runtime.LoadAssembly(
typeof(MbrBase).Assembly);
var code = engine.CreateScriptSourceFromString(@
import MbrBase
class C(MbrBase):
pass
a = C()
, SourceCodeKind.Statements);
var scope = engine.CreateScope();
code.Execute(scope);
Console.WriteLine(Trying to do it... {0},
AppDomain.CurrentDomain.Idhttp://appdomain.currentdomain.id/);
MbrBase mbr = (MbrBase)scope.GetVariable(a);
// MY CHANGES
string isSubClassCode = String.Format(issubclass({0},{1}), C,
MbrBase);
ScriptSource script =
engine.CreateScriptSourceFromString(isSubClassCode, SourceCodeKind.Expression);
bool result = (bool)script.Execute(scope);
if (result == true)
{
ObjectOperations ops = engine.Operations;
object subClass = scope.GetVariable(C);
object instance = ops.Call(subClass);
mbr = instance as MbrBase;
}
// END OF MY CHANGE
mbr.DoItVirtually();
mbr.DoIt();
Console.ReadKey();
}
}
public class MbrBase : MarshalByRefObject
{
public virtual void DoItVirtually()
{
Console.WriteLine(Did it virtually {0},
AppDomain.CurrentDomain.Idhttp://appdomain.currentdomain.id/);
}
public void DoIt()
{
Console.WriteLine(Did it {0},
AppDomain.CurrentDomain.Idhttp://appdomain.currentdomain.id/);
}
}
On Tue, Mar 30, 2010 at 10:12 PM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
This works for me w/ 2.6. I've included my simple repro below which creates a
new script engine in a remote app domain, loads my assembly in, runs some code
which subclasses the MBRO base class, instantiates an instance of this class,
and then calls it from a remote app domain. The key thing here is that when an
MBRO is involved a PythonType should not need to be serialized - the type
should live in the remote app domain and all execution of that code should also
happen in the remote app domain where we have access to the local PythonType
object. Are you also subclassing types which don't derive from MBRO? It might
help to run IronPython w/ -X:ExceptionDetail if the exception is propagating
through IronPython - that'll give a better stack trace to understand what's
going on. Or if you can tweak the simple repro below to match the behavior
you're seeing that'd be helpful as well.
using System;
using Microsoft.Scripting;
using IronPython.Hosting;
class Foo {
public static void Main(string[] args) {
AppDomain ad = AppDomain.CreateDomain(foo);
var engine = Python.CreateEngine(ad);
engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly);
var code = engine.CreateScriptSourceFromString(@
import MbrBase
class C(MbrBase):
pass
a = C()
, SourceCodeKind.Statements);
var scope = engine.CreateScope();
code.Execute(scope);
Console.WriteLine(Trying to do it... {0},
AppDomain.CurrentDomain.Idhttp://AppDomain.CurrentDomain.Id);
MbrBase mbr = (MbrBase)scope.GetVariable(a);
mbr.DoItVirtually();
mbr.DoIt();
}
}
public class MbrBase
[IronPython] Building via AST
Suppose I would like to build an AST programmatically and compile that into an assembly dynamically (meaning an assembly flagged with RunAndCollect) from C#. How would I do that with IronPython's help? I do not what to author Python code and compile that I would like to just deal directly with the AST. Currently I have working code where I'm using System.Linq.Expression namespace to build statements and expressions into delegates but what I would like is to leverage the DLR to build dynamic types as well (without having to use ILGenerator preferably). Is this possible today? -- Justin Chase http://www.justnbusiness.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Building via AST
Nope – the DLR doesn’t have any support for building .NET types – dynamic or
otherwise. If you’d like to just build an object which behaves dynamically I’d
suggest looking at DynamicObject. You can just subclass it and override
various Try* methods and you’ll have a dynamic object.
If you really do need to do ILGen into a type, and as long as you’re building
only static methods, you can use expression trees via LambdaT.CompileToMethod
(unfortunately currently instance methods are not supported). Here’s an
example of that:
using System;
using System.Linq.Expressions;
using System.Reflection;
class Foo {
public static void Main(string[] args) {
var asm = AppDomain.CurrentDomain.DefineDynamicAssembly(new
AssemblyName(foo), System.Reflection.Emit.AssemblyBuilderAccess.Save);
var module = asm.DefineDynamicModule(foo.dll);
var type = module.DefineType(TestType);
var param1 = Expression.Parameter(typeof(Foox), arg1);
var param2 = Expression.Parameter(typeof(Foox), arg2);
var method = type.DefineMethod(TestMethod, MethodAttributes.Public |
MethodAttributes.Static);
Expression.LambdaFuncFoox, Foox, bool(
Expression.Equal(param1, param2),
new[] { param1, param2 }
).CompileToMethod(method);
type.CreateType();
asm.Save(foo.dll);
}
}
enum Foox {
Bar,
Baz
}
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Justin Chase
Sent: Monday, April 12, 2010 1:21 PM
To: users@lists.ironpython.com
Subject: [IronPython] Building via AST
Suppose I would like to build an AST programmatically and compile that into an
assembly dynamically (meaning an assembly flagged with RunAndCollect) from C#.
How would I do that with IronPython's help? I do not what to author Python code
and compile that I would like to just deal directly with the AST.
Currently I have working code where I'm using System.Linq.Expression namespace
to build statements and expressions into delegates but what I would like is to
leverage the DLR to build dynamic types as well (without having to use
ILGenerator preferably). Is this possible today?
--
Justin Chase
http://www.justnbusiness.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Building via AST
Ok so I'm wondering if I'm perhaps using the wrong words to try to say what
I mean. Because when I look into the IronPython source code I see a class
called Microsoft.Scripting.Generation.TypeGen (
http://ironpython.codeplex.com/SourceControl/changeset/view/65328#1011039).
Which appears to be code for generating a .net type contrary to your
response. Am I misinterpreting that?
Thanks for your examples below but that is about as far as I have gotten
already, what I need is a way to actually generate types and instances
members. And I was just looking at the ILGen class and all it's interesting
helpers but what I'd really love to find is a way to generate this by just
giving it an AST (including this references) instead of having to mess
around with IL (hasn't this been solved already??).
I know that Python has a class construct and that if I compile scripts I
can create instances of these objects, does this translate into actual .net
types under the hood? Or something else? Can you add attributes or
annotations to these classes for example? For my grand finale what I would
really like to do is to generate types that implement interfaces and load
them via MEF (by means of the Export attribute). Is this just the wrong way
to be thinking about this entirely? Or am I just missing something?
On Mon, Apr 12, 2010 at 3:33 PM, Dino Viehland di...@microsoft.com wrote:
Nope – the DLR doesn’t have any support for building .NET types – dynamic
or otherwise. If you’d like to just build an object which behaves
dynamically I’d suggest looking at DynamicObject. You can just subclass it
and override various Try* methods and you’ll have a dynamic object.
If you really do need to do ILGen into a type, and as long as you’re
building only static methods, you can use expression trees via
LambdaT.CompileToMethod (unfortunately currently instance methods are not
supported). Here’s an example of that:
using System;
using System.Linq.Expressions;
using System.Reflection;
class Foo {
public static void Main(string[] args) {
var asm = AppDomain.CurrentDomain.DefineDynamicAssembly(new
AssemblyName(foo), System.Reflection.Emit.AssemblyBuilderAccess.Save);
var module = asm.DefineDynamicModule(foo.dll);
var type = module.DefineType(TestType);
var param1 = Expression.Parameter(typeof(Foox), arg1);
var param2 = Expression.Parameter(typeof(Foox), arg2);
var method = type.DefineMethod(TestMethod,
MethodAttributes.Public | MethodAttributes.Static);
Expression.LambdaFuncFoox, Foox, bool(
Expression.Equal(param1, param2),
new[] { param1, param2 }
).CompileToMethod(method);
type.CreateType();
asm.Save(foo.dll);
}
}
enum Foox {
Bar,
Baz
}
*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Justin Chase
*Sent:* Monday, April 12, 2010 1:21 PM
*To:* users@lists.ironpython.com
*Subject:* [IronPython] Building via AST
Suppose I would like to build an AST programmatically and compile that into
an assembly dynamically (meaning an assembly flagged with RunAndCollect)
from C#. How would I do that with IronPython's help? I do not what to author
Python code and compile that I would like to just deal directly with the
AST.
Currently I have working code where I'm using System.Linq.Expression
namespace to build statements and expressions into delegates but what I
would like is to leverage the DLR to build dynamic types as well (without
having to use ILGenerator preferably). Is this possible today?
--
Justin Chase
http://www.justnbusiness.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
Justin Chase
http://www.justnbusiness.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Announcing IronPython 2.6.1
Hello Python Community, We're pleased to announce the final release of IronPython 2.6.1. This version of IronPython makes great strides in stability and compatibility, including a considerable number of targeted bugfixes. This is our largest servicing release to date, and with your help both before and during the RC phase, along with the simultaneous release of .NET 4.0, this has become a very exciting release for all of us. IronPython 2.6.1 comes in two flavors - one that runs on top of .NET 4.0, and one that runs on any earlier framework starting with .NET 2.0 SP1. They can both be downloaded at http://ironpython.codeplex.com/releases/view/36280. We'd like to place a particular emphasis on the .NET 4.0 flavor of IronPython 2.6.1 and encourage all of you to try it out. It has a number of advantages over the 2.0 version, some of which Dave discusses on his blog at http://knowbody.livejournal.com/20751.html. These include faster startup time, compatibility with C#'s new dynamic keyword, and access to the numerous new features present in the updated Framework. The final release of Microsoft .NET Framework 4.0 is publically available as of today, and is required for this flavor of IronPython 2.6.1. Download it here: http://www.microsoft.com/downloads/details.aspx?FamilyID=9cfb2d51-5ff4-4491-b0e5-b386f32c0992displaylang=en The IronPython 2.6.1 RC included fixes for well over 50 bugs, large and small. Ctypes has had a number of significant updates, including union support, variant_bool, and wintypes. Another focus has been on sys.settrace, making debugging more reliable. For example, sys.settrace now returns the correct frame, supports tracing through modules, and no longer interferes with import os. Other notable fixes include thread-safe importing, and the missing error code in _winreg exception. In addition, we've made a substantial improvement in import time. Not only does this reduce startup time, but it can speed up the importing of large, definition-heavy modules by up to 50%. As you might imagine, the .NET 4.0 flavor of IronPython 2.6.1 RC has a few of its own changes designed for better interoperability with the framework. These include fixing some errors with Func and better runtime isolation when similarly-named assemblies in different locations are loaded in multiple engines. In addition, both the .NET 2.0 and .NET 4.0 builds support the new .NET 4.0 IStructuralEquatable and IStructuralComparable interfaces and maps them to the appropriate operations (__eq__, __hash__, __gt__, etc.). In the case of .NET 4.0, this replaces IValueEquality as the gold standard for defining equality in an interop-friendly manner. In the .NET 2.0 build, these interfaces are copied so that their use can be phased in while retaining IValueEquality for backwards compatibility. Since the RC, we have fixed numerous other issues, as well as adding CPython's ssl.py to our distribution. We've also made some major unicode-related changes in response to your feedback on the mailing list, changes that improve compatibility with certain third-party applications including Django. In particular, invoking unicode() or using unicode string formatting will now call __unicode__() first if it is present on the object. Finally, we've included a new code sample that shows how to use __clrtype__ to create custom CLR classes from IronPython. This sample is a sneak preview of what we expect will become a fully supported IronPython module, so we encourage anyone who is so inclined to try it out and let us know how it goes. Special thanks to Albert Szilvasy, amajorek, cendalc, clovery, egonw_, Eloff, essey, fabiofz, gjones, gpgemini, Haibo Luo, igalse, jazzcat, jdhardy, jlunder, JustinCle, klrohe, László de Almásy, laughingboy, lbaker, Lukas Cenovsky, marten_range, olav, paulfelix, pl6306, razam, roinet, russomf, sanxiyn, see_toronto at web dot de, Thomas Heller, variant77, vernondcole, William Reade, and Wolfram for reporting issues and making this a great release. Happy scripting! - The IronPython Team ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Building via AST
Yes – there is the TypeGen class but really it’s just a thin wrapper around
TypeBuilder w/ some helper APIs. If we were to implement it today it might
just be extension methods instead of a wrapper class.
Unfortunately there is currently no way to go from an expression tree to an
instance method. It’s on the top of the things to fix in the DLR for a future
.NET release. It’s sad that it hasn’t been solved yet but that is the state of
the world. If you really wanted to get crazy you could look at forking the DLR
expression tree compiler and adding support ☺
As far as how Python does this – we do generate classes and we do this via our
NewTypeMaker class. But the IL that we create is rather minimal. We just
derive and override every virtual method and have it dispatch either to the
method defined in a PythonType type (which is stored as an instance field in
the object). So while it sucks that we need to generate the IL by hand it’s
small enough that it’s not a big deal.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Justin Chase
Sent: Monday, April 12, 2010 2:03 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Building via AST
Ok so I'm wondering if I'm perhaps using the wrong words to try to say what I
mean. Because when I look into the IronPython source code I see a class called
Microsoft.Scripting.Generation.TypeGen
(http://ironpython.codeplex.com/SourceControl/changeset/view/65328#1011039).
Which appears to be code for generating a .net type contrary to your response.
Am I misinterpreting that?
Thanks for your examples below but that is about as far as I have gotten
already, what I need is a way to actually generate types and instances members.
And I was just looking at the ILGen class and all it's interesting helpers but
what I'd really love to find is a way to generate this by just giving it an AST
(including this references) instead of having to mess around with IL (hasn't
this been solved already??).
I know that Python has a class construct and that if I compile scripts I can
create instances of these objects, does this translate into actual .net types
under the hood? Or something else? Can you add attributes or annotations to
these classes for example? For my grand finale what I would really like to do
is to generate types that implement interfaces and load them via MEF (by means
of the Export attribute). Is this just the wrong way to be thinking about this
entirely? Or am I just missing something?
On Mon, Apr 12, 2010 at 3:33 PM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
Nope – the DLR doesn’t have any support for building .NET types – dynamic or
otherwise. If you’d like to just build an object which behaves dynamically I’d
suggest looking at DynamicObject. You can just subclass it and override
various Try* methods and you’ll have a dynamic object.
If you really do need to do ILGen into a type, and as long as you’re building
only static methods, you can use expression trees via LambdaT.CompileToMethod
(unfortunately currently instance methods are not supported). Here’s an
example of that:
using System;
using System.Linq.Expressions;
using System.Reflection;
class Foo {
public static void Main(string[] args) {
var asm = AppDomain.CurrentDomain.DefineDynamicAssembly(new
AssemblyName(foo), System.Reflection.Emit.AssemblyBuilderAccess.Save);
var module = asm.DefineDynamicModule(foo.dll);
var type = module.DefineType(TestType);
var param1 = Expression.Parameter(typeof(Foox), arg1);
var param2 = Expression.Parameter(typeof(Foox), arg2);
var method = type.DefineMethod(TestMethod, MethodAttributes.Public |
MethodAttributes.Static);
Expression.LambdaFuncFoox, Foox, bool(
Expression.Equal(param1, param2),
new[] { param1, param2 }
).CompileToMethod(method);
type.CreateType();
asm.Save(foo.dll);
}
}
enum Foox {
Bar,
Baz
}
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com]
On Behalf Of Justin Chase
Sent: Monday, April 12, 2010 1:21 PM
To: users@lists.ironpython.commailto:users@lists.ironpython.com
Subject: [IronPython] Building via AST
Suppose I would like to build an AST programmatically and compile that into an
assembly dynamically (meaning an assembly flagged with RunAndCollect) from C#.
How would I do that with IronPython's help? I do not what to author Python code
and compile that I would like to just deal directly with the AST.
Currently I have working code where I'm using System.Linq.Expression namespace
to build statements and expressions into delegates but what I would like is to
leverage the DLR to build dynamic types as well (without having to use
ILGenerator preferably). Is this possible today?
--
Justin Chase
[IronPython] Update to the World's Worst Paint Program Sample
A newer version of Dino's World's Worst Paint Program sample has just been uploaded to the 2.6.1 download page as (Sample) BadPaint.ziphttp://ironpython.codeplex.com/releases/view/36280#DownloadId=116523. This sample shows how to utilize the DLR/IronPython hosting APIs to manipulate the behavior of C#/VB/etc .NET 4.0 applications. In short, you can move around objects on the paint canvas, change their colors, etc using a poor man's Python interactive session built directly into the paint program. If you've ever wanted to see how the hosting APIs work, this is a great place to start! From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of David DiCato Sent: Monday, April 12, 2010 2:54 PM To: Discussion of IronPython Subject: [IronPython] Announcing IronPython 2.6.1 Hello Python Community, We're pleased to announce the final release of IronPython 2.6.1. This version of IronPython makes great strides in stability and compatibility, including a considerable number of targeted bugfixes. This is our largest servicing release to date, and with your help both before and during the RC phase, along with the simultaneous release of .NET 4.0, this has become a very exciting release for all of us. IronPython 2.6.1 comes in two flavors - one that runs on top of .NET 4.0, and one that runs on any earlier framework starting with .NET 2.0 SP1. They can both be downloaded at http://ironpython.codeplex.com/releases/view/36280. We'd like to place a particular emphasis on the .NET 4.0 flavor of IronPython 2.6.1 and encourage all of you to try it out. It has a number of advantages over the 2.0 version, some of which Dave discusses on his blog at http://knowbody.livejournal.com/20751.html. These include faster startup time, compatibility with C#'s new dynamic keyword, and access to the numerous new features present in the updated Framework. The final release of Microsoft .NET Framework 4.0 is publically available as of today, and is required for this flavor of IronPython 2.6.1. Download it here: http://www.microsoft.com/downloads/details.aspx?FamilyID=9cfb2d51-5ff4-4491-b0e5-b386f32c0992displaylang=en The IronPython 2.6.1 RC included fixes for well over 50 bugs, large and small. Ctypes has had a number of significant updates, including union support, variant_bool, and wintypes. Another focus has been on sys.settrace, making debugging more reliable. For example, sys.settrace now returns the correct frame, supports tracing through modules, and no longer interferes with import os. Other notable fixes include thread-safe importing, and the missing error code in _winreg exception. In addition, we've made a substantial improvement in import time. Not only does this reduce startup time, but it can speed up the importing of large, definition-heavy modules by up to 50%. As you might imagine, the .NET 4.0 flavor of IronPython 2.6.1 RC has a few of its own changes designed for better interoperability with the framework. These include fixing some errors with Func and better runtime isolation when similarly-named assemblies in different locations are loaded in multiple engines. In addition, both the .NET 2.0 and .NET 4.0 builds support the new .NET 4.0 IStructuralEquatable and IStructuralComparable interfaces and maps them to the appropriate operations (__eq__, __hash__, __gt__, etc.). In the case of .NET 4.0, this replaces IValueEquality as the gold standard for defining equality in an interop-friendly manner. In the .NET 2.0 build, these interfaces are copied so that their use can be phased in while retaining IValueEquality for backwards compatibility. Since the RC, we have fixed numerous other issues, as well as adding CPython's ssl.py to our distribution. We've also made some major unicode-related changes in response to your feedback on the mailing list, changes that improve compatibility with certain third-party applications including Django. In particular, invoking unicode() or using unicode string formatting will now call __unicode__() first if it is present on the object. Finally, we've included a new code sample that shows how to use __clrtype__ to create custom CLR classes from IronPython. This sample is a sneak preview of what we expect will become a fully supported IronPython module, so we encourage anyone who is so inclined to try it out and let us know how it goes. Special thanks to Albert Szilvasy, amajorek, cendalc, clovery, egonw_, Eloff, essey, fabiofz, gjones, gpgemini, Haibo Luo, igalse, jazzcat, jdhardy, jlunder, JustinCle, klrohe, László de Almásy, laughingboy, lbaker, Lukas Cenovsky, marten_range, olav, paulfelix, pl6306, razam, roinet, russomf, sanxiyn, see_toronto at web dot de, Thomas Heller, variant77, vernondcole, William Reade, and Wolfram for reporting issues and making this a great release. Happy scripting! - The IronPython Team ___ Users mailing list
Re: [IronPython] Building via AST
Ok, so at risk of being a nuissance I have one last question because I feel
like I'm half way there. I have the following example that seems to work:
# sample.py
from ConsoleApplication4 import IExample
class Example(IExample):
test = hello python
def Do(self):
return self.test
# program.cs
namespace ConsoleApplication4
{
class Program
{
static void Main(string[] args)
{
var runtime = Python.CreateRuntime();
runtime.LoadAssembly(typeof(IExample).Assembly);
dynamic python = runtime.UseFile(sample.py);
IExample example = (IExample)python.Example();
Console.WriteLine(example.Do());
Console.ReadKey(true);
}
}
public interface IExample
{
string Do();
}
}
Which prints out hello python as expected and is the *exact *behavior I
would like to have. So now, say I did this instead:
# program.cs
namespace ConsoleApplication4
{
class Program
{
static void Main(string[] args)
{
var runtime = Python.CreateRuntime();
runtime.LoadAssembly(typeof(IExample).Assembly);
var import = new IronPython.Compiler.Ast.ImportStatement(
new[] { new ModuleName(new[] { ConsoleApplication4 }) },
new[] { IExample },
false);
var classDefinition = new IronPython.Compiler.Ast.ClassDefinition(Example,
new Expression[] { new NameExpression(IExample) },
new FunctionDefinition(
Do,
new[] { new Parameter(self) },
new ReturnStatement(new ConstantExpression(hello python!;
*// TODO: Compile the above AST into something!*
* **dynamic python = null;*
IExample example = (IExample)python.Example();
Console.WriteLine(example.Do());
Console.ReadKey(true);
}
}
public interface IExample
{
string Do();
}
}
Is there anyway to fill in the line below the TODO such that I will get the
exact same behavior as the first example? If you say no this time then I'll
finally stop asking you questions (except maybe why not :-P). If you do say
no this time, then I might be interested in trying to extend things such
that it is possible.
On Mon, Apr 12, 2010 at 5:20 PM, Dino Viehland di...@microsoft.com wrote:
Yes – there is the TypeGen class but really it’s just a thin wrapper
around TypeBuilder w/ some helper APIs. If we were to implement it today it
might just be extension methods instead of a wrapper class.
Unfortunately there is currently no way to go from an expression tree to an
instance method. It’s on the top of the things to fix in the DLR for a
future .NET release. It’s sad that it hasn’t been solved yet but that is
the state of the world. If you really wanted to get crazy you could look at
forking the DLR expression tree compiler and adding support J
As far as how Python does this – we do generate classes and we do this via
our NewTypeMaker class. But the IL that we create is rather minimal. We
just derive and override every virtual method and have it dispatch either to
the method defined in a PythonType type (which is stored as an instance
field in the object). So while it sucks that we need to generate the IL by
hand it’s small enough that it’s not a big deal.
*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Justin Chase
*Sent:* Monday, April 12, 2010 2:03 PM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] Building via AST
Ok so I'm wondering if I'm perhaps using the wrong words to try to say what
I mean. Because when I look into the IronPython source code I see a class
called Microsoft.Scripting.Generation.TypeGen (
http://ironpython.codeplex.com/SourceControl/changeset/view/65328#1011039).
Which appears to be code for generating a .net type contrary to your
response. Am I misinterpreting that?
Thanks for your examples below but that is about as far as I have gotten
already, what I need is a way to actually generate types and instances
members. And I was just looking at the ILGen class and all it's interesting
helpers but what I'd really love to find is a way to generate this by just
giving it an AST (including this references) instead of having to mess
around with IL (hasn't this been solved already??).
I know that Python has a class construct and that if I compile scripts I
can create instances of these objects, does this translate into actual .net
types under the hood? Or something else? Can you add attributes or
annotations to these classes for example? For my grand finale what I would
really like to do is to generate types that implement interfaces and load
them via MEF (by means of the Export attribute). Is this just the wrong way
to be thinking about this entirely? Or am I just missing something?
On Mon, Apr 12, 2010 at 3:33 PM, Dino Viehland di...@microsoft.com
wrote:
Nope – the DLR doesn’t have any support for building .NET types – dynamic
or otherwise. If you’d like to just build an object which behaves
dynamically I’d suggest looking at DynamicObject. You can just subclass it
and override various Try* methods and you’ll have a dynamic object.
If you really do need to do ILGen into a
Re: [IronPython] Building via AST
This might be possible. If you wrap this all up in a PythonAst object (calling
the constructor which takes a CompilerContext), call Bind on it then you should
get a LambdaExpression back out. You can Compile() on that.
But it’s not like this is well traveled territory and this only applies to
2.6.1 (before that the trees weren’t DLR ASTs so they weren’t reducable). When
we do this ourselves we also call the produced delegate and flow in some data.
The delegate is going to want at least a FunctionCode object as an argument but
I think you could get away with passing null (at least as long as no exceptions
are thrown). The delegate might also want a CodeContext object as well
depending on the compilation mode we end up using (which is based on the
CompilerContext you give us). This you wouldn’t be able to get away w/ passing
null. But you can get one by doing new ModuleContext(new PythonDictionary(),
pythonContext).GlobalContext. The HostingHelpers class can give you a
LanguageContext from the ScriptEngine for Python which you can cast to a
PythonContext.
Let me know if it works! ☺
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Justin Chase
Sent: Monday, April 12, 2010 4:09 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Building via AST
Ok, so at risk of being a nuissance I have one last question because I feel
like I'm half way there. I have the following example that seems to work:
# sample.py
from ConsoleApplication4 import IExample
class Example(IExample):
test = hello python
def Do(self):
return self.test
# program.cs
namespace ConsoleApplication4
{
class Program
{
static void Main(string[] args)
{
var runtime = Python.CreateRuntime();
runtime.LoadAssembly(typeof(IExample).Assembly);
dynamic python = runtime.UseFile(sample.py);
IExample example = (IExample)python.Example();
Console.WriteLine(example.Do());
Console.ReadKey(true);
}
}
public interface IExample
{
string Do();
}
}
Which prints out hello python as expected and is the exact behavior I would
like to have. So now, say I did this instead:
# program.cs
namespace ConsoleApplication4
{
class Program
{
static void Main(string[] args)
{
var runtime = Python.CreateRuntime();
runtime.LoadAssembly(typeof(IExample).Assembly);
var import = new
IronPython.Compiler.Ast.ImportStatement(
new[] { new ModuleName(new[] {
ConsoleApplication4 }) },
new[] { IExample },
false);
var classDefinition = new
IronPython.Compiler.Ast.ClassDefinition(Example,
new Expression[] { new
NameExpression(IExample) },
new FunctionDefinition(
Do,
new[] { new
Parameter(self) },
new
ReturnStatement(new ConstantExpression(hello python!;
// TODO: Compile the above AST into something!
dynamic python = null;
IExample example = (IExample)python.Example();
Console.WriteLine(example.Do());
Console.ReadKey(true);
}
}
public interface IExample
{
string Do();
}
}
Is there anyway to fill in the line below the TODO such that I will get the
exact same behavior as the first example? If you say no this time then I'll
finally stop asking you questions (except maybe why not :-P). If you do say no
this time, then I might be interested in trying to extend things such that it
is possible.
On Mon, Apr 12, 2010 at 5:20 PM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
Yes – there is the TypeGen class but really it’s just a thin wrapper around
TypeBuilder w/ some helper APIs. If we were to implement it today it might
just be extension methods instead of a wrapper class.
Unfortunately there is currently no way to go from an expression tree to an
instance method. It’s on the top of the things to fix in the DLR for a future
.NET
Re: [IronPython] Building via AST
Awesome. I will thanks. On Apr 12, 2010 7:49 PM, Dino Viehland di...@microsoft.com wrote: This might be possible. If you wrap this all up in a PythonAst object (calling the constructor which takes a CompilerContext), call Bind on it then you should get a LambdaExpression back out. You can Compile() on that. But it’s not like this is well traveled territory and this only applies to 2.6.1 (before that the trees weren’t DLR ASTs so they weren’t reducable). When we do this ourselves we also call the produced delegate and flow in some data. The delegate is going to want at least a FunctionCode object as an argument but I think you could get away with passing null (at least as long as no exceptions are thrown). The delegate might also want a CodeContext object as well depending on the compilation mode we end up using (which is based on the CompilerContext you give us). This you wouldn’t be able to get away w/ passing null. But you can get one by doing new ModuleContext(new PythonDictionary(), pythonContext).GlobalContext. The HostingHelpers class can give you a LanguageContext from the ScriptEngine for Python which you can cast to a PythonContext. Let me know if it works! J *From:* users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] *On Behalf Of *Justin Chase *Sent:* Monday, April 12, 2010 4:09 PM To: Discussion of IronPython Subject: Re: [IronPython] Building via AST Ok, so at risk of being a nuissance I have one last question because I feel like I'm half way t... ___ 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
[IronPython] 2.6.1 implements ssl module, but it crash...
import imaplib
c = imaplib.IMAP4_SSL('imap.sohu.com', 993)
c.login(myusername, mypassword)
ipy.exe memory footprint increase to 170M... and crash soon.
2.6.1 and 2.6.1with.NET4 has the same problem
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
