From fuzzyman at voidspace.org.uk Mon Apr 2 23:42:26 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 02 Apr 2007 22:42:26 +0100 Subject: [IronPython] Weird Anomoly with SetStandardOutput Message-ID: <461178C2.2070702@voidspace.org.uk> Hello all, If I create a subclass of 'Stream' from IronPython - and set it onto a PythonEngine using 'SetStandardOutput', then it fails with the following message: Traceback (most recent call last): File C:\Python Projects\modules in progress\ironpython\embeddingDivert.py, lin e 32, in Initialize File , line 0, in SetStandardOutput##94 TypeError: issubclass: arg 1 must be a class If I define an empty class, and set this then I get the expected error 'AttributeError: 'Diverter' object has no attribute 'get_CanSeek'. What is weird, is if I add the required methods and properties one at a time to the class (which the instance then acquires) - eventually it works !! Unfortunately this problem is going to block us very rapidly at resolver. We can probably get round it by creating the stream subclass in C# - but what is the problem with doing it from IronPython ? Below is a full interactive interpreter session showing what happens as I add methods to a class dynamically : >>> from IronPython.Hosting import PythonEngine >>> from System.IO import Stream >>> py = PythonEngine() >>> class Diverter(Stream): pass ... >>> output = Diverter() >>> py.SetStandardOutput(output) Traceback (most recent call last): AttributeError: 'Diverter' object has no attribute 'get_CanRead' >>> >>> Diverter.CanRead = lambda self: False >>> py.SetStandardOutput(output) Traceback (most recent call last): AttributeError: 'Diverter' object has no attribute 'get_CanSeek' >>> Diverter.CanSeek = lambda self: False >>> py.SetStandardOutput(output) Traceback (most recent call last): AttributeError: 'Diverter' object has no attribute 'get_Position' >>> Diverter.Position = property(lambda self: 0) >>> py.SetStandardOutput(output) Traceback (most recent call last): AttributeError: 'Diverter' object has no attribute 'get_CanWrite' >>> Diverter.CanWrite = lambda self: True >>> py.SetStandardOutput(output) >>> py.Execute('print 3') Traceback (most recent call last): AttributeError: 'Diverter' object has no attribute 'Write' >>> def Write(self, chars, offset, count): ... sys.stdout.write(repr(chars)) # silly buggy implementation ... >>> Diverter.Write = Write >>> import sys >>> py.Execute('print 3') System.Byte[](51, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)Traceback (most recent call las t): File , line 0, in ##126 File , line 0, in Execute##116 File , line 0, in ##127 File , line 0, in Write##121 File mscorlib, line unknown, in Flush File mscorlib, line unknown, in Flush AttributeError: 'Diverter' object has no attribute 'Flush' >>> From fuzzyman at voidspace.org.uk Mon Apr 2 23:54:34 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 02 Apr 2007 22:54:34 +0100 Subject: [IronPython] Weird Anomoly with SetStandardOutput In-Reply-To: <461178C2.2070702@voidspace.org.uk> References: <461178C2.2070702@voidspace.org.uk> Message-ID: <46117B9A.6050800@voidspace.org.uk> Michael Foord wrote: > Hello all, > > If I create a subclass of 'Stream' from IronPython - and set it onto a > PythonEngine using 'SetStandardOutput', then it fails with the following > message: > > Traceback (most recent call last): > File C:\Python Projects\modules in > progress\ironpython\embeddingDivert.py, lin > e 32, in Initialize > File , line 0, in SetStandardOutput##94 > TypeError: issubclass: arg 1 must be a class > > If I define an empty class, and set this then I get the expected error > 'AttributeError: 'Diverter' object has no attribute 'get_CanSeek'. > > [snip...] > > Unfortunately this problem is going to block us very rapidly at > resolver. We can probably get round it by creating the stream subclass > in C# - but what is the problem with doing it from IronPython ? > > Except that I realise that you may not have anticipated your users passing .NET subclasses from one IronPython engine to another... Can this be fixed ? Michael From matt at wecollectmore.com Tue Apr 3 00:02:44 2007 From: matt at wecollectmore.com (Matthew Swank) Date: Mon, 2 Apr 2007 17:02:44 -0500 Subject: [IronPython] strange runtime error hosting Iron Python in C# app Message-ID: <000001c77572$a47067a0$9838016f@EX46> Given a set of classes in a c# Library like the following: public interface IFoo { int Bar { get;} } public abstract class FooBase : IFoo { public abstract int Bar { get;} } public class FooConcrete1 : FooBase { public override int Bar { get { return 1; } } } and a C# consumer: public class FooUser { public static int FooInt(IFoo a) { return a.Bar; } } if I call FooInt from Python I'll get: "We Encountered an error: expected IFoo, got FooConcrete1". I suspect the error stems from adding an assembly as a reference inside the python code in addition to referencing it in the C# project. If this is the case, how do I make referenced assemblies visible to the hosted python module w/o using AddReference.? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernsnat at iit.edu Tue Apr 3 00:11:08 2007 From: ernsnat at iit.edu (Nathan Ernst) Date: Mon, 02 Apr 2007 17:11:08 -0500 Subject: [IronPython] Weird Anomoly with SetStandardOutput In-Reply-To: <46117B9A.6050800@voidspace.org.uk> References: <461178C2.2070702@voidspace.org.uk> <46117B9A.6050800@voidspace.org.uk> Message-ID: It looks to me that the problem is that abstract members defined on Stream are not implemented in Diverter. It would make sense to me that as they're added dynamically, it begins to work. What happens if all abstract members are defined initially in the derived class instead of added later? ----- Original Message ----- From: Michael Foord Date: Monday, April 2, 2007 4:59 pm Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput To: Discussion of IronPython > Michael Foord wrote: > > Hello all, > > > > If I create a subclass of 'Stream' from IronPython - and set it > onto a > > PythonEngine using 'SetStandardOutput', then it fails with the > following > > message: > > > > Traceback (most recent call last): > > File C:\Python Projects\modules in > > progress\ironpython\embeddingDivert.py, lin > > e 32, in Initialize > > File , line 0, in SetStandardOutput##94 > > TypeError: issubclass: arg 1 must be a class > > > > If I define an empty class, and set this then I get the expected > error > > 'AttributeError: 'Diverter' object has no attribute 'get_CanSeek'. > > > > [snip...] > > > > Unfortunately this problem is going to block us very rapidly at > > resolver. We can probably get round it by creating the stream > subclass > > in C# - but what is the problem with doing it from IronPython ? > > > > > > Except that I realise that you may not have anticipated your users > passing .NET subclasses from one IronPython engine to another... > > Can this be fixed ? > > Michael > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Tue Apr 3 00:08:56 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 02 Apr 2007 23:08:56 +0100 Subject: [IronPython] Weird Anomoly with SetStandardOutput In-Reply-To: <46117B9A.6050800@voidspace.org.uk> References: <461178C2.2070702@voidspace.org.uk> <46117B9A.6050800@voidspace.org.uk> Message-ID: <46117EF8.1080805@voidspace.org.uk> Michael Foord wrote: > Michael Foord wrote: > >> Hello all, >> >> If I create a subclass of 'Stream' from IronPython - and set it onto a >> PythonEngine using 'SetStandardOutput', then it fails with the following >> message: >> >> Traceback (most recent call last): >> File C:\Python Projects\modules in >> progress\ironpython\embeddingDivert.py, lin >> e 32, in Initialize >> File , line 0, in SetStandardOutput##94 >> TypeError: issubclass: arg 1 must be a class >> >> If I define an empty class, and set this then I get the expected error >> 'AttributeError: 'Diverter' object has no attribute 'get_CanSeek'. >> >> [snip...] >> >> Unfortunately this problem is going to block us very rapidly at >> resolver. We can probably get round it by creating the stream subclass >> in C# - but what is the problem with doing it from IronPython ? >> >> >> > > Except that I realise that you may not have anticipated your users > passing .NET subclasses from one IronPython engine to another... > > Can this be fixed ? > Oh, and : http://www.voidspace.org.uk/ironpython/ip_in_ip.shtml Embedding IronPython in IronPython. Michael Foord > Michael > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From dinov at exchange.microsoft.com Tue Apr 3 00:33:25 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 2 Apr 2007 15:33:25 -0700 Subject: [IronPython] Weird Anomoly with SetStandardOutput In-Reply-To: <46117EF8.1080805@voidspace.org.uk> References: <461178C2.2070702@voidspace.org.uk> <46117B9A.6050800@voidspace.org.uk> <46117EF8.1080805@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C22276EC76C1172@DF-GRTDANE-MSG.exchange.corp.microsoft.com> This seems to work for me: from IronPython.Hosting import PythonEngine from System.IO import Stream class C(Stream): @property def CanRead(self): return False @property def CanSeek(self): return False @property def CanWrite(self): return True @property def Position(self): return 0 def Write(self, chars, offset, count): from System import Console Console.WriteLine(chars) def Flush(self): pass py.SetStandardOutput(C()) py.Execute('print 3') I stuck to Console.WriteLine just to avoid having to think about sys across engines. Just out of curiosity - do you use the multiple engine support extensively? -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, April 02, 2007 3:09 PM To: Discussion of IronPython Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput Michael Foord wrote: > Michael Foord wrote: > >> Hello all, >> >> If I create a subclass of 'Stream' from IronPython - and set it onto a >> PythonEngine using 'SetStandardOutput', then it fails with the following >> message: >> >> Traceback (most recent call last): >> File C:\Python Projects\modules in >> progress\ironpython\embeddingDivert.py, lin >> e 32, in Initialize >> File , line 0, in SetStandardOutput##94 >> TypeError: issubclass: arg 1 must be a class >> >> If I define an empty class, and set this then I get the expected error >> 'AttributeError: 'Diverter' object has no attribute 'get_CanSeek'. >> >> [snip...] >> >> Unfortunately this problem is going to block us very rapidly at >> resolver. We can probably get round it by creating the stream subclass >> in C# - but what is the problem with doing it from IronPython ? >> >> >> > > Except that I realise that you may not have anticipated your users > passing .NET subclasses from one IronPython engine to another... > > Can this be fixed ? > Oh, and : http://www.voidspace.org.uk/ironpython/ip_in_ip.shtml Embedding IronPython in IronPython. Michael Foord > Michael > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Tue Apr 3 00:36:28 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 02 Apr 2007 23:36:28 +0100 Subject: [IronPython] Weird Anomoly with SetStandardOutput In-Reply-To: <7AD436E4270DD54A94238001769C22276EC76C1172@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <461178C2.2070702@voidspace.org.uk> <46117B9A.6050800@voidspace.org.uk> <46117EF8.1080805@voidspace.org.uk> <7AD436E4270DD54A94238001769C22276EC76C1172@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4611856C.3090402@voidspace.org.uk> Dino Viehland wrote: > This seems to work for me: > > from IronPython.Hosting import PythonEngine > from System.IO import Stream > > class C(Stream): > @property > def CanRead(self): return False > @property > def CanSeek(self): return False > @property > def CanWrite(self): return True > @property > def Position(self): return 0 > def Write(self, chars, offset, count): > from System import Console > Console.WriteLine(chars) > def Flush(self): pass > > Ha - they're properties. I was implementing them as methods - and it *appeared* to work... Cool - thanks. We're only just starting to use the multiple engine support. Thanks Dino. Michael > py.SetStandardOutput(C()) > py.Execute('print 3') > > > I stuck to Console.WriteLine just to avoid having to think about sys across engines. > > Just out of curiosity - do you use the multiple engine support extensively? > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, April 02, 2007 3:09 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput > > Michael Foord wrote: > >> Michael Foord wrote: >> >> >>> Hello all, >>> >>> If I create a subclass of 'Stream' from IronPython - and set it onto a >>> PythonEngine using 'SetStandardOutput', then it fails with the following >>> message: >>> >>> Traceback (most recent call last): >>> File C:\Python Projects\modules in >>> progress\ironpython\embeddingDivert.py, lin >>> e 32, in Initialize >>> File , line 0, in SetStandardOutput##94 >>> TypeError: issubclass: arg 1 must be a class >>> >>> If I define an empty class, and set this then I get the expected error >>> 'AttributeError: 'Diverter' object has no attribute 'get_CanSeek'. >>> >>> [snip...] >>> >>> Unfortunately this problem is going to block us very rapidly at >>> resolver. We can probably get round it by creating the stream subclass >>> in C# - but what is the problem with doing it from IronPython ? >>> >>> >>> >>> >> Except that I realise that you may not have anticipated your users >> passing .NET subclasses from one IronPython engine to another... >> >> Can this be fixed ? >> >> > Oh, and : > > http://www.voidspace.org.uk/ironpython/ip_in_ip.shtml > > Embedding IronPython in IronPython. > > Michael Foord > > >> Michael >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From dinov at exchange.microsoft.com Tue Apr 3 00:37:23 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 2 Apr 2007 15:37:23 -0700 Subject: [IronPython] strange runtime error hosting Iron Python in C# app In-Reply-To: <000001c77572$a47067a0$9838016f@EX46> References: <000001c77572$a47067a0$9838016f@EX46> Message-ID: <7AD436E4270DD54A94238001769C22276EC76C1180@DF-GRTDANE-MSG.exchange.corp.microsoft.com> How exactly are you doing this? If I take the code you've provided and put it into a .cs file, compile it to a DLL, and import it I get: IronPython 1.1b1 (1.1) on .NET 2.0.50727.312 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference('test') >>> import FooUser, FooConcrete1 >>> FooUser.FooInt(FooConcrete1()) 1 >>> ^Z Are you doing something different? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matthew Swank Sent: Monday, April 02, 2007 3:03 PM To: users at lists.ironpython.com Subject: [IronPython] strange runtime error hosting Iron Python in C# app Given a set of classes in a c# Library like the following: public interface IFoo { int Bar { get;} } public abstract class FooBase : IFoo { public abstract int Bar { get;} } public class FooConcrete1 : FooBase { public override int Bar { get { return 1; } } } and a C# consumer: public class FooUser { public static int FooInt(IFoo a) { return a.Bar; } } if I call FooInt from Python I'll get: "We Encountered an error: expected IFoo, got FooConcrete1". I suspect the error stems from adding an assembly as a reference inside the python code in addition to referencing it in the C# project. If this is the case, how do I make referenced assemblies visible to the hosted python module w/o using AddReference...? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Tue Apr 3 00:41:00 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 2 Apr 2007 15:41:00 -0700 Subject: [IronPython] Weird Anomoly with SetStandardOutput In-Reply-To: <4611856C.3090402@voidspace.org.uk> References: <461178C2.2070702@voidspace.org.uk> <46117B9A.6050800@voidspace.org.uk> <46117EF8.1080805@voidspace.org.uk> <7AD436E4270DD54A94238001769C22276EC76C1172@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4611856C.3090402@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C22276EC76C1183@DF-GRTDANE-MSG.exchange.corp.microsoft.com> The reason why I asked about multiple engine support is that it's actually a feature we don't know if we can maintain long-term. The problem is that it's actually impossible for us to always know what engine we were calling from. For example if we need to call back into something that requires an engine from a .NET ToString method we cannot properly flow the context into ToString and therefore we lose what engine was calling. So this might be a feature which disappears in later versions of IronPython. Instead we'd encourage hosting each engine in its own app domain leveraging the CLR's own isolation mechanisms. I don't believe that decision is entirely set in stone so it'd be interesting to hear what everyone thinks about it. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, April 02, 2007 3:36 PM To: Discussion of IronPython Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput Dino Viehland wrote: > This seems to work for me: > > from IronPython.Hosting import PythonEngine > from System.IO import Stream > > class C(Stream): > @property > def CanRead(self): return False > @property > def CanSeek(self): return False > @property > def CanWrite(self): return True > @property > def Position(self): return 0 > def Write(self, chars, offset, count): > from System import Console > Console.WriteLine(chars) > def Flush(self): pass > > Ha - they're properties. I was implementing them as methods - and it *appeared* to work... Cool - thanks. We're only just starting to use the multiple engine support. Thanks Dino. Michael > py.SetStandardOutput(C()) > py.Execute('print 3') > > > I stuck to Console.WriteLine just to avoid having to think about sys across engines. > > Just out of curiosity - do you use the multiple engine support extensively? > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, April 02, 2007 3:09 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput > > Michael Foord wrote: > >> Michael Foord wrote: >> >> >>> Hello all, >>> >>> If I create a subclass of 'Stream' from IronPython - and set it onto a >>> PythonEngine using 'SetStandardOutput', then it fails with the following >>> message: >>> >>> Traceback (most recent call last): >>> File C:\Python Projects\modules in >>> progress\ironpython\embeddingDivert.py, lin >>> e 32, in Initialize >>> File , line 0, in SetStandardOutput##94 >>> TypeError: issubclass: arg 1 must be a class >>> >>> If I define an empty class, and set this then I get the expected error >>> 'AttributeError: 'Diverter' object has no attribute 'get_CanSeek'. >>> >>> [snip...] >>> >>> Unfortunately this problem is going to block us very rapidly at >>> resolver. We can probably get round it by creating the stream subclass >>> in C# - but what is the problem with doing it from IronPython ? >>> >>> >>> >>> >> Except that I realise that you may not have anticipated your users >> passing .NET subclasses from one IronPython engine to another... >> >> Can this be fixed ? >> >> > Oh, and : > > http://www.voidspace.org.uk/ironpython/ip_in_ip.shtml > > Embedding IronPython in IronPython. > > Michael Foord > > >> Michael >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Tue Apr 3 00:44:48 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 02 Apr 2007 23:44:48 +0100 Subject: [IronPython] Weird Anomoly with SetStandardOutput In-Reply-To: <7AD436E4270DD54A94238001769C22276EC76C1183@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <461178C2.2070702@voidspace.org.uk> <46117B9A.6050800@voidspace.org.uk> <46117EF8.1080805@voidspace.org.uk> <7AD436E4270DD54A94238001769C22276EC76C1172@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4611856C.3090402@voidspace.org.uk> <7AD436E4270DD54A94238001769C22276EC76C1183@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <46118760.1070101@voidspace.org.uk> Dino Viehland wrote: > The reason why I asked about multiple engine support is that it's actually a feature we don't know if we can maintain long-term. The problem is that it's actually impossible for us to always know what engine we were calling from. For example if we need to call back into something that requires an engine from a .NET ToString method we cannot properly flow the context into ToString and therefore we lose what engine was calling. > > So this might be a feature which disappears in later versions of IronPython. Instead we'd encourage hosting each engine in its own app domain leveraging the CLR's own isolation mechanisms. I don't believe that decision is entirely set in stone so it'd be interesting to hear what everyone thinks about it. > Wouldn't there be performance implications of passing 'big' objects between app domains ? We're just switching to use the multiple engine feature - and keeping code sections isolated (from trashing the calling engines globals) is a big plus. At some stage we'd like to move to appdomains, but have 'contexts' with hundreds of objects to move across the boundaries. Having some (known) limitations on multiple engine support would be better than losing it, if possible. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, April 02, 2007 3:36 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput > > Dino Viehland wrote: > >> This seems to work for me: >> >> from IronPython.Hosting import PythonEngine >> from System.IO import Stream >> >> class C(Stream): >> @property >> def CanRead(self): return False >> @property >> def CanSeek(self): return False >> @property >> def CanWrite(self): return True >> @property >> def Position(self): return 0 >> def Write(self, chars, offset, count): >> from System import Console >> Console.WriteLine(chars) >> def Flush(self): pass >> >> >> > Ha - they're properties. > > I was implementing them as methods - and it *appeared* to work... > > Cool - thanks. > > We're only just starting to use the multiple engine support. > > Thanks Dino. > > Michael > > >> py.SetStandardOutput(C()) >> py.Execute('print 3') >> >> >> I stuck to Console.WriteLine just to avoid having to think about sys across engines. >> >> Just out of curiosity - do you use the multiple engine support extensively? >> >> >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Monday, April 02, 2007 3:09 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput >> >> Michael Foord wrote: >> >> >>> Michael Foord wrote: >>> >>> >>> >>>> Hello all, >>>> >>>> If I create a subclass of 'Stream' from IronPython - and set it onto a >>>> PythonEngine using 'SetStandardOutput', then it fails with the following >>>> message: >>>> >>>> Traceback (most recent call last): >>>> File C:\Python Projects\modules in >>>> progress\ironpython\embeddingDivert.py, lin >>>> e 32, in Initialize >>>> File , line 0, in SetStandardOutput##94 >>>> TypeError: issubclass: arg 1 must be a class >>>> >>>> If I define an empty class, and set this then I get the expected error >>>> 'AttributeError: 'Diverter' object has no attribute 'get_CanSeek'. >>>> >>>> [snip...] >>>> >>>> Unfortunately this problem is going to block us very rapidly at >>>> resolver. We can probably get round it by creating the stream subclass >>>> in C# - but what is the problem with doing it from IronPython ? >>>> >>>> >>>> >>>> >>>> >>> Except that I realise that you may not have anticipated your users >>> passing .NET subclasses from one IronPython engine to another... >>> >>> Can this be fixed ? >>> >>> >>> >> Oh, and : >> >> http://www.voidspace.org.uk/ironpython/ip_in_ip.shtml >> >> Embedding IronPython in IronPython. >> >> Michael Foord >> >> >> >>> Michael >>> >>> _______________________________________________ >>> users mailing list >>> users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >>> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From dinov at exchange.microsoft.com Tue Apr 3 00:51:48 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 2 Apr 2007 15:51:48 -0700 Subject: [IronPython] Weird Anomoly with SetStandardOutput In-Reply-To: <46118760.1070101@voidspace.org.uk> References: <461178C2.2070702@voidspace.org.uk> <46117B9A.6050800@voidspace.org.uk> <46117EF8.1080805@voidspace.org.uk> <7AD436E4270DD54A94238001769C22276EC76C1172@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4611856C.3090402@voidspace.org.uk> <7AD436E4270DD54A94238001769C22276EC76C1183@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <46118760.1070101@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C22276EC76C1195@DF-GRTDANE-MSG.exchange.corp.microsoft.com> To the extent that objects can be marshaled by ref it won't be too much of a problem - unless the objects are chatty in which case it'll be the x-domain calls which would kill perf instead of serialization of a large object graph. Thanks for the feedback, and if anyone else has other comments those are always appreciated. It's at least good to know we should think about it some more. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, April 02, 2007 3:45 PM To: Discussion of IronPython Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput Dino Viehland wrote: > The reason why I asked about multiple engine support is that it's actually a feature we don't know if we can maintain long-term. The problem is that it's actually impossible for us to always know what engine we were calling from. For example if we need to call back into something that requires an engine from a .NET ToString method we cannot properly flow the context into ToString and therefore we lose what engine was calling. > > So this might be a feature which disappears in later versions of IronPython. Instead we'd encourage hosting each engine in its own app domain leveraging the CLR's own isolation mechanisms. I don't believe that decision is entirely set in stone so it'd be interesting to hear what everyone thinks about it. > Wouldn't there be performance implications of passing 'big' objects between app domains ? We're just switching to use the multiple engine feature - and keeping code sections isolated (from trashing the calling engines globals) is a big plus. At some stage we'd like to move to appdomains, but have 'contexts' with hundreds of objects to move across the boundaries. Having some (known) limitations on multiple engine support would be better than losing it, if possible. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, April 02, 2007 3:36 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput > > Dino Viehland wrote: > >> This seems to work for me: >> >> from IronPython.Hosting import PythonEngine >> from System.IO import Stream >> >> class C(Stream): >> @property >> def CanRead(self): return False >> @property >> def CanSeek(self): return False >> @property >> def CanWrite(self): return True >> @property >> def Position(self): return 0 >> def Write(self, chars, offset, count): >> from System import Console >> Console.WriteLine(chars) >> def Flush(self): pass >> >> >> > Ha - they're properties. > > I was implementing them as methods - and it *appeared* to work... > > Cool - thanks. > > We're only just starting to use the multiple engine support. > > Thanks Dino. > > Michael > > >> py.SetStandardOutput(C()) >> py.Execute('print 3') >> >> >> I stuck to Console.WriteLine just to avoid having to think about sys across engines. >> >> Just out of curiosity - do you use the multiple engine support extensively? >> >> >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Monday, April 02, 2007 3:09 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput >> >> Michael Foord wrote: >> >> >>> Michael Foord wrote: >>> >>> >>> >>>> Hello all, >>>> >>>> If I create a subclass of 'Stream' from IronPython - and set it onto a >>>> PythonEngine using 'SetStandardOutput', then it fails with the following >>>> message: >>>> >>>> Traceback (most recent call last): >>>> File C:\Python Projects\modules in >>>> progress\ironpython\embeddingDivert.py, lin >>>> e 32, in Initialize >>>> File , line 0, in SetStandardOutput##94 >>>> TypeError: issubclass: arg 1 must be a class >>>> >>>> If I define an empty class, and set this then I get the expected error >>>> 'AttributeError: 'Diverter' object has no attribute 'get_CanSeek'. >>>> >>>> [snip...] >>>> >>>> Unfortunately this problem is going to block us very rapidly at >>>> resolver. We can probably get round it by creating the stream subclass >>>> in C# - but what is the problem with doing it from IronPython ? >>>> >>>> >>>> >>>> >>>> >>> Except that I realise that you may not have anticipated your users >>> passing .NET subclasses from one IronPython engine to another... >>> >>> Can this be fixed ? >>> >>> >>> >> Oh, and : >> >> http://www.voidspace.org.uk/ironpython/ip_in_ip.shtml >> >> Embedding IronPython in IronPython. >> >> Michael Foord >> >> >> >>> Michael >>> >>> _______________________________________________ >>> users mailing list >>> users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >>> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Tue Apr 3 00:57:12 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 02 Apr 2007 23:57:12 +0100 Subject: [IronPython] Weird Anomoly with SetStandardOutput In-Reply-To: <7AD436E4270DD54A94238001769C22276EC76C1195@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <461178C2.2070702@voidspace.org.uk> <46117B9A.6050800@voidspace.org.uk> <46117EF8.1080805@voidspace.org.uk> <7AD436E4270DD54A94238001769C22276EC76C1172@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4611856C.3090402@voidspace.org.uk> <7AD436E4270DD54A94238001769C22276EC76C1183@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <46118760.1070101@voidspace.org.uk> <7AD436E4270DD54A94238001769C22276EC76C1195@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <46118A48.3030607@voidspace.org.uk> Dino Viehland wrote: > To the extent that objects can be marshaled by ref it won't be too much of a problem - unless the objects are chatty in which case it'll be the x-domain calls which would kill perf instead of serialization of a large object graph. > They would largely be pure Python classes (just potentially a lot of instances). We should have to do very few calls across domain barriers though. However, it is in the most 'performance-sensitive' part of our application. Michael From matt at wecollectmore.com Tue Apr 3 16:27:29 2007 From: matt at wecollectmore.com (Matthew Swank) Date: Tue, 3 Apr 2007 09:27:29 -0500 Subject: [IronPython] strange runtime error hosting Iron Python in C# app In-Reply-To: <7AD436E4270DD54A94238001769C22276EC76C1180@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <000001c77572$a47067a0$9838016f@EX46> <7AD436E4270DD54A94238001769C22276EC76C1180@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <000601c775fc$3b3c6290$9838016f@EX46> _____ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, April 02, 2007 5:37 PM To: Discussion of IronPython Subject: Re: [IronPython] strange runtime error hosting Iron Python in C# app How exactly are you doing this? . I have a C# app that embeds python to run scripts. Given a script both the script and the app need to access the same library. Both the script and the app create objects using the library. The app links to the shared library. In addition, each hosted script has a preamble to add a reference to, and imports namespaces from the shared library. Matt From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matthew Swank Sent: Monday, April 02, 2007 3:03 PM To: users at lists.ironpython.com Subject: [IronPython] strange runtime error hosting Iron Python in C# app Given a set of classes in a c# Library like the following: public interface IFoo { int Bar { get;} } public abstract class FooBase : IFoo { public abstract int Bar { get;} } public class FooConcrete1 : FooBase { public override int Bar { get { return 1; } } } and a C# consumer: public class FooUser { public static int FooInt(IFoo a) { return a.Bar; } } if I call FooInt from Python I'll get: "We Encountered an error: expected IFoo, got FooConcrete1". I suspect the error stems from adding an assembly as a reference inside the python code in addition to referencing it in the C# project. If this is the case, how do I make referenced assemblies visible to the hosted python module w/o using AddReference.? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at wecollectmore.com Tue Apr 3 16:40:10 2007 From: matt at wecollectmore.com (Matthew Swank) Date: Tue, 3 Apr 2007 09:40:10 -0500 Subject: [IronPython] strange runtime error hosting Iron Python in C# app In-Reply-To: <000601c775fc$3b3c6290$9838016f@EX46> References: <000001c77572$a47067a0$9838016f@EX46><7AD436E4270DD54A94238001769C22276EC76C1180@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <000601c775fc$3b3c6290$9838016f@EX46> Message-ID: <000001c775fd$fba15b20$9838016f@EX46> Also, using the library directly from the ipy shell does not trigger the observed behavior. Matt _____ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, April 02, 2007 5:37 PM To: Discussion of IronPython Subject: Re: [IronPython] strange runtime error hosting Iron Python in C# app How exactly are you doing this? . I have a C# app that embeds python to run scripts. Given a script both the script and the app need to access the same library. Both the script and the app create objects using the library. The app links to the shared library. In addition, each hosted script has a preamble to add a reference to, and imports namespaces from the shared library. Matt From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matthew Swank Sent: Monday, April 02, 2007 3:03 PM To: users at lists.ironpython.com Subject: [IronPython] strange runtime error hosting Iron Python in C# app Given a set of classes in a c# Library like the following: public interface IFoo { int Bar { get;} } public abstract class FooBase : IFoo { public abstract int Bar { get;} } public class FooConcrete1 : FooBase { public override int Bar { get { return 1; } } } and a C# consumer: public class FooUser { public static int FooInt(IFoo a) { return a.Bar; } } if I call FooInt from Python I'll get: "We Encountered an error: expected IFoo, got FooConcrete1". I suspect the error stems from adding an assembly as a reference inside the python code in addition to referencing it in the C# project. If this is the case, how do I make referenced assemblies visible to the hosted python module w/o using AddReference.? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Tue Apr 3 17:35:50 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 3 Apr 2007 08:35:50 -0700 Subject: [IronPython] strange runtime error hosting Iron Python in C# app In-Reply-To: <000001c775fd$fba15b20$9838016f@EX46> References: <000001c77572$a47067a0$9838016f@EX46><7AD436E4270DD54A94238001769C22276EC76C1180@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <000601c775fc$3b3c6290$9838016f@EX46> <000001c775fd$fba15b20$9838016f@EX46> Message-ID: <7AD436E4270DD54A94238001769C22276EC76C136E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Oh, this is probably a loader context issue. Do you need to setup sys.path in order to clr.AddRefernece your assembly? If so then your assembly is most likely getting loaded twice. Once in the normal load context and once in the load file context (which is the context that files that live on sys.path but outside of your app domain base will get loaded into). Probably what's best would be for you to get the assembly object from one of your types (typeof(IFoo).GetAssembly()) and then add that reference directly to the clr module instead of asking us to do the load. You should be able to do that via PythonEngine.LoadAssembly. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matthew Swank Sent: Tuesday, April 03, 2007 7:40 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] strange runtime error hosting Iron Python in C# app Also, using the library directly from the ipy shell does not trigger the observed behavior. Matt ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, April 02, 2007 5:37 PM To: Discussion of IronPython Subject: Re: [IronPython] strange runtime error hosting Iron Python in C# app How exactly are you doing this? ... I have a C# app that embeds python to run scripts. Given a script both the script and the app need to access the same library. Both the script and the app create objects using the library. The app links to the shared library. In addition, each hosted script has a preamble to add a reference to, and imports namespaces from the shared library. Matt From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matthew Swank Sent: Monday, April 02, 2007 3:03 PM To: users at lists.ironpython.com Subject: [IronPython] strange runtime error hosting Iron Python in C# app Given a set of classes in a c# Library like the following: public interface IFoo { int Bar { get;} } public abstract class FooBase : IFoo { public abstract int Bar { get;} } public class FooConcrete1 : FooBase { public override int Bar { get { return 1; } } } and a C# consumer: public class FooUser { public static int FooInt(IFoo a) { return a.Bar; } } if I call FooInt from Python I'll get: "We Encountered an error: expected IFoo, got FooConcrete1". I suspect the error stems from adding an assembly as a reference inside the python code in addition to referencing it in the C# project. If this is the case, how do I make referenced assemblies visible to the hosted python module w/o using AddReference...? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at wecollectmore.com Tue Apr 3 18:19:01 2007 From: matt at wecollectmore.com (Matthew Swank) Date: Tue, 3 Apr 2007 11:19:01 -0500 Subject: [IronPython] strange runtime error hosting Iron Python in C# app In-Reply-To: <7AD436E4270DD54A94238001769C22276EC76C136E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <000001c77572$a47067a0$9838016f@EX46><7AD436E4270DD54A94238001769C22276EC76C1180@DF-GRTDANE-MSG.exchange.corp.microsoft.com><000601c775fc$3b3c6290$9838016f@EX46><000001c775fd$fba15b20$9838016f@EX46> <7AD436E4270DD54A94238001769C22276EC76C136E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <000901c7760b$d0b48dc0$9838016f@EX46> That did the trick! Thanks a lot, Matt _____ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, April 03, 2007 10:36 AM To: Discussion of IronPython Subject: Re: [IronPython] strange runtime error hosting Iron Python in C# app . Probably what's best would be for you to get the assembly object from one of your types (typeof(IFoo).GetAssembly()) and then add that reference directly to the clr module instead of asking us to do the load. You should be able to do that via PythonEngine.LoadAssembly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Apr 5 23:47:27 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 05 Apr 2007 22:47:27 +0100 Subject: [IronPython] Setting Recursion Limit On Embedded PythonEngine Message-ID: <46156E6F.7010802@voidspace.org.uk> Hello all, Setting the recursion limit on an embedded PythonEngine also affects the current engine. (We were hoping that using an embedded engine would shield our main environment from our users doing daft things like this in their code). >>> from IronPython.Hosting import PythonEngine >>> >>> e = PythonEngine() >>> e.Sys.getrecursionlimit() 2147483647 >>> e.Sys.setrecursionlimit(2) >>> import sys >>> sys.getrecursionlimit() 2 >>> e.Sys.getrecursionlimit() 2 By the way - the 'sys' module is a 'SystemState' object, which isn't in the API documentation (at least not in 1.0.1). We had to dig into the sources (which wasn't such a bad thing) to learn about it. Thanks Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml From dinov at exchange.microsoft.com Thu Apr 5 23:58:04 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 5 Apr 2007 14:58:04 -0700 Subject: [IronPython] Setting Recursion Limit On Embedded PythonEngine In-Reply-To: <46156E6F.7010802@voidspace.org.uk> References: <46156E6F.7010802@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C22276EC7C1D407@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Yep, this another is one of those spots where the engine isolation falls down :(. Unfortunately this one is currently by design. SystemState not being a real module was done to better support multiple engines as well. We probably won't fix that in v1.x but maybe in v2.x it could become a normal module. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, April 05, 2007 2:47 PM To: Discussion of IronPython Subject: [IronPython] Setting Recursion Limit On Embedded PythonEngine Hello all, Setting the recursion limit on an embedded PythonEngine also affects the current engine. (We were hoping that using an embedded engine would shield our main environment from our users doing daft things like this in their code). >>> from IronPython.Hosting import PythonEngine >>> >>> e = PythonEngine() >>> e.Sys.getrecursionlimit() 2147483647 >>> e.Sys.setrecursionlimit(2) >>> import sys >>> sys.getrecursionlimit() 2 >>> e.Sys.getrecursionlimit() 2 By the way - the 'sys' module is a 'SystemState' object, which isn't in the API documentation (at least not in 1.0.1). We had to dig into the sources (which wasn't such a bad thing) to learn about it. Thanks Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Fri Apr 6 00:02:15 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 05 Apr 2007 23:02:15 +0100 Subject: [IronPython] Setting Recursion Limit On Embedded PythonEngine In-Reply-To: <7AD436E4270DD54A94238001769C22276EC7C1D407@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <46156E6F.7010802@voidspace.org.uk> <7AD436E4270DD54A94238001769C22276EC7C1D407@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <461571E7.2090203@voidspace.org.uk> Dino Viehland wrote: > Yep, this another is one of those spots where the engine isolation falls down :(. Unfortunately this one is currently by design. SystemState not being a real module was done to better support multiple engines as well. We probably won't fix that in v1.x but maybe in v2.x it could become a normal module. > > Ok :-) Thanks for the quick reply. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, April 05, 2007 2:47 PM > To: Discussion of IronPython > Subject: [IronPython] Setting Recursion Limit On Embedded PythonEngine > > Hello all, > > Setting the recursion limit on an embedded PythonEngine also affects the > current engine. (We were hoping that using an embedded engine would > shield our main environment from our users doing daft things like this > in their code). > > >>> from IronPython.Hosting import PythonEngine > >>> > >>> e = PythonEngine() > >>> e.Sys.getrecursionlimit() > 2147483647 > >>> e.Sys.setrecursionlimit(2) > >>> import sys > >>> sys.getrecursionlimit() > 2 > >>> e.Sys.getrecursionlimit() > 2 > > By the way - the 'sys' module is a 'SystemState' object, which isn't in > the API documentation (at least not in 1.0.1). > > We had to dig into the sources (which wasn't such a bad thing) to learn > about it. > > Thanks > > Michael Foord > http://www.voidspace.org.uk/ironpython/index.shtml > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From iapyeh at gmail.com Fri Apr 6 11:38:30 2007 From: iapyeh at gmail.com (=?BIG5?B?uK2rSLe9?=) Date: Fri, 6 Apr 2007 17:38:30 +0800 Subject: [IronPython] Q: How do I compile .py files to a DLL for linking into my C# or VB program? Message-ID: <5d2316750704060238v37203c2eyfe5297acdb221d72@mail.gmail.com> A: IronPython does not support building DLLs for a C# style of linking and calling into Python code. You can define interfaces in C#, build those into a DLL, and then implement those interfaces in Python code as well as pass the python objects that implement the interfaces to C# code. Can Someone kindly give an example? Thanks in advance. iap -------------- next part -------------- An HTML attachment was scrubbed... URL: From iapyeh at gmail.com Fri Apr 6 11:47:40 2007 From: iapyeh at gmail.com (=?BIG5?B?uK2rSLe9?=) Date: Fri, 6 Apr 2007 17:47:40 +0800 Subject: [IronPython] Question about using IronPython in C# Message-ID: <5d2316750704060247i4d42f942i4203927cc4827db1@mail.gmail.com> As a C+ newbie. I am tring to write the MSN add-in in C# and use IronPython (Python, my favorite) actually. The following code can be compiled successfully (in VC# Studio). But it fails to be imported to be Messenger Add-in. The problem happens to create PythonEngine in Initialize(). Any Hints? Thanks in advance. iap ================================================================================= using System; using Microsoft.Messenger; using IronPython.Hosting; namespace MyAddIn { public class AddIn: IMessengerAddIn { MessengerClient _mclient = null; public void Initialize(MessengerClient mclient){ PythonEngine engine = new PythonEngine(); // If this line disabled, to be imported in Messenger will be fine. _mclient = mclient; _mclient.AddInProperties.FriendlyName = "My Bot 2"; _mclient.AddInProperties.Creator = "My Name"; _mclient.AddInProperties.Description = "Bot for testing"; _mclient.AddInProperties.Url = new Uri(http://www.google.com); _mclient.IncomingTextMessage += new EventHandler(IncomingTextMessageHandler); } void IncomingTextMessageHandler(object sender,IncomingTextMessageEventArgs args){ _mclient.SendTextMessage("What you said:"+args.TextMessage, args.UserFrom); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.hajek at teamvienna.at Fri Apr 6 15:33:12 2007 From: markus.hajek at teamvienna.at (Markus Hajek) Date: Fri, 6 Apr 2007 15:33:12 +0200 Subject: [IronPython] Restricting IronPython Message-ID: <003c01c77850$20c35ee0$624a1ca0$@hajek@teamvienna.at> Hi, I'm evaluating IronPython for use as a scripting language in a game server. Designers would use it for game-logic. Because designers typically are not engineers, one cannot expect them to follow common good practices. So I need to restrict what their script code can do in a few ways: a. They should not be able to use any libraries other than what we expose to them explicitly. That includes Python libraries (other than local) and .NET-Framework libraries. b. For framework classes it's necessary to expose only certain members of these classes that are meant to be used from Python. c. It should be possible to time-limit execution time of a script. Designers might build scripts that under certain circumstances enter an infinite loop or something similar. In such a case, script execution should be aborted. Now with a) it's easy enough to take away access to Python libraries. Neither is there a problem with .NET framework stuff because you need to add a reference explicitly - with two exceptions, mscorlib.dll and system.dll are referenced automatically. I wrote a patch to get around this (PythonEngine and ReflectedPackage). With this patch you have two boolean properties in EngineOptions, AutoReferenceMscorlib and AutoReferenceSystem which by default are set to true to keep behavior as it is, but can be set to false, too, with the expected effect. For b) it turns out there is no easy way of having a framework classes expose only certain methods/properties by for example passing only an interface to Python. That just doesn't work because Python will allow access to any public member of the concrete instance. One way around that would be to write adapter for each framework class (like: for class Player create class PythonPlayer which holds an instance of Player as private member and exposes only those members publicly that should be visible from Python), but that would be tedious. So I created another patch (Attributes and ReflectedType) which adds a new attribute [DoNotExpose] to IronPython. Framework code writers can decorate properties, methods, fields, nested types etc. with this attribute. Members decorated such won't be visible to Python code. Again, by default behavior is not changed as no code has this attribute. With c) I am stuck. I'm not at all sure where I could add such functionality with minimum impact to the existing codebase. Any ideas on that? Besides, any feedback to the patches would be most welcome, too. Happy Easter holidays, Max Hajek Vienna -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PythonEngine.patch Type: application/octet-stream Size: 453 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ReflectedPackage.patch Type: application/octet-stream Size: 614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Attributes.patch Type: application/octet-stream Size: 154 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ReflectedType.patch Type: application/octet-stream Size: 1163 bytes Desc: not available URL: From Martin.Maly at microsoft.com Fri Apr 6 17:39:08 2007 From: Martin.Maly at microsoft.com (Martin Maly) Date: Fri, 6 Apr 2007 08:39:08 -0700 Subject: [IronPython] Q: How do I compile .py files to a DLL for linking into my C# or VB program? In-Reply-To: <5d2316750704060238v37203c2eyfe5297acdb221d72@mail.gmail.com> References: <5d2316750704060238v37203c2eyfe5297acdb221d72@mail.gmail.com> Message-ID: There is a way to compile Python sources into a dll (there's a "pyc" sample on the codeplex website), however it will not produce a dll that is easily used from C# or VB. It is the dynamic nature of Python that makes it hard to compile into classes and methods in the same fashion as C# or VB do. Martin From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of ??? Sent: Friday, April 06, 2007 2:39 AM To: users at lists.ironpython.com Subject: [IronPython] Q: How do I compile .py files to a DLL for linking into my C# or VB program? A: IronPython does not support building DLLs for a C# style of linking and calling into Python code. You can define interfaces in C#, build those into a DLL, and then implement those interfaces in Python code as well as pass the python objects that implement the interfaces to C# code. Can Someone kindly give an example? Thanks in advance. iap -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Fri Apr 6 23:42:51 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 6 Apr 2007 14:42:51 -0700 Subject: [IronPython] Restricting IronPython In-Reply-To: <003c01c77850$20c35ee0$624a1ca0$@hajek@teamvienna.at> References: <003c01c77850$20c35ee0$624a1ca0$@hajek@teamvienna.at> Message-ID: <7AD436E4270DD54A94238001769C22276EC7C1D826@DF-GRTDANE-MSG.exchange.corp.microsoft.com> There's two ways I can think of how to enforce the time limit: 1. An external monitor which aborts the thread when a quantum has expired. This has the problem of potentially aborting at any native CPU instruction which most code is in no way prepared to handle. Therefore 2. Update CodeGen to emit checks to see if the current quantum has expired. Most likely you'd want to do this on every back-branch within the IL. I'm not sure how exactly you'd detect that w/o putting an abstraction around the Label structure so you know where each label lives within the IL. For compiler generated loops which you know to be bounded you could eliminate the check also and only do it for user defined loops. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Markus Hajek Sent: Friday, April 06, 2007 6:33 AM To: users at lists.ironpython.com Subject: [IronPython] Restricting IronPython Hi, I'm evaluating IronPython for use as a scripting language in a game server. Designers would use it for game-logic. Because designers typically are not engineers, one cannot expect them to follow common good practices. So I need to restrict what their script code can do in a few ways: a. They should not be able to use any libraries other than what we expose to them explicitly. That includes Python libraries (other than local) and .NET-Framework libraries. b. For framework classes it's necessary to expose only certain members of these classes that are meant to be used from Python. c. It should be possible to time-limit execution time of a script. Designers might build scripts that under certain circumstances enter an infinite loop or something similar. In such a case, script execution should be aborted. Now with a) it's easy enough to take away access to Python libraries. Neither is there a problem with .NET framework stuff because you need to add a reference explicitly - with two exceptions, mscorlib.dll and system.dll are referenced automatically. I wrote a patch to get around this (PythonEngine and ReflectedPackage). With this patch you have two boolean properties in EngineOptions, AutoReferenceMscorlib and AutoReferenceSystem which by default are set to true to keep behavior as it is, but can be set to false, too, with the expected effect. For b) it turns out there is no easy way of having a framework classes expose only certain methods/properties by for example passing only an interface to Python. That just doesn't work because Python will allow access to any public member of the concrete instance. One way around that would be to write adapter for each framework class (like: for class Player create class PythonPlayer which holds an instance of Player as private member and exposes only those members publicly that should be visible from Python), but that would be tedious. So I created another patch (Attributes and ReflectedType) which adds a new attribute [DoNotExpose] to IronPython. Framework code writers can decorate properties, methods, fields, nested types etc. with this attribute. Members decorated such won't be visible to Python code. Again, by default behavior is not changed as no code has this attribute. With c) I am stuck. I'm not at all sure where I could add such functionality with minimum impact to the existing codebase. Any ideas on that? Besides, any feedback to the patches would be most welcome, too. Happy Easter holidays, Max Hajek Vienna -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeff at ingenio.com Sat Apr 7 08:14:09 2007 From: Jeff at ingenio.com (Jeff Brown) Date: Fri, 6 Apr 2007 23:14:09 -0700 Subject: [IronPython] Restricting IronPython In-Reply-To: <7AD436E4270DD54A94238001769C22276EC7C1D826@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: You'll want to apply CodeAccessSecurity constraints to limit access to various pieces of functionality like Assembly.Load, etc... Basically, before you run any of this "untrusted" code, you should enter a minimum security context that specifically does not have permission to access the filesystem, run native code, link to other libraries and whatnot. It should only be able to do relatively "safe" things that prevent the code from exiting the .Net sandbox. In your own game libraries, you'll want to ensure that your methods can be called from a Partially Trusted context and can Demand the necessary priviledges to run. However, be aware that locking up the CPU is just one of many denial of service techniques a malicious (or careless) game user or designer might employ. Such a user might also cause log files to pile up, cause stack overflows, generate unreasonable network traffic, cause huge numbers of exceptions to be thrown, allocate large numbers of objects, leak memory and so on. CodeAccessSecurity will really cut down on how much of this can be done by user code, but you do need to very careful when you write your library to ensure that none of its functions can be abused (even innocently!). In any case, assuming you deny the SecurityPermissionFlag.ControlThread permission, then you can use Thread.Abort() to kill the thread. As Dino suggested you set up a monitoring thread that enforces the quantum and calls Thread.Abort(). If the code that's running does not have ControlThread (and can't block in unusual ways) then it cannot call Thread.ResetAbort() to prevent its shutdown. It _should_ shut down pretty quickly. I wouldn't be surprised if using Thread.Abort() were not completely robust but doing it within .Net (instead of via native code as I think Dino implies) is at least guaranteed not to trash the runtime environment. You might be interested in the constrained execution model that was added to .Net 2.0 to support integration with the CLR. It specifies that only code that satisfies certain reliability contracts may run. Check out this article: http://msdn2.microsoft.com/en-us/library/ms228973.aspx It doesn't sound like you need to be quite that paranoid though. Someone out there must have already implemented a robust .Net sandbox for just the kind of thing you're trying to do... Look around. It may be hard to find something that will work with IronPython because it uses a lot of reflection and its builtin modules might not be completely safe w.r.t. CodeAccessSecurity (might expose dangerous public methods). I'm just guessing here... Jeff. ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, April 06, 2007 2:43 PM To: Discussion of IronPython Subject: Re: [IronPython] Restricting IronPython There's two ways I can think of how to enforce the time limit: 1. An external monitor which aborts the thread when a quantum has expired. This has the problem of potentially aborting at any native CPU instruction which most code is in no way prepared to handle. Therefore 2. Update CodeGen to emit checks to see if the current quantum has expired. Most likely you'd want to do this on every back-branch within the IL. I'm not sure how exactly you'd detect that w/o putting an abstraction around the Label structure so you know where each label lives within the IL. For compiler generated loops which you know to be bounded you could eliminate the check also and only do it for user defined loops. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Markus Hajek Sent: Friday, April 06, 2007 6:33 AM To: users at lists.ironpython.com Subject: [IronPython] Restricting IronPython Hi, I'm evaluating IronPython for use as a scripting language in a game server. Designers would use it for game-logic. Because designers typically are not engineers, one cannot expect them to follow common good practices. So I need to restrict what their script code can do in a few ways: a. They should not be able to use any libraries other than what we expose to them explicitly. That includes Python libraries (other than local) and .NET-Framework libraries. b. For framework classes it's necessary to expose only certain members of these classes that are meant to be used from Python. c. It should be possible to time-limit execution time of a script. Designers might build scripts that under certain circumstances enter an infinite loop or something similar. In such a case, script execution should be aborted. Now with a) it's easy enough to take away access to Python libraries. Neither is there a problem with .NET framework stuff because you need to add a reference explicitly - with two exceptions, mscorlib.dll and system.dll are referenced automatically. I wrote a patch to get around this (PythonEngine and ReflectedPackage). With this patch you have two boolean properties in EngineOptions, AutoReferenceMscorlib and AutoReferenceSystem which by default are set to true to keep behavior as it is, but can be set to false, too, with the expected effect. For b) it turns out there is no easy way of having a framework classes expose only certain methods/properties by for example passing only an interface to Python. That just doesn't work because Python will allow access to any public member of the concrete instance. One way around that would be to write adapter for each framework class (like: for class Player create class PythonPlayer which holds an instance of Player as private member and exposes only those members publicly that should be visible from Python), but that would be tedious. So I created another patch (Attributes and ReflectedType) which adds a new attribute [DoNotExpose] to IronPython. Framework code writers can decorate properties, methods, fields, nested types etc. with this attribute. Members decorated such won't be visible to Python code. Again, by default behavior is not changed as no code has this attribute. With c) I am stuck. I'm not at all sure where I could add such functionality with minimum impact to the existing codebase. Any ideas on that? Besides, any feedback to the patches would be most welcome, too. Happy Easter holidays, Max Hajek Vienna -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidjensen at usa.net Sat Apr 7 17:23:54 2007 From: davidjensen at usa.net (David Jensen) Date: Sat, 07 Apr 2007 11:23:54 -0400 Subject: [IronPython] putting ironpython on backend, access through browser Message-ID: <821LDgPw37162S06.1175959434@cmsweb06.cms.usa.net> I would like to have a window in a browser, similar to telnet, but not the telnet that is included in some browser installations, access the IronPython dll on the backend for interactive Python interpreting. I assume the exe that comes with IronPython does nothing but access the dll that comes with it. Can I do this? If so, how? I would like to send files (text files from document databases) to the backend and use Python to modify them. I use Python in preference to c# because it is much easier, among other things. The shared web hosting service that I use do not allow anything (regular Python) but components on the back end and does not allow telnet to a windows server. (by the way, I cannot do a browser ftp if I use their Linux backend) I can edit Python scripts using the an HTML editor that works in a web page or a similar HTML/JavaScript text editor and I can ftp files to the backend using Internet Explorer. I am trying to do this on client computers that do not allow executables. My web hosting service said it does not check components(dlls?) unless they cause trouble with their system. IronPython could access their file system, but I do not intend to intrude on it. I assume I would find these policies on other shared hosting services. This setup could also be better that the regular Python on the backend even if I had a dedicated server, because it can integrate with the Foundation Class Library. David Jensen Apartment 412 414 West 120th Street New York, New York 10027 212-866-7094 646-245-2654 (cell) 206-984-4900 (fax to email) davidjensen at usa.net From chetan.techno at gmail.com Mon Apr 9 22:35:55 2007 From: chetan.techno at gmail.com (chetan soundankar) Date: Tue, 10 Apr 2007 02:05:55 +0530 Subject: [IronPython] Automation of Sharepoint Server 2007 Message-ID: Hi, Is it possible to Automate tasks such as creating a site, checking content types in sharepoint server 2007 with IronPython? if yes how can you give me some direction I am completely new to the Automation under COM environment. -Chetan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Tue Apr 10 05:09:43 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 9 Apr 2007 20:09:43 -0700 Subject: [IronPython] Automation of Sharepoint Server 2007 In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C222776869080DA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> It looks like there are managed APIs (maybe they're just COM wrappers?) for SharePoint which you could use from IronPython. A quick search turned up this site http://www.codeproject.com/useritems/SharePoint_Automation.asp which is using SharePoint from C#. From IronPython you would add references to the assemblies via the clr module: import clr clr.AddReference('Microsoft.SharePoint') ... and same for the other assemblies they suggest referencing ... >From there you need to import the appropriate namespaces, e.g.: import Microsoft.SharePoint as SP And then you could start inspecting the namespaces and types available: dir(SP) and drill down into the available functionality. That should line up with what you see for other examples of automating SharePoint on the web. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of chetan soundankar Sent: Monday, April 09, 2007 1:36 PM To: users at lists.ironpython.com Subject: [IronPython] Automation of Sharepoint Server 2007 Hi, Is it possible to Automate tasks such as creating a site, checking content types in sharepoint server 2007 with IronPython? if yes how can you give me some direction I am completely new to the Automation under COM environment. -Chetan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbarnett at uniserve.com Wed Apr 11 06:25:57 2007 From: mbarnett at uniserve.com (Mitch Barnett) Date: Tue, 10 Apr 2007 21:25:57 -0700 Subject: [IronPython] Automation of Sharepoint Server 2007 In-Reply-To: References: Message-ID: <001501c77bf1$81e5bc00$6700a8c0@valleyforge> Hi Chetan, MOSS 2007 is fully .NET 2.0 (built on ASP.NET 2.0 actually - no COM). You can find the SDK at: http://msdn2.microsoft.com/en-us/library/ms550992.aspx Note the class library and web service reference down the tree abit. You can automate pretty much anything and everything you want in MOSS 2007 with IronPython (at least I can in C#, so should be no probs in IP). Hope that helps, Mitch http://softwareindustrialization.com -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of users-request at lists.ironpython.com Sent: Tuesday, April 10, 2007 4:15 PM To: users at lists.ironpython.com Subject: users Digest, Vol 33, Issue 11 Send users mailing list submissions to users at lists.ironpython.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.ironpython.com/listinfo.cgi/users-ironpython.com or, via email, send a message with subject or body 'help' to users-request at lists.ironpython.com You can reach the person managing the list at users-owner at lists.ironpython.com When replying, please edit your Subject line so it is more specific than "Re: Contents of users digest..." Today's Topics: 1. Re: Automation of Sharepoint Server 2007 (Dino Viehland) ---------------------------------------------------------------------- Message: 1 Date: Mon, 9 Apr 2007 20:09:43 -0700 From: Dino Viehland Subject: Re: [IronPython] Automation of Sharepoint Server 2007 To: Discussion of IronPython Message-ID: <7AD436E4270DD54A94238001769C222776869080DA at DF-GRTDANE-MSG.exchange.corp.mic rosoft.com> Content-Type: text/plain; charset="us-ascii" It looks like there are managed APIs (maybe they're just COM wrappers?) for SharePoint which you could use from IronPython. A quick search turned up this site http://www.codeproject.com/useritems/SharePoint_Automation.asp which is using SharePoint from C#. From IronPython you would add references to the assemblies via the clr module: import clr clr.AddReference('Microsoft.SharePoint') ... and same for the other assemblies they suggest referencing ... >From there you need to import the appropriate namespaces, e.g.: import Microsoft.SharePoint as SP And then you could start inspecting the namespaces and types available: dir(SP) and drill down into the available functionality. That should line up with what you see for other examples of automating SharePoint on the web. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of chetan soundankar Sent: Monday, April 09, 2007 1:36 PM To: users at lists.ironpython.com Subject: [IronPython] Automation of Sharepoint Server 2007 Hi, Is it possible to Automate tasks such as creating a site, checking content types in sharepoint server 2007 with IronPython? if yes how can you give me some direction I am completely new to the Automation under COM environment. -Chetan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ironpython.com/pipermail/users-ironpython.com/attachments/20070 409/4e4b187d/attachment.html ------------------------------ _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com End of users Digest, Vol 33, Issue 11 ************************************* From adam at volition-inc.com Wed Apr 11 17:21:24 2007 From: adam at volition-inc.com (Adam Pletcher) Date: Wed, 11 Apr 2007 10:21:24 -0500 Subject: [IronPython] Debugging embedded IP? In-Reply-To: <001501c77bf1$81e5bc00$6700a8c0@valleyforge> References: <001501c77bf1$81e5bc00$6700a8c0@valleyforge> Message-ID: <893A44FF792E904A97B7515CE3419146C262C6@volimxs01.thqinc.com> I'm giving IronPython a test run, and definitely like it so far. I have the VS 2005 debugger working with IP scripts, which is pretty slick. One thing I'm trying to determine is if it's possible to use a debugger (VS, CLR or otherwise) to debug scripts run by an embedded IronPython interpreter. The turorials cover how to embed, then how debug, but not together. Any pointers/links appreciated. -- Adam Pletcher Senior Technical Artist Volition / THQ From dinov at exchange.microsoft.com Wed Apr 11 17:58:29 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 11 Apr 2007 08:58:29 -0700 Subject: [IronPython] Debugging embedded IP? In-Reply-To: <893A44FF792E904A97B7515CE3419146C262C6@volimxs01.thqinc.com> References: <001501c77bf1$81e5bc00$6700a8c0@valleyforge> <893A44FF792E904A97B7515CE3419146C262C6@volimxs01.thqinc.com> Message-ID: <7AD436E4270DD54A94238001769C22277A1835D083@DF-GRTDANE-MSG.exchange.corp.microsoft.com> The answer to this all depends upon how the scripts are getting executed. If you have a bunch of .py files which are getting loaded as modules from disk (e.g. your typical import scenario) and you haven't used the -X:GenerateAsSnippets mode then the answer is yes. You should be able to attach to the process doing the embedding, open the .py file in VS and set breakpoints and step through it. If you build your own copy of IronPython.dll then you'll also be able to step from the script code to the IronPython code. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Adam Pletcher Sent: Wednesday, April 11, 2007 8:21 AM To: Discussion of IronPython Subject: [IronPython] Debugging embedded IP? I'm giving IronPython a test run, and definitely like it so far. I have the VS 2005 debugger working with IP scripts, which is pretty slick. One thing I'm trying to determine is if it's possible to use a debugger (VS, CLR or otherwise) to debug scripts run by an embedded IronPython interpreter. The turorials cover how to embed, then how debug, but not together. Any pointers/links appreciated. -- Adam Pletcher Senior Technical Artist Volition / THQ _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From matt at wecollectmore.com Wed Apr 11 20:56:27 2007 From: matt at wecollectmore.com (Matthew Swank) Date: Wed, 11 Apr 2007 13:56:27 -0500 Subject: [IronPython] Debugging embedded IP? In-Reply-To: <7AD436E4270DD54A94238001769C22277A1835D083@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <001501c77bf1$81e5bc00$6700a8c0@valleyforge><893A44FF792E904A97B7515CE3419146C262C6@volimxs01.thqinc.com> <7AD436E4270DD54A94238001769C22277A1835D083@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <000001c77c6b$1c529eb0$9838016f@EX46> I would also like to debug my scripts, but I'm not sure how I could import them in the way you describe. My application provides a context in which a script can execute. From inside C# I create a module that has certain assemblies referenced, and makes certain runtime objects available to the script. I then use ExecuteFile to run the script in the context of the prepared module. Is there any way to attach the debugger to scripts run in this fashion? Matt -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, April 11, 2007 10:58 AM To: Discussion of IronPython Subject: Re: [IronPython] Debugging embedded IP? The answer to this all depends upon how the scripts are getting executed. If you have a bunch of .py files which are getting loaded as modules from disk (e.g. your typical import scenario) and you haven't used the -X:GenerateAsSnippets mode then the answer is yes. You should be able to attach to the process doing the embedding, open the .py file in VS and set breakpoints and step through it. If you build your own copy of IronPython.dll then you'll also be able to step from the script code to the IronPython code. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Adam Pletcher Sent: Wednesday, April 11, 2007 8:21 AM To: Discussion of IronPython Subject: [IronPython] Debugging embedded IP? I'm giving IronPython a test run, and definitely like it so far. I have the VS 2005 debugger working with IP scripts, which is pretty slick. One thing I'm trying to determine is if it's possible to use a debugger (VS, CLR or otherwise) to debug scripts run by an embedded IronPython interpreter. The turorials cover how to embed, then how debug, but not together. Any pointers/links appreciated. -- Adam Pletcher Senior Technical Artist Volition / THQ _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From chris.stoy at redstorm.com Wed Apr 11 21:14:51 2007 From: chris.stoy at redstorm.com (Chris Stoy) Date: Wed, 11 Apr 2007 15:14:51 -0400 Subject: [IronPython] Sharing state between embedded PythonEngines Message-ID: <930168C299A0C44D905F4B11995AD74407E6D5D3@UBIMAIL2.ubisoft.org> Hi all, I'm working on embedding IronPython in a C# application and would like to have a single, global module where I expose my objects and run scripts, and have multiple views into that state. For example, I want to have one (or more) IronPython console views that provide an interactive prompt that the user can type in and execute code. If I enter a function/variable in one of the consoles, then it is also available in the others. (ie, I enter "x=1" in console A and in console B I can say "print x" and see "1" output.) I also want to execute much larger, non-interactive scripts that a user can write and, again, this state is shared across all my IronPython views. So, am I just thinking about this wrong? How are people embedding IronPython in their apps? It seems strange (and inefficient) to have to create a new PythonEngine and add all the references and expose globals every time I want to execute script. Is there a way to share some of this state? Can this be done using EngineModules? Any thoughts would be appreciated. Thanks. Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Wed Apr 11 21:39:32 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 11 Apr 2007 20:39:32 +0100 Subject: [IronPython] Sharing state between embedded PythonEngines In-Reply-To: <930168C299A0C44D905F4B11995AD74407E6D5D3@UBIMAIL2.ubisoft.org> References: <930168C299A0C44D905F4B11995AD74407E6D5D3@UBIMAIL2.ubisoft.org> Message-ID: <461D3974.1060703@voidspace.org.uk> Chris Stoy wrote: > > Hi all, > > I?m working on embedding IronPython in a C# application and would like > to have a single, global module where I expose my objects and run > scripts, and have multiple views into that state. > That is certainly possible - but I'm not sure how easy it will be to have multiple *consoles*. Creating a custom control which receives input and displays the result in a window. (Sharing a single context behind the scenes...) Is using consoles as your view, central to your application ? Michael http://www.voidspace.org.uk/ironpython/index.shtml > For example, I want to have one (or more) IronPython console views > that provide an interactive prompt that the user can type in and > execute code. If I enter a function/variable in one of the consoles, > then it is also available in the others. (ie, I enter ?x=1? in console > A and in console B I can say ?print x? and see ?1? output.) I also > want to execute much larger, non-interactive scripts that a user can > write and, again, this state is shared across all my IronPython views. > > So, am I just thinking about this wrong? How are people embedding > IronPython in their apps? It seems strange (and inefficient) to have > to create a new PythonEngine and add all the references and expose > globals every time I want to execute script. Is there a way to share > some of this state? Can this be done using EngineModules? > > Any thoughts would be appreciated. > > Thanks. > > Chris. > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at exchange.microsoft.com Wed Apr 11 21:46:16 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 11 Apr 2007 12:46:16 -0700 Subject: [IronPython] Debugging embedded IP? In-Reply-To: <000001c77c6b$1c529eb0$9838016f@EX46> References: <001501c77bf1$81e5bc00$6700a8c0@valleyforge><893A44FF792E904A97B7515CE3419146C262C6@volimxs01.thqinc.com> <7AD436E4270DD54A94238001769C22277A1835D083@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <000001c77c6b$1c529eb0$9838016f@EX46> Message-ID: <7AD436E4270DD54A94238001769C22277A1835D26D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> You can call PythonEngine.CreateOptimizedModule on the engine to create the module which will be fully debuggable. After you get the module back you'll need to inject your runtime objects and then call Execute on the module. The referenced assemblies happen at the engine level rather than the module level so you can do those whenever. If you want to also import them on behalf of the user you can call the Import API on the OptimizedEngineModule class. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matthew Swank Sent: Wednesday, April 11, 2007 11:56 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging embedded IP? I would also like to debug my scripts, but I'm not sure how I could import them in the way you describe. My application provides a context in which a script can execute. From inside C# I create a module that has certain assemblies referenced, and makes certain runtime objects available to the script. I then use ExecuteFile to run the script in the context of the prepared module. Is there any way to attach the debugger to scripts run in this fashion? Matt -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, April 11, 2007 10:58 AM To: Discussion of IronPython Subject: Re: [IronPython] Debugging embedded IP? The answer to this all depends upon how the scripts are getting executed. If you have a bunch of .py files which are getting loaded as modules from disk (e.g. your typical import scenario) and you haven't used the -X:GenerateAsSnippets mode then the answer is yes. You should be able to attach to the process doing the embedding, open the .py file in VS and set breakpoints and step through it. If you build your own copy of IronPython.dll then you'll also be able to step from the script code to the IronPython code. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Adam Pletcher Sent: Wednesday, April 11, 2007 8:21 AM To: Discussion of IronPython Subject: [IronPython] Debugging embedded IP? I'm giving IronPython a test run, and definitely like it so far. I have the VS 2005 debugger working with IP scripts, which is pretty slick. One thing I'm trying to determine is if it's possible to use a debugger (VS, CLR or otherwise) to debug scripts run by an embedded IronPython interpreter. The turorials cover how to embed, then how debug, but not together. Any pointers/links appreciated. -- Adam Pletcher Senior Technical Artist Volition / THQ _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From chris.stoy at redstorm.com Wed Apr 11 22:00:37 2007 From: chris.stoy at redstorm.com (Chris Stoy) Date: Wed, 11 Apr 2007 16:00:37 -0400 Subject: [IronPython] Sharing state between embedded PythonEngines In-Reply-To: <461D3974.1060703@voidspace.org.uk> Message-ID: <930168C299A0C44D905F4B11995AD74407E6D688@UBIMAIL2.ubisoft.org> Well, a single console would be sufficient. I guess my real question is what the best architecture is for having a console and executing scripts? I imagine three ways to access IronPython: 1. an interactive console window (I already have this control working) 2. a script editing window (with possible debugger support) 3. executing a script file saved on disk The first issue is the amount of setup that goes into creating a PythonEngine instance set up to access objects exposed by my app. This may not be a big deal, but seems wasteful to keep creating and destroying these things. The second issue is preserving state between script executions. Maybe that is a bad idea in the first place and I should just make people import their scripts when they want to use them. What are other people doing? Chris. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Wednesday, April 11, 2007 3:40 PM To: Discussion of IronPython Subject: Re: [IronPython] Sharing state between embedded PythonEngines Chris Stoy wrote: > > Hi all, > > I'm working on embedding IronPython in a C# application and would like > to have a single, global module where I expose my objects and run > scripts, and have multiple views into that state. > That is certainly possible - but I'm not sure how easy it will be to have multiple *consoles*. Creating a custom control which receives input and displays the result in a window. (Sharing a single context behind the scenes...) Is using consoles as your view, central to your application ? Michael http://www.voidspace.org.uk/ironpython/index.shtml > For example, I want to have one (or more) IronPython console views > that provide an interactive prompt that the user can type in and > execute code. If I enter a function/variable in one of the consoles, > then it is also available in the others. (ie, I enter "x=1" in console > A and in console B I can say "print x" and see "1" output.) I also > want to execute much larger, non-interactive scripts that a user can > write and, again, this state is shared across all my IronPython views. > > So, am I just thinking about this wrong? How are people embedding > IronPython in their apps? It seems strange (and inefficient) to have > to create a new PythonEngine and add all the references and expose > globals every time I want to execute script. Is there a way to share > some of this state? Can this be done using EngineModules? > > Any thoughts would be appreciated. > > Thanks. > > Chris. > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From matt at wecollectmore.com Wed Apr 11 22:03:32 2007 From: matt at wecollectmore.com (Matthew Swank) Date: Wed, 11 Apr 2007 15:03:32 -0500 Subject: [IronPython] Debugging embedded IP? In-Reply-To: <7AD436E4270DD54A94238001769C22277A1835D26D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <001501c77bf1$81e5bc00$6700a8c0@valleyforge><893A44FF792E904A97B7515CE3419146C262C6@volimxs01.thqinc.com><7AD436E4270DD54A94238001769C22277A1835D083@DF-GRTDANE-MSG.exchange.corp.microsoft.com><000001c77c6b$1c529eb0$9838016f@EX46> <7AD436E4270DD54A94238001769C22277A1835D26D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <000701c77c74$7b3e00a0$9838016f@EX46> *in a Mr. Burns voice* Excellent! Thanks again, Matt -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, April 11, 2007 2:46 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging embedded IP? You can call PythonEngine.CreateOptimizedModule on the engine to create the module which will be fully debuggable. After you get the module back you'll need to inject your runtime objects and then call Execute on the module. The referenced assemblies happen at the engine level rather than the module level so you can do those whenever. If you want to also import them on behalf of the user you can call the Import API on the OptimizedEngineModule class. From joesox at gmail.com Wed Apr 11 22:05:00 2007 From: joesox at gmail.com (JoeSox) Date: Wed, 11 Apr 2007 13:05:00 -0700 Subject: [IronPython] Sharing state between embedded PythonEngines In-Reply-To: <930168C299A0C44D905F4B11995AD74407E6D5D3@UBIMAIL2.ubisoft.org> References: <930168C299A0C44D905F4B11995AD74407E6D5D3@UBIMAIL2.ubisoft.org> Message-ID: <785694cd0704111305l665f3d4bk1b9f1d376e468903@mail.gmail.com> On 4/11/07, Chris Stoy wrote: > So, am I just thinking about this wrong? How are people embedding > IronPython in their apps? I believe it really depends upon the application's objectives. From just being onlist for awhile it seems to me most developers are creating something that is working behind the scene of the app itself. It also sounds to me that people place IronPython in a .Net app so the user just uses .py files for the actual day-to-day work, sort of a best of both worlds solution. I originally got interested in IronPython much the same way. I am not sure if you have taken a look at a 'console' I have thrown out there. I original created it to help me turn Python modules into IP friendly ones. http://www.codeproject.com/useritems/irontextbox.asp I am not too happy with how it stands right now but it is very easy to place in a .Net app and you can have several. It is very easy to customize to your liking. I have been looking at a redesign making it very similar to the VS IronPython console window. I was hoping to make some hooks into the VS dlls but it is very complicated and it looks to me that I would need to make a bunch of custom classes, which unfortunately, I don't have the time to due right now. If no one beats me to it I might have something in 6 months or so. I also have to design it so it doesn't depend upon VS dlls, incase the user doesn't have them, or not, I haven't decided yet. > It seems strange (and inefficient) to have to > create a new PythonEngine and add all the references and expose globals > every time I want to execute script. Is there a way to share some of this > state? Can this be done using EngineModules? Not knowing the exact details of your app and why you would need to send messages to multiple consoles, it sounds like you would need to develop your own classes to handle the messaging. From what I have derived from all of IP's console classes, this is not a built in feature but I could be very much mistaken. I do believe it can be done, just that you would have to develop your own classes to handle your objective and I bet there is at least two different ways you can design them. -- Later, JoeSox From markus.hajek at teamvienna.at Thu Apr 12 09:13:03 2007 From: markus.hajek at teamvienna.at (Markus Hajek) Date: Thu, 12 Apr 2007 09:13:03 +0200 Subject: [IronPython] Restricting IronPython In-Reply-To: <7AD436E4270DD54A94238001769C22276EC7C1D826@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <003c01c77850$20c35ee0$624a1ca0$@hajek@teamvienna.at> <7AD436E4270DD54A94238001769C22276EC7C1D826@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <000301c77cd2$03df2300$0b9d6900$@hajek@teamvienna.at> Hi, thanks for the answer. Isn't there a way to add a delegate to each executed (python) statement - and do so in one place in the code base? I was thinking about a delegate returning a Boolean. Only if it returns true, the statement is actually executed. Otherwise something like "exit python" is executed. Is there a place where I could add this instrumentation? And how would I go about the "exit python" bit? Cheers, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Freitag, 06. April 2007 23:43 An: Discussion of IronPython Betreff: Re: [IronPython] Restricting IronPython There's two ways I can think of how to enforce the time limit: 1. An external monitor which aborts the thread when a quantum has expired. This has the problem of potentially aborting at any native CPU instruction which most code is in no way prepared to handle. Therefore 2. Update CodeGen to emit checks to see if the current quantum has expired. Most likely you'd want to do this on every back-branch within the IL. I'm not sure how exactly you'd detect that w/o putting an abstraction around the Label structure so you know where each label lives within the IL. For compiler generated loops which you know to be bounded you could eliminate the check also and only do it for user defined loops. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Markus Hajek Sent: Friday, April 06, 2007 6:33 AM To: users at lists.ironpython.com Subject: [IronPython] Restricting IronPython Hi, I'm evaluating IronPython for use as a scripting language in a game server. Designers would use it for game-logic. Because designers typically are not engineers, one cannot expect them to follow common good practices. So I need to restrict what their script code can do in a few ways: a. They should not be able to use any libraries other than what we expose to them explicitly. That includes Python libraries (other than local) and .NET-Framework libraries. b. For framework classes it's necessary to expose only certain members of these classes that are meant to be used from Python. c. It should be possible to time-limit execution time of a script. Designers might build scripts that under certain circumstances enter an infinite loop or something similar. In such a case, script execution should be aborted. Now with a) it's easy enough to take away access to Python libraries. Neither is there a problem with .NET framework stuff because you need to add a reference explicitly - with two exceptions, mscorlib.dll and system.dll are referenced automatically. I wrote a patch to get around this (PythonEngine and ReflectedPackage). With this patch you have two boolean properties in EngineOptions, AutoReferenceMscorlib and AutoReferenceSystem which by default are set to true to keep behavior as it is, but can be set to false, too, with the expected effect. For b) it turns out there is no easy way of having a framework classes expose only certain methods/properties by for example passing only an interface to Python. That just doesn't work because Python will allow access to any public member of the concrete instance. One way around that would be to write adapter for each framework class (like: for class Player create class PythonPlayer which holds an instance of Player as private member and exposes only those members publicly that should be visible from Python), but that would be tedious. So I created another patch (Attributes and ReflectedType) which adds a new attribute [DoNotExpose] to IronPython. Framework code writers can decorate properties, methods, fields, nested types etc. with this attribute. Members decorated such won't be visible to Python code. Again, by default behavior is not changed as no code has this attribute. With c) I am stuck. I'm not at all sure where I could add such functionality with minimum impact to the existing codebase. Any ideas on that? Besides, any feedback to the patches would be most welcome, too. Happy Easter holidays, Max Hajek Vienna -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.hajek at teamvienna.at Thu Apr 12 09:32:15 2007 From: markus.hajek at teamvienna.at (Markus Hajek) Date: Thu, 12 Apr 2007 09:32:15 +0200 Subject: [IronPython] Restricting IronPython In-Reply-To: References: <7AD436E4270DD54A94238001769C22276EC7C1D826@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <000e01c77cd4$b22504f0$166f0ed0$@hajek@teamvienna.at> Hi, thank you for your thoughts. CAS sure enough is a valuable addition to my arsenal for keeping designer's code in their sandbox (even though I do not expect them to actively try a DOS-attack, but innocents can sometimes cause the most harm ;-) CAS wouldn't help to prevent the time-problem, though. And the Thread.Abort() way of ensuring that Python-code doesn't execute too long just does not seem very stable. Ideally, I'd like to be able to interrupt python execution with each python statement. I do not need to interrupt inside a python statement because a single statement cannot execute very long except for when it calls library code. As the only library code I expose to Python is under my control, I can guarantee this code to not expose any methods with inacceptable runtime-behavior. Alas, I have not yet found out where I could add such behavior (see my other mail). Interestingly, I have been looking for a ready-made sandbox environment, but with no success. Actually, I'm also somewhat surprised that it seems as if I'm the first wanting to use IronPython in such a way, given the history of CPython being used for game-scripting languages. Cheers, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Jeff Brown Gesendet: Samstag, 07. April 2007 08:14 An: Discussion of IronPython Betreff: Re: [IronPython] Restricting IronPython You'll want to apply CodeAccessSecurity constraints to limit access to various pieces of functionality like Assembly.Load, etc... Basically, before you run any of this "untrusted" code, you should enter a minimum security context that specifically does not have permission to access the filesystem, run native code, link to other libraries and whatnot. It should only be able to do relatively "safe" things that prevent the code from exiting the .Net sandbox. In your own game libraries, you'll want to ensure that your methods can be called from a Partially Trusted context and can Demand the necessary priviledges to run. However, be aware that locking up the CPU is just one of many denial of service techniques a malicious (or careless) game user or designer might employ. Such a user might also cause log files to pile up, cause stack overflows, generate unreasonable network traffic, cause huge numbers of exceptions to be thrown, allocate large numbers of objects, leak memory and so on. CodeAccessSecurity will really cut down on how much of this can be done by user code, but you do need to very careful when you write your library to ensure that none of its functions can be abused (even innocently!). In any case, assuming you deny the SecurityPermissionFlag.ControlThread permission, then you can use Thread.Abort() to kill the thread. As Dino suggested you set up a monitoring thread that enforces the quantum and calls Thread.Abort(). If the code that's running does not have ControlThread (and can't block in unusual ways) then it cannot call Thread.ResetAbort() to prevent its shutdown. It _should_ shut down pretty quickly. I wouldn't be surprised if using Thread.Abort() were not completely robust but doing it within .Net (instead of via native code as I think Dino implies) is at least guaranteed not to trash the runtime environment. You might be interested in the constrained execution model that was added to .Net 2.0 to support integration with the CLR. It specifies that only code that satisfies certain reliability contracts may run. Check out this article: http://msdn2.microsoft.com/en-us/library/ms228973.aspx It doesn't sound like you need to be quite that paranoid though. Someone out there must have already implemented a robust .Net sandbox for just the kind of thing you're trying to do... Look around. It may be hard to find something that will work with IronPython because it uses a lot of reflection and its builtin modules might not be completely safe w.r.t. CodeAccessSecurity (might expose dangerous public methods). I'm just guessing here... Jeff. _____ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, April 06, 2007 2:43 PM To: Discussion of IronPython Subject: Re: [IronPython] Restricting IronPython There's two ways I can think of how to enforce the time limit: 1. An external monitor which aborts the thread when a quantum has expired. This has the problem of potentially aborting at any native CPU instruction which most code is in no way prepared to handle. Therefore 2. Update CodeGen to emit checks to see if the current quantum has expired. Most likely you'd want to do this on every back-branch within the IL. I'm not sure how exactly you'd detect that w/o putting an abstraction around the Label structure so you know where each label lives within the IL. For compiler generated loops which you know to be bounded you could eliminate the check also and only do it for user defined loops. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Markus Hajek Sent: Friday, April 06, 2007 6:33 AM To: users at lists.ironpython.com Subject: [IronPython] Restricting IronPython Hi, I'm evaluating IronPython for use as a scripting language in a game server. Designers would use it for game-logic. Because designers typically are not engineers, one cannot expect them to follow common good practices. So I need to restrict what their script code can do in a few ways: a. They should not be able to use any libraries other than what we expose to them explicitly. That includes Python libraries (other than local) and .NET-Framework libraries. b. For framework classes it's necessary to expose only certain members of these classes that are meant to be used from Python. c. It should be possible to time-limit execution time of a script. Designers might build scripts that under certain circumstances enter an infinite loop or something similar. In such a case, script execution should be aborted. Now with a) it's easy enough to take away access to Python libraries. Neither is there a problem with .NET framework stuff because you need to add a reference explicitly - with two exceptions, mscorlib.dll and system.dll are referenced automatically. I wrote a patch to get around this (PythonEngine and ReflectedPackage). With this patch you have two boolean properties in EngineOptions, AutoReferenceMscorlib and AutoReferenceSystem which by default are set to true to keep behavior as it is, but can be set to false, too, with the expected effect. For b) it turns out there is no easy way of having a framework classes expose only certain methods/properties by for example passing only an interface to Python. That just doesn't work because Python will allow access to any public member of the concrete instance. One way around that would be to write adapter for each framework class (like: for class Player create class PythonPlayer which holds an instance of Player as private member and exposes only those members publicly that should be visible from Python), but that would be tedious. So I created another patch (Attributes and ReflectedType) which adds a new attribute [DoNotExpose] to IronPython. Framework code writers can decorate properties, methods, fields, nested types etc. with this attribute. Members decorated such won't be visible to Python code. Again, by default behavior is not changed as no code has this attribute. With c) I am stuck. I'm not at all sure where I could add such functionality with minimum impact to the existing codebase. Any ideas on that? Besides, any feedback to the patches would be most welcome, too. Happy Easter holidays, Max Hajek Vienna -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joss.Burnett at livedrive.com Fri Apr 13 09:41:28 2007 From: Joss.Burnett at livedrive.com (Joss Burnett) Date: Fri, 13 Apr 2007 08:41:28 +0100 Subject: [IronPython] Problem importing standard libraries Message-ID: I am very new to Python and IronPython, so my apologies if this is a very dumb question: I have been trying to import the standard Python libraries and having some issues (apparently with module dependancies), for example: If my Site.py file is set up as follows: import sys sys.path.append(r"c:\Python24\Lib") and I import the "os" module, import os It appears to work correctly, but certain functions do not appear to have the correct dependancies loaded (e.g. when using any of the "exec" routines I receive the following message "NameError: name 'execv' not defined" ). Also, packages installed in the site-packages directory cannot be directly loaded as they can via "normal" python. I am pretty sure I have set something up incorrectly and if someone could point me in the right direction I'd really appreciate it. Joss Burnett LiveDrive.Com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh at defuze.org Fri Apr 13 09:58:51 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Fri, 13 Apr 2007 08:58:51 +0100 Subject: [IronPython] Problem importing standard libraries In-Reply-To: References: Message-ID: <461F383B.2020503@defuze.org> I was wondering if you were using IPCE or a vanilla IP? http://fepy.sourceforge.net/ Look notably at fepy's options: http://fepy.sourceforge.net/doc/fepy-options.html - Sylvain Joss Burnett wrote: > I am very new to Python and IronPython, so my apologies if this is a > very dumb question: > > > > I have been trying to import the standard Python libraries and having > some issues (apparently with module dependancies), for example: > > > > If my Site.py file is set up as follows: > > > > import sys > > > > sys.path.append(r"c:\Python24\Lib") > > > > and I import the "os" module, > > > > import os > > > > It appears to work correctly, but certain functions do not appear to > have the correct dependancies loaded (e.g. when using any of the "exec" > routines I receive the following message "NameError: name 'execv' not > defined" ). > > > > Also, packages installed in the site-packages directory cannot be > directly loaded as they can via "normal" python. I am pretty sure I have > set something up incorrectly and if someone could point me in the right > direction I'd really appreciate it. > > > > Joss Burnett > > LiveDrive.Com > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From Joss.Burnett at livedrive.com Fri Apr 13 10:14:03 2007 From: Joss.Burnett at livedrive.com (Joss Burnett) Date: Fri, 13 Apr 2007 09:14:03 +0100 Subject: [IronPython] Problem importing standard libraries References: <461F383B.2020503@defuze.org> Message-ID: Hi Sylvain, I am using the version of IronPython from: http://www.codeplex.com/IronPython "IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved." I have not seen the FePy version before but I will take a look. Thanks Joss -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch Sent: 13 April 2007 08:59 To: Discussion of IronPython Subject: Re: [IronPython] Problem importing standard libraries I was wondering if you were using IPCE or a vanilla IP? http://fepy.sourceforge.net/ Look notably at fepy's options: http://fepy.sourceforge.net/doc/fepy-options.html - Sylvain Joss Burnett wrote: > I am very new to Python and IronPython, so my apologies if this is a > very dumb question: > > > > I have been trying to import the standard Python libraries and having > some issues (apparently with module dependancies), for example: > > > > If my Site.py file is set up as follows: > > > > import sys > > > > sys.path.append(r"c:\Python24\Lib") > > > > and I import the "os" module, > > > > import os > > > > It appears to work correctly, but certain functions do not appear to > have the correct dependancies loaded (e.g. when using any of the "exec" > routines I receive the following message "NameError: name 'execv' not > defined" ). > > > > Also, packages installed in the site-packages directory cannot be > directly loaded as they can via "normal" python. I am pretty sure I have > set something up incorrectly and if someone could point me in the right > direction I'd really appreciate it. > > > > Joss Burnett > > LiveDrive.Com > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sh at defuze.org Fri Apr 13 10:30:05 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Fri, 13 Apr 2007 09:30:05 +0100 Subject: [IronPython] Problem importing standard libraries In-Reply-To: References: <461F383B.2020503@defuze.org> Message-ID: <461F3F8D.8080502@defuze.org> Joss Burnett wrote: > Hi Sylvain, > > I am using the version of IronPython from: > http://www.codeplex.com/IronPython > > "IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 > Copyright (c) Microsoft Corporation. All rights reserved." > > I have not seen the FePy version before but I will take a look. > You should indeed because it contains quite a few improvements to get the stdlib and other third-party Python packages to work with IP. You can grab IPCEr5 which contains IP1a1 IIRC. But you should be able to drop the latest IP binaries in the folder and it would work the same. - Sylvain From ctrachte at gmail.com Sat Apr 14 05:38:26 2007 From: ctrachte at gmail.com (ctrachte at gmail.com) Date: Sat, 14 Apr 2007 03:38:26 -0000 Subject: [IronPython] style question - site.py Message-ID: <1176521906.655183.64820@n76g2000hsh.googlegroups.com> Hello. This is my first attempt at a post. I am an IronPython newb. The distro I'm using is the Microsoft one. I am on Windows XP. Which is most correct and why? A) >>> site.clr.AddReference() B) >>> import clr. >>> clr.AddReference C) neither Thanks a ton. Carl T. From sanxiyn at gmail.com Sat Apr 14 05:44:02 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sat, 14 Apr 2007 12:44:02 +0900 Subject: [IronPython] style question - site.py In-Reply-To: <1176521906.655183.64820@n76g2000hsh.googlegroups.com> References: <1176521906.655183.64820@n76g2000hsh.googlegroups.com> Message-ID: <5b0248170704132044q33e263bdu879b1ab339b0dff0@mail.gmail.com> 2007/4/14, ctrachte at gmail.com : > Which is most correct and why? > > A) >>> site.clr.AddReference() > B) >>> import clr. > >>> clr.AddReference > C) neither B is correct. Well, I can't articulate exactly why, but A just looks wrong. -- Seo Sanghyeon From ctrachte at gmail.com Sat Apr 14 06:24:24 2007 From: ctrachte at gmail.com (Carl Trachte) Date: Fri, 13 Apr 2007 21:24:24 -0700 Subject: [IronPython] style question - site.py In-Reply-To: <5b0248170704132044q33e263bdu879b1ab339b0dff0@mail.gmail.com> References: <1176521906.655183.64820@n76g2000hsh.googlegroups.com> <5b0248170704132044q33e263bdu879b1ab339b0dff0@mail.gmail.com> Message-ID: <426ada670704132124o1faa9617x6e90993eb8a0037@mail.gmail.com> > Which is most correct and why? > > > > A) >>> site.clr.AddReference() > > B) >>> import clr. > > >>> clr.AddReference > > C) neither > > B is correct. > > Well, I can't articulate exactly why, but A just looks wrong. > > Works for me. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thane at tkpcorp.com Sat Apr 14 20:18:47 2007 From: thane at tkpcorp.com (Thane Plummer) Date: Sat, 14 Apr 2007 14:18:47 -0400 Subject: [IronPython] style question - site.py In-Reply-To: <5b0248170704132044q33e263bdu879b1ab339b0dff0@mail.gmail.com> Message-ID: <001a01c77ec1$5856a610$6603a8c0@Dell9150> One problem with A) lies in the ambiguity of the contents of site.py -- portability issues could be large. Also, remember that site.py was implemented as a solution to give IronPython access to the standard libs. This may change at some point and solution A) could be deprecated. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Friday, April 13, 2007 11:44 PM To: Discussion of IronPython Subject: Re: [IronPython] style question - site.py 2007/4/14, ctrachte at gmail.com : > Which is most correct and why? > > A) >>> site.clr.AddReference() > B) >>> import clr. > >>> clr.AddReference > C) neither B is correct. Well, I can't articulate exactly why, but A just looks wrong. -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From ctrachte at gmail.com Sat Apr 14 23:02:33 2007 From: ctrachte at gmail.com (Carl Trachte) Date: Sat, 14 Apr 2007 14:02:33 -0700 Subject: [IronPython] style question - site.py In-Reply-To: <001a01c77ec1$5856a610$6603a8c0@Dell9150> References: <5b0248170704132044q33e263bdu879b1ab339b0dff0@mail.gmail.com> <001a01c77ec1$5856a610$6603a8c0@Dell9150> Message-ID: <426ada670704141402j5385b294n2cfc399ad263dcfc@mail.gmail.com> On 4/14/07, Thane Plummer wrote: > > One problem with A) lies in the ambiguity of the contents of site.py -- > portability issues could be large. Also, remember that site.py was > implemented as a solution to give IronPython access to the standard libs. > This may change at some point and solution A) could be deprecated. This makes sense. It was a real newb question; the idea of importing > something twice under different names (clr) made me wonder, and that's why I > asked. Plus, I'm trying to get my arms around the whole dotNet thing. The > automatically generated code out of Visual Studio for C# and VB.NET can be > pretty ornate - things aren't always intuitive from the code. Again, thanks. 2007/4/14, ctrachte at gmail.com : > > Which is most correct and why? > > > > A) >>> site.clr.AddReference() > > B) >>> import clr. > > >>> clr.AddReference > > C) neither > > B is correct. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.hajek at teamvienna.at Mon Apr 16 12:36:51 2007 From: markus.hajek at teamvienna.at (Markus Hajek) Date: Mon, 16 Apr 2007 12:36:51 +0200 Subject: [IronPython] Callback per statement Message-ID: <002e01c78013$2633ee60$729bcb20$@hajek@teamvienna.at> Hi, is there a way to execute a callback whenever a Python statement is about to be executed (or just has executed)? With Python statements, I mean method calls, operators, assignments. And if there's no such way, how would I have to go about changing code generation to facilitate that? Many thanks, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Maly at microsoft.com Mon Apr 16 20:12:33 2007 From: Martin.Maly at microsoft.com (Martin Maly) Date: Mon, 16 Apr 2007 11:12:33 -0700 Subject: [IronPython] Callback per statement In-Reply-To: <002e01c78013$2633ee60$729bcb20$@hajek@teamvienna.at> References: <002e01c78013$2633ee60$729bcb20$@hajek@teamvienna.at> Message-ID: It is not possible to do this without change to code generation at this point. Essentially you could do something like this: public class MyCallbackClass { public void MyCallback() { // } } And then emit call to this utility wherever you like: cg.EmitCall(typeof(MyCallbackClass).GetMethod("MyCallback")) You can then control the granularity at which you call this. Per statement, or even per expression (I am a bit confused about your mention of operators below, whether you want to do this for each expression, but it is certainly possible as well). For starters, what you could easily do to get feel for things would be to modify SuiteStatement's Emit method (which only loops through enclosed statements and emits each of them) and add the above "cg.EmitCall" for each statement, run your repro, say: X = 1 X = 2 X = 3 And put breakpoint in the "MyCallback", or better yet, run the repro: Ipy.exe -X:SaveAssemblies x.py And examine the x.exe we'll generate with ildasm or reflector. Then you can add calls to your callbacks wherever desired. Hope this helps Martin From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Markus Hajek Sent: Monday, April 16, 2007 3:37 AM To: 'Discussion of IronPython' Subject: [IronPython] Callback per statement Hi, is there a way to execute a callback whenever a Python statement is about to be executed (or just has executed)? With Python statements, I mean method calls, operators, assignments. And if there's no such way, how would I have to go about changing code generation to facilitate that? Many thanks, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Tue Apr 17 00:11:46 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 16 Apr 2007 23:11:46 +0100 Subject: [IronPython] Application Domains and IronPython Message-ID: <4623F4A2.6020403@voidspace.org.uk> Hello all, I'm trying to experiment with using AppDomains from IronPython - and not getting very far. I've created a simple assembly in C#, containing the following : using System; namespace goodbye { public class GoodbyeWorld { public void test() { Console.WriteLine("Goodbye World!"); } } } This is saved as 'goodbye.dll' and I can use it fine from IronPython. The initial code to create the AppDomain is as follows: import clr from System import AppDomain, AppDomainSetup, MarshalByRefObject from System.Environment import CurrentDirectory from System.IO import Path, Directory from System.Reflection import Assembly ads = AppDomainSetup() ads.ApplicationBase = Directory.GetCurrentDirectory() ads.DisallowBindingRedirects = False ads.DisallowCodeDownload = True ads.ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile appDomain = AppDomain.CreateDomain("newAppDomain", None, ads) asmPath = Path.Combine(Directory.GetCurrentDirectory(), "goodbye.dll") So far so good. If I try *either* of the following lines to *use* the appdomain, then it fails: testClass = appDomain.CreateInstanceAndUnwrap(asmPath, "goodbye.GoodbyeWorld") or: appDomain.Load(asmPath) The error is: Traceback (most recent call last): File C:\Python Projects\modules in progress\ironpython\appDomain.py, line 22, in Initialize File , line 0, in Load##97 File mscorlib, line unknown, in Load IOError: Could not load file or assembly 'C:\\Python Projects\\modules in progre ss\\ironpython\\goodbye.dll' or one of its dependencies. The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047) I've also tried loading the assembly and using the assembly name, which is obviously wrong because it then fails to find the assembly. Anyone got any clues as to what I am doing wrong ? All the best, Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml From markus.hajek at teamvienna.at Tue Apr 17 08:37:52 2007 From: markus.hajek at teamvienna.at (Markus Hajek) Date: Tue, 17 Apr 2007 08:37:52 +0200 Subject: [IronPython] Callback per statement In-Reply-To: References: <002e01c78013$2633ee60$729bcb20$@hajek@teamvienna.at> Message-ID: <000a01c780ba$ee1a1e70$ca4e5b50$@hajek@teamvienna.at> Thanks a million, I'll start experimenting with that right away. Looks just exactly like what I need, thanks again. Cheers, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Martin Maly Gesendet: Montag, 16. April 2007 20:13 An: Discussion of IronPython Betreff: Re: [IronPython] Callback per statement It is not possible to do this without change to code generation at this point. Essentially you could do something like this: public class MyCallbackClass { public void MyCallback() { // } } And then emit call to this utility wherever you like: cg.EmitCall(typeof(MyCallbackClass).GetMethod("MyCallback")) You can then control the granularity at which you call this. Per statement, or even per expression (I am a bit confused about your mention of operators below, whether you want to do this for each expression, but it is certainly possible as well). For starters, what you could easily do to get feel for things would be to modify SuiteStatement's Emit method (which only loops through enclosed statements and emits each of them) and add the above "cg.EmitCall" for each statement, run your repro, say: X = 1 X = 2 X = 3 And put breakpoint in the "MyCallback", or better yet, run the repro: Ipy.exe -X:SaveAssemblies x.py And examine the x.exe we'll generate with ildasm or reflector. Then you can add calls to your callbacks wherever desired. Hope this helps Martin From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Markus Hajek Sent: Monday, April 16, 2007 3:37 AM To: 'Discussion of IronPython' Subject: [IronPython] Callback per statement Hi, is there a way to execute a callback whenever a Python statement is about to be executed (or just has executed)? With Python statements, I mean method calls, operators, assignments. And if there's no such way, how would I have to go about changing code generation to facilitate that? Many thanks, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.hajek at teamvienna.at Tue Apr 17 08:54:32 2007 From: markus.hajek at teamvienna.at (Markus Hajek) Date: Tue, 17 Apr 2007 08:54:32 +0200 Subject: [IronPython] Callback per statement In-Reply-To: <000a01c780ba$ee1a1e70$ca4e5b50$@hajek@teamvienna.at> References: <002e01c78013$2633ee60$729bcb20$@hajek@teamvienna.at> <000a01c780ba$ee1a1e70$ca4e5b50$@hajek@teamvienna.at> Message-ID: <000001c780bd$41babd80$c5303880$@hajek@teamvienna.at> One more question: I want to use this callback to abort python execution in certain cases. I'm currently thinking the best way to go about this would be to throw an exception in the callback I hook up. About like: public static class PythonCallback { public static void Callback() { If (pythonAbortionDesired) Throw new PythonAbortionException(); } } //. try { engine.ExecuteFile("SomePythonFile.py"); } catch (PythonAbortionException) { // do whatever I wanna do when Python execution has aborted } What do you think of this? Is there any better alternative? Many thanks again, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Markus Hajek Gesendet: Dienstag, 17. April 2007 08:38 An: 'Discussion of IronPython' Betreff: Re: [IronPython] Callback per statement Thanks a million, I'll start experimenting with that right away. Looks just exactly like what I need, thanks again. Cheers, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Martin Maly Gesendet: Montag, 16. April 2007 20:13 An: Discussion of IronPython Betreff: Re: [IronPython] Callback per statement It is not possible to do this without change to code generation at this point. Essentially you could do something like this: public class MyCallbackClass { public void MyCallback() { // } } And then emit call to this utility wherever you like: cg.EmitCall(typeof(MyCallbackClass).GetMethod("MyCallback")) You can then control the granularity at which you call this. Per statement, or even per expression (I am a bit confused about your mention of operators below, whether you want to do this for each expression, but it is certainly possible as well). For starters, what you could easily do to get feel for things would be to modify SuiteStatement's Emit method (which only loops through enclosed statements and emits each of them) and add the above "cg.EmitCall" for each statement, run your repro, say: X = 1 X = 2 X = 3 And put breakpoint in the "MyCallback", or better yet, run the repro: Ipy.exe -X:SaveAssemblies x.py And examine the x.exe we'll generate with ildasm or reflector. Then you can add calls to your callbacks wherever desired. Hope this helps Martin From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Markus Hajek Sent: Monday, April 16, 2007 3:37 AM To: 'Discussion of IronPython' Subject: [IronPython] Callback per statement Hi, is there a way to execute a callback whenever a Python statement is about to be executed (or just has executed)? With Python statements, I mean method calls, operators, assignments. And if there's no such way, how would I have to go about changing code generation to facilitate that? Many thanks, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Maly at microsoft.com Tue Apr 17 09:11:13 2007 From: Martin.Maly at microsoft.com (Martin Maly) Date: Tue, 17 Apr 2007 00:11:13 -0700 Subject: [IronPython] Callback per statement In-Reply-To: <000001c780bd$41babd80$c5303880$@hajek@teamvienna.at> References: <002e01c78013$2633ee60$729bcb20$@hajek@teamvienna.at> <000a01c780ba$ee1a1e70$ca4e5b50$@hajek@teamvienna.at> <000001c780bd$41babd80$c5303880$@hajek@teamvienna.at> Message-ID: I think this may work pretty well. Something worth thinking through would be to what degree can user make your life complicated by catching exceptions. Once you throw your exception, the user can actually catch it (or you can modify codegen to filter your special exceptions out so user cannot catch them), but at the same time, to do that, user has to execute a statement (or in this case the except clause of the try statement) which would end up throwing the exception again as the time quantum for the script expired. The only danger I can see is if there is an exception handler on the stack which you don't control (such as a call into .NET) User can catch anything there and never give you control back. I can only think of explicit monitor thread and forced termination of the runaway thread as a protection against such misbehavior... Martin From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Markus Hajek Sent: Monday, April 16, 2007 11:55 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] Callback per statement One more question: I want to use this callback to abort python execution in certain cases. I'm currently thinking the best way to go about this would be to throw an exception in the callback I hook up. About like: public static class PythonCallback { public static void Callback() { If (pythonAbortionDesired) Throw new PythonAbortionException(); } } //... try { engine.ExecuteFile("SomePythonFile.py"); } catch (PythonAbortionException) { // do whatever I wanna do when Python execution has aborted } What do you think of this? Is there any better alternative? Many thanks again, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Markus Hajek Gesendet: Dienstag, 17. April 2007 08:38 An: 'Discussion of IronPython' Betreff: Re: [IronPython] Callback per statement Thanks a million, I'll start experimenting with that right away. Looks just exactly like what I need, thanks again. Cheers, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Martin Maly Gesendet: Montag, 16. April 2007 20:13 An: Discussion of IronPython Betreff: Re: [IronPython] Callback per statement It is not possible to do this without change to code generation at this point. Essentially you could do something like this: public class MyCallbackClass { public void MyCallback() { // } } And then emit call to this utility wherever you like: cg.EmitCall(typeof(MyCallbackClass).GetMethod("MyCallback")) You can then control the granularity at which you call this. Per statement, or even per expression (I am a bit confused about your mention of operators below, whether you want to do this for each expression, but it is certainly possible as well). For starters, what you could easily do to get feel for things would be to modify SuiteStatement's Emit method (which only loops through enclosed statements and emits each of them) and add the above "cg.EmitCall" for each statement, run your repro, say: X = 1 X = 2 X = 3 And put breakpoint in the "MyCallback", or better yet, run the repro: Ipy.exe -X:SaveAssemblies x.py And examine the x.exe we'll generate with ildasm or reflector. Then you can add calls to your callbacks wherever desired. Hope this helps Martin From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Markus Hajek Sent: Monday, April 16, 2007 3:37 AM To: 'Discussion of IronPython' Subject: [IronPython] Callback per statement Hi, is there a way to execute a callback whenever a Python statement is about to be executed (or just has executed)? With Python statements, I mean method calls, operators, assignments. And if there's no such way, how would I have to go about changing code generation to facilitate that? Many thanks, Markus Hajek Team Vienna - Kazemi, Hajek & Pisarik OG -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickl at volition-inc.com Mon Apr 16 23:53:58 2007 From: nickl at volition-inc.com (xenarcher) Date: Mon, 16 Apr 2007 14:53:58 -0700 (PDT) Subject: [IronPython] Extending/Embedding IronPython using C++ Message-ID: <10025430.post@talk.nabble.com> Apologies if this has been asked before... Is there a way to extend and/or embed IronPython using C/C++? The tutorial that comes with the IronPython installation talks about C# and Visual Basic, but says nothing about C/C++. -- View this message in context: http://www.nabble.com/Extending-Embedding-IronPython-using-C%2B%2B-tf3587469.html#a10025430 Sent from the IronPython mailing list archive at Nabble.com. From dinov at exchange.microsoft.com Tue Apr 17 23:43:38 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 17 Apr 2007 14:43:38 -0700 Subject: [IronPython] IronPython v1.1 Released! Message-ID: <7AD436E4270DD54A94238001769C22278A27154FCC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Hello IronPython Community, We have just released IronPython 1.1. It started out as the work on v1.0 started to wind down. We could not get the features ready before we started locking down for the v1.0 release but we're happy we can finally include them - as will be our summer interns who worked on some of these features and many of the modules during their stay with us. After that we have been looking at the most requested bug fixes and new features from the community. Based upon this feedback we've fixed a large number of bugs, greatly improved compatibility of some of the built-in modules, and a few other new features such as XML doc comments and the array module. IronPython v1.1 is a minor update to IronPython including both new functionality as fixes for the most voted for bugs. The new functionality in v1.1 includes several new modules (array, SHA, MD5, and select), support for .NET XML Doc comments within the help system and doc tags, as well as support for loading cached pre-compiled modules. This release improves compatibility with CPython and gives the .NET developer a better interactive experience. You can download the release from: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=2573 We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: Arman0, Anthony Baxter, Christopher Baus, Christian Muirhead, Coleyc, Diane Trout, Doubleyewdee, Eloff, J. Merrill, JoeSox, J?rgen Stenarson, Michael Foord, Mike Raath, Py_Sunil, Seo Sanghyeon, Sylvain Hellegouarch, sophros, Tarlano, and Whit537. More complete list of changes and bug fixes: ============================================ CodePlex bug #1216: ironpython shows different error msgs when we use cpython's os module CodePlex bug #1403 int.dict0=0 CodePlex bug #2704 import and packages aren't mixing well CodePlex bug #5083 operator.contains is broken CodePlex bug #5445 socket.getaddrinfo(...) does not throw on nonsense parameters CodePlex bug #5446 socket.getaddrinfo(...) proto parameter CodePlex bug #5566 base64 slash bug CodePlex bug #5609 (Py2.5) File lacks enter and exit CodePlex bug #5641 co_name in code objects is None CodePlex bug #5712 iterating over main.dict throws CodePlex bug #5904 Multi-line dictionary expressions in IP interpreter console not compatible w/ CPython Interpreter console CodePlex bug #6010 UnicodeErrorInit sets @object instead of object CodePlex bug #6142 Setting func_name on function doesn't show up in name CodePlex bug #6265 maxsplit keyword arg of re.split not accepted CodePlex bug #6704 globals().fromkeys(...) broken CodePlex bug #6706 globals().Values enumerator broken CodePlex bug #6735 help incorrectly displays arguments for params functions CodePlex bug #6805 funccode.coargcount and funccode.coflags are wrong CodePlex bug #7532 func_defaults is empty tuple when there are no defaults CodePlex bug #7982 ^L yields SyntaxError CodePlex bug #7827 IronPython thread module does not implement stack_size CodePlex bug #7828 IronPython lock type does not support context manager methods Support importing pre-compiled modules produced when running in -X:SaveAssemblies mode Enable inheritance of static op_Implicit implicit conversion operators on .NET types Fixed tracebacks when catching exceptions in the method that threw them and a few other fixes here Bugfix: 4859 datetime.date.str broken Bugfix: 4870 datetime.datetime.isoformat does not report microseconds Bugfix: 5148 datetime.time(..., None).tzname() returns '' instead of None Bugfix: Bugfix: 5146 datetime.time(...).isoformat() does not work Bugfix: 4860 datetime.datetime.* only accurate to 1000 microseconds Bugfix: 3850 datetime.datetime(...) allows negative microsecond parameter Bugfix: 5147 datetime.time(..., None).utcoffset() returns 0 instead of None Bugfix: 5145 datetime.time.resolution is the wrong type Bugfix: 5143 datetime.time(...) allows parameters < time.min and > time.max Bugfix: 5139 datetime.timedelta and datetime.time objects should work correctly in boolean contexts Bugfix: 5133 datetime.timedelta.* does not normalize negative parameters and return values Bugfix: 5132 datetime.timedelta(...) constructor does not round off floating point parameters correctly Bugfix: 4871 datetime.timedelta.init does not accept the 4 optional keyword parameters Bugfix: 4868 datetime.datetime.timetuple returns an incorrect value Bugfix: 4867 datetime.datetime.tzname returns incorrect value if tzinfo member is None Bugfix: 4866 datetime.datetime.resolution is of the wrong type Bugfix: 4865 datetime.datetime.cmp broken for datetime.datetime.max Bugfix: 4864 datetime.datetime.max has the wrong value for the microsecond member Bugfix: 4863 datetime.datetime.init(...) defaults the hour keyword param to 1 (should be 0) Bugfix: 4861 datetime.timedelta + datetime.datetime throws a TypeError Bugfix: 3990 datetime.timedelta member attributes out of range Bugfix: 5149 datetime.timdelta(...) does not add fractional microseconds correctly Bugfix: 5136 datetime.timedelta.min(imum), datetime.timedelta.max(imum), and datetime.timedelta.resolution all have incorrect values Bugfix: 5135 datetime.timedelta.min and datetime.timedelta.max are missing Bugfix: 4858 datetime.date.reduce broken Bugfix 7426: in operator doesn't check for overloaded contains on dictionary Implemented array module Bugfix: KeyboardInterrupt propagates after except block that catches it Bugfix: Compiled regex gets different results for findall then non-compiled Bugfix: regex match doesn't implement lastgroup Bugfix: Import in exec doesn't publish into provided dictionary Bugfix: Lacking file open() modes (at, rt, etc...) Bugfix: PythonBinaryReader shouldn't access Position if stream isn't seekable Bugfix: Cannot pass arbitrary sequence to method defined w/ both * and ** args Bugfix: rb+ mode on file not implemented Bugfix: improved thread safety of dictionaries Bugfix: KeyError from dict adds quotes (and doesn't contain original key, only string repr) Bugfix: del {None:23} raises a TypeError Support for external region blocks when producing errors Bugfix: line number information in VS SDK is incorrect for web projects Support for Python 2.5 unified try/except/finally Support for Python 2.5 yield from finally block help supports documentation on reflected fields, properties, and events Support for XML Doc comments (requires XML files to live next to DLLs) for help and doc Nt module implements spawnle, spawnv, spawnve functions Socket implements makefile function Support for picking exception instances Fix issue with metaclass & deriving from mixed new-style / old-style classes Implement select module Implement sha module Implement md5 module Add new tests for codecs and CLR numeric interop From dinov at exchange.microsoft.com Tue Apr 17 23:56:44 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 17 Apr 2007 14:56:44 -0700 Subject: [IronPython] Application Domains and IronPython In-Reply-To: <4623F4A2.6020403@voidspace.org.uk> References: <4623F4A2.6020403@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C22278A27154FEB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> For the call to .Load I think you'll want to provide "goodbye" instead of the fully qualified path. If that still doesn't work there's a tool called fuslogvw.exe which is part of the .NET Framework SDK (on my machine it's in %ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin but if you don't have VS and instead just have the SDK I believe it ends up in %ProgramFiles%\Microsoft.NET\SDK\...). Load that up, turn on the logging options, and then re-run. Refresh in Fuslogvw and you'll see a list of places where it tried to load your assembly from and where it's not finding them. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, April 16, 2007 3:12 PM To: Discussion of IronPython Subject: [IronPython] Application Domains and IronPython Hello all, I'm trying to experiment with using AppDomains from IronPython - and not getting very far. I've created a simple assembly in C#, containing the following : using System; namespace goodbye { public class GoodbyeWorld { public void test() { Console.WriteLine("Goodbye World!"); } } } This is saved as 'goodbye.dll' and I can use it fine from IronPython. The initial code to create the AppDomain is as follows: import clr from System import AppDomain, AppDomainSetup, MarshalByRefObject from System.Environment import CurrentDirectory from System.IO import Path, Directory from System.Reflection import Assembly ads = AppDomainSetup() ads.ApplicationBase = Directory.GetCurrentDirectory() ads.DisallowBindingRedirects = False ads.DisallowCodeDownload = True ads.ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile appDomain = AppDomain.CreateDomain("newAppDomain", None, ads) asmPath = Path.Combine(Directory.GetCurrentDirectory(), "goodbye.dll") So far so good. If I try *either* of the following lines to *use* the appdomain, then it fails: testClass = appDomain.CreateInstanceAndUnwrap(asmPath, "goodbye.GoodbyeWorld") or: appDomain.Load(asmPath) The error is: Traceback (most recent call last): File C:\Python Projects\modules in progress\ironpython\appDomain.py, line 22, in Initialize File , line 0, in Load##97 File mscorlib, line unknown, in Load IOError: Could not load file or assembly 'C:\\Python Projects\\modules in progre ss\\ironpython\\goodbye.dll' or one of its dependencies. The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047) I've also tried loading the assembly and using the assembly name, which is obviously wrong because it then fails to find the assembly. Anyone got any clues as to what I am doing wrong ? All the best, Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Wed Apr 18 00:34:46 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 17 Apr 2007 23:34:46 +0100 Subject: [IronPython] Application Domains and IronPython In-Reply-To: <7AD436E4270DD54A94238001769C22278A27154FEB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <4623F4A2.6020403@voidspace.org.uk> <7AD436E4270DD54A94238001769C22278A27154FEB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <46254B86.1000304@voidspace.org.uk> Dino Viehland wrote: > For the call to .Load I think you'll want to provide "goodbye" instead of the fully qualified path. > > If that still doesn't work there's a tool called fuslogvw.exe which is part of the .NET Framework SDK (on my machine it's in %ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin but if you don't have VS and instead just have the SDK I believe it ends up in %ProgramFiles%\Microsoft.NET\SDK\...). Load that up, turn on the logging options, and then re-run. Refresh in Fuslogvw and you'll see a list of places where it tried to load your assembly from and where it's not finding them. > Thanks for the reply Dino - and nice work on IP 1.1. :-) I'm sure I tried just 'goodbye', but that tool for tracing what is going on sounds like a great idea. Thanks Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, April 16, 2007 3:12 PM > To: Discussion of IronPython > Subject: [IronPython] Application Domains and IronPython > > Hello all, > > I'm trying to experiment with using AppDomains from IronPython - and not > getting very far. > > I've created a simple assembly in C#, containing the following : > > using System; > namespace goodbye > { > public class GoodbyeWorld > > { > public void test() > > { > Console.WriteLine("Goodbye World!"); > } > } > } > > > This is saved as 'goodbye.dll' and I can use it fine from IronPython. > > The initial code to create the AppDomain is as follows: > > import clr > > from System import AppDomain, AppDomainSetup, MarshalByRefObject > from System.Environment import CurrentDirectory > from System.IO import Path, Directory > from System.Reflection import Assembly > > > ads = AppDomainSetup() > ads.ApplicationBase = Directory.GetCurrentDirectory() > ads.DisallowBindingRedirects = False > ads.DisallowCodeDownload = True > ads.ConfigurationFile = > AppDomain.CurrentDomain.SetupInformation.ConfigurationFile > > > appDomain = AppDomain.CreateDomain("newAppDomain", None, ads) > > > asmPath = Path.Combine(Directory.GetCurrentDirectory(), "goodbye.dll") > > So far so good. > > If I try *either* of the following lines to *use* the appdomain, then it > fails: > > testClass = appDomain.CreateInstanceAndUnwrap(asmPath, > "goodbye.GoodbyeWorld") > > or: > > appDomain.Load(asmPath) > > > The error is: > > > Traceback (most recent call last): > File C:\Python Projects\modules in progress\ironpython\appDomain.py, > line 22, > in Initialize > File , line 0, in Load##97 > File mscorlib, line unknown, in Load > IOError: Could not load file or assembly 'C:\\Python Projects\\modules > in progre > ss\\ironpython\\goodbye.dll' or one of its dependencies. The given > assembly name > or codebase was invalid. (Exception from HRESULT: 0x80131047) > > I've also tried loading the assembly and using the assembly name, which > is obviously wrong because it then fails to find the assembly. > > Anyone got any clues as to what I am doing wrong ? > > All the best, > > > Fuzzyman > http://www.voidspace.org.uk/ironpython/index.shtml > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From davidjensen at usa.net Wed Apr 18 02:22:23 2007 From: davidjensen at usa.net (David Jensen) Date: Tue, 17 Apr 2007 20:22:23 -0400 Subject: [IronPython] import os Message-ID: <589LDRaVX9170S07.1176855743@cmsweb07.cms.usa.net> This is a very simple and obvious question. However, I am puzzled. I cannot do "import os" in ipy 1.0 or 1.1. Apparently, I have to import it from cpython according to codeplex? When I try importing ftplib, it says there is no os module. Why was an import of the os module not implemented? It would seem there would be numerous modules dependent on it. I am using an ironpython1.1 folder which I carry with me on a usb drive. I did not "install" it on a local machine, although I did think I would have to because I can carry the regular python 2.4 on the usb drive. I cannot find ironpython documents or commentaries which mention the apparent inability to import the os module. David Jensen Apartment 412 414 West 120th Street New York, New York 10027 212-866-7094 646-245-2654 (cell) 206-984-4900 (fax to email) davidjensen at usa.net From fuzzyman at voidspace.org.uk Wed Apr 18 02:38:20 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 18 Apr 2007 01:38:20 +0100 Subject: [IronPython] import os In-Reply-To: <589LDRaVX9170S07.1176855743@cmsweb07.cms.usa.net> References: <589LDRaVX9170S07.1176855743@cmsweb07.cms.usa.net> Message-ID: <4625687C.5060500@voidspace.org.uk> David Jensen wrote: > This is a very simple and obvious question. However, I am puzzled. I cannot do > "import os" in ipy 1.0 or 1.1. Apparently, I have to import it from cpython > according to codeplex? When I try importing ftplib, it says there is no os > module. Why was an import of the os module not implemented? It would seem > there would be numerous modules dependent on it. I am using an ironpython1.1 > folder which I carry with me on a usb drive. I did not "install" it on a local > machine, although I did think I would have to because I can carry the regular > python 2.4 on the usb drive. I cannot find ironpython documents or > commentaries which mention the apparent inability to import the os module. > > 'os' is a Python standard library module. You can copy the Python 2.4 standard library onto your USB key and add that directory to 'sys.path' in your script. With the standard library on the path, import os will work fine. Michael http://www.voidspace.org.uk/ironpython/index.shtml > David Jensen > Apartment 412 > 414 West 120th Street > New York, New York 10027 > 212-866-7094 > 646-245-2654 (cell) > 206-984-4900 (fax to email) > davidjensen at usa.net > > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From dinov at exchange.microsoft.com Wed Apr 18 02:39:48 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 17 Apr 2007 17:39:48 -0700 Subject: [IronPython] import os In-Reply-To: <589LDRaVX9170S07.1176855743@cmsweb07.cms.usa.net> References: <589LDRaVX9170S07.1176855743@cmsweb07.cms.usa.net> Message-ID: <7AD436E4270DD54A94238001769C22278A27155121@DF-GRTDANE-MSG.exchange.corp.microsoft.com> We don't ship the Python standard libraries (written in Python) w/ IronPython and os is part of the standard libraries. IronPython just implements the built-in libraries which those standard libraries build upon. The easiest way to solve this for you would be to copy the contents of the Lib directory below CPython on your USB drive to the Lib directory in the IronPython folder. Alternately you can set the environment variable IRONPYTHONPATH to point to the lib directory below CPython. Once you do that import os should work. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David Jensen Sent: Tuesday, April 17, 2007 5:22 PM To: users at lists.ironpython.com Subject: [IronPython] import os This is a very simple and obvious question. However, I am puzzled. I cannot do "import os" in ipy 1.0 or 1.1. Apparently, I have to import it from cpython according to codeplex? When I try importing ftplib, it says there is no os module. Why was an import of the os module not implemented? It would seem there would be numerous modules dependent on it. I am using an ironpython1.1 folder which I carry with me on a usb drive. I did not "install" it on a local machine, although I did think I would have to because I can carry the regular python 2.4 on the usb drive. I cannot find ironpython documents or commentaries which mention the apparent inability to import the os module. David Jensen Apartment 412 414 West 120th Street New York, New York 10027 212-866-7094 646-245-2654 (cell) 206-984-4900 (fax to email) davidjensen at usa.net _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Wed Apr 18 21:39:46 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 18 Apr 2007 12:39:46 -0700 Subject: [IronPython] IronPython v1.1 Released! Message-ID: <7AD436E4270DD54A94238001769C22278A271553BF@DF-GRTDANE-MSG.exchange.corp.microsoft.com> It seems like some people didn't get this announcement sent to them (including myself) so I'm re-sending it in case there was a hiccup w/ our mailing list server. -----Original Message----- From: Dino Viehland Sent: Tuesday, April 17, 2007 2:44 PM To: Discussion of IronPython Subject: IronPython v1.1 Released! Hello IronPython Community, We have just released IronPython 1.1. It started out as the work on v1.0 started to wind down. We could not get the features ready before we started locking down for the v1.0 release but we're happy we can finally include them - as will be our summer interns who worked on some of these features and many of the modules during their stay with us. After that we have been looking at the most requested bug fixes and new features from the community. Based upon this feedback we've fixed a large number of bugs, greatly improved compatibility of some of the built-in modules, and a few other new features such as XML doc comments and the array module. IronPython v1.1 is a minor update to IronPython including both new functionality as fixes for the most voted for bugs. The new functionality in v1.1 includes several new modules (array, SHA, MD5, and select), support for .NET XML Doc comments within the help system and doc tags, as well as support for loading cached pre-compiled modules. This release improves compatibility with CPython and gives the .NET developer a better interactive experience. You can download the release from: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=2573 We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: Arman0, Anthony Baxter, Christopher Baus, Christian Muirhead, Coleyc, Diane Trout, Doubleyewdee, Eloff, J. Merrill, JoeSox, J?rgen Stenarson, Michael Foord, Mike Raath, Py_Sunil, Seo Sanghyeon, Sylvain Hellegouarch, sophros, Tarlano, and Whit537. More complete list of changes and bug fixes: ============================================ CodePlex bug #1216: ironpython shows different error msgs when we use cpython's os module CodePlex bug #1403 int.dict0=0 CodePlex bug #2704 import and packages aren't mixing well CodePlex bug #5083 operator.contains is broken CodePlex bug #5445 socket.getaddrinfo(...) does not throw on nonsense parameters CodePlex bug #5446 socket.getaddrinfo(...) proto parameter CodePlex bug #5566 base64 slash bug CodePlex bug #5609 (Py2.5) File lacks enter and exit CodePlex bug #5641 co_name in code objects is None CodePlex bug #5712 iterating over main.dict throws CodePlex bug #5904 Multi-line dictionary expressions in IP interpreter console not compatible w/ CPython Interpreter console CodePlex bug #6010 UnicodeErrorInit sets @object instead of object CodePlex bug #6142 Setting func_name on function doesn't show up in name CodePlex bug #6265 maxsplit keyword arg of re.split not accepted CodePlex bug #6704 globals().fromkeys(...) broken CodePlex bug #6706 globals().Values enumerator broken CodePlex bug #6735 help incorrectly displays arguments for params functions CodePlex bug #6805 funccode.coargcount and funccode.coflags are wrong CodePlex bug #7532 func_defaults is empty tuple when there are no defaults CodePlex bug #7982 ^L yields SyntaxError CodePlex bug #7827 IronPython thread module does not implement stack_size CodePlex bug #7828 IronPython lock type does not support context manager methods Support importing pre-compiled modules produced when running in -X:SaveAssemblies mode Enable inheritance of static op_Implicit implicit conversion operators on .NET types Fixed tracebacks when catching exceptions in the method that threw them and a few other fixes here Bugfix: 4859 datetime.date.str broken Bugfix: 4870 datetime.datetime.isoformat does not report microseconds Bugfix: 5148 datetime.time(..., None).tzname() returns '' instead of None Bugfix: Bugfix: 5146 datetime.time(...).isoformat() does not work Bugfix: 4860 datetime.datetime.* only accurate to 1000 microseconds Bugfix: 3850 datetime.datetime(...) allows negative microsecond parameter Bugfix: 5147 datetime.time(..., None).utcoffset() returns 0 instead of None Bugfix: 5145 datetime.time.resolution is the wrong type Bugfix: 5143 datetime.time(...) allows parameters < time.min and > time.max Bugfix: 5139 datetime.timedelta and datetime.time objects should work correctly in boolean contexts Bugfix: 5133 datetime.timedelta.* does not normalize negative parameters and return values Bugfix: 5132 datetime.timedelta(...) constructor does not round off floating point parameters correctly Bugfix: 4871 datetime.timedelta.init does not accept the 4 optional keyword parameters Bugfix: 4868 datetime.datetime.timetuple returns an incorrect value Bugfix: 4867 datetime.datetime.tzname returns incorrect value if tzinfo member is None Bugfix: 4866 datetime.datetime.resolution is of the wrong type Bugfix: 4865 datetime.datetime.cmp broken for datetime.datetime.max Bugfix: 4864 datetime.datetime.max has the wrong value for the microsecond member Bugfix: 4863 datetime.datetime.init(...) defaults the hour keyword param to 1 (should be 0) Bugfix: 4861 datetime.timedelta + datetime.datetime throws a TypeError Bugfix: 3990 datetime.timedelta member attributes out of range Bugfix: 5149 datetime.timdelta(...) does not add fractional microseconds correctly Bugfix: 5136 datetime.timedelta.min(imum), datetime.timedelta.max(imum), and datetime.timedelta.resolution all have incorrect values Bugfix: 5135 datetime.timedelta.min and datetime.timedelta.max are missing Bugfix: 4858 datetime.date.reduce broken Bugfix 7426: in operator doesn't check for overloaded contains on dictionary Implemented array module Bugfix: KeyboardInterrupt propagates after except block that catches it Bugfix: Compiled regex gets different results for findall then non-compiled Bugfix: regex match doesn't implement lastgroup Bugfix: Import in exec doesn't publish into provided dictionary Bugfix: Lacking file open() modes (at, rt, etc...) Bugfix: PythonBinaryReader shouldn't access Position if stream isn't seekable Bugfix: Cannot pass arbitrary sequence to method defined w/ both * and ** args Bugfix: rb+ mode on file not implemented Bugfix: improved thread safety of dictionaries Bugfix: KeyError from dict adds quotes (and doesn't contain original key, only string repr) Bugfix: del {None:23} raises a TypeError Support for external region blocks when producing errors Bugfix: line number information in VS SDK is incorrect for web projects Support for Python 2.5 unified try/except/finally Support for Python 2.5 yield from finally block help supports documentation on reflected fields, properties, and events Support for XML Doc comments (requires XML files to live next to DLLs) for help and doc Nt module implements spawnle, spawnv, spawnve functions Socket implements makefile function Support for picking exception instances Fix issue with metaclass & deriving from mixed new-style / old-style classes Implement select module Implement sha module Implement md5 module Add new tests for codecs and CLR numeric interop From sanxiyn at gmail.com Fri Apr 20 16:02:49 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 20 Apr 2007 23:02:49 +0900 Subject: [IronPython] pybench results for CPython and IronPython Message-ID: <5b0248170704200702t1b62d37eu3c126df749509659@mail.gmail.com> With IronPython 1.1 released, I ran pybench for CPython and IronPython on my machine, and published the result here: http://sparcs.kaist.ac.kr/~tinuviel/pybench/ py24, py25, ipy11 are raw pybench result files. ipy11-vs-py24 and ipy11-vs-py25 are comparing reports generated by pybench. -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Sat Apr 21 00:00:58 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 20 Apr 2007 23:00:58 +0100 Subject: [IronPython] Invalid IRONPYTHONPATH Message-ID: <4629381A.5090201@voidspace.org.uk> Hello all, By the way, an invalid path on IRONPYTHON path causes the following traceback when you run 'ipy.exe'. C:\\ironpython\1.1>ipy.exe Traceback (most recent call last): File mscorlib, line unknown, in Combine File mscorlib, line unknown, in CheckInvalidPathChars ValueError: Illegal characters in path. IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> Probably not harmful, but I thought I'd let you know. :-) Just finished chapter 6 of the book, so time for the first review. After which it will be available (assuming they don't pull the plug!) to people under the Manning Early Access program... Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml From fuzzyman at voidspace.org.uk Sat Apr 21 00:05:49 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 20 Apr 2007 23:05:49 +0100 Subject: [IronPython] IronPython and help Message-ID: <4629393D.10401@voidspace.org.uk> Hello all, I see that one of the improvements listed for IronPython 1.1 is an extension to the help system. I'm finding that when the Python standard library is set in IRONPYTHONPATH, help doesn't seem to work *at all*. >>> help(3) Traceback (most recent call last): File , line 0, in ##77 File site, line unknown, in __call__ File c:\Python24\Lib\site.py, line 328, in __call__ File c:\Python24\Lib\pydoc.py, line 1655, in __call__ File c:\Python24\Lib\pydoc.py, line 1699, in help File c:\Python24\Lib\pydoc.py, line 1485, in doc File pydoc, line unknown, in document File c:\Python24\Lib\pydoc.py, line 307, in document File c:\Python24\Lib\pydoc.py, line 1177, in docclass File c:\Python24\Lib\inspect.py, line 224, in classify_class_attrs Exception: The method or operation is not implemented. >>> help(int) Traceback (most recent call last): File , line 0, in ##124 File site, line unknown, in __call__ File c:\Python24\Lib\site.py, line 328, in __call__ File c:\Python24\Lib\pydoc.py, line 1655, in __call__ File c:\Python24\Lib\pydoc.py, line 1699, in help File c:\Python24\Lib\pydoc.py, line 1485, in doc File pydoc, line unknown, in document File c:\Python24\Lib\pydoc.py, line 307, in document File c:\Python24\Lib\pydoc.py, line 1177, in docclass File c:\Python24\Lib\inspect.py, line 224, in classify_class_attrs Exception: The method or operation is not implemented. It works ok when the Python standard library isn't on the path - but most of the time I need the standard library and *deeply* regret that help isn't available to me. :-) Michael http://www.voidspace.org.uk/ironpython/index.shtml From sanxiyn at gmail.com Sat Apr 21 02:16:51 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sat, 21 Apr 2007 09:16:51 +0900 Subject: [IronPython] IronPython and help In-Reply-To: <4629393D.10401@voidspace.org.uk> References: <4629393D.10401@voidspace.org.uk> Message-ID: <5b0248170704201716n57ff079fo313969838e62e846@mail.gmail.com> 2007/4/21, Michael Foord : > Hello all, > > I see that one of the improvements listed for IronPython 1.1 is an > extension to the help system. > > I'm finding that when the Python standard library is set in > IRONPYTHONPATH, help doesn't seem to work *at all*. This is because site.py in Python standard library *overwrites* builtin help function. :( -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Sat Apr 21 02:19:15 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 21 Apr 2007 01:19:15 +0100 Subject: [IronPython] IronPython and help In-Reply-To: <5b0248170704201716n57ff079fo313969838e62e846@mail.gmail.com> References: <4629393D.10401@voidspace.org.uk> <5b0248170704201716n57ff079fo313969838e62e846@mail.gmail.com> Message-ID: <46295883.9040806@voidspace.org.uk> Sanghyeon Seo wrote: > 2007/4/21, Michael Foord : > >> Hello all, >> >> I see that one of the improvements listed for IronPython 1.1 is an >> extension to the help system. >> >> I'm finding that when the Python standard library is set in >> IRONPYTHONPATH, help doesn't seem to work *at all*. >> > > This is because site.py in Python standard library *overwrites* builtin > help function. :( > Is there a way to have the Python standard library on my path - but not have site.py imported ? I guess the answer is to have another 'site.py' earlier in the path... hmmm... Thanks. Michael http://www.voidspace.org.uk/ironpython/index.shtml From arman at twinsun.com Sat Apr 21 08:51:56 2007 From: arman at twinsun.com (Arman Bostani) Date: Fri, 20 Apr 2007 23:51:56 -0700 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: References: Message-ID: <4629B48C.40107@twinsun.com> Thanks to Sanghyeon for running the benchmarks. To summarize his results, it seems like IP is pretty good at: comparing simple types, loops, function calls and float arithmetic. It performs pretty poorly at almost everything else! I guess its time to convert critical code sections to Boo. -arman > Date: Fri, 20 Apr 2007 23:02:49 +0900 > From: "Sanghyeon Seo" > Subject: [IronPython] pybench results for CPython and IronPython > > With IronPython 1.1 released, I ran pybench for CPython and IronPython > on my machine, and published the result here: > > http://sparcs.kaist.ac.kr/~tinuviel/pybench/ > > py24, py25, ipy11 are raw pybench result files. ipy11-vs-py24 and > ipy11-vs-py25 are comparing reports generated by pybench. From xmlhacker at gmail.com Sat Apr 21 15:04:25 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sat, 21 Apr 2007 07:04:25 -0600 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: <4629B48C.40107@twinsun.com> References: <4629B48C.40107@twinsun.com> Message-ID: I agree, Boo is a nice language, but given its foundation as a statically-typed language it's not exactly a one-to-one comparison. Of course you can always use the duck type capabilities to gain a similar dynamic effect, but even a Boo duck type doesn't provide a fair one-to-one as you still have to declare it as a duck type, and once you do, the performance advantage gained from the static compilation is obviously lessened. Anybody happen to know of a similar benchmark comparison between CPython and the duck type-based Boo equivalent? And has anybody taken the time to quantify how much benefit is gained in developer productivity due to the rapid prototyping and interactive capabilities provided to the .NET developer at runtime? If for no other reason (and there are quite a few other reasons), the fact that with IronPython I can quickly and easily move from idea > through the thought process > and into a working prototype in about the same amount of time it takes to open up Visual Studio and create a new project is worth each and every additional cycle, cycles which can easily be gained back by writing the production app in C# (or Boo, for that matter) once things have solidified into something a bit more production worthy. Just food for thought, but if we're going to compare apples and oranges lets at least take a bite out of the apple and peel the orange before making a determination as to which one is preferable, and why. On 4/21/07, Arman Bostani wrote: > Thanks to Sanghyeon for running the benchmarks. To summarize his > results, it seems like IP is pretty good at: comparing simple types, > loops, function calls and float arithmetic. It performs pretty poorly > at almost everything else! I guess its time to convert critical code > sections to Boo. > > -arman > > > Date: Fri, 20 Apr 2007 23:02:49 +0900 > > From: "Sanghyeon Seo" > > Subject: [IronPython] pybench results for CPython and IronPython > > > > With IronPython 1.1 released, I ran pybench for CPython and IronPython > > on my machine, and published the result here: > > > > http://sparcs.kaist.ac.kr/~tinuviel/pybench/ > > > > py24, py25, ipy11 are raw pybench result files. ipy11-vs-py24 and > > ipy11-vs-py25 are comparing reports generated by pybench. > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 From luismgz at gmail.com Sat Apr 21 16:55:35 2007 From: luismgz at gmail.com (luismg) Date: Sat, 21 Apr 2007 14:55:35 -0000 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: References: <4629B48C.40107@twinsun.com> Message-ID: <1177167335.086141.47650@d57g2000hsg.googlegroups.com> I also I agree with you two. Boo is an extremelly nice and productive static language, and its syntax is so similar to Python's that waisting time deciding what to choose for a given task is almost non-sense. I think the decision should be made based on platform and libraries to be used mainly and, in any case, converting from python to Boo is pretty straightforward. Note that performance-wise, Boo is still completely unoptimized, as its author recently recognized. It has for sure the potential to become as fast as C#, but so far its development has been concentrated in completeness and correction (as is the case with IP). For me, the difference between python's dynamicity and Boo is simply that python allows for a more exploratory way of development. But if performance is paramount, moving part or all the program to Boo is extremelly simple. Luis On Apr 21, 10:04 am, "M. David Peterson" wrote: > I agree, Boo is a nice language, but given its foundation as a > statically-typed language it's not exactly a one-to-one comparison. > > Of course you can always use the duck type capabilities to gain a > similar dynamic effect, but even a Boo duck type doesn't provide a > fair one-to-one as you still have to declare it as a duck type, and > once you do, the performance advantage gained from the static > compilation is obviously lessened. > > Anybody happen to know of a similar benchmark comparison between > CPython and the duck type-based Boo equivalent? And has anybody taken > the time to quantify how much benefit is gained in developer > productivity due to the rapid prototyping and interactive capabilities > provided to the .NET developer at runtime? > > If for no other reason (and there are quite a few other reasons), the > fact that with IronPython I can quickly and easily move from idea > > through the thought process > and into a working prototype in about > the same amount of time it takes to open up Visual Studio and create a > new project is worth each and every additional cycle, cycles which can > easily be gained back by writing the production app in C# (or Boo, for > that matter) once things have solidified into something a bit more > production worthy. > > Just food for thought, but if we're going to compare apples and > oranges lets at least take a bite out of the apple and peel the orange > before making a determination as to which one is preferable, and why. > > On 4/21/07, Arman Bostani wrote: > > > > > Thanks to Sanghyeon for running the benchmarks. To summarize his > > results, it seems like IP is pretty good at: comparing simple types, > > loops, function calls and float arithmetic. It performs pretty poorly > > at almost everything else! I guess its time to convert critical code > > sections to Boo. > > > -arman > > > > Date: Fri, 20 Apr 2007 23:02:49 +0900 > > > From: "Sanghyeon Seo" > > > Subject: [IronPython] pybench results for CPython and IronPython > > > > With IronPython 1.1 released, I ran pybench for CPython and IronPython > > > on my machine, and published the result here: > > > >http://sparcs.kaist.ac.kr/~tinuviel/pybench/ > > > > py24, py25, ipy11 are raw pybench result files. ipy11-vs-py24 and > > > ipy11-vs-py25 are comparing reports generated by pybench. > > > _______________________________________________ > > users mailing list > > u... at lists.ironpython.com > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- > /M:D > > M. David Petersonhttp://mdavid.name|http://www.oreillynet.com/pub/au/2354|http://dev.aol.com/blog/3155 > _______________________________________________ > users mailing list > u... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com From xmlhacker at gmail.com Sun Apr 22 05:56:41 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sat, 21 Apr 2007 21:56:41 -0600 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: <1177167335.086141.47650@d57g2000hsg.googlegroups.com> References: <4629B48C.40107@twinsun.com> <1177167335.086141.47650@d57g2000hsg.googlegroups.com> Message-ID: On 4/21/07, luismg wrote: > > > For me, the difference between python's dynamicity and Boo is simply > that python allows for a more exploratory way of development. I *LOVE* it! :D > http://www.oreillynet.com/xml/blog/2007/04/qotdluisironpythondevlist_pyth.html -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jim.Hugunin at microsoft.com Sun Apr 22 09:00:48 2007 From: Jim.Hugunin at microsoft.com (Jim Hugunin) Date: Sun, 22 Apr 2007 00:00:48 -0700 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: <4629B48C.40107@twinsun.com> References: <4629B48C.40107@twinsun.com> Message-ID: I'd like to point out one fact about these benchmarks that seems to have been missed. Seo's numbers are for running IronPython 1.1 on Mono - not on the Microsoft .NET implementation. The Mono team has done excellent work with that project, but today the performance of the .NET implementation is still significantly better and is a much better platform for benchmarking IronPython's performance. I reran pybench on my laptop tonight on the RTM version of .NET that ships with Windows Vista - and has been available for XP for quite some time now. I compared with CPython-2.5.1 (the latest version). Running on .NET, I find that IronPython is faster on some tests and CPython is faster on others. We know that we still have performance work to do. After all, IronPython just reached its 1.1 release and almost all of our recent work has been about compatibility and completeness. However, the story is already quite interesting. Out of the 51 tests in pybench, CPython is more than 2x faster on 10 of the tests and IronPython is more than 2x faster on 9 of the tests. Depending on what your code does, either implementation could run faster. The most interesting cases to me are the 5 tests where CPython is more than 3x faster than IronPython and the other 5 tests where IronPython is more than 3x faster than CPython. CPython's strongest performance is in dictionaries with integer and string keys, list slicing, small tuples and code that actually throws and catches exceptions. IronPython's strongest performance is in calling builtin functions, if/then/else blocks, calling python functions, deep recursion, and try/except blocks that don't actually catch an exception. The places where IronPython is performing strongest are where it can use the .NET code generation and JIT optimization most effectively. The places where it is slowest are mainly in runtime library implementation of core datatypes. CPython's list and dictionary datatypes are written in C and have been hand-tuned for Python-style workloads over the past 10 years. IronPython's datatypes are much newer and clearly need more tuning as the implementation matures. The only two tests that really stand out as showing a deep performance issue are the two exception handling ones. These are the only tests where either implementation is more than 4x faster than the other. IronPython is 10x faster on the try/catch without an exception and CPython is 30x faster when an exception is actually raised. This is a deliberate design decision within .NET to make code that doesn't throw exceptions run faster - even if that means slowing down code that does throw exceptions. I'm fairly confident this was the right decision - and even remember the day long ago when Guido was discussing Python's exception system and explained that he'd accept almost any slow-down to the exceptional case in return for removing a single instruction from the non-exceptional path. Thanks - Jim My results ------------------------------------------------------------------------------- PYBENCH 2.0 ------------------------------------------------------------------------------- * using Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Int el)] * disabled garbage collection * system check interval set to maximum: 2147483647 * using timer: time.clock ------------------------------------------------------------------------------- Benchmark: ipy11.pybench ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID: cli-32bit Processor: Python: Implementation: Python Executable: c:\ironpython-1.1\ipy.exe Version: 1.1.0 Compiler: X Bits: 32bit Build: 0 0 (#0) Unicode: UCS2 ------------------------------------------------------------------------------- Comparing with: py25.pybench ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.clock Machine Details: Platform ID: Microsoft-Windows-32bit-WindowsPE Processor: Python: Implementation: Python Executable: c:\python25\python.exe Version: 2.5.1 Compiler: MSC v.1310 32 bit (Intel) Bits: 32bit Build: Apr 18 2007 08:51:08 (#r251:54863) Unicode: UCS2 Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- BuiltinFunctionCalls: 44ms 181ms -75.7% 48ms 182ms -73.7% BuiltinMethodLookup: 335ms 160ms +109.1% 344ms 162ms +112.0% CompareFloats: 99ms 111ms -11.3% 105ms 112ms -6.0% CompareFloatsIntegers: 63ms 125ms -49.7% 65ms 126ms -48.7% CompareIntegers: 102ms 114ms -10.4% 105ms 115ms -8.9% CompareInternedStrings: 175ms 126ms +39.0% 180ms 127ms +41.6% CompareLongs: 111ms 105ms +5.3% 114ms 106ms +7.2% CompareStrings: 167ms 126ms +32.7% 172ms 127ms +35.1% CompareUnicode: 121ms 125ms -3.4% 123ms 126ms -2.0% ConcatStrings: 482ms 272ms +77.2% 533ms 275ms +93.4% ConcatUnicode: 305ms 216ms +41.0% 350ms 217ms +61.5% CreateInstances: 102ms 148ms -31.1% 106ms 149ms -28.9% CreateNewInstances: 326ms 131ms +148.0% 335ms 133ms +151.9% CreateStringsWithConcat: 228ms 147ms +55.9% 238ms 148ms +61.0% CreateUnicodeWithConcat: 91ms 154ms -41.2% 94ms 157ms -40.4% DictCreation: 137ms 105ms +30.0% 143ms 106ms +33.9% DictWithFloatKeys: 301ms 230ms +30.8% 306ms 232ms +32.0% DictWithIntegerKeys: 343ms 106ms +223.0% 351ms 108ms +224.7% DictWithStringKeys: 388ms 102ms +282.1% 395ms 102ms +285.1% ForLoops: 39ms 95ms -59.0% 40ms 97ms -58.5% IfThenElse: 35ms 111ms -68.9% 37ms 112ms -66.8% ListSlicing: 468ms 155ms +201.3% 477ms 157ms +204.4% NestedForLoops: 55ms 120ms -54.1% 57ms 122ms -53.0% NormalClassAttribute: 276ms 127ms +117.7% 282ms 129ms +119.7% NormalInstanceAttribute: 106ms 119ms -11.0% 109ms 120ms -9.7% PythonFunctionCalls: 37ms 130ms -71.7% 40ms 131ms -69.5% PythonMethodCalls: 127ms 158ms -19.6% 132ms 159ms -16.8% Recursion: 49ms 177ms -72.5% 50ms 179ms -71.8% SecondImport: 189ms 126ms +50.4% 195ms 127ms +53.6% SecondPackageImport: 196ms 134ms +45.8% 202ms 136ms +48.5% SecondSubmoduleImport: 266ms 177ms +50.6% 272ms 180ms +51.3% SimpleComplexArithmetic: 97ms 148ms -34.4% 101ms 149ms -32.0% SimpleDictManipulation: 311ms 118ms +164.4% 318ms 118ms +168.0% SimpleFloatArithmetic: 64ms 119ms -46.6% 69ms 121ms -43.2% SimpleIntFloatArithmetic: 41ms 100ms -59.4% 43ms 102ms -58.2% SimpleIntegerArithmetic: 43ms 100ms -57.2% 44ms 101ms -56.4% SimpleListManipulation: 121ms 104ms +16.6% 124ms 105ms +18.3% SimpleLongArithmetic: 126ms 113ms +11.2% 131ms 115ms +14.1% SmallLists: 223ms 154ms +45.0% 229ms 156ms +47.0% SmallTuples: 508ms 144ms +252.2% 523ms 145ms +259.7% SpecialClassAttribute: 275ms 124ms +121.2% 283ms 126ms +124.5% SpecialInstanceAttribute: 105ms 210ms -50.1% 109ms 212ms -48.5% StringMappings: 342ms 633ms -46.0% 351ms 637ms -44.9% StringPredicates: 222ms 217ms +2.3% 228ms 219ms +4.4% StringSlicing: 245ms 162ms +51.4% 260ms 163ms +59.4% TryExcept: 7ms 100ms -93.4% 11ms 102ms -89.4% TryRaiseExcept: 3413ms 114ms +2896.2% 3453ms 115ms +2910.6% TupleSlicing: 227ms 150ms +51.6% 235ms 151ms +54.9% UnicodeMappings: 227ms 126ms +79.6% 233ms 129ms +81.4% UnicodePredicates: 218ms 129ms +68.8% 224ms 132ms +70.4% UnicodeSlicing: 211ms 182ms +15.8% 223ms 184ms +21.3% ------------------------------------------------------------------------------- Totals: 12781ms 7659ms +66.9% 13191ms 7741ms +70.4% (this=ipy11.pybench, other=py25.pybench) From xmlhacker at gmail.com Sun Apr 22 10:08:22 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sun, 22 Apr 2007 02:08:22 -0600 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: References: <4629B48C.40107@twinsun.com> Message-ID: Hi Jim, Your point regarding the performance difference between Mono and MS.NET is an important one. It's one of those things that should have been a lot more obvious than it was. None-the-less, thanks for bringing it to the surface! One question: While I recognize the fact that for obvious reasons, ngen'ing the IronPython assemblies as part of the distribution isn't an option (don't worry, I'm not suggesting that it should or even could be an option ;-), has anyone ran these same benchmarks against an ngen'd version of the assemblies to compare the results? I realize that performance gains are no guarantee, but I have found that more often than not the performance gains are fairly significant, and worth the extra effort to ngen during the setup processes in *most* cases. And in this case, given the fact that the CPython runtime is compiled to native code and IronPython is still in all of its CIL glory during the start-up process I wonder if its worth gaining a more apples-to-apples comparison by running the same tests with ngen'd IP assemblies? I would suggest the same for Mono, but as of the last time I checked, there is currently no support for AOT compiling .NET 2.0 assemblies (though I will quickly check to verify, as its been a month or two since I last checked) Worth pointing out: With these updated numbers, and given your statement, IronPython just reached its 1.1 release and almost all of our recent work > has been about compatibility and completeness. I must admit, I am certainly looking forward to the result when "speed and optimization" is added to the mix. :) Thanks for all of your hard work! On 4/22/07, Jim Hugunin wrote: > > I'd like to point out one fact about these benchmarks that seems to have > been missed. Seo's numbers are for running IronPython 1.1 on Mono - not > on the Microsoft .NET implementation. The Mono team has done excellent work > with that project, but today the performance of the .NET implementation is > still significantly better and is a much better platform for benchmarking > IronPython's performance. > > I reran pybench on my laptop tonight on the RTM version of .NET that ships > with Windows Vista - and has been available for XP for quite some time > now. I compared with CPython-2.5.1 (the latest version). > > Running on .NET, I find that IronPython is faster on some tests and > CPython is faster on others. We know that we still have performance work to > do. After all, IronPython just reached its 1.1 release and almost all of > our recent work has been about compatibility and completeness. However, the > story is already quite interesting. Out of the 51 tests in pybench, CPython > is more than 2x faster on 10 of the tests and IronPython is more than 2x > faster on 9 of the tests. Depending on what your code does, either > implementation could run faster. > > The most interesting cases to me are the 5 tests where CPython is more > than 3x faster than IronPython and the other 5 tests where IronPython is > more than 3x faster than CPython. CPython's strongest performance is in > dictionaries with integer and string keys, list slicing, small tuples and > code that actually throws and catches exceptions. IronPython's strongest > performance is in calling builtin functions, if/then/else blocks, calling > python functions, deep recursion, and try/except blocks that don't actually > catch an exception. > > The places where IronPython is performing strongest are where it can use > the .NET code generation and JIT optimization most effectively. The places > where it is slowest are mainly in runtime library implementation of core > datatypes. CPython's list and dictionary datatypes are written in C and > have been hand-tuned for Python-style workloads over the past 10 > years. IronPython's datatypes are much newer and clearly need more tuning > as the implementation matures. > > The only two tests that really stand out as showing a deep performance > issue are the two exception handling ones. These are the only tests where > either implementation is more than 4x faster than the other. IronPython is > 10x faster on the try/catch without an exception and CPython is 30x faster > when an exception is actually raised. This is a deliberate design decision > within .NET to make code that doesn't throw exceptions run faster - even if > that means slowing down code that does throw exceptions. I'm fairly > confident this was the right decision - and even remember the day long ago > when Guido was discussing Python's exception system and explained that he'd > accept almost any slow-down to the exceptional case in return for removing a > single instruction from the non-exceptional path. > > Thanks - Jim > > My results > > ------------------------------------------------------------------------------- > PYBENCH 2.0 > > ------------------------------------------------------------------------------- > * using Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 > bit (Int > el)] > * disabled garbage collection > * system check interval set to maximum: 2147483647 > * using timer: time.clock > > > ------------------------------------------------------------------------------- > Benchmark: ipy11.pybench > > ------------------------------------------------------------------------------- > > Rounds: 10 > Warp: 10 > Timer: time.time > > Machine Details: > Platform ID: cli-32bit > Processor: > > Python: > Implementation: Python > Executable: c:\ironpython-1.1\ipy.exe > Version: 1.1.0 > Compiler: X > Bits: 32bit > Build: 0 0 (#0) > Unicode: UCS2 > > > > ------------------------------------------------------------------------------- > Comparing with: py25.pybench > > ------------------------------------------------------------------------------- > > Rounds: 10 > Warp: 10 > Timer: time.clock > > Machine Details: > Platform ID: Microsoft-Windows-32bit-WindowsPE > Processor: > > Python: > Implementation: Python > Executable: c:\python25\python.exe > Version: 2.5.1 > Compiler: MSC v.1310 32 bit (Intel) > Bits: 32bit > Build: Apr 18 2007 08:51:08 (#r251:54863) > Unicode: UCS2 > > > Test minimum run-time average run-time > this other diff this other > diff > > ------------------------------------------------------------------------------- > BuiltinFunctionCalls: 44ms 181ms -75.7% 48ms 182ms - > 73.7% > BuiltinMethodLookup: 335ms 160ms +109.1% 344ms 162ms > +112.0% > CompareFloats: 99ms 111ms -11.3% 105ms 112ms > -6.0% > CompareFloatsIntegers: 63ms 125ms -49.7% 65ms 126ms - > 48.7% > CompareIntegers: 102ms 114ms -10.4% 105ms 115ms > -8.9% > CompareInternedStrings: 175ms 126ms +39.0% 180ms > 127ms +41.6% > CompareLongs: 111ms 105ms +5.3% 114ms 106ms > +7.2% > CompareStrings: 167ms 126ms +32.7% 172ms > 127ms +35.1% > CompareUnicode: 121ms 125ms -3.4% 123ms 126ms > -2.0% > ConcatStrings: 482ms 272ms +77.2% 533ms > 275ms +93.4% > ConcatUnicode: 305ms 216ms +41.0% 350ms > 217ms +61.5% > CreateInstances: 102ms 148ms -31.1% 106ms 149ms - > 28.9% > CreateNewInstances: 326ms 131ms +148.0% 335ms 133ms > +151.9% > CreateStringsWithConcat: 228ms 147ms +55.9% 238ms > 148ms +61.0% > CreateUnicodeWithConcat: 91ms 154ms -41.2% 94ms 157ms - > 40.4% > DictCreation: 137ms 105ms +30.0% 143ms > 106ms +33.9% > DictWithFloatKeys: 301ms 230ms +30.8% 306ms > 232ms +32.0% > DictWithIntegerKeys: 343ms 106ms +223.0% 351ms 108ms > +224.7% > DictWithStringKeys: 388ms 102ms +282.1% 395ms 102ms > +285.1% > ForLoops: 39ms 95ms -59.0% 40ms 97ms - > 58.5% > IfThenElse: 35ms 111ms -68.9% 37ms 112ms - > 66.8% > ListSlicing: 468ms 155ms +201.3% 477ms 157ms > +204.4% > NestedForLoops: 55ms 120ms -54.1% 57ms 122ms - > 53.0% > NormalClassAttribute: 276ms 127ms +117.7% 282ms 129ms > +119.7% > NormalInstanceAttribute: 106ms 119ms -11.0% 109ms 120ms > -9.7% > PythonFunctionCalls: 37ms 130ms -71.7% 40ms 131ms - > 69.5% > PythonMethodCalls: 127ms 158ms -19.6% 132ms 159ms - > 16.8% > Recursion: 49ms 177ms -72.5% 50ms 179ms - > 71.8% > SecondImport: 189ms 126ms +50.4% 195ms > 127ms +53.6% > SecondPackageImport: 196ms 134ms +45.8% 202ms > 136ms +48.5% > SecondSubmoduleImport: 266ms 177ms +50.6% 272ms > 180ms +51.3% > SimpleComplexArithmetic: 97ms 148ms -34.4% 101ms 149ms - > 32.0% > SimpleDictManipulation: 311ms 118ms +164.4% 318ms 118ms > +168.0% > SimpleFloatArithmetic: 64ms 119ms -46.6% 69ms 121ms - > 43.2% > SimpleIntFloatArithmetic: 41ms 100ms -59.4% 43ms 102ms - > 58.2% > SimpleIntegerArithmetic: 43ms 100ms -57.2% 44ms 101ms - > 56.4% > SimpleListManipulation: 121ms 104ms +16.6% 124ms > 105ms +18.3% > SimpleLongArithmetic: 126ms 113ms +11.2% 131ms > 115ms +14.1% > SmallLists: 223ms 154ms +45.0% 229ms > 156ms +47.0% > SmallTuples: 508ms 144ms +252.2% 523ms 145ms > +259.7% > SpecialClassAttribute: 275ms 124ms +121.2% 283ms 126ms > +124.5% > SpecialInstanceAttribute: 105ms 210ms -50.1% 109ms 212ms - > 48.5% > StringMappings: 342ms 633ms -46.0% 351ms 637ms - > 44.9% > StringPredicates: 222ms 217ms +2.3% 228ms 219ms > +4.4% > StringSlicing: 245ms 162ms +51.4% 260ms > 163ms +59.4% > TryExcept: 7ms 100ms -93.4% 11ms 102ms - > 89.4% > TryRaiseExcept: 3413ms 114ms +2896.2% 3453ms 115ms > +2910.6% > TupleSlicing: 227ms 150ms +51.6% 235ms > 151ms +54.9% > UnicodeMappings: 227ms 126ms +79.6% 233ms > 129ms +81.4% > UnicodePredicates: 218ms 129ms +68.8% 224ms > 132ms +70.4% > UnicodeSlicing: 211ms 182ms +15.8% 223ms > 184ms +21.3% > > ------------------------------------------------------------------------------- > Totals: 12781ms 7659ms +66.9% > 13191ms 7741ms +70.4% > > (this=ipy11.pybench, other=py25.pybench) > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sun Apr 22 15:29:39 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 22 Apr 2007 14:29:39 +0100 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: References: <4629B48C.40107@twinsun.com> Message-ID: <462B6343.5070006@voidspace.org.uk> Hi Jim, Great to hear from you. Does this mean that IronPython 2 *has* seem some optimization work ? Anyway, thanks for the benchmark. *Very* interesting. Michael Foord Jim Hugunin wrote: > I'd like to point out one fact about these benchmarks that seems to have been missed. Seo's numbers are for running IronPython 1.1 on Mono - not on the Microsoft .NET implementation. The Mono team has done excellent work with that project, but today the performance of the .NET implementation is still significantly better and is a much better platform for benchmarking IronPython's performance. > > I reran pybench on my laptop tonight on the RTM version of .NET that ships with Windows Vista - and has been available for XP for quite some time now. I compared with CPython-2.5.1 (the latest version). > > Running on .NET, I find that IronPython is faster on some tests and CPython is faster on others. We know that we still have performance work to do. After all, IronPython just reached its 1.1 release and almost all of our recent work has been about compatibility and completeness. However, the story is already quite interesting. Out of the 51 tests in pybench, CPython is more than 2x faster on 10 of the tests and IronPython is more than 2x faster on 9 of the tests. Depending on what your code does, either implementation could run faster. > > The most interesting cases to me are the 5 tests where CPython is more than 3x faster than IronPython and the other 5 tests where IronPython is more than 3x faster than CPython. CPython's strongest performance is in dictionaries with integer and string keys, list slicing, small tuples and code that actually throws and catches exceptions. IronPython's strongest performance is in calling builtin functions, if/then/else blocks, calling python functions, deep recursion, and try/except blocks that don't actually catch an exception. > > The places where IronPython is performing strongest are where it can use the .NET code generation and JIT optimization most effectively. The places where it is slowest are mainly in runtime library implementation of core datatypes. CPython's list and dictionary datatypes are written in C and have been hand-tuned for Python-style workloads over the past 10 years. IronPython's datatypes are much newer and clearly need more tuning as the implementation matures. > > The only two tests that really stand out as showing a deep performance issue are the two exception handling ones. These are the only tests where either implementation is more than 4x faster than the other. IronPython is 10x faster on the try/catch without an exception and CPython is 30x faster when an exception is actually raised. This is a deliberate design decision within .NET to make code that doesn't throw exceptions run faster - even if that means slowing down code that does throw exceptions. I'm fairly confident this was the right decision - and even remember the day long ago when Guido was discussing Python's exception system and explained that he'd accept almost any slow-down to the exceptional case in return for removing a single instruction from the non-exceptional path. > > Thanks - Jim > > My results > ------------------------------------------------------------------------------- > PYBENCH 2.0 > ------------------------------------------------------------------------------- > * using Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Int > el)] > * disabled garbage collection > * system check interval set to maximum: 2147483647 > * using timer: time.clock > > ------------------------------------------------------------------------------- > Benchmark: ipy11.pybench > ------------------------------------------------------------------------------- > > Rounds: 10 > Warp: 10 > Timer: time.time > > Machine Details: > Platform ID: cli-32bit > Processor: > > Python: > Implementation: Python > Executable: c:\ironpython-1.1\ipy.exe > Version: 1.1.0 > Compiler: X > Bits: 32bit > Build: 0 0 (#0) > Unicode: UCS2 > > > ------------------------------------------------------------------------------- > Comparing with: py25.pybench > ------------------------------------------------------------------------------- > > Rounds: 10 > Warp: 10 > Timer: time.clock > > Machine Details: > Platform ID: Microsoft-Windows-32bit-WindowsPE > Processor: > > Python: > Implementation: Python > Executable: c:\python25\python.exe > Version: 2.5.1 > Compiler: MSC v.1310 32 bit (Intel) > Bits: 32bit > Build: Apr 18 2007 08:51:08 (#r251:54863) > Unicode: UCS2 > > > Test minimum run-time average run-time > this other diff this other diff > ------------------------------------------------------------------------------- > BuiltinFunctionCalls: 44ms 181ms -75.7% 48ms 182ms -73.7% > BuiltinMethodLookup: 335ms 160ms +109.1% 344ms 162ms +112.0% > CompareFloats: 99ms 111ms -11.3% 105ms 112ms -6.0% > CompareFloatsIntegers: 63ms 125ms -49.7% 65ms 126ms -48.7% > CompareIntegers: 102ms 114ms -10.4% 105ms 115ms -8.9% > CompareInternedStrings: 175ms 126ms +39.0% 180ms 127ms +41.6% > CompareLongs: 111ms 105ms +5.3% 114ms 106ms +7.2% > CompareStrings: 167ms 126ms +32.7% 172ms 127ms +35.1% > CompareUnicode: 121ms 125ms -3.4% 123ms 126ms -2.0% > ConcatStrings: 482ms 272ms +77.2% 533ms 275ms +93.4% > ConcatUnicode: 305ms 216ms +41.0% 350ms 217ms +61.5% > CreateInstances: 102ms 148ms -31.1% 106ms 149ms -28.9% > CreateNewInstances: 326ms 131ms +148.0% 335ms 133ms +151.9% > CreateStringsWithConcat: 228ms 147ms +55.9% 238ms 148ms +61.0% > CreateUnicodeWithConcat: 91ms 154ms -41.2% 94ms 157ms -40.4% > DictCreation: 137ms 105ms +30.0% 143ms 106ms +33.9% > DictWithFloatKeys: 301ms 230ms +30.8% 306ms 232ms +32.0% > DictWithIntegerKeys: 343ms 106ms +223.0% 351ms 108ms +224.7% > DictWithStringKeys: 388ms 102ms +282.1% 395ms 102ms +285.1% > ForLoops: 39ms 95ms -59.0% 40ms 97ms -58.5% > IfThenElse: 35ms 111ms -68.9% 37ms 112ms -66.8% > ListSlicing: 468ms 155ms +201.3% 477ms 157ms +204.4% > NestedForLoops: 55ms 120ms -54.1% 57ms 122ms -53.0% > NormalClassAttribute: 276ms 127ms +117.7% 282ms 129ms +119.7% > NormalInstanceAttribute: 106ms 119ms -11.0% 109ms 120ms -9.7% > PythonFunctionCalls: 37ms 130ms -71.7% 40ms 131ms -69.5% > PythonMethodCalls: 127ms 158ms -19.6% 132ms 159ms -16.8% > Recursion: 49ms 177ms -72.5% 50ms 179ms -71.8% > SecondImport: 189ms 126ms +50.4% 195ms 127ms +53.6% > SecondPackageImport: 196ms 134ms +45.8% 202ms 136ms +48.5% > SecondSubmoduleImport: 266ms 177ms +50.6% 272ms 180ms +51.3% > SimpleComplexArithmetic: 97ms 148ms -34.4% 101ms 149ms -32.0% > SimpleDictManipulation: 311ms 118ms +164.4% 318ms 118ms +168.0% > SimpleFloatArithmetic: 64ms 119ms -46.6% 69ms 121ms -43.2% > SimpleIntFloatArithmetic: 41ms 100ms -59.4% 43ms 102ms -58.2% > SimpleIntegerArithmetic: 43ms 100ms -57.2% 44ms 101ms -56.4% > SimpleListManipulation: 121ms 104ms +16.6% 124ms 105ms +18.3% > SimpleLongArithmetic: 126ms 113ms +11.2% 131ms 115ms +14.1% > SmallLists: 223ms 154ms +45.0% 229ms 156ms +47.0% > SmallTuples: 508ms 144ms +252.2% 523ms 145ms +259.7% > SpecialClassAttribute: 275ms 124ms +121.2% 283ms 126ms +124.5% > SpecialInstanceAttribute: 105ms 210ms -50.1% 109ms 212ms -48.5% > StringMappings: 342ms 633ms -46.0% 351ms 637ms -44.9% > StringPredicates: 222ms 217ms +2.3% 228ms 219ms +4.4% > StringSlicing: 245ms 162ms +51.4% 260ms 163ms +59.4% > TryExcept: 7ms 100ms -93.4% 11ms 102ms -89.4% > TryRaiseExcept: 3413ms 114ms +2896.2% 3453ms 115ms +2910.6% > TupleSlicing: 227ms 150ms +51.6% 235ms 151ms +54.9% > UnicodeMappings: 227ms 126ms +79.6% 233ms 129ms +81.4% > UnicodePredicates: 218ms 129ms +68.8% 224ms 132ms +70.4% > UnicodeSlicing: 211ms 182ms +15.8% 223ms 184ms +21.3% > ------------------------------------------------------------------------------- > Totals: 12781ms 7659ms +66.9% 13191ms 7741ms +70.4% > > (this=ipy11.pybench, other=py25.pybench) > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From fuzzyman at voidspace.org.uk Sun Apr 22 16:15:27 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 22 Apr 2007 15:15:27 +0100 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: References: <4629B48C.40107@twinsun.com> Message-ID: <462B6DFF.4010907@voidspace.org.uk> Jim Hugunin wrote: > I'd like to point out one fact about these benchmarks that seems to have been missed. Seo's numbers are for running IronPython 1.1 on Mono - not on the Microsoft .NET implementation. The Mono team has done excellent work with that project, but today the performance of the .NET implementation is still significantly better and is a much better platform for benchmarking IronPython's performance. > And on close examination the results are impressive. Nice one. The anomaly with raising exceptions is very weird though (IronPython is around 30 times slower!) : TryExcept: 7ms 100ms -93.4% 11ms 102ms -89.4% TryRaiseExcept: 3413ms 114ms +2896.2% 3453ms 115ms +2910.6% All the best, Michael Foord > I reran pybench on my laptop tonight on the RTM version of .NET that ships with Windows Vista - and has been available for XP for quite some time now. I compared with CPython-2.5.1 (the latest version). > > Running on .NET, I find that IronPython is faster on some tests and CPython is faster on others. We know that we still have performance work to do. After all, IronPython just reached its 1.1 release and almost all of our recent work has been about compatibility and completeness. However, the story is already quite interesting. Out of the 51 tests in pybench, CPython is more than 2x faster on 10 of the tests and IronPython is more than 2x faster on 9 of the tests. Depending on what your code does, either implementation could run faster. > > The most interesting cases to me are the 5 tests where CPython is more than 3x faster than IronPython and the other 5 tests where IronPython is more than 3x faster than CPython. CPython's strongest performance is in dictionaries with integer and string keys, list slicing, small tuples and code that actually throws and catches exceptions. IronPython's strongest performance is in calling builtin functions, if/then/else blocks, calling python functions, deep recursion, and try/except blocks that don't actually catch an exception. > > The places where IronPython is performing strongest are where it can use the .NET code generation and JIT optimization most effectively. The places where it is slowest are mainly in runtime library implementation of core datatypes. CPython's list and dictionary datatypes are written in C and have been hand-tuned for Python-style workloads over the past 10 years. IronPython's datatypes are much newer and clearly need more tuning as the implementation matures. > > The only two tests that really stand out as showing a deep performance issue are the two exception handling ones. These are the only tests where either implementation is more than 4x faster than the other. IronPython is 10x faster on the try/catch without an exception and CPython is 30x faster when an exception is actually raised. This is a deliberate design decision within .NET to make code that doesn't throw exceptions run faster - even if that means slowing down code that does throw exceptions. I'm fairly confident this was the right decision - and even remember the day long ago when Guido was discussing Python's exception system and explained that he'd accept almost any slow-down to the exceptional case in return for removing a single instruction from the non-exceptional path. > > Thanks - Jim > > My results > ------------------------------------------------------------------------------- > PYBENCH 2.0 > ------------------------------------------------------------------------------- > * using Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Int > el)] > * disabled garbage collection > * system check interval set to maximum: 2147483647 > * using timer: time.clock > > ------------------------------------------------------------------------------- > Benchmark: ipy11.pybench > ------------------------------------------------------------------------------- > > Rounds: 10 > Warp: 10 > Timer: time.time > > Machine Details: > Platform ID: cli-32bit > Processor: > > Python: > Implementation: Python > Executable: c:\ironpython-1.1\ipy.exe > Version: 1.1.0 > Compiler: X > Bits: 32bit > Build: 0 0 (#0) > Unicode: UCS2 > > > ------------------------------------------------------------------------------- > Comparing with: py25.pybench > ------------------------------------------------------------------------------- > > Rounds: 10 > Warp: 10 > Timer: time.clock > > Machine Details: > Platform ID: Microsoft-Windows-32bit-WindowsPE > Processor: > > Python: > Implementation: Python > Executable: c:\python25\python.exe > Version: 2.5.1 > Compiler: MSC v.1310 32 bit (Intel) > Bits: 32bit > Build: Apr 18 2007 08:51:08 (#r251:54863) > Unicode: UCS2 > > > Test minimum run-time average run-time > this other diff this other diff > ------------------------------------------------------------------------------- > BuiltinFunctionCalls: 44ms 181ms -75.7% 48ms 182ms -73.7% > BuiltinMethodLookup: 335ms 160ms +109.1% 344ms 162ms +112.0% > CompareFloats: 99ms 111ms -11.3% 105ms 112ms -6.0% > CompareFloatsIntegers: 63ms 125ms -49.7% 65ms 126ms -48.7% > CompareIntegers: 102ms 114ms -10.4% 105ms 115ms -8.9% > CompareInternedStrings: 175ms 126ms +39.0% 180ms 127ms +41.6% > CompareLongs: 111ms 105ms +5.3% 114ms 106ms +7.2% > CompareStrings: 167ms 126ms +32.7% 172ms 127ms +35.1% > CompareUnicode: 121ms 125ms -3.4% 123ms 126ms -2.0% > ConcatStrings: 482ms 272ms +77.2% 533ms 275ms +93.4% > ConcatUnicode: 305ms 216ms +41.0% 350ms 217ms +61.5% > CreateInstances: 102ms 148ms -31.1% 106ms 149ms -28.9% > CreateNewInstances: 326ms 131ms +148.0% 335ms 133ms +151.9% > CreateStringsWithConcat: 228ms 147ms +55.9% 238ms 148ms +61.0% > CreateUnicodeWithConcat: 91ms 154ms -41.2% 94ms 157ms -40.4% > DictCreation: 137ms 105ms +30.0% 143ms 106ms +33.9% > DictWithFloatKeys: 301ms 230ms +30.8% 306ms 232ms +32.0% > DictWithIntegerKeys: 343ms 106ms +223.0% 351ms 108ms +224.7% > DictWithStringKeys: 388ms 102ms +282.1% 395ms 102ms +285.1% > ForLoops: 39ms 95ms -59.0% 40ms 97ms -58.5% > IfThenElse: 35ms 111ms -68.9% 37ms 112ms -66.8% > ListSlicing: 468ms 155ms +201.3% 477ms 157ms +204.4% > NestedForLoops: 55ms 120ms -54.1% 57ms 122ms -53.0% > NormalClassAttribute: 276ms 127ms +117.7% 282ms 129ms +119.7% > NormalInstanceAttribute: 106ms 119ms -11.0% 109ms 120ms -9.7% > PythonFunctionCalls: 37ms 130ms -71.7% 40ms 131ms -69.5% > PythonMethodCalls: 127ms 158ms -19.6% 132ms 159ms -16.8% > Recursion: 49ms 177ms -72.5% 50ms 179ms -71.8% > SecondImport: 189ms 126ms +50.4% 195ms 127ms +53.6% > SecondPackageImport: 196ms 134ms +45.8% 202ms 136ms +48.5% > SecondSubmoduleImport: 266ms 177ms +50.6% 272ms 180ms +51.3% > SimpleComplexArithmetic: 97ms 148ms -34.4% 101ms 149ms -32.0% > SimpleDictManipulation: 311ms 118ms +164.4% 318ms 118ms +168.0% > SimpleFloatArithmetic: 64ms 119ms -46.6% 69ms 121ms -43.2% > SimpleIntFloatArithmetic: 41ms 100ms -59.4% 43ms 102ms -58.2% > SimpleIntegerArithmetic: 43ms 100ms -57.2% 44ms 101ms -56.4% > SimpleListManipulation: 121ms 104ms +16.6% 124ms 105ms +18.3% > SimpleLongArithmetic: 126ms 113ms +11.2% 131ms 115ms +14.1% > SmallLists: 223ms 154ms +45.0% 229ms 156ms +47.0% > SmallTuples: 508ms 144ms +252.2% 523ms 145ms +259.7% > SpecialClassAttribute: 275ms 124ms +121.2% 283ms 126ms +124.5% > SpecialInstanceAttribute: 105ms 210ms -50.1% 109ms 212ms -48.5% > StringMappings: 342ms 633ms -46.0% 351ms 637ms -44.9% > StringPredicates: 222ms 217ms +2.3% 228ms 219ms +4.4% > StringSlicing: 245ms 162ms +51.4% 260ms 163ms +59.4% > TryExcept: 7ms 100ms -93.4% 11ms 102ms -89.4% > TryRaiseExcept: 3413ms 114ms +2896.2% 3453ms 115ms +2910.6% > TupleSlicing: 227ms 150ms +51.6% 235ms 151ms +54.9% > UnicodeMappings: 227ms 126ms +79.6% 233ms 129ms +81.4% > UnicodePredicates: 218ms 129ms +68.8% 224ms 132ms +70.4% > UnicodeSlicing: 211ms 182ms +15.8% 223ms 184ms +21.3% > ------------------------------------------------------------------------------- > Totals: 12781ms 7659ms +66.9% 13191ms 7741ms +70.4% > > (this=ipy11.pybench, other=py25.pybench) > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From fuzzyman at voidspace.org.uk Sun Apr 22 16:19:19 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 22 Apr 2007 15:19:19 +0100 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: <462B6DFF.4010907@voidspace.org.uk> References: <4629B48C.40107@twinsun.com> <462B6DFF.4010907@voidspace.org.uk> Message-ID: <462B6EE7.2010009@voidspace.org.uk> Michael Foord wrote: > Jim Hugunin wrote: > >> I'd like to point out one fact about these benchmarks that seems to have been missed. Seo's numbers are for running IronPython 1.1 on Mono - not on the Microsoft .NET implementation. The Mono team has done excellent work with that project, but today the performance of the .NET implementation is still significantly better and is a much better platform for benchmarking IronPython's performance. >> >> > And on close examination the results are impressive. Nice one. > > The anomaly with raising exceptions is very weird though (IronPython is > around 30 times slower!) : > > TryExcept: 7ms 100ms -93.4% 11ms 102ms -89.4% > TryRaiseExcept: 3413ms 114ms +2896.2% 3453ms 115ms +2910.6% > Sorry for all the emails - I see that you addressed this in your comments Jim. Michael > All the best, > > Michael Foord > > > >> I reran pybench on my laptop tonight on the RTM version of .NET that ships with Windows Vista - and has been available for XP for quite some time now. I compared with CPython-2.5.1 (the latest version). >> >> Running on .NET, I find that IronPython is faster on some tests and CPython is faster on others. We know that we still have performance work to do. After all, IronPython just reached its 1.1 release and almost all of our recent work has been about compatibility and completeness. However, the story is already quite interesting. Out of the 51 tests in pybench, CPython is more than 2x faster on 10 of the tests and IronPython is more than 2x faster on 9 of the tests. Depending on what your code does, either implementation could run faster. >> >> The most interesting cases to me are the 5 tests where CPython is more than 3x faster than IronPython and the other 5 tests where IronPython is more than 3x faster than CPython. CPython's strongest performance is in dictionaries with integer and string keys, list slicing, small tuples and code that actually throws and catches exceptions. IronPython's strongest performance is in calling builtin functions, if/then/else blocks, calling python functions, deep recursion, and try/except blocks that don't actually catch an exception. >> >> The places where IronPython is performing strongest are where it can use the .NET code generation and JIT optimization most effectively. The places where it is slowest are mainly in runtime library implementation of core datatypes. CPython's list and dictionary datatypes are written in C and have been hand-tuned for Python-style workloads over the past 10 years. IronPython's datatypes are much newer and clearly need more tuning as the implementation matures. >> >> The only two tests that really stand out as showing a deep performance issue are the two exception handling ones. These are the only tests where either implementation is more than 4x faster than the other. IronPython is 10x faster on the try/catch without an exception and CPython is 30x faster when an exception is actually raised. This is a deliberate design decision within .NET to make code that doesn't throw exceptions run faster - even if that means slowing down code that does throw exceptions. I'm fairly confident this was the right decision - and even remember the day long ago when Guido was discussing Python's exception system and explained that he'd accept almost any slow-down to the exceptional case in return for removing a single instruction from the non-exceptional path. >> >> Thanks - Jim >> >> My results >> ------------------------------------------------------------------------------- >> PYBENCH 2.0 >> ------------------------------------------------------------------------------- >> * using Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Int >> el)] >> * disabled garbage collection >> * system check interval set to maximum: 2147483647 >> * using timer: time.clock >> >> ------------------------------------------------------------------------------- >> Benchmark: ipy11.pybench >> ------------------------------------------------------------------------------- >> >> Rounds: 10 >> Warp: 10 >> Timer: time.time >> >> Machine Details: >> Platform ID: cli-32bit >> Processor: >> >> Python: >> Implementation: Python >> Executable: c:\ironpython-1.1\ipy.exe >> Version: 1.1.0 >> Compiler: X >> Bits: 32bit >> Build: 0 0 (#0) >> Unicode: UCS2 >> >> >> ------------------------------------------------------------------------------- >> Comparing with: py25.pybench >> ------------------------------------------------------------------------------- >> >> Rounds: 10 >> Warp: 10 >> Timer: time.clock >> >> Machine Details: >> Platform ID: Microsoft-Windows-32bit-WindowsPE >> Processor: >> >> Python: >> Implementation: Python >> Executable: c:\python25\python.exe >> Version: 2.5.1 >> Compiler: MSC v.1310 32 bit (Intel) >> Bits: 32bit >> Build: Apr 18 2007 08:51:08 (#r251:54863) >> Unicode: UCS2 >> >> >> Test minimum run-time average run-time >> this other diff this other diff >> ------------------------------------------------------------------------------- >> BuiltinFunctionCalls: 44ms 181ms -75.7% 48ms 182ms -73.7% >> BuiltinMethodLookup: 335ms 160ms +109.1% 344ms 162ms +112.0% >> CompareFloats: 99ms 111ms -11.3% 105ms 112ms -6.0% >> CompareFloatsIntegers: 63ms 125ms -49.7% 65ms 126ms -48.7% >> CompareIntegers: 102ms 114ms -10.4% 105ms 115ms -8.9% >> CompareInternedStrings: 175ms 126ms +39.0% 180ms 127ms +41.6% >> CompareLongs: 111ms 105ms +5.3% 114ms 106ms +7.2% >> CompareStrings: 167ms 126ms +32.7% 172ms 127ms +35.1% >> CompareUnicode: 121ms 125ms -3.4% 123ms 126ms -2.0% >> ConcatStrings: 482ms 272ms +77.2% 533ms 275ms +93.4% >> ConcatUnicode: 305ms 216ms +41.0% 350ms 217ms +61.5% >> CreateInstances: 102ms 148ms -31.1% 106ms 149ms -28.9% >> CreateNewInstances: 326ms 131ms +148.0% 335ms 133ms +151.9% >> CreateStringsWithConcat: 228ms 147ms +55.9% 238ms 148ms +61.0% >> CreateUnicodeWithConcat: 91ms 154ms -41.2% 94ms 157ms -40.4% >> DictCreation: 137ms 105ms +30.0% 143ms 106ms +33.9% >> DictWithFloatKeys: 301ms 230ms +30.8% 306ms 232ms +32.0% >> DictWithIntegerKeys: 343ms 106ms +223.0% 351ms 108ms +224.7% >> DictWithStringKeys: 388ms 102ms +282.1% 395ms 102ms +285.1% >> ForLoops: 39ms 95ms -59.0% 40ms 97ms -58.5% >> IfThenElse: 35ms 111ms -68.9% 37ms 112ms -66.8% >> ListSlicing: 468ms 155ms +201.3% 477ms 157ms +204.4% >> NestedForLoops: 55ms 120ms -54.1% 57ms 122ms -53.0% >> NormalClassAttribute: 276ms 127ms +117.7% 282ms 129ms +119.7% >> NormalInstanceAttribute: 106ms 119ms -11.0% 109ms 120ms -9.7% >> PythonFunctionCalls: 37ms 130ms -71.7% 40ms 131ms -69.5% >> PythonMethodCalls: 127ms 158ms -19.6% 132ms 159ms -16.8% >> Recursion: 49ms 177ms -72.5% 50ms 179ms -71.8% >> SecondImport: 189ms 126ms +50.4% 195ms 127ms +53.6% >> SecondPackageImport: 196ms 134ms +45.8% 202ms 136ms +48.5% >> SecondSubmoduleImport: 266ms 177ms +50.6% 272ms 180ms +51.3% >> SimpleComplexArithmetic: 97ms 148ms -34.4% 101ms 149ms -32.0% >> SimpleDictManipulation: 311ms 118ms +164.4% 318ms 118ms +168.0% >> SimpleFloatArithmetic: 64ms 119ms -46.6% 69ms 121ms -43.2% >> SimpleIntFloatArithmetic: 41ms 100ms -59.4% 43ms 102ms -58.2% >> SimpleIntegerArithmetic: 43ms 100ms -57.2% 44ms 101ms -56.4% >> SimpleListManipulation: 121ms 104ms +16.6% 124ms 105ms +18.3% >> SimpleLongArithmetic: 126ms 113ms +11.2% 131ms 115ms +14.1% >> SmallLists: 223ms 154ms +45.0% 229ms 156ms +47.0% >> SmallTuples: 508ms 144ms +252.2% 523ms 145ms +259.7% >> SpecialClassAttribute: 275ms 124ms +121.2% 283ms 126ms +124.5% >> SpecialInstanceAttribute: 105ms 210ms -50.1% 109ms 212ms -48.5% >> StringMappings: 342ms 633ms -46.0% 351ms 637ms -44.9% >> StringPredicates: 222ms 217ms +2.3% 228ms 219ms +4.4% >> StringSlicing: 245ms 162ms +51.4% 260ms 163ms +59.4% >> TryExcept: 7ms 100ms -93.4% 11ms 102ms -89.4% >> TryRaiseExcept: 3413ms 114ms +2896.2% 3453ms 115ms +2910.6% >> TupleSlicing: 227ms 150ms +51.6% 235ms 151ms +54.9% >> UnicodeMappings: 227ms 126ms +79.6% 233ms 129ms +81.4% >> UnicodePredicates: 218ms 129ms +68.8% 224ms 132ms +70.4% >> UnicodeSlicing: 211ms 182ms +15.8% 223ms 184ms +21.3% >> ------------------------------------------------------------------------------- >> Totals: 12781ms 7659ms +66.9% 13191ms 7741ms +70.4% >> >> (this=ipy11.pybench, other=py25.pybench) >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From sanxiyn at gmail.com Sun Apr 22 16:35:29 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sun, 22 Apr 2007 23:35:29 +0900 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: References: <4629B48C.40107@twinsun.com> Message-ID: <5b0248170704220735g355d6467k63fb81aa2bb0c875@mail.gmail.com> 2007/4/22, Jim Hugunin : > I'd like to point out one fact about these benchmarks that seems to have been missed. Seo's numbers are for running IronPython 1.1 on Mono - not on the Microsoft .NET implementation. The Mono team has done excellent work with that project, but today the performance of the .NET implementation is still significantly better and is a much better platform for benchmarking IronPython's performance. I never tried to claim otherwise. Perhaps I should have been more explicit. > I reran pybench on my laptop tonight on the RTM version of .NET that ships with Windows Vista - and has been available for XP for quite some time now. I compared with CPython-2.5.1 (the latest version). > (snip) Can you provide the raw pybench result files? I can host it on my site side-by-side with Mono results. -- Seo Sanghyeon From sanxiyn at gmail.com Sun Apr 22 17:27:41 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 23 Apr 2007 00:27:41 +0900 Subject: [IronPython] Microsoft .NET vs. Mono on running IronPython Message-ID: <5b0248170704220827xb8fcccdl7a7edc08ac8ffaf@mail.gmail.com> As Jim published pybench results running on Microsoft .NET (Thanks, Jim!), we can now compare Microsoft .NET with Mono on performance of running IronPython. We always assumed .NET is faster than Mono, but how do they compare in details? As Jim's results were against CPython 2.5, I will use the result against CPython 2.5 too. Let's assume that CPython 2.5's performance characteristics are same on both Windows ans Linux, that is, Windows CPython 2.5 doesn't perform (say) integer arithmetics faster than Linux CPython 2.5. This could be wrong, for example, Visual C++ maybe optimize better than GCC, or vice versa. Indeed, if I compare Windows CPython 2.5 numbers and Linux CPython 2.5 numbers, Windows CPython 2.5 is ~1.2 times faster, most likely because Jim's laptop is faster. With a single exception. StringMappings test, calling .upper() and .lower() methods on string, is 4 times faster on Linux. This could be glibc doing smart optimization. I decided to exclude this test in comparisons below. Numbers below are for minimum runtime. Summary: >From these tests, Mono seems to perform comparisons and exception handlings better than .NET for running IronPython. Mono is 6 times slower on string and unicode concatenation and 4 times slower on slicing. It's also 3 to 4 times slower on IronPython instance creation. # Transcript mono = [[168, 214], [538, 207], [81, 153], [61, 159], [105, 139], [134, 168], [145, 123], [208, 170], [157, 155], [3626, 314], [2166, 244], [273, 194], [1260, 171], [1071, 180], [402, 192], [678, 148], [362, 245], [467, 138], [521, 148], [69, 110], [38, 126], [1369, 141], [108, 153], [413, 172], [143, 149], [114, 184], [190, 221], [57, 264], [506, 163], [507, 168], [721, 210], [254, 153], [458, 148], [193, 170], [57, 125], [57, 132], [176, 139], [372, 158], [583, 162], [1452, 152], [413, 169], [143, 271], [377, 198], [1097, 179], [6, 103], [2680, 136], [619, 161], [302, 147], [324, 176], [977, 197]] net = [[44, 181], [335, 160], [99, 111], [63, 125], [102, 114], [175, 126], [111, 105], [167, 126], [121, 125], [482, 272], [305, 216], [102, 148], [326, 131], [228, 147], [91, 154], [137, 105], [301, 230], [343, 106], [388, 102], [39, 95], [35, 111], [468, 155], [55, 120], [276, 127], [106, 119], [37, 130], [127, 158], [49, 177], [189, 126], [196, 134], [266, 177], [97, 148], [311, 118], [64, 119], [41, 100], [43, 100], [121, 104], [126, 113], [223, 154], [508, 144], [275, 124], [105, 210], [222, 217], [245, 162], [7, 100], [3413, 114], [227, 150], [227, 126], [218, 129], [211, 182]] # Linux IronPython against Windows IronPython, adjusted by multiplying Windows CPython against Linux CPython. k = [float(li)/wi*wc/lc for ((li, lc), (wi, wc)) in zip(mono, net)] # How many tests Mono run fast? >>> len([1 for x in k if x < 1]) 10 These tests are: CompareFloats, CompareFloatsIntegers, CompareIntegers, CompareInternedStrings, CompareStrings, DictWithStringKeys, IfThenElse, Recursion, TryExcept, TryRaiseExcept. # And .NET? >>> len([1 for x in k if x > 1]) 40 Well, sure. # How many tests .NET run more than two times faster? >>> len([1 for x in k if x > 2]) 21 # Three times? >>> len([1 for x in k if x > 2]) 9 These tests, embarassing for Mono are: BuiltinFunctionCalls, ConcatStrings, ConcatUnicode, CreateInstances, CreateNewInstances, CreateStringsWithConcat, ListSlicing, StringSlicing, UnicodeSlicing. -- Seo Sanghyeon From Jim.Hugunin at microsoft.com Sun Apr 22 20:50:41 2007 From: Jim.Hugunin at microsoft.com (Jim Hugunin) Date: Sun, 22 Apr 2007 11:50:41 -0700 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: <5b0248170704220735g355d6467k63fb81aa2bb0c875@mail.gmail.com> References: <4629B48C.40107@twinsun.com> <5b0248170704220735g355d6467k63fb81aa2bb0c875@mail.gmail.com> Message-ID: Hi Seo, I saw nothing wrong with your original post. I had just noticed that others on the list were taking these numbers as indicative of expected IronPython performance anywhere and I wanted to be sure that they could also see the numbers on .NET for the rest of the story. Trying to understand these numbers and use the relative performance to help improve all of the different implementations out there can only be a good thing. Often these kinds of discrepancies can help identify low-hanging fruit for performance optimizations. I know that we're going to be looking at our dictionaries and our slicing operation in much more detail during the next performance push. I also remember that IronPython-0.6's poor performance on try/raise/except was noted by the Mono team - at the time, Mono was 10x slower than the already slow .NET here. I believe that this was the original motivation for the performance improvements to that Mono path that now make it even faster than .NETs. In the spirit of more data, I've attached my raw results files for you in case they help with your comparisons. My results are on a ThinkPad X60 laptop with an intel T2400 1.83 GHz core duo processor and 1.5GB of RAM running Windows Vista. Thanks - Jim -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Sunday, April 22, 2007 7:35 AM To: Discussion of IronPython Subject: Re: [IronPython] pybench results for CPython and IronPython 2007/4/22, Jim Hugunin : > I'd like to point out one fact about these benchmarks that seems to have been missed. Seo's numbers are for running IronPython 1.1 on Mono - not on the Microsoft .NET implementation. The Mono team has done excellent work with that project, but today the performance of the .NET implementation is still significantly better and is a much better platform for benchmarking IronPython's performance. I never tried to claim otherwise. Perhaps I should have been more explicit. > I reran pybench on my laptop tonight on the RTM version of .NET that ships with Windows Vista - and has been available for XP for quite some time now. I compared with CPython-2.5.1 (the latest version). > (snip) Can you provide the raw pybench result files? I can host it on my site side-by-side with Mono results. -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- A non-text attachment was scrubbed... Name: py25.pybench Type: application/octet-stream Size: 49233 bytes Desc: py25.pybench URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipy11.pybench Type: application/octet-stream Size: 44667 bytes Desc: ipy11.pybench URL: From miguel at novell.com Sun Apr 22 19:58:27 2007 From: miguel at novell.com (Miguel de Icaza) Date: Sun, 22 Apr 2007 13:58:27 -0400 Subject: [IronPython] Microsoft .NET vs. Mono on running IronPython In-Reply-To: <5b0248170704220827xb8fcccdl7a7edc08ac8ffaf@mail.gmail.com> References: <5b0248170704220827xb8fcccdl7a7edc08ac8ffaf@mail.gmail.com> Message-ID: <1177264707.21140.57.camel@mirrors.mathematik.uni-bielefeld.de> Hello, > Indeed, if I compare Windows CPython 2.5 numbers and Linux CPython 2.5 > numbers, Windows CPython 2.5 is ~1.2 times faster, most likely because > Jim's laptop is faster. With a single exception. StringMappings test, > calling .upper() and .lower() methods on string, is 4 times faster on > Linux. This could be glibc doing smart optimization. I decided to > exclude this test in comparisons below. Our ToUpper and ToLower implementations are completely managed, as the unicode rules for .NET are slightly different than the standard Unicode ones (Windows unicode string rules predated Unicode). Since this is managed code, and managed code tends to be slower than C++ code, my guesses are: * Mono is not taking something important into consideration. Possible, but doubtful at this point. * .NET's implementation lives in C++ and the overhead is probably due to the managed to unmanaged transition. For example, memset/memcpy are typically faster if written in managed code for blocks of up to 16k bytes or so (I forget the details, but they are in some mailing list). Miguel. From sanxiyn at gmail.com Mon Apr 23 02:33:00 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 23 Apr 2007 09:33:00 +0900 Subject: [IronPython] Microsoft .NET vs. Mono on running IronPython In-Reply-To: <1177264707.21140.57.camel@mirrors.mathematik.uni-bielefeld.de> References: <5b0248170704220827xb8fcccdl7a7edc08ac8ffaf@mail.gmail.com> <1177264707.21140.57.camel@mirrors.mathematik.uni-bielefeld.de> Message-ID: <5b0248170704221733m1fa5ed2k6843dcc0d37b46@mail.gmail.com> 2007/4/23, Miguel de Icaza : > Our ToUpper and ToLower implementations are completely managed, as the > unicode rules for .NET are slightly different than the standard Unicode > ones (Windows unicode string rules predated Unicode). Eh, you misunderstood. .upper() and .lower() methods speed comparison was between Windows CPython and Linux CPython, where CLR runtime doesn't enter the picture at all. -- Seo Sanghyeon From tony at v-sim.com Mon Apr 23 21:35:53 2007 From: tony at v-sim.com (Tony Djordjevski) Date: Mon, 23 Apr 2007 15:35:53 -0400 Subject: [IronPython] wierd import problem Message-ID: <462D0A99.7080705@v-sim.com> Hi everyone, I'm seeing a bit of weirdness when trying to import a dll with a nested namespace. Actually, I'm not sure if it's a filename issue or a namespace issue, as the filename of the assembly is named after the namespace. OK, let's say I have two assemblies: Foo.exe and Foo.Bar.dll (I've attached a simple Visual Studio project to recreate the situation) I want to "import Foo.Bar", but I'm getting an error concerning Foo.exe Here's the steps to reproduce: >>> import clr >>> clr.AddReferenceToFile('Foo.Bar.dll') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> for ref in clr.References: ... print ref ... mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Foo.Bar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null >>> As the output shows, Foo.Bar has been referenced. So what am I doing wrong that I can't import? BTW, I'm using IP v1.1 (in case you're wondering). Thanks, Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: Foo.zip Type: application/zip Size: 5011 bytes Desc: not available URL: From edfialk at gmail.com Mon Apr 23 22:31:41 2007 From: edfialk at gmail.com (edfialk) Date: Mon, 23 Apr 2007 20:31:41 -0000 Subject: [IronPython] script for seconds in given month, year Message-ID: <1177360301.770353.249870@n76g2000hsh.googlegroups.com> Hello, I'm looking for a way to provide month and year, and return the number of seconds in that month. My range will be roughly from 01/01/1960 to 12/31/2000 for now. I originally thought we would be working with regular Python and asked in the Python group, to which I got a great, working Python script: import calendar def seconds_in_month(month, year): nomatter, daysinmonth = calendar.monthrange(year, month) return daysinmonth * 24 * 60 * 60 Unfortunately, in IronPython the calendar module does not import: SyntaxError: unexpected token TimeEncoding (c:\Python25\Lib \calendar.py, line 510) So, does anyone happen to know of a script that could perform this in IronPython? Any help would be greatly appreciated. Thanks! -Ed From dinov at exchange.microsoft.com Mon Apr 23 22:41:24 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 23 Apr 2007 13:41:24 -0700 Subject: [IronPython] script for seconds in given month, year In-Reply-To: <1177360301.770353.249870@n76g2000hsh.googlegroups.com> References: <1177360301.770353.249870@n76g2000hsh.googlegroups.com> Message-ID: <7AD436E4270DD54A94238001769C22278F0E96CB04@DF-GRTDANE-MSG.exchange.corp.microsoft.com> What version of IronPython are you using? This works for me w/ IronPython v1.1 and the 2.4 libs or the 2.5 libs when running with the -X:Python25 command line option. W/ v1.1 w/o -X:Python25 I get: SyntaxError: future feature is not defined: with_statement (F:\Product\Merlin\External\Languages\IronPython20\25\Lib\calendar.py, line 8) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of edfialk Sent: Monday, April 23, 2007 1:32 PM To: users at lists.ironpython.com Subject: [IronPython] script for seconds in given month, year Hello, I'm looking for a way to provide month and year, and return the number of seconds in that month. My range will be roughly from 01/01/1960 to 12/31/2000 for now. I originally thought we would be working with regular Python and asked in the Python group, to which I got a great, working Python script: import calendar def seconds_in_month(month, year): nomatter, daysinmonth = calendar.monthrange(year, month) return daysinmonth * 24 * 60 * 60 Unfortunately, in IronPython the calendar module does not import: SyntaxError: unexpected token TimeEncoding (c:\Python25\Lib \calendar.py, line 510) So, does anyone happen to know of a script that could perform this in IronPython? Any help would be greatly appreciated. Thanks! -Ed _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Mon Apr 23 22:49:13 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 23 Apr 2007 13:49:13 -0700 Subject: [IronPython] wierd import problem In-Reply-To: <462D0A99.7080705@v-sim.com> References: <462D0A99.7080705@v-sim.com> Message-ID: <7AD436E4270DD54A94238001769C22278F0E96CB15@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I haven't had a chance to track down what the underlying problem here is (and suspect this is a bug), but is there a reason you can't do: >>> import clr >>> clr.AddReference('Foo.bar.dll') >>> import Foo.Bar This seems to work. The only reason to use AddReferenceToFile is really if you are dealing with assemblies that live outside of your app domain base. In that case AddReferenceToFile will attempt to use sys.path to search for referenced assemblies when the CLR loader attempts to load them. But if you're using this DLL from within your app domain base then doing AddReference will cause the CLR to do an Assembly.Load('foo.bar.dll') which will succeed and also get the dependencies using the standard .NET way. Let me know if this is a reasonable workaround for you and I'll continue to look into the underlying issue here. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski Sent: Monday, April 23, 2007 12:36 PM To: users at lists.ironpython.com Subject: [IronPython] wierd import problem Hi everyone, I'm seeing a bit of weirdness when trying to import a dll with a nested namespace. Actually, I'm not sure if it's a filename issue or a namespace issue, as the filename of the assembly is named after the namespace. OK, let's say I have two assemblies: Foo.exe and Foo.Bar.dll (I've attached a simple Visual Studio project to recreate the situation) I want to "import Foo.Bar", but I'm getting an error concerning Foo.exe Here's the steps to reproduce: >>> import clr >>> clr.AddReferenceToFile('Foo.Bar.dll') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> for ref in clr.References: ... print ref ... mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Foo.Bar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null >>> As the output shows, Foo.Bar has been referenced. So what am I doing wrong that I can't import? BTW, I'm using IP v1.1 (in case you're wondering). Thanks, Tony From tony at v-sim.com Mon Apr 23 23:14:59 2007 From: tony at v-sim.com (Tony Djordjevski) Date: Mon, 23 Apr 2007 17:14:59 -0400 Subject: [IronPython] wierd import problem In-Reply-To: <7AD436E4270DD54A94238001769C22278F0E96CB15@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <462D0A99.7080705@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB15@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <462D21D3.1080902@v-sim.com> Hi Dino, Sorry, I should have mentioned in my original post that I've already tried to get it to work with all the AddReference* methods. AddReferenceToFile was just the last example that I tried at the time I sent the original post. Currently I'm still getting the same error. I've even tried variations on the assembly name (Foo.Bar.dll vs. Foo.Bar) and the AddReference always seems to work, it's just that the import has problems. I've just tried the example on another computer, and it's showing the same issue. Thanks for the help, Tony Dino Viehland wrote: > I haven't had a chance to track down what the underlying problem here is (and suspect this is a bug), but is there a reason you can't do: > >>>> import clr >>>> clr.AddReference('Foo.bar.dll') >>>> import Foo.Bar > > This seems to work. The only reason to use AddReferenceToFile is really if you are dealing with assemblies that live outside of your app domain base. In that case AddReferenceToFile will attempt to use sys.path to search for referenced assemblies when the CLR loader attempts to load them. > > But if you're using this DLL from within your app domain base then doing AddReference will cause the CLR to do an Assembly.Load('foo.bar.dll') which will succeed and also get the dependencies using the standard .NET way. > > Let me know if this is a reasonable workaround for you and I'll continue to look into the underlying issue here. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski > Sent: Monday, April 23, 2007 12:36 PM > To: users at lists.ironpython.com > Subject: [IronPython] wierd import problem > > Hi everyone, > > I'm seeing a bit of weirdness when trying to import a dll with a nested namespace. Actually, I'm not sure if it's a filename issue or a namespace issue, as the filename of the assembly is named after the namespace. > > OK, let's say I have two assemblies: Foo.exe and Foo.Bar.dll (I've attached a simple Visual Studio project to recreate the situation) > > I want to "import Foo.Bar", but I'm getting an error concerning Foo.exe > > Here's the steps to reproduce: > > >>> import clr > >>> clr.AddReferenceToFile('Foo.Bar.dll') > >>> import Foo.Bar > Traceback (most recent call last): > File , line 0, in ##14 > File , line 0, in __import__##7 > SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. > >>> for ref in clr.References: > ... print ref > ... > mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Foo.Bar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null >>> > > As the output shows, Foo.Bar has been referenced. So what am I doing wrong that I can't import? > > BTW, I'm using IP v1.1 (in case you're wondering). > > Thanks, > Tony > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at exchange.microsoft.com Mon Apr 23 23:24:38 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 23 Apr 2007 14:24:38 -0700 Subject: [IronPython] wierd import problem In-Reply-To: <462D21D3.1080902@v-sim.com> References: <462D0A99.7080705@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB15@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <462D21D3.1080902@v-sim.com> Message-ID: <7AD436E4270DD54A94238001769C22278F0E96CB6E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Oh, it seems to be the presence of the '.dll' in the filename (although I still haven't looked too deeply to understand the exception). See below for the 3 different variations I've tried. The .NET loader will append .dll/.exe for you automatically. F:\repro\foo\Foo\bin\Debug>dir Volume in drive F is New Volume Volume Serial Number is F62E-82C1 Directory of F:\repro\foo\Foo\bin\Debug 04/23/2007 01:45 PM . 04/23/2007 01:45 PM .. 04/23/2007 01:42 PM 4,096 Foo.Bar.dll 04/23/2007 01:42 PM 11,776 Foo.Bar.pdb 04/23/2007 01:42 PM 4,096 Foo.exe 04/23/2007 01:42 PM 11,776 Foo.pdb 04/10/2007 10:17 AM 71,016 ipy.exe 04/10/2007 10:17 AM 62,824 ipyw.exe 04/10/2007 10:17 AM 50,536 IronMath.dll 04/10/2007 10:17 AM 1,373,544 IronPython.dll 04/23/2007 01:45 PM tmp 8 File(s) 1,589,664 bytes 3 Dir(s) 35,566,551,040 bytes free F:\repro\foo\Foo\bin\Debug>.\ipy.exe IronPython 1.1 (1.1) on .NET 2.0.50727.1318 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReferenceToFile('Foo.bar.dll') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> ^Z F:\repro\foo\Foo\bin\Debug>.\ipy.exe IronPython 1.1 (1.1) on .NET 2.0.50727.1318 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference('Foo.bar.dll') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> ^Z F:\repro\foo\Foo\bin\Debug>ipyd IronPython console: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1318 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference('foo.bar') >>> import Foo.Bar >>> dir(Foo.Bar) ['Bar'] >>> -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski Sent: Monday, April 23, 2007 2:15 PM To: Discussion of IronPython Subject: Re: [IronPython] wierd import problem Hi Dino, Sorry, I should have mentioned in my original post that I've already tried to get it to work with all the AddReference* methods. AddReferenceToFile was just the last example that I tried at the time I sent the original post. Currently I'm still getting the same error. I've even tried variations on the assembly name (Foo.Bar.dll vs. Foo.Bar) and the AddReference always seems to work, it's just that the import has problems. I've just tried the example on another computer, and it's showing the same issue. Thanks for the help, Tony Dino Viehland wrote: > I haven't had a chance to track down what the underlying problem here is (and suspect this is a bug), but is there a reason you can't do: > >>>> import clr >>>> clr.AddReference('Foo.bar.dll') >>>> import Foo.Bar > > This seems to work. The only reason to use AddReferenceToFile is really if you are dealing with assemblies that live outside of your app domain base. In that case AddReferenceToFile will attempt to use sys.path to search for referenced assemblies when the CLR loader attempts to load them. > > But if you're using this DLL from within your app domain base then doing AddReference will cause the CLR to do an Assembly.Load('foo.bar.dll') which will succeed and also get the dependencies using the standard .NET way. > > Let me know if this is a reasonable workaround for you and I'll continue to look into the underlying issue here. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski > Sent: Monday, April 23, 2007 12:36 PM > To: users at lists.ironpython.com > Subject: [IronPython] wierd import problem > > Hi everyone, > > I'm seeing a bit of weirdness when trying to import a dll with a nested namespace. Actually, I'm not sure if it's a filename issue or a namespace issue, as the filename of the assembly is named after the namespace. > > OK, let's say I have two assemblies: Foo.exe and Foo.Bar.dll (I've attached a simple Visual Studio project to recreate the situation) > > I want to "import Foo.Bar", but I'm getting an error concerning Foo.exe > > Here's the steps to reproduce: > > >>> import clr > >>> clr.AddReferenceToFile('Foo.Bar.dll') > >>> import Foo.Bar > Traceback (most recent call last): > File , line 0, in ##14 > File , line 0, in __import__##7 > SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. > >>> for ref in clr.References: > ... print ref > ... > mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Foo.Bar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null >>> > > As the output shows, Foo.Bar has been referenced. So what am I doing wrong that I can't import? > > BTW, I'm using IP v1.1 (in case you're wondering). > > Thanks, > Tony > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From simon.dahlbacka at gmail.com Mon Apr 23 23:28:44 2007 From: simon.dahlbacka at gmail.com (Simon Dahlbacka) Date: Tue, 24 Apr 2007 00:28:44 +0300 Subject: [IronPython] wierd import problem In-Reply-To: <7AD436E4270DD54A94238001769C22278F0E96CB6E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <462D0A99.7080705@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB15@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <462D21D3.1080902@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB6E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <57124720704231428y5e2d8d6fr3fd3096f390dd0d7@mail.gmail.com> On 4/24/07, Dino Viehland wrote: > Oh, it seems to be the presence of the '.dll' in the filename (although I > still haven't looked too deeply to understand the exception). See below for > the 3 different variations I've tried. The .NET loader will append > .dll/.exe for you automatically. > > F:\repro\foo\Foo\bin\Debug>dir > Volume in drive F is New Volume > Volume Serial Number is F62E-82C1 > > Directory of F:\repro\foo\Foo\bin\Debug > > 04/23/2007 01:45 PM . > 04/23/2007 01:45 PM .. > 04/23/2007 01:42 PM 4,096 Foo.Bar.dll > 04/23/2007 01:42 PM 11,776 Foo.Bar.pdb > 04/23/2007 01:42 PM 4,096 Foo.exe > 04/23/2007 01:42 PM 11,776 Foo.pdb > 04/10/2007 10:17 AM 71,016 ipy.exe > 04/10/2007 10:17 AM 62,824 ipyw.exe > 04/10/2007 10:17 AM 50,536 IronMath.dll > 04/10/2007 10:17 AM 1,373,544 IronPython.dll > 04/23/2007 01:45 PM tmp > 8 File(s) 1,589,664 bytes > 3 Dir(s) 35,566,551,040 bytes free > > F:\repro\foo\Foo\bin\Debug>.\ipy.exe > IronPython 1.1 (1.1) on .NET 2.0.50727.1318 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import clr > >>> clr.AddReferenceToFile('Foo.bar.dll') > >>> import Foo.Bar > Traceback (most recent call last): > File , line 0, in ##14 > File , line 0, in __import__##7 > SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled > module; try again after deleting it. > >>> ^Z > > F:\repro\foo\Foo\bin\Debug>.\ipy.exe > IronPython 1.1 (1.1) on .NET 2.0.50727.1318 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import clr > >>> clr.AddReference('Foo.bar.dll') > >>> import Foo.Bar > Traceback (most recent call last): > File , line 0, in ##14 > File , line 0, in __import__##7 > SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled > module; try again after deleting it. > >>> ^Z > > F:\repro\foo\Foo\bin\Debug>ipyd > IronPython console: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1318 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import clr > >>> clr.AddReference('foo.bar') > >>> import Foo.Bar > >>> dir(Foo.Bar) > ['Bar'] > >>> Was the switching to another executable intentional? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Mon Apr 23 23:39:39 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 23 Apr 2007 14:39:39 -0700 Subject: [IronPython] wierd import problem In-Reply-To: <57124720704231428y5e2d8d6fr3fd3096f390dd0d7@mail.gmail.com> References: <462D0A99.7080705@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB15@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <462D21D3.1080902@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB6E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <57124720704231428y5e2d8d6fr3fd3096f390dd0d7@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C22278F0E96CB89@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Argh, no it wasn't... thanks for catching that. It looks like it's broken in v1.1 when I use it normally, that must have been what I did wrong before.. Ok, I'll have to look into this one deeper :). From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Simon Dahlbacka Sent: Monday, April 23, 2007 2:29 PM To: Discussion of IronPython Subject: Re: [IronPython] wierd import problem On 4/24/07, Dino Viehland > wrote: Oh, it seems to be the presence of the '.dll' in the filename (although I still haven't looked too deeply to understand the exception). See below for the 3 different variations I've tried. The .NET loader will append .dll/.exe for you automatically. F:\repro\foo\Foo\bin\Debug>dir Volume in drive F is New Volume Volume Serial Number is F62E-82C1 Directory of F:\repro\foo\Foo\bin\Debug 04/23/2007 01:45 PM . 04/23/2007 01:45 PM .. 04/23/2007 01:42 PM 4,096 Foo.Bar.dll 04/23/2007 01:42 PM 11,776 Foo.Bar.pdb 04/23/2007 01:42 PM 4,096 Foo.exe 04/23/2007 01:42 PM 11,776 Foo.pdb 04/10/2007 10:17 AM 71,016 ipy.exe 04/10/2007 10:17 AM 62,824 ipyw.exe 04/10/2007 10:17 AM 50,536 IronMath.dll 04/10/2007 10:17 AM 1,373,544 IronPython.dll 04/23/2007 01:45 PM tmp 8 File(s) 1,589,664 bytes 3 Dir(s) 35,566,551,040 bytes free F:\repro\foo\Foo\bin\Debug>.\ipy.exe IronPython 1.1 (1.1) on .NET 2.0.50727.1318 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReferenceToFile('Foo.bar.dll') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> ^Z F:\repro\foo\Foo\bin\Debug>.\ipy.exe IronPython 1.1 (1.1) on .NET 2.0.50727.1318 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference('Foo.bar.dll') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> ^Z F:\repro\foo\Foo\bin\Debug>ipyd IronPython console: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1318 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference('foo.bar') >>> import Foo.Bar >>> dir(Foo.Bar) ['Bar'] >>> Was the switching to another executable intentional? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at v-sim.com Mon Apr 23 23:43:04 2007 From: tony at v-sim.com (Tony Djordjevski) Date: Mon, 23 Apr 2007 17:43:04 -0400 Subject: [IronPython] wierd import problem In-Reply-To: <7AD436E4270DD54A94238001769C22278F0E96CB6E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <462D0A99.7080705@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB15@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <462D21D3.1080902@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB6E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <462D2868.6010508@v-sim.com> Dino, What's ipyd? I noticed in your example that worked, you ran that instead of ipy. Here's the output I'm getting: C:\Temp\Foo\bin\Debug>dir Volume in drive C has no label. Volume Serial Number is 5454-DE81 Directory of C:\Temp\Foo\bin\Debug 04/23/2007 02:55 PM . 04/23/2007 02:55 PM .. 04/23/2007 02:55 PM 16,384 Foo.Bar.dll 04/23/2007 02:55 PM 11,776 Foo.Bar.pdb 04/23/2007 02:55 PM 16,384 Foo.exe 04/23/2007 02:55 PM 11,776 Foo.pdb 09/23/2005 07:56 AM 5,632 Foo.vshost.exe 04/10/2007 10:17 AM 71,016 ipy.exe 04/10/2007 10:17 AM 62,824 ipyw.exe 04/10/2007 10:17 AM 50,536 IronMath.dll 04/10/2007 10:17 AM 1,373,544 IronPython.dll 9 File(s) 1,619,872 bytes 2 Dir(s) 91,054,919,680 bytes free C:\Temp\Foo\bin\Debug>ipy IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference('Foo.Bar.dll') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> ^Z C:\Temp\Foo\bin\Debug>ipy IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference('Foo.Bar') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> ^Z C:\Temp\Foo\bin\Debug>ipy IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference('foo.bar') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> ^Z The last example was a "shot in the dark" attempt to see if case had anything to do with the AddReference. I didn't actually expect it to work. Dino Viehland wrote: > Oh, it seems to be the presence of the '.dll' in the filename (although I still haven't looked too deeply to understand the exception). See below for the 3 different variations I've tried. The .NET loader will append .dll/.exe for you automatically. > > F:\repro\foo\Foo\bin\Debug>dir > Volume in drive F is New Volume > Volume Serial Number is F62E-82C1 > > Directory of F:\repro\foo\Foo\bin\Debug > > 04/23/2007 01:45 PM . > 04/23/2007 01:45 PM .. > 04/23/2007 01:42 PM 4,096 Foo.Bar.dll > 04/23/2007 01:42 PM 11,776 Foo.Bar.pdb > 04/23/2007 01:42 PM 4,096 Foo.exe > 04/23/2007 01:42 PM 11,776 Foo.pdb > 04/10/2007 10:17 AM 71,016 ipy.exe > 04/10/2007 10:17 AM 62,824 ipyw.exe > 04/10/2007 10:17 AM 50,536 IronMath.dll > 04/10/2007 10:17 AM 1,373,544 IronPython.dll > 04/23/2007 01:45 PM tmp > 8 File(s) 1,589,664 bytes > 3 Dir(s) 35,566,551,040 bytes free > > F:\repro\foo\Foo\bin\Debug>.\ipy.exe > IronPython 1.1 (1.1) on .NET 2.0.50727.1318 > Copyright (c) Microsoft Corporation. All rights reserved. >>>> import clr >>>> clr.AddReferenceToFile('Foo.bar.dll') >>>> import Foo.Bar > Traceback (most recent call last): > File , line 0, in ##14 > File , line 0, in __import__##7 > SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>>> ^Z > > F:\repro\foo\Foo\bin\Debug>.\ipy.exe > IronPython 1.1 (1.1) on .NET 2.0.50727.1318 > Copyright (c) Microsoft Corporation. All rights reserved. >>>> import clr >>>> clr.AddReference('Foo.bar.dll') >>>> import Foo.Bar > Traceback (most recent call last): > File , line 0, in ##14 > File , line 0, in __import__##7 > SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>>> ^Z > > F:\repro\foo\Foo\bin\Debug>ipyd > IronPython console: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1318 > Copyright (c) Microsoft Corporation. All rights reserved. >>>> import clr >>>> clr.AddReference('foo.bar') >>>> import Foo.Bar >>>> dir(Foo.Bar) > ['Bar'] > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski > Sent: Monday, April 23, 2007 2:15 PM > To: Discussion of IronPython > Subject: Re: [IronPython] wierd import problem > > Hi Dino, > > Sorry, I should have mentioned in my original post that I've already > tried to get it to work with all the AddReference* methods. > AddReferenceToFile was just the last example that I tried at the time I > sent the original post. > > Currently I'm still getting the same error. I've even tried variations > on the assembly name (Foo.Bar.dll vs. Foo.Bar) and the AddReference > always seems to work, it's just that the import has problems. > > I've just tried the example on another computer, and it's showing the > same issue. > > Thanks for the help, > Tony > > > Dino Viehland wrote: >> I haven't had a chance to track down what the underlying problem here is (and suspect this is a bug), but is there a reason you can't do: >> >>>>> import clr >>>>> clr.AddReference('Foo.bar.dll') >>>>> import Foo.Bar >> This seems to work. The only reason to use AddReferenceToFile is really if you are dealing with assemblies that live outside of your app domain base. In that case AddReferenceToFile will attempt to use sys.path to search for referenced assemblies when the CLR loader attempts to load them. >> >> But if you're using this DLL from within your app domain base then doing AddReference will cause the CLR to do an Assembly.Load('foo.bar.dll') which will succeed and also get the dependencies using the standard .NET way. >> >> Let me know if this is a reasonable workaround for you and I'll continue to look into the underlying issue here. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski >> Sent: Monday, April 23, 2007 12:36 PM >> To: users at lists.ironpython.com >> Subject: [IronPython] wierd import problem >> >> Hi everyone, >> >> I'm seeing a bit of weirdness when trying to import a dll with a nested namespace. Actually, I'm not sure if it's a filename issue or a namespace issue, as the filename of the assembly is named after the namespace. >> >> OK, let's say I have two assemblies: Foo.exe and Foo.Bar.dll (I've attached a simple Visual Studio project to recreate the situation) >> >> I want to "import Foo.Bar", but I'm getting an error concerning Foo.exe >> >> Here's the steps to reproduce: >> >> >>> import clr >> >>> clr.AddReferenceToFile('Foo.Bar.dll') >> >>> import Foo.Bar >> Traceback (most recent call last): >> File , line 0, in ##14 >> File , line 0, in __import__##7 >> SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >> >>> for ref in clr.References: >> ... print ref >> ... >> mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Foo.Bar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null >>> >> >> As the output shows, Foo.Bar has been referenced. So what am I doing wrong that I can't import? >> >> BTW, I'm using IP v1.1 (in case you're wondering). >> >> Thanks, >> Tony >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at exchange.microsoft.com Mon Apr 23 23:52:40 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 23 Apr 2007 14:52:40 -0700 Subject: [IronPython] wierd import problem In-Reply-To: <462D2868.6010508@v-sim.com> References: <462D0A99.7080705@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB15@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <462D21D3.1080902@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB6E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <462D2868.6010508@v-sim.com> Message-ID: <7AD436E4270DD54A94238001769C22278F0E96CBB2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> It's an alias to run IronPython 2.0 in my dev environment :( I don't think we've actually ported the pre-compiled module feature to the v2.0 branch so this just works there. Ok, so either this is a bug or a feature depending on how you look at it (we either be ignoring the DLL or our complaining loudly is the right thing, depending upon your perspective). Anyway, I've opened a new bug (#9807): http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=9807 There's two work arounds for this issue: #1) Run w/ -X:NotImportCompiled, this disables this feature which is raising this exception. #2) Use the assembly object directly instead of importing the namespace: import clr asm = clr.LoadAssemblyByName('Foo.bar') inst = asm.Foo.Bar.Bar() I've even made sure they work right on v1.1 this time :) Thanks for the bug report and sorry for messing up the repro. Hopefully one of those workarounds will work for you. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski Sent: Monday, April 23, 2007 2:43 PM To: Discussion of IronPython Subject: Re: [IronPython] wierd import problem Dino, What's ipyd? I noticed in your example that worked, you ran that instead of ipy. Here's the output I'm getting: C:\Temp\Foo\bin\Debug>dir Volume in drive C has no label. Volume Serial Number is 5454-DE81 Directory of C:\Temp\Foo\bin\Debug 04/23/2007 02:55 PM . 04/23/2007 02:55 PM .. 04/23/2007 02:55 PM 16,384 Foo.Bar.dll 04/23/2007 02:55 PM 11,776 Foo.Bar.pdb 04/23/2007 02:55 PM 16,384 Foo.exe 04/23/2007 02:55 PM 11,776 Foo.pdb 09/23/2005 07:56 AM 5,632 Foo.vshost.exe 04/10/2007 10:17 AM 71,016 ipy.exe 04/10/2007 10:17 AM 62,824 ipyw.exe 04/10/2007 10:17 AM 50,536 IronMath.dll 04/10/2007 10:17 AM 1,373,544 IronPython.dll 9 File(s) 1,619,872 bytes 2 Dir(s) 91,054,919,680 bytes free C:\Temp\Foo\bin\Debug>ipy IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference('Foo.Bar.dll') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> ^Z C:\Temp\Foo\bin\Debug>ipy IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference('Foo.Bar') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> ^Z C:\Temp\Foo\bin\Debug>ipy IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference('foo.bar') >>> import Foo.Bar Traceback (most recent call last): File , line 0, in ##14 File , line 0, in __import__##7 SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> ^Z The last example was a "shot in the dark" attempt to see if case had anything to do with the AddReference. I didn't actually expect it to work. Dino Viehland wrote: > Oh, it seems to be the presence of the '.dll' in the filename (although I still haven't looked too deeply to understand the exception). See below for the 3 different variations I've tried. The .NET loader will append .dll/.exe for you automatically. > > F:\repro\foo\Foo\bin\Debug>dir > Volume in drive F is New Volume > Volume Serial Number is F62E-82C1 > > Directory of F:\repro\foo\Foo\bin\Debug > > 04/23/2007 01:45 PM . > 04/23/2007 01:45 PM .. > 04/23/2007 01:42 PM 4,096 Foo.Bar.dll > 04/23/2007 01:42 PM 11,776 Foo.Bar.pdb > 04/23/2007 01:42 PM 4,096 Foo.exe > 04/23/2007 01:42 PM 11,776 Foo.pdb > 04/10/2007 10:17 AM 71,016 ipy.exe > 04/10/2007 10:17 AM 62,824 ipyw.exe > 04/10/2007 10:17 AM 50,536 IronMath.dll > 04/10/2007 10:17 AM 1,373,544 IronPython.dll > 04/23/2007 01:45 PM tmp > 8 File(s) 1,589,664 bytes > 3 Dir(s) 35,566,551,040 bytes free > > F:\repro\foo\Foo\bin\Debug>.\ipy.exe > IronPython 1.1 (1.1) on .NET 2.0.50727.1318 > Copyright (c) Microsoft Corporation. All rights reserved. >>>> import clr >>>> clr.AddReferenceToFile('Foo.bar.dll') >>>> import Foo.Bar > Traceback (most recent call last): > File , line 0, in ##14 > File , line 0, in __import__##7 > SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>>> ^Z > > F:\repro\foo\Foo\bin\Debug>.\ipy.exe > IronPython 1.1 (1.1) on .NET 2.0.50727.1318 > Copyright (c) Microsoft Corporation. All rights reserved. >>>> import clr >>>> clr.AddReference('Foo.bar.dll') >>>> import Foo.Bar > Traceback (most recent call last): > File , line 0, in ##14 > File , line 0, in __import__##7 > SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>>> ^Z > > F:\repro\foo\Foo\bin\Debug>ipyd > IronPython console: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1318 > Copyright (c) Microsoft Corporation. All rights reserved. >>>> import clr >>>> clr.AddReference('foo.bar') >>>> import Foo.Bar >>>> dir(Foo.Bar) > ['Bar'] > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski > Sent: Monday, April 23, 2007 2:15 PM > To: Discussion of IronPython > Subject: Re: [IronPython] wierd import problem > > Hi Dino, > > Sorry, I should have mentioned in my original post that I've already > tried to get it to work with all the AddReference* methods. > AddReferenceToFile was just the last example that I tried at the time I > sent the original post. > > Currently I'm still getting the same error. I've even tried variations > on the assembly name (Foo.Bar.dll vs. Foo.Bar) and the AddReference > always seems to work, it's just that the import has problems. > > I've just tried the example on another computer, and it's showing the > same issue. > > Thanks for the help, > Tony > > > Dino Viehland wrote: >> I haven't had a chance to track down what the underlying problem here is (and suspect this is a bug), but is there a reason you can't do: >> >>>>> import clr >>>>> clr.AddReference('Foo.bar.dll') >>>>> import Foo.Bar >> This seems to work. The only reason to use AddReferenceToFile is really if you are dealing with assemblies that live outside of your app domain base. In that case AddReferenceToFile will attempt to use sys.path to search for referenced assemblies when the CLR loader attempts to load them. >> >> But if you're using this DLL from within your app domain base then doing AddReference will cause the CLR to do an Assembly.Load('foo.bar.dll') which will succeed and also get the dependencies using the standard .NET way. >> >> Let me know if this is a reasonable workaround for you and I'll continue to look into the underlying issue here. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski >> Sent: Monday, April 23, 2007 12:36 PM >> To: users at lists.ironpython.com >> Subject: [IronPython] wierd import problem >> >> Hi everyone, >> >> I'm seeing a bit of weirdness when trying to import a dll with a nested namespace. Actually, I'm not sure if it's a filename issue or a namespace issue, as the filename of the assembly is named after the namespace. >> >> OK, let's say I have two assemblies: Foo.exe and Foo.Bar.dll (I've attached a simple Visual Studio project to recreate the situation) >> >> I want to "import Foo.Bar", but I'm getting an error concerning Foo.exe >> >> Here's the steps to reproduce: >> >> >>> import clr >> >>> clr.AddReferenceToFile('Foo.Bar.dll') >> >>> import Foo.Bar >> Traceback (most recent call last): >> File , line 0, in ##14 >> File , line 0, in __import__##7 >> SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >> >>> for ref in clr.References: >> ... print ref >> ... >> mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Foo.Bar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null >>> >> >> As the output shows, Foo.Bar has been referenced. So what am I doing wrong that I can't import? >> >> BTW, I'm using IP v1.1 (in case you're wondering). >> >> Thanks, >> Tony >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From tony at v-sim.com Tue Apr 24 00:40:39 2007 From: tony at v-sim.com (Tony Djordjevski) Date: Mon, 23 Apr 2007 18:40:39 -0400 Subject: [IronPython] wierd import problem In-Reply-To: <7AD436E4270DD54A94238001769C22278F0E96CBB2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <462D0A99.7080705@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB15@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <462D21D3.1080902@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CB6E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <462D2868.6010508@v-sim.com> <7AD436E4270DD54A94238001769C22278F0E96CBB2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <462D35E7.6040600@v-sim.com> Thanks Dino! That fixes it. In case anybody is interested, I originally came across this problem while trying to host IronPython. In order to get workaround #1 working in a hosting situation, you'll need to do the following: IronPython.Compiler.Options.ImportCompiledModule = false; Thanks again, Tony Dino Viehland wrote: > It's an alias to run IronPython 2.0 in my dev environment :( I don't think we've actually ported the pre-compiled module feature to the v2.0 branch so this just works there. > > Ok, so either this is a bug or a feature depending on how you look at it (we either be ignoring the DLL or our complaining loudly is the right thing, depending upon your perspective). Anyway, I've opened a new bug (#9807): > > http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=9807 > > There's two work arounds for this issue: > #1) Run w/ -X:NotImportCompiled, this disables this feature which is raising this exception. > #2) Use the assembly object directly instead of importing the namespace: > > import clr > asm = clr.LoadAssemblyByName('Foo.bar') > inst = asm.Foo.Bar.Bar() > > I've even made sure they work right on v1.1 this time :) > > Thanks for the bug report and sorry for messing up the repro. Hopefully one of those workarounds will work for you. > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski > Sent: Monday, April 23, 2007 2:43 PM > To: Discussion of IronPython > Subject: Re: [IronPython] wierd import problem > > Dino, > > What's ipyd? I noticed in your example that worked, you ran that > instead of ipy. > > Here's the output I'm getting: > > C:\Temp\Foo\bin\Debug>dir > Volume in drive C has no label. > Volume Serial Number is 5454-DE81 > > Directory of C:\Temp\Foo\bin\Debug > > 04/23/2007 02:55 PM . > 04/23/2007 02:55 PM .. > 04/23/2007 02:55 PM 16,384 Foo.Bar.dll > 04/23/2007 02:55 PM 11,776 Foo.Bar.pdb > 04/23/2007 02:55 PM 16,384 Foo.exe > 04/23/2007 02:55 PM 11,776 Foo.pdb > 09/23/2005 07:56 AM 5,632 Foo.vshost.exe > 04/10/2007 10:17 AM 71,016 ipy.exe > 04/10/2007 10:17 AM 62,824 ipyw.exe > 04/10/2007 10:17 AM 50,536 IronMath.dll > 04/10/2007 10:17 AM 1,373,544 IronPython.dll > 9 File(s) 1,619,872 bytes > 2 Dir(s) 91,054,919,680 bytes free > > C:\Temp\Foo\bin\Debug>ipy > IronPython 1.1 (1.1) on .NET 2.0.50727.42 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import clr > >>> clr.AddReference('Foo.Bar.dll') > >>> import Foo.Bar > Traceback (most recent call last): > File , line 0, in ##14 > File , line 0, in __import__##7 > SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; > try again after deleting it. > >>> ^Z > > C:\Temp\Foo\bin\Debug>ipy > IronPython 1.1 (1.1) on .NET 2.0.50727.42 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import clr > >>> clr.AddReference('Foo.Bar') > >>> import Foo.Bar > Traceback (most recent call last): > File , line 0, in ##14 > File , line 0, in __import__##7 > SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; > try again after deleting it. > >>> ^Z > > C:\Temp\Foo\bin\Debug>ipy > IronPython 1.1 (1.1) on .NET 2.0.50727.42 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import clr > >>> clr.AddReference('foo.bar') > >>> import Foo.Bar > Traceback (most recent call last): > File , line 0, in ##14 > File , line 0, in __import__##7 > SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; > try again after deleting it. > >>> ^Z > > The last example was a "shot in the dark" attempt to see if case had > anything to do with the AddReference. I didn't actually expect it to work. > > Dino Viehland wrote: >> Oh, it seems to be the presence of the '.dll' in the filename (although I still haven't looked too deeply to understand the exception). See below for the 3 different variations I've tried. The .NET loader will append .dll/.exe for you automatically. >> >> F:\repro\foo\Foo\bin\Debug>dir >> Volume in drive F is New Volume >> Volume Serial Number is F62E-82C1 >> >> Directory of F:\repro\foo\Foo\bin\Debug >> >> 04/23/2007 01:45 PM . >> 04/23/2007 01:45 PM .. >> 04/23/2007 01:42 PM 4,096 Foo.Bar.dll >> 04/23/2007 01:42 PM 11,776 Foo.Bar.pdb >> 04/23/2007 01:42 PM 4,096 Foo.exe >> 04/23/2007 01:42 PM 11,776 Foo.pdb >> 04/10/2007 10:17 AM 71,016 ipy.exe >> 04/10/2007 10:17 AM 62,824 ipyw.exe >> 04/10/2007 10:17 AM 50,536 IronMath.dll >> 04/10/2007 10:17 AM 1,373,544 IronPython.dll >> 04/23/2007 01:45 PM tmp >> 8 File(s) 1,589,664 bytes >> 3 Dir(s) 35,566,551,040 bytes free >> >> F:\repro\foo\Foo\bin\Debug>.\ipy.exe >> IronPython 1.1 (1.1) on .NET 2.0.50727.1318 >> Copyright (c) Microsoft Corporation. All rights reserved. >>>>> import clr >>>>> clr.AddReferenceToFile('Foo.bar.dll') >>>>> import Foo.Bar >> Traceback (most recent call last): >> File , line 0, in ##14 >> File , line 0, in __import__##7 >> SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>>>> ^Z >> F:\repro\foo\Foo\bin\Debug>.\ipy.exe >> IronPython 1.1 (1.1) on .NET 2.0.50727.1318 >> Copyright (c) Microsoft Corporation. All rights reserved. >>>>> import clr >>>>> clr.AddReference('Foo.bar.dll') >>>>> import Foo.Bar >> Traceback (most recent call last): >> File , line 0, in ##14 >> File , line 0, in __import__##7 >> SystemError: F:\repro\foo\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>>>> ^Z >> F:\repro\foo\Foo\bin\Debug>ipyd >> IronPython console: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1318 >> Copyright (c) Microsoft Corporation. All rights reserved. >>>>> import clr >>>>> clr.AddReference('foo.bar') >>>>> import Foo.Bar >>>>> dir(Foo.Bar) >> ['Bar'] >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski >> Sent: Monday, April 23, 2007 2:15 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] wierd import problem >> >> Hi Dino, >> >> Sorry, I should have mentioned in my original post that I've already >> tried to get it to work with all the AddReference* methods. >> AddReferenceToFile was just the last example that I tried at the time I >> sent the original post. >> >> Currently I'm still getting the same error. I've even tried variations >> on the assembly name (Foo.Bar.dll vs. Foo.Bar) and the AddReference >> always seems to work, it's just that the import has problems. >> >> I've just tried the example on another computer, and it's showing the >> same issue. >> >> Thanks for the help, >> Tony >> >> >> Dino Viehland wrote: >>> I haven't had a chance to track down what the underlying problem here is (and suspect this is a bug), but is there a reason you can't do: >>> >>>>>> import clr >>>>>> clr.AddReference('Foo.bar.dll') >>>>>> import Foo.Bar >>> This seems to work. The only reason to use AddReferenceToFile is really if you are dealing with assemblies that live outside of your app domain base. In that case AddReferenceToFile will attempt to use sys.path to search for referenced assemblies when the CLR loader attempts to load them. >>> >>> But if you're using this DLL from within your app domain base then doing AddReference will cause the CLR to do an Assembly.Load('foo.bar.dll') which will succeed and also get the dependencies using the standard .NET way. >>> >>> Let me know if this is a reasonable workaround for you and I'll continue to look into the underlying issue here. >>> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski >>> Sent: Monday, April 23, 2007 12:36 PM >>> To: users at lists.ironpython.com >>> Subject: [IronPython] wierd import problem >>> >>> Hi everyone, >>> >>> I'm seeing a bit of weirdness when trying to import a dll with a nested namespace. Actually, I'm not sure if it's a filename issue or a namespace issue, as the filename of the assembly is named after the namespace. >>> >>> OK, let's say I have two assemblies: Foo.exe and Foo.Bar.dll (I've attached a simple Visual Studio project to recreate the situation) >>> >>> I want to "import Foo.Bar", but I'm getting an error concerning Foo.exe >>> >>> Here's the steps to reproduce: >>> >>> >>> import clr >>> >>> clr.AddReferenceToFile('Foo.Bar.dll') >>> >>> import Foo.Bar >>> Traceback (most recent call last): >>> File , line 0, in ##14 >>> File , line 0, in __import__##7 >>> SystemError: C:\Temp\Foo\bin\Debug\Foo.exe is not pre-compiled module; try again after deleting it. >>> >>> for ref in clr.References: >>> ... print ref >>> ... >>> mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Foo.Bar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null >>> >>> >>> As the output shows, Foo.Bar has been referenced. So what am I doing wrong that I can't import? >>> >>> BTW, I'm using IP v1.1 (in case you're wondering). >>> >>> Thanks, >>> Tony >>> >>> _______________________________________________ >>> users mailing list >>> users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From lupus at ximian.com Tue Apr 24 17:05:45 2007 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 24 Apr 2007 17:05:45 +0200 Subject: [IronPython] Microsoft .NET vs. Mono on running IronPython In-Reply-To: <5b0248170704220827xb8fcccdl7a7edc08ac8ffaf@mail.gmail.com> References: <5b0248170704220827xb8fcccdl7a7edc08ac8ffaf@mail.gmail.com> Message-ID: <20070424150545.GE5441@debian.org> Thanks for the numbers and for the comparisons! On 04/23/07 Sanghyeon Seo wrote: > Indeed, if I compare Windows CPython 2.5 numbers and Linux CPython 2.5 > numbers, Windows CPython 2.5 is ~1.2 times faster, most likely because > Jim's laptop is faster. With a single exception. StringMappings test, > calling .upper() and .lower() methods on string, is 4 times faster on > Linux. This could be glibc doing smart optimization. I decided to > exclude this test in comparisons below. Check the string representation, I believe on Linux python can be compiled to 2 or 3 different encodings (likely utf8, utf16, UCS4) and the encoding used, if different, could explain much of the speedup. > Summary: > > >>From these tests, Mono seems to perform comparisons and exception > handlings better than .NET for running IronPython. > > Mono is 6 times slower on string and unicode concatenation and 4 times > slower on slicing. It's also 3 to 4 times slower on IronPython > instance creation. Yeah, I had a quick look at pybench a few months ago and the major issue for mono is the garbage collector performance. IronPython is very alloc-happy in its implementation and this hurts us more than the MS runtime (for GC microbenchmarks, which some of pybench ends up being comparable to, the MS runtime is 2-3 times faster than mono). It is also likely that IronPython has been optimized to follow the MS .net performance guidelines which don't necessarily match mono's preference. We're working on a new GC which will reduce significantly the gap, expect news in the next few months. > # How many tests Mono run fast? > >>> len([1 for x in k if x < 1]) > 10 Well, at least we win somewhere:) > >>> len([1 for x in k if x > 2]) > 21 > > # Three times? > >>> len([1 for x in k if x > 2]) Typo there, should be a 3 > 9 > > These tests, embarassing for Mono are: BuiltinFunctionCalls, > ConcatStrings, ConcatUnicode, CreateInstances, CreateNewInstances, > CreateStringsWithConcat, ListSlicing, StringSlicing, UnicodeSlicing. You'll note that all those are heavy allocators (except maybe BuiltinFunctionCalls?). lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From arman at twinsun.com Tue Apr 24 20:42:30 2007 From: arman at twinsun.com (Arman Bostani) Date: Tue, 24 Apr 2007 11:42:30 -0700 Subject: [IronPython] pybench results for CPython and IronPython Message-ID: <462E4F96.8040202@twinsun.com> I assume that IronPython is implemented with thread-safe data structures (i.e. there's no GIL). If so, then IronPython is at a disadvantage on single-threaded benchmarks like pybench. Just for fun, I tested System.Collections.SortedList against its thread safe (Synchronized) version. The latter was 5 times slower! In light of this simple test, its possible that 1) IP is very efficient at implementing thread safety 2) .NET Synchronized collections are horribly slow 3) my assumption on IP's implementation are wrong. -arman From dinov at exchange.microsoft.com Tue Apr 24 21:37:25 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 24 Apr 2007 12:37:25 -0700 Subject: [IronPython] pybench results for CPython and IronPython In-Reply-To: <462E4F96.8040202@twinsun.com> References: <462E4F96.8040202@twinsun.com> Message-ID: <7AD436E4270DD54A94238001769C22278F5F55C4F6@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I think #2 is the winner here - the synchronized versions of the classes are much slower than just using a simple Monitor. But IronPython's data structures are thread safe and we just use Monitor's for most of them (there are some more tuned classes in the system as well but there aren't too many of those). ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Arman Bostani [arman at twinsun.com] Sent: Tuesday, April 24, 2007 11:42 AM To: users at lists.ironpython.com Subject: Re: [IronPython] pybench results for CPython and IronPython I assume that IronPython is implemented with thread-safe data structures (i.e. there's no GIL). If so, then IronPython is at a disadvantage on single-threaded benchmarks like pybench. Just for fun, I tested System.Collections.SortedList against its thread safe (Synchronized) version. The latter was 5 times slower! In light of this simple test, its possible that 1) IP is very efficient at implementing thread safety 2) .NET Synchronized collections are horribly slow 3) my assumption on IP's implementation are wrong. -arman _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From daglask at gmail.com Thu Apr 26 10:26:42 2007 From: daglask at gmail.com (kostas daglas) Date: Thu, 26 Apr 2007 11:26:42 +0300 Subject: [IronPython] DataSet.Tables not callable Message-ID: <34b8be480704260126v22e2287co392d8bc40ec8cda6@mail.gmail.com> hi all ! this is my first post and i am new to database programming generally. Anyway i would appreciate your help.. i made an Addressbook table with 5 rows (myfriends!) and every row has items (name, surname etc.)i called it AddressBook.mdb I made a form with a button and a TextBox contorl i want to show when i click the button the first item of a given row in my textbox. i did: con = OleDb.OleDbConnection() ds = DataSet() con.ConnectionString = 'PROVIDER=Microsoft.Jet.OLEDB.4.0;Data Source = C:\AddressBook.mdb' con.Open() sql = 'SELECT * FROM tblContacts' da=OleDb.OleDbDataAdapter(sql, con) da.Fill(ds, "AddressBook") in c# i could do : txtFirstName.Text = ds.Tables("AddressBook").Rows(0).Item(1) how can i do that in IronPython? ( i tried it but : "DataTableCollection object is not callable.". ) Thanks in advance for your help ! Kostas -------------- next part -------------- An HTML attachment was scrubbed... URL: From hydonlee at gmail.com Thu Apr 26 10:44:23 2007 From: hydonlee at gmail.com (=?GB2312?B?tqvX0w==?=) Date: Thu, 26 Apr 2007 16:44:23 +0800 Subject: [IronPython] DataSet.Tables not callable In-Reply-To: <34b8be480704260126v22e2287co392d8bc40ec8cda6@mail.gmail.com> References: <34b8be480704260126v22e2287co392d8bc40ec8cda6@mail.gmail.com> Message-ID: <3bc65bab0704260144g483b1e83o22ecf7c71e970c8e@mail.gmail.com> in Python, "() " means a CALL, if you want a INDEX, try "[]" . like this: txtFirstName.Text = ds.Tables["AddressBook"].Rows[0].Item[1] 2007/4/26, kostas daglas : > > hi all ! this is my first post and i am new to database programming > generally. > Anyway i would appreciate your help.. > > i made an Addressbook table with 5 rows (myfriends!) and every row has > items (name, surname etc.)i called it AddressBook.mdb > > I made a form with a button and a TextBox contorl > i want to show when i click the button the first item of a given row in my > textbox. > i did: > con = OleDb.OleDbConnection() > ds = DataSet() > > > > con.ConnectionString = 'PROVIDER=Microsoft.Jet.OLEDB.4.0;Data > Source = C:\AddressBook.mdb' > con.Open() > sql = 'SELECT * FROM tblContacts' > > da=OleDb.OleDbDataAdapter(sql, con) > da.Fill(ds, "AddressBook") > > in c# i could do : > txtFirstName.Text = ds.Tables("AddressBook").Rows(0).Item(1) > how can i do that in IronPython? ( i tried it but : > "DataTableCollection object is not callable.". ) > > Thanks in advance for your help ! > > Kostas > > > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- ???????, ??????? ????,?????????!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From yan.lixin at gmail.com Thu Apr 26 10:47:29 2007 From: yan.lixin at gmail.com (=?GB2312?B?48Ygwabqvw==?=) Date: Thu, 26 Apr 2007 16:47:29 +0800 Subject: [IronPython] DataSet.Tables not callable In-Reply-To: <34b8be480704260126v22e2287co392d8bc40ec8cda6@mail.gmail.com> References: <34b8be480704260126v22e2287co392d8bc40ec8cda6@mail.gmail.com> Message-ID: <174e07690704260147h13de71e4xd4d47c741349308d@mail.gmail.com> try it ds.Tables["AddressBook"].Rows[0][1] or for dr in ds.Tables[AddressBook].Rows: dr[1] 2007/4/26, kostas daglas : > > hi all ! this is my first post and i am new to database programming > generally. > Anyway i would appreciate your help.. > > i made an Addressbook table with 5 rows (myfriends!) and every row has > items (name, surname etc.)i called it AddressBook.mdb > > I made a form with a button and a TextBox contorl > i want to show when i click the button the first item of a given row in my > textbox. > i did: > con = OleDb.OleDbConnection() > ds = DataSet() > > > > con.ConnectionString = 'PROVIDER=Microsoft.Jet.OLEDB.4.0;Data > Source = C:\AddressBook.mdb' > con.Open() > sql = 'SELECT * FROM tblContacts' > > da=OleDb.OleDbDataAdapter(sql, con) > da.Fill(ds, "AddressBook") > > in c# i could do : > txtFirstName.Text = ds.Tables("AddressBook").Rows(0).Item(1) > how can i do that in IronPython? ( i tried it but : > "DataTableCollection object is not callable.". ) > > Thanks in advance for your help ! > > Kostas > > > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- ?????????????. -------------- next part -------------- An HTML attachment was scrubbed... URL: From redmoon17 at gmail.com Thu Apr 26 14:02:25 2007 From: redmoon17 at gmail.com (Kevin Chu) Date: Thu, 26 Apr 2007 20:02:25 +0800 Subject: [IronPython] About IronPython and LINQ again Message-ID: <41d7f4a90704260502j73f6836ao57c22753c130001a@mail.gmail.com> Hi, IronPythoners In May 10, 2006 ,I post a discussion about IronPython and LINQ, complete discussion url is : http://lists.ironpython.com/pipermail/users-ironpython.com/2006-May/002300.html And now Orcas Beta 1 is released, I again inquire about can I use LINQ in IronPython. Because ,IronPython now only use ado.net to access database, if we can use LINQtoSQL to access SQL Server. It's cool! -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jba at ELLINGTON.com Thu Apr 26 17:23:13 2007 From: jba at ELLINGTON.com (Jonathan Amsterdam) Date: Thu, 26 Apr 2007 11:23:13 -0400 Subject: [IronPython] can't override LayoutEngine property Message-ID: <70617F310C03C54294DC77569ADC2D289FEB68@emgmail1.ellington.com> I'm trying to overrride the LayoutEngine property of Control so I can implement my own layout engine. I find that this doesn't work in IP. Accessing the LayoutEngine property in IP works fine, but it doesn't work from C#. //////////////////// C# code: public class MyCSharpClass { public static LayoutEngine getLayoutEngine(Panel p) { return p.LayoutEngine; } } //////////////////// Python code: class MyLayoutEngine(LayoutEngine): def Layout(self, parent, eventArgs): pass mle = MyLayoutEngine() class MyPanel(Panel): LayoutEngine = property(lambda self: mle) p = MyPanel() print "from Python:", p.LayoutEngine print "from C#:", MyCSharpClass.getLayoutEngine(p) //////////////////// output: from Python: from C#: System.Windows.Forms.Layout.DefaultLayout ============================================================================================= Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ============================================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From daglask at gmail.com Thu Apr 26 18:19:03 2007 From: daglask at gmail.com (kostas daglas) Date: Thu, 26 Apr 2007 19:19:03 +0300 Subject: [IronPython] DataSet.Tables not callable In-Reply-To: <174e07690704260147h13de71e4xd4d47c741349308d@mail.gmail.com> References: <34b8be480704260126v22e2287co392d8bc40ec8cda6@mail.gmail.com> <174e07690704260147h13de71e4xd4d47c741349308d@mail.gmail.com> Message-ID: <34b8be480704260919v412695evf89aa3fd454718fe@mail.gmail.com> ds.Tables["AddressBook"].Rows[0][1] works excellent ! thanks again for your immediate feedback Kostas On 4/26/07, ? ?? wrote: > > try it > ds.Tables["AddressBook"].Rows[0][1] > or > for dr in ds.Tables[AddressBook].Rows: > dr[1] > > > 2007/4/26, kostas daglas : > > > > hi all ! this is my first post and i am new to database programming > > generally. > > Anyway i would appreciate your help.. > > > > i made an Addressbook table with 5 rows (myfriends!) and every row has > > items (name, surname etc.)i called it AddressBook.mdb > > > > I made a form with a button and a TextBox contorl > > i want to show when i click the button the first item of a given row in > > my textbox. > > i did: > > con = OleDb.OleDbConnection() > > ds = DataSet() > > > > > > > > con.ConnectionString = 'PROVIDER=Microsoft.Jet.OLEDB.4.0;Data > > Source = C:\AddressBook.mdb' > > con.Open() > > sql = 'SELECT * FROM tblContacts' > > > > da=OleDb.OleDbDataAdapter(sql, con) > > da.Fill(ds, "AddressBook") > > > > in c# i could do : > > txtFirstName.Text = ds.Tables("AddressBook").Rows(0).Item(1) > > > > how can i do that in IronPython? ( i tried it but : > > "DataTableCollection object is not callable.". ) > > > > Thanks in advance for your help ! > > > > Kostas > > > > > > > > > > _______________________________________________ > > users mailing list > > users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > -- > ?????????????. > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Thu Apr 26 20:04:08 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 26 Apr 2007 11:04:08 -0700 Subject: [IronPython] can't override LayoutEngine property In-Reply-To: <70617F310C03C54294DC77569ADC2D289FEB68@emgmail1.ellington.com> References: <70617F310C03C54294DC77569ADC2D289FEB68@emgmail1.ellington.com> Message-ID: <7AD436E4270DD54A94238001769C22278F5F482E0B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I believe currently you need to do: @property def get_MyLayoutEngine(self): return mle to get the get_ method to override this. A couple of people have ran into this and we don't seem to have a bug on it so I've opened bug #9902 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=9902) to make this more intuitive. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Amsterdam Sent: Thursday, April 26, 2007 8:23 AM To: users at lists.ironpython.com Subject: [IronPython] can't override LayoutEngine property I'm trying to overrride the LayoutEngine property of Control so I can implement my own layout engine. I find that this doesn't work in IP. Accessing the LayoutEngine property in IP works fine, but it doesn't work from C#. //////////////////// C# code: public class MyCSharpClass { public static LayoutEngine getLayoutEngine(Panel p) { return p.LayoutEngine; } } //////////////////// Python code: class MyLayoutEngine(LayoutEngine): def Layout(self, parent, eventArgs): pass mle = MyLayoutEngine() class MyPanel(Panel): LayoutEngine = property(lambda self: mle) p = MyPanel() print "from Python:", p.LayoutEngine print "from C#:", MyCSharpClass.getLayoutEngine(p) //////////////////// output: from Python: from C#: System.Windows.Forms.Layout.DefaultLayout ============================================================================================= Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution,or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ============================================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Thu Apr 26 20:10:13 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 26 Apr 2007 11:10:13 -0700 Subject: [IronPython] About IronPython and LINQ again In-Reply-To: <41d7f4a90704260502j73f6836ao57c22753c130001a@mail.gmail.com> References: <41d7f4a90704260502j73f6836ao57c22753c130001a@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C22278F5F482E18@DF-GRTDANE-MSG.exchange.corp.microsoft.com> There's still no direct LINQ support. We believe we're getting the correct architecture in place to support extension methods in v2.0 (note though we still haven't done the actual work to enable the extension methods and when we ship the first 2.0 builds there will be no dependencies on Orcas). This will enable much of the LINQ abilities in a convenient to use syntax. Until then you can clr.AddReference to the LINQ libraries and call the static extension methods directly but it'll be ugly. Other than that we still haven't gotten to figuring out how to support LINQ in a more direct form. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu Sent: Thursday, April 26, 2007 5:02 AM To: Discussion of IronPython Subject: [IronPython] About IronPython and LINQ again Hi, IronPythoners In May 10, 2006 ,I post a discussion about IronPython and LINQ, complete discussion url is :http://lists.ironpython.com/pipermail/users-ironpython.com/2006-May/002300.html And now Orcas Beta 1 is released, I again inquire about can I use LINQ in IronPython. Because ,IronPython now only use ado.net to access database, if we can use LINQtoSQL to access SQL Server. It's cool! -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Thu Apr 26 20:27:35 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Thu, 26 Apr 2007 11:27:35 -0700 Subject: [IronPython] About IronPython and LINQ again Message-ID: Well, get to it! ;) -- Keith [MSFT: LINQ to SQL] ________________________________ From: users-bounces at lists.ironpython.com on behalf of Dino Viehland Sent: Thu 4/26/2007 11:10 AM To: Discussion of IronPython Subject: Re: [IronPython] About IronPython and LINQ again There's still no direct LINQ support. We believe we're getting the correct architecture in place to support extension methods in v2.0 (note though we still haven't done the actual work to enable the extension methods and when we ship the first 2.0 builds there will be no dependencies on Orcas). This will enable much of the LINQ abilities in a convenient to use syntax. Until then you can clr.AddReference to the LINQ libraries and call the static extension methods directly but it'll be ugly. Other than that we still haven't gotten to figuring out how to support LINQ in a more direct form. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu Sent: Thursday, April 26, 2007 5:02 AM To: Discussion of IronPython Subject: [IronPython] About IronPython and LINQ again Hi, IronPythoners In May 10, 2006 ,I post a discussion about IronPython and LINQ, complete discussion url is :http://lists.ironpython.com/pipermail/users-ironpython.com/2006-May/002300.html And now Orcas Beta 1 is released, I again inquire about can I use LINQ in IronPython. Because ,IronPython now only use ado.net to access database, if we can use LINQtoSQL to access SQL Server. It's cool! -- Once in a Redmoon From jba at ELLINGTON.com Thu Apr 26 21:22:46 2007 From: jba at ELLINGTON.com (Jonathan Amsterdam) Date: Thu, 26 Apr 2007 15:22:46 -0400 Subject: [IronPython] can't override LayoutEngine property References: Message-ID: <70617F310C03C54294DC77569ADC2D289FEB6C@emgmail1.ellington.com> Dino, Thanks for your prompt reply. Unfortunately, your suggestion doesn't work either (it gives the same result when invoked from C#). Moreover, the first way (name = property(...)) worked fine when I just built my own C# class with its own virtual property. Date: Thu, 26 Apr 2007 11:04:08 -0700 From: Dino Viehland Subject: Re: [IronPython] can't override LayoutEngine property To: Discussion of IronPython Message-ID: <7AD436E4270DD54A94238001769C22278F5F482E0B at DF-GRTDANE-MSG.exchange.corp .microsoft.com> Content-Type: text/plain; charset="us-ascii" I believe currently you need to do: @property def get_MyLayoutEngine(self): return mle to get the get_ method to override this. A couple of people have ran into this and we don't seem to have a bug on it so I've opened bug #9902 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=9902) to make this more intuitive. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Amsterdam Sent: Thursday, April 26, 2007 8:23 AM To: users at lists.ironpython.com Subject: [IronPython] can't override LayoutEngine property I'm trying to overrride the LayoutEngine property of Control so I can implement my own layout engine. I find that this doesn't work in IP. Accessing the LayoutEngine property in IP works fine, but it doesn't work from C#. //////////////////// C# code: public class MyCSharpClass { public static LayoutEngine getLayoutEngine(Panel p) { return p.LayoutEngine; } } //////////////////// Python code: class MyLayoutEngine(LayoutEngine): def Layout(self, parent, eventArgs): pass mle = MyLayoutEngine() class MyPanel(Panel): LayoutEngine = property(lambda self: mle) p = MyPanel() print "from Python:", p.LayoutEngine print "from C#:", MyCSharpClass.getLayoutEngine(p) //////////////////// output: from Python: from C#: System.Windows.Forms.Layout.DefaultLayout ============================================================================================= Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ============================================================================================== From dinov at exchange.microsoft.com Thu Apr 26 22:44:45 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 26 Apr 2007 13:44:45 -0700 Subject: [IronPython] can't override LayoutEngine property In-Reply-To: <70617F310C03C54294DC77569ADC2D289FEB6C@emgmail1.ellington.com> References: <70617F310C03C54294DC77569ADC2D289FEB6C@emgmail1.ellington.com> Message-ID: <7AD436E4270DD54A94238001769C22278F5F482EF3@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Wow, after digging into this some more I gotta say: this is very interesting and may be a CLR bug. The short of this is there's a bug here and there's at least a work around (from the perspective of you can rebuild IronPython :) ). In Src\IronPython\Compiler\Generation\NewTypeMaker.cs there's a function called OverrideSpecialName. It's signature needs a new parameter: private void OverrideSpecialName(Type type, MethodInfo mi, Dictionary specialNames) { and then that parameter needs to be used for the GetProperties call: PropertyInfo[] pis = type.GetProperties(BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic); There's 1 caller to this function in OverrideVirtualMethods and it just needs to pass type: OverrideSpecialName(type, mi, specialNames); Here's an explanation of what's going on. We are calling GetMethods() on Panel which returns the methods for Panel and all of its subtypes - including Control. We are then filtering those down to virtual methods and trying to find the property they are associated with. At that point in time we call GetProperties() on the method's declaring type (in this case, Control) to get all of the properties. We then go through each property trying to find the property who has a get or set method that matches this method (get_LayoutEngine). What's strange is that we come to a point where we have a get_LayoutEngine method declared on Control that we grabbed from Panel, and we have a get_LayoutEngine method declared on Control that we grabbed from Control's LayoutEngine property. For some reason these two methods aren't comparing equal even though they're the exact same method. Given that we have a workaround for IronPython I'll open a bug (9908 - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=9908) and this should go into the next stable release. I'll also follow up with the CLR team and see if they believe this is a bug and if so get that fixed as well. Thanks for reporting this... Hopefully the workaround won't be too much trouble until we get the next release out. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Amsterdam Sent: Thursday, April 26, 2007 12:23 PM To: users at lists.ironpython.com Subject: Re: [IronPython] can't override LayoutEngine property Dino, Thanks for your prompt reply. Unfortunately, your suggestion doesn't work either (it gives the same result when invoked from C#). Moreover, the first way (name = property(...)) worked fine when I just built my own C# class with its own virtual property. Date: Thu, 26 Apr 2007 11:04:08 -0700 From: Dino Viehland Subject: Re: [IronPython] can't override LayoutEngine property To: Discussion of IronPython Message-ID: <7AD436E4270DD54A94238001769C22278F5F482E0B at DF-GRTDANE-MSG.exchange.corp .microsoft.com> Content-Type: text/plain; charset="us-ascii" I believe currently you need to do: @property def get_MyLayoutEngine(self): return mle to get the get_ method to override this. A couple of people have ran into this and we don't seem to have a bug on it so I've opened bug #9902 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=9902) to make this more intuitive. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Amsterdam Sent: Thursday, April 26, 2007 8:23 AM To: users at lists.ironpython.com Subject: [IronPython] can't override LayoutEngine property I'm trying to overrride the LayoutEngine property of Control so I can implement my own layout engine. I find that this doesn't work in IP. Accessing the LayoutEngine property in IP works fine, but it doesn't work from C#. //////////////////// C# code: public class MyCSharpClass { public static LayoutEngine getLayoutEngine(Panel p) { return p.LayoutEngine; } } //////////////////// Python code: class MyLayoutEngine(LayoutEngine): def Layout(self, parent, eventArgs): pass mle = MyLayoutEngine() class MyPanel(Panel): LayoutEngine = property(lambda self: mle) p = MyPanel() print "from Python:", p.LayoutEngine print "from C#:", MyCSharpClass.getLayoutEngine(p) //////////////////// output: from Python: from C#: System.Windows.Forms.Layout.DefaultLayout ============================================================================================= Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ============================================================================================== _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From redmoon17 at gmail.com Fri Apr 27 04:13:47 2007 From: redmoon17 at gmail.com (Kevin Chu) Date: Fri, 27 Apr 2007 10:13:47 +0800 Subject: [IronPython] About IronPython and LINQ again In-Reply-To: References: Message-ID: <41d7f4a90704261913u7009904crfd6b42a0cfe0e337@mail.gmail.com> If I plan to create Web Framework base of IronPython for ASP.NET like Django. First thing,I have to solve is a ORMapper. So do you any adivces about ORMapper used in IronPython for ASP.NET? On 4/27/07, Keith J. Farmer wrote: > > Well, get to it! ;) > > -- Keith [MSFT: LINQ to SQL] > > ________________________________ > > From: users-bounces at lists.ironpython.com on behalf of Dino Viehland > Sent: Thu 4/26/2007 11:10 AM > To: Discussion of IronPython > Subject: Re: [IronPython] About IronPython and LINQ again > > > > There's still no direct LINQ support. We believe we're getting the > correct architecture in place to support extension methods in v2.0 (note > though we still haven't done the actual work to enable the extension methods > and when we ship the first 2.0 builds there will be no dependencies on > Orcas). This will enable much of the LINQ abilities in a convenient to use > syntax. Until then you can clr.AddReference to the LINQ libraries and > call the static extension methods directly but it'll be ugly. > > > > Other than that we still haven't gotten to figuring out how to support > LINQ in a more direct form. > > > > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu > Sent: Thursday, April 26, 2007 5:02 AM > To: Discussion of IronPython > Subject: [IronPython] About IronPython and LINQ again > > > > Hi, IronPythoners > > > > In May 10, 2006 ,I post a discussion about IronPython and LINQ, complete > discussion url is : > http://lists.ironpython.com/pipermail/users-ironpython.com/2006-May/002300.html > > > And now Orcas Beta 1 is released, I again inquire about can I use LINQ in > IronPython. > > Because ,IronPython now only use ado.net to access database, if we can use > LINQtoSQL to access SQL Server. It's cool! > > > -- > Once in a Redmoon > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jba at ELLINGTON.com Fri Apr 27 16:05:07 2007 From: jba at ELLINGTON.com (Jonathan Amsterdam) Date: Fri, 27 Apr 2007 10:05:07 -0400 Subject: [IronPython] can't override LayoutEngine property References: <70617F310C03C54294DC77569ADC2D289FEB6C@emgmail1.ellington.com> <7AD436E4270DD54A94238001769C22278F5F482EF3@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <70617F310C03C54294DC77569ADC2D289FEB6E@emgmail1.ellington.com> Thanks for digging into it. A fix in the next release will be fine. Rather than recompile IP, I worked around it by writing a C# class that overrides the property. -----Original Message----- From: Dino Viehland [mailto:dinov at exchange.microsoft.com] Sent: Thursday, April 26, 2007 4:45 PM To: Discussion of IronPython Subject: Re: [IronPython] can't override LayoutEngine property Wow, after digging into this some more I gotta say: this is very interesting and may be a CLR bug. The short of this is there's a bug here and there's at least a work around (from the perspective of you can rebuild IronPython :) ). In Src\IronPython\Compiler\Generation\NewTypeMaker.cs there's a function called OverrideSpecialName. It's signature needs a new parameter: private void OverrideSpecialName(Type type, MethodInfo mi, Dictionary specialNames) { and then that parameter needs to be used for the GetProperties call: PropertyInfo[] pis = type.GetProperties(BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic); There's 1 caller to this function in OverrideVirtualMethods and it just needs to pass type: OverrideSpecialName(type, mi, specialNames); Here's an explanation of what's going on. We are calling GetMethods() on Panel which returns the methods for Panel and all of its subtypes - including Control. We are then filtering those down to virtual methods and trying to find the property they are associated with. At that point in time we call GetProperties() on the method's declaring type (in this case, Control) to get all of the properties. We then go through each property trying to find the property who has a get or set method that matches this method (get_LayoutEngine). What's strange is that we come to a point where we have a get_LayoutEngine method declared on Control that we grabbed from Panel, and we have a get_LayoutEngine method declared on Control that we grabbed from Control's LayoutEngine property. For some reason these two methods aren't comparing equal even though they're the exact same method. Given that we have a workaround for IronPython I'll open a bug (9908 - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=9908) and this should go into the next stable release. I'll also follow up with the CLR team and see if they believe this is a bug and if so get that fixed as well. Thanks for reporting this... Hopefully the workaround won't be too much trouble until we get the next release out. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Amsterdam Sent: Thursday, April 26, 2007 12:23 PM To: users at lists.ironpython.com Subject: Re: [IronPython] can't override LayoutEngine property Dino, Thanks for your prompt reply. Unfortunately, your suggestion doesn't work either (it gives the same result when invoked from C#). Moreover, the first way (name = property(...)) worked fine when I just built my own C# class with its own virtual property. Date: Thu, 26 Apr 2007 11:04:08 -0700 From: Dino Viehland Subject: Re: [IronPython] can't override LayoutEngine property To: Discussion of IronPython Message-ID: <7AD436E4270DD54A94238001769C22278F5F482E0B at DF-GRTDANE-MSG.exchange.corp .microsoft.com> Content-Type: text/plain; charset="us-ascii" I believe currently you need to do: @property def get_MyLayoutEngine(self): return mle to get the get_ method to override this. A couple of people have ran into this and we don't seem to have a bug on it so I've opened bug #9902 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=9902) to make this more intuitive. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Amsterdam Sent: Thursday, April 26, 2007 8:23 AM To: users at lists.ironpython.com Subject: [IronPython] can't override LayoutEngine property I'm trying to overrride the LayoutEngine property of Control so I can implement my own layout engine. I find that this doesn't work in IP. Accessing the LayoutEngine property in IP works fine, but it doesn't work from C#. //////////////////// C# code: public class MyCSharpClass { public static LayoutEngine getLayoutEngine(Panel p) { return p.LayoutEngine; } } //////////////////// Python code: class MyLayoutEngine(LayoutEngine): def Layout(self, parent, eventArgs): pass mle = MyLayoutEngine() class MyPanel(Panel): LayoutEngine = property(lambda self: mle) p = MyPanel() print "from Python:", p.LayoutEngine print "from C#:", MyCSharpClass.getLayoutEngine(p) //////////////////// output: from Python: from C#: System.Windows.Forms.Layout.DefaultLayout ======================================================================== ===================== Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ======================================================================== ====================== _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From kfarmer at thuban.org Fri Apr 27 20:57:56 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Fri, 27 Apr 2007 11:57:56 -0700 Subject: [IronPython] About IronPython and LINQ again Message-ID: As Dino mentions, nothing prevents you from calling the static extensions directly: they exist in the System.Linq namespace of System.Core.dll. The problem, of course, is that you end up with a lot of Queryable.Select(Queryable.Where(someInputSequence, somePredicate), someFuncThatReturnsTheSequenceElement) instead of the more pleasant someInputSequence.Where(somePredicate).Select(someFuncThatReturnsTheSequenceElement) or even from x in someInputSequence where somePredicate(x) select someFuncThatReturnsTheSequenceElement(x) And that's without getting deeply into the type naming, or expression building with parameters. However, it's still entirely doable -- it's just *MUCH* easier when the language is helping out with extension methods, expressions trees from lambdas, and sophisticated type inference capabilities. As for ASP.NET itself, Scott Guthrie (in his blog) has already mentioned the impending LinqDataSource control, which will do some of the more interesting stuff for you. You'll probably be able to have a working solution off of that alone, I think (I haven't had the opportunity to play around with it, though I took a stab at writing one, which exists in the May CTP samples). Then, when IronPython gets additional features enabled I imagine you'll have some more flexibility available. ________________________________ From: users-bounces at lists.ironpython.com on behalf of Kevin Chu Sent: Thu 4/26/2007 7:13 PM To: Discussion of IronPython Subject: Re: [IronPython] About IronPython and LINQ again If I plan to create Web Framework base of IronPython for ASP.NET like Django. First thing,I have to solve is a ORMapper. So do you any adivces about ORMapper used in IronPython for ASP.NET? On 4/27/07, Keith J. Farmer wrote: Well, get to it! ;) -- Keith [MSFT: LINQ to SQL] ________________________________ From: users-bounces at lists.ironpython.com on behalf of Dino Viehland Sent: Thu 4/26/2007 11:10 AM To: Discussion of IronPython Subject: Re: [IronPython] About IronPython and LINQ again There's still no direct LINQ support. We believe we're getting the correct architecture in place to support extension methods in v2.0 (note though we still haven't done the actual work to enable the extension methods and when we ship the first 2.0 builds there will be no dependencies on Orcas). This will enable much of the LINQ abilities in a convenient to use syntax. Until then you can clr.AddReference to the LINQ libraries and call the static extension methods directly but it'll be ugly. Other than that we still haven't gotten to figuring out how to support LINQ in a more direct form. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu Sent: Thursday, April 26, 2007 5:02 AM To: Discussion of IronPython Subject: [IronPython] About IronPython and LINQ again Hi, IronPythoners In May 10, 2006 ,I post a discussion about IronPython and LINQ, complete discussion url is : http://lists.ironpython.com/pipermail/users-ironpython.com/2006-May/002300.html And now Orcas Beta 1 is released, I again inquire about can I use LINQ in IronPython. Because ,IronPython now only use ado.net to access database, if we can use LINQtoSQL to access SQL Server. It's cool! -- Once in a Redmoon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Once in a Redmoon From jba at ELLINGTON.com Mon Apr 30 15:55:04 2007 From: jba at ELLINGTON.com (Jonathan Amsterdam) Date: Mon, 30 Apr 2007 09:55:04 -0400 Subject: [IronPython] concerns about startup time Message-ID: <70617F310C03C54294DC77569ADC2D289FEB72@emgmail1.ellington.com> I've been evaluating IronPython over the last week or so for a project at work. Much as I love it, I do have one concern: start-up time. My demo app-much smaller than the actual one will be-takes about 4 seconds just to load, before doing any work such as building the GUI. This time will be acceptable in the deployed application, but adds much pain to the development cycle-I suspect using C# in Visual Studio would yield faster overall time even with compilation of a changed file. I've done the obvious optimization of using -X:SaveAssemblies. The above times were taken after loading the app once with -X:SaveAssemblies, then running it a second time without that flag. The main file of the app contains just an import and a function call. All the other code is in other files. I'm aware of the authenticode issue. I tried to disable the runtime code check by running caspol -e off. That didn't make any difference. Any other optimizations you can suggest? Do you think there is room for improvement in start-up in IP's implementation, or is the bottleneck in the CLR? Assuming there is room for improvement, can you give me a sense of the priority of this issue, and when we can expect to see a difference? Thanks for your help. -Jonathan Amsterdam ============================================================================================= Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ============================================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Mon Apr 30 18:30:10 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 30 Apr 2007 09:30:10 -0700 Subject: [IronPython] IronPython 2.0 Alpha 1 Released Message-ID: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Hello IronPython Community, We have just released IronPython 2.0 Alpha 1. IronPython 2.0 will be the first release of IronPython built upon a common dynamic language runtime (DLR) as well as targeting version 2.5 of Python. These release notes list what is new in IronPython 2.0, a brief overview of the DLR, and what to expect from the 2.0 release. One major focus during this release will be further improving our conformance with CPython. We've already made several improvements, for example one is that our type system no longer contains a hierarchy of types: now type(type) is type. We have also fixed a number of issues related to various statements such as imports and function definitions inside of exec or eval. There have also been a number of other small issues fixed that our users reported to us. IronPython 2.0 will also be the first major release to support 2.5 out of the box. In IronPython 1.x, and in this initial alpha release, users must enable this with a command line switch. During the 2.0 release cycle we will flush out the remaining 2.5 features and permanently enable this option. We will also start looking at supporting v2.6 features via command line switch and start some experimentation around the 3.0 features. In particular, we are excited about looking at the new bytes and string types as well as formatting options that we believe will fit nicely with .NET. IronPython 2.0 is also the first release built upon the Dynamic Language Runtime: a shared runtime for dynamic languages on .NET. The DLR both reduces the amount of work to create new dynamic languages on .NET enables rich interoperability between dynamic languages, and provides a shared module for consuming those languages from applications. We are particularly excited about the ability to share code across dynamic languages enabling users to share libraries without worrying the particular language in which the library is written. Over time, the DLR will expand and improve bringing language developers more benefits from this shared infrastructure. We also look forward to seeing a new era of programmable apps that can support a wide range of options for end-users. When we started working on the DLR we initially used the IronPython v1.0 code base. From there we extracted the core concepts that were common to dynamic languages, generalized the concepts that were specific to Python, expanded the framework to provide rich support for other dynamic languages, and exposed all of the languages via a common interface. Starting with IronPython 1.0 was an obvious choice because it had already captured many of the best practices for building dynamic languages on .NET and had done a great job leveraging many of the underlying features of .NET. In IronPython 2.0 all of these best practices are expanded and implemented with an eye on maximizing forward compatibility with new features in .NET v3.5 such as LINQ and extension methods. Moreover, the DLR exposes this functionality to the language implementer via a small set of core concepts that all dynamic language implementations can share. One additional change in this release is that we're moving to use the Microsoft Permissive License for IronPython 2.0. Our original release of IronPython predated the Microsoft Permissive License, and so we created a custom license specifically for Iron Python. After releasing Iron Python, we created new Microsoft Shared Source licenses, including the Microsoft Permissive License, to facilitate and standardize source code licensing for appropriate Microsoft projects. We believe our users appreciate consistency in licensing from Microsoft. Therefore, because we are now using the more modern Microsoft Permissive License where appropriate for similar current source code releases, we feel we should offer IronPython under the Microsoft Permissive License as well. Note because this is an alpha release there is also some missing functionality that was formerly present in v1.0. This includes CodeDom support, the static compiler that produced .NET assemblies, support for creating strongly typed delegates to script code, as well as a drastically changed hosting API. We will be bringing this functionality back to future releases in the IronPython 2.0 series as well many other improvements. You can download IronPython v2.0 at: 2.0 Alpha If you'd like more details about the DLR, Jim will be using his blog to post design notes as they are written over the next couple of weeks - http://blogs.msdn.com/hugunin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Mon Apr 30 18:50:11 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 30 Apr 2007 09:50:11 -0700 Subject: [IronPython] IronPython 2.0 Alpha 1 Released Message-ID: Woo hoo! From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, April 30, 2007 9:30 AM To: Discussion of IronPython Subject: [IronPython] IronPython 2.0 Alpha 1 Released Hello IronPython Community, We have just released IronPython 2.0 Alpha 1. IronPython 2.0 will be the first release of IronPython built upon a common dynamic language runtime (DLR) as well as targeting version 2.5 of Python. These release notes list what is new in IronPython 2.0, a brief overview of the DLR, and what to expect from the 2.0 release. One major focus during this release will be further improving our conformance with CPython. We?ve already made several improvements, for example one is that our type system no longer contains a hierarchy of types: now type(type) is type. We have also fixed a number of issues related to various statements such as imports and function definitions inside of exec or eval. There have also been a number of other small issues fixed that our users reported to us. IronPython 2.0 will also be the first major release to support 2.5 out of the box. In IronPython 1.x, and in this initial alpha release, users must enable this with a command line switch. During the 2.0 release cycle we will flush out the remaining 2.5 features and permanently enable this option. We will also start looking at supporting v2.6 features via command line switch and start some experimentation around the 3.0 features. In particular, we are excited about looking at the new bytes and string types as well as formatting options that we believe will fit nicely with .NET. IronPython 2.0 is also the first release built upon the Dynamic Language Runtime: a shared runtime for dynamic languages on .NET. The DLR both reduces the amount of work to create new dynamic languages on .NET enables rich interoperability between dynamic languages, and provides a shared module for consuming those languages from applications. We are particularly excited about the ability to share code across dynamic languages enabling users to share libraries without worrying the particular language in which the library is written. Over time, the DLR will expand and improve bringing language developers more benefits from this shared infrastructure. We also look forward to seeing a new era of programmable apps that can support a wide range of options for end-users. When we started working on the DLR we initially used the IronPython v1.0 code base. From there we extracted the core concepts that were common to dynamic languages, generalized the concepts that were specific to Python, expanded the framework to provide rich support for other dynamic languages, and exposed all of the languages via a common interface. Starting with IronPython 1.0 was an obvious choice because it had already captured many of the best practices for building dynamic languages on .NET and had done a great job leveraging many of the underlying features of .NET. In IronPython 2.0 all of these best practices are expanded and implemented with an eye on maximizing forward compatibility with new features in .NET v3.5 such as LINQ and extension methods. Moreover, the DLR exposes this functionality to the language implementer via a small set of core concepts that all dynamic language implementations can share. One additional change in this release is that we?re moving to use the Microsoft Permissive License for IronPython 2.0. Our original release of IronPython predated the Microsoft Permissive License, and so we created a custom license specifically for Iron Python. After releasing Iron Python, we created new Microsoft Shared Source licenses, including the Microsoft Permissive License, to facilitate and standardize source code licensing for appropriate Microsoft projects. We believe our users appreciate consistency in licensing from Microsoft. Therefore, because we are now using the more modern Microsoft Permissive License where appropriate for similar current source code releases, we feel we should offer IronPython under the Microsoft Permissive License as well. Note because this is an alpha release there is also some missing functionality that was formerly present in v1.0. This includes CodeDom support, the static compiler that produced .NET assemblies, support for creating strongly typed delegates to script code, as well as a drastically changed hosting API. We will be bringing this functionality back to future releases in the IronPython 2.0 series as well many other improvements. You can download IronPython v2.0 at: 2.0 Alpha If you?d like more details about the DLR, Jim will be using his blog to post design notes as they are written over the next couple of weeks ? http://blogs.msdn.com/hugunin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From LThompson at ixiacom.com Mon Apr 30 19:26:46 2007 From: LThompson at ixiacom.com (Lyle Thompson) Date: Mon, 30 Apr 2007 10:26:46 -0700 Subject: [IronPython] IP 2.0 and DLR In-Reply-To: References: Message-ID: <897A9E9DE9919A42B110869B344311F4102BA9@IXCA-EXCHANGE.ixiacom.com> Great news on IP 2.0! Could I get a little clarification on the DLR? " and provides a shared module for consuming those languages from applications." Is that the same as allowing consumption of IP assemblies from non-dynamic assemblies (e.g. C#)? Or will we still need to write/generate delegate wrappers around IP assemblies to consume them? Thanks, Lyle From dinov at exchange.microsoft.com Mon Apr 30 19:54:05 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 30 Apr 2007 10:54:05 -0700 Subject: [IronPython] IP 2.0 and DLR In-Reply-To: <897A9E9DE9919A42B110869B344311F4102BA9@IXCA-EXCHANGE.ixiacom.com> References: , <897A9E9DE9919A42B110869B344311F4102BA9@IXCA-EXCHANGE.ixiacom.com> Message-ID: <7AD436E4270DD54A94238001769C222790ACF7A478@DF-GRTDANE-MSG.exchange.corp.microsoft.com> These shared modules are for consumption from one dynamic language to another. So for example in Python I could do "import foo". Today IronPython v1.x falls back to looking at .NET assemblies to find namespaces if a Python module/package isn't found. In v2.0 we'll also fall back to the DLR module loader which might return say a module which was created from JavaScript or Ruby or another language. Unfortunately there's still no support for early-bound access to Python classes. ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Lyle Thompson [LThompson at ixiacom.com] Sent: Monday, April 30, 2007 10:26 AM To: users at lists.ironpython.com Subject: [IronPython] IP 2.0 and DLR Great news on IP 2.0! Could I get a little clarification on the DLR? " and provides a shared module for consuming those languages from applications." Is that the same as allowing consumption of IP assemblies from non-dynamic assemblies (e.g. C#)? Or will we still need to write/generate delegate wrappers around IP assemblies to consume them? Thanks, Lyle _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com