From davidescobar1976 at gmail.com Tue Dec 1 07:58:40 2009 From: davidescobar1976 at gmail.com (David Escobar) Date: Mon, 30 Nov 2009 22:58:40 -0800 Subject: [IronPython] Web Services library In-Reply-To: <4B0FB36F.4020801@gmail.com> References: <4B0FB36F.4020801@gmail.com> Message-ID: <38ef96bd0911302258h10e98848na858ff79f64af147@mail.gmail.com> One way to do it is to use the *wsdl.exe* tool to generate a proxy class. The tool will generate the proxy class in C# (it can't do IronPython code), but you can then take the resulting .cs file and compile it to a .dll (using the C# compiler - *csc.exe*). Place the .dll into the same folder as your IronPython program and add a reference to it from your IronPython code using the *clr.AddReference* method. Something like this: *import clr clr.AddReference("MyServiceProxyClass.dll") * There may be other methods as well, which I'm not aware of, but this is the way I would do it. The easiest way to get to *wsdl.exe* and *csc.exe* is to open up the Visual Studio command prompt, which puts all of these tools in your path - that way, you don't have to go hunting for the tools yourself. On Fri, Nov 27, 2009 at 3:09 AM, Pavel Suhotyuk wrote: > Hello. > > What a client library you recomend for using WebServices with IronPython ( > something like SOAP.PY ) ? > _______________________________________________ > 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 pavel.suhotjuk at gmail.com Tue Dec 1 08:15:04 2009 From: pavel.suhotjuk at gmail.com (Pavel Suhotyuk) Date: Tue, 01 Dec 2009 09:15:04 +0200 Subject: [IronPython] Web Services library In-Reply-To: <38ef96bd0911302258h10e98848na858ff79f64af147@mail.gmail.com> References: <4B0FB36F.4020801@gmail.com> <38ef96bd0911302258h10e98848na858ff79f64af147@mail.gmail.com> Message-ID: <4B14C278.7010804@gmail.com> Thank you for the answer. Yes, I know about this way, but we have a part of processing system. This component compile and run many scripts and we want to have dynamic way to construct/destruct SOAP classes. David Escobar wrote: > One way to do it is to use the /wsdl.exe/ tool to generate a proxy > class. The tool will generate the proxy class in C# (it can't do > IronPython code), but you can then take the resulting .cs file and > compile it to a .dll (using the C# compiler - /csc.exe/). Place the .dll > into the same folder as your IronPython program and add a reference to > it from your IronPython code using the *clr.AddReference* method. > Something like this: > > *import clr > clr.AddReference("MyServiceProxyClass.dll") > * > There may be other methods as well, which I'm not aware of, but this is > the way I would do it. The easiest way to get to /wsdl.exe/ and > /csc.exe/ is to open up the Visual Studio command prompt, which puts all > of these tools in your path - that way, you don't have to go hunting for > the tools yourself. > > > > On Fri, Nov 27, 2009 at 3:09 AM, Pavel Suhotyuk > > wrote: > > Hello. > > What a client library you recomend for using WebServices with > IronPython ( something like SOAP.PY ) ? > _______________________________________________ > 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 pavel.suhotjuk at gmail.com Tue Dec 1 09:22:20 2009 From: pavel.suhotjuk at gmail.com (Pavel Suhotyuk) Date: Tue, 01 Dec 2009 10:22:20 +0200 Subject: [IronPython] Using ruby module from python. In-Reply-To: <4B342496A3EFEB48839E10BB4BF5964C1826E1FB@TK5EX14MBXC129.redmond.corp.microsoft.com> References: <4B13A06A.7040601@gmail.com> <4B342496A3EFEB48839E10BB4BF5964C1826E1FB@TK5EX14MBXC129.redmond.corp.microsoft.com> Message-ID: <4B14D23C.6050800@gmail.com> Thank you for replay. I will try to use this way. Tomas Matousek wrote: > Our Python-Ruby interop is not quite done yet so you need to use some workarounds. > > The easiest way how to get WSDL factory instance would be to write a simple Ruby script that loads it: > > == wsdl.rb == > > require 'soap/wsdlDriver' > > def get_factory > SOAP::WSDLDriverFactory > end > > === > > And then you can do: >>>> import clr >>>> wsdl = clr.Use('wsdl.rb', 'rb') >>>> factory = wsdl.get_factory() >>>> print factory("x.wsdl") > Traceback (most recent call last): > File "", line 1, in > SystemError: Cannot connect to x.wsdl (Not HTTP.) > > > get_factory method is exposed on the "wsdl" module so that Python can call it. IronRuby doesn't yet implement dynamic protocols for constant access so you need the get_factory helper for accessing Ruby constants. > Also we have some work to do to make clr.Use work better with libraries of other DLR languages. > Let us know if you hit some other issues. > > Tomas > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pavel Suhotyuk > Sent: Monday, November 30, 2009 2:38 AM > To: Discussion of IronPython > Subject: [IronPython] Using ruby module from python. > > Hello. > > I want try to use ruby library (soap) in python code. > I found method Use(str) in clr module for load the specified module searching all languages in the loaded ScriptRuntime, but don't understand how to used it. > > I try to call this method in any variants, but nothing happends. > > >>> import clr > >>> clr.Use('soap/wsdlDriver') > Traceback (most recent call last): > File "", line 1, in > ValueError: couldn't find module soap/wsdlDriver to use >>> clr.Use('soap.wsdlDriver') Traceback (most recent call last): > File "", line 1, in > ValueError: couldn't find module soap.wsdlDriver to use >>> clr.Use('soap/wsdlDriver.rb') Traceback (most recent call last): > File "", line 1, in > ValueError: couldn't find module soap/wsdlDriver.rb to use >>> clr.Use(r'''C:\usr\env\IronRuby\lib\ruby\1.8\soap\wsdlDriver.rb''', > 'rb') > > >>> m = > clr.Use(r'''C:\usr\env\IronRuby\lib\ruby\1.8\soap\wsdlDriver.rb''', 'rb') >>> m >>> dir(m) ['__builtins__'] > > > Thanks. > _______________________________________________ > 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 pavel.suhotjuk at gmail.com Tue Dec 1 14:26:46 2009 From: pavel.suhotjuk at gmail.com (Pavel Suhotyuk) Date: Tue, 01 Dec 2009 15:26:46 +0200 Subject: [IronPython] Using ruby module from python. In-Reply-To: <4B342496A3EFEB48839E10BB4BF5964C1826E1FB@TK5EX14MBXC129.redmond.corp.microsoft.com> References: <4B13A06A.7040601@gmail.com> <4B342496A3EFEB48839E10BB4BF5964C1826E1FB@TK5EX14MBXC129.redmond.corp.microsoft.com> Message-ID: <4B151996.8000306@gmail.com> I try your example. It's really work, but have some problem with ruby objects: 1) Can't call RubyObject methods. >>> import clr >>> wsdl = clr.Use('wsdl.rb', 'rb') >>> factory = wsdl.get_factory() >>> client = factory('http://localhost/PaymentsBroker/Manager/ProviderService.asmx?WSDL').create_rpc_drive() Traceback (most recent call last): File "", line 1, in AttributeError: 'RubyObject' object has no attribute 'create_rpc_drive' >>> client = getattr(factory('http://localhost/PaymentsBroker/Manager/ProviderService.asmx?WSDL'), 'create_rpc_driver')() >>> 2) Calling methods without parameters possible. >>> client.GetProviders(None) ]> But I don't understand how call methods with parameters. In ruby I can call like this: >>> print client.GetBalance(:providerId => 3).getBalanceResult().balance 60663.89=> nil In python it's not work: >>> client.GetBalance(3) Traceback (most recent call last): File "", line 1, in SystemError: SOAP::Mapping::MappingError >>> client.GetBalance(provider=3) Traceback (most recent call last): File "", line 1, in TypeError: RubyMethod is not callable >>> getattr(client, 'GetBalance')(3) Traceback (most recent call last): File "", line 1, in SystemError: SOAP::Mapping::MappingError >>> getattr(client, 'GetBalance')(provider=3) Traceback (most recent call last): File "", line 1, in TypeError: RubyMethod is not callable >>> getattr(client, 'GetBalance')({'providerId':3}) Traceback (most recent call last): File "", line 1, in SystemError: SOAP::Mapping::MappingError >>> getattr(client, 'GetBalance')({'providerId':3}) Traceback (most recent call last): File "", line 1, in SystemError: SOAP::Mapping::MappingError >>> getattr(client, 'GetBalance')({':providerId':3}) Traceback (most recent call last): File "", line 1, in SystemError: SOAP::Mapping::MappingError Tomas Matousek wrote: > Our Python-Ruby interop is not quite done yet so you need to use some workarounds. > > The easiest way how to get WSDL factory instance would be to write a simple Ruby script that loads it: > > == wsdl.rb == > > require 'soap/wsdlDriver' > > def get_factory > SOAP::WSDLDriverFactory > end > > === > > And then you can do: >>>> import clr >>>> wsdl = clr.Use('wsdl.rb', 'rb') >>>> factory = wsdl.get_factory() >>>> print factory("x.wsdl") > Traceback (most recent call last): > File "", line 1, in > SystemError: Cannot connect to x.wsdl (Not HTTP.) > > > get_factory method is exposed on the "wsdl" module so that Python can call it. IronRuby doesn't yet implement dynamic protocols for constant access so you need the get_factory helper for accessing Ruby constants. > Also we have some work to do to make clr.Use work better with libraries of other DLR languages. > Let us know if you hit some other issues. > > Tomas > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pavel Suhotyuk > Sent: Monday, November 30, 2009 2:38 AM > To: Discussion of IronPython > Subject: [IronPython] Using ruby module from python. > > Hello. > > I want try to use ruby library (soap) in python code. > I found method Use(str) in clr module for load the specified module searching all languages in the loaded ScriptRuntime, but don't understand how to used it. > > I try to call this method in any variants, but nothing happends. > > >>> import clr > >>> clr.Use('soap/wsdlDriver') > Traceback (most recent call last): > File "", line 1, in > ValueError: couldn't find module soap/wsdlDriver to use >>> clr.Use('soap.wsdlDriver') Traceback (most recent call last): > File "", line 1, in > ValueError: couldn't find module soap.wsdlDriver to use >>> clr.Use('soap/wsdlDriver.rb') Traceback (most recent call last): > File "", line 1, in > ValueError: couldn't find module soap/wsdlDriver.rb to use >>> clr.Use(r'''C:\usr\env\IronRuby\lib\ruby\1.8\soap\wsdlDriver.rb''', > 'rb') > > >>> m = > clr.Use(r'''C:\usr\env\IronRuby\lib\ruby\1.8\soap\wsdlDriver.rb''', 'rb') >>> m >>> dir(m) ['__builtins__'] > > > Thanks. > _______________________________________________ > 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 merllab at microsoft.com Tue Dec 1 17:53:02 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Tue, 1 Dec 2009 08:53:02 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/61888. MODIFIED SOURCES $/IronPython/IronPython_Main/Src/AssemblyVersion.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Properties/ExtensionAssemblyInfo.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/Properties/AssemblyInfo.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/AssemblyInfo.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Properties/AssemblyInfo.cs From nbuttarelli at gmail.com Tue Dec 1 19:48:48 2009 From: nbuttarelli at gmail.com (=?ISO-8859-1?Q?Nicol=E1s_Buttarelli?=) Date: Tue, 1 Dec 2009 19:48:48 +0100 Subject: [IronPython] Safe execution of python scripts on my .net application In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04C78DD9@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <2c2511410911021238k10d57f8duc8ce268a5fbc18ab@mail.gmail.com> <2c2511410911031306m523d8cccs3d0daa248e461bb7@mail.gmail.com> <2c2511410911031329h231181a8g6f9ade8f28de973a@mail.gmail.com> <1A472770E042064698CB5ADC83A12ACD04C2EC54@TK5EX14MBXC118.redmond.corp.microsoft.com> <8E45365BECA665489F3CB8878A6C1B7D0C7B5085@TK5EX14MBXC140.redmond.corp.microsoft.com> <2c2511410911051117w19b1a8a7y54aeee45bd1701a9@mail.gmail.com> <1A472770E042064698CB5ADC83A12ACD04C4C7D0@TK5EX14MBXC118.redmond.corp.microsoft.com> <2c2511410911060035j3c9b12c2xa9b023a2fe743dc9@mail.gmail.com> <2c2511410911090748n6e9c66cem5b601627e54bdf75@mail.gmail.com> <1A472770E042064698CB5ADC83A12ACD04C78DD9@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <2c2511410912011048m7c9f26fas28dfd9573782ee38@mail.gmail.com> Hi all, I'm bringing again some problem that I though that it was solved for me. I have to run some python code that comes from a web service, so I want to execute it in a sandbox with restricted permissions. I also want to execute some .NET code from these scripts and I want to have all the permissions (create files, access to the database, etc) for them. I have tried several options and I can't get it working. I have follow the last options that Dino told me but they didn't work either. I will try to explain all the options that I have managed, please let me know if something is not clear enough. *[1]* I am creating my AppDomain in the following way. AppDomainSetup anAppDomainSetup = new AppDomainSetup(); anAppDomainSetup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory; anAppDomainSetup.ApplicationName = "Testing"; Evidence evidence = new Evidence(); evidence.AddHost(new Zone(SecurityZone.Internet)); return AppDomain.CreateDomain("Test Domain", evidence, anAppDomainSetup); *[2]* Another option is to create it using *AppDomain.CreateDomain(aName, aEvidence, anAppDomainSetup, aPermissionSet, aStrongNameArray)*, but I have already told here, when you try to create the engine using * Python.CreateEngine(appDomain)*, it throws an Serialization exception of the Microsoft.Scripting. * * *[3]* I have also added the StrongName of the assembly to de Evidence using: * * * evidence.AddHost(CreateStrongName(Assembly.GetAssembly(typeof(TestingAssembly.FileFactory)))); * * * but it doesn't work. *[4]* I have subclassified my class *FileFactory* with MarshalByRefObject class, then I have created another appDomain with all the permissions. Then I create an instance of this class *FileFactory *using: * * *FileFactory aFileFactory = (FileFactory)appDomain.CreateInstanceAndUnwrap("TestingAssembly", "TestingAssembly.FileFactory")* and finally, I have set o the scope the variable *aFileFactory* * * *scope.SetVariable("aFileFactory", aFileFactory);* * * but when I try to create or delete a file previously created, it doesn't work. *[5]* I had to add the attribute to the assembly to allow Partially Trusted Callers [assembly: AllowPartiallyTrustedCallers] and the code is executed, but the AppDomain where the script is execute applies its security policy without taking into account the AppDomain where the object have been instantiated. *[6]* Here is an example of a test that probably will clarify what I am trying to do. *AppDomain appDomain = TestSupportMethods.CreateFullTrustSandboxedAppDomain();* *FileFactory aFileFactory = (FileFactory)appDomain.CreateInstanceAndUnwrap("TestingAssembly", TestingAssembly.FileFactory");* * * *// Here the file is created and then deleted, so it means that the FullTrustSandboxed allows to create files.* *aFileFactory.createFile();* *aFileFactory.deleteFile();* *string pythonCode = @"aFileFactory.createFile()";* *ScriptEngine engine = Python.CreateEngine(TestSupportMethods.CreateSafeSandboxedAppDomainWithEvidence()); * *ScriptSource source = engine.CreateScriptSourceFromString(pythonCode);* *ScriptScope scope = engine.CreateScope();* *scope.SetVariable("aFileFactory", aFileFactory);* *source.Execute(scope);* It throws... *System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.. * Well, sorry about the size of the email. Please let me know if you have new ideas, I will do my best to test them. Regards, Nicolas On Mon, Nov 9, 2009 at 7:44 PM, Dino Viehland wrote: > Couple of options spring to mind: > > 1. Setup evidence such that your assembly is given full trust. I > believe you had the start of this in your other code where you were adding > some strong name evidence. You should be able to search the web for normal > .NET partial trust scenarios for getting this right. > > 2. Setup your object model so that it is a MarshalByRefObject which > lives in another app domain. You can then expose the remote object to the > partial trust app domain via SetVariable. > > > > As far as including the DLL ? you can call LoadAssembly on the > ScriptRuntime and give it your assembly. Then the user can import all of > the types from your DLL as they need them. That won?t work w/ #2 though. > Alternately you can implement IAttributesCollection (or use a dynamic object > in 2.6 although IAC is still supported) and create a scope w/ that as the > backing storage. Then you?ll be able to lazily resolve the members rather > than eagerly populating them - although you still need some code to lazily > resolve them. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Nicol?s Buttarelli > *Sent:* Monday, November 09, 2009 7:49 AM > > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Safe execution of python scripts on my .net > application > > > > Hi all again, I am still working with the same problem. > > > > Now I am creating the appDomain in this way by recommendation of Dino: > > > > *public static AppDomain CreateSandboxAppDomain()* > > * {* > > * AppDomainSetup anAppDomainSetup = new AppDomainSetup();* > > * anAppDomainSetup.ApplicationBase = > AppDomain.CurrentDomain.BaseDirectory;* > > * anAppDomainSetup.ApplicationName = "Testing";* > > * Evidence evidence = new Evidence();* > > * evidence.AddHost(new Zone(SecurityZone.Internet));* > > * * > > * AppDomain aSandboxedDomain = AppDomain.CreateDomain("Test > Domain", * > > * > evidence, * > > * > anAppDomainSetup);* > > * * > > * return aSandboxedDomain;* > > * }* > > > > Now it is working but I have security restrictions over some .dll that I > want to have full trusted permissions. I am trying to do this: > > > > *string aPythonScript =* > > *@"aDocument = CDLDocument()* > > *aFigure = TextBlock(1, 'type 1')* > > *anotherFigure = TextBlock(2, 'type 2')* > > *aDocument.AddFigure(aFigure)* > > *aDocument.AddFigure(anotherFigure)* > > *aList = aDocument.Figures* > > *";* > > > > *ScriptSource source = engine.CreateScriptSourceFromString(aPythonScript); > * > > *ScriptScope scope = engine.CreateScope();* > > * * > > *scope.SetVariable("CDLDocument", typeof(CDLDocument));* > > *scope.SetVariable("TextBlock", typeof(TextBlock));* > > *source.Execute(scope);* > > > > This is throwing the System.Security.SecurityException. > > > > 1. How can I give full trusted to a specific dll in an AppDomain? > > > > 2. How can I include a .dll to the scope instead of do a SetVariable for > each type which I have to manage from the python script? > > > > Thanks! > > Nicol?s > > > > 2009/11/6 Nicol?s Buttarelli > > Hi, > > On Fri, Nov 6, 2009 at 1:07 AM, Dino Viehland wrote: > > So you?ve run this as a standalone program and it?s failing? In the > standalone app are all of the IronPython and DLR DLLs present > (IronPython.dll, IronPython.modules.dll, Microsoft.Scripting.Core.dll, > Microsoft.Scripting.dll, Microsoft.Dynamic.dll and > Micrsoft.Scripting.Extensionattribute.dll)? > > Yes I have all this dlls present. > > > > A slightly modified version of this, dropping the strong name, works just > fine for me: > > > > using System; > > using Microsoft.Scripting; > > using Microsoft.Scripting.Hosting; > > using IronPython.Hosting; > > using System.Security; > > using System.Security.Permissions; > > > > class Test { > > public static void Main(string[] args) { > > > > PermissionSet aRestrictedPermissionSet = new > PermissionSet(PermissionState.None); > > aRestrictedPermissionSet.AddPermission(new > SecurityPermission(SecurityPermissionFlag.Execution)); > > > > AppDomainSetup domaininfo = new AppDomainSetup(); > > domaininfo.ApplicationBase = System.Environment.CurrentDirectory; > > > > AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed > Domain", > > AppDomain.CurrentDomain.Evidence, > > domaininfo, > > aRestrictedPermissionSet); > > > > ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); > > ScriptSource source = engine.CreateScriptSourceFromString("2+2"); > > ScriptScope scope = engine.CreateScope(); > > Console.WriteLine(source.Execute(scope)); > > > > } > > } > > > Great, I will try this after university. Thanks! > > Compile with: > > > > csc test.cs /r:Microsoft.Scripting.Core.dll /r:Microsoft.Scripting.dll > /r:IronPython.dll > > > > And run and it prints 4. Does that not work for you? > > > > We also have a different way we do this in our test suite which also works: > > > > AppDomainSetup info = new AppDomainSetup(); > > info.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory; > > info.ApplicationName = "Test"; > > Evidence evidence = new Evidence(); > > evidence.AddHost(new Zone(SecurityZone.Internet)); > > AppDomain newDomain = AppDomain.CreateDomain("test", evidence, > info); > > > > // create runtime in partial trust... > > ScriptRuntime runtime = Python.CreateRuntime(newDomain); > > > > // get the Python engine... > > ScriptEngine engine = runtime.GetEngine("py"); > > > This make sense too, I will try it. Thanks again. > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Nicol?s Buttarelli > *Sent:* Thursday, November 05, 2009 11:18 AM > > > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Safe execution of python scripts on my .net > application > > > > Again, thanks everyone for your help. > > > > But.. I bring bad news. This is still not working and it doesn't depend on > the Test environment. > > > > I create another proyect, a Form project, with one button which executes > the following code: > > > > // Creating the permission set to grant other assemblies > > PermissionSet aRestrictedPermissionSet = new > PermissionSet(PermissionState.None); > > aRestrictedPermissionSet.AddPermission(new > SecurityPermission(SecurityPermissionFlag.Execution)); > > > > AppDomainSetup domaininfo = new AppDomainSetup(); > > domaininfo.ApplicationBase = System.Environment.CurrentDirectory; > > > > List strongNameList = new List(); > > strongNameList.Add(CreateStrongName(Assembly.GetExecutingAssembly())); > > > > AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed Domain", > > > AppDomain.CurrentDomain.Evidence, > > > domaininfo, > > > aRestrictedPermissionSet, > > > strongNameList.ToArray()); > > > > ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); > > ScriptSource source = engine.CreateScriptSourceFromString(pythonScript); > > ScriptScope scope = engine.CreateScope(); > > source.Execute(scope); > > > > It throws this error: > > Type is not resolved for member > 'Microsoft.Scripting.Hosting.ScriptRuntimeSetup,Microsoft.Scripting, > Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. > > > > I used the fuslogvw application to see if the Microsoft.Scripting is > loaded, an it is. > > > > What seems strange for me is that anyone has tried this before. I hope to > find some more help here. > > > > Regards, > > Nicolas > > > > > > On Wed, Nov 4, 2009 at 7:36 PM, Shri Borde > wrote: > > http://www.dev102.com/2008/03/22/3-ways-to-run-nunit-from-visual-studio/has some info about test projects and appbase problems. > > > > You can also use fuslogvw ( > http://msdn.microsoft.com/en-us/library/e74a18c4(VS.71).aspx)to see why Microsoft.Scripting.dll is failing to load. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Dino Viehland > *Sent:* Tuesday, November 03, 2009 1:52 PM > > > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Safe execution of python scripts on my .net > application > > > > Test projects are weird and somehow you don?t end up inheriting the > application base. This seems to work though: > > > > AppDomainSetup setup = new AppDomainSetup(); > > setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory; > > AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed > Domain", null, setup); > > ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); > > ScriptSource source = > engine.CreateScriptSourceFromString("2+2"); > > ScriptScope scope = engine.CreateScope(); > > Console.WriteLine(source.Execute(scope)); > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Nicol?s Buttarelli > *Sent:* Tuesday, November 03, 2009 1:30 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Safe execution of python scripts on my .net > application > > > > I have create a new "Test Project" and an Unit Test class in order to test > the following code inside: > > > > AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed Domain"); > > ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); > > ScriptSource source = engine.CreateScriptSourceFromString(pythonScript); > > ScriptScope scope = engine.CreateScope(); > > source.Execute(scope); > > > > > > I have add the references: > > > > - IronPython > > - Microsoft.Scripting > > - Microsoft.ScriptingCore > > > > But it still not working and throwing the > same System.Runtime.Serialization.SerializationException: Type is not > resolved for member > 'Microsoft.Scripting.Hosting.ScriptRuntimeSetup,Microsoft.Scripting. > > > > Any ideas? > > > > > > 2009/11/3 Nicol?s Buttarelli > > Thanks Shri, I will try. > > > > In addition, I found this open issue: > http://dlr.codeplex.com/WorkItem/View.aspx?WorkItemId=2816. I think that > it is related. > > > > On Tue, Nov 3, 2009 at 9:29 PM, Shri Borde > wrote: > > I think this happens if the new appdomain cannot load the required > assembly. By default, the new appdomain should inherit its BaseDirectory > property from the creating domain and should be able to load > Microsoft.Scripting.dll. Is your exe and all the dlls in the same folder? If > not, can you try to put all assemblies in the same folder (or in the GAC) to > see if it works? If that works, you can then figure out how to configure the > new appdomain such that it can load Microsoft.Scripting.dll. There may be > some setting in AppDomainSetup, or you could hook the AssemblyResolve event? > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Nicol?s Buttarelli > *Sent:* Tuesday, November 03, 2009 12:08 PM > > > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Safe execution of python scripts on my .net > application > > > > Hi again, thanks for your clear response. > > > > I was trying to do what you proposed but it is not working. I am receiving > an exception: > > > > *Test method > CadworX3WCFRestTest.IronPython.SafeScriptExecutionTest.writingAFileTest > threw exception: System.Runtime.Serialization.SerializationException: Type > is not resolved for member > 'Microsoft.Scripting.Hosting.ScriptRuntimeSetup,Microsoft.Scripting, > Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'..* > > I tried to find a solution but I couldn't. This is the minimal code that I > am running to get this exception (I have removed all the security stuff but > apparently that does not resolve the problem): > > > > *AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed Domain");* > > > > *ScriptEngine engine = Python.CreateEngine(aSandboxedDomain);* > > *ScriptSource source = engine.CreateScriptSourceFromString(pythonScript);* > > *SriptScope scope = engine.CreateScope();* > > *source.Execute(scope);* > > > > The exception is thronged in this line: > > *ScriptEngine engine = Python.CreateEngine(aSandboxedDomain);* > > > > > > Do you have any idea which could be the problem? > > > > Thanks again, > > Nicolas > > > > On Mon, Nov 2, 2009 at 10:25 PM, Dino Viehland > wrote: > > Assuming the app domain is setup properly then there?s no way for the > Python code to elevate permissions (modulo CLR security bugs which are few > and far between). This is because IronPython its self is 100% security > transparent and does not affect any security decisions or assert any form of > trust ? so it?s all up to the CLR to limit permissions. So for example > while you can access the file object, or import ctypes, or call various > other Python APIs which would require trust you?ll get a security exception > from the CLR when you don?t have permissions to do something. > > > > For more complex scenarios you might also have an object model which you > expose to the application and inject in via its scope. Once you?ve done > that you?ll want to make sure that the object model is also secure. > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Nicol?s Buttarelli > *Sent:* Monday, November 02, 2009 1:20 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Safe execution of python scripts on my .net > application > > > > Thanks for your response. > > > > But what happens with the python code? Does not exist a way to write some > scripts that can do some damage to my app, the server, the database, etc? > > > > Thanks again, > > Nicolas > > > > On Mon, Nov 2, 2009 at 9:41 PM, Dino Viehland wrote: > > After creating your app domain you can do: > > > > ScriptEngine engine = Python.CreateEngine(someAppDomain); > > > > And then the rest of your code should work as it?s written. > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Nicol?s Buttarelli > *Sent:* Monday, November 02, 2009 12:39 PM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Safe execution of python scripts on my .net > application > > > > Sorry, I don't know if my previous message have arrived. So, here it is: > > > > > > Hello all, > > > > I am starting with python and I would like to add to my web application > some web services. This services will allow the different clients of my > application to execute some python scripts. > > > > I would like to know if someone did this before and how can I do this in a > secure way. I mean, how can I do to restrict the environment where the > scripts will be executed. > > > > In .net I can do this using the AppDoman and setting the permission set. > > > > AppDomain.CreateDomain( string friendlyName, > Evidence securityInfo, > AppDomainSetup info, > PermissionSet grantSet, > params StrongName[] fullTrustAssemblies); > > > > > > Is there a way to do the same with my python scripts? > > > > I am running them using this: > > > > ScriptEngine engine = Python.CreateEngine(); > > ScriptSource source = engine.CreateScriptSourceFromString(scriptAsString); > > ScriptScope scope = engine.CreateScope(); > > source.Execute(scope); > > > > Thanks in advance. > > Nicolas > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Tue Dec 1 21:07:14 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Tue, 1 Dec 2009 12:07:14 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <520d00f5-11e6-4787-91bc-ab39ba9f7c06@tk5-exsmh-c102.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/61892. MODIFIED SOURCES $/IronPython/IronPython_2_6/Src/AssemblyVersion.cs $/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/Properties/AssemblyInfo.cs $/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Scripting.Core/Properties/ExtensionAssemblyInfo.cs $/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Scripting.Core/Properties/AssemblyInfo.cs $/IronPython/IronPython_2_6/Src/Hosts/SilverLight/Chiron/Properties/AssemblyInfo.cs $/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Scripting.Debugging/AssemblyInfo.cs $/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Scripting/Properties/AssemblyInfo.cs From leculver at microsoft.com Wed Dec 2 00:06:47 2009 From: leculver at microsoft.com (Lee Culver) Date: Tue, 1 Dec 2009 23:06:47 +0000 Subject: [IronPython] Is it possible to get the DLR's AST when it fails to parse? Message-ID: <583F11613AC4F044B32175D273E48C90225DA38B@TK5EX14MBXC112.redmond.corp.microsoft.com> I have been playing with an implementation of a simple GUI console for IronPython (similar to IDLE, without it's text-editor IDE). I've mostly brought it up to rough feature parity with IDLE, but I'd like to add a rudimentary itellisense such that when you type something on the order of "foo.", the interpreter can pop up a menu containing the contents of foo (assuming it's something already defined in the local scope). However, I'd really rather not get in the business of parsing Python code. (That's what the DLR is for!) Is there any way I can use DLR to give me the AST up to the point at which it failed to parse so that I can walk that and see if we are in a valid place to look up the fields of an object? I looked at using the ErrorListener class with ScriptSource.Compile, but it only gives me "unexpected found" at the point where the "." is...which I already knew. Basically, whenever the user presses the "." key in the console what I would like to do is roughly this code: ScriptEngine engine = Python.CreateEngine(); ScriptScope scope = engine.CreateScope(); ScriptSource source = engine.CreateScriptSourceFromString("if foo.", Microsoft.Scripting.SourceCodeKind.InteractiveCode); source.Compile(); // <-- This *should* fail. I want the AST when it does. Primarily, I'm trying to find chains of identifiers to walk so that I can display the Nth identifier's fields: identifier1 . identifier2 . identifier3 . ... I need to distinguish this from things like this, because there's nothing you can reasonably do to have intellisense in this case: Function(args) . identifier1 . identifier2 (Yes, I realize that walking this chain can execute code and have side effects, I'm willing to live with that for my purposes.) Is there any mechanism through which I can have the DLR parse this for me and give me the resulting AST that I can walk so I can see if we can pop up an intellisense-like view? Can anyone recommend a better way to do this outside of simply writing my own mini-parser? Thanks, -Lee Culver -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Wed Dec 2 01:06:52 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 02 Dec 2009 00:06:52 +0000 Subject: [IronPython] Is it possible to get the DLR's AST when it fails to parse? In-Reply-To: <583F11613AC4F044B32175D273E48C90225DA38B@TK5EX14MBXC112.redmond.corp.microsoft.com> References: <583F11613AC4F044B32175D273E48C90225DA38B@TK5EX14MBXC112.redmond.corp.microsoft.com> Message-ID: <4B15AF9C.6000808@voidspace.org.uk> No time for a longer reply, but you probably want to tokenize rather than parse. Michael Lee Culver wrote: > > I have been playing with an implementation of a simple GUI console for > IronPython (similar to IDLE, without it?s text-editor IDE). I?ve > mostly brought it up to rough feature parity with IDLE, but I?d like > to add a rudimentary itellisense such that when you type something on > the order of ?foo.?, the interpreter can pop up a menu containing the > contents of foo (assuming it?s something already defined in the local > scope). However, I?d really rather not get in the business of parsing > Python code. (That?s what the DLR is for!) > > Is there any way I can use DLR to give me the AST up to the point at > which it failed to parse so that I can walk that and see if we are in > a valid place to look up the fields of an object? I looked at using > the ErrorListener class with ScriptSource.Compile, but it only gives > me ?unexpected found? at the point where the ?.? is?which I > already knew. > > Basically, whenever the user presses the ?.? key in the console what I > would like to do is roughly this code: > > ScriptEngine engine = Python.CreateEngine(); > > ScriptScope scope = engine.CreateScope(); > > ScriptSource source = engine.CreateScriptSourceFromString("if foo.", > Microsoft.Scripting.SourceCodeKind.InteractiveCode); > > source.Compile(); // <-- This *should* fail. I want the AST when it does. > > Primarily, I?m trying to find chains of identifiers to walk so that I > can display the Nth identifier?s fields: > > identifier1 . identifier2 . identifier3 . ? > > I need to distinguish this from things like this, because there?s > nothing you can reasonably do to have intellisense in this case: > > Function(args) . identifier1 . identifier2 > > (Yes, I realize that walking this chain can execute code and have side > effects, I?m willing to live with that for my purposes.) Is there any > mechanism through which I can have the DLR parse this for me and give > me the resulting AST that I can walk so I can see if we can pop up an > intellisense-like view? > > Can anyone recommend a better way to do this outside of simply writing > my own mini-parser? > > Thanks, > > -Lee Culver > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From dinov at microsoft.com Wed Dec 2 01:14:57 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 2 Dec 2009 00:14:57 +0000 Subject: [IronPython] Is it possible to get the DLR's AST when it fails to parse? In-Reply-To: <4B15AF9C.6000808@voidspace.org.uk> References: <583F11613AC4F044B32175D273E48C90225DA38B@TK5EX14MBXC112.redmond.corp.microsoft.com> <4B15AF9C.6000808@voidspace.org.uk> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D28642@TK5EX14MBXC118.redmond.corp.microsoft.com> Tokenization would save some work but he could also just use the IronPython parser. It's unfortunately a small pain to create (it's overly tied to the DLR APIs right now) but it's: return Parser.CreateParser( new CompilerContext(sourceUnit, new PythonCompilerOptions(), ErrorSink.Null), new PythonOptions() ); And to get that SourceUnit you can do HostingHelpers.GetSourceUnit on the ScriptSource. The resulting parsed expression will include ErrorExpression's where we encounter invalid code. You may also find that things like class and function definitions can be missing their names if you are parsing incomplete code like "def ". Then you'll be working on the IronPython AST instead of the DLR AST (but the two will be the same likely in IronPython 2.6.1 - the ASTs are now reducible DLR ASTs). > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Tuesday, December 01, 2009 4:07 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Is it possible to get the DLR's AST when it fails to > parse? > > No time for a longer reply, but you probably want to tokenize rather > than parse. > > Michael > > Lee Culver wrote: > > > > I have been playing with an implementation of a simple GUI console for > > IronPython (similar to IDLE, without it's text-editor IDE). I've > > mostly brought it up to rough feature parity with IDLE, but I'd like > > to add a rudimentary itellisense such that when you type something on > > the order of "foo.", the interpreter can pop up a menu containing the > > contents of foo (assuming it's something already defined in the local > > scope). However, I'd really rather not get in the business of parsing > > Python code. (That's what the DLR is for!) > > > > Is there any way I can use DLR to give me the AST up to the point at > > which it failed to parse so that I can walk that and see if we are in > > a valid place to look up the fields of an object? I looked at using > > the ErrorListener class with ScriptSource.Compile, but it only gives > > me "unexpected found" at the point where the "." is...which I > > already knew. > > > > Basically, whenever the user presses the "." key in the console what I > > would like to do is roughly this code: > > > > ScriptEngine engine = Python.CreateEngine(); > > > > ScriptScope scope = engine.CreateScope(); > > > > ScriptSource source = engine.CreateScriptSourceFromString("if foo.", > > Microsoft.Scripting.SourceCodeKind.InteractiveCode); > > > > source.Compile(); // <-- This *should* fail. I want the AST when it does. > > > > Primarily, I'm trying to find chains of identifiers to walk so that I > > can display the Nth identifier's fields: > > > > identifier1 . identifier2 . identifier3 . ... > > > > I need to distinguish this from things like this, because there's > > nothing you can reasonably do to have intellisense in this case: > > > > Function(args) . identifier1 . identifier2 > > > > (Yes, I realize that walking this chain can execute code and have side > > effects, I'm willing to live with that for my purposes.) Is there any > > mechanism through which I can have the DLR parse this for me and give > > me the resulting AST that I can walk so I can see if we can pop up an > > intellisense-like view? > > > > Can anyone recommend a better way to do this outside of simply writing > > my own mini-parser? > > > > Thanks, > > > > -Lee Culver > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Wed Dec 2 01:18:22 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 2 Dec 2009 00:18:22 +0000 Subject: [IronPython] Safe execution of python scripts on my .net application In-Reply-To: <2c2511410912011048m7c9f26fas28dfd9573782ee38@mail.gmail.com> References: <2c2511410911021238k10d57f8duc8ce268a5fbc18ab@mail.gmail.com> <2c2511410911031306m523d8cccs3d0daa248e461bb7@mail.gmail.com> <2c2511410911031329h231181a8g6f9ade8f28de973a@mail.gmail.com> <1A472770E042064698CB5ADC83A12ACD04C2EC54@TK5EX14MBXC118.redmond.corp.microsoft.com> <8E45365BECA665489F3CB8878A6C1B7D0C7B5085@TK5EX14MBXC140.redmond.corp.microsoft.com> <2c2511410911051117w19b1a8a7y54aeee45bd1701a9@mail.gmail.com> <1A472770E042064698CB5ADC83A12ACD04C4C7D0@TK5EX14MBXC118.redmond.corp.microsoft.com> <2c2511410911060035j3c9b12c2xa9b023a2fe743dc9@mail.gmail.com> <2c2511410911090748n6e9c66cem5b601627e54bdf75@mail.gmail.com> <1A472770E042064698CB5ADC83A12ACD04C78DD9@TK5EX14MBXC118.redmond.corp.microsoft.com> <2c2511410912011048m7c9f26fas28dfd9573782ee38@mail.gmail.com> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D28660@TK5EX14MBXC118.redmond.corp.microsoft.com> I think you need to add an Assert into FileFactory.createFile/deleteFile. See also: http://blogs.msdn.com/shawnfa/archive/2004/08/23/219155.aspx and http://msdn.microsoft.com/en-us/library/system.security.codeaccesspermission.assert.aspx W/o the assert I think the stack walk will continue and find the lower trust caller higher on the stack, but w/ it the stack walk should stop. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Nicol?s Buttarelli Sent: Tuesday, December 01, 2009 10:49 AM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application Hi all, I'm bringing again some problem that I though that it was solved for me. I have to run some python code that comes from a web service, so I want to execute it in a sandbox with restricted permissions. I also want to execute some .NET code from these scripts and I want to have all the permissions (create files, access to the database, etc) for them. I have tried several options and I can't get it working. I have follow the last options that Dino told me but they didn't work either. I will try to explain all the options that I have managed, please let me know if something is not clear enough. [1] I am creating my AppDomain in the following way. AppDomainSetup anAppDomainSetup = new AppDomainSetup(); anAppDomainSetup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory; anAppDomainSetup.ApplicationName = "Testing"; Evidence evidence = new Evidence(); evidence.AddHost(new Zone(SecurityZone.Internet)); return AppDomain.CreateDomain("Test Domain", evidence, anAppDomainSetup); [2] Another option is to create it using AppDomain.CreateDomain(aName, aEvidence, anAppDomainSetup, aPermissionSet, aStrongNameArray), but I have already told here, when you try to create the engine using Python.CreateEngine(appDomain), it throws an Serialization exception of the Microsoft.Scripting. [3] I have also added the StrongName of the assembly to de Evidence using: evidence.AddHost(CreateStrongName(Assembly.GetAssembly(typeof(TestingAssembly.FileFactory)))); but it doesn't work. [4] I have subclassified my class FileFactory with MarshalByRefObject class, then I have created another appDomain with all the permissions. Then I create an instance of this class FileFactory using: FileFactory aFileFactory = (FileFactory)appDomain.CreateInstanceAndUnwrap("TestingAssembly", "TestingAssembly.FileFactory") and finally, I have set o the scope the variable aFileFactory scope.SetVariable("aFileFactory", aFileFactory); but when I try to create or delete a file previously created, it doesn't work. [5] I had to add the attribute to the assembly to allow Partially Trusted Callers [assembly: AllowPartiallyTrustedCallers] and the code is executed, but the AppDomain where the script is execute applies its security policy without taking into account the AppDomain where the object have been instantiated. [6] Here is an example of a test that probably will clarify what I am trying to do. AppDomain appDomain = TestSupportMethods.CreateFullTrustSandboxedAppDomain(); FileFactory aFileFactory = (FileFactory)appDomain.CreateInstanceAndUnwrap("TestingAssembly", TestingAssembly.FileFactory"); // Here the file is created and then deleted, so it means that the FullTrustSandboxed allows to create files. aFileFactory.createFile(); aFileFactory.deleteFile(); string pythonCode = @"aFileFactory.createFile()"; ScriptEngine engine = Python.CreateEngine(TestSupportMethods.CreateSafeSandboxedAppDomainWithEvidence()); ScriptSource source = engine.CreateScriptSourceFromString(pythonCode); ScriptScope scope = engine.CreateScope(); scope.SetVariable("aFileFactory", aFileFactory); source.Execute(scope); It throws... System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.. Well, sorry about the size of the email. Please let me know if you have new ideas, I will do my best to test them. Regards, Nicolas On Mon, Nov 9, 2009 at 7:44 PM, Dino Viehland > wrote: Couple of options spring to mind: 1. Setup evidence such that your assembly is given full trust. I believe you had the start of this in your other code where you were adding some strong name evidence. You should be able to search the web for normal .NET partial trust scenarios for getting this right. 2. Setup your object model so that it is a MarshalByRefObject which lives in another app domain. You can then expose the remote object to the partial trust app domain via SetVariable. As far as including the DLL - you can call LoadAssembly on the ScriptRuntime and give it your assembly. Then the user can import all of the types from your DLL as they need them. That won't work w/ #2 though. Alternately you can implement IAttributesCollection (or use a dynamic object in 2.6 although IAC is still supported) and create a scope w/ that as the backing storage. Then you'll be able to lazily resolve the members rather than eagerly populating them - although you still need some code to lazily resolve them. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Nicol?s Buttarelli Sent: Monday, November 09, 2009 7:49 AM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application Hi all again, I am still working with the same problem. Now I am creating the appDomain in this way by recommendation of Dino: public static AppDomain CreateSandboxAppDomain() { AppDomainSetup anAppDomainSetup = new AppDomainSetup(); anAppDomainSetup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory; anAppDomainSetup.ApplicationName = "Testing"; Evidence evidence = new Evidence(); evidence.AddHost(new Zone(SecurityZone.Internet)); AppDomain aSandboxedDomain = AppDomain.CreateDomain("Test Domain", evidence, anAppDomainSetup); return aSandboxedDomain; } Now it is working but I have security restrictions over some .dll that I want to have full trusted permissions. I am trying to do this: string aPythonScript = @"aDocument = CDLDocument() aFigure = TextBlock(1, 'type 1') anotherFigure = TextBlock(2, 'type 2') aDocument.AddFigure(aFigure) aDocument.AddFigure(anotherFigure) aList = aDocument.Figures "; ScriptSource source = engine.CreateScriptSourceFromString(aPythonScript); ScriptScope scope = engine.CreateScope(); scope.SetVariable("CDLDocument", typeof(CDLDocument)); scope.SetVariable("TextBlock", typeof(TextBlock)); source.Execute(scope); This is throwing the System.Security.SecurityException. 1. How can I give full trusted to a specific dll in an AppDomain? 2. How can I include a .dll to the scope instead of do a SetVariable for each type which I have to manage from the python script? Thanks! Nicol?s 2009/11/6 Nicol?s Buttarelli > Hi, On Fri, Nov 6, 2009 at 1:07 AM, Dino Viehland > wrote: So you've run this as a standalone program and it's failing? In the standalone app are all of the IronPython and DLR DLLs present (IronPython.dll, IronPython.modules.dll, Microsoft.Scripting.Core.dll, Microsoft.Scripting.dll, Microsoft.Dynamic.dll and Micrsoft.Scripting.Extensionattribute.dll)? Yes I have all this dlls present. A slightly modified version of this, dropping the strong name, works just fine for me: using System; using Microsoft.Scripting; using Microsoft.Scripting.Hosting; using IronPython.Hosting; using System.Security; using System.Security.Permissions; class Test { public static void Main(string[] args) { PermissionSet aRestrictedPermissionSet = new PermissionSet(PermissionState.None); aRestrictedPermissionSet.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution)); AppDomainSetup domaininfo = new AppDomainSetup(); domaininfo.ApplicationBase = System.Environment.CurrentDirectory; AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed Domain", AppDomain.CurrentDomain.Evidence, domaininfo, aRestrictedPermissionSet); ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); ScriptSource source = engine.CreateScriptSourceFromString("2+2"); ScriptScope scope = engine.CreateScope(); Console.WriteLine(source.Execute(scope)); } } Great, I will try this after university. Thanks! Compile with: csc test.cs /r:Microsoft.Scripting.Core.dll /r:Microsoft.Scripting.dll /r:IronPython.dll And run and it prints 4. Does that not work for you? We also have a different way we do this in our test suite which also works: AppDomainSetup info = new AppDomainSetup(); info.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory; info.ApplicationName = "Test"; Evidence evidence = new Evidence(); evidence.AddHost(new Zone(SecurityZone.Internet)); AppDomain newDomain = AppDomain.CreateDomain("test", evidence, info); // create runtime in partial trust... ScriptRuntime runtime = Python.CreateRuntime(newDomain); // get the Python engine... ScriptEngine engine = runtime.GetEngine("py"); This make sense too, I will try it. Thanks again. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Nicol?s Buttarelli Sent: Thursday, November 05, 2009 11:18 AM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application Again, thanks everyone for your help. But.. I bring bad news. This is still not working and it doesn't depend on the Test environment. I create another proyect, a Form project, with one button which executes the following code: // Creating the permission set to grant other assemblies PermissionSet aRestrictedPermissionSet = new PermissionSet(PermissionState.None); aRestrictedPermissionSet.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution)); AppDomainSetup domaininfo = new AppDomainSetup(); domaininfo.ApplicationBase = System.Environment.CurrentDirectory; List strongNameList = new List(); strongNameList.Add(CreateStrongName(Assembly.GetExecutingAssembly())); AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed Domain", AppDomain.CurrentDomain.Evidence, domaininfo, aRestrictedPermissionSet, strongNameList.ToArray()); ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); ScriptSource source = engine.CreateScriptSourceFromString(pythonScript); ScriptScope scope = engine.CreateScope(); source.Execute(scope); It throws this error: Type is not resolved for member 'Microsoft.Scripting.Hosting.ScriptRuntimeSetup,Microsoft.Scripting, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. I used the fuslogvw application to see if the Microsoft.Scripting is loaded, an it is. What seems strange for me is that anyone has tried this before. I hope to find some more help here. Regards, Nicolas On Wed, Nov 4, 2009 at 7:36 PM, Shri Borde > wrote: http://www.dev102.com/2008/03/22/3-ways-to-run-nunit-from-visual-studio/ has some info about test projects and appbase problems. You can also use fuslogvw (http://msdn.microsoft.com/en-us/library/e74a18c4(VS.71).aspx) to see why Microsoft.Scripting.dll is failing to load. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, November 03, 2009 1:52 PM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application Test projects are weird and somehow you don't end up inheriting the application base. This seems to work though: AppDomainSetup setup = new AppDomainSetup(); setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory; AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed Domain", null, setup); ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); ScriptSource source = engine.CreateScriptSourceFromString("2+2"); ScriptScope scope = engine.CreateScope(); Console.WriteLine(source.Execute(scope)); From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Nicol?s Buttarelli Sent: Tuesday, November 03, 2009 1:30 PM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application I have create a new "Test Project" and an Unit Test class in order to test the following code inside: AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed Domain"); ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); ScriptSource source = engine.CreateScriptSourceFromString(pythonScript); ScriptScope scope = engine.CreateScope(); source.Execute(scope); I have add the references: - IronPython - Microsoft.Scripting - Microsoft.ScriptingCore But it still not working and throwing the same System.Runtime.Serialization.SerializationException: Type is not resolved for member 'Microsoft.Scripting.Hosting.ScriptRuntimeSetup,Microsoft.Scripting. Any ideas? 2009/11/3 Nicol?s Buttarelli > Thanks Shri, I will try. In addition, I found this open issue: http://dlr.codeplex.com/WorkItem/View.aspx?WorkItemId=2816. I think that it is related. On Tue, Nov 3, 2009 at 9:29 PM, Shri Borde > wrote: I think this happens if the new appdomain cannot load the required assembly. By default, the new appdomain should inherit its BaseDirectory property from the creating domain and should be able to load Microsoft.Scripting.dll. Is your exe and all the dlls in the same folder? If not, can you try to put all assemblies in the same folder (or in the GAC) to see if it works? If that works, you can then figure out how to configure the new appdomain such that it can load Microsoft.Scripting.dll. There may be some setting in AppDomainSetup, or you could hook the AssemblyResolve event... From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Nicol?s Buttarelli Sent: Tuesday, November 03, 2009 12:08 PM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application Hi again, thanks for your clear response. I was trying to do what you proposed but it is not working. I am receiving an exception: Test method CadworX3WCFRestTest.IronPython.SafeScriptExecutionTest.writingAFileTest threw exception: System.Runtime.Serialization.SerializationException: Type is not resolved for member 'Microsoft.Scripting.Hosting.ScriptRuntimeSetup,Microsoft.Scripting, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.. I tried to find a solution but I couldn't. This is the minimal code that I am running to get this exception (I have removed all the security stuff but apparently that does not resolve the problem): AppDomain aSandboxedDomain = AppDomain.CreateDomain("Sandboxed Domain"); ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); ScriptSource source = engine.CreateScriptSourceFromString(pythonScript); SriptScope scope = engine.CreateScope(); source.Execute(scope); The exception is thronged in this line: ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); Do you have any idea which could be the problem? Thanks again, Nicolas On Mon, Nov 2, 2009 at 10:25 PM, Dino Viehland > wrote: Assuming the app domain is setup properly then there's no way for the Python code to elevate permissions (modulo CLR security bugs which are few and far between). This is because IronPython its self is 100% security transparent and does not affect any security decisions or assert any form of trust - so it's all up to the CLR to limit permissions. So for example while you can access the file object, or import ctypes, or call various other Python APIs which would require trust you'll get a security exception from the CLR when you don't have permissions to do something. For more complex scenarios you might also have an object model which you expose to the application and inject in via its scope. Once you've done that you'll want to make sure that the object model is also secure. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Nicol?s Buttarelli Sent: Monday, November 02, 2009 1:20 PM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application Thanks for your response. But what happens with the python code? Does not exist a way to write some scripts that can do some damage to my app, the server, the database, etc? Thanks again, Nicolas On Mon, Nov 2, 2009 at 9:41 PM, Dino Viehland > wrote: After creating your app domain you can do: ScriptEngine engine = Python.CreateEngine(someAppDomain); And then the rest of your code should work as it's written. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Nicol?s Buttarelli Sent: Monday, November 02, 2009 12:39 PM To: users at lists.ironpython.com Subject: [IronPython] Safe execution of python scripts on my .net application Sorry, I don't know if my previous message have arrived. So, here it is: Hello all, I am starting with python and I would like to add to my web application some web services. This services will allow the different clients of my application to execute some python scripts. I would like to know if someone did this before and how can I do this in a secure way. I mean, how can I do to restrict the environment where the scripts will be executed. In .net I can do this using the AppDoman and setting the permission set. AppDomain.CreateDomain( string friendlyName, Evidence securityInfo, AppDomainSetup info, PermissionSet grantSet, params StrongName[] fullTrustAssemblies); Is there a way to do the same with my python scripts? I am running them using this: ScriptEngine engine = Python.CreateEngine(); ScriptSource source = engine.CreateScriptSourceFromString(scriptAsString); ScriptScope scope = engine.CreateScope(); source.Execute(scope); Thanks in advance. Nicolas _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From leculver at microsoft.com Wed Dec 2 02:06:27 2009 From: leculver at microsoft.com (Lee Culver) Date: Wed, 2 Dec 2009 01:06:27 +0000 Subject: [IronPython] Is it possible to get the DLR's AST when it fails to parse? In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04D28642@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <583F11613AC4F044B32175D273E48C90225DA38B@TK5EX14MBXC112.redmond.corp.microsoft.com> <4B15AF9C.6000808@voidspace.org.uk> <1A472770E042064698CB5ADC83A12ACD04D28642@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <583F11613AC4F044B32175D273E48C90225DA496@TK5EX14MBXC112.redmond.corp.microsoft.com> Thanks Dino. This (very) rough draft worked perfectly: class Program { static void Main(string[] args) { string cmd = "if one.two.three.four."; ScriptEngine engine = Python.CreateEngine(); ScriptScope scope = engine.CreateScope(); ScriptSource source = engine.CreateScriptSourceFromString(cmd, SourceCodeKind.InteractiveCode); SourceUnit unit = HostingHelpers.GetSourceUnit(source); Parser p = Parser.CreateParser( new CompilerContext(unit, new PythonCompilerOptions(), ErrorSink.Null), new PythonOptions() ); PythonAst ast = p.ParseFile(false); Walker w = new Walker(cmd.Length); ast.Walk(w); Stack members = w.GetResult(); while (members.Count != 0) Console.WriteLine(members.Pop()); } } public class Walker : PythonWalker { int mIndex; Stack mResult = null; public Walker(int index) { mIndex = index; } public Stack GetResult() { return mResult; } public override bool Walk(MemberExpression node) { if (mIndex == node.Span.End.Index) { mResult = new Stack(); MemberExpression curr = node; while (curr.Target is MemberExpression) { curr = (MemberExpression)curr.Target; mResult.Push(curr.Name.ToString()); } if (curr.Target is NameExpression) mResult.Push(((NameExpression)curr.Target).Name.ToString()); return false; } return true; } } -Lee -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, December 01, 2009 4:15 PM To: Discussion of IronPython Subject: Re: [IronPython] Is it possible to get the DLR's AST when it fails to parse? Tokenization would save some work but he could also just use the IronPython parser. It's unfortunately a small pain to create (it's overly tied to the DLR APIs right now) but it's: return Parser.CreateParser( new CompilerContext(sourceUnit, new PythonCompilerOptions(), ErrorSink.Null), new PythonOptions() ); And to get that SourceUnit you can do HostingHelpers.GetSourceUnit on the ScriptSource. The resulting parsed expression will include ErrorExpression's where we encounter invalid code. You may also find that things like class and function definitions can be missing their names if you are parsing incomplete code like "def ". Then you'll be working on the IronPython AST instead of the DLR AST (but the two will be the same likely in IronPython 2.6.1 - the ASTs are now reducible DLR ASTs). > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Tuesday, December 01, 2009 4:07 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Is it possible to get the DLR's AST when it fails to > parse? > > No time for a longer reply, but you probably want to tokenize rather > than parse. > > Michael > > Lee Culver wrote: > > > > I have been playing with an implementation of a simple GUI console for > > IronPython (similar to IDLE, without it's text-editor IDE). I've > > mostly brought it up to rough feature parity with IDLE, but I'd like > > to add a rudimentary itellisense such that when you type something on > > the order of "foo.", the interpreter can pop up a menu containing the > > contents of foo (assuming it's something already defined in the local > > scope). However, I'd really rather not get in the business of parsing > > Python code. (That's what the DLR is for!) > > > > Is there any way I can use DLR to give me the AST up to the point at > > which it failed to parse so that I can walk that and see if we are in > > a valid place to look up the fields of an object? I looked at using > > the ErrorListener class with ScriptSource.Compile, but it only gives > > me "unexpected found" at the point where the "." is...which I > > already knew. > > > > Basically, whenever the user presses the "." key in the console what I > > would like to do is roughly this code: > > > > ScriptEngine engine = Python.CreateEngine(); > > > > ScriptScope scope = engine.CreateScope(); > > > > ScriptSource source = engine.CreateScriptSourceFromString("if foo.", > > Microsoft.Scripting.SourceCodeKind.InteractiveCode); > > > > source.Compile(); // <-- This *should* fail. I want the AST when it does. > > > > Primarily, I'm trying to find chains of identifiers to walk so that I > > can display the Nth identifier's fields: > > > > identifier1 . identifier2 . identifier3 . ... > > > > I need to distinguish this from things like this, because there's > > nothing you can reasonably do to have intellisense in this case: > > > > Function(args) . identifier1 . identifier2 > > > > (Yes, I realize that walking this chain can execute code and have side > > effects, I'm willing to live with that for my purposes.) Is there any > > mechanism through which I can have the DLR parse this for me and give > > me the resulting AST that I can walk so I can see if we can pop up an > > intellisense-like view? > > > > Can anyone recommend a better way to do this outside of simply writing > > my own mini-parser? > > > > Thanks, > > > > -Lee Culver > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > 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 jeffrey at extremeoptimization.com Wed Dec 2 02:26:44 2009 From: jeffrey at extremeoptimization.com (Jeffrey Sax) Date: Tue, 1 Dec 2009 20:26:44 -0500 Subject: [IronPython] Magic methods on CLR types Message-ID: <017901ca72ee$86170940$92451bc0$@com> Is there a way to add magic methods like __repr__, __call__, etc. to CLR types? 1. Can it be done in the external CLR assembly without polluting the API for other languages? If so, how? 2. Can it be done using F# style type augmentations by redefining such methods on the Python type corresponding to the CLR type? If so, how? 3. If neither of these alternatives is possible, is there a third way? Thanks! Jeffrey Sax -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed Dec 2 02:57:23 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 2 Dec 2009 01:57:23 +0000 Subject: [IronPython] Magic methods on CLR types In-Reply-To: <017901ca72ee$86170940$92451bc0$@com> References: <017901ca72ee$86170940$92451bc0$@com> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D28DCD@TK5EX14MBXC118.redmond.corp.microsoft.com> If you want IronPython to recognize them you just need to create an assembly w/ ExtensionTypeAttribute and have it point at the extended and extending types. Then the assembly needs to be loaded into the ScriptRuntime using ScriptRuntime.LoadAssembly. We still need to figure out our story for recognizing and importing normal .NET extension methods that C# supports. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Tuesday, December 01, 2009 5:27 PM To: 'Discussion of IronPython' Subject: [IronPython] Magic methods on CLR types Is there a way to add magic methods like __repr__, __call__, etc. to CLR types? 1. Can it be done in the external CLR assembly without polluting the API for other languages? If so, how? 2. Can it be done using F# style type augmentations by redefining such methods on the Python type corresponding to the CLR type? If so, how? 3. If neither of these alternatives is possible, is there a third way? Thanks! Jeffrey Sax -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Wed Dec 2 17:52:43 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Wed, 2 Dec 2009 08:52:43 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/61957. ADDED SOURCES $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/GetParentContextFromFunctionExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/GetGlobalContextExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DynamicGetMemberExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DynamicConvertExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/LazyDynamicExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/PythonConstantExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.Generated.cs MODIFIED SOURCES $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/GetParentContextFromFunctionExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/GetGlobalContextExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DynamicGetMemberExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DynamicConvertExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/LazyDynamicExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/PythonConstantExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/AstMethods.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/PythonAst.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/NameExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/MemberExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/IndexExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/IfStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/FunctionDefinition.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ForStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DictionaryExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ClassDefinition.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/CallExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/BinaryExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/UncollectableCompilationMode.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/ClosureExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonBinaryOperationBinder.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/WithStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/WhileStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/UnaryExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ScopeStatement.cs $/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj $/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.Generated.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.Generated.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Generation/ToDiskRewriter.cs $/IronPython/IronPython_Main/Src/Scripts/generate_calls.py CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1296901 Date: 12/1/2009 10:45:16 AM Improves performance of code which is purely interpreted. Also has some small benefits for startup perf. The interpreter perf improvements mostly come out of not using our optimized call sites which perform really badly in the interpreter. The reason they perform so badly is that we spend a lot of time accessing fields which is very very slow compared to doing it when compiled. So instead we have some intermediate expressions which lazily create dynamic sites and hold onto them directly. I?ve also added an instruction provider which gets our code context which just gets the optimized value. I?ve also gone ahead and moved hot methods into IInstructionProvider implementations. So now for hot methods like getting our code context from a function object this will run faster. I?ve also implemented some more fast bindings ? most of these are for more binary operations, but I?ve also added a few for calls which are hot. The end result of this is running interpreted (-X:CompilationThreshold 999999) our Pystones go from 18080.8 to 54864.4 (200% improvement). Big imports (no ngen) goes from 5.44 seconds to 5.16. Big imports (ngen) goes from 3.11 seconds to 2.69. Working set goes from to 64,088k to 60,164k. This seems to all be a saving in shared pages (private working set is effectively unchanged). (Shelveset: InterpreterPerfAndStartup2;REDMOND\dinov | SNAP CheckinId: 9955) From jeffrey at extremeoptimization.com Thu Dec 3 00:13:54 2009 From: jeffrey at extremeoptimization.com (Jeffrey Sax) Date: Wed, 2 Dec 2009 18:13:54 -0500 Subject: [IronPython] Magic methods on CLR types In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04D28DCD@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <017901ca72ee$86170940$92451bc0$@com> <1A472770E042064698CB5ADC83A12ACD04D28DCD@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <001101ca73a5$1f7882b0$5e698810$@com> That works, even for generic types! Thank you. I did notice that __repr__ (and possibly others) is not picked up unless I add ExtensionType attributes for each public subtype of a base type that I'm extending. My guess is that IronPython already supplies a default implementation for these, so there is no need to look up in the hierarchy. This is understandable but somewhat unexpected. Is there a way to assign Python-friendly names to CLR types by extension? I.e. get the same effect as if a PythonTypeAttribute was applied to the original class? Thanks, Jeffrey From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, December 01, 2009 8:57 PM To: Discussion of IronPython Subject: Re: [IronPython] Magic methods on CLR types If you want IronPython to recognize them you just need to create an assembly w/ ExtensionTypeAttribute and have it point at the extended and extending types. Then the assembly needs to be loaded into the ScriptRuntime using ScriptRuntime.LoadAssembly. We still need to figure out our story for recognizing and importing normal .NET extension methods that C# supports. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Tuesday, December 01, 2009 5:27 PM To: 'Discussion of IronPython' Subject: [IronPython] Magic methods on CLR types Is there a way to add magic methods like __repr__, __call__, etc. to CLR types? 1. Can it be done in the external CLR assembly without polluting the API for other languages? If so, how? 2. Can it be done using F# style type augmentations by redefining such methods on the Python type corresponding to the CLR type? If so, how? 3. If neither of these alternatives is possible, is there a third way? Thanks! Jeffrey Sax -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Dec 3 00:26:29 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 2 Dec 2009 23:26:29 +0000 Subject: [IronPython] Magic methods on CLR types In-Reply-To: <001101ca73a5$1f7882b0$5e698810$@com> References: <017901ca72ee$86170940$92451bc0$@com> <1A472770E042064698CB5ADC83A12ACD04D28DCD@TK5EX14MBXC118.redmond.corp.microsoft.com> <001101ca73a5$1f7882b0$5e698810$@com> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D320A9@TK5EX14MBXC118.redmond.corp.microsoft.com> The reason we don't pick up your __repr__ is we don't expect it to be defined on types which aren't marked w/ PythonTypeAttribute. Therefore we go w/ our default implementation. If you put [PythonType] on it we'll pick it up though. There's 6 other methods which are a little magical like this where we do something special before going to reflection (__str__, __new__, __repr__, __hash__, __iter__, and __reduce_ex__). Ideally we should probably hit reflection first or make the early resolution something we internally opt-in to. There's no extensible way to change the type names by extension currently - we just have a hard coded table for the 15 types we rename right now. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Wednesday, December 02, 2009 3:14 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] Magic methods on CLR types That works, even for generic types! Thank you. I did notice that __repr__ (and possibly others) is not picked up unless I add ExtensionType attributes for each public subtype of a base type that I'm extending. My guess is that IronPython already supplies a default implementation for these, so there is no need to look up in the hierarchy. This is understandable but somewhat unexpected. Is there a way to assign Python-friendly names to CLR types by extension? I.e. get the same effect as if a PythonTypeAttribute was applied to the original class? Thanks, Jeffrey From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, December 01, 2009 8:57 PM To: Discussion of IronPython Subject: Re: [IronPython] Magic methods on CLR types If you want IronPython to recognize them you just need to create an assembly w/ ExtensionTypeAttribute and have it point at the extended and extending types. Then the assembly needs to be loaded into the ScriptRuntime using ScriptRuntime.LoadAssembly. We still need to figure out our story for recognizing and importing normal .NET extension methods that C# supports. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Tuesday, December 01, 2009 5:27 PM To: 'Discussion of IronPython' Subject: [IronPython] Magic methods on CLR types Is there a way to add magic methods like __repr__, __call__, etc. to CLR types? 1. Can it be done in the external CLR assembly without polluting the API for other languages? If so, how? 2. Can it be done using F# style type augmentations by redefining such methods on the Python type corresponding to the CLR type? If so, how? 3. If neither of these alternatives is possible, is there a third way? Thanks! Jeffrey Sax -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey at extremeoptimization.com Thu Dec 3 02:38:57 2009 From: jeffrey at extremeoptimization.com (Jeffrey Sax) Date: Wed, 2 Dec 2009 20:38:57 -0500 Subject: [IronPython] Magic methods on CLR types In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04D28DCD@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <017901ca72ee$86170940$92451bc0$@com> <1A472770E042064698CB5ADC83A12ACD04D28DCD@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <002701ca73b9$62f974e0$28ec5ea0$@com> I found 2 issues: 1. It looks like __index__ is not called for slice arguments of non-Python objects (like List's). Reading PEP 357 (which introduced __index__), I would expect __index__ to always be called, so that I can be sure that the slice components are either int, long, or NULL. (I haven't verified this in CPython.) 2. If I supply a __getitem__ method in my extension type (in my case with a strongly typed ISlice parameter), the underlying CLR indexers are no longer picked up. Extender assembly: [assembly: ExtensionType(typeof(List<>), typeof(ListExtensions<>))] namespace Compatibility.Python { public static class ListExtensions { public static T __getitem__(List a, ISlice slice) { return a[(int)slice.Start]; // Dummy } } } IP session 1: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> from System.Collections.Generic import List >>> a=List[int]() >>> a.Add(55) >>> a[0] 55 >>> a[0:1.2] 55 >>> b=[1,2,3,4] >>> b[0:1.2] Traceback (most recent call last): File "", line 1, in TypeError: expected index value, got float >>> IP session 2: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> import clr >>> clr.AddReferenceToFile("Compatibility.Python") >>> from System.Collections.Generic import List >>> a=List[int]() >>> a.Add(55) >>> a[0] Traceback (most recent call last): File "", line 1, in TypeError: expected ISlice, got int >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, December 01, 2009 8:57 PM To: Discussion of IronPython Subject: Re: [IronPython] Magic methods on CLR types If you want IronPython to recognize them you just need to create an assembly w/ ExtensionTypeAttribute and have it point at the extended and extending types. Then the assembly needs to be loaded into the ScriptRuntime using ScriptRuntime.LoadAssembly. We still need to figure out our story for recognizing and importing normal .NET extension methods that C# supports. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Tuesday, December 01, 2009 5:27 PM To: 'Discussion of IronPython' Subject: [IronPython] Magic methods on CLR types Is there a way to add magic methods like __repr__, __call__, etc. to CLR types? 1. Can it be done in the external CLR assembly without polluting the API for other languages? If so, how? 2. Can it be done using F# style type augmentations by redefining such methods on the Python type corresponding to the CLR type? If so, how? 3. If neither of these alternatives is possible, is there a third way? Thanks! Jeffrey Sax -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Dec 3 04:02:06 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 3 Dec 2009 03:02:06 +0000 Subject: [IronPython] Magic methods on CLR types In-Reply-To: <002701ca73b9$62f974e0$28ec5ea0$@com> References: <017901ca72ee$86170940$92451bc0$@com> <1A472770E042064698CB5ADC83A12ACD04D28DCD@TK5EX14MBXC118.redmond.corp.microsoft.com> <002701ca73b9$62f974e0$28ec5ea0$@com> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D336A5@TK5EX14MBXC118.redmond.corp.microsoft.com> #1 is definitely correct behavior, consider: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> class c(object): ... def __getitem__(self, index): ... return index ... >>> c()[0:1.2] slice(0, 1.2, None) It's Python's list implementation which is converting indexes to integers so you'll need to do that as well. You can do that via IronPython.Runtime.Converter.ConvertToIndex though. On #2 in theory we don't let you override existing members w/ extension members. But __getitem__ is taking precedence here because we pick up the List version later in resolution via a .NET mapping than looking up members by name. But you can define the integer overload for __getitem__ and forward it to the real implementation. We could also consider just adding slicing support for List to IronPython natively :) We probably can't do that for all IList's though in case there's one that accepts negative or out of range indexes. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Wednesday, December 02, 2009 5:39 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] Magic methods on CLR types I found 2 issues: 1. It looks like __index__ is not called for slice arguments of non-Python objects (like List's). Reading PEP 357 (which introduced __index__), I would expect __index__ to always be called, so that I can be sure that the slice components are either int, long, or NULL. (I haven't verified this in CPython.) 2. If I supply a __getitem__ method in my extension type (in my case with a strongly typed ISlice parameter), the underlying CLR indexers are no longer picked up. Extender assembly: [assembly: ExtensionType(typeof(List<>), typeof(ListExtensions<>))] namespace Compatibility.Python { public static class ListExtensions { public static T __getitem__(List a, ISlice slice) { return a[(int)slice.Start]; // Dummy } } } IP session 1: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> from System.Collections.Generic import List >>> a=List[int]() >>> a.Add(55) >>> a[0] 55 >>> a[0:1.2] 55 >>> b=[1,2,3,4] >>> b[0:1.2] Traceback (most recent call last): File "", line 1, in TypeError: expected index value, got float >>> IP session 2: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> import clr >>> clr.AddReferenceToFile("Compatibility.Python") >>> from System.Collections.Generic import List >>> a=List[int]() >>> a.Add(55) >>> a[0] Traceback (most recent call last): File "", line 1, in TypeError: expected ISlice, got int >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, December 01, 2009 8:57 PM To: Discussion of IronPython Subject: Re: [IronPython] Magic methods on CLR types If you want IronPython to recognize them you just need to create an assembly w/ ExtensionTypeAttribute and have it point at the extended and extending types. Then the assembly needs to be loaded into the ScriptRuntime using ScriptRuntime.LoadAssembly. We still need to figure out our story for recognizing and importing normal .NET extension methods that C# supports. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Tuesday, December 01, 2009 5:27 PM To: 'Discussion of IronPython' Subject: [IronPython] Magic methods on CLR types Is there a way to add magic methods like __repr__, __call__, etc. to CLR types? 1. Can it be done in the external CLR assembly without polluting the API for other languages? If so, how? 2. Can it be done using F# style type augmentations by redefining such methods on the Python type corresponding to the CLR type? If so, how? 3. If neither of these alternatives is possible, is there a third way? Thanks! Jeffrey Sax -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey at extremeoptimization.com Thu Dec 3 06:19:13 2009 From: jeffrey at extremeoptimization.com (Jeffrey Sax) Date: Thu, 3 Dec 2009 00:19:13 -0500 Subject: [IronPython] Magic methods on CLR types In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04D336A5@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <017901ca72ee$86170940$92451bc0$@com> <1A472770E042064698CB5ADC83A12ACD04D28DCD@TK5EX14MBXC118.redmond.corp.microsoft.com> <002701ca73b9$62f974e0$28ec5ea0$@com> <1A472770E042064698CB5ADC83A12ACD04D336A5@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <005101ca73d8$27b53e40$771fbac0$@com> #1: Ok. And I just found Converter.ConvertToIndex so it's easy enough to do. Great! Thanks. #2: I think something else is going on. An extension type should not remove functionality, which is what is happening here. Consider this: [assembly: ExtensionType(typeof(Sliceable), typeof(SliceableExtensions))] namespace Compatibility.Python { public class Sliceable { public int this[int index] { get { return index; } } } public static class SliceableExtensions { public static ISlice __getitem__(Sliceable a, ISlice b) { return b; } } } IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> import clr >>> clr.AddReferenceToFile("Compatibility.Python") >>> from Compatibility.Python import * >>> s = Sliceable() >>> s[1] Traceback (most recent call last): File "", line 1, in TypeError: expected ISlice, got int >>> s.Item[2] 2 >>> s.Item[10] 10 There is no IList or anything enumerable, just the indexer method. And it's basically hidden by the __getitem__ in the extension type. Item still works, because that's a direct reflection of the CLR type. Adding an extension type to enable standard Python functionality like slicing for CLR objects seems like a common scenario that, IMHO, should be properly supported, eventually. F# has something similar with type augmentations. Yes, I can just create pass-through methods, but in my view that shouldn't be necessary. (In F#, it isn't, but then there are other limitations.) Thanks, Jeffrey From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, December 02, 2009 10:02 PM To: Discussion of IronPython Subject: Re: [IronPython] Magic methods on CLR types #1 is definitely correct behavior, consider: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> class c(object): ... def __getitem__(self, index): ... return index ... >>> c()[0:1.2] slice(0, 1.2, None) It's Python's list implementation which is converting indexes to integers so you'll need to do that as well. You can do that via IronPython.Runtime.Converter.ConvertToIndex though. On #2 in theory we don't let you override existing members w/ extension members. But __getitem__ is taking precedence here because we pick up the List version later in resolution via a .NET mapping than looking up members by name. But you can define the integer overload for __getitem__ and forward it to the real implementation. We could also consider just adding slicing support for List to IronPython natively J We probably can't do that for all IList's though in case there's one that accepts negative or out of range indexes. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Wednesday, December 02, 2009 5:39 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] Magic methods on CLR types I found 2 issues: 1. It looks like __index__ is not called for slice arguments of non-Python objects (like List's). Reading PEP 357 (which introduced __index__), I would expect __index__ to always be called, so that I can be sure that the slice components are either int, long, or NULL. (I haven't verified this in CPython.) 2. If I supply a __getitem__ method in my extension type (in my case with a strongly typed ISlice parameter), the underlying CLR indexers are no longer picked up. Extender assembly: [assembly: ExtensionType(typeof(List<>), typeof(ListExtensions<>))] namespace Compatibility.Python { public static class ListExtensions { public static T __getitem__(List a, ISlice slice) { return a[(int)slice.Start]; // Dummy } } } IP session 1: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> from System.Collections.Generic import List >>> a=List[int]() >>> a.Add(55) >>> a[0] 55 >>> a[0:1.2] 55 >>> b=[1,2,3,4] >>> b[0:1.2] Traceback (most recent call last): File "", line 1, in TypeError: expected index value, got float >>> IP session 2: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> import clr >>> clr.AddReferenceToFile("Compatibility.Python") >>> from System.Collections.Generic import List >>> a=List[int]() >>> a.Add(55) >>> a[0] Traceback (most recent call last): File "", line 1, in TypeError: expected ISlice, got int >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, December 01, 2009 8:57 PM To: Discussion of IronPython Subject: Re: [IronPython] Magic methods on CLR types If you want IronPython to recognize them you just need to create an assembly w/ ExtensionTypeAttribute and have it point at the extended and extending types. Then the assembly needs to be loaded into the ScriptRuntime using ScriptRuntime.LoadAssembly. We still need to figure out our story for recognizing and importing normal .NET extension methods that C# supports. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Tuesday, December 01, 2009 5:27 PM To: 'Discussion of IronPython' Subject: [IronPython] Magic methods on CLR types Is there a way to add magic methods like __repr__, __call__, etc. to CLR types? 1. Can it be done in the external CLR assembly without polluting the API for other languages? If so, how? 2. Can it be done using F# style type augmentations by redefining such methods on the Python type corresponding to the CLR type? If so, how? 3. If neither of these alternatives is possible, is there a third way? Thanks! Jeffrey Sax -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Thu Dec 3 17:53:37 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Thu, 3 Dec 2009 08:53:37 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <37d98a9f-ed63-4a6f-a85c-852aff11caf8@tk5-exsmh-c102.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/61985. DELETED SOURCES $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/GetParentContextFromFunctionExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/GetGlobalContextExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DynamicGetMemberExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DynamicConvertExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/LazyDynamicExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/PythonConstantExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.Generated.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/BinderHelpers.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Utils/TypeExtensions.cs MODIFIED SOURCES $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/AstMethods.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/UncollectableCompilationMode.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/Calls/ParameterMapping.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/Calls/OverloadResolver.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/Calls/ParameterWrapper.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/Calls/SimpleArgBuilder.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/Calls/MethodCandidate.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/NamespaceTracker.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.Generated.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/IfStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/FunctionDefinition.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ForStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DictionaryExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ClassDefinition.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/CallExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/BinaryExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/ClosureExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonBinaryOperationBinder.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonProtocol.Operations.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/SlotOrFunction.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/BuiltinFunction.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/WithStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/WhileStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/UnaryExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ScopeStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/PythonAst.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/NameExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/MemberExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/IndexExpression.cs $/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Generation/ToDiskRewriter.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Ast/MethodCallExpression.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Microsoft.Dynamic.csproj $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Runtime/DelegateInfo.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Runtime/AssemblyTypeNames.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Generation/ILGen.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Generation/CompilerHelpers.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightCompiler.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Utils/ReflectionUtils.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Utils/TypeUtils.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Runtime/MetaObjectExtensions.cs $/IronPython/IronPython_Main/Src/Scripts/generate_calls.py $/IronPython/IronPython_Main/Src/Tests/test_methodbinder1.py From merllab at microsoft.com Fri Dec 4 17:53:00 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Fri, 4 Dec 2009 08:53:00 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <30dbfa8f-424e-46bd-bf57-4181a9b5dd87@tk5-exsmh-c102.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/62012. ADDED SOURCES $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DynamicConvertExpression.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/DivInstruction.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/LazyDynamicExpression.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Ast/Utils.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/GetGlobalContextExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DynamicGetMemberExpression.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LoopCompiler.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/PythonConstantExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.Generated.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/GetParentContextFromFunctionExpression.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LocalVariables.cs MODIFIED SOURCES $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DynamicConvertExpression.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/DivInstruction.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/LazyDynamicExpression.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Ast/Utils.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/GetGlobalContextExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DynamicGetMemberExpression.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LoopCompiler.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/PythonConstantExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.Generated.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/GetParentContextFromFunctionExpression.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LocalVariables.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/BranchLabel.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/ControlFlowInstructions.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/InstructionList.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/TypeOperations.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/AstMethods.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/UncollectableCompilationMode.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/Instruction.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/LocalAccess.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/StackOperations.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Generation/ToDiskRewriter.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Ast/UnaryExpression.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Ast/FinallyFlowControlExpression.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Ast/FlowControlRewriter.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Microsoft.Dynamic.csproj $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Utils/ThreadLocal.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Runtime/ScriptingRuntimeHelpers.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Generation/CompilerHelpers.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Interpreter.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightLambdaClosureVisitor.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightLambda.Generated.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightCompiler.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightLambda.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/InterpretedFrame.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightDelegateCreator.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.Generated.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/DebuggableLambdaBuilder.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/GeneratorRewriter.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/LazyCode.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/ClosureExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/PythonScriptCode.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/RuntimeScriptCode.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonBinaryOperationBinder.cs $/IronPython/IronPython_Main/Src/Scripts/generate_dynamic_instructions.py $/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonGetMemberBinder.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/FunctionCode.cs $/IronPython/IronPython_Main/Src/Tests/test_traceback.py $/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs $/IronPython/IronPython_Main/Src/Tests/test_memory.py $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/WithStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/WhileStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/UnaryExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/TryStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ScopeStatement.cs $/IronPython/IronPython_Main/Src/Scripts/generate_calls.py $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/PythonAst.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/NameExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/MemberExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/IndexExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/IfStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/FunctionDefinition.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ForStatement.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/DictionaryExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ClassDefinition.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/CallExpression.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/BinaryExpression.cs $/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1305533 Date: 12/3/2009 2:04:07 PM Improves performance of code which is purely interpreted. Also has some small benefits for startup perf. The interpreter perf improvements mostly come out of not using our optimized call sites which perform really badly in the interpreter. The reason they perform so badly is that we spend a lot of time accessing fields which is very very slow compared to doing it when compiled. So instead we have some intermediate expressions which lazily create dynamic sites and hold onto them directly. I?ve also added an instruction provider which gets our code context which just gets the optimized value. I?ve also gone ahead and moved hot methods into IInstructionProvider implementations. So now for hot methods like getting our code context from a function object this will run faster. I?ve also implemented some more fast bindings ? most of these are for more binary operations, but I?ve also added a few for calls which are hot. The end result of this is running interpreted (-X:CompilationThreshold 999999) our Pystones go from 18080.8 to 54864.4 (200% improvement). Big imports (no ngen) goes from 5.44 seconds to 5.16. Big imports (ngen) goes from 3.11 seconds to 2.69. Working set goes from to 64,088k to 60,164k. This seems to all be a saving in shared pages (private working set is effectively unchanged). (Shelveset: InterpreterPerfAndStartup3;REDMOND\dinov | SNAP CheckinId: 9966) From dinov at microsoft.com Fri Dec 4 19:03:53 2009 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 4 Dec 2009 18:03:53 +0000 Subject: [IronPython] Magic methods on CLR types In-Reply-To: <005101ca73d8$27b53e40$771fbac0$@com> References: <017901ca72ee$86170940$92451bc0$@com> <1A472770E042064698CB5ADC83A12ACD04D28DCD@TK5EX14MBXC118.redmond.corp.microsoft.com> <002701ca73b9$62f974e0$28ec5ea0$@com> <1A472770E042064698CB5ADC83A12ACD04D336A5@TK5EX14MBXC118.redmond.corp.microsoft.com> <005101ca73d8$27b53e40$771fbac0$@com> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D412BE@TK5EX14MBXC118.redmond.corp.microsoft.com> Yeah, I think I buy your argument on #2. We'll need to change the way we do resolution to make that happen which is a little scary - I'm inclined to say it'll have to wait until we either figure out exactly how we support normal extension methods or until IronPython 3k when we can make some breaking changes. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Wednesday, December 02, 2009 9:19 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] Magic methods on CLR types #1: Ok. And I just found Converter.ConvertToIndex so it's easy enough to do. Great! Thanks. #2: I think something else is going on. An extension type should not remove functionality, which is what is happening here. Consider this: [assembly: ExtensionType(typeof(Sliceable), typeof(SliceableExtensions))] namespace Compatibility.Python { public class Sliceable { public int this[int index] { get { return index; } } } public static class SliceableExtensions { public static ISlice __getitem__(Sliceable a, ISlice b) { return b; } } } IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> import clr >>> clr.AddReferenceToFile("Compatibility.Python") >>> from Compatibility.Python import * >>> s = Sliceable() >>> s[1] Traceback (most recent call last): File "", line 1, in TypeError: expected ISlice, got int >>> s.Item[2] 2 >>> s.Item[10] 10 There is no IList or anything enumerable, just the indexer method. And it's basically hidden by the __getitem__ in the extension type. Item still works, because that's a direct reflection of the CLR type. Adding an extension type to enable standard Python functionality like slicing for CLR objects seems like a common scenario that, IMHO, should be properly supported, eventually. F# has something similar with type augmentations. Yes, I can just create pass-through methods, but in my view that shouldn't be necessary. (In F#, it isn't, but then there are other limitations.) Thanks, Jeffrey From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, December 02, 2009 10:02 PM To: Discussion of IronPython Subject: Re: [IronPython] Magic methods on CLR types #1 is definitely correct behavior, consider: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> class c(object): ... def __getitem__(self, index): ... return index ... >>> c()[0:1.2] slice(0, 1.2, None) It's Python's list implementation which is converting indexes to integers so you'll need to do that as well. You can do that via IronPython.Runtime.Converter.ConvertToIndex though. On #2 in theory we don't let you override existing members w/ extension members. But __getitem__ is taking precedence here because we pick up the List version later in resolution via a .NET mapping than looking up members by name. But you can define the integer overload for __getitem__ and forward it to the real implementation. We could also consider just adding slicing support for List to IronPython natively :) We probably can't do that for all IList's though in case there's one that accepts negative or out of range indexes. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Wednesday, December 02, 2009 5:39 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] Magic methods on CLR types I found 2 issues: 1. It looks like __index__ is not called for slice arguments of non-Python objects (like List's). Reading PEP 357 (which introduced __index__), I would expect __index__ to always be called, so that I can be sure that the slice components are either int, long, or NULL. (I haven't verified this in CPython.) 2. If I supply a __getitem__ method in my extension type (in my case with a strongly typed ISlice parameter), the underlying CLR indexers are no longer picked up. Extender assembly: [assembly: ExtensionType(typeof(List<>), typeof(ListExtensions<>))] namespace Compatibility.Python { public static class ListExtensions { public static T __getitem__(List a, ISlice slice) { return a[(int)slice.Start]; // Dummy } } } IP session 1: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> from System.Collections.Generic import List >>> a=List[int]() >>> a.Add(55) >>> a[0] 55 >>> a[0:1.2] 55 >>> b=[1,2,3,4] >>> b[0:1.2] Traceback (most recent call last): File "", line 1, in TypeError: expected index value, got float >>> IP session 2: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type "help", "copyright", "credits" or "license" for more information. >>> import clr >>> clr.AddReferenceToFile("Compatibility.Python") >>> from System.Collections.Generic import List >>> a=List[int]() >>> a.Add(55) >>> a[0] Traceback (most recent call last): File "", line 1, in TypeError: expected ISlice, got int >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, December 01, 2009 8:57 PM To: Discussion of IronPython Subject: Re: [IronPython] Magic methods on CLR types If you want IronPython to recognize them you just need to create an assembly w/ ExtensionTypeAttribute and have it point at the extended and extending types. Then the assembly needs to be loaded into the ScriptRuntime using ScriptRuntime.LoadAssembly. We still need to figure out our story for recognizing and importing normal .NET extension methods that C# supports. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Tuesday, December 01, 2009 5:27 PM To: 'Discussion of IronPython' Subject: [IronPython] Magic methods on CLR types Is there a way to add magic methods like __repr__, __call__, etc. to CLR types? 1. Can it be done in the external CLR assembly without polluting the API for other languages? If so, how? 2. Can it be done using F# style type augmentations by redefining such methods on the Python type corresponding to the CLR type? If so, how? 3. If neither of these alternatives is possible, is there a third way? Thanks! Jeffrey Sax -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sun Dec 6 15:47:48 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 06 Dec 2009 14:47:48 +0000 Subject: [IronPython] IronPython Mailing List Inaccessible Message-ID: <4B1BC414.7030402@voidspace.org.uk> ironpython.com is redirecting to a bing search. This makes the mailing list inacessible (and breaks hundreds if not thousands of links). All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From fuzzyman at voidspace.org.uk Mon Dec 7 19:21:26 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 07 Dec 2009 18:21:26 +0000 Subject: [IronPython] ping Message-ID: <4B1D47A6.10706@voidspace.org.uk> print 'Hello world' -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From Jimmy.Schementi at microsoft.com Mon Dec 7 19:24:51 2009 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Mon, 7 Dec 2009 18:24:51 +0000 Subject: [IronPython] IronPython Mailing List Inaccessible In-Reply-To: <4B1BC414.7030402@voidspace.org.uk> References: <4B1BC414.7030402@voidspace.org.uk> Message-ID: <1B42307CD4AADD438CDDA2FE1121CC92058B5D@TK5EX14MBXC141.redmond.corp.microsoft.com> Sorry about the mailing list downtime this weekend; it was a mess-up with moving the Iron* domains to a new DNS server. ~js > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Sunday, December 06, 2009 6:48 AM > To: Discussion of IronPython > Subject: [IronPython] IronPython Mailing List Inaccessible > > ironpython.com is redirecting to a bing search. This makes the mailing list > inacessible (and breaks hundreds if not thousands of links). > > All the best, > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From Jimmy.Schementi at microsoft.com Mon Dec 7 19:05:27 2009 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Mon, 7 Dec 2009 18:05:27 +0000 Subject: [IronPython] Mailing list back to normal Message-ID: <1B42307CD4AADD438CDDA2FE1121CC92058A1F@TK5EX14MBXC141.redmond.corp.microsoft.com> Sorry for the mailing list downtime this weekend; it was a messup with moving to a new DNS server. Things appear to be back to normal. If not, feel free to directly email me, or on twitter (@jschementi). ~Jimmy From Jimmy.Schementi at microsoft.com Mon Dec 7 18:53:08 2009 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Mon, 7 Dec 2009 17:53:08 +0000 Subject: [IronPython] Mailing list downtime Message-ID: <1B42307CD4AADD438CDDA2FE1121CC920586D9@TK5EX14MBXC141.redmond.corp.microsoft.com> Sorry for the IronPython mailing list downtime this weekend; it was a mess-up with moving to a new DNS server. ~Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Mon Dec 7 17:52:56 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Mon, 7 Dec 2009 08:52:56 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/62096. MODIFIED SOURCES $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/Calls/DefaultOverloadResolver.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/ActionBinder.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/DefaultBinder.Conversions.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/DefaultBinder.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/DefaultBinder.GetMember.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/OperatorInfo.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/DefaultBinder.Operations.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/DefaultBinder.SetMember.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/DefaultBinder.Invoke.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/DefaultBinder.DeleteMember.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Microsoft.Dynamic.csproj $/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonBinder.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs $/IronPython/IronPython_Main/Src/Tests/test_memory.py CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1309042 Date: 12/4/2009 5:15:01 PM Default Binder Improvements: Decouples DefaultBinder from ScriptDomainManager. Leaves ScriptDomainManager ctors for backwards compat, moves IronPython/IronRuby to overriding PrivateBinding which is the only reason we needed the SDM Makes DefaultBinder non-abstract so that you can simply new one up if you don't need any customization Removes unused "DefaultLanguageContext.cs" file which was actually a DefaultBinder subclass Adds overloads for various default binder operations which don't take a OverloadResolverFactory - instead they use the DefaultOverloadResolverFactory. Adds DoOperation overload which takes an ExpressionType for better compat w/ the DLR binders, obsoletes string version, moves this lookup for OperatorInfo into a dictionary lookup Also starts adding some unit tests for the default binder (Shelveset: DefaultBinderImprovements;REDMOND\dinov | SNAP CheckinId: m10807) From Jimmy.Schementi at microsoft.com Mon Dec 7 18:36:04 2009 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Mon, 7 Dec 2009 17:36:04 +0000 Subject: [IronPython] Mailing list downtime Message-ID: <1B42307CD4AADD438CDDA2FE1121CC92057C26@TK5EX14MBXC141.redmond.corp.microsoft.com> Sorry for the IronPython mailing list downtime this weekend; it was a mess-up with moving to a new DNS server. ~Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jimmy.Schementi at microsoft.com Mon Dec 7 19:59:37 2009 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Mon, 7 Dec 2009 18:59:37 +0000 Subject: [IronPython] Mailing list back to normal In-Reply-To: <1B42307CD4AADD438CDDA2FE1121CC92058A1F@TK5EX14MBXC141.redmond.corp.microsoft.com> References: <1B42307CD4AADD438CDDA2FE1121CC92058A1F@TK5EX14MBXC141.redmond.corp.microsoft.com> Message-ID: <1B42307CD4AADD438CDDA2FE1121CC92058C45@TK5EX14MBXC141.redmond.corp.microsoft.com> Haha, there are all my messages =) Sorry for the continued spam, I think that's the last of it. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Jimmy Schementi > Sent: Monday, December 07, 2009 10:05 AM > To: users at lists.ironpython.com > Subject: [IronPython] Mailing list back to normal > > Sorry for the mailing list downtime this weekend; it was a messup with > moving to a new DNS server. Things appear to be back to normal. If not, feel > free to directly email me, or on twitter (@jschementi). > > ~Jimmy > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Mon Dec 7 04:38:05 2009 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Mon, 7 Dec 2009 12:38:05 +0900 Subject: [IronPython] Mail archive Message-ID: <5b0248170912061938t5a3cbb42i182402bcbbe7eb41@mail.gmail.com> Hi, I can't access the mail archive of this list. URL redirects to Bing's search result page. Is it only me? Any idea? -- Seo Sanghyeon From dinov at microsoft.com Mon Dec 7 20:46:13 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 7 Dec 2009 19:46:13 +0000 Subject: [IronPython] Mail archive In-Reply-To: <5b0248170912061938t5a3cbb42i182402bcbbe7eb41@mail.gmail.com> References: <5b0248170912061938t5a3cbb42i182402bcbbe7eb41@mail.gmail.com> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D5A23E@TK5EX14MBXC118.redmond.corp.microsoft.com> There were some issues w/ DNS over the weekend. It should be back up now but you might need to flush your DNS cache to get up to date info. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon > Sent: Sunday, December 06, 2009 7:38 PM > To: Discussion of IronPython > Subject: [IronPython] Mail archive > > Hi, I can't access the mail archive of this list. URL redirects to > Bing's search result page. Is it only me? Any idea? > > -- > Seo Sanghyeon > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From empirebuilder at gmail.com Tue Dec 8 10:38:44 2009 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 8 Dec 2009 11:38:44 +0200 Subject: [IronPython] Mailing list downtime In-Reply-To: <1B42307CD4AADD438CDDA2FE1121CC920586D9@TK5EX14MBXC141.redmond.corp.microsoft.com> References: <1B42307CD4AADD438CDDA2FE1121CC920586D9@TK5EX14MBXC141.redmond.corp.microsoft.com> Message-ID: <8cd017b80912080138n74c9bfqd7c7b536470b3532@mail.gmail.com> So you guys switching to the new Google DNS too (DARFC) :) On Mon, Dec 7, 2009 at 7:53 PM, Jimmy Schementi < Jimmy.Schementi at microsoft.com> wrote: > Sorry for the IronPython mailing list downtime this weekend; it was a > mess-up with moving to a new DNS server. > > > > ~Jimmy > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.suhotjuk at gmail.com Tue Dec 8 16:54:41 2009 From: pavel.suhotjuk at gmail.com (Suhotyuk Pavel) Date: Tue, 08 Dec 2009 17:54:41 +0200 Subject: [IronPython] Using ruby module from python. In-Reply-To: <4B151996.8000306@gmail.com> References: <4B13A06A.7040601@gmail.com> <4B342496A3EFEB48839E10BB4BF5964C1826E1FB@TK5EX14MBXC129.redmond.corp.microsoft.com> <4B151996.8000306@gmail.com> Message-ID: <4B1E76C1.8070101@gmail.com> I write some helpers for python-ruby interop. It's allowed to use ruby soap-library. It's very simple helpers. It have problem with convert python types to ruby. This helpers place at http://files.roinet.net/blog/2009-12-07/PythonRubyInterop.7z And I write some note about this problem in russian language. http://roinet.net/2009/12/08/python-ruby-interop/ From Tomas.Matousek at microsoft.com Tue Dec 8 22:10:44 2009 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Tue, 8 Dec 2009 21:10:44 +0000 Subject: [IronPython] Using ruby module from python. In-Reply-To: <4B151996.8000306@gmail.com> References: <4B13A06A.7040601@gmail.com> <4B342496A3EFEB48839E10BB4BF5964C1826E1FB@TK5EX14MBXC129.redmond.corp.microsoft.com> <4B151996.8000306@gmail.com> Message-ID: <4B342496A3EFEB48839E10BB4BF5964C182933A4@TK5EX14MBXC129.redmond.corp.microsoft.com> I have filed a bug to track these issues: http://ironruby.codeplex.com/WorkItem/View.aspx?WorkItemId=3279 Tomas -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pavel Suhotyuk Sent: Tuesday, December 01, 2009 5:27 AM To: Discussion of IronPython Subject: Re: [IronPython] Using ruby module from python. I try your example. It's really work, but have some problem with ruby objects: 1) Can't call RubyObject methods. >>> import clr >>> wsdl = clr.Use('wsdl.rb', 'rb') >>> factory = wsdl.get_factory() >>> client = factory('http://localhost/PaymentsBroker/Manager/ProviderService.asmx?WSDL').create_rpc_drive() Traceback (most recent call last): File "", line 1, in AttributeError: 'RubyObject' object has no attribute 'create_rpc_drive' >>> client = getattr(factory('http://localhost/PaymentsBroker/Manager/ProviderService.asmx?WSDL'), 'create_rpc_driver')() >>> 2) Calling methods without parameters possible. >>> client.GetProviders(None) ]> But I don't understand how call methods with parameters. In ruby I can call like this: >>> print client.GetBalance(:providerId => 3).getBalanceResult().balance 60663.89=> nil In python it's not work: >>> client.GetBalance(3) Traceback (most recent call last): File "", line 1, in SystemError: SOAP::Mapping::MappingError >>> client.GetBalance(provider=3) Traceback (most recent call last): File "", line 1, in TypeError: RubyMethod is not callable >>> getattr(client, 'GetBalance')(3) Traceback (most recent call last): File "", line 1, in SystemError: SOAP::Mapping::MappingError >>> getattr(client, 'GetBalance')(provider=3) Traceback (most recent call last): File "", line 1, in TypeError: RubyMethod is not callable >>> getattr(client, 'GetBalance')({'providerId':3}) Traceback (most recent call last): File "", line 1, in SystemError: SOAP::Mapping::MappingError >>> getattr(client, 'GetBalance')({'providerId':3}) Traceback (most recent call last): File "", line 1, in SystemError: SOAP::Mapping::MappingError >>> getattr(client, 'GetBalance')({':providerId':3}) Traceback (most recent call last): File "", line 1, in SystemError: SOAP::Mapping::MappingError Tomas Matousek wrote: > Our Python-Ruby interop is not quite done yet so you need to use some workarounds. > > The easiest way how to get WSDL factory instance would be to write a simple Ruby script that loads it: > > == wsdl.rb == > > require 'soap/wsdlDriver' > > def get_factory > SOAP::WSDLDriverFactory > end > > === > > And then you can do: >>>> import clr >>>> wsdl = clr.Use('wsdl.rb', 'rb') >>>> factory = wsdl.get_factory() >>>> print factory("x.wsdl") > Traceback (most recent call last): > File "", line 1, in > SystemError: Cannot connect to x.wsdl (Not HTTP.) > > > get_factory method is exposed on the "wsdl" module so that Python can call it. IronRuby doesn't yet implement dynamic protocols for constant access so you need the get_factory helper for accessing Ruby constants. > Also we have some work to do to make clr.Use work better with libraries of other DLR languages. > Let us know if you hit some other issues. > > Tomas > > > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pavel > Suhotyuk > Sent: Monday, November 30, 2009 2:38 AM > To: Discussion of IronPython > Subject: [IronPython] Using ruby module from python. > > Hello. > > I want try to use ruby library (soap) in python code. > I found method Use(str) in clr module for load the specified module searching all languages in the loaded ScriptRuntime, but don't understand how to used it. > > I try to call this method in any variants, but nothing happends. > > >>> import clr > >>> clr.Use('soap/wsdlDriver') > Traceback (most recent call last): > File "", line 1, in > ValueError: couldn't find module soap/wsdlDriver to use >>> clr.Use('soap.wsdlDriver') Traceback (most recent call last): > File "", line 1, in > ValueError: couldn't find module soap.wsdlDriver to use >>> clr.Use('soap/wsdlDriver.rb') Traceback (most recent call last): > File "", line 1, in > ValueError: couldn't find module soap/wsdlDriver.rb to use >>> > clr.Use(r'''C:\usr\env\IronRuby\lib\ruby\1.8\soap\wsdlDriver.rb''', > 'rb') > > >>> m = > clr.Use(r'''C:\usr\env\IronRuby\lib\ruby\1.8\soap\wsdlDriver.rb''', > 'rb') >>> m >>> dir(m) ['__builtins__'] > > > Thanks. > _______________________________________________ > 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 giles.thomas at resolversystems.com Wed Dec 9 13:54:11 2009 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Wed, 09 Dec 2009 12:54:11 +0000 Subject: [IronPython] London Financial Python Users Group Message-ID: <4B1F9DF3.5000204@resolversystems.com> Hi all, If you're based in or visiting London, and have an interest in using (Iron)Python for financial software, you might want to come to the next meeting of the London Financial Python Users Group! The time: Monday 14 December 2009 at 7pm The place: MWB Regent Street, Liberty House 222 Regent Street, London W1B 5TR We've got a couple of lightning talks lined up (I'll be talking about Resolver One, IronPython, and Ironclad) but if you're interested in giving one yourself then drop Didrik Pinte a line at dpinte at enthought.com . There's a (very minimal) Wiki page about the Users Group here: Cheers, Giles -- Giles Thomas giles.thomas at resolversystems.com +44 (0) 20 7253 6372 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Wed Dec 9 17:52:36 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Wed, 9 Dec 2009 08:52:36 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/62149. MODIFIED SOURCES $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Generation/AssemblyGen.cs From empirebuilder at gmail.com Thu Dec 10 10:41:28 2009 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Thu, 10 Dec 2009 11:41:28 +0200 Subject: [IronPython] Embedding IronPython in Silverlight Message-ID: <8cd017b80912100141v1bdef46csacd3f53bc5c8bf03@mail.gmail.com> What are the necessarily libraries for embedding IronPython in Silverlight for the 2.6 releases? My scenario is simply running snippets of Python codes inside oceans of C# based Silverlight code. This Silverlight application has already an embedded IronPython based on older binaries in 2.0 version. I tried yesterday to upgrade this to 2.6 RC 3 and failed. I tried using the technique on Jimmy's recent blog post, http://blog.jimmy.schementi.com/2009/11/embedding-ironpython-in-silverlight.html, I couldn't find the bloody Silverlight.DynamicEngine.CreateRuntime() method anywhere even after linking to Microsoft.Scripting.Silverlight.dll I linked to the following assemblies located under Silverlight\bin under IronPython 2.6 RC 3 zip. - IronPython.dll - IronPython.MOdules.dll - Microsoft.Dynamic.dll - Microsoft.Scripting.Core.dll - Microsoft.Scripting.dll - Microsoft.Scripting.Silverlight.dll -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Thu Dec 10 17:57:54 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Thu, 10 Dec 2009 08:57:54 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <26363bb3-e036-4f33-b33a-9ab4f7ef49d2@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/62169. MODIFIED SOURCES $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Runtime/TokenizerBuffer.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/Tokenizer.cs From Jimmy.Schementi at microsoft.com Thu Dec 10 18:31:36 2009 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Thu, 10 Dec 2009 17:31:36 +0000 Subject: [IronPython] Embedding IronPython in Silverlight In-Reply-To: <8cd017b80912100141v1bdef46csacd3f53bc5c8bf03@mail.gmail.com> References: <8cd017b80912100141v1bdef46csacd3f53bc5c8bf03@mail.gmail.com> Message-ID: <1B42307CD4AADD438CDDA2FE1121CC9205A888@TK5EX14MBXC141.redmond.corp.microsoft.com> Dody, That blog post should work against 2.6 RC3; the method your looking for is a static method: Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntime. Take a look at the example again, I use a using statement to get rid of the Microsoft.Scripting part. ~js ________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] on behalf of Dody Gunawinata [empirebuilder at gmail.com] Sent: Thursday, December 10, 2009 1:41 AM To: Discussion of IronPython Subject: [IronPython] Embedding IronPython in Silverlight What are the necessarily libraries for embedding IronPython in Silverlight for the 2.6 releases? My scenario is simply running snippets of Python codes inside oceans of C# based Silverlight code. This Silverlight application has already an embedded IronPython based on older binaries in 2.0 version. I tried yesterday to upgrade this to 2.6 RC 3 and failed. I tried using the technique on Jimmy's recent blog post, http://blog.jimmy.schementi.com/2009/11/embedding-ironpython-in-silverlight.html, I couldn't find the bloody Silverlight.DynamicEngine.CreateRuntime() method anywhere even after linking to Microsoft.Scripting.Silverlight.dll I linked to the following assemblies located under Silverlight\bin under IronPython 2.6 RC 3 zip. - IronPython.dll - IronPython.MOdules.dll - Microsoft.Dynamic.dll - Microsoft.Scripting.Core.dll - Microsoft.Scripting.dll - Microsoft.Scripting.Silverlight.dll -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Thu Dec 10 21:18:43 2009 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Thu, 10 Dec 2009 22:18:43 +0200 Subject: [IronPython] Embedding IronPython in Silverlight In-Reply-To: <1B42307CD4AADD438CDDA2FE1121CC9205A888@TK5EX14MBXC141.redmond.corp.microsoft.com> References: <8cd017b80912100141v1bdef46csacd3f53bc5c8bf03@mail.gmail.com> <1B42307CD4AADD438CDDA2FE1121CC9205A888@TK5EX14MBXC141.redmond.corp.microsoft.com> Message-ID: <8cd017b80912101218h5fd43a27w457a53dfebe024fe@mail.gmail.com> OK I found out what's wrong. I am using Visual Studio 2010 Beta 2 targeting Silverlight 3. This application already has references to IP 2.0 assemblies. So what I did was remove the old references and then re-add IronPython 2.6 RC 3. Now although VS informed me that the referred assemblies points to 2.6, it still uses IP 2.0 assemblies for Intellisense and Object Browser. A right click reload to Reflector from the VS also loaded IP 2.0 assembly. I had to delete the ClientBin folder so VS stopped referring to the old IP assemblies. Once this is done, finally all the "missing" types appear (the old one only had DynamicApplication and 4 other classes). Sorry for the wrong alarm :) Dody G. On Thu, Dec 10, 2009 at 7:31 PM, Jimmy Schementi < Jimmy.Schementi at microsoft.com> wrote: > Dody, > > That blog post should work against 2.6 RC3; the method your looking for > is a static > method: Microsoft.Scripting.Silverlight.DynamicEngine.CreateRuntime. Take a > look at the example again, I use a using statement to get rid of the > Microsoft.Scripting part. > > ~js > > ------------------------------ > *From:* users-bounces at lists.ironpython.com [ > users-bounces at lists.ironpython.com] on behalf of Dody Gunawinata [ > empirebuilder at gmail.com] > *Sent:* Thursday, December 10, 2009 1:41 AM > *To:* Discussion of IronPython > *Subject:* [IronPython] Embedding IronPython in Silverlight > > What are the necessarily libraries for embedding IronPython in > Silverlight for the 2.6 releases? > > My scenario is simply running snippets of Python codes inside oceans of > C# based Silverlight code. This Silverlight application has already an > embedded IronPython based on older binaries in 2.0 version. > > I tried yesterday to upgrade this to 2.6 RC 3 and failed. I tried using > the technique on Jimmy's recent blog post, > http://blog.jimmy.schementi.com/2009/11/embedding-ironpython-in-silverlight.html, > I couldn't find the bloody Silverlight.DynamicEngine.CreateRuntime() > method anywhere even after linking to Microsoft.Scripting.Silverlight.dll > > I linked to the following assemblies located under Silverlight\bin under > IronPython 2.6 RC 3 zip. > - IronPython.dll > - IronPython.MOdules.dll > - Microsoft.Dynamic.dll > - Microsoft.Scripting.Core.dll > - Microsoft.Scripting.dll > - Microsoft.Scripting.Silverlight.dll > > -- > nomadlife.org > > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Sat Dec 12 00:50:38 2009 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 11 Dec 2009 23:50:38 +0000 Subject: [IronPython] [ANN]: IronPython 2.6 final Message-ID: <1A472770E042064698CB5ADC83A12ACD04D7B34A@TK5EX14MBXC118.redmond.corp.microsoft.com> Hello Python Community, We're proud to announce the release of IronPython 2.6 final. This is a major release with improvements across all areas of IronPython and can be downloaded from http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12482. Significant changes include: * Updating the language and standard library to match CPython 2.6 * Improved .NET integration * Updating to the latest version of the DLR * Adding previously missing CPython features and fixing bugs * Performance improvements in particular startup time improvements Python 2.6 support includes a large number of new features which include support for the new bytes and byte array types (PEP 3112), decorators for classes (PEP 3129), advanced string formatting (PEP 3101) which will feel familiar to .NET users and integrates nicely with IFormattable, print as a function (PEP 3105), Abstract Base Classes (PEP 3119), support for binary literals, along with lots of other minor features and changes. IronPython also continues to improve .NET integration in this release. We've added the __clrtype__ method to types which enables deep integration via meta-classes with the .NET type system. There are also a number of smaller changes such as supporting IDisposable in for loops matching the behavior of other .NET languages. This release also includes the latest version of the DLR and fixes a number of issues related to cross-language dynamic interop. Not to be left out there's improvements in Silverlight integration by supporting Python code in HTML script tags. We've also continued to improve Python compatibility by adding missing features and fixing bugs. In this release we've added support for the ctypes module which provides interop with native code in a compatible way across Python implementations. We've also implemented sys.settrace to provide support for the pdb module and other Python debuggers. This release also changes how we support sys._getframe: a fully working version is now available by a command line option; when not enabled sys._getframe doesn't exist at all. This release also fixes over 400 bugs removing a large number of smaller incompatibilities. As always we've also continued to improve performance, and this release primarily focuses on improving startup time. The IronPython installer now pre-compiles (ngens) IronPython during installation on both 32-bit and 64-bit platforms. Modules are now interpreted initially and hot functions are compiled for faster import times. A number of other code paths that used to involve runtime code generation have been optimized to be contained within the pre-compiled IronPython binaries. We've also made a number of smaller changes which improve performance in other areas such as adding constant folding. Finally we'd like to thank everyone who reported issues and helped make this a better release: Anders M. Mikkelsen, Dan Eloff, Zachc, yamakox, vernondcole, VAks, tscottw, tonyandrewmeyer, tomwright, TomasMatousek, tkamiya, timers, srivatsn, sopeajw, saveenr, sanxiyn, rridge, ronniemaor, quirogaco, pythonfoo, pysunil, pm100, pl6306, paulfelix, orestis, olegt, oldman, NDHUMuscle, mycall, mmaly, mmacdonaldssfcu, maplpro, luntain, llaske, lbaker, Lawouach, laurionb, laughingboy, kurhan, kuno, kowenswp, klrohe, kevgu, jmesserly, jlunder, jdhardy, jbevain, jackeyoo, hhonisch, gz, gjones, fwereade, deadalusai, daveremy, Seo Sanghyeon, CurtHagenlocher, chaghi, cgravill, cartman, bobarnso, atifaziz, ashcor, alvanet, Helmut, fuzzyman, fabiofz, Eloff, RuiDC, Kevin Chu, Kyle Howland-Rose egonw, davec, dungen, dsblank, cjacobs, dmajnemer, leppie, Mark Rees, soulfry, tatwright, ufechner and wilberforce. Thank you for your continued support of IronPython. The IronPython Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Sat Dec 12 10:09:09 2009 From: kfarmer at thuban.org (Keith J. Farmer) Date: Sat, 12 Dec 2009 01:09:09 -0800 Subject: [IronPython] [ANN]: IronPython 2.6 final In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04D7B34A@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <1A472770E042064698CB5ADC83A12ACD04D7B34A@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: May I say: Woot! (And here?s to getting the DLR base types into the framework.. ScriptHost and the like. I have a rather conservative client when it comes to supportability stories.) From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, December 11, 2009 3:51 PM To: Discussion of IronPython; python-announce-list at python.org Subject: [IronPython] [ANN]: IronPython 2.6 final Hello Python Community, We?re proud to announce the release of IronPython 2.6 final. This is a major release with improvements across all areas of IronPython and can be downloaded from http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12482. Significant changes include: ? Updating the language and standard library to match CPython 2.6 ? Improved .NET integration ? Updating to the latest version of the DLR ? Adding previously missing CPython features and fixing bugs ? Performance improvements in particular startup time improvements Python 2.6 support includes a large number of new features which include support for the new bytes and byte array types (PEP 3112 ), decorators for classes (PEP 3129 ), advanced string formatting (PEP 3101 ) which will feel familiar to .NET users and integrates nicely with IFormattable, print as a function (PEP 3105 ), Abstract Base Classes (PEP 3119 ), support for binary literals, along with lots of other minor features and changes. IronPython also continues to improve .NET integration in this release. We?ve added the __clrtype__ method to types which enables deep integration via meta-classes with the .NET type system. There are also a number of smaller changes such as supporting IDisposable in for loops matching the behavior of other .NET languages. This release also includes the latest version of the DLR and fixes a number of issues related to cross-language dynamic interop. Not to be left out there?s improvements in Silverlight integration by supporting Python code in HTML script tags . We?ve also continued to improve Python compatibility by adding missing features and fixing bugs. In this release we?ve added support for the ctypes module which provides interop with native code in a compatible way across Python implementations. We?ve also implemented sys.settrace to provide support for the pdb module and other Python debuggers. This release also changes how we support sys._getframe: a fully working version is now available by a command line option; when not enabled sys._getframe doesn?t exist at all. This release also fixes over 400 bugs removing a large number of smaller incompatibilities. As always we?ve also continued to improve performance, and this release primarily focuses on improving startup time. The IronPython installer now pre-compiles (ngens) IronPython during installation on both 32-bit and 64-bit platforms. Modules are now interpreted initially and hot functions are compiled for faster import times. A number of other code paths that used to involve runtime code generation have been optimized to be contained within the pre-compiled IronPython binaries. We?ve also made a number of smaller changes which improve performance in other areas such as adding constant folding. Finally we?d like to thank everyone who reported issues and helped make this a better release: Anders M. Mikkelsen, Dan Eloff, Zachc, yamakox, vernondcole, VAks, tscottw, tonyandrewmeyer, tomwright, TomasMatousek, tkamiya, timers, srivatsn, sopeajw, saveenr, sanxiyn, rridge, ronniemaor, quirogaco, pythonfoo, pysunil, pm100, pl6306, paulfelix, orestis, olegt, oldman, NDHUMuscle, mycall, mmaly, mmacdonaldssfcu, maplpro, luntain, llaske, lbaker, Lawouach, laurionb, laughingboy, kurhan, kuno, kowenswp, klrohe, kevgu, jmesserly, jlunder, jdhardy, jbevain, jackeyoo, hhonisch, gz, gjones, fwereade, deadalusai, daveremy, Seo Sanghyeon, CurtHagenlocher, chaghi, cgravill, cartman, bobarnso, atifaziz, ashcor, alvanet, Helmut, fuzzyman, fabiofz, Eloff, RuiDC, Kevin Chu, Kyle Howland-Rose egonw, davec, dungen, dsblank, cjacobs, dmajnemer, leppie, Mark Rees, soulfry, tatwright, ufechner and wilberforce. Thank you for your continued support of IronPython. The IronPython Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at globalherald.net Sat Dec 12 22:31:10 2009 From: josh at globalherald.net (Joshua Kramer) Date: Sat, 12 Dec 2009 16:31:10 -0500 (EST) Subject: [IronPython] IronPython 2.6 final: Debugging not working? Message-ID: Hello, First - thanks for all the hard work going into 2.6! But something appears to have broken between 2.6rc3 and 2.6 final. In Eclipse, using either CPython 2.6.4 or IronPython 2.6rc3, I can debug a simple program. Basically, with a series of 'print' statements I can set a breakpoint on one in the middle and the program will stop on the breakpoint. With 2.6 final, the program does not stop on the breakpoints. I have tried setting the Debug perspective manually, and removing the option '-X:noframes'. At first I simply updated 2.6rc3 to 2.6, but after seeing this I completely un-installed 2.6 and re-installed 2.6. Any ideas which bit flipped between 2.6rc3 and 2.6 final? Thanks, -JK From dinov at microsoft.com Sun Dec 13 02:22:28 2009 From: dinov at microsoft.com (Dino Viehland) Date: Sun, 13 Dec 2009 01:22:28 +0000 Subject: [IronPython] IronPython 2.6 final: Debugging not working? In-Reply-To: References: Message-ID: <1A472770E042064698CB5ADC83A12ACD04D81CFF@TK5EX14MBXC118.redmond.corp.microsoft.com> There were no changes between RC3 & the final version - the files are all exactly the same, just now at a new link. I just ran fc.exe on both the MSI and the ZIP as downloaded from CodePlex to make sure and they're identical. When you say "re-installed 2.6" do you mean "re-installed 2.6RC3"? And that fixed the problem? What happens if you try installing 2.6 final again? :) > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Joshua Kramer > Sent: Saturday, December 12, 2009 1:31 PM > To: users at lists.ironpython.com > Subject: [IronPython] IronPython 2.6 final: Debugging not working? > > > Hello, > > First - thanks for all the hard work going into 2.6! > > But something appears to have broken between 2.6rc3 and 2.6 final. In > Eclipse, using either CPython 2.6.4 or IronPython 2.6rc3, I can debug a > simple program. Basically, with a series of 'print' statements I can > set > a breakpoint on one in the middle and the program will stop on the > breakpoint. > > With 2.6 final, the program does not stop on the breakpoints. I have > tried setting the Debug perspective manually, and removing the option > '-X:noframes'. At first I simply updated 2.6rc3 to 2.6, but after > seeing > this I completely un-installed 2.6 and re-installed 2.6. > > Any ideas which bit flipped between 2.6rc3 and 2.6 final? > > Thanks, > -JK > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From josh at globalherald.net Mon Dec 14 05:32:23 2009 From: josh at globalherald.net (Joshua Kramer) Date: Sun, 13 Dec 2009 23:32:23 -0500 (EST) Subject: [IronPython] IronPython 2.6 final: Debugging not working? Message-ID: Dino, This actually appears to be a threading issue. While I was filing a bug report for PyDev I did further testing. In three debugging sessions, two sessions worked fine with full debugging and one session skipped the breakpoints. Here's a relevant debug log: This is where it DOES work: pydev debugger: starting ('Executing file ', 'C:\\Documents and Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py') ('arguments:', "['C:\\\\Documents and Settings\\\\Joshua.Kramer\\\\workspace\\\\DebugTest\\\\src\\\\Program.py']") ('Connecting to ', 'localhost', ':', '3416') ('Connected.',) ('received command ', '501\t1\t1.1') ('received command ', '111\t3\tC:\\Documents and Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py\t10\t**FUNC**\tNone') sending cmd: CMD_THREAD_CREATE 103 2 sending cmd: CMD_VERSION 501 1 1.1 sending cmd: CMD_THREAD_CREATE 103 4 Added breakpoint:c:\documents and settings\joshua.kramer\workspace\debugtest\src\program.py - line:10 - func_name: ('received command ', '101\t5\t') hello lightbulb ('found a new thread ', 'pid264_seq1') sending cmd: CMD_THREAD_CREATE 103 6 sending cmd: CMD_THREAD_SUSPEND 105 8 " ('received command ', '114\t7\tpid264_seq1\t43\tFRAME') ('processing internal command ', '') sending cmd: CMD_GET_FRAME 114 7 %0A%0A%0A This is where it does NOT work: pydev debugger: starting ('Executing file ', 'C:\\Documents and Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py') ('arguments:', "['C:\\\\Documents and Settings\\\\Joshua.Kramer\\\\workspace\\\\DebugTest\\\\src\\\\Program.py']") ('Connecting to ', 'localhost', ':', '3422') ('Connected.',) ('received command ', '501\t1\t1.1') ('received command ', '111\t3\tC:\\Documents and Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py\t10\t**FUNC**\tNone') sending cmd: CMD_THREAD_CREATE 103 2 sending cmd: CMD_VERSION 501 1 1.1 sending cmd: CMD_THREAD_CREATE 103 4 Added breakpoint:c:\documents and settings\joshua.kramer\workspace\debugtest\src\program.py - line:10 - func_name: ('received command ', '101\t5\t') hello lightbulb goodbye gobble done testing How can I further assist? Thanks, -Josh -- ----- http://www.globalherald.net/jb01 GlobalHerald.NET, the Smarter Social Network! (tm) From cenovsky at bakalari.cz Mon Dec 14 11:18:36 2009 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Mon, 14 Dec 2009 11:18:36 +0100 Subject: [IronPython] from __future__ import ... Message-ID: <4B2610FC.2000507@bakalari.cz> Hi, I've found that the from __future__ import ... works in .py file run by ipy.exe but not when I create an engine in C#. test.py: from __future__ import division print 'done' test.cs: using Microsoft.Scripting; using Microsoft.Scripting.Hosting; using IronPython.Hosting; namespace TestDuture { public class Test { static void Main(string[] args) { ScriptEngine engine = Python.CreateEngine(); ScriptRuntime runtime = engine.Runtime; ScriptScope scope = runtime.CreateScope(); ScriptSource source = engine.CreateScriptSourceFromFile("test.py"); source.Execute(scope); } } } build command: csc /r:Microsoft.Dynamic.dll /r:Microsoft.Scripting.core.dll /r:Microsoft.Scripting.dll /r:IronPython.dll /r:IronPython.Modules.dll test.cs Running test.exe throws exception: C:\Users\dev\Documents\FutureTest>test.exe Unhandled Exception: IronPython.Runtime.Exceptions.ImportException: No module named __future__ at Microsoft.Scripting.Actions.Calls.MethodCandidate.Caller.Call(Object[] args, Boolean& shouldOptimize) at IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`5.Call4(CallSite site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, T3 arg3) at System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) at IronPython.Runtime.Importer.Import(CodeContext context, String fullName, PythonTuple from, Int32 level) at IronPython.Runtime.Operations.PythonOps.ImportWithNames(CodeContext context, String fullName, String[] names, Int32 level) at Microsoft.Scripting.Utils.InvokeHelper`5.Invoke(Object arg0, Object arg1, Object arg2, Object arg3) at Microsoft.Scripting.Utils.ReflectedCaller.Invoke(Object[] args) at Microsoft.Scripting.Interpreter.CallInstruction.Run(InterpretedFrame frame) at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) at Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0 arg0, T1 arg1) at IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx) at IronPython.Compiler.PythonScriptCode.Run(Scope scope) at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope) at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope) at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink errorSink) at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope) at TestDuture.Test.Main(String[] args) Am I missing something? It works ok when I add __future__.py from Python 2.6. -- -- Luk?? From giles.thomas at resolversystems.com Mon Dec 14 13:08:38 2009 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Mon, 14 Dec 2009 12:08:38 +0000 Subject: [IronPython] [ANN]: IronPython 2.6 final In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04D7B34A@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <1A472770E042064698CB5ADC83A12ACD04D7B34A@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <4B262AC6.80004@resolversystems.com> Congratulations! We have a release of Resolver One based on IronPython 2.6 that is almost ready to go, and hope to get that into beta shortly. Dino Viehland wrote: > > Hello Python Community, > > We're proud to announce the release of IronPython 2.6 final. This is > a major release with improvements across all areas of IronPython and > can be downloaded from > http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12482. > Significant changes include: > > ? Updating the language and standard library to match CPython 2.6 > > ? Improved .NET integration > > ? Updating to the latest version of the DLR > > ? Adding previously missing CPython features and fixing bugs > > ? Performance improvements in particular startup time improvements > > Python 2.6 support includes a large number of new features which > include support for the new bytes and byte array types (PEP 3112 > ), decorators for classes > (PEP 3129 ), advanced string > formatting (PEP 3101 ) which > will feel familiar to .NET users and integrates nicely with > IFormattable, print as a function (PEP 3105 > ), Abstract Base Classes > (PEP 3119 ), support for > binary literals, along with lots of other minor features and changes. > > IronPython also continues to improve .NET integration in this > release. We've added the __clrtype__ method > > to types which enables deep integration via meta-classes with the .NET > type system. There are also a number of smaller changes such as > supporting IDisposable in for loops > > matching the behavior of other .NET languages. This release also > includes the latest version of the DLR and fixes a number of issues > related to cross-language dynamic interop. Not to be left out there's > improvements in Silverlight integration by supporting Python code in > HTML script tags . > > We've also continued to improve Python compatibility by adding missing > features and fixing bugs. In this release we've added support for the > ctypes module which > provides interop with native code in a compatible way across Python > implementations. We've also implemented sys.settrace to provide > support for the pdb module > and other Python debuggers. This release also changes how we support > sys._getframe: a fully working version is now available by a command > line option; when not enabled sys._getframe doesn't exist at all. > This release also fixes over 400 bugs removing a large number of > smaller incompatibilities. > > As always we've also continued to improve performance, and this > release primarily focuses on improving startup time. The IronPython > installer now pre-compiles (ngens) IronPython during installation on > both 32-bit and 64-bit platforms. Modules are now interpreted > initially and hot functions are compiled for faster import times. A > number of other code paths that used to involve runtime code > generation have been optimized to be contained within the pre-compiled > IronPython binaries. We've also made a number of smaller changes > which improve performance in other areas such as adding constant folding. > > Finally we'd like to thank everyone who reported issues and helped > make this a better release: Anders M. Mikkelsen, Dan Eloff, Zachc, > yamakox, vernondcole, VAks, tscottw, tonyandrewmeyer, tomwright, > TomasMatousek, tkamiya, timers, srivatsn, sopeajw, saveenr, sanxiyn, > rridge, ronniemaor, quirogaco, pythonfoo, pysunil, pm100, pl6306, > paulfelix, orestis, olegt, oldman, NDHUMuscle, mycall, mmaly, > mmacdonaldssfcu, maplpro, luntain, llaske, lbaker, Lawouach, laurionb, > laughingboy, kurhan, kuno, kowenswp, klrohe, kevgu, jmesserly, > jlunder, jdhardy, jbevain, jackeyoo, hhonisch, gz, gjones, fwereade, > deadalusai, daveremy, Seo Sanghyeon, CurtHagenlocher, chaghi, > cgravill, cartman, bobarnso, atifaziz, ashcor, alvanet, Helmut, > fuzzyman, fabiofz, Eloff, RuiDC, Kevin Chu, Kyle Howland-Rose egonw, > davec, dungen, dsblank, cjacobs, dmajnemer, leppie, Mark Rees, > soulfry, tatwright, ufechner and wilberforce. > > Thank you for your continued support of IronPython. > > The IronPython Team > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Giles Thomas giles.thomas at resolversystems.com +44 (0) 20 7253 6372 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Dec 14 16:09:06 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 14 Dec 2009 15:09:06 +0000 Subject: [IronPython] from __future__ import ... In-Reply-To: <4B2610FC.2000507@bakalari.cz> References: <4B2610FC.2000507@bakalari.cz> Message-ID: <4B265512.2020701@voidspace.org.uk> __future__ is a standard library module that must be on the path in order to do future imports. You must put the directory containing this module (or preferably all the standard library) into sys.path before importing it. The ScriptRuntime or ScriptEngine has a SetSearchPaths method that allows you to do this from C#. All the best, Michael Foord On 14/12/2009 10:18, Lukas Cenovsky wrote: > Hi, > I've found that the from __future__ import ... works in .py file run > by ipy.exe but not when I create an engine in C#. > > test.py: > > from __future__ import division > print 'done' > > test.cs: > > using Microsoft.Scripting; > using Microsoft.Scripting.Hosting; > using IronPython.Hosting; > > namespace TestDuture > { > public class Test > { > static void Main(string[] args) > { > ScriptEngine engine = Python.CreateEngine(); > ScriptRuntime runtime = engine.Runtime; > ScriptScope scope = runtime.CreateScope(); > ScriptSource source = > engine.CreateScriptSourceFromFile("test.py"); > source.Execute(scope); > } > } > } > > build command: > > csc /r:Microsoft.Dynamic.dll /r:Microsoft.Scripting.core.dll > /r:Microsoft.Scripting.dll /r:IronPython.dll /r:IronPython.Modules.dll > test.cs > > Running test.exe throws exception: > > C:\Users\dev\Documents\FutureTest>test.exe > > Unhandled Exception: IronPython.Runtime.Exceptions.ImportException: No > module named __future__ > at > Microsoft.Scripting.Actions.Calls.MethodCandidate.Caller.Call(Object[] > args, Boolean& shouldOptimize) > at > IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`5.Call4(CallSite > site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, > T3 arg3) > at > System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite > site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) > at IronPython.Runtime.Importer.Import(CodeContext context, String > fullName, PythonTuple from, Int32 level) > at > IronPython.Runtime.Operations.PythonOps.ImportWithNames(CodeContext > context, String fullName, String[] names, Int32 level) > at Microsoft.Scripting.Utils.InvokeHelper`5.Invoke(Object arg0, > Object arg1, Object arg2, Object arg3) > at Microsoft.Scripting.Utils.ReflectedCaller.Invoke(Object[] args) > at > Microsoft.Scripting.Interpreter.CallInstruction.Run(InterpretedFrame > frame) > at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame > frame) > at Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0 > arg0, T1 arg1) > at IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx) > at IronPython.Compiler.PythonScriptCode.Run(Scope scope) > at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope) > at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope) > at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink > errorSink) > at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope) > at TestDuture.Test.Main(String[] args) > > Am I missing something? It works ok when I add __future__.py from > Python 2.6. > > -- > -- Luk?? > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From cenovsky at bakalari.cz Mon Dec 14 17:08:32 2009 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Mon, 14 Dec 2009 17:08:32 +0100 Subject: [IronPython] from __future__ import ... In-Reply-To: <4B265512.2020701@voidspace.org.uk> References: <4B2610FC.2000507@bakalari.cz> <4B265512.2020701@voidspace.org.uk> Message-ID: <4B266300.3000601@bakalari.cz> I've found the catch - the __future__.py module is in ironpython\lib folder which is automatically added to path by ipy.exe - that's why it worked from interpreter but not from the ScriptEngine. -- -- Luk?? Michael Foord wrote: > __future__ is a standard library module that must be on the path in > order to do future imports. You must put the directory containing this > module (or preferably all the standard library) into sys.path before > importing it. > > The ScriptRuntime or ScriptEngine has a SetSearchPaths method that > allows you to do this from C#. > > All the best, > > Michael Foord > > On 14/12/2009 10:18, Lukas Cenovsky wrote: >> Hi, >> I've found that the from __future__ import ... works in .py file run >> by ipy.exe but not when I create an engine in C#. >> >> test.py: >> >> from __future__ import division >> print 'done' >> >> test.cs: >> >> using Microsoft.Scripting; >> using Microsoft.Scripting.Hosting; >> using IronPython.Hosting; >> >> namespace TestDuture >> { >> public class Test >> { >> static void Main(string[] args) >> { >> ScriptEngine engine = Python.CreateEngine(); >> ScriptRuntime runtime = engine.Runtime; >> ScriptScope scope = runtime.CreateScope(); >> ScriptSource source = >> engine.CreateScriptSourceFromFile("test.py"); >> source.Execute(scope); >> } >> } >> } >> >> build command: >> >> csc /r:Microsoft.Dynamic.dll /r:Microsoft.Scripting.core.dll >> /r:Microsoft.Scripting.dll /r:IronPython.dll >> /r:IronPython.Modules.dll test.cs >> >> Running test.exe throws exception: >> >> C:\Users\dev\Documents\FutureTest>test.exe >> >> Unhandled Exception: IronPython.Runtime.Exceptions.ImportException: >> No module named __future__ >> at >> Microsoft.Scripting.Actions.Calls.MethodCandidate.Caller.Call(Object[] >> args, Boolean& shouldOptimize) >> at >> IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`5.Call4(CallSite >> site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, >> T3 arg3) >> at >> System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite >> site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) >> at IronPython.Runtime.Importer.Import(CodeContext context, String >> fullName, PythonTuple from, Int32 level) >> at >> IronPython.Runtime.Operations.PythonOps.ImportWithNames(CodeContext >> context, String fullName, String[] names, Int32 level) >> at Microsoft.Scripting.Utils.InvokeHelper`5.Invoke(Object arg0, >> Object arg1, Object arg2, Object arg3) >> at Microsoft.Scripting.Utils.ReflectedCaller.Invoke(Object[] args) >> at >> Microsoft.Scripting.Interpreter.CallInstruction.Run(InterpretedFrame >> frame) >> at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame >> frame) >> at Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0 >> arg0, T1 arg1) >> at IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx) >> at IronPython.Compiler.PythonScriptCode.Run(Scope scope) >> at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope) >> at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope) >> at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink >> errorSink) >> at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope) >> at TestDuture.Test.Main(String[] args) >> >> Am I missing something? It works ok when I add __future__.py from >> Python 2.6. >> >> -- >> -- Luk?? >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From merllab at microsoft.com Mon Dec 14 17:53:40 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Mon, 14 Dec 2009 08:53:40 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/62266. ADDED SOURCES $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Actions/IInvokeOnGetBinder.cs MODIFIED SOURCES $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Actions/IInvokeOnGetBinder.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/ConstantCheck.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/ILGen.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/TypeUtils.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Actions/DynamicObject.cs From dwoogle at gmail.com Mon Dec 14 17:59:45 2009 From: dwoogle at gmail.com (David Welden) Date: Mon, 14 Dec 2009 10:59:45 -0600 Subject: [IronPython] Users Digest, Vol 65, Issue 16 In-Reply-To: References: Message-ID: Any news on work item 25106: ctypes: no support for Union? ctypes is not really done if unions are unsupported. 1. [ANN]: IronPython 2.6 final (Dino Viehland) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Waller1 at Blueyonder.co.uk Mon Dec 14 18:47:10 2009 From: David.Waller1 at Blueyonder.co.uk (David Waller) Date: Mon, 14 Dec 2009 17:47:10 -0000 Subject: [IronPython] IronPython 2.6 final and net 4 Message-ID: <001b01ca7ce5$7612d0a0$623871e0$@Waller1@Blueyonder.co.uk> Hello, I have been using earlier versions of IronPython 2.6 (not sure exactly which version) without any major issues. I have recently tried to install the latest 2.6 final and it complains about "requires .NET Framework 2.0 SP1 or later. NET 4.0 is not supported". I have installed .NET 4.0 as part of the Visual express 2010 software. Is there any way I can convince IronPython to update itself without uninstalling the visual express software. Also isn't .NET 4.0 a later version of .NET 2.0 Thanks David Waller -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Dec 14 18:57:16 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 14 Dec 2009 17:57:16 +0000 Subject: [IronPython] IronPython 2.6 final and net 4 In-Reply-To: <001b01ca7ce5$7612d0a0$623871e0$@Waller1@Blueyonder.co.uk> References: <001b01ca7ce5$7612d0a0$623871e0$@Waller1@Blueyonder.co.uk> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D8E128@TK5EX14MBXC118.redmond.corp.microsoft.com> Do you have .NET 2.0 installed as well as .NET 4.0? .NET 2.0 and .NET 4.0 are side by side releases. While IronPython built for .NET 2.0 would probably run fine on .NET 4.0 we haven't done any testing to make sure that's the case. Additionally it would cause a lot of confusion because we have been putting out .NET 4.0 compatible releases which use new functionality that we usually ship as part of IronPython (Microsoft.Scripting.Core - the portions of the DLR shipping in .NET 4.0). Therefore lots of people would probably try and use C#/VB.NET's new dynamic support to talk to IronPython and it would fail but it wouldn't be entirely obvious why it's not working. You should just be able to install .NET 2.0 SP1 in addition to 4.0 and things should work. .NET 4.0 is certainly a later version and that's why the message explicitly calls out that .NET 4.0 isn't supported :) It means later in the 2.0/3.0/3.5 series of runtimes which are all in place upgrades. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David Waller Sent: Monday, December 14, 2009 9:47 AM To: users at lists.ironpython.com Subject: [IronPython] IronPython 2.6 final and net 4 Hello, I have been using earlier versions of IronPython 2.6 (not sure exactly which version) without any major issues. I have recently tried to install the latest 2.6 final and it complains about "requires .NET Framework 2.0 SP1 or later. NET 4.0 is not supported". I have installed .NET 4.0 as part of the Visual express 2010 software. Is there any way I can convince IronPython to update itself without uninstalling the visual express software. Also isn't .NET 4.0 a later version of .NET 2.0 Thanks David Waller -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Dec 14 18:59:22 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 14 Dec 2009 17:59:22 +0000 Subject: [IronPython] Users Digest, Vol 65, Issue 16 In-Reply-To: References: Message-ID: <1A472770E042064698CB5ADC83A12ACD04D8E172@TK5EX14MBXC118.redmond.corp.microsoft.com> Unfortunately it didn't get fixed for 2.6 but we're planning on fixing that for 2.6.1. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David Welden Sent: Monday, December 14, 2009 9:00 AM To: users at lists.ironpython.com Subject: Re: [IronPython] Users Digest, Vol 65, Issue 16 Any news on work item 25106: ctypes: no support for Union? ctypes is not really done if unions are unsupported. 1. [ANN]: IronPython 2.6 final (Dino Viehland) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Dec 14 19:35:38 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 14 Dec 2009 18:35:38 +0000 Subject: [IronPython] IronPython 2.6 final: Debugging not working? In-Reply-To: References: Message-ID: <1A472770E042064698CB5ADC83A12ACD04D8E5B0@TK5EX14MBXC118.redmond.corp.microsoft.com> I'll have to look into this and get back to you - hopefully I can figure it out on my side. There were some threading issues in Beta 2 I believe and I thought they were all fixed but maybe there's still something lingering. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Joshua Kramer > Sent: Sunday, December 13, 2009 8:32 PM > To: users at lists.ironpython.com > Subject: Re: [IronPython] IronPython 2.6 final: Debugging not working? > > > Dino, > > This actually appears to be a threading issue. While I was filing a bug > report for PyDev I did further testing. In three debugging sessions, two > sessions worked fine with full debugging and one session skipped the > breakpoints. Here's a relevant debug log: > > This is where it DOES work: > > pydev debugger: starting > ('Executing file ', 'C:\\Documents and > Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py') > ('arguments:', "['C:\\\\Documents and > Settings\\\\Joshua.Kramer\\\\workspace\\\\DebugTest\\\\src\\\\Program.py']") > ('Connecting to ', 'localhost', ':', '3416') > ('Connected.',) > ('received command ', '501\t1\t1.1') > ('received command ', '111\t3\tC:\\Documents and > Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py\t10\t**FUNC**\t > None') > sending cmd: CMD_THREAD_CREATE 103 2 name="pydevd.reader" id="-1"/> > > sending cmd: CMD_VERSION 501 1 1.1 > > sending cmd: CMD_THREAD_CREATE 103 4 name="pydevd.writer" id="-1"/> > > Added breakpoint:c:\documents and > settings\joshua.kramer\workspace\debugtest\src\program.py - line:10 - > func_name: > ('received command ', '101\t5\t') > hello > lightbulb > ('found a new thread ', 'pid264_seq1') > sending cmd: CMD_THREAD_CREATE 103 6 name="MainThread" id="pid264_seq1" /> > > sending cmd: CMD_THREAD_SUSPEND 105 8 id="pid264_seq1" stop_reason="111"> name="%26lt%3Bmodule%26gt%3B" file="c%253A%255Cdocuments and > settings%255Cjoshua.kramer%255Cworkspace%255Cdebugtest%255Csrc%255Cprogram.py" > line="10">" > > ('received command ', '114\t7\tpid264_seq1\t43\tFRAME') > ('processing internal command ', ' at 0x000000000000002C>') > sending cmd: CMD_GET_FRAME 114 7 type="CodeContext" value="CodeContext%253A > %253CIronPython.Runtime.CodeContext object at 0x000000000000002D > %255BIronPython.Runtime.CodeContext%255D%26gt%3B" isContainer="True" > />%0A%0A name="functionCode" type="code" value="code%253A %253Ccode object at > 0x000000000000002E%26gt%3B" isContainer="True" />%0A > > This is where it does NOT work: > > pydev debugger: starting > ('Executing file ', 'C:\\Documents and > Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py') > ('arguments:', "['C:\\\\Documents and > Settings\\\\Joshua.Kramer\\\\workspace\\\\DebugTest\\\\src\\\\Program.py']") > ('Connecting to ', 'localhost', ':', '3422') > ('Connected.',) > ('received command ', '501\t1\t1.1') > ('received command ', '111\t3\tC:\\Documents and > Settings\\Joshua.Kramer\\workspace\\DebugTest\\src\\Program.py\t10\t**FUNC**\t > None') > sending cmd: CMD_THREAD_CREATE 103 2 name="pydevd.reader" id="-1"/> > > sending cmd: CMD_VERSION 501 1 1.1 > > sending cmd: CMD_THREAD_CREATE 103 4 name="pydevd.writer" id="-1"/> > > Added breakpoint:c:\documents and > settings\joshua.kramer\workspace\debugtest\src\program.py - line:10 - > func_name: > ('received command ', '101\t5\t') > hello > lightbulb > goodbye > gobble > done testing > > How can I further assist? > > Thanks, > -Josh > > -- > > ----- > http://www.globalherald.net/jb01 > GlobalHerald.NET, the Smarter Social Network! (tm) > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From kfarmer at thuban.org Mon Dec 14 19:45:00 2009 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 14 Dec 2009 10:45:00 -0800 Subject: [IronPython] IronPython 2.6 final and net 4 References: <001b01ca7ce5$7612d0a0$623871e0$@Waller1@Blueyonder.co.uk> <1A472770E042064698CB5ADC83A12ACD04D8E128@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: Is a refresh planned for .NET 4 RTM that won't require the 2.x CLR be installed? ________________________________ From: users-bounces at lists.ironpython.com on behalf of Dino Viehland Sent: Mon 12/14/2009 9:57 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 final and net 4 Do you have .NET 2.0 installed as well as .NET 4.0? .NET 2.0 and .NET 4.0 are side by side releases. While IronPython built for .NET 2.0 would probably run fine on .NET 4.0 we haven't done any testing to make sure that's the case. Additionally it would cause a lot of confusion because we have been putting out .NET 4.0 compatible releases which use new functionality that we usually ship as part of IronPython (Microsoft.Scripting.Core - the portions of the DLR shipping in .NET 4.0). Therefore lots of people would probably try and use C#/VB.NET's new dynamic support to talk to IronPython and it would fail but it wouldn't be entirely obvious why it's not working. You should just be able to install .NET 2.0 SP1 in addition to 4.0 and things should work. .NET 4.0 is certainly a later version and that's why the message explicitly calls out that .NET 4.0 isn't supported J It means later in the 2.0/3.0/3.5 series of runtimes which are all in place upgrades. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David Waller Sent: Monday, December 14, 2009 9:47 AM To: users at lists.ironpython.com Subject: [IronPython] IronPython 2.6 final and net 4 Hello, I have been using earlier versions of IronPython 2.6 (not sure exactly which version) without any major issues. I have recently tried to install the latest 2.6 final and it complains about "requires .NET Framework 2.0 SP1 or later. NET 4.0 is not supported". I have installed .NET 4.0 as part of the Visual express 2010 software. Is there any way I can convince IronPython to update itself without uninstalling the visual express software. Also isn't .NET 4.0 a later version of .NET 2.0 Thanks David Waller -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Dec 14 20:00:16 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 14 Dec 2009 19:00:16 +0000 Subject: [IronPython] IronPython 2.6 final and net 4 In-Reply-To: References: <001b01ca7ce5$7612d0a0$623871e0$@Waller1@Blueyonder.co.uk> <1A472770E042064698CB5ADC83A12ACD04D8E128@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D8E8A1@TK5EX14MBXC118.redmond.corp.microsoft.com> Yes - we've got previews of this already in the form of our IronPython 2.6 CTP for .NET 4.0 Beta 2 (and previously beta 1 release). We are continuing to update 2.6 for better .NET 4.0 compatbility and the plan is to ship a 2.6.x release in both .NET 2.0 and .NET 4.0 flavors around when .NET 4.0 ships. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer Sent: Monday, December 14, 2009 10:45 AM To: Discussion of IronPython; Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 final and net 4 Is a refresh planned for .NET 4 RTM that won't require the 2.x CLR be installed? ________________________________ From: users-bounces at lists.ironpython.com on behalf of Dino Viehland Sent: Mon 12/14/2009 9:57 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 final and net 4 Do you have .NET 2.0 installed as well as .NET 4.0? .NET 2.0 and .NET 4.0 are side by side releases. While IronPython built for .NET 2.0 would probably run fine on .NET 4.0 we haven't done any testing to make sure that's the case. Additionally it would cause a lot of confusion because we have been putting out .NET 4.0 compatible releases which use new functionality that we usually ship as part of IronPython (Microsoft.Scripting.Core - the portions of the DLR shipping in .NET 4.0). Therefore lots of people would probably try and use C#/VB.NET's new dynamic support to talk to IronPython and it would fail but it wouldn't be entirely obvious why it's not working. You should just be able to install .NET 2.0 SP1 in addition to 4.0 and things should work. .NET 4.0 is certainly a later version and that's why the message explicitly calls out that .NET 4.0 isn't supported :) It means later in the 2.0/3.0/3.5 series of runtimes which are all in place upgrades. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David Waller Sent: Monday, December 14, 2009 9:47 AM To: users at lists.ironpython.com Subject: [IronPython] IronPython 2.6 final and net 4 Hello, I have been using earlier versions of IronPython 2.6 (not sure exactly which version) without any major issues. I have recently tried to install the latest 2.6 final and it complains about "requires .NET Framework 2.0 SP1 or later. NET 4.0 is not supported". I have installed .NET 4.0 as part of the Visual express 2010 software. Is there any way I can convince IronPython to update itself without uninstalling the visual express software. Also isn't .NET 4.0 a later version of .NET 2.0 Thanks David Waller -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Tue Dec 15 01:55:57 2009 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Tue, 15 Dec 2009 01:55:57 +0100 Subject: [IronPython] codecs module in Silverlight Message-ID: <4B26DE9D.1080907@bakalari.cz> Hi all, I cannot import codecs module in Silverligh IronPython - it throws NameError for lookup_error method. The reason is this method is not in the _codecs module of Silverlight IronPython: dir(_codecs) - Silverlight ['__doc__', '__name__', '__package__', 'ascii_decode', 'ascii_encode', 'charbuffer_encode', 'charmap_decode', 'charmap_encode', 'decode', 'encode', 'escape_decode', 'escape_encode', 'lookup', 'raw_unicode_escape_decode', 'raw_unicode_escape_encode', 'readbuffer_encode', 'register', 'unicode_escape_decode', 'unicode_escape_encode', 'unicode_internal_decode', 'unicode_internal_encode', 'utf_16_be_decode', 'utf_16_be_encode', 'utf_16_decode', 'utf_16_encode', 'utf_16_ex_decode', 'utf_16_le_decode', 'utf_16_le_encode', 'utf_8_decode', 'utf_8_encode'] dir(_codecs) - IronPython ['__doc__', '__name__', '__package__', 'ascii_decode', 'ascii_encode', 'charbuffer_encode', 'charmap_decode', 'charmap_encode', 'decode', 'encode', 'escape_decode', 'escape_encode', 'latin_1_decode', 'latin_1_encode', 'lookup', 'lookup_error', 'mbcs_decode', 'mbcs_encode', 'raw_unicode_escape_decode', 'raw_unicode_escape_encode', 'readbuffer_encode', 'register', 'register_error', 'unicode_escape_decode', 'unicode_escape_encode', 'unicode_internal_decode', 'unicode_internal_encode', 'utf_16_be_decode', 'utf_16_be_encode', 'utf_16_decode', 'utf_16_encode', 'utf_16_ex_decode', 'utf_16_le_decode', 'utf_16_le_encode', 'utf_32_decode', 'utf_32_encode', 'utf_32_ex_decode', 'utf_32_le_decode', 'utf_32_le_encode', 'utf_7_decode', 'utf_7_encode', 'utf_8_decode', 'utf_8_encode'] Any idea how to make it work? Thanks. -- -- Luk?? From dinov at microsoft.com Tue Dec 15 02:05:13 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 15 Dec 2009 01:05:13 +0000 Subject: [IronPython] codecs module in Silverlight In-Reply-To: <4B26DE9D.1080907@bakalari.cz> References: <4B26DE9D.1080907@bakalari.cz> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D90DBE@TK5EX14MBXC118.redmond.corp.microsoft.com> You could do: import _codecs def lookup_error(name): raise LookupError('unknown error handler') _codecs.lookup_error = lookup_error This looks like we've just overly aggressively disabled some functionality in Silverlight. Maybe it used to depend upon something that wasn't available but it doesn't look like it does anymore. I've opened a bug: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25673 It should be trivial to fix. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Lukas Cenovsky > Sent: Monday, December 14, 2009 4:56 PM > To: Discussion of IronPython > Subject: [IronPython] codecs module in Silverlight > > Hi all, > I cannot import codecs module in Silverligh IronPython - it throws > NameError for lookup_error method. The reason is this method is not in > the _codecs module of Silverlight IronPython: > > dir(_codecs) - Silverlight > ['__doc__', '__name__', '__package__', 'ascii_decode', 'ascii_encode', > 'charbuffer_encode', 'charmap_decode', 'charmap_encode', 'decode', 'encode', > 'escape_decode', 'escape_encode', 'lookup', 'raw_unicode_escape_decode', > 'raw_unicode_escape_encode', 'readbuffer_encode', 'register', > 'unicode_escape_decode', 'unicode_escape_encode', 'unicode_internal_decode', > 'unicode_internal_encode', 'utf_16_be_decode', 'utf_16_be_encode', > 'utf_16_decode', 'utf_16_encode', 'utf_16_ex_decode', 'utf_16_le_decode', > 'utf_16_le_encode', 'utf_8_decode', 'utf_8_encode'] > > dir(_codecs) - IronPython > ['__doc__', '__name__', '__package__', 'ascii_decode', 'ascii_encode', > 'charbuffer_encode', 'charmap_decode', 'charmap_encode', 'decode', 'encode', > 'escape_decode', 'escape_encode', 'latin_1_decode', 'latin_1_encode', > 'lookup', > 'lookup_error', 'mbcs_decode', 'mbcs_encode', 'raw_unicode_escape_decode', > 'raw_unicode_escape_encode', 'readbuffer_encode', 'register', > 'register_error', > 'unicode_escape_decode', 'unicode_escape_encode', 'unicode_internal_decode', > 'unicode_internal_encode', 'utf_16_be_decode', 'utf_16_be_encode', > 'utf_16_decode', 'utf_16_encode', 'utf_16_ex_decode', 'utf_16_le_decode', > 'utf_16_le_encode', 'utf_32_decode', 'utf_32_encode', 'utf_32_ex_decode', > 'utf_32_le_decode', 'utf_32_le_encode', 'utf_7_decode', 'utf_7_encode', > 'utf_8_decode', 'utf_8_encode'] > > Any idea how to make it work? Thanks. > > -- > -- Luk?? > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Tue Dec 15 11:03:41 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 15 Dec 2009 10:03:41 +0000 Subject: [IronPython] codecs module in Silverlight In-Reply-To: <4B26DE9D.1080907@bakalari.cz> References: <4B26DE9D.1080907@bakalari.cz> Message-ID: <4B275EFD.6020201@voidspace.org.uk> On 15/12/2009 00:55, Lukas Cenovsky wrote: > Hi all, > I cannot import codecs module in Silverligh IronPython - it throws > NameError for lookup_error method. The reason is this method is not in > the _codecs module of Silverlight IronPython: > Yeah, this is a problem that prevents you using simplejson in Silverlight as well. :-( Michael > dir(_codecs) - Silverlight > ['__doc__', '__name__', '__package__', 'ascii_decode', 'ascii_encode', > 'charbuffer_encode', 'charmap_decode', 'charmap_encode', 'decode', > 'encode', > 'escape_decode', 'escape_encode', 'lookup', 'raw_unicode_escape_decode', > 'raw_unicode_escape_encode', 'readbuffer_encode', 'register', > 'unicode_escape_decode', 'unicode_escape_encode', > 'unicode_internal_decode', > 'unicode_internal_encode', 'utf_16_be_decode', 'utf_16_be_encode', > 'utf_16_decode', 'utf_16_encode', 'utf_16_ex_decode', 'utf_16_le_decode', > 'utf_16_le_encode', 'utf_8_decode', 'utf_8_encode'] > > dir(_codecs) - IronPython > ['__doc__', '__name__', '__package__', 'ascii_decode', 'ascii_encode', > 'charbuffer_encode', 'charmap_decode', 'charmap_encode', 'decode', > 'encode', > 'escape_decode', 'escape_encode', 'latin_1_decode', 'latin_1_encode', > 'lookup', > 'lookup_error', 'mbcs_decode', 'mbcs_encode', > 'raw_unicode_escape_decode', > 'raw_unicode_escape_encode', 'readbuffer_encode', 'register', > 'register_error', > 'unicode_escape_decode', 'unicode_escape_encode', > 'unicode_internal_decode', > 'unicode_internal_encode', 'utf_16_be_decode', 'utf_16_be_encode', > 'utf_16_decode', 'utf_16_encode', 'utf_16_ex_decode', 'utf_16_le_decode', > 'utf_16_le_encode', 'utf_32_decode', 'utf_32_encode', 'utf_32_ex_decode', > 'utf_32_le_decode', 'utf_32_le_encode', 'utf_7_decode', 'utf_7_encode', > 'utf_8_decode', 'utf_8_encode'] > > Any idea how to make it work? Thanks. > > -- > -- Luk?? > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From cenovsky at bakalari.cz Tue Dec 15 11:15:28 2009 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Tue, 15 Dec 2009 11:15:28 +0100 Subject: [IronPython] codecs module in Silverlight In-Reply-To: <4B275EFD.6020201@voidspace.org.uk> References: <4B26DE9D.1080907@bakalari.cz> <4B275EFD.6020201@voidspace.org.uk> Message-ID: <4B2761C0.50809@bakalari.cz> Michael Foord wrote: > On 15/12/2009 00:55, Lukas Cenovsky wrote: >> Hi all, >> I cannot import codecs module in Silverligh IronPython - it throws >> NameError for lookup_error method. The reason is this method is not >> in the _codecs module of Silverlight IronPython: > > Yeah, this is a problem that prevents you using simplejson in > Silverlight as well. :-( > > Michael Yep - I found your message from last month this morning. The whole browser crashes when I try to import simplejson (after adding lookup_error to _codecs). Have you hacked it somehow or do you use something else (Newtonsoft Json.NET)? -- -- Luk?? From fuzzyman at voidspace.org.uk Tue Dec 15 11:22:44 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 15 Dec 2009 10:22:44 +0000 Subject: [IronPython] codecs module in Silverlight In-Reply-To: <4B2761C0.50809@bakalari.cz> References: <4B26DE9D.1080907@bakalari.cz> <4B275EFD.6020201@voidspace.org.uk> <4B2761C0.50809@bakalari.cz> Message-ID: <4B276374.7010804@voidspace.org.uk> On 15/12/2009 10:15, Lukas Cenovsky wrote: > Michael Foord wrote: >> On 15/12/2009 00:55, Lukas Cenovsky wrote: >>> Hi all, >>> I cannot import codecs module in Silverligh IronPython - it throws >>> NameError for lookup_error method. The reason is this method is not >>> in the _codecs module of Silverlight IronPython: >> >> Yeah, this is a problem that prevents you using simplejson in >> Silverlight as well. :-( >> >> Michael > Yep - I found your message from last month this morning. > The whole browser crashes when I try to import simplejson (after > adding lookup_error to _codecs). > Have you hacked it somehow or do you use something else (Newtonsoft > Json.NET)? Currently we're using an old version of simplejson. It's pretty horrible as it uses the old sre_* modules rather than re. It works fine but we'd like to switch to a C# JSON parser to reduce the import time. Michael > > -- > -- Luk?? > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From cenovsky at bakalari.cz Tue Dec 15 12:36:19 2009 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Tue, 15 Dec 2009 12:36:19 +0100 Subject: [IronPython] codecs module in Silverlight In-Reply-To: <4B276374.7010804@voidspace.org.uk> References: <4B26DE9D.1080907@bakalari.cz> <4B275EFD.6020201@voidspace.org.uk> <4B2761C0.50809@bakalari.cz> <4B276374.7010804@voidspace.org.uk> Message-ID: <4B2774B3.5060002@bakalari.cz> Michael Foord wrote: > On 15/12/2009 10:15, Lukas Cenovsky wrote: >> Michael Foord wrote: >>> On 15/12/2009 00:55, Lukas Cenovsky wrote: >>>> Hi all, >>>> I cannot import codecs module in Silverligh IronPython - it throws >>>> NameError for lookup_error method. The reason is this method is not >>>> in the _codecs module of Silverlight IronPython: >>> >>> Yeah, this is a problem that prevents you using simplejson in >>> Silverlight as well. :-( >>> >>> Michael >> Yep - I found your message from last month this morning. >> The whole browser crashes when I try to import simplejson (after >> adding lookup_error to _codecs). >> Have you hacked it somehow or do you use something else (Newtonsoft >> Json.NET)? > > Currently we're using an old version of simplejson. It's pretty > horrible as it uses the old sre_* modules rather than re. It works > fine but we'd like to switch to a C# JSON parser to reduce the import > time. > > Michael Yes - the import time is quite an issue. I checked the issue tracker and I did not see any opened issue for pyc.py supporting Silverlight so I have added one. Please vote: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25680 -- -- Luk?? From fuzzyman at voidspace.org.uk Tue Dec 15 12:48:51 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 15 Dec 2009 11:48:51 +0000 Subject: [IronPython] codecs module in Silverlight In-Reply-To: <4B2774B3.5060002@bakalari.cz> References: <4B26DE9D.1080907@bakalari.cz> <4B275EFD.6020201@voidspace.org.uk> <4B2761C0.50809@bakalari.cz> <4B276374.7010804@voidspace.org.uk> <4B2774B3.5060002@bakalari.cz> Message-ID: <4B2777A3.5010605@voidspace.org.uk> On 15/12/2009 11:36, Lukas Cenovsky wrote: > Michael Foord wrote: >> On 15/12/2009 10:15, Lukas Cenovsky wrote: >>> Michael Foord wrote: >>>> On 15/12/2009 00:55, Lukas Cenovsky wrote: >>>>> Hi all, >>>>> I cannot import codecs module in Silverligh IronPython - it throws >>>>> NameError for lookup_error method. The reason is this method is >>>>> not in the _codecs module of Silverlight IronPython: >>>> >>>> Yeah, this is a problem that prevents you using simplejson in >>>> Silverlight as well. :-( >>>> >>>> Michael >>> Yep - I found your message from last month this morning. >>> The whole browser crashes when I try to import simplejson (after >>> adding lookup_error to _codecs). >>> Have you hacked it somehow or do you use something else (Newtonsoft >>> Json.NET)? >> >> Currently we're using an old version of simplejson. It's pretty >> horrible as it uses the old sre_* modules rather than re. It works >> fine but we'd like to switch to a C# JSON parser to reduce the import >> time. >> >> Michael > Yes - the import time is quite an issue. I checked the issue tracker > and I did not see any opened issue for pyc.py supporting Silverlight > so I have added one. Please vote: > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25680 Voted. Our current app shows the login screen and then does the imports in the background (using parallel imports code) whilst the login screen is showing. Michael > > -- > -- Luk?? > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From David.Waller1 at Blueyonder.co.uk Tue Dec 15 15:58:06 2009 From: David.Waller1 at Blueyonder.co.uk (David Waller) Date: Tue, 15 Dec 2009 14:58:06 -0000 Subject: [IronPython] Ironpython 2.6 final and net 4 Message-ID: <003c01ca7d97$02526b50$06f741f0$@Waller1@Blueyonder.co.uk> Sorry I wasn't explain enough last time. I am running Vista and already have .NET 3.5 SP1 installed, as well as the current .NET 4. When I try and install the latest Iron python 2.6 final it complains "requires .NET Framework 2.0 SP1 or later. NET 4.0 is not supported". As I am running Vista I can't install .NET 2.0 SP1 as it is already part of Vista. I already have an earlier version of Iron Python 2.6 and this is what it reports when starting up "IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4200" Thanks David Waller -------------- next part -------------- An HTML attachment was scrubbed... URL: From merllab at microsoft.com Tue Dec 15 17:52:27 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Tue, 15 Dec 2009 08:52:27 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/62295. ADDED SOURCES $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/CustomInstanceDictionaryStorage.cs DELETED SOURCES $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Runtime/DynamicRuntimeHostingProvider.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/CustomOldClassDictionary.cs MODIFIED SOURCES $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/CustomInstanceDictionaryStorage.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Microsoft.Dynamic.csproj $/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaOldInstance.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaUserObject.Members.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonTypeDictSlot.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/OldInstance.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/OldClass.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/UserTypeOps.cs $/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1345559 Date: 12/14/2009 5:56:03 PM For old-style classes we have had an optimized dictionary which performs lock-free array based storage for instance members which are assigned in __init__. This adds the same optimization for (most) new-style classes. The class CustomOldClassDictionaryStorage is renamed to CustomInstanceDictionaryStorage to indicate that this is now shared between both new-style and old-style classes. The names version allocation moves as a static on CIDS. When creating a new-style class which doesn?t have a meta-class we now flow the self names that we?ve always calculated in the type. When initializing the type we walk the MRO and collect all of the names that are base classes want as well. We then remember the list of names if we have any. Then when we go and create the dictionary for a new-style class we create a dictionary backed by CIDS instead of our CommonDictionaryStorage. Finally both are pre-compiled and non-precompiled code paths are updated to generate rules which access the correct array index instead of doing a dictionary lookup. On my machine this brings Richards.py, a bench mark which does lots of instance dictionary access, execution time down to 4.68s from 7.84s for a 38% improvement. I?m also deleting DynamicRuntimeHostingProvider from Microsoft.Dynamic ? this type was duplicated in both Microsoft.Scripting and Microsoft.Dynamic but only the one in Microsoft.Scripting is useful. (Shelveset: OptimizedNewStyleClassesFinal;REDMOND\dinov | SNAP CheckinId: 10016) From dinov at microsoft.com Tue Dec 15 19:10:54 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 15 Dec 2009 18:10:54 +0000 Subject: [IronPython] Ironpython 2.6 final and net 4 In-Reply-To: <003c01ca7d97$02526b50$06f741f0$@Waller1@Blueyonder.co.uk> References: <003c01ca7d97$02526b50$06f741f0$@Waller1@Blueyonder.co.uk> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D972C0@TK5EX14MBXC118.redmond.corp.microsoft.com> Can you look at the value in the registry for HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727 for "Install"? Is it 1? Also is it 64-bit or 32-bit Vista? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David Waller Sent: Tuesday, December 15, 2009 6:58 AM To: users at lists.ironpython.com Subject: Re: [IronPython] Ironpython 2.6 final and net 4 Sorry I wasn't explain enough last time. I am running Vista and already have .NET 3.5 SP1 installed, as well as the current .NET 4. When I try and install the latest Iron python 2.6 final it complains "requires .NET Framework 2.0 SP1 or later. NET 4.0 is not supported". As I am running Vista I can't install .NET 2.0 SP1 as it is already part of Vista. I already have an earlier version of Iron Python 2.6 and this is what it reports when starting up "IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4200" Thanks David Waller -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jimmy.Schementi at microsoft.com Tue Dec 15 19:38:19 2009 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Tue, 15 Dec 2009 18:38:19 +0000 Subject: [IronPython] codecs module in Silverlight In-Reply-To: <4B2761C0.50809@bakalari.cz> References: <4B26DE9D.1080907@bakalari.cz> <4B275EFD.6020201@voidspace.org.uk> <4B2761C0.50809@bakalari.cz> Message-ID: The whole browser crashes?! That shouldn't be happening; can you open a bug with a repro of that? System.Json.dll is what I've used in silverlight, it's in the silverlight sdk. ~Jimmy Sent from my phone On Dec 15, 2009, at 2:16 AM, "Lukas Cenovsky" wrote: > Michael Foord wrote: >> On 15/12/2009 00:55, Lukas Cenovsky wrote: >>> Hi all, >>> I cannot import codecs module in Silverligh IronPython - it throws >>> NameError for lookup_error method. The reason is this method is >>> not in the _codecs module of Silverlight IronPython: >> >> Yeah, this is a problem that prevents you using simplejson in >> Silverlight as well. :-( >> >> Michael > Yep - I found your message from last month this morning. > The whole browser crashes when I try to import simplejson (after > adding lookup_error to _codecs). > Have you hacked it somehow or do you use something else (Newtonsoft Json.NET > )? > > -- > -- Luk?? > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From cenovsky at bakalari.cz Tue Dec 15 21:10:40 2009 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Tue, 15 Dec 2009 21:10:40 +0100 Subject: [IronPython] codecs module in Silverlight In-Reply-To: References: <4B26DE9D.1080907@bakalari.cz> <4B275EFD.6020201@voidspace.org.uk> <4B2761C0.50809@bakalari.cz> Message-ID: <4B27ED40.2050903@bakalari.cz> Jimmy Schementi wrote: > The whole browser crashes?! That shouldn't be happening; can you open > a bug with a repro of that? > I've created http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25690. -- -- Luk?? From merllab at microsoft.com Wed Dec 16 17:52:47 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Wed, 16 Dec 2009 08:52:47 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <3b10ebc6-bef8-4718-8d95-dc1029eb076b@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/62327. MODIFIED SOURCES $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Math/BigIntegerV2.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Math/BigIntegerV4.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Utils/MathUtils.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/PointerType.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/CFuncPtr.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/_ctypes.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/UnionType.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/SimpleCData.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/CFuncPtrType.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/Array.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/INativeType.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/ModuleOps.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/SimpleType.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/CData.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/ArrayType.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/StructType.cs $/IronPython/IronPython_Main/Src/IronPython/Compiler/GeneratorRewriter.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/LongOps.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/socket.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/math.cs CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1346991 Date: 12/15/2009 11:56:36 AM Fixes _ctypes union support so that it now works. Also fixes _buffer_info API so that it can work (and enables one test which was previously failing). _buffer_info is a little bit odd in that sometimes we need to save the buffer format when a type is created and other times we don?t (the tests cover this). Union is easy ? it just needs the same logic for getting/setting values that structures have. GeneratorRewriter is looking for something which isn?t a DelayedTupleExpression. But we can get back a simple FieldExpression for the LHS and when that happens the cast to BlockExpression fails. So instead we should always test that we have a BlockExpression. (Shelveset: CtypesUnionAndGeneratorFullFramesBugFinal;REDMOND\dinov | SNAP CheckinId: 10020) -------------------------------------------------------------------------------- Changeset Id: 1346865 Date: 12/15/2009 10:24:40 AM Removes some excess methods from BigIntegerV4 that the underlying BigInt does not implement, to help phase out this wrapper: - Moves ToFloat64 and TryToFloat64 into MathUtils as extension methods - Removes the IConvertible interface from BigIntegerV4 Fixes minor bugs in math.cs and socket.cs, and removes dependenies on BigInteger's IConvertible methods. Corrects BigIntegerV2's broken right-shift so we don't have to permute the value in LongOps.RightShift (which is broken given BigIntegerV4's correct behavior). Fixes BigIntegerV4's float and double conversions to overflow properly by adding an implicit BigInteger to double conversion. (Shelveset: BigIntV4;REDMOND\ddicato | SNAP CheckinId: 10019) From fuzzyman at voidspace.org.uk Wed Dec 16 18:31:39 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 16 Dec 2009 17:31:39 +0000 Subject: [IronPython] Chiron and Mono Message-ID: <4B29197B.1010901@voidspace.org.uk> Hello all, Just a warning that Chiron is broken with Mono 2.4.3 and Mono 2.6. It may only happen with large xap files (still to be confirmed) but for us the last working version of Mono is 2.4.2.3. What compression API does Chiron use? I need to report back to the Mono team so that they can fix this... Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From dinov at microsoft.com Wed Dec 16 20:18:23 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 16 Dec 2009 19:18:23 +0000 Subject: [IronPython] IPY and multitasking In-Reply-To: <4AFD202F.4010202@gmail.com> References: <4AFC2844.9000402@gmail.com> <1A472770E042064698CB5ADC83A12ACD04C93119@TK5EX14MBXC118.redmond.corp.microsoft.com> <4AFD202F.4010202@gmail.com> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D9F3FD@TK5EX14MBXC118.redmond.corp.microsoft.com> Sorry for taking so long on getting back to you on this - PDC and Thanksgiving caused this to fall off my radar. I've taken a look at the repro and ultimately the issues come down to the fact that we don't have any kind of module importing lock which is causing things to get imported multiple times. I'm really inclined not to fix this the way CPython has (a big importing lock) for user defined modules as our users want the ability to import these in parallel. But in your case the problem isn't limited to just user defined modules, built in modules are also a problem. Clearly we should make sure each built-in module is only getting loaded once. I also think we should probably have some sort of per-file lock so that each individual .py file will have its own importing be serialized. But anyway I was able to make your program work by modifying IronPythonHelper.CreateScriptEngine so that it will eagerly import The things that it needs and then everything else works by adding this code: var scope = scriptEngine.CreateScope(); scriptEngine.Execute("from utils import Struct", scope); scriptEngine.Execute("import cPickle", scope); scriptEngine.Execute("import copy_reg", scope); I realize you've opened a DLR bug for this but because this is an IronPython bug I've gone ahead and opened an issue in our tracker: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25700 The DLR issue will probably get closed soon. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Pavel Suhotyuk > Sent: Friday, November 13, 2009 1:01 AM > To: Discussion of IronPython > Subject: Re: [IronPython] IPY and multitasking > > I'm prepare simple test for problem demonstration. > http://files.roinet.net/DLRTest.zip > > Module utils imported 6-7 times on 2x Dual-Core Opteron 2216 machine, > but method IronPythonHelper.CreateScript() called one time. On Core 2 > Quad this problem has detected 4 times. On Core 2 Duo problem has not > detected. > > In file out.txt console output with exceptions and logging information. > > Dino Viehland wrote: > > You're only using 1 ScriptEngine class? That should be fine based upon > > the code below but I just want to make sure I understand the scenario. > > > > Is citypay.utils being ran multiple times when you run the code in the > > multi-threaded scenario? If you have a console app you could put a > > print statement in utils.py to see if it's getting executed multiple > > times. If it's not a console app you could put some other logging > > into it. Executing Struct's definition multiple times might cause > > the exceptions you're seeing but I don't know why it would get executed > > multiple times. > > > > _______________________________________________ > > 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 ivan at flanders.co.nz Wed Dec 16 21:44:35 2009 From: ivan at flanders.co.nz (Ivan Porto Carrero) Date: Wed, 16 Dec 2009 21:44:35 +0100 Subject: [IronPython] Chiron and Mono In-Reply-To: <4B29197B.1010901@voidspace.org.uk> References: <4B29197B.1010901@voidspace.org.uk> Message-ID: Michael it uses System.IO.Compression stuff and a class to create zip files. I'll submit the bug to mono no sweat. I was called away earlier. It happens with small xap files too. --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Blog: http://flanders.co.nz Google Wave: portocarrero.ivan at googlewave.com Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) On Wed, Dec 16, 2009 at 6:31 PM, Michael Foord wrote: > Hello all, > > Just a warning that Chiron is broken with Mono 2.4.3 and Mono 2.6. It may > only happen with large xap files (still to be confirmed) but for us the last > working version of Mono is 2.4.2.3. > > What compression API does Chiron use? I need to report back to the Mono > team so that they can fix this... > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > 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 theller at ctypes.org Thu Dec 17 10:13:14 2009 From: theller at ctypes.org (Thomas Heller) Date: Thu, 17 Dec 2009 10:13:14 +0100 Subject: [IronPython] Disappointed Message-ID: <4B29F62A.1060903@ctypes.org> I was excited to see that the latest IronPython release contains ctypes, so I was tempted to try it out. This is the first time I use IronPython. However, soon came frustration. ctypes.wintypes is missing, copying the Python 2.6 ctypes\wintypes.py into place doesn't make it work either: c:\>ipy -c "import ctypes.wintypes" Traceback (most recent call last): File "", line 1, in File "c:\Programme\IronPython 2.6\Lib\ctypes\wintypes.py", line 23, in c:\Programme\IronPython 2.6\Lib\ctypes\wintypes.py NotImplementedError: simple type v c:\> The same NotImplementedError is raised when I try to import comtypes, which uses this code: class BSTR(_SimpleCData): "The windows BSTR data type" _type_ = "X" ... Ok. Gave up trying out ctypes. Tried to run other scripts that I have written. Snippet from that: """ import _winreg def QueryValue(hkey, valuename, default=0): if hkey is None: return default try: return _winreg.QueryValue(hkey, valuename) except WindowsError, detail: if detail.errno == 2: return default raise """ Doesn't work either. WindowsError is raised, but detail.errno is None, detail.winerror also. Is there any chance of running a working, nontrivial CPython program with IronPython? Are the above problems oversights? Missing features? -- Thanks, Thomas From fuzzyman at voidspace.org.uk Thu Dec 17 11:38:20 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 17 Dec 2009 10:38:20 +0000 Subject: [IronPython] Chiron and Mono In-Reply-To: References: <4B29197B.1010901@voidspace.org.uk> Message-ID: <4B2A0A1C.3030002@voidspace.org.uk> On 16/12/2009 20:44, Ivan Porto Carrero wrote: > Michael it uses System.IO.Compression stuff and a class to create zip > files. Cool. The Mono guys have already fixed the problem in SVN. :-) All the best, Michael > I'll submit the bug to mono no sweat. > I was called away earlier. > > > It happens with small xap files too. > --- > Met vriendelijke groeten - Best regards - Salutations > Ivan Porto Carrero > Blog: http://flanders.co.nz > Google Wave: portocarrero.ivan at googlewave.com > > Twitter: http://twitter.com/casualjim > Author of IronRuby in Action (http://manning.com/carrero) > > > > On Wed, Dec 16, 2009 at 6:31 PM, Michael Foord > > wrote: > > Hello all, > > Just a warning that Chiron is broken with Mono 2.4.3 and Mono 2.6. > It may only happen with large xap files (still to be confirmed) > but for us the last working version of Mono is 2.4.2.3. > > What compression API does Chiron use? I need to report back to the > Mono team so that they can fix this... > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > 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 > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From Justin.Perez at energytransfer.com Thu Dec 17 17:10:01 2009 From: Justin.Perez at energytransfer.com (Perez, Justin) Date: Thu, 17 Dec 2009 10:10:01 -0600 Subject: [IronPython] Users Digest, Vol 65, Issue 24 References: Message-ID: <5D89E1EA57432748ADF38D7724384892011356E4@SANxchg01.etc.lan> Hello all, I have been following the mailing list quite vigorously and have learned much. I work with python in Geographic Information Systems. I poked around Shri Borde's example of using IronPython to work with Excel. I have the need to go through a directory and convert each .dbf file to a .csv file. I am thinking this may be a good intro into IronPython to do this. However, I am needing to get the solution quickly as this is just the last part of my code (mostly dealing with geo processing code). Does anyone have an idea as to how quickly I could get this running. Otherwise I am thinking to use the win32all module and hopefully that will be painless for a newcomer like myself. Is IronPython ready to be used in this context? Thanks. Justin Perez Energy Transfer Houston Pipeline Integrity GIS 281.714.2382 -----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: Wednesday, December 16, 2009 3:08 PM To: users at lists.ironpython.com Subject: Users Digest, Vol 65, Issue 24 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. IronPython 2.6 CodePlex Source Update (merllab at microsoft.com) 2. Chiron and Mono (Michael Foord) 3. Re: IPY and multitasking (Dino Viehland) 4. Re: Chiron and Mono (Ivan Porto Carrero) ---------------------------------------------------------------------- Message: 1 Date: Wed, 16 Dec 2009 08:52:47 -0800 From: To: Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <3b10ebc6-bef8-4718-8d95-dc1029eb076b at tk5-exsmh-c101.redmond.corp.micros oft.com> Content-Type: text/plain; charset="utf-8" This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/62327. MODIFIED SOURCES $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Math/BigInteg erV2.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Math/BigInteg erV4.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Utils/MathUti ls.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/PointerType. cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/CFuncPtr.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/_ctypes.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/UnionType.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/SimpleCData. cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/CFuncPtrType .cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/Array.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/INativeType. cs $/IronPython/IronPython_Main/Src/IronPython.Modules/ModuleOps.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/SimpleType.c s $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/CData.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/ArrayType.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/StructType.c s $/IronPython/IronPython_Main/Src/IronPython/Compiler/GeneratorRewriter.c s $/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/LongOps.c s $/IronPython/IronPython_Main/Src/IronPython.Modules/socket.cs $/IronPython/IronPython_Main/Src/IronPython.Modules/math.cs CHECKIN COMMENTS ------------------------------------------------------------------------ -------- Changeset Id: 1346991 Date: 12/15/2009 11:56:36 AM Fixes _ctypes union support so that it now works. Also fixes _buffer_info API so that it can work (and enables one test which was previously failing). _buffer_info is a little bit odd in that sometimes we need to save the buffer format when a type is created and other times we don?t (the tests cover this). Union is easy ? it just needs the same logic for getting/setting values that structures have. GeneratorRewriter is looking for something which isn?t a DelayedTupleExpression. But we can get back a simple FieldExpression for the LHS and when that happens the cast to BlockExpression fails. So instead we should always test that we have a BlockExpression. (Shelveset: CtypesUnionAndGeneratorFullFramesBugFinal;REDMOND\dinov | SNAP CheckinId: 10020) ------------------------------------------------------------------------ -------- Changeset Id: 1346865 Date: 12/15/2009 10:24:40 AM Removes some excess methods from BigIntegerV4 that the underlying BigInt does not implement, to help phase out this wrapper: - Moves ToFloat64 and TryToFloat64 into MathUtils as extension methods - Removes the IConvertible interface from BigIntegerV4 Fixes minor bugs in math.cs and socket.cs, and removes dependenies on BigInteger's IConvertible methods. Corrects BigIntegerV2's broken right-shift so we don't have to permute the value in LongOps.RightShift (which is broken given BigIntegerV4's correct behavior). Fixes BigIntegerV4's float and double conversions to overflow properly by adding an implicit BigInteger to double conversion. (Shelveset: BigIntV4;REDMOND\ddicato | SNAP CheckinId: 10019) ------------------------------ Message: 2 Date: Wed, 16 Dec 2009 17:31:39 +0000 From: Michael Foord To: Discussion of IronPython Subject: [IronPython] Chiron and Mono Message-ID: <4B29197B.1010901 at voidspace.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello all, Just a warning that Chiron is broken with Mono 2.4.3 and Mono 2.6. It may only happen with large xap files (still to be confirmed) but for us the last working version of Mono is 2.4.2.3. What compression API does Chiron use? I need to report back to the Mono team so that they can fix this... Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ------------------------------ Message: 3 Date: Wed, 16 Dec 2009 19:18:23 +0000 From: Dino Viehland To: Discussion of IronPython Subject: Re: [IronPython] IPY and multitasking Message-ID: <1A472770E042064698CB5ADC83A12ACD04D9F3FD at TK5EX14MBXC118.redmond.corp.mi crosoft.com> Content-Type: text/plain; charset="us-ascii" Sorry for taking so long on getting back to you on this - PDC and Thanksgiving caused this to fall off my radar. I've taken a look at the repro and ultimately the issues come down to the fact that we don't have any kind of module importing lock which is causing things to get imported multiple times. I'm really inclined not to fix this the way CPython has (a big importing lock) for user defined modules as our users want the ability to import these in parallel. But in your case the problem isn't limited to just user defined modules, built in modules are also a problem. Clearly we should make sure each built-in module is only getting loaded once. I also think we should probably have some sort of per-file lock so that each individual .py file will have its own importing be serialized. But anyway I was able to make your program work by modifying IronPythonHelper.CreateScriptEngine so that it will eagerly import The things that it needs and then everything else works by adding this code: var scope = scriptEngine.CreateScope(); scriptEngine.Execute("from utils import Struct", scope); scriptEngine.Execute("import cPickle", scope); scriptEngine.Execute("import copy_reg", scope); I realize you've opened a DLR bug for this but because this is an IronPython bug I've gone ahead and opened an issue in our tracker: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25700 The DLR issue will probably get closed soon. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Pavel Suhotyuk > Sent: Friday, November 13, 2009 1:01 AM > To: Discussion of IronPython > Subject: Re: [IronPython] IPY and multitasking > > I'm prepare simple test for problem demonstration. > http://files.roinet.net/DLRTest.zip > > Module utils imported 6-7 times on 2x Dual-Core Opteron 2216 machine, > but method IronPythonHelper.CreateScript() called one time. On Core 2 > Quad this problem has detected 4 times. On Core 2 Duo problem has not > detected. > > In file out.txt console output with exceptions and logging information. > > Dino Viehland wrote: > > You're only using 1 ScriptEngine class? That should be fine based upon > > the code below but I just want to make sure I understand the scenario. > > > > Is citypay.utils being ran multiple times when you run the code in the > > multi-threaded scenario? If you have a console app you could put a > > print statement in utils.py to see if it's getting executed multiple > > times. If it's not a console app you could put some other logging > > into it. Executing Struct's definition multiple times might cause > > the exceptions you're seeing but I don't know why it would get executed > > multiple times. > > > > _______________________________________________ > > 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 ------------------------------ Message: 4 Date: Wed, 16 Dec 2009 21:44:35 +0100 From: Ivan Porto Carrero To: Discussion of IronPython Cc: ironruby-core Subject: Re: [IronPython] Chiron and Mono Message-ID: Content-Type: text/plain; charset="utf-8" Michael it uses System.IO.Compression stuff and a class to create zip files. I'll submit the bug to mono no sweat. I was called away earlier. It happens with small xap files too. --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Blog: http://flanders.co.nz Google Wave: portocarrero.ivan at googlewave.com Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) On Wed, Dec 16, 2009 at 6:31 PM, Michael Foord wrote: > Hello all, > > Just a warning that Chiron is broken with Mono 2.4.3 and Mono 2.6. It may > only happen with large xap files (still to be confirmed) but for us the last > working version of Mono is 2.4.2.3. > > What compression API does Chiron use? I need to report back to the Mono > team so that they can fix this... > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > 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: ------------------------------ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com End of Users Digest, Vol 65, Issue 24 ************************************* From cenovsky at bakalari.cz Thu Dec 17 17:36:23 2009 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Thu, 17 Dec 2009 17:36:23 +0100 Subject: [IronPython] Users Digest, Vol 65, Issue 24 In-Reply-To: <5D89E1EA57432748ADF38D7724384892011356E4@SANxchg01.etc.lan> References: <5D89E1EA57432748ADF38D7724384892011356E4@SANxchg01.etc.lan> Message-ID: <4B2A5E07.3070308@bakalari.cz> Perez, Justin wrote: > Hello all, > > I have been following the mailing list quite vigorously and have learned > much. I work with python in Geographic Information Systems. I poked > around Shri Borde's example of using IronPython to work with Excel. I > have the need to go through a directory and convert each .dbf file to a > .csv file. I am thinking this may be a good intro into IronPython to do > this. However, I am needing to get the solution quickly as this is just > the last part of my code (mostly dealing with geo processing code). > Does anyone have an idea as to how quickly I could get this running. > Otherwise I am thinking to use the win32all module and hopefully that > will be painless for a newcomer like myself. Is IronPython ready to be > used in this context? Thanks. > > Justin Perez > Energy Transfer > Houston > Pipeline Integrity GIS > 281.714.2382 > I would go with System.Data.OleDb: con = System.Data.OleDb.OleDbConnection("Provider=vfpoledb;Data Source=") The con is then standard connection object and you use it as it was SQL. The file name without extension is name of the table. If you need info about the structure, just execute command 'select * from table' and then check reader.GetSchemaTable() -- -- Luk?? From dinov at microsoft.com Thu Dec 17 18:51:17 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 17 Dec 2009 17:51:17 +0000 Subject: [IronPython] Disappointed In-Reply-To: <4B29F62A.1060903@ctypes.org> References: <4B29F62A.1060903@ctypes.org> Message-ID: <1A472770E042064698CB5ADC83A12ACD04DA8EB7@TK5EX14MBXC118.redmond.corp.microsoft.com> I've opened bugs for both of these issues: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25708 http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25709 These are both just oversights. The tests for ctypes and winreg both aren't exhaustive so the more real world use cases and tests we can get to throw at these the better they'll get over time. As for a non-trivial working program it certainly is possible. But Python and its libraries are large and sometimes it requires some iteration to either fix bugs in IronPython or make changes to the program for things like Unicode-only strings. We do try to be extremely responsive on fixing bugs that block real world programs from working unmodified. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Thomas Heller > Sent: Thursday, December 17, 2009 1:13 AM > To: Discussion of IronPython > Subject: [IronPython] Disappointed > > I was excited to see that the latest IronPython release contains > ctypes, so I was > tempted to try it out. This is the first time I use IronPython. > > However, soon came frustration. > > ctypes.wintypes is missing, copying the Python 2.6 ctypes\wintypes.py > into place > doesn't make it work either: > > c:\>ipy -c "import ctypes.wintypes" > Traceback (most recent call last): > File "", line 1, in > File "c:\Programme\IronPython 2.6\Lib\ctypes\wintypes.py", line 23, > in c:\Programme\IronPython 2.6\Lib\ctypes\wintypes.py > NotImplementedError: simple type v > c:\> > > The same NotImplementedError is raised when I try to import comtypes, > which uses this code: > > class BSTR(_SimpleCData): > "The windows BSTR data type" > _type_ = "X" > ... > > Ok. Gave up trying out ctypes. Tried to run other scripts that I have > written. Snippet from that: > > """ > import _winreg > > def QueryValue(hkey, valuename, default=0): > if hkey is None: > return default > try: > return _winreg.QueryValue(hkey, valuename) > except WindowsError, detail: > if detail.errno == 2: > return default > raise > """ > > Doesn't work either. WindowsError is raised, but detail.errno is None, > detail.winerror also. > > > Is there any chance of running a working, nontrivial CPython program > with > IronPython? > > Are the above problems oversights? Missing features? > > -- > Thanks, > Thomas > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From vernondcole at gmail.com Thu Dec 17 20:05:31 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Thu, 17 Dec 2009 12:05:31 -0700 Subject: [IronPython] x = unicode(someExtendedUnicodeString) fails. Message-ID: I just tripped over this one and it took some time to figure out what in blazes was going on. You may want to watch for it when porting CPython code. I was cleaning up an input argument using s = unicode(S.strip().upper()) where S is the argument supplying the value I need to convert. When I handed the function a genuine unicode string, such as in: assert Roman(u'\u217b') == 12 #unicode Roman number 'xii' as a single charactor IronPython complains with: UnicodeEncodeError: ('unknown', '\x00', 0, 1, '') The Python manual says: > If no optional parameters are given, unicode() will mimic the behaviour of > str() except that it returns Unicode strings instead of 8-bit strings. > More precisely, if *object* is a Unicode string or subclass it will return > that Unicode string without any additional decoding applied. It turns out that this was already reported on codeplex as: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=15372 but the reporting party did not catch the fact that he had located an incompatibility with documented behavior. It has been setting on a back burner for some time. Others may want to join me in voting this up. Meanwhile I will add an unneeded exception handler to my own code. -- Vernon Cole -------------- next part -------------- An HTML attachment was scrubbed... URL: From theller at ctypes.org Thu Dec 17 20:17:02 2009 From: theller at ctypes.org (Thomas Heller) Date: Thu, 17 Dec 2009 20:17:02 +0100 Subject: [IronPython] Disappointed In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04DA8EB7@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <4B29F62A.1060903@ctypes.org> <1A472770E042064698CB5ADC83A12ACD04DA8EB7@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <4B2A83AE.8070007@ctypes.org> Am 17.12.2009 18:51, schrieb Dino Viehland: > I've opened bugs for both of these issues: > > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25708 > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25709 > > These are both just oversights. The tests for ctypes and winreg > both aren't exhaustive so the more real world use cases and tests > we can get to throw at these the better they'll get over time. > > As for a non-trivial working program it certainly is possible. But > Python and its libraries are large and sometimes it requires some > iteration to either fix bugs in IronPython or make changes to the > program for things like Unicode-only strings. We do try to be > extremely responsive on fixing bugs that block real world programs > from working unmodified. Ok, great. Then I'll keep reporting unimplemented things that I find. The next one is ctypes.FormatError(code=None). -- Thanks, Thomas From dinov at microsoft.com Thu Dec 17 20:27:28 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 17 Dec 2009 19:27:28 +0000 Subject: [IronPython] x = unicode(someExtendedUnicodeString) fails. In-Reply-To: References: Message-ID: <1A472770E042064698CB5ADC83A12ACD04DA9A9F@TK5EX14MBXC118.redmond.corp.microsoft.com> This is one of those bugs that it's simply not clear that it can be fixed at all. The problem is that we have four different things to try and be compatible with: unicode(some_unicode_string) unicode(some_ascii_string) str(some_unicode_string) str(some_ascii_string) But in IronPython we don't know whether some_*_string is Unicode or ASCII because they're always Unicode. We also don't know if we're calling unicode or str because they're also the same thing. So we have 4 possible behaviors in CPython but there can only be 1 behavior in IronPython. Ultimately we need to pick which behaviors we want to be incompatible with :( Maybe now that we have bytes we should look at changing which one we picked so that if you replace str with bytes we could match CPython. But most likely this problem, and other subtle Unicode issues like it, won't be completely solvable until IronPython 3k. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Vernon Cole Sent: Thursday, December 17, 2009 11:06 AM To: Discussion of IronPython Subject: [IronPython] x = unicode(someExtendedUnicodeString) fails. I just tripped over this one and it took some time to figure out what in blazes was going on. You may want to watch for it when porting CPython code. I was cleaning up an input argument using s = unicode(S.strip().upper()) where S is the argument supplying the value I need to convert. When I handed the function a genuine unicode string, such as in: assert Roman(u'\u217b') == 12 #unicode Roman number 'xii' as a single charactor IronPython complains with: UnicodeEncodeError: ('unknown', '\x00', 0, 1, '') The Python manual says: If no optional parameters are given, unicode() will mimic the behaviour of str() except that it returns Unicode strings instead of 8-bit strings. More precisely, if object is a Unicode string or subclass it will return that Unicode string without any additional decoding applied. It turns out that this was already reported on codeplex as: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=15372 but the reporting party did not catch the fact that he had located an incompatibility with documented behavior. It has been setting on a back burner for some time. Others may want to join me in voting this up. Meanwhile I will add an unneeded exception handler to my own code. -- Vernon Cole -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.kanryu at gmail.com Fri Dec 18 03:29:34 2009 From: k.kanryu at gmail.com (KATO Kanryu) Date: Fri, 18 Dec 2009 11:29:34 +0900 Subject: [IronPython] How to convert from byte[] to str ? Message-ID: Hi, How to convert from byte[] to str without converted ? I'm saveing datas as records to System.Data.SQLite with using cPickle. There are defined pickled data column as 'blob' type. The cPickle.dumps() outputs as str type. When we read 'blob' column as byte[] type. cPickle.loads() gets str type, and I must convert from byte[] to str. Now I call the following: pickled = Encoding.UTF8.GetString(record.data) data = cPickle.loads(pickled) But, GetString sometimes failed :( KATO Kanryu From dinov at microsoft.com Fri Dec 18 03:33:04 2009 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 18 Dec 2009 02:33:04 +0000 Subject: [IronPython] How to convert from byte[] to str ? In-Reply-To: References: Message-ID: <1A472770E042064698CB5ADC83A12ACD283E9061@TK5EX14MBXC118.redmond.corp.microsoft.com> We have helpers in PythonOps called MakeByteArray and MakeString which do the conversion. To use these from Python you can do: import clr clr.AddReference('IronPython') from IronPython.Runtime.Operations import PythonOps pickled = PythonOps.MakeString(record.data) > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of KATO Kanryu > Sent: Thursday, December 17, 2009 6:30 PM > To: Discussion of IronPython > Subject: [IronPython] How to convert from byte[] to str ? > > Hi, > > How to convert from byte[] to str without converted ? > > I'm saveing datas as records to System.Data.SQLite with using cPickle. > There are defined pickled data column as 'blob' type. > The cPickle.dumps() outputs as str type. > When we read 'blob' column as byte[] type. > cPickle.loads() gets str type, and I must convert from byte[] to str. > > Now I call the following: > > pickled = Encoding.UTF8.GetString(record.data) > data = cPickle.loads(pickled) > > But, GetString sometimes failed :( > > > KATO Kanryu > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From k.kanryu at gmail.com Fri Dec 18 03:53:38 2009 From: k.kanryu at gmail.com (KATO Kanryu) Date: Fri, 18 Dec 2009 11:53:38 +0900 Subject: [IronPython] How to convert from byte[] to str ? In-Reply-To: <1A472770E042064698CB5ADC83A12ACD283E9061@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <1A472770E042064698CB5ADC83A12ACD283E9061@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: 2009/12/18 Dino Viehland wrote: > import clr > clr.AddReference('IronPython') > from IronPython.Runtime.Operations import PythonOps > pickled = PythonOps.MakeString(record.data) That's right! Thank you! From simon.segal at bigpond.com Fri Dec 18 04:37:11 2009 From: simon.segal at bigpond.com (Simon Segal) Date: Fri, 18 Dec 2009 14:37:11 +1100 Subject: [IronPython] __clrtype__ and generics Message-ID: I am curious as to how to define a System.Collections.Generic.ICollection as per the below with @clrtype.accepts and @clrtype.returns. Same question goes for _clrfields where I want an ICollection (c#) as a field. @property @clrtype.accepts() @clrtype.returns(ICollection[Order]) def Orders(self): return self._orders @Orders.setter @clrtype.accepts(ICollection[Order]) @clrtype.returns() def Orders(self, value): self._orders = value Thanks, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From cenovsky at bakalari.cz Fri Dec 18 11:00:53 2009 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Fri, 18 Dec 2009 11:00:53 +0100 Subject: [IronPython] __clrtype__ and generics In-Reply-To: References: Message-ID: <4B2B52D5.7090406@bakalari.cz> Hi, I haven't tried your code, but there are currently 2 small issues with clrtype.py I know of: 1. You cannot use iterable for @returns and @accepts - see http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25448 I think your issue is similar. 2. You cannot use Python classes with clrtype.ClrClass metaclass in @accepts and @returns. Both issues can be fixen in validate_clr_types function in clrtype.py. Here is my version: def validate_clr_types(signature_types, var_signature = False): if not isinstance(signature_types, tuple): signature_types = (signature_types,) for t in signature_types: clr_type = clr.GetClrType(t) if t == Void: raise TypeError("Void cannot be used in signature") if clr.GetPythonType(clr_type) != t and \ clr.GetPythonType(clr_type) != clr.GetPythonType(t): raise Exception, "Invalid CLR type %s" % str(t) if not var_signature: if clr_type.IsByRef: raise TypeError("Byref can only be used as arguments and locals") # ArgIterator is not present in Silverlight if hasattr(System, "ArgIterator") and t == System.ArgIterator: raise TypeError("Stack-referencing types can only be used as arguments and locals") -- -- Luk?s( Simon Segal wrote: > I am curious as to how to define a > System.Collections.Generic.ICollection as per the below with > @clrtype.accepts and @clrtype.returns. Same question goes for > _clrfields where I want an ICollection (c#) as a field. > > @property > @clrtype.accepts() > @clrtype.returns(ICollection[Order]) > def Orders(self): return self._orders > > @Orders.setter > @clrtype.accepts(ICollection[Order]) > @clrtype.returns() > def Orders(self, value): self._orders = value > > Thanks, > > Simon > ------------------------------------------------------------------------ > > _______________________________________________ > 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 simon.segal at bigpond.com Fri Dec 18 11:34:57 2009 From: simon.segal at bigpond.com (Simon Segal) Date: Fri, 18 Dec 2009 21:34:57 +1100 Subject: [IronPython] __clrtype__ and generics Message-ID: I am curious as to how to define a System.Collections.Generic. ICollection as per the below with @clrtype.accepts and @clrtype.returns. Same question goes for _clrfields where I want an ICollection (c#) as a field. @property @clrtype.accepts() @clrtype.returns(ICollection[Order]) def Orders(self): return self._orders @Orders.setter @clrtype.accepts(ICollection[Order]) @clrtype.returns() def Orders(self, value): self._orders = value Thanks, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.segal at bigpond.com Fri Dec 18 12:07:07 2009 From: simon.segal at bigpond.com (Simon Segal) Date: Fri, 18 Dec 2009 22:07:07 +1100 Subject: [IronPython] __clrtype__ and generics In-Reply-To: <4B2B52D5.7090406@bakalari.cz> References: <4B2B52D5.7090406@bakalari.cz> Message-ID: Thanks a lot Luk?? that gets me past this issue. On Fri, Dec 18, 2009 at 9:00 PM, Lukas Cenovsky wrote: > Hi, > I haven't tried your code, but there are currently 2 small issues with > clrtype.py I know of: > > 1. You cannot use iterable for @returns and @accepts - see > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25448 I think > your issue is similar. > > 2. You cannot use Python classes with clrtype.ClrClass metaclass in > @accepts and @returns. > > Both issues can be fixen in validate_clr_types function in clrtype.py. Here > is my version: > > def validate_clr_types(signature_types, var_signature = False): > if not isinstance(signature_types, tuple): > signature_types = (signature_types,) > for t in signature_types: > clr_type = clr.GetClrType(t) > if t == Void: > raise TypeError("Void cannot be used in signature") > if clr.GetPythonType(clr_type) != t and \ > clr.GetPythonType(clr_type) != clr.GetPythonType(t): > raise Exception, "Invalid CLR type %s" % str(t) > if not var_signature: > if clr_type.IsByRef: > raise TypeError("Byref can only be used as arguments and > locals") > # ArgIterator is not present in Silverlight > if hasattr(System, "ArgIterator") and t == System.ArgIterator: > raise TypeError("Stack-referencing types can only be used > as arguments and locals") > > -- > -- Luk?? > > Simon Segal wrote: > > I am curious as to how to define a System.Collections.Generic.ICollection > as per the below with @clrtype.accepts and @clrtype.returns. Same question > goes for _clrfields where I want an ICollection (c#) as a field. > > @property > @clrtype.accepts() > @clrtype.returns(ICollection[Order]) > def Orders(self): return self._orders > > @Orders.setter > @clrtype.accepts(ICollection[Order]) > @clrtype.returns() > def Orders(self, value): self._orders = value > > Thanks, > > Simon > > ------------------------------ > > _______________________________________________ > Users mailing listUsers at lists.ironpython.comhttp://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 > > -- Regards, Simon Segal MCSD, MCDBA, MCSE, MCTS - Biztalk Mobile: 0414854913 Email: simon.segal at simonsegal.net Web Site: http://www.simonsegal.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.mcwright at usbfmi.com Fri Dec 18 18:00:59 2009 From: david.mcwright at usbfmi.com (David McWright) Date: Fri, 18 Dec 2009 09:00:59 -0800 (PST) Subject: [IronPython] How to convert from byte[] to str ? In-Reply-To: <1A472770E042064698CB5ADC83A12ACD283E9061@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <1A472770E042064698CB5ADC83A12ACD283E9061@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <1ce4822a-dfa8-4c26-8e16-f576c81836af@k9g2000vbl.googlegroups.com> Dino, Is there somewhere I can find a reference for the other helpers in PythonOps? Thanks, David On Dec 17, 9:33?pm, Dino Viehland wrote: > We have helpers in PythonOps called MakeByteArray and MakeString which > do the conversion. ?To use these from Python you can do: > > import clr > clr.AddReference('IronPython') > from IronPython.Runtime.Operations import PythonOps > pickled = PythonOps.MakeString(record.data) > > > > > -----Original Message----- > > From: users-boun... at lists.ironpython.com [mailto:users- > > boun... at lists.ironpython.com] On Behalf Of KATO Kanryu > > Sent: Thursday, December 17, 2009 6:30 PM > > To: Discussion of IronPython > > Subject: [IronPython] How to convert from byte[] to str ? > > > Hi, > > > How to convert from byte[] to str without converted ? > > > I'm saveing datas as records to System.Data.SQLite with using cPickle. > > There are defined pickled data column as 'blob' type. > > The cPickle.dumps() outputs as str type. > > When we read 'blob' column as byte[] type. > > cPickle.loads() gets str type, and I must convert from byte[] to str. > > > Now I call the following: > > > pickled = Encoding.UTF8.GetString(record.data) > > data = cPickle.loads(pickled) > > > But, GetString sometimes failed :( > > > KATO Kanryu > > _______________________________________________ > > Users mailing list > > Us... at lists.ironpython.com > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com From David.Waller1 at Blueyonder.co.uk Fri Dec 18 18:43:33 2009 From: David.Waller1 at Blueyonder.co.uk (David Waller) Date: Fri, 18 Dec 2009 17:43:33 -0000 Subject: [IronPython] Ironpython 2.6 final and net 4 Message-ID: <003f01ca8009$9f34d060$dd9e7120$@Waller1@Blueyonder.co.uk> Thanks for responding. I am running Vista 32 with all the updates. The value of HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727 for "Install" is 1 David Waller David.Waller1 at Blueyonder.co.uk Date: Tue, 15 Dec 2009 18:10:54 +0000 From: Dino Viehland To: Discussion of IronPython Subject: Re: [IronPython] Ironpython 2.6 final and net 4 Message-ID: <1A472770E042064698CB5ADC83A12ACD04D972C0 at TK5EX14MBXC118.redmond.corp.micros oft.com> Content-Type: text/plain; charset="us-ascii" Can you look at the value in the registry for HKLM\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727 for "Install"? Is it 1? Also is it 64-bit or 32-bit Vista? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David Waller Sent: Tuesday, December 15, 2009 6:58 AM To: users at lists.ironpython.com Subject: Re: [IronPython] Ironpython 2.6 final and net 4 Sorry I wasn't explain enough last time. I am running Vista and already have .NET 3.5 SP1 installed, as well as the current .NET 4. When I try and install the latest Iron python 2.6 final it complains "requires .NET Framework 2.0 SP1 or later. NET 4.0 is not supported". As I am running Vista I can't install .NET 2.0 SP1 as it is already part of Vista. I already have an earlier version of Iron Python 2.6 and this is what it reports when starting up "IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4200" Thanks David Waller Thanks David Waller -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Fri Dec 18 19:05:27 2009 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 18 Dec 2009 18:05:27 +0000 Subject: [IronPython] How to convert from byte[] to str ? In-Reply-To: <1ce4822a-dfa8-4c26-8e16-f576c81836af@k9g2000vbl.googlegroups.com> References: <1A472770E042064698CB5ADC83A12ACD283E9061@TK5EX14MBXC118.redmond.corp.microsoft.com> <1ce4822a-dfa8-4c26-8e16-f576c81836af@k9g2000vbl.googlegroups.com> Message-ID: <1A472770E042064698CB5ADC83A12ACD284304B1@TK5EX14MBXC118.redmond.corp.microsoft.com> The best reference is probably going to be IronPython.xml which contains all of the doc comments pulled out. Other than that there's not really a good reference for these. And unfortunately it's further complicated by the fact that some things in PythonOps are really pretty static and meant are fine for consumption by anyone. Other things are really just calls that we need to emit from generated code and so they need to be somewhere and public. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of David McWright > Sent: Friday, December 18, 2009 9:01 AM > To: users at lists.ironpython.com > Subject: Re: [IronPython] How to convert from byte[] to str ? > > Dino, > Is there somewhere I can find a reference for the other helpers in > PythonOps? > > Thanks, > David > > On Dec 17, 9:33?pm, Dino Viehland wrote: > > We have helpers in PythonOps called MakeByteArray and MakeString which > > do the conversion. ?To use these from Python you can do: > > > > import clr > > clr.AddReference('IronPython') > > from IronPython.Runtime.Operations import PythonOps > > pickled = PythonOps.MakeString(record.data) > > > > > > > > > -----Original Message----- > > > From: users-boun... at lists.ironpython.com [mailto:users- > > > boun... at lists.ironpython.com] On Behalf Of KATO Kanryu > > > Sent: Thursday, December 17, 2009 6:30 PM > > > To: Discussion of IronPython > > > Subject: [IronPython] How to convert from byte[] to str ? > > > > > Hi, > > > > > How to convert from byte[] to str without converted ? > > > > > I'm saveing datas as records to System.Data.SQLite with using cPickle. > > > There are defined pickled data column as 'blob' type. > > > The cPickle.dumps() outputs as str type. > > > When we read 'blob' column as byte[] type. > > > cPickle.loads() gets str type, and I must convert from byte[] to str. > > > > > Now I call the following: > > > > > pickled = Encoding.UTF8.GetString(record.data) > > > data = cPickle.loads(pickled) > > > > > But, GetString sometimes failed :( > > > > > KATO Kanryu > > > _______________________________________________ > > > Users mailing list > > > Us... at lists.ironpython.com > > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > > Users mailing list > > Us... at lists.ironpython.comhttp://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 idan at cloudshare.com Sun Dec 20 07:20:16 2009 From: idan at cloudshare.com (Idan Zaltzberg) Date: Sun, 20 Dec 2009 08:20:16 +0200 Subject: [IronPython] Timer constructor fails on float Message-ID: <009701ca813c$7fb4d9e0$7f1e8da0$@com> Hi, I recently encountered a problem when creating timers. It seems that creating a timer with a floating point interval or delay throws an exception: >>> def _callback(n): pass ... >>> timer = System.Threading.Timer(_callback, None, 100, 0) # Works fine >>> timer = System.Threading.Timer(_callback, None, 100.1, 0) # Throws exception Traceback (most recent call last): File "", line 1, in TypeError: expected TimerCallback, got function How can I solve this? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From idan at cloudshare.com Sun Dec 20 11:56:42 2009 From: idan at cloudshare.com (Idan Zaltzberg) Date: Sun, 20 Dec 2009 12:56:42 +0200 Subject: [IronPython] Bug in Ipy 2.6 when pickling exceptions Message-ID: <000601ca8163$1ebd0550$5c370ff0$@com> Hi, I'm using IronPython 2.6 final. When deriving from Exception class, and creating a constructor with a different signature (not 1 argument), I get an exception when pickling and unpickling. Seems like the pickling process "neglects" some of the information so the unpickling fails. This can be reproduced with: >>> class my_exc(Exception): ... def __init__(self, message, param): ... super(my_exc, self).__init__(message) ... self.param = param ... >>> e = my_exc('message','param') >>> import pickle >>> pickle.loads(pickle.dumps(e)) Traceback (most recent call last): File "", line 1, in File "C:\Systems\3rd_party\IronPython\2.6\Lib\pickle.py", line 1374, in loads File "C:\Systems\3rd_party\IronPython\2.6\Lib\pickle.py", line 858, in load File "C:\Systems\3rd_party\IronPython\2.6\Lib\pickle.py", line 1133, in load_reduce TypeError: __init__() takes exactly 3 arguments (2 given) Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Sun Dec 20 20:31:18 2009 From: dinov at microsoft.com (Dino Viehland) Date: Sun, 20 Dec 2009 19:31:18 +0000 Subject: [IronPython] Timer constructor fails on float In-Reply-To: <009701ca813c$7fb4d9e0$7f1e8da0$@com> References: <009701ca813c$7fb4d9e0$7f1e8da0$@com> Message-ID: <1A472770E042064698CB5ADC83A12ACD28466C87@TK5EX14MBXC118.redmond.corp.microsoft.com> There's no overload that takes a float - just overloads that take int, int64, and uint32 and TimeSpan objects. Because there are multiple numeric types we can't pick which one is better to call - we lose precision either way. I would recommend: timer = System.Threading.Timer(_callback, None, int(100.1), 0) # Throws exception From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Idan Zaltzberg Sent: Saturday, December 19, 2009 10:20 PM To: users at lists.ironpython.com Subject: [IronPython] Timer constructor fails on float Hi, I recently encountered a problem when creating timers. It seems that creating a timer with a floating point interval or delay throws an exception: >>> def _callback(n): pass ... >>> timer = System.Threading.Timer(_callback, None, 100, 0) # Works fine >>> timer = System.Threading.Timer(_callback, None, 100.1, 0) # Throws exception Traceback (most recent call last): File "", line 1, in TypeError: expected TimerCallback, got function How can I solve this? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Sun Dec 20 20:44:25 2009 From: dinov at microsoft.com (Dino Viehland) Date: Sun, 20 Dec 2009 19:44:25 +0000 Subject: [IronPython] Bug in Ipy 2.6 when pickling exceptions In-Reply-To: <000601ca8163$1ebd0550$5c370ff0$@com> References: <000601ca8163$1ebd0550$5c370ff0$@com> Message-ID: <1A472770E042064698CB5ADC83A12ACD28466DCD@TK5EX14MBXC118.redmond.corp.microsoft.com> CPython does the exact same thing: Python 2.6.3 (r263rc1:75186, Oct 2 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class my_exc(Exception): ... def __init__(self, message, param): ... super(my_exc, self).__init__(message) ... self.param = param ... >>> >>> e = my_exc('message','param') >>> import pickle >>> pickle.loads(pickle.dumps(e)) Traceback (most recent call last): File "", line 1, in File "C:\Python26\lib\pickle.py", line 1374, in loads return Unpickler(file).load() File "C:\Python26\lib\pickle.py", line 858, in load dispatch[key](self) File "C:\Python26\lib\pickle.py", line 1133, in load_reduce value = func(*args) TypeError: __init__() takes exactly 3 arguments (2 given) >>> You can override __reduce_ex__ so that it'll match up with your __init__ method: class my_exc(Exception): def __init__(self, message, param): super(my_exc, self).__init__(message) self.param = param def __reduce_ex__(self, protocol): return (my_exc, (self.message, self.param)) e = my_exc('message','param') import pickle pickle.loads(pickle.dumps(e)) It looks like you should be able to just override __reduce__ but it looks like IronPython calls __reduce_ex__ where CPython calls __reduce__ for some reason. I've filed that as bug 25731 http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=25731 From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Idan Zaltzberg Sent: Sunday, December 20, 2009 2:57 AM To: users at lists.ironpython.com Subject: [IronPython] Bug in Ipy 2.6 when pickling exceptions Hi, I'm using IronPython 2.6 final. When deriving from Exception class, and creating a constructor with a different signature (not 1 argument), I get an exception when pickling and unpickling. Seems like the pickling process "neglects" some of the information so the unpickling fails. This can be reproduced with: >>> class my_exc(Exception): ... def __init__(self, message, param): ... super(my_exc, self).__init__(message) ... self.param = param ... >>> e = my_exc('message','param') >>> import pickle >>> pickle.loads(pickle.dumps(e)) Traceback (most recent call last): File "", line 1, in File "C:\Systems\3rd_party\IronPython\2.6\Lib\pickle.py", line 1374, in loads File "C:\Systems\3rd_party\IronPython\2.6\Lib\pickle.py", line 858, in load File "C:\Systems\3rd_party\IronPython\2.6\Lib\pickle.py", line 1133, in load_reduce TypeError: __init__() takes exactly 3 arguments (2 given) Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Tue Dec 22 05:59:34 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 21 Dec 2009 21:59:34 -0700 Subject: [IronPython] LINQ from IronPython Message-ID: This is one of those things that I've been pondering for a while, so I thougt I'd throw it out there and see what everyone else thinks (I fully expect to hear that I'm crazy...). I'd like to be able to query an existing data model (Entity Framework in this case, but that's not important) from IronPython without pulling all of the data to the client. By my read there are two necessary things and one nice-to-have to enable this. This is just a bunch of random thoughts about how to get LINQ support into IronPython; I know nothing about the details of the IronPython compiler, so I'm making no assumptions about the difficulty of any of this. Extension Methods -- The biggest hurdle (but probably the most fruitful) is enabling extension methods. Unfortunately, I don't know enough about how IronPython looks up methods on .NET classes to know how easy this is, so I'll just ramble about possible syntaxes and assume the lookups will work. The first option is identical to C#: from System import Linq # or... import System.Linq Either form pulls in all extension methods in all public, static types in that namespace. The second option is similar to C#, but requires knowing the extension class as well: from System.Linq import Queryable This form would only pull in extension methods defined in the Queryable class. I prefer the second option over the first ('explicit is better than implicit'), but both have problems in not being completely clear what is happening. Another option is to be completely explicit: clr.Extend(myObj, System.Linq.Queryable) It's nice and explicit about what is happening, but could get tedious quickly. Expression Trees (C# lambdas) -- Trying to do Queryable.Where(entities.Customers, lambda c: c.Id % 2 == 0)) gives (not surprisingly) The type arguments for method 'Where' cannot be inferred from the usage. Putting in the generic argument manually Queryable.Where[Customer](entities.Customers, lambda c: c.Id % 2 == 0)) I get (again, not surprisingly) `expected Expression[Func[Course, int, bool]], got function` So, at the very least lambdas would have to be convertible to Expression<> objects. I know the DLR uses expression trees internally, but I don't know if they're available at the proper time for that conversion to be possible. The type inference doesn't seem anymore difficult than what's already done, but who knows... Generator Expressions as LINQ exprssions -- With extension methods and expression trees, the Q in LINQ is handled; now the LIN ('Language INtegrated') needs to be filled in. Most of the LINQ queries I do are of the form: from customer in entities.Customers where customer.Name == name select customer This just so happens to look a lot like customer for customer in entities.Customers if customer.Name == name i.e. a generator expression. Generator expressions and LINQ queries have a lot in common - chief amongst them is that they're both lazy. Would it be possible, if `entities.Customers ` implements IQueryable, for a generator expression to be converted into a LINQ query? Would it even be desirable? The alternative is entities.Customers.Where(lambda c: c.Name == name) which is perfectly fine, but something more would be nice. -- One thing all of this is that it doesn't change the syntax of Python at all, just the semantics. I'm not sure if that's good or bad, though. Thoughts? - Jeff From empirebuilder at gmail.com Tue Dec 22 18:11:28 2009 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 22 Dec 2009 19:11:28 +0200 Subject: [IronPython] LINQ from IronPython In-Reply-To: References: Message-ID: <8cd017b80912220911n90043afkc5eba1f726ef2f76@mail.gmail.com> I am not well averse with generator expression, but I think it will have problem supporting the 9 keywords in LINQ Query Comprehension Syntax so sticking to extension methods would make more sense. C# LINQ Query comprehension is purely syntactic ( http://blogs.msdn.com/ericlippert/archive/2009/12/07/query-transformations-are-syntactic.aspx ), On Tue, Dec 22, 2009 at 6:59 AM, Jeff Hardy wrote: > This is one of those things that I've been pondering for a while, so I > thougt I'd throw it out there and see what everyone else thinks (I > fully expect to hear that I'm crazy...). I'd like to be able to query > an existing data model (Entity Framework in this case, but that's not > important) from IronPython without pulling all of the data to the > client. By my read there are two necessary things and one nice-to-have > to enable this. > > This is just a bunch of random thoughts about how to get LINQ support > into IronPython; I know nothing about the details of the IronPython > compiler, so I'm making no assumptions about the difficulty of any of > this. > > Extension Methods > -- > The biggest hurdle (but probably the most fruitful) is enabling > extension methods. Unfortunately, I don't know enough about how > IronPython looks up methods on .NET classes to know how easy this is, > so I'll just ramble about possible syntaxes and assume the lookups > will work. > > The first option is identical to C#: > from System import Linq # or... > import System.Linq > > Either form pulls in all extension methods in all public, static types > in that namespace. > > The second option is similar to C#, but requires knowing the extension > class as well: > from System.Linq import Queryable > > This form would only pull in extension methods defined in the Queryable > class. > > I prefer the second option over the first ('explicit is better than > implicit'), but both have problems in not being completely clear what > is happening. > > Another option is to be completely explicit: > clr.Extend(myObj, System.Linq.Queryable) > > It's nice and explicit about what is happening, but could get tedious > quickly. > > Expression Trees (C# lambdas) > -- > Trying to do > Queryable.Where(entities.Customers, lambda c: c.Id % 2 == 0)) > gives (not surprisingly) > The type arguments for method 'Where' cannot be inferred from the usage. > > Putting in the generic argument manually > Queryable.Where[Customer](entities.Customers, lambda c: c.Id % 2 == 0)) > I get (again, not surprisingly) > `expected Expression[Func[Course, int, bool]], got function` > > So, at the very least lambdas would have to be convertible to > Expression<> objects. I know the DLR uses expression trees internally, > but I don't know if they're available at the proper time for that > conversion to be possible. The type inference doesn't seem anymore > difficult than what's already done, but who knows... > > Generator Expressions as LINQ exprssions > -- > With extension methods and expression trees, the Q in LINQ is handled; > now the LIN ('Language INtegrated') needs to be filled in. > > Most of the LINQ queries I do are of the form: > from customer in entities.Customers > where customer.Name == name > select customer > > This just so happens to look a lot like > customer for customer in entities.Customers if customer.Name == name > > i.e. a generator expression. > > Generator expressions and LINQ queries have a lot in common - chief > amongst them is that they're both lazy. Would it be possible, if > `entities.Customers ` implements IQueryable, for a generator > expression to be converted into a LINQ query? Would it even be > desirable? > > The alternative is > entities.Customers.Where(lambda c: c.Name == name) > > which is perfectly fine, but something more would be nice. > -- > > One thing all of this is that it doesn't change the syntax of Python > at all, just the semantics. I'm not sure if that's good or bad, > though. > > Thoughts? > > - Jeff > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Dec 22 19:49:23 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 22 Dec 2009 18:49:23 +0000 Subject: [IronPython] LINQ from IronPython In-Reply-To: References: Message-ID: <1A472770E042064698CB5ADC83A12ACD284761AA@TK5EX14MBXC118.redmond.corp.microsoft.com> Jeff wrote: > This is one of those things that I've been pondering for a while, so I > thougt I'd throw it out there and see what everyone else thinks (I > fully expect to hear that I'm crazy...). I'd like to be able to query > an existing data model (Entity Framework in this case, but that's not > important) from IronPython without pulling all of the data to the > client. By my read there are two necessary things and one nice-to-have > to enable this. I'd say this is a pretty good write up of the issues and potential solutions. Not really crazy at all. > > This is just a bunch of random thoughts about how to get LINQ support > into IronPython; I know nothing about the details of the IronPython > compiler, so I'm making no assumptions about the difficulty of any of > this. > > Extension Methods > -- > The biggest hurdle (but probably the most fruitful) is enabling > extension methods. Unfortunately, I don't know enough about how > IronPython looks up methods on .NET classes to know how easy this is, > so I'll just ramble about possible syntaxes and assume the lookups > will work. > > The first option is identical to C#: > from System import Linq # or... > import System.Linq > > Either form pulls in all extension methods in all public, static types > in that namespace. > > The second option is similar to C#, but requires knowing the extension > class as well: > from System.Linq import Queryable > > This form would only pull in extension methods defined in the Queryable > class. > > I prefer the second option over the first ('explicit is better than > implicit'), but both have problems in not being completely clear what > is happening. > > Another option is to be completely explicit: > clr.Extend(myObj, System.Linq.Queryable) Personally I like the 2nd option. I think only the 2nd and 3rd are really viable. The one important thing to keep in mind here is that importlib may become the default importer in the future. So any hooks here need to be based off of the processing of what the import machinery brings back - not something buried deep in the import machinery. The 2nd form means we only need to check the type going back vs. it's entire namespace which will be more expensive. The 3rd option could also be done w/o myObj, e.g. you just say bring in this type or namespace. It could also be global (not very nice) or it could be local to the module like the other forms presumably are. >From an implementation perspective the real difficulty here is making our get members be isolated across modules while still enabling sharing of our cached rules. > > It's nice and explicit about what is happening, but could get tedious > quickly. > > Expression Trees (C# lambdas) > -- > Trying to do > Queryable.Where(entities.Customers, lambda c: c.Id % 2 == 0)) > gives (not surprisingly) > The type arguments for method 'Where' cannot be inferred from the > usage. > > Putting in the generic argument manually > Queryable.Where[Customer](entities.Customers, lambda c: c.Id % 2 == > 0)) > I get (again, not surprisingly) > `expected Expression[Func[Course, int, bool]], got function` > > So, at the very least lambdas would have to be convertible to > Expression<> objects. I know the DLR uses expression trees internally, > but I don't know if they're available at the proper time for that > conversion to be possible. The type inference doesn't seem anymore > difficult than what's already done, but who knows... We certainly have the raw AST available to us at all times except for when we've pre-compiled code. We don't expose this directly today just because it's a big implementation detail to bleed out. Exposing a conversion of functions to Experssion though might be a really good way to expose it w/o exposing all of the implementation details. The biggest problem w/ exposing our AST though is can anyone else do something useful with it? If they're just going to compile the AST and run it then that's fine. But if they want to take the AST and send it off to the database as a query things aren't going to work so well at this point simply because they won't recognize the dynamic nodes. There's also some situations where we open code to the dynamic nodes as call sites then things are really confusing. This may be fine for this case where the conversion is explicit and the user can make sure it works. > > Generator Expressions as LINQ exprssions > -- > With extension methods and expression trees, the Q in LINQ is handled; > now the LIN ('Language INtegrated') needs to be filled in. > > Most of the LINQ queries I do are of the form: > from customer in entities.Customers > where customer.Name == name > select customer > > This just so happens to look a lot like > customer for customer in entities.Customers if customer.Name == name > > i.e. a generator expression. > > Generator expressions and LINQ queries have a lot in common - chief > amongst them is that they're both lazy. Would it be possible, if > `entities.Customers ` implements IQueryable, for a generator > expression to be converted into a LINQ query? Would it even be > desirable? > > The alternative is > entities.Customers.Where(lambda c: c.Name == name) > > which is perfectly fine, but something more would be nice. This is actually a really cool idea. But because it'd occur implicitly it has the same problems as the function ASTs do but they might otherwise break working code. Maybe we could try and create another AST with faked out expressions which indicate our intent without specifying exactly how to do it. But the expression trees are really particular about being valid so we'd probably need to know the type of entities first and then infer the types from there. This would probably be the trickiest part. > -- > > One thing all of this is that it doesn't change the syntax of Python > at all, just the semantics. I'm not sure if that's good or bad, > though. > > Thoughts? > > - Jeff > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jdhardy at gmail.com Tue Dec 22 20:51:22 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 22 Dec 2009 12:51:22 -0700 Subject: [IronPython] LINQ from IronPython In-Reply-To: <8cd017b80912220911n90043afkc5eba1f726ef2f76@mail.gmail.com> References: <8cd017b80912220911n90043afkc5eba1f726ef2f76@mail.gmail.com> Message-ID: On Tue, Dec 22, 2009 at 10:11 AM, Dody Gunawinata wrote: > I am not well averse with generator expression, but I think it will have > problem supporting the 9 keywords in LINQ Query Comprehension Syntax so > sticking to extension methods would make more sense. I wouldn't expect support for the whole whack of operators - just the ones that make sense using the syntax for generator expressions. Most of the queries I do are just filtering a set, which genexps are perfectly suited for, and it would be nice if using a genexp on an entity framework set could be executed in the database instead of on the client. All that said, it would just be syntax sugar over the extension methods in the same way that C#'s query expressions are. - Jeff From kfarmer at thuban.org Tue Dec 22 21:54:10 2009 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 22 Dec 2009 12:54:10 -0800 Subject: [IronPython] LINQ from IronPython In-Reply-To: <1A472770E042064698CB5ADC83A12ACD284761AA@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <1A472770E042064698CB5ADC83A12ACD284761AA@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: I greatly prefer the C#-ish import rather than "clr.Extend". Beyond that, explicitly importing the extending class could have benefits that were noted back when LINQ was introduced: it's possible for a single namespace to have conflicting extension methods. The moment there's conflict, you lose the extension method syntax. Therefore, my suggestion is for the second method (and not for the IMHO-abused "explicit better than implicit" reason people give). As for expression trees: I wouldn't expose the DLR's AST. Instead, I would expose the same trees that C# and VB expose. The reason being, of course, is that these would be what mainstream LINQ implementations would target, LINQ to SQL in particular. For the most part, that should be a simple transformation, and could be performed at runtime. That is, implicitly replace a call: MethodExpectingExpressionOfFunc(lambda x: x.Foo + x.Bar) with MethodExpectingExpressionOfFunc(DlrToClrExpressionConverter(lambda x: x.Foo + x.Bar)) .. and not worry about it. If you *do* want to worry about it (ie, you wouldn't want to lose the "this was a dynamic call" knowledge), I could see some sort of pragma to modify that behavior, or an explicit NonLossyDlrExpressionConverter that bypasses implicit expression tree conversion. Let's face it: there are plenty of *static* methods that LINQ to SQL and friends cannot handle, because there is no translation possible to their target. We cannot expect to do any better. But we *can* talk the same dialect of the same language. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, December 22, 2009 10:49 AM To: Discussion of IronPython Subject: Re: [IronPython] LINQ from IronPython Jeff wrote: > Extension Methods Personally I like the 2nd option. I think only the 2nd and 3rd are really viable. The one important thing to keep in mind here is that importlib may become the default importer in the future. So any hooks here need to be based off of the processing of what the import machinery brings back - not something buried deep in the import machinery. The 2nd form means we only need to check the type going back vs. it's entire namespace which will be more expensive. The 3rd option could also be done w/o myObj, e.g. you just say bring in this type or namespace. It could also be global (not very nice) or it could be local to the module like the other forms presumably are. Jeff wrote: > Expression Trees (C# lambdas) We certainly have the raw AST available to us at all times except for when we've pre-compiled code. We don't expose this directly today just because it's a big implementation detail to bleed out. Exposing a conversion of functions to Experssion though might be a really good way to expose it w/o exposing all of the implementation details. The biggest problem w/ exposing our AST though is can anyone else do something useful with it? If they're just going to compile the AST and run it then that's fine. But if they want to take the AST and send it off to the database as a query things aren't going to work so well at this point simply because they won't recognize the dynamic nodes. There's also some situations where we open code to the dynamic nodes as call sites then things are really confusing. This may be fine for this case where the conversion is explicit and the user can make sure it works. From kfarmer at thuban.org Tue Dec 22 21:55:03 2009 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 22 Dec 2009 12:55:03 -0800 Subject: [IronPython] LINQ from IronPython In-Reply-To: References: <8cd017b80912220911n90043afkc5eba1f726ef2f76@mail.gmail.com> Message-ID: Don't forget the ones in VB that C# devs would kill for. Like Distinct :) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Tuesday, December 22, 2009 11:51 AM To: dody at nomadlife.org; Discussion of IronPython Subject: Re: [IronPython] LINQ from IronPython On Tue, Dec 22, 2009 at 10:11 AM, Dody Gunawinata wrote: > I am not well averse with generator expression, but I think it will have > problem supporting the 9 keywords in LINQ Query Comprehension Syntax so > sticking to extension methods would make more sense. I wouldn't expect support for the whole whack of operators - just the ones that make sense using the syntax for generator expressions. Most of the queries I do are just filtering a set, which genexps are perfectly suited for, and it would be nice if using a genexp on an entity framework set could be executed in the database instead of on the client. All that said, it would just be syntax sugar over the extension methods in the same way that C#'s query expressions are. - Jeff _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Tue Dec 22 22:07:58 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 22 Dec 2009 21:07:58 +0000 Subject: [IronPython] LINQ from IronPython In-Reply-To: References: <1A472770E042064698CB5ADC83A12ACD284761AA@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <1A472770E042064698CB5ADC83A12ACD28477059@TK5EX14MBXC118.redmond.corp.microsoft.com> Keith wrote: > I greatly prefer the C#-ish import rather than "clr.Extend". Beyond > that, explicitly importing the extending class could have benefits that > were noted back when LINQ was introduced: it's possible for a single > namespace to have conflicting extension methods. The moment there's > conflict, you lose the extension method syntax. Therefore, my > suggestion is for the second method (and not for the IMHO-abused > "explicit better than implicit" reason people give). > > As for expression trees: I wouldn't expose the DLR's AST. Instead, I > would expose the same trees that C# and VB expose. The reason being, > of course, is that these would be what mainstream LINQ implementations > would target, LINQ to SQL in particular. For the most part, that > should be a simple transformation, and could be performed at runtime. > That is, implicitly replace a call: > > MethodExpectingExpressionOfFunc(lambda x: x.Foo + x.Bar) > > with > > MethodExpectingExpressionOfFunc(DlrToClrExpressionConverter(lambd > a x: x.Foo + x.Bar)) Assuming this is DlrToClrExpressionConverter is converting the expression tree and not a call in the produced expression tree the difficulty is performing the type inference of the expression tree. In this case presumably the conversion to Expression informs us of the type of x. From there we could know that it did indeed have Foo and Bar properties and those were of some addable type. And so we could probably produce a valid expression tree. Not exactly a "simple transformation" but we could probably usually pull it off for code like this. I'm not sure how predictable it would be when we could or couldn't pull it off though. From jdhardy at gmail.com Tue Dec 22 22:24:20 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 22 Dec 2009 14:24:20 -0700 Subject: [IronPython] LINQ from IronPython In-Reply-To: <1A472770E042064698CB5ADC83A12ACD28477059@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <1A472770E042064698CB5ADC83A12ACD284761AA@TK5EX14MBXC118.redmond.corp.microsoft.com> <1A472770E042064698CB5ADC83A12ACD28477059@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: On Tue, Dec 22, 2009 at 2:07 PM, Dino Viehland wrote: > Assuming this is DlrToClrExpressionConverter is converting the expression > tree and not a call in the produced expression tree the difficulty is > performing the type inference of the expression tree. ?In this case > presumably the conversion to Expression informs us of the type of > x. ?From there we could know that it did indeed have Foo and Bar properties > and those were of some addable type. ?And so we could probably produce > a valid expression tree. ?Not exactly a "simple transformation" but > we could probably usually pull it off for code like this. ?I'm not sure > how predictable it would be when we could or couldn't pull it off though. I would guess that most of those lambdas are going to be fairly simple, and hopefully easy to type-infer. For ones that aren't inferable, the best option would be to give an error. Given: id = 1 customers.Where(lambda c: c.Id == id) Would IronPython be able to know that the type of `id` is `int` at the appropriate stage of the compiler? Presumably, because it would have to know the type of `customers` (and thus `c`) to even apply the extension methods. Would it even have to know the type of `id` to construct the proper expression tree, given that it knows the type of `c`? This rabbit hole goes surprisingly deep! No wonder you haven't tackled it yet. - Jeff From dinov at microsoft.com Tue Dec 22 22:39:57 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 22 Dec 2009 21:39:57 +0000 Subject: [IronPython] LINQ from IronPython In-Reply-To: References: <1A472770E042064698CB5ADC83A12ACD284761AA@TK5EX14MBXC118.redmond.corp.microsoft.com> <1A472770E042064698CB5ADC83A12ACD28477059@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <1A472770E042064698CB5ADC83A12ACD284772AE@TK5EX14MBXC118.redmond.corp.microsoft.com> Jeff wrote: > I would guess that most of those lambdas are going to be fairly > simple, and hopefully easy to type-infer. For ones that aren't > inferable, the best option would be to give an error. > > Given: > id = 1 > customers.Where(lambda c: c.Id == id) > > Would IronPython be able to know that the type of `id` is `int` at the > appropriate stage of the compiler? Presumably, because it would have > to know the type of `customers` (and thus `c`) to even apply the > extension methods. Would it even have to know the type of `id` to > construct the proper expression tree, given that it knows the type of > `c`? > > This rabbit hole goes surprisingly deep! No wonder you haven't tackled > it yet. We would know customers when we bind the GetMember and find the extension method. That'd give us a method Where which is actually: Queryable.Where[Customer](IQueryable[Customer], Expression>) Then when we invoke that we would know what we're converting the lambda to and that its signature needs to take a Customer. That's when any type inference over the lambda would kick in. I think our existing type inference would be pretty close to getting that right, we just need to look for Expression in addition to delegate types. So that gives us c.Id's type and you could imagine that we then require the LHS & RHS types for equality to line up. Another option is that we might be able to generate code that looks something like: if (id is int) { return c.Id == (int)id; } else { return Expression.Equal(c.Id, id, PythonOps.EqualRetBool(c.Id, id)); } The equality here is something that might pass over the wire fine as this is a pattern that existed in expression trees V1. All of the dynamic stuff would be hidden in the EqualRetBool call and hopefully we'd just never hit that code path. But even if we did it might just get interpreted as equality instead of a method call. The really interesting thing to me is that this is a closure - either id is in a nested function scope or it's in a global scope. I'm not sure how that gets transmitted across the wire. Do closures work in LINQ in C# going across to a database? From jdhardy at gmail.com Tue Dec 22 23:11:39 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 22 Dec 2009 15:11:39 -0700 Subject: [IronPython] LINQ from IronPython In-Reply-To: <1A472770E042064698CB5ADC83A12ACD284772AE@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <1A472770E042064698CB5ADC83A12ACD284761AA@TK5EX14MBXC118.redmond.corp.microsoft.com> <1A472770E042064698CB5ADC83A12ACD28477059@TK5EX14MBXC118.redmond.corp.microsoft.com> <1A472770E042064698CB5ADC83A12ACD284772AE@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: On Tue, Dec 22, 2009 at 2:39 PM, Dino Viehland wrote: > The really interesting thing to me is that this is a closure - either id is in > a nested function scope or it's in a global scope. ?I'm not sure how that gets > transmitted across the wire. ?Do closures work in LINQ in C# going across to > a database? Yep: int id = 1; var result = customers.Where(c => c.Id == id); would become a parametrized SQL query: SELECT * FROM Customers AS t0 WHERE t0.Id = @p0; where @p0 is the parameter passed along with the query, with the value 1. - Jeff From kfarmer at thuban.org Tue Dec 22 23:22:24 2009 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 22 Dec 2009 14:22:24 -0800 Subject: [IronPython] LINQ from IronPython In-Reply-To: References: <1A472770E042064698CB5ADC83A12ACD284761AA@TK5EX14MBXC118.redmond.corp.microsoft.com><1A472770E042064698CB5ADC83A12ACD28477059@TK5EX14MBXC118.redmond.corp.microsoft.com><1A472770E042064698CB5ADC83A12ACD284772AE@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: Indeed, and Jeff demonstrates. C# would embed such things as constant expressions or variables (as opposed to parameters), and LINQ to SQL knows to pull those in. No problem. As I mentioned, being able to (inasmuch as possible) mimic C# and VB's expression tree output should be the target. Anything arcane, really, need not be supported yet. The goal is compatibility with the more interesting providers, which were developed with those trees in mind. This in itself doesn't preclude EF or LINQ to SQL from gaining dynamic support at a later point (although dynamic typing may), nor would it necessarily preclude being able to emit the dynamic call sites if there's nothing better (in which case, you *could* have DLR-specific APIs that consume more interesting trees). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Tuesday, December 22, 2009 2:12 PM To: Discussion of IronPython Subject: Re: [IronPython] LINQ from IronPython On Tue, Dec 22, 2009 at 2:39 PM, Dino Viehland wrote: > The really interesting thing to me is that this is a closure - either id is in > a nested function scope or it's in a global scope. ?I'm not sure how that gets > transmitted across the wire. ?Do closures work in LINQ in C# going across to > a database? Yep: int id = 1; var result = customers.Where(c => c.Id == id); would become a parametrized SQL query: SELECT * FROM Customers AS t0 WHERE t0.Id = @p0; where @p0 is the parameter passed along with the query, with the value 1. - Jeff _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jdhardy at gmail.com Tue Dec 22 23:23:10 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 22 Dec 2009 15:23:10 -0700 Subject: [IronPython] LINQ from IronPython In-Reply-To: <1A472770E042064698CB5ADC83A12ACD284761AA@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <1A472770E042064698CB5ADC83A12ACD284761AA@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: On Tue, Dec 22, 2009 at 11:49 AM, Dino Viehland wrote: > Personally I like the 2nd option. ?I think only the 2nd and 3rd are > really viable. ?The one important thing to keep in mind here is that > importlib may become the default importer in the future. ?So any hooks > here need to be based off of the processing of what the import machinery > brings back - not something buried deep in the import machinery. ?The 2nd > form means we only need to check the type going back vs. it's entire > namespace which will be more expensive. > > The 3rd option could also be done w/o myObj, e.g. you just say bring > in this type or namespace. ?It could also be global (not very nice) or > it could be local to the module like the other forms presumably are. Sounds like option #2 is the preferred one, so far. I do like the idea of using `clr.ExtendFrom` (or whatever) as a prototype, however, before trying to muck with the import machinery. > We certainly have the raw AST available to us at all times except for > when we've pre-compiled code. ?We don't expose this directly today just > because it's a big implementation detail to bleed out. ?Exposing a > conversion of functions to Experssion though might be a really good > way to expose it w/o exposing all of the implementation details. I think even just lambdas (and, for the IR guys, blocks) would be sufficient, as they are limited to expressions; arbitrary functions are unlikely to be handled by the various LINQ providers out there (per Keith's comment about generating C#-compatible expression trees). > > The biggest problem w/ exposing our AST though is can anyone else do > something useful with it? ?If they're just going to compile the AST > and run it then that's fine. ?But if they want to take the AST and > send it off to the database as a query things aren't going to work > so well at this point simply because they won't recognize the dynamic > nodes. ?There's also some situations where we open code to the dynamic > nodes as call sites then things are really confusing. ?This may > be fine for this case where the conversion is explicit and the user > can make sure it works. I can think of all sorts of uses for being to manipulate the parse tree at compile time; I'm just not sure any of them are good ideas :). Much like C#, supporting a tightly restricted subset of cases is probably the best approach. > This is actually a really cool idea. ?But because it'd occur implicitly > it has the same problems as the function ASTs do but they might otherwise > break working code. If generator expressions (or anything else...) were convertible back to their parse trees, you could have a method in C#: Expression query(GeneratorExpression genexp) { ... } that would re-write the genexp to use LINQ's extension methods instead - basically, an extension point for the IronPython compiler. - Jeff From kfarmer at thuban.org Wed Dec 23 00:19:32 2009 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 22 Dec 2009 15:19:32 -0800 Subject: [IronPython] LINQ from IronPython Message-ID: <005101ca835d$34db9101$080a010a@circlecross.home> Rewrites to use extensions methods need to happen with knowledge of what extensions are available at that instant, and should defer to what's defined on the object in question when possible. Unless carried in the AST, this knowledge wouldn't likely be available to non-DLR environment, so probably best done by the DLR itself, neh? -----Original Message----- From: Jeff Hardy Sent: Tuesday, December 22, 2009 14:23 To: Discussion of IronPython Subject: Re: [IronPython] LINQ from IronPython On Tue, Dec 22, 2009 at 11:49 AM, Dino Viehland wrote: > Personally I like the 2nd option. I think only the 2nd and 3rd are > really viable. The one important thing to keep in mind here is that > importlib may become the default importer in the future. So any hooks > here need to be based off of the processing of what the import machinery > brings back - not something buried deep in the import machinery. The 2nd > form means we only need to check the type going back vs. it's entire > namespace which will be more expensive. > > The 3rd option could also be done w/o myObj, e.g. you just say bring > in this type or namespace. It could also be global (not very nice) or > it could be local to the module like the other forms presumably are. Sounds like option #2 is the preferred one, so far. I do like the idea of using `clr.ExtendFrom` (or whatever) as a prototype, however, before trying to muck with the import machinery. > We certainly have the raw AST available to us at all times except for > when we've pre-compiled code. We don't expose this directly today just > because it's a big implementation detail to bleed out. Exposing a > conversion of functions to Experssion though might be a really good > way to expose it w/o exposing all of the implementation details. I think even just lambdas (and, for the IR guys, blocks) would be sufficient, as they are limited to expressions; arbitrary functions are unlikely to be handled by the various LINQ providers out there (per Keith's comment about generating C#-compatible expression trees). > > The biggest problem w/ exposing our AST though is can anyone else do > something useful with it? If they're just going to compile the AST > and run it then that's fine. But if they want to take the AST and > send it off to the database as a query things aren't going to work > so well at this point simply because they won't recognize the dynamic > nodes. There's also some situations where we open code to the dynamic > nodes as call sites then things are really confusing. This may > be fine for this case where the conversion is explicit and the user > can make sure it works. I can think of all sorts of uses for being to manipulate the parse tree at compile time; I'm just not sure any of them are good ideas :). Much like C#, supporting a tightly restricted subset of cases is probably the best approach. > This is actually a really cool idea. But because it'd occur implicitly > it has the same problems as the function ASTs do but they might otherwise > break working code. If generator expressions (or anything else...) were convertible back to their parse trees, you could have a method in C#: Expression query(GeneratorExpression genexp) { ... } that would re-write the genexp to use LINQ's extension methods instead - basically, an extension point for the IronPython compiler. - Jeff _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jdhardy at gmail.com Wed Dec 23 00:40:23 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 22 Dec 2009 16:40:23 -0700 Subject: [IronPython] LINQ from IronPython In-Reply-To: <005101ca835d$34db9101$080a010a@circlecross.home> References: <005101ca835d$34db9101$080a010a@circlecross.home> Message-ID: On Tue, Dec 22, 2009 at 4:19 PM, Keith J. Farmer wrote: > Rewrites to use extensions methods need to happen with knowledge of what extensions are available at that instant, and should defer to what's defined on the object in question when possible. ?Unless carried in the AST, this knowledge wouldn't likely be available to non-DLR environment, so probably best done by the DLR itself, neh? For the given case (LINQ), it should absolutely be part of the DLR (or IronPython, wherever it fits best). I'm speculating about what it would be like if we could rewrite *any* part of the DLR tree. Any such hypothetical method would have to be closely tied to the DLR, yes, but I *think* that a CodeContext could carry that information. Whether that's a good idea or not is up for debate. - Jeff From fwereade at googlemail.com Wed Dec 23 23:30:58 2009 From: fwereade at googlemail.com (William Reade) Date: Wed, 23 Dec 2009 23:30:58 +0100 Subject: [IronPython] Ironclad v2.6.0rc1 released Message-ID: Hi all I'm very happy to announce the latest release (candidate) of Ironclad, the 120-proof home-brewed CPython compatibility layer, now available for IronPython 2.6! No longer need .NET pythonistas toil thanklessly without the benefits of bz2, csv, numpy and scipy: with a simple 'import ironclad', (most parts of) the above packages -- and many more -- will transparently Just Work. Get the package from: http://code.google.com/p/ironclad/ ...and get support from: http://groups.google.com/group/c-extensions-for-ironpython ...or just ask me directly. I'm very keen to hear your experiences, both positive and negative; I haven't been able to test it on as many machines as I have in the past, so your feedback is especially important this time round*. Cheers William * I'd be especially grateful if someone with a newish multicore machine would run the numpy and scipy test scripts (included in the source distrbution) a few times to check for consistent results and absence of weird crashes; if someone volunteers, I'll help however I can. From marscel at googlemail.com Mon Dec 28 13:22:00 2009 From: marscel at googlemail.com (Marcel Heing-Becker) Date: Mon, 28 Dec 2009 13:22:00 +0100 Subject: [IronPython] Cannot create instances of RuntimeType because it has no public constructors Message-ID: <24b7e04e0912280422n78ae9312y6e5c7a107863e680@mail.gmail.com> Hi there, I have a problem with my application. It's written in C# and embeds IronPython. In C#, I have a class that looks like this: public class foo { public foo() { ... } ... } I put this into the ScriptScope I use by doing: scope.SetVariable("fooclass", typeof(foo)); Operations like: a = fooclass() work without any problem, but the following IronPython does not work and raises the error: Cannot create instances of RuntimeType because it has no public constructors. Code: class bar(foo): def __init__(self): Name = "Unused" def TestFunction(self): return "Juhu!" ObjTileTypeUnused = TileTypeUnused() -------------- next part -------------- An HTML attachment was scrubbed... URL: From marscel at googlemail.com Mon Dec 28 13:36:49 2009 From: marscel at googlemail.com (Marcel Heing-Becker) Date: Mon, 28 Dec 2009 13:36:49 +0100 Subject: [IronPython] (UPDATE) Cannot create instances of RuntimeType because it has no public constructors Message-ID: <24b7e04e0912280436x2474420fm4a61efdb4a7a8c4a@mail.gmail.com> PLEASE IGNORE MY PREVIOUS POST with the same title, I accidentally sent it before I was finished cleaning up the code. Hi there, I have a problem with my application. It's written in C# and embeds IronPython. In C#, I have a class that looks like this: public class foo { public foo() { ... } ... } I put this into the ScriptScope I use by doing: scope.SetVariable("fooclass", typeof(foo)); Operations like: a = fooclass() work without any problem, but the following IronPython does not work and raises the error: Cannot create instances of RuntimeType because it has no public constructors. Code: class bar(fooclass): def __init__(self): Name = "Unused" ... barobject = bar() Well, I can't really say what this is about. Is it a Bug in IP or anything like a limitation? Greetings, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From idan at cloudshare.com Mon Dec 28 17:33:15 2009 From: idan at cloudshare.com (Idan Zaltzberg) Date: Mon, 28 Dec 2009 18:33:15 +0200 Subject: [IronPython] Memory leaks in Ipy 2.6 Message-ID: <023e01ca87db$74fe7060$5efb5120$@com> Hi, Working with the new version I have encountered some problems which look like memory leaks to me. I've written 3 test methods that reproduce the problems, and would appreciate your response. Thanks *Problem 1* Occurs when you do the all of the following 1. Define a generator method 2. Insert a try/except clause in the method 3. define an inner method that uses some local variable 4. Call the generator method without reaching the "StopIteration" Looks like the local variable used by the inner method is never cleared. This code reproduces the problem: def test_generator_memory_leak(self): """ Ipy 2.6 This test reproduces a memory leak when calling a generator method without reaching the end. """ def coroutine(): try: pass except: pass just_numbers = range(1,1000) def inner_method(): return just_numbers yield None yield None from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() for j in xrange(10000): crt = coroutine() crt.next() after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) *Problem 2* The same as problem, just instead of defining an inner method, just call "eval" with any string def test_generator_memory_leak2(self): """ Ipy 2.6 This test reproduces a memory leak when calling a generator method without reaching the end. """ def coroutine(b_bool): try: pass except: pass if False: eval("") just_numbers = range(1,1000) yield None yield None from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() for j in xrange(10000): crt = coroutine(False) crt.next() after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) *Problem 3* This is actually a our solution to problems 1,2. We noticed that if we end the iteration by using "throw" then the memory doesn?t rise on subsequent instances. Still there some memory increase that depends on the size of the local variable which doesn?t seem to go away: def test_generator_memory_leak2(self): """ Ipy 2.6 when exiting a generator method with an exception, some objects are never collected This seems to be static to the type (the leak does not grow if we repeat the experiment """ def coroutine(): just_numbers = range(1,1000000) def inner_method(): return just_numbers yield None raise Exception("some exception") # comment out this line to make the test not work from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() crt = coroutine() try: crt.next() crt.next() except: pass crt = None after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Mon Dec 28 17:56:16 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 28 Dec 2009 08:56:16 -0800 Subject: [IronPython] (UPDATE) Cannot create instances of RuntimeType because it has no public constructors In-Reply-To: <24b7e04e0912280436x2474420fm4a61efdb4a7a8c4a@mail.gmail.com> References: <24b7e04e0912280436x2474420fm4a61efdb4a7a8c4a@mail.gmail.com> Message-ID: "fooclass" is not a Python type. It's an instance of the CLR class System.RuntimeType. In order to derive from "foo" in this fashion, you might be able to turn fooclass into a IronPython.Runtime.Types.PythonType by saying import clr foo = clr.GetPythonType(fooclass) class bar(foo): pass If it's consistent with your security requirements, it would be simpler to simply expose your C# assembly directly to IronPython. You would do this from within the C# code by saying scriptRuntime.LoadAssembly(typeof(foo).Assembly); and then you could say from your Python code from Namespace.Containing.Your.Foo.Class import foo On Mon, Dec 28, 2009 at 4:36 AM, Marcel Heing-Becker wrote: > PLEASE IGNORE MY PREVIOUS POST with the same title, I accidentally sent it > before I was finished cleaning up the code. > > Hi there, > I have a problem with my application. It's written in C# and embeds > IronPython. In C#, I have a class that looks like this: > > public class foo > { > public foo() > { > ... > } > ... > } > > I put this into the ScriptScope I use by doing: > > scope.SetVariable("fooclass", typeof(foo)); > > Operations like: a = fooclass() work without any problem, but the following > IronPython does not work and raises the error: Cannot create instances of > RuntimeType because it has no public constructors. Code: > > class bar(fooclass): > def __init__(self): > Name = "Unused" > ... > > barobject = bar() > > Well, I can't really say what this is about. Is it a Bug in IP or anything > like a limitation? > Greetings, Marcel > > _______________________________________________ > 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 marscel at googlemail.com Mon Dec 28 18:45:03 2009 From: marscel at googlemail.com (Marcel Heing-Becker) Date: Mon, 28 Dec 2009 18:45:03 +0100 Subject: [IronPython] (UPDATE) Cannot create instances of RuntimeType because it has no public constructors In-Reply-To: References: <24b7e04e0912280436x2474420fm4a61efdb4a7a8c4a@mail.gmail.com> Message-ID: <24b7e04e0912280945v43d55c9dufb370f880cdfb9b4@mail.gmail.com> Thanks, this seems to work. This exposes my whole namepsace to IronPython but I think, it seems to be sufficiant to mark classes and types that must stay off this scope with 'internal'. 2009/12/28 Curt Hagenlocher > "fooclass" is not a Python type. It's an instance of the CLR class > System.RuntimeType. In order to derive from "foo" in this fashion, you might > be able to turn fooclass into a IronPython.Runtime.Types.PythonType by > saying > > import clr > foo = clr.GetPythonType(fooclass) > class bar(foo): > pass > > If it's consistent with your security requirements, it would be simpler to > simply expose your C# assembly directly to IronPython. You would do this > from within the C# code by saying > > scriptRuntime.LoadAssembly(typeof(foo).Assembly); > > and then you could say from your Python code > > from Namespace.Containing.Your.Foo.Class import foo > > On Mon, Dec 28, 2009 at 4:36 AM, Marcel Heing-Becker < > marscel at googlemail.com> wrote: > >> PLEASE IGNORE MY PREVIOUS POST with the same title, I accidentally sent it >> before I was finished cleaning up the code. >> >> Hi there, >> I have a problem with my application. It's written in C# and embeds >> IronPython. In C#, I have a class that looks like this: >> >> public class foo >> { >> public foo() >> { >> ... >> } >> ... >> } >> >> I put this into the ScriptScope I use by doing: >> >> scope.SetVariable("fooclass", typeof(foo)); >> >> Operations like: a = fooclass() work without any problem, but the >> following IronPython does not work and raises the error: Cannot create >> instances of RuntimeType because it has no public constructors. Code: >> >> class bar(fooclass): >> def __init__(self): >> Name = "Unused" >> ... >> >> barobject = bar() >> >> Well, I can't really say what this is about. Is it a Bug in IP or anything >> like a limitation? >> Greetings, Marcel >> >> _______________________________________________ >> 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 microsoft.com Mon Dec 28 20:46:55 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 28 Dec 2009 19:46:55 +0000 Subject: [IronPython] Memory leaks in Ipy 2.6 In-Reply-To: <023e01ca87db$74fe7060$5efb5120$@com> References: <023e01ca87db$74fe7060$5efb5120$@com> Message-ID: <1A472770E042064698CB5ADC83A12ACD2848539C@TK5EX14MBXC118.redmond.corp.microsoft.com> This is definitely a bug - we're leaking our stack frames on the CLR's finalizer thread when we swallow exceptions while closing the generator. I think this is the correct fix but I haven't fully tested it yet, in our generator we have the code below but it's missing the assignment of null to DynamicStackFrames: try { @throw(new GeneratorExitException()); // Generator should not have exited normally. throw new RuntimeException("generator ignored GeneratorExit"); } catch (StopIterationException) { // Ignore ExceptionHelpers.DynamicStackFrames = null; // adding this fixes it } catch (GeneratorExitException) { // Ignore ExceptionHelpers.DynamicStackFrames = null; // adding this fixes it } This definitely fixes 1 and 2. After running this 3 doesn't actually seem to leak memory when running repeatedly for me but after-before > 10 is True. I'll take a closer look and make sure this is the correct fix after the new year when I'm back in the office. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Idan Zaltzberg Sent: Monday, December 28, 2009 10:33 AM To: users at lists.ironpython.com Subject: [IronPython] Memory leaks in Ipy 2.6 Hi, Working with the new version I have encountered some problems which look like memory leaks to me. I've written 3 test methods that reproduce the problems, and would appreciate your response. Thanks Problem 1 Occurs when you do the all of the following 1. Define a generator method 2. Insert a try/except clause in the method 3. define an inner method that uses some local variable 4. Call the generator method without reaching the "StopIteration" Looks like the local variable used by the inner method is never cleared. This code reproduces the problem: def test_generator_memory_leak(self): """ Ipy 2.6 This test reproduces a memory leak when calling a generator method without reaching the end. """ def coroutine(): try: pass except: pass just_numbers = range(1,1000) def inner_method(): return just_numbers yield None yield None from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() for j in xrange(10000): crt = coroutine() crt.next() after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) Problem 2 The same as problem, just instead of defining an inner method, just call "eval" with any string def test_generator_memory_leak2(self): """ Ipy 2.6 This test reproduces a memory leak when calling a generator method without reaching the end. """ def coroutine(b_bool): try: pass except: pass if False: eval("") just_numbers = range(1,1000) yield None yield None from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() for j in xrange(10000): crt = coroutine(False) crt.next() after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) Problem 3 This is actually a our solution to problems 1,2. We noticed that if we end the iteration by using "throw" then the memory doesn't rise on subsequent instances. Still there some memory increase that depends on the size of the local variable which doesn't seem to go away: def test_generator_memory_leak2(self): """ Ipy 2.6 when exiting a generator method with an exception, some objects are never collected This seems to be static to the type (the leak does not grow if we repeat the experiment """ def coroutine(): just_numbers = range(1,1000000) def inner_method(): return just_numbers yield None raise Exception("some exception") # comment out this line to make the test not work from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() crt = coroutine() try: crt.next() crt.next() except: pass crt = None after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) -------------- next part -------------- An HTML attachment was scrubbed... URL: From idan at cloudshare.com Tue Dec 29 06:52:21 2009 From: idan at cloudshare.com (Idan Zaltzberg) Date: Tue, 29 Dec 2009 07:52:21 +0200 Subject: [IronPython] Memory leaks in Ipy 2.6 In-Reply-To: <1A472770E042064698CB5ADC83A12ACD2848539C@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <023e01ca87db$74fe7060$5efb5120$@com> <1A472770E042064698CB5ADC83A12ACD2848539C@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <025801ca884b$16c144d0$4443ce70$@com> Thanks for the fast reply. Could you estimate when and how (in what version) the fix will be deployed? Regardless, our current fix is to "throw" exception when we want the generator to be disposed and catch it ourselves, is that the right way to go? *From:* users-bounces at lists.ironpython.com [mailto: users-bounces at lists.ironpython.com] *On Behalf Of *Dino Viehland *Sent:* Monday, December 28, 2009 9:47 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Memory leaks in Ipy 2.6 This is definitely a bug ? we?re leaking our stack frames on the CLR?s finalizer thread when we swallow exceptions while closing the generator. I think this is the correct fix but I haven?t fully tested it yet, in our generator we have the code below but it?s missing the assignment of null to DynamicStackFrames: try { @throw(new GeneratorExitException()); // Generator should not have exited normally. throw new RuntimeException("generator ignored GeneratorExit" ); } catch (StopIterationException) { // Ignore ExceptionHelpers.DynamicStackFrames = null; // adding this fixes it } catch (GeneratorExitException) { // Ignore ExceptionHelpers.DynamicStackFrames = null; // adding this fixes it } This definitely fixes 1 and 2. After running this 3 doesn?t actually seem to leak memory when running repeatedly for me but after-before > 10 is True. I?ll take a closer look and make sure this is the correct fix after the new year when I?m back in the office. *From:* users-bounces at lists.ironpython.com [mailto: users-bounces at lists.ironpython.com] *On Behalf Of *Idan Zaltzberg *Sent:* Monday, December 28, 2009 10:33 AM *To:* users at lists.ironpython.com *Subject:* [IronPython] Memory leaks in Ipy 2.6 Hi, Working with the new version I have encountered some problems which look like memory leaks to me. I've written 3 test methods that reproduce the problems, and would appreciate your response. Thanks *Problem 1* Occurs when you do the all of the following 1. Define a generator method 2. Insert a try/except clause in the method 3. define an inner method that uses some local variable 4. Call the generator method without reaching the "StopIteration" Looks like the local variable used by the inner method is never cleared. This code reproduces the problem: def test_generator_memory_leak(self): """ Ipy 2.6 This test reproduces a memory leak when calling a generator method without reaching the end. """ def coroutine(): try: pass except: pass just_numbers = range(1,1000) def inner_method(): return just_numbers yield None yield None from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() for j in xrange(10000): crt = coroutine() crt.next() after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) *Problem 2* The same as problem, just instead of defining an inner method, just call "eval" with any string def test_generator_memory_leak2(self): """ Ipy 2.6 This test reproduces a memory leak when calling a generator method without reaching the end. """ def coroutine(b_bool): try: pass except: pass if False: eval("") just_numbers = range(1,1000) yield None yield None from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() for j in xrange(10000): crt = coroutine(False) crt.next() after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) *Problem 3* This is actually a our solution to problems 1,2. We noticed that if we end the iteration by using "throw" then the memory doesn?t rise on subsequent instances. Still there some memory increase that depends on the size of the local variable which doesn?t seem to go away: def test_generator_memory_leak2(self): """ Ipy 2.6 when exiting a generator method with an exception, some objects are never collected This seems to be static to the type (the leak does not grow if we repeat the experiment """ def coroutine(): just_numbers = range(1,1000000) def inner_method(): return just_numbers yield None raise Exception("some exception") # comment out this line to make the test not work from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() crt = coroutine() try: crt.next() crt.next() except: pass crt = None after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Dec 29 07:36:28 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 29 Dec 2009 06:36:28 +0000 Subject: [IronPython] Memory leaks in Ipy 2.6 In-Reply-To: <025801ca884b$16c144d0$4443ce70$@com> References: <023e01ca87db$74fe7060$5efb5120$@com> <1A472770E042064698CB5ADC83A12ACD2848539C@TK5EX14MBXC118.redmond.corp.microsoft.com> <025801ca884b$16c144d0$4443ce70$@com> Message-ID: <1A472770E042064698CB5ADC83A12ACD28486E99@TK5EX14MBXC118.redmond.corp.microsoft.com> 2.6.1 is when it should be fixed which should be sometime early next year. A better workaround might be to avoid try/except in the generator if you can refactor that out into its own function. But if that doesn't work then I also think calling close explicitly should avoid it and do so without the cost of throwing the exception. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Idan Zaltzberg Sent: Monday, December 28, 2009 11:52 PM To: Discussion of IronPython Subject: Re: [IronPython] Memory leaks in Ipy 2.6 Thanks for the fast reply. Could you estimate when and how (in what version) the fix will be deployed? Regardless, our current fix is to "throw" exception when we want the generator to be disposed and catch it ourselves, is that the right way to go? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, December 28, 2009 9:47 PM To: Discussion of IronPython Subject: Re: [IronPython] Memory leaks in Ipy 2.6 This is definitely a bug - we're leaking our stack frames on the CLR's finalizer thread when we swallow exceptions while closing the generator. I think this is the correct fix but I haven't fully tested it yet, in our generator we have the code below but it's missing the assignment of null to DynamicStackFrames: try { @throw(new GeneratorExitException()); // Generator should not have exited normally. throw new RuntimeException("generator ignored GeneratorExit"); } catch (StopIterationException) { // Ignore ExceptionHelpers.DynamicStackFrames = null; // adding this fixes it } catch (GeneratorExitException) { // Ignore ExceptionHelpers.DynamicStackFrames = null; // adding this fixes it } This definitely fixes 1 and 2. After running this 3 doesn't actually seem to leak memory when running repeatedly for me but after-before > 10 is True. I'll take a closer look and make sure this is the correct fix after the new year when I'm back in the office. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Idan Zaltzberg Sent: Monday, December 28, 2009 10:33 AM To: users at lists.ironpython.com Subject: [IronPython] Memory leaks in Ipy 2.6 Hi, Working with the new version I have encountered some problems which look like memory leaks to me. I've written 3 test methods that reproduce the problems, and would appreciate your response. Thanks Problem 1 Occurs when you do the all of the following 1. Define a generator method 2. Insert a try/except clause in the method 3. define an inner method that uses some local variable 4. Call the generator method without reaching the "StopIteration" Looks like the local variable used by the inner method is never cleared. This code reproduces the problem: def test_generator_memory_leak(self): """ Ipy 2.6 This test reproduces a memory leak when calling a generator method without reaching the end. """ def coroutine(): try: pass except: pass just_numbers = range(1,1000) def inner_method(): return just_numbers yield None yield None from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() for j in xrange(10000): crt = coroutine() crt.next() after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) Problem 2 The same as problem, just instead of defining an inner method, just call "eval" with any string def test_generator_memory_leak2(self): """ Ipy 2.6 This test reproduces a memory leak when calling a generator method without reaching the end. """ def coroutine(b_bool): try: pass except: pass if False: eval("") just_numbers = range(1,1000) yield None yield None from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() for j in xrange(10000): crt = coroutine(False) crt.next() after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) Problem 3 This is actually a our solution to problems 1,2. We noticed that if we end the iteration by using "throw" then the memory doesn't rise on subsequent instances. Still there some memory increase that depends on the size of the local variable which doesn't seem to go away: def test_generator_memory_leak2(self): """ Ipy 2.6 when exiting a generator method with an exception, some objects are never collected This seems to be static to the type (the leak does not grow if we repeat the experiment """ def coroutine(): just_numbers = range(1,1000000) def inner_method(): return just_numbers yield None raise Exception("some exception") # comment out this line to make the test not work from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() crt = coroutine() try: crt.next() crt.next() except: pass crt = None after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) -------------- next part -------------- An HTML attachment was scrubbed... URL: From idan at cloudshare.com Tue Dec 29 07:41:36 2009 From: idan at cloudshare.com (Idan Zaltzberg) Date: Tue, 29 Dec 2009 08:41:36 +0200 Subject: [IronPython] Memory leaks in Ipy 2.6 In-Reply-To: <1A472770E042064698CB5ADC83A12ACD28486E99@TK5EX14MBXC118.redmond.corp.microsoft.com> References: <023e01ca87db$74fe7060$5efb5120$@com> <1A472770E042064698CB5ADC83A12ACD2848539C@TK5EX14MBXC118.redmond.corp.microsoft.com> <025801ca884b$16c144d0$4443ce70$@com> <1A472770E042064698CB5ADC83A12ACD28486E99@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <028701ca8851$f81821a0$e84864e0$@com> Unless I'm missing something, it seems calling close doesn?t solve the problem *From:* users-bounces at lists.ironpython.com [mailto: users-bounces at lists.ironpython.com] *On Behalf Of *Dino Viehland *Sent:* Tuesday, December 29, 2009 8:36 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Memory leaks in Ipy 2.6 2.6.1 is when it should be fixed which should be sometime early next year. A better workaround might be to avoid try/except in the generator if you can refactor that out into its own function. But if that doesn?t work then I also think calling close explicitly should avoid it and do so without the cost of throwing the exception. *From:* users-bounces at lists.ironpython.com [mailto: users-bounces at lists.ironpython.com] *On Behalf Of *Idan Zaltzberg *Sent:* Monday, December 28, 2009 11:52 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Memory leaks in Ipy 2.6 Thanks for the fast reply. Could you estimate when and how (in what version) the fix will be deployed? Regardless, our current fix is to "throw" exception when we want the generator to be disposed and catch it ourselves, is that the right way to go? *From:* users-bounces at lists.ironpython.com [mailto: users-bounces at lists.ironpython.com] *On Behalf Of *Dino Viehland *Sent:* Monday, December 28, 2009 9:47 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Memory leaks in Ipy 2.6 This is definitely a bug ? we?re leaking our stack frames on the CLR?s finalizer thread when we swallow exceptions while closing the generator. I think this is the correct fix but I haven?t fully tested it yet, in our generator we have the code below but it?s missing the assignment of null to DynamicStackFrames: try { @throw(new GeneratorExitException()); // Generator should not have exited normally. throw new RuntimeException("generator ignored GeneratorExit" ); } catch (StopIterationException) { // Ignore ExceptionHelpers.DynamicStackFrames = null; // adding this fixes it } catch (GeneratorExitException) { // Ignore ExceptionHelpers.DynamicStackFrames = null; // adding this fixes it } This definitely fixes 1 and 2. After running this 3 doesn?t actually seem to leak memory when running repeatedly for me but after-before > 10 is True. I?ll take a closer look and make sure this is the correct fix after the new year when I?m back in the office. *From:* users-bounces at lists.ironpython.com [mailto: users-bounces at lists.ironpython.com] *On Behalf Of *Idan Zaltzberg *Sent:* Monday, December 28, 2009 10:33 AM *To:* users at lists.ironpython.com *Subject:* [IronPython] Memory leaks in Ipy 2.6 Hi, Working with the new version I have encountered some problems which look like memory leaks to me. I've written 3 test methods that reproduce the problems, and would appreciate your response. Thanks *Problem 1* Occurs when you do the all of the following 1. Define a generator method 2. Insert a try/except clause in the method 3. define an inner method that uses some local variable 4. Call the generator method without reaching the "StopIteration" Looks like the local variable used by the inner method is never cleared. This code reproduces the problem: def test_generator_memory_leak(self): """ Ipy 2.6 This test reproduces a memory leak when calling a generator method without reaching the end. """ def coroutine(): try: pass except: pass just_numbers = range(1,1000) def inner_method(): return just_numbers yield None yield None from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() for j in xrange(10000): crt = coroutine() crt.next() after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) *Problem 2* The same as problem, just instead of defining an inner method, just call "eval" with any string def test_generator_memory_leak2(self): """ Ipy 2.6 This test reproduces a memory leak when calling a generator method without reaching the end. """ def coroutine(b_bool): try: pass except: pass if False: eval("") just_numbers = range(1,1000) yield None yield None from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() for j in xrange(10000): crt = coroutine(False) crt.next() after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) *Problem 3* This is actually a our solution to problems 1,2. We noticed that if we end the iteration by using "throw" then the memory doesn?t rise on subsequent instances. Still there some memory increase that depends on the size of the local variable which doesn?t seem to go away: def test_generator_memory_leak2(self): """ Ipy 2.6 when exiting a generator method with an exception, some objects are never collected This seems to be static to the type (the leak does not grow if we repeat the experiment """ def coroutine(): just_numbers = range(1,1000000) def inner_method(): return just_numbers yield None raise Exception("some exception") # comment out this line to make the test not work from System import GC def get_memory(): for _ in xrange(4): GC.Collect() GC.WaitForPendingFinalizers() return GC.GetTotalMemory(True)/1e6 before = get_memory() crt = coroutine() try: crt.next() crt.next() except: pass crt = None after = get_memory() self.assert_(after-before > 10,'There should be a memory leak in this case.before=%s after=%s' % (before,after)) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgopale at gmail.com Wed Dec 30 11:07:09 2009 From: sgopale at gmail.com (Shyam Gopale) Date: Wed, 30 Dec 2009 15:37:09 +0530 Subject: [IronPython] Silverlight DataBinding Not Working Message-ID: Hi, I am trying out some sample Silverlight code with IronPython and I found that the data binding does not work properly. The app.xaml is as below: This XAML when used in a C# Silverlight app reflects the correct data binding behaviour but does not work when used with IronPython and Chiron. Mainly the font size of the text block is not updated. Does anyone have any idea about this? Thanks, Shyam -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Wed Dec 30 17:10:02 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 30 Dec 2009 08:10:02 -0800 Subject: [IronPython] Silverlight DataBinding Not Working In-Reply-To: References: Message-ID: Silverlight doesn't support ICustomTypeDescriptor, which is how IronPython objects interact with data binding on the desktop. For a workaround, see http://devhawk.net/2009/04/24/clrtype+Metaclasses+Demo+Silverlight+Databinding.aspx I believe Silverlight 4 supports IDynamicMetaObjectProvider for data binding, so the need for emitting your own CLR type goes away with that release. On Wed, Dec 30, 2009 at 2:07 AM, Shyam Gopale wrote: > Hi, > > I am trying out some sample Silverlight code with IronPython and I found > that the data binding does not work properly. > The app.xaml is as below: > > xmlns="http://schemas.microsoft.com/client/2007" > xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> > > > Value="10" /> > FontSize="{Binding ElementName=sliderFontSize, > Path=Value,Mode=TwoWay}"> > > > > > This XAML when used in a C# Silverlight app reflects the correct data > binding behaviour but does not work when used with IronPython and Chiron. > Mainly the font size of the text block is not updated. > Does anyone have any idea about this? > > Thanks, > Shyam > > _______________________________________________ > 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 cenovsky at bakalari.cz Wed Dec 30 17:32:53 2009 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Wed, 30 Dec 2009 17:32:53 +0100 Subject: [IronPython] Silverlight DataBinding Not Working In-Reply-To: References: Message-ID: <4B3B80B5.8010308@bakalari.cz> Shyam Gopale wrote: > Hi, > I am trying out some sample Silverlight code with IronPython and I > found that the data binding does not work properly. > The app.xaml is as below: > xmlns="http://schemas.microsoft.com/client/2007" > xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> > > > Value="10" /> > FontSize="{Binding ElementName=sliderFontSize, > Path=Value,Mode=TwoWay}"> > > > > > This XAML when used in a C# Silverlight app reflects the correct data > binding behaviour but does not work when used with IronPython and > Chiron. Mainly the font size of the text block is not updated. > Does anyone have any idea about this? Check my blog about binding in Silverlight: http://gui-at.blogspot.com/2009/11/inotifypropertychanged-and-databinding.html -- -- Luk?? From merllab at microsoft.com Wed Dec 30 17:53:01 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Wed, 30 Dec 2009 08:53:01 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/62725. MODIFIED SOURCES $/IronPython/IronPython_Main/Src/Tests/modules/misc/system_namespaces.py CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1404743 Date: 12/29/2009 3:50:00 PM Disabled a test in modules.misc.system_namespaces due to CodePlex 25806. (Shelveset: CP25806;REDMOND\dfugate | SNAP CheckinId: 10057) From sgopale at gmail.com Thu Dec 31 04:54:17 2009 From: sgopale at gmail.com (Shyam Gopale) Date: Thu, 31 Dec 2009 09:24:17 +0530 Subject: [IronPython] Silverlight DataBinding Not Working In-Reply-To: <4B3B80B5.8010308@bakalari.cz> References: <4B3B80B5.8010308@bakalari.cz> Message-ID: But, I am just doing binding between elements. Is this still required. If you see my XAML I am just binding the value of a slider to the fontsize of a textblock. I am not sure if the Ironpython code hits that path. Thanks, Shyam On Wed, Dec 30, 2009 at 10:02 PM, Lukas Cenovsky wrote: > Shyam Gopale wrote: > >> Hi, >> I am trying out some sample Silverlight code with IronPython and I found >> that the data binding does not work properly. >> The app.xaml is as below: >> > xmlns="http://schemas.microsoft.com/client/2007" >> xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> >> >> >> > Value="10" /> >> > FontSize="{Binding ElementName=sliderFontSize, >> Path=Value,Mode=TwoWay}"> >> >> >> >> >> This XAML when used in a C# Silverlight app reflects the correct data >> binding behaviour but does not work when used with IronPython and Chiron. >> Mainly the font size of the text block is not updated. >> Does anyone have any idea about this? >> > Check my blog about binding in Silverlight: > > http://gui-at.blogspot.com/2009/11/inotifypropertychanged-and-databinding.html > > -- > -- Luk?? > > > _______________________________________________ > 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 cenovsky at bakalari.cz Thu Dec 31 10:37:03 2009 From: cenovsky at bakalari.cz (Lukas Cenovsky) Date: Thu, 31 Dec 2009 10:37:03 +0100 Subject: [IronPython] Silverlight DataBinding Not Working In-Reply-To: References: <4B3B80B5.8010308@bakalari.cz> Message-ID: <4B3C70BF.8040600@bakalari.cz> I overlooked you are doing ElementBinding. It seems it does not work in IronPython - the Slider (element you are binding to) probably does not fire PropertyChanged event. I would blame some magic with codebehind files :-) In this case, the slider is updated when the text box changes its value: In this case, the text box is updated when the slider changes its value: Finally this works but it not much usable: -- -- Luk?? Shyam Gopale wrote: > But, I am just doing binding between elements. Is this still required. > If you see my XAML I am just binding the value of a slider to the > fontsize of a textblock. I am not sure if the Ironpython code hits > that path. > > Thanks, > Shyam > > On Wed, Dec 30, 2009 at 10:02 PM, Lukas Cenovsky > wrote: > > Shyam Gopale wrote: > > Hi, > I am trying out some sample Silverlight code with IronPython > and I found that the data binding does not work properly. > The app.xaml is as below: > xmlns="http://schemas.microsoft.com/client/2007" > xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> > > > Maximum="40" Value="10" /> > FontSize="{Binding ElementName=sliderFontSize, > Path=Value,Mode=TwoWay}"> > > > > > This XAML when used in a C# Silverlight app reflects the > correct data binding behaviour but does not work when used > with IronPython and Chiron. Mainly the font size of the text > block is not updated. > Does anyone have any idea about this? > > Check my blog about binding in Silverlight: > http://gui-at.blogspot.com/2009/11/inotifypropertychanged-and-databinding.html > > -- > -- Luk?? > > > _______________________________________________ > 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 merllab at microsoft.com Thu Dec 31 17:52:49 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Thu, 31 Dec 2009 08:52:49 -0800 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <318230e8-0fc5-47ac-9305-40db9f6a6de4@tk5-exsmh-c102.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/62761. MODIFIED SOURCES $/IronPython/IronPython_Main/Src/Tests/interop/com/apps/excel.py $/IronPython/IronPython_Main/Src/Tests/RunAgainstCpy.py CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1406088 Date: 12/30/2009 5:40:13 PM - RunAgainstCpy.py - pass "-B" flag to Python subprocesses - limit the output coming from ipy.bat - ipy.bat now recognizes an "IS_FLAKEY" environment variable. When this variable is set and the script passed to ipy.bat emits a non-zero exit code, the script is given one last chance to emit a zero exit code. This feature is particularly useful with CPython socket-based tests in which we don't want to make many modifications - test_asynchat_cpy.GenericTest - set IS_FLAKEY (Shelveset: RUNCPY;REDMOND\dfugate | SNAP CheckinId: 10065) -------------------------------------------------------------------------------- Changeset Id: 1405853 Date: 12/30/2009 12:49:22 PM Added a small regression relating to 'callable' and COM objects. (Shelveset: MISC01;REDMOND\dfugate | SNAP CheckinId: 10060) From johnf at jfcomputer.com Thu Dec 31 18:54:06 2009 From: johnf at jfcomputer.com (John) Date: Thu, 31 Dec 2009 09:54:06 -0800 Subject: [IronPython] sqlAlachemy Message-ID: <200912310954.06341.johnf@jfcomputer.com> Does ironpython (any version) work with sqlAlachemy? Johnf From fuzzyman at voidspace.org.uk Thu Dec 31 19:08:28 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 31 Dec 2009 18:08:28 +0000 Subject: [IronPython] sqlAlachemy In-Reply-To: <200912310954.06341.johnf@jfcomputer.com> References: <200912310954.06341.johnf@jfcomputer.com> Message-ID: <4B3CE89C.5070005@voidspace.org.uk> On 31/12/2009 17:54, John wrote: > Does ironpython (any version) work with sqlAlachemy? > I haven't seen any reports on this list recently of SqlAlchemy either working or not working. Have you tried it? Michael > Johnf > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From vernondcole at gmail.com Thu Dec 31 19:31:10 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Thu, 31 Dec 2009 11:31:10 -0700 Subject: [IronPython] sqlAlachemy In-Reply-To: <4B3CE89C.5070005@voidspace.org.uk> References: <200912310954.06341.johnf@jfcomputer.com> <4B3CE89C.5070005@voidspace.org.uk> Message-ID: sqlAlchemy is documented to work with a PEP-249 compliant db api. AFAIK adodbapi is the only IronPython db module which is fully db api v2.0 compliant. Last time I looked (a few years ago) adodbapi was in last place on their list of suggested drivers. I have done some work since then which should have eliminated some of the problems that sqlAlchemy had with it, but I have not checked back. I am in the middle of adding django support to adodbapi at this time -- a major revision. If you want to test sqlAlchemy with adodbapi I will try to include any patches you may find. I will try to get an alpha test version of the new code out next week. Stay tuned. -- Vernon Cole http://sourceforge.net/projects/adodbapi On Thu, Dec 31, 2009 at 11:08 AM, Michael Foord wrote: > On 31/12/2009 17:54, John wrote: > >> Does ironpython (any version) work with sqlAlachemy? >> >> > I haven't seen any reports on this list recently of SqlAlchemy either > working or not working. Have you tried it? > > Michael > > > Johnf >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > > _______________________________________________ > 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 johnf at jfcomputer.com Thu Dec 31 19:43:49 2009 From: johnf at jfcomputer.com (John) Date: Thu, 31 Dec 2009 10:43:49 -0800 Subject: [IronPython] sqlAlachemy In-Reply-To: References: <200912310954.06341.johnf@jfcomputer.com> <4B3CE89C.5070005@voidspace.org.uk> Message-ID: <200912311043.49264.johnf@jfcomputer.com> On Thursday 31 December 2009 10:31:10 am Vernon Cole wrote: > sqlAlchemy is documented to work with a PEP-249 compliant db api. AFAIK > adodbapi is the only IronPython db module which is fully db api v2.0 > compliant. Last time I looked (a few years ago) adodbapi was in last place > on their list of suggested drivers. I have done some work since then which > should have eliminated some of the problems that sqlAlchemy had with it, > but I have not checked back. I am in the middle of adding django support to > adodbapi at this time -- a major revision. If you want to test sqlAlchemy > with adodbapi I will try to include any patches you may find. I will try to > get an alpha test version of the new code out next week. Stay tuned. -- > Vernon Cole > http://sourceforge.net/projects/adodbapi > > On Thu, Dec 31, 2009 at 11:08 AM, Michael Foord > > wrote: > > On 31/12/2009 17:54, John wrote: > >> Does ironpython (any version) work with sqlAlachemy? > > > > I haven't seen any reports on this list recently of SqlAlchemy either > > working or not working. Have you tried it? > > > > Michael > > > > > > Johnf Thanks Vernon. Please do not do anything on my behalf. I will not be starting an Ironpython for sometime. I'm just starting the investigation of what will be needed. Johnf