From dinov at microsoft.com Wed Apr 1 00:54:59 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 31 Mar 2009 15:54:59 -0700 Subject: [IronPython] PYC and 2.6 A1 In-Reply-To: <20253b0c0903311352pbb35055sa9bcbbdbb0623c8e@mail.gmail.com> References: <20253b0c0903311352pbb35055sa9bcbbdbb0623c8e@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23555726CA7365@NA-EXMSG-C102.redmond.corp.microsoft.com> Yeah there is apparently an issue here, Resolver reported it to me the other day off-line. We've been changing our code gen rather significantly and it looks like our existing test coverage isn't hitting whatever the issue is here. I'll probably look at it tomorrow. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Tuesday, March 31, 2009 1:52 PM To: Discussion of IronPython Subject: [IronPython] PYC and 2.6 A1 Hi Guys, Are there known issues with PYC and IPY 2.6 A1? When my exe compiles, I get: Unhandled Exception: Microsoft.Scripting.Runtime.UnboundNameException: name 'ThreadExceptionEventArgs' is not defined at Microsoft.Scripting.Actions.Calls.MethodTarget.Caller.Call(Object[] args, Boolean& shouldOptimize) at IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`6.Call5(CallSite site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) at Microsoft.Scripting.UpdateDelegates.UpdateAndExecute7[T0,T1,T2,T3,T4,T5,T6,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6) at IronPython.Runtime.Importer.Import(CodeContext context, String fullName, PythonTuple from, Int32 level) at IronPython.Runtime.Operations.PythonOps.InitializeModule(Assembly precompiled, String main, String[] references) at PythonMain.Main() Works fine in 2.01. Thanks, Davy Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed Apr 1 00:54:59 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 31 Mar 2009 15:54:59 -0700 Subject: [IronPython] PYC and 2.6 A1 In-Reply-To: <20253b0c0903311352pbb35055sa9bcbbdbb0623c8e@mail.gmail.com> References: <20253b0c0903311352pbb35055sa9bcbbdbb0623c8e@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23555726CA7365@NA-EXMSG-C102.redmond.corp.microsoft.com> Yeah there is apparently an issue here, Resolver reported it to me the other day off-line. We've been changing our code gen rather significantly and it looks like our existing test coverage isn't hitting whatever the issue is here. I'll probably look at it tomorrow. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Tuesday, March 31, 2009 1:52 PM To: Discussion of IronPython Subject: [IronPython] PYC and 2.6 A1 Hi Guys, Are there known issues with PYC and IPY 2.6 A1? When my exe compiles, I get: Unhandled Exception: Microsoft.Scripting.Runtime.UnboundNameException: name 'ThreadExceptionEventArgs' is not defined at Microsoft.Scripting.Actions.Calls.MethodTarget.Caller.Call(Object[] args, Boolean& shouldOptimize) at IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`6.Call5(CallSite site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) at Microsoft.Scripting.UpdateDelegates.UpdateAndExecute7[T0,T1,T2,T3,T4,T5,T6,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6) at IronPython.Runtime.Importer.Import(CodeContext context, String fullName, PythonTuple from, Int32 level) at IronPython.Runtime.Operations.PythonOps.InitializeModule(Assembly precompiled, String main, String[] references) at PythonMain.Main() Works fine in 2.01. Thanks, Davy Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamb at silverkeytech.com Wed Apr 1 17:35:15 2009 From: adamb at silverkeytech.com (Adam Brand) Date: Wed, 1 Apr 2009 08:35:15 -0700 Subject: [IronPython] Python In-Browser Code Editor Message-ID: <8bd92c0e0904010835ta05f4a7s5196dfaf9ac43d6a@mail.gmail.com> Hey all, We've been looking for an in-browser code editor to replace EditArea for editing IP code in-browser...something faster/lighter. I found codemirror ( http://marijn.haverbeke.nl/codemirror/) and worked with another community member (Timothy Farrell) to create a Python plugin for it (he did the work, I did the prodding/testing :-)). If anyone is interested in testing the IP implementations of Python in this editor (for parsing and syntax highlighting), we'd love to incorporate feedback and make this a very solid option for the IP community. Thanks, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuelt at gmail.com Thu Apr 2 19:42:49 2009 From: samuelt at gmail.com (Samuel Tjokrosoesilo) Date: Thu, 2 Apr 2009 12:42:49 -0500 Subject: [IronPython] Question on loading assembly from byte array Message-ID: I would like to be able to load assembly from byte array inside of IronPython. Is there any way to do it directly in IronPython? I'm unable to run something like clr.AddReference(byte []). Below is what I do in .NET DLR in order to make this work: byte[] rawAssemblyFile = File.ReadAllBytes(assemblyName); Runtime.LoadAssembly(Assembly.Load(rawAssemblyFile)); Another alternative that I use would be the following: C# byte[] rawAssemblyFile = File.ReadAllBytes(assemblyName); Assembly rawAssembly = Assembly.Load(rawAssemblyFile); Scope.SetVariable("rawAssembly", rawAssembly); Python import clr clr.AddReference(rawAssembly) I'm just wondering if there's a cleaner way to do this whole thing inside of IronPython. Thanks. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Apr 2 20:12:06 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 2 Apr 2009 11:12:06 -0700 Subject: [IronPython] Question on loading assembly from byte array In-Reply-To: References: Message-ID: <350E7D38B6D819428718949920EC23555726DD0EC8@NA-EXMSG-C102.redmond.corp.microsoft.com> You can do: import clr from System.IO import File clr.AddReference(Assembly.Load(File.ReadAllBytes(assemblyName))) From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Samuel Tjokrosoesilo Sent: Thursday, April 02, 2009 10:43 AM To: Discussion of IronPython Subject: [IronPython] Question on loading assembly from byte array I would like to be able to load assembly from byte array inside of IronPython. Is there any way to do it directly in IronPython? I'm unable to run something like clr.AddReference(byte []). Below is what I do in .NET DLR in order to make this work: byte [] rawAssemblyFile = File.ReadAllBytes(assemblyName); Runtime.LoadAssembly(Assembly.Load(rawAssemblyFile)); Another alternative that I use would be the following: C# byte[] rawAssemblyFile = File.ReadAllBytes(assemblyName); Assembly rawAssembly = Assembly.Load(rawAssemblyFile); Scope.SetVariable( "rawAssembly", rawAssembly); Python import clr clr.AddReference(rawAssembly) I'm just wondering if there's a cleaner way to do this whole thing inside of IronPython. Thanks. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuelt at gmail.com Thu Apr 2 21:40:18 2009 From: samuelt at gmail.com (Samuel Tjokrosoesilo) Date: Thu, 2 Apr 2009 14:40:18 -0500 Subject: [IronPython] Question on loading assembly from byte array In-Reply-To: <350E7D38B6D819428718949920EC23555726DD0EC8@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <350E7D38B6D819428718949920EC23555726DD0EC8@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: Wow, thanks a lot, Dino. I went ahead and imported the Assembly from System.Reflection and it resolved it. Samuel 2009/4/2 Dino Viehland > You can do: > > > > import clr > > from System.IO import File > > clr.AddReference(Assembly.Load(File.ReadAllBytes(assemblyName))) > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Samuel Tjokrosoesilo > *Sent:* Thursday, April 02, 2009 10:43 AM > *To:* Discussion of IronPython > *Subject:* [IronPython] Question on loading assembly from byte array > > > > I would like to be able to load assembly from byte array inside of > IronPython. > > Is there any way to do it directly in IronPython? I'm unable to run > something like clr.AddReference(byte []). > > > > > > Below is what I do in .NET DLR in order to make this work: > > byte > > [] rawAssemblyFile = File.ReadAllBytes(assemblyName); > > Runtime.LoadAssembly(Assembly.Load(rawAssemblyFile)); > > > > Another alternative that I use would be the following: > > C# > > byte[] rawAssemblyFile = File.ReadAllBytes(assemblyName); > > Assembly > > rawAssembly = Assembly.Load(rawAssemblyFile); > > Scope.SetVariable( > > "rawAssembly", rawAssembly); > > Python > > import clr > > clr.AddReference(rawAssembly) > > > > I'm just wondering if there's a cleaner way to do this whole thing inside > of IronPython. > > Thanks. > > Samuel > > > > _______________________________________________ > 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 daftspaniel at gmail.com Thu Apr 2 22:34:46 2009 From: daftspaniel at gmail.com (Davy Mitchell) Date: Thu, 2 Apr 2009 21:34:46 +0100 Subject: [IronPython] PYC and 2.6 A1 In-Reply-To: <350E7D38B6D819428718949920EC23555726CA7365@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <20253b0c0903311352pbb35055sa9bcbbdbb0623c8e@mail.gmail.com> <350E7D38B6D819428718949920EC23555726CA7365@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <20253b0c0904021334v1c9697e2h32370933b5702a32@mail.gmail.com> Thanks Dino - no urgency for me. I usually compile DIE for my own use but under 2.6A1 it runs fairly snappily even when run from ipy :-) Thanks, Davy On Tue, Mar 31, 2009 at 11:54 PM, Dino Viehland wrote: > Yeah there is apparently an issue here, Resolver reported it to me the > other day off-line. We?ve been changing our code gen rather significantly > and it looks like our existing test coverage isn?t hitting whatever the > issue is here. I?ll probably look at it tomorrow. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Davy Mitchell > *Sent:* Tuesday, March 31, 2009 1:52 PM > *To:* Discussion of IronPython > *Subject:* [IronPython] PYC and 2.6 A1 > > > > Hi Guys, > > > > Are there known issues with PYC and IPY 2.6 A1? > > > > When my exe compiles, I get: > > > Unhandled Exception: Microsoft.Scripting.Runtime.UnboundNameException: name > 'ThreadExceptionEventArgs' is not defined > at Microsoft.Scripting.Actions.Calls.MethodTarget.Caller.Call(Object[] > args, Boolean& shouldOptimize) > at > IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`6.Call5(CallSite > site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, T3 > arg3, T4 arg4) > at > Microsoft.Scripting.UpdateDelegates.UpdateAndExecute7[T0,T1,T2,T3,T4,T5,T6,TRet](CallSite > site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6) > at IronPython.Runtime.Importer.Import(CodeContext context, String > fullName, PythonTuple from, Int32 level) > at IronPython.Runtime.Operations.PythonOps.InitializeModule(Assembly > precompiled, String main, String[] references) > at PythonMain.Main() > > Works fine in 2.01. > > > > Thanks, > > Davy Mitchell > > _______________________________________________ > 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 adamb at silverkeytech.com Fri Apr 3 21:01:40 2009 From: adamb at silverkeytech.com (Adam Brand) Date: Fri, 3 Apr 2009 12:01:40 -0700 Subject: [IronPython] with_statement in IronPython for ASP.Net? Message-ID: <8bd92c0e0904031201t6925995aub0a85416bfafa42e@mail.gmail.com> Using IronPython for ASP.Net, trying to use: from __future__ import with_statement ...get the message: future feature is not defined:with_statement Have put the __future__.py file in the directory that py file is in as well as my lib folder. Any ideas? I saw some references to needing to put the switch -X:Python25, but I think that was for earlier versions of IPY. AFAIK the IP for ASP.NETis IronPython 2, Alpha 1...I'm thinking that one shouldn't need the switch? Thanks, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinjvinj at gmail.com Fri Apr 3 21:59:22 2009 From: vinjvinj at gmail.com (Vineet Jain) Date: Fri, 3 Apr 2009 15:59:22 -0400 Subject: [IronPython] How to use memcache client library written in csharp from ironpython Message-ID: <70a7f84f0904031259y307cffa9g4490e063829ab942@mail.gmail.com> I'm trying the use the memcache client library written here: http://code.google.com/p/beitmemcached/ Here is the example file showing how to connect: http://code.google.com/p/beitmemcached/source/browse/trunk/Example.cs# Couple of questions: 1. When will csharp 4 and the corresponding iron python be out where we could just use static and dynamic? 2. How would I go about using the memecache library from iron python 2.x? Any help would be appreciated. Cheers, vinjvinj From empirebuilder at gmail.com Fri Apr 3 22:10:34 2009 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Fri, 3 Apr 2009 22:10:34 +0200 Subject: [IronPython] How to use memcache client library written in csharp from ironpython In-Reply-To: <70a7f84f0904031259y307cffa9g4490e063829ab942@mail.gmail.com> References: <70a7f84f0904031259y307cffa9g4490e063829ab942@mail.gmail.com> Message-ID: <8cd017b80904031310j6e58eb6bj7d0dc86ddac7d346@mail.gmail.com> 1. I guess it will be in 2010 (Visual Studio 2010 timeline) 2. You can find more tutorials on to do iron python here http://www.ironpython.info/index.php/Contents#Getting_Started On Fri, Apr 3, 2009 at 9:59 PM, Vineet Jain wrote: > I'm trying the use the memcache client library written here: > > http://code.google.com/p/beitmemcached/ > > Here is the example file showing how to connect: > > http://code.google.com/p/beitmemcached/source/browse/trunk/Example.cs# > > Couple of questions: > > 1. When will csharp 4 and the corresponding iron python be out where > we could just use static and dynamic? > 2. How would I go about using the memecache library from iron python 2.x? > > Any help would be appreciated. > > Cheers, > > vinjvinj > _______________________________________________ > 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 daftspaniel at gmail.com Sun Apr 5 12:54:34 2009 From: daftspaniel at gmail.com (Davy Mitchell) Date: Sun, 5 Apr 2009 11:54:34 +0100 Subject: [IronPython] Modifying The PYC Stub EXE Message-ID: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> Hi Folks, I am looking to modify the EXE stub generated by PYC so that it will set the current working directory to the location of the EXE before loading its assemblies. The problem I am having is I build my EXE to a sub-folder called BUILD. If I call it in the form .\build\die.exe then it can't find the DLLs. This can be worked around with shortcuts setting the working dir etc but having this option in code in PYC would be useful. Forgive me if I am very very muddled up about something :-) Thanks, Davy Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From idmkid at yahoo.com Sun Apr 5 15:50:05 2009 From: idmkid at yahoo.com (David Seruyange) Date: Sun, 5 Apr 2009 06:50:05 -0700 (PDT) Subject: [IronPython] The Overloading Story, IsolatedStorage (Silverlight) In-Reply-To: References: Message-ID: <606860.41987.qm@web30805.mail.mud.yahoo.com> Hey everyone, What is the story on overloading with IronPython? From Michael Foord's IronPython in Action p. 208: "[Overloading] largely works seemlessly in IronPython... If IronPython gets it wrong, it's a bug and you should report it on the IronPython mailing list or the issue tracker on the IronPython CodePlex site!" I've been recently implementing some Silverlight + IronPython and ran into trouble with IsolatedStorage. Specifically, there are overloads for the OpenFile method as follows: OpenFile(string path, FileMode mode) OpenFile(string path, FileMode mode, FileAccess access) OpenFile(string path, FileMode mode, FileAccess access, FileShare share) In order to open the file for reading, I found that the two parameter version was inadequate: ioStorage = IsolatedStorageFile.GetUserStoreForApplication() ioStorage.OpenFile("foo.text", FileMode.Open) # FAIL But passing all parameters led to success: ioStorage.OpenFile("foo.text", FileMode.Open, FileAccess.Read, FileShare.Read) #WIN Interestingly enough, I can succeed in writing to a file when I don't pass a FileShare parameter: ioStorage.OpenFile("foo.text", FileMode.Append, FileAccess.Write) I would assume there would be some issue with incompatibility with the defaults for the parameter assignment but when I use a C# project I can succeed with the stripped down calls to create a filestream in IsolatedStorage. Anticipating enlightenment, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Apr 6 01:10:42 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 06 Apr 2009 00:10:42 +0100 Subject: [IronPython] Cross implementation and testing Message-ID: <49D93A72.5060109@voidspace.org.uk> Hello all, One of the things that came out of the Python language summit at PyCon was an agreement to improve the Python test suite for alternative implementations, plus attempt to develop useful cross-implementation benchmarks. Discussion of this is now happening on the stdlib-sig mailing list (which was chosen because it already existed and was unused): http://mail.python.org/mailman/listinfo/stdlib-sig Anyone interested can join the list. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From dinov at microsoft.com Mon Apr 6 17:17:08 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 6 Apr 2009 08:17:08 -0700 Subject: [IronPython] The Overloading Story, IsolatedStorage (Silverlight) In-Reply-To: <606860.41987.qm@web30805.mail.mud.yahoo.com> References: <606860.41987.qm@web30805.mail.mud.yahoo.com> Message-ID: <350E7D38B6D819428718949920EC23555726DD1618@NA-EXMSG-C102.redmond.corp.microsoft.com> For the read case what happens if you explicitly pass FileShare.None instead of FileShare.Read? The reason I ask is the default for FileShare is FileShare.None unless FileAccess == FileAccess.Read. We should just be picking the ctor w/o parameters here so my guess is that the default values are actually behaving in a surprising way. But then again IsolatedStorage is a bit of a magical API (at least on the desktop CLR) so there is a possibility that something weird is happening here. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David Seruyange Sent: Sunday, April 05, 2009 6:50 AM To: Discussion of IronPython Subject: [IronPython] The Overloading Story, IsolatedStorage (Silverlight) Hey everyone, What is the story on overloading with IronPython? From Michael Foord's IronPython in Action p. 208: "[Overloading] largely works seemlessly in IronPython... If IronPython gets it wrong, it's a bug and you should report it on the IronPython mailing list or the issue tracker on the IronPython CodePlex site!" I've been recently implementing some Silverlight + IronPython and ran into trouble with IsolatedStorage. Specifically, there are overloads for the OpenFile method as follows: OpenFile(string path, FileMode mode) OpenFile(string path, FileMode mode, FileAccess access) OpenFile(string path, FileMode mode, FileAccess access, FileShare share) In order to open the file for reading, I found that the two parameter version was inadequate: ioStorage = IsolatedStorageFile.GetUserStoreForApplication() ioStorage.OpenFile("foo.text", FileMode.Open) # FAIL But passing all parameters led to success: ioStorage.OpenFile("foo.text", FileMode.Open, FileAccess.Read, FileShare.Read) #WIN Interestingly enough, I can succeed in writing to a file when I don't pass a FileShare parameter: ioStorage.OpenFile("foo.text", FileMode.Append, FileAccess.Write) I would assume there would be some issue with incompatibility with the defaults for the parameter assignment but when I use a C# project I can succeed with the stripped down calls to create a filestream in IsolatedStorage. Anticipating enlightenment, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Apr 6 17:18:33 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 6 Apr 2009 08:18:33 -0700 Subject: [IronPython] Modifying The PYC Stub EXE In-Reply-To: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> References: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23555726DD161C@NA-EXMSG-C102.redmond.corp.microsoft.com> What DLLs you want to be loaded? The reason I ask is that .NET assembly loading doesn't really work on the basis of the current working directory - instead it looks at the app base which by default is where your EXE is located. We do modify sys.path so that IronPython can load things outside of the app base but I wouldn't suggest pushing this too far. Instead I'd propose doing what a normal build process does and copy the DLLs into the build directory. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Sunday, April 05, 2009 3:55 AM To: Discussion of IronPython Subject: [IronPython] Modifying The PYC Stub EXE Hi Folks, I am looking to modify the EXE stub generated by PYC so that it will set the current working directory to the location of the EXE before loading its assemblies. The problem I am having is I build my EXE to a sub-folder called BUILD. If I call it in the form .\build\die.exe then it can't find the DLLs. This can be worked around with shortcuts setting the working dir etc but having this option in code in PYC would be useful. Forgive me if I am very very muddled up about something :-) Thanks, Davy Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From daftspaniel at gmail.com Mon Apr 6 19:57:04 2009 From: daftspaniel at gmail.com (Davy Mitchell) Date: Mon, 6 Apr 2009 18:57:04 +0100 Subject: [IronPython] Modifying The PYC Stub EXE In-Reply-To: <350E7D38B6D819428718949920EC23555726DD161C@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD161C@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <20253b0c0904061057y753d5976u33d97289b769ae30@mail.gmail.com> Hi Dino, All the DLLs are in the Build directory. Everything runs great if the CWD is the folder containing the EXE. If you try and run it from another folder things go wrong (File Not Found Exception). I've posted a basic repro on my Skydrive http://cid-1c5b93086198f54e.skydrive.live.com/self.aspx/Public/hello.zip cd hello\build\ and die.exe will run cd hello and run .\build\die.exe and it will fail Thanks, Davy Mitchell On Mon, Apr 6, 2009 at 4:18 PM, Dino Viehland wrote: > What DLLs you want to be loaded?? The reason I ask is that .NET assembly > loading doesn?t really work on the basis of the current working directory ? > instead it looks at the app base which by default is where your EXE is > located.? We do modify sys.path so that IronPython can load things outside > of the app base but I wouldn?t suggest pushing this too far.? Instead I?d > propose doing what a normal build process does and copy the DLLs into the > build directory. > > > > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell > Sent: Sunday, April 05, 2009 3:55 AM > To: Discussion of IronPython > Subject: [IronPython] Modifying The PYC Stub EXE > > > > Hi Folks, > > > > I am looking to modify the EXE stub generated by PYC so that it will set the > current working directory to the location of the EXE > > before loading its assemblies. > > > > The problem I am having is I build my EXE to a sub-folder called BUILD. If I > call it in the form .\build\die.exe then it can't find the DLLs. > > This can be worked around with shortcuts setting the working dir?etc but > having this option in code?in PYC would be useful. > > > > Forgive me if I am very very muddled up about something :-) > > > > Thanks, > > Davy Mitchell > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From bruce.bromberek at gmail.com Mon Apr 6 22:18:58 2009 From: bruce.bromberek at gmail.com (Bruce Bromberek) Date: Mon, 6 Apr 2009 15:18:58 -0500 Subject: [IronPython] Modifying The PYC Stub EXE In-Reply-To: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> References: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> Message-ID: <58ad4a110904061318q1201ab68xd4c6144de5ea62df@mail.gmail.com> Davy- I had a similar problem in that the EXE stub built by pyc does not work as expected. My problem was the sys.argv being set to None. As someone who comes to ironpython from Cpython, I want the ironpython equivalent of py2exe where everything just works :) The best advice I've found here is to build your own C# stub exe (thanks Michael!) For my own purposes, I'm going with a two step process. PYC to create the DLL of my script and imported modules. And C# stub that hosts ironpython, loads all the assemblies, and calls my Main(). Now looking at your sample code, I wonder if part of the problem is that you do not have references to the assemblies that the Ironpython console loads by default. Of course I could be wrong on everything. Bruce On Sun, Apr 5, 2009 at 5:54 AM, Davy Mitchell wrote: > Hi Folks, > > I am looking to modify the EXE stub generated by PYC so that it will set > the current working directory to the location of the EXE > before loading its assemblies. > > The problem I am having is I build my EXE to a sub-folder called BUILD. If > I call it in the form .\build\die.exe then it can't find the DLLs. > This can be worked around with shortcuts setting the working dir etc but > having this option in code in PYC would be useful. > > Forgive me if I am very very muddled up about something :-) > > Thanks, > Davy Mitchell > > > > _______________________________________________ > 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 Tue Apr 7 04:33:10 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 6 Apr 2009 19:33:10 -0700 Subject: [IronPython] Modifying The PYC Stub EXE In-Reply-To: <20253b0c0904061057y753d5976u33d97289b769ae30@mail.gmail.com> References: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD161C@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904061057y753d5976u33d97289b769ae30@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23555726DD19DE@NA-EXMSG-C102.redmond.corp.microsoft.com> Ahh, I see, you want to add something like: gen.EmitCall(OpCodes.Call, clr.GetClrType(Assembly).GetMethod("GetEntryAssembly"), ()); gen.EmitCall(OpCodes.Call, clr.GetClrType(Assembly).GetMethod("get_CodeBase"), ()); gen.Emit(OpCodes.Newobj, clr.GetClrType(System.Uri).GetConstructor( (str, ) )); gen.EmitCall(OpCodes.Call, clr.GetClrType(System.Uri).GetMethod("get_LocalPath"), ()); gen.Emit(OpCodes.Newobj, clr.GetClrType(System.IO.FileInfo).GetConstructor( (str, ) )) gen.EmitCall(OpCodes.Call, clr.GetClrType(System.IO.FileInfo).GetMethod("get_Directory"), ()) gen.EmitCall(OpCodes.Call, clr.GetClrType(System.IO.DirectoryInfo).GetMethod("get_FullName"), ()) gen.EmitCall(OpCodes.Call, clr.GetClrType(System.Environment).GetMethod("set_CurrentDirectory"), ()) right before we get the ScriptCode assembly in GenerateExe. It's really unfortunate that this is necessary. In theory we can burn a reference from your DLL into your EXE and have the CLR load the assembly and it should be able to pick it up w/o changing the CWD. The problem seems to be that we end up with "DIE.EXE" and "DIE.DLL" and it would appear the CLR always loads DIE.EXE and then it doesn't find the types in DIE.DLL. Presumably if we named them different this would work. Maybe we should enable naming them differently or maybe we should enable generating just one EXE instead of the wrapper EXE. Feel free to open a feature request - at the very least we can make an option to insert the above code :) > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Davy Mitchell > Sent: Monday, April 06, 2009 10:57 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Modifying The PYC Stub EXE > > Hi Dino, > > All the DLLs are in the Build directory. Everything runs great if the > CWD is the folder containing > the EXE. If you try and run it from another folder things go wrong > (File Not Found Exception). > > I've posted a basic repro on my Skydrive > http://cid- > 1c5b93086198f54e.skydrive.live.com/self.aspx/Public/hello.zip > > cd hello\build\ and die.exe will run > cd hello and run .\build\die.exe and it will fail > > Thanks, > Davy Mitchell > > On Mon, Apr 6, 2009 at 4:18 PM, Dino Viehland > wrote: > > What DLLs you want to be loaded?? The reason I ask is that .NET > assembly > > loading doesn't really work on the basis of the current working > directory - > > instead it looks at the app base which by default is where your EXE > is > > located.? We do modify sys.path so that IronPython can load things > outside > > of the app base but I wouldn't suggest pushing this too far.? Instead > I'd > > propose doing what a normal build process does and copy the DLLs into > the > > build directory. > > > > > > > > From: users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy > Mitchell > > Sent: Sunday, April 05, 2009 3:55 AM > > To: Discussion of IronPython > > Subject: [IronPython] Modifying The PYC Stub EXE > > > > > > > > Hi Folks, > > > > > > > > I am looking to modify the EXE stub generated by PYC so that it will > set the > > current working directory to the location of the EXE > > > > before loading its assemblies. > > > > > > > > The problem I am having is I build my EXE to a sub-folder called > BUILD. If I > > call it in the form .\build\die.exe then it can't find the DLLs. > > > > This can be worked around with shortcuts setting the working dir?etc > but > > having this option in code?in PYC would be useful. > > > > > > > > Forgive me if I am very very muddled up about something :-) > > > > > > > > Thanks, > > > > Davy Mitchell > > > > > > > > > > > > _______________________________________________ > > 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 daftspaniel at gmail.com Tue Apr 7 08:09:12 2009 From: daftspaniel at gmail.com (Davy Mitchell) Date: Tue, 7 Apr 2009 07:09:12 +0100 Subject: [IronPython] Modifying The PYC Stub EXE In-Reply-To: <350E7D38B6D819428718949920EC23555726DD19DE@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD161C@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904061057y753d5976u33d97289b769ae30@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD19DE@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <20253b0c0904062309w2246e791laf5889ce30e7f4c0@mail.gmail.com> Thanks Dino - will try it out when I get a chance. Davy On Tue, Apr 7, 2009 at 3:33 AM, Dino Viehland wrote: > Ahh, I see, you want to add something like: > > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(Assembly).GetMethod("GetEntryAssembly"), ()); > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(Assembly).GetMethod("get_CodeBase"), ()); > ? ?gen.Emit(OpCodes.Newobj, clr.GetClrType(System.Uri).GetConstructor( (str, ) )); > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(System.Uri).GetMethod("get_LocalPath"), ()); > ? ?gen.Emit(OpCodes.Newobj, clr.GetClrType(System.IO.FileInfo).GetConstructor( (str, ) )) > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(System.IO.FileInfo).GetMethod("get_Directory"), ()) > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(System.IO.DirectoryInfo).GetMethod("get_FullName"), ()) > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(System.Environment).GetMethod("set_CurrentDirectory"), ()) > > right before we get the ScriptCode assembly in GenerateExe. > > It's really unfortunate that this is necessary. ?In theory we can burn a reference from your DLL into your EXE and have the CLR load the assembly and it should be able to pick it up w/o changing the CWD. ?The problem seems to be that we end up with "DIE.EXE" and "DIE.DLL" and it would appear the CLR always loads DIE.EXE and then it doesn't find the types in DIE.DLL. ?Presumably if we named them different this would work. ?Maybe we should enable naming them differently or maybe we should enable generating just one EXE instead of the wrapper EXE. > > Feel free to open a feature request - at the very least we can make an option to insert the above code :) > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Davy Mitchell >> Sent: Monday, April 06, 2009 10:57 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Modifying The PYC Stub EXE >> >> Hi Dino, >> >> All the DLLs are in the Build directory. Everything runs great if the >> CWD is the folder containing >> the EXE. If you try and run it from another folder things go wrong >> (File Not Found Exception). >> >> I've posted a basic repro on my Skydrive >> http://cid- >> 1c5b93086198f54e.skydrive.live.com/self.aspx/Public/hello.zip >> >> cd hello\build\ and die.exe will run >> cd hello and run .\build\die.exe and it will fail >> >> Thanks, >> Davy Mitchell >> >> On Mon, Apr 6, 2009 at 4:18 PM, Dino Viehland >> wrote: >> > What DLLs you want to be loaded?? The reason I ask is that .NET >> assembly >> > loading doesn't really work on the basis of the current working >> directory - >> > instead it looks at the app base which by default is where your EXE >> is >> > located.? We do modify sys.path so that IronPython can load things >> outside >> > of the app base but I wouldn't suggest pushing this too far.? Instead >> I'd >> > propose doing what a normal build process does and copy the DLLs into >> the >> > build directory. >> > >> > >> > >> > From: users-bounces at lists.ironpython.com >> > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy >> Mitchell >> > Sent: Sunday, April 05, 2009 3:55 AM >> > To: Discussion of IronPython >> > Subject: [IronPython] Modifying The PYC Stub EXE >> > >> > >> > >> > Hi Folks, >> > >> > >> > >> > I am looking to modify the EXE stub generated by PYC so that it will >> set the >> > current working directory to the location of the EXE >> > >> > before loading its assemblies. >> > >> > >> > >> > The problem I am having is I build my EXE to a sub-folder called >> BUILD. If I >> > call it in the form .\build\die.exe then it can't find the DLLs. >> > >> > This can be worked around with shortcuts setting the working dir?etc >> but >> > having this option in code?in PYC would be useful. >> > >> > >> > >> > Forgive me if I am very very muddled up about something :-) >> > >> > >> > >> > Thanks, >> > >> > Davy Mitchell >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 dhendricks at msn.com Wed Apr 8 20:34:35 2009 From: dhendricks at msn.com (Daryl Hendricks) Date: Wed, 8 Apr 2009 14:34:35 -0400 Subject: [IronPython] IronPython Studio Xaml editor issue Message-ID: Hello, I'm running into a problem where I can't use the XAML editor in the isolated version of IronPython Studio. The error I'm getting is "Package 'Microsoft.VisualStudio.Xaml' has failed to load ( GUID = {E58C2A8B-BCC4-4559-AD59-D62EB6D58A22} )" Can anyone offer some guidance as to how to fix this? The XAML displays but the designer is not available. Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From daftspaniel at gmail.com Wed Apr 8 22:10:38 2009 From: daftspaniel at gmail.com (Davy Mitchell) Date: Wed, 8 Apr 2009 21:10:38 +0100 Subject: [IronPython] Modifying The PYC Stub EXE In-Reply-To: <350E7D38B6D819428718949920EC23555726DD19DE@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD161C@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904061057y753d5976u33d97289b769ae30@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD19DE@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <20253b0c0904081310o419fde0fp25b31189402b2fc5@mail.gmail.com> Hi Dino, Thanks works great - you confused me with the semi-colons :-) Thanks Bruce too - your posts re:sys.argv were useful in looking at this. I'll raise a feature request of some sort. Is PYC ever likely to become part of the standard install? In case it is of use to anyone, I've put my modified PYC on my skydrive. Also has a modification for STA as I use the webcontrol in DIE. http://cid-1c5b93086198f54e.skydrive.live.com/self.aspx/Public/pyc.py Regards, Davy Mitchell On Tue, Apr 7, 2009 at 3:33 AM, Dino Viehland wrote: > Ahh, I see, you want to add something like: > > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(Assembly).GetMethod("GetEntryAssembly"), ()); > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(Assembly).GetMethod("get_CodeBase"), ()); > ? ?gen.Emit(OpCodes.Newobj, clr.GetClrType(System.Uri).GetConstructor( (str, ) )); > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(System.Uri).GetMethod("get_LocalPath"), ()); > ? ?gen.Emit(OpCodes.Newobj, clr.GetClrType(System.IO.FileInfo).GetConstructor( (str, ) )) > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(System.IO.FileInfo).GetMethod("get_Directory"), ()) > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(System.IO.DirectoryInfo).GetMethod("get_FullName"), ()) > ? ?gen.EmitCall(OpCodes.Call, clr.GetClrType(System.Environment).GetMethod("set_CurrentDirectory"), ()) > > right before we get the ScriptCode assembly in GenerateExe. > > It's really unfortunate that this is necessary. ?In theory we can burn a reference from your DLL into your EXE and have the CLR load the assembly and it should be able to pick it up w/o changing the CWD. ?The problem seems to be that we end up with "DIE.EXE" and "DIE.DLL" and it would appear the CLR always loads DIE.EXE and then it doesn't find the types in DIE.DLL. ?Presumably if we named them different this would work. ?Maybe we should enable naming them differently or maybe we should enable generating just one EXE instead of the wrapper EXE. > > Feel free to open a feature request - at the very least we can make an option to insert the above code :) > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Davy Mitchell >> Sent: Monday, April 06, 2009 10:57 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Modifying The PYC Stub EXE >> >> Hi Dino, >> >> All the DLLs are in the Build directory. Everything runs great if the >> CWD is the folder containing >> the EXE. If you try and run it from another folder things go wrong >> (File Not Found Exception). >> >> I've posted a basic repro on my Skydrive >> http://cid- >> 1c5b93086198f54e.skydrive.live.com/self.aspx/Public/hello.zip >> >> cd hello\build\ and die.exe will run >> cd hello and run .\build\die.exe and it will fail >> >> Thanks, >> Davy Mitchell >> >> On Mon, Apr 6, 2009 at 4:18 PM, Dino Viehland >> wrote: >> > What DLLs you want to be loaded?? The reason I ask is that .NET >> assembly >> > loading doesn't really work on the basis of the current working >> directory - >> > instead it looks at the app base which by default is where your EXE >> is >> > located.? We do modify sys.path so that IronPython can load things >> outside >> > of the app base but I wouldn't suggest pushing this too far.? Instead >> I'd >> > propose doing what a normal build process does and copy the DLLs into >> the >> > build directory. >> > >> > >> > >> > From: users-bounces at lists.ironpython.com >> > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy >> Mitchell >> > Sent: Sunday, April 05, 2009 3:55 AM >> > To: Discussion of IronPython >> > Subject: [IronPython] Modifying The PYC Stub EXE >> > >> > >> > >> > Hi Folks, >> > >> > >> > >> > I am looking to modify the EXE stub generated by PYC so that it will >> set the >> > current working directory to the location of the EXE >> > >> > before loading its assemblies. >> > >> > >> > >> > The problem I am having is I build my EXE to a sub-folder called >> BUILD. If I >> > call it in the form .\build\die.exe then it can't find the DLLs. >> > >> > This can be worked around with shortcuts setting the working dir?etc >> but >> > having this option in code?in PYC would be useful. >> > >> > >> > >> > Forgive me if I am very very muddled up about something :-) >> > >> > >> > >> > Thanks, >> > >> > Davy Mitchell >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 dfugate at microsoft.com Wed Apr 8 22:19:42 2009 From: dfugate at microsoft.com (Dave Fugate) Date: Wed, 8 Apr 2009 13:19:42 -0700 Subject: [IronPython] Modifying The PYC Stub EXE In-Reply-To: <20253b0c0904081310o419fde0fp25b31189402b2fc5@mail.gmail.com> References: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD161C@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904061057y753d5976u33d97289b769ae30@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD19DE@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904081310o419fde0fp25b31189402b2fc5@mail.gmail.com> Message-ID: I've been working on making this happen for a few days now. It should be available in the IronPython_Main branch on CodePlex's TFS server within a day or so. Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Wednesday, April 08, 2009 1:11 PM To: Discussion of IronPython Subject: Re: [IronPython] Modifying The PYC Stub EXE Is PYC ever likely to become part of the standard install? From dinov at microsoft.com Wed Apr 8 22:31:45 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 8 Apr 2009 13:31:45 -0700 Subject: [IronPython] Modifying The PYC Stub EXE In-Reply-To: <20253b0c0904081310o419fde0fp25b31189402b2fc5@mail.gmail.com> References: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD161C@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904061057y753d5976u33d97289b769ae30@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD19DE@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904081310o419fde0fp25b31189402b2fc5@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23555726F04B58@NA-EXMSG-C102.redmond.corp.microsoft.com> Doh! The semi-colons are there because I really wanted intellisense while writing that code :) > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Davy Mitchell > Sent: Wednesday, April 08, 2009 1:11 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Modifying The PYC Stub EXE > > Hi Dino, > > Thanks works great - you confused me with the semi-colons :-) Thanks > Bruce too - your posts > re:sys.argv were useful in looking at this. > > I'll raise a feature request of some sort. Is PYC ever likely to > become part of the standard install? > > In case it is of use to anyone, I've put my modified PYC on my > skydrive. Also has a modification for STA as I use the webcontrol in > DIE. > > http://cid-1c5b93086198f54e.skydrive.live.com/self.aspx/Public/pyc.py > > Regards, > Davy Mitchell > > On Tue, Apr 7, 2009 at 3:33 AM, Dino Viehland > wrote: > > Ahh, I see, you want to add something like: > > > > ? ?gen.EmitCall(OpCodes.Call, > clr.GetClrType(Assembly).GetMethod("GetEntryAssembly"), ()); > > ? ?gen.EmitCall(OpCodes.Call, > clr.GetClrType(Assembly).GetMethod("get_CodeBase"), ()); > > ? ?gen.Emit(OpCodes.Newobj, > clr.GetClrType(System.Uri).GetConstructor( (str, ) )); > > ? ?gen.EmitCall(OpCodes.Call, > clr.GetClrType(System.Uri).GetMethod("get_LocalPath"), ()); > > ? ?gen.Emit(OpCodes.Newobj, > clr.GetClrType(System.IO.FileInfo).GetConstructor( (str, ) )) > > ? ?gen.EmitCall(OpCodes.Call, > clr.GetClrType(System.IO.FileInfo).GetMethod("get_Directory"), ()) > > ? ?gen.EmitCall(OpCodes.Call, > clr.GetClrType(System.IO.DirectoryInfo).GetMethod("get_FullName"), ()) > > ? ?gen.EmitCall(OpCodes.Call, > clr.GetClrType(System.Environment).GetMethod("set_CurrentDirectory"), > ()) > > > > right before we get the ScriptCode assembly in GenerateExe. > > > > It's really unfortunate that this is necessary. ?In theory we can > burn a reference from your DLL into your EXE and have the CLR load the > assembly and it should be able to pick it up w/o changing the CWD. ?The > problem seems to be that we end up with "DIE.EXE" and "DIE.DLL" and it > would appear the CLR always loads DIE.EXE and then it doesn't find the > types in DIE.DLL. ?Presumably if we named them different this would > work. ?Maybe we should enable naming them differently or maybe we > should enable generating just one EXE instead of the wrapper EXE. > > > > Feel free to open a feature request - at the very least we can make > an option to insert the above code :) > > > >> -----Original Message----- > >> From: users-bounces at lists.ironpython.com [mailto:users- > >> bounces at lists.ironpython.com] On Behalf Of Davy Mitchell > >> Sent: Monday, April 06, 2009 10:57 AM > >> To: Discussion of IronPython > >> Subject: Re: [IronPython] Modifying The PYC Stub EXE > >> > >> Hi Dino, > >> > >> All the DLLs are in the Build directory. Everything runs great if > the > >> CWD is the folder containing > >> the EXE. If you try and run it from another folder things go wrong > >> (File Not Found Exception). > >> > >> I've posted a basic repro on my Skydrive > >> http://cid- > >> 1c5b93086198f54e.skydrive.live.com/self.aspx/Public/hello.zip > >> > >> cd hello\build\ and die.exe will run > >> cd hello and run .\build\die.exe and it will fail > >> > >> Thanks, > >> Davy Mitchell > >> > >> On Mon, Apr 6, 2009 at 4:18 PM, Dino Viehland > >> wrote: > >> > What DLLs you want to be loaded?? The reason I ask is that .NET > >> assembly > >> > loading doesn't really work on the basis of the current working > >> directory - > >> > instead it looks at the app base which by default is where your > EXE > >> is > >> > located.? We do modify sys.path so that IronPython can load things > >> outside > >> > of the app base but I wouldn't suggest pushing this too far. > Instead > >> I'd > >> > propose doing what a normal build process does and copy the DLLs > into > >> the > >> > build directory. > >> > > >> > > >> > > >> > From: users-bounces at lists.ironpython.com > >> > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy > >> Mitchell > >> > Sent: Sunday, April 05, 2009 3:55 AM > >> > To: Discussion of IronPython > >> > Subject: [IronPython] Modifying The PYC Stub EXE > >> > > >> > > >> > > >> > Hi Folks, > >> > > >> > > >> > > >> > I am looking to modify the EXE stub generated by PYC so that it > will > >> set the > >> > current working directory to the location of the EXE > >> > > >> > before loading its assemblies. > >> > > >> > > >> > > >> > The problem I am having is I build my EXE to a sub-folder called > >> BUILD. If I > >> > call it in the form .\build\die.exe then it can't find the DLLs. > >> > > >> > This can be worked around with shortcuts setting the working > dir?etc > >> but > >> > having this option in code?in PYC would be useful. > >> > > >> > > >> > > >> > Forgive me if I am very very muddled up about something :-) > >> > > >> > > >> > > >> > Thanks, > >> > > >> > Davy Mitchell > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Users mailing list > >> > Users at lists.ironpython.com > >> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >> > > >> > > >> _______________________________________________ > >> Users mailing list > >> Users at lists.ironpython.com > >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Wed Apr 8 22:35:19 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 8 Apr 2009 13:35:19 -0700 Subject: [IronPython] PYC and 2.6 A1 In-Reply-To: <20253b0c0903311352pbb35055sa9bcbbdbb0623c8e@mail.gmail.com> References: <20253b0c0903311352pbb35055sa9bcbbdbb0623c8e@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23555726F04B5A@NA-EXMSG-C102.redmond.corp.microsoft.com> This is fixed now so pre-compilation is working again in the current 2.6 sources. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Tuesday, March 31, 2009 1:52 PM To: Discussion of IronPython Subject: [IronPython] PYC and 2.6 A1 Hi Guys, Are there known issues with PYC and IPY 2.6 A1? When my exe compiles, I get: Unhandled Exception: Microsoft.Scripting.Runtime.UnboundNameException: name 'ThreadExceptionEventArgs' is not defined at Microsoft.Scripting.Actions.Calls.MethodTarget.Caller.Call(Object[] args, Boolean& shouldOptimize) at IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`6.Call5(CallSite site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) at Microsoft.Scripting.UpdateDelegates.UpdateAndExecute7[T0,T1,T2,T3,T4,T5,T6,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6) at IronPython.Runtime.Importer.Import(CodeContext context, String fullName, PythonTuple from, Int32 level) at IronPython.Runtime.Operations.PythonOps.InitializeModule(Assembly precompiled, String main, String[] references) at PythonMain.Main() Works fine in 2.01. Thanks, Davy Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed Apr 8 22:35:19 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 8 Apr 2009 13:35:19 -0700 Subject: [IronPython] PYC and 2.6 A1 In-Reply-To: <20253b0c0903311352pbb35055sa9bcbbdbb0623c8e@mail.gmail.com> References: <20253b0c0903311352pbb35055sa9bcbbdbb0623c8e@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23555726F04B5A@NA-EXMSG-C102.redmond.corp.microsoft.com> This is fixed now so pre-compilation is working again in the current 2.6 sources. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Tuesday, March 31, 2009 1:52 PM To: Discussion of IronPython Subject: [IronPython] PYC and 2.6 A1 Hi Guys, Are there known issues with PYC and IPY 2.6 A1? When my exe compiles, I get: Unhandled Exception: Microsoft.Scripting.Runtime.UnboundNameException: name 'ThreadExceptionEventArgs' is not defined at Microsoft.Scripting.Actions.Calls.MethodTarget.Caller.Call(Object[] args, Boolean& shouldOptimize) at IronPython.Runtime.Types.BuiltinFunction.BuiltinFunctionCaller`6.Call5(CallSite site, CodeContext context, TFuncType func, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) at Microsoft.Scripting.UpdateDelegates.UpdateAndExecute7[T0,T1,T2,T3,T4,T5,T6,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6) at IronPython.Runtime.Importer.Import(CodeContext context, String fullName, PythonTuple from, Int32 level) at IronPython.Runtime.Operations.PythonOps.InitializeModule(Assembly precompiled, String main, String[] references) at PythonMain.Main() Works fine in 2.01. Thanks, Davy Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From daftspaniel at gmail.com Wed Apr 8 22:38:39 2009 From: daftspaniel at gmail.com (Davy Mitchell) Date: Wed, 8 Apr 2009 21:38:39 +0100 Subject: [IronPython] Modifying The PYC Stub EXE In-Reply-To: References: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD161C@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904061057y753d5976u33d97289b769ae30@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD19DE@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904081310o419fde0fp25b31189402b2fc5@mail.gmail.com> Message-ID: <20253b0c0904081338j77214de1ue3a8066ab9ae23ef@mail.gmail.com> Dave - +1 :-) On Wed, Apr 8, 2009 at 9:19 PM, Dave Fugate wrote: > I've been working on making this happen for a few days now. ?It should be available in the IronPython_Main branch on CodePlex's TFS server within a day or so. > > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell > Sent: Wednesday, April 08, 2009 1:11 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Modifying The PYC Stub EXE > > > Is PYC ever likely to become part of the standard install? > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dfugate at microsoft.com Thu Apr 9 17:42:28 2009 From: dfugate at microsoft.com (Dave Fugate) Date: Thu, 9 Apr 2009 08:42:28 -0700 Subject: [IronPython] Modifying The PYC Stub EXE In-Reply-To: <20253b0c0904081338j77214de1ue3a8066ab9ae23ef@mail.gmail.com> References: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD161C@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904061057y753d5976u33d97289b769ae30@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD19DE@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904081310o419fde0fp25b31189402b2fc5@mail.gmail.com> <20253b0c0904081338j77214de1ue3a8066ab9ae23ef@mail.gmail.com> Message-ID: Pyc.py is now in TFS on CodePlex, $/IronPython/IronPython_Main/Tools/Scripts/pyc.py, and a few related tests have been added to our checkin system ensuring this doesn't get broken in the future. Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Wednesday, April 08, 2009 1:39 PM To: Discussion of IronPython Subject: Re: [IronPython] Modifying The PYC Stub EXE Dave - +1 :-) On Wed, Apr 8, 2009 at 9:19 PM, Dave Fugate wrote: > I've been working on making this happen for a few days now. ?It should be available in the IronPython_Main branch on CodePlex's TFS server within a day or so. > > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell > Sent: Wednesday, April 08, 2009 1:11 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Modifying The PYC Stub EXE > > > Is PYC ever likely to become part of the standard install? > > > _______________________________________________ > 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 anleewxs at gmail.com Thu Apr 9 18:14:24 2009 From: anleewxs at gmail.com (Alex News) Date: Thu, 9 Apr 2009 12:14:24 -0400 Subject: [IronPython] RuntimeType from PythonType in C# code Message-ID: <2c77c440904090914x9ca588j5f5c1c6656070c3@mail.gmail.com> I have embedded IronPython 2.01 into my C# application, and am extremely impressed by the ease of integration and the interoperability with the .NET types. However I am a bit stumped by something that probably is quite simple. 1) In a python script, I import one of my application types. 2) From that script I call a function implemented in C#. I pass in the type (not an instance of the type) 3) My C# function sees a PythonType. I would like to get the associated RuntimeType, but can't figure out how to do so. For example (using a system type): python: from System import String myfunction(String) # calls C# delegate defined below C#: delegate(object o) { // o is of type PythonType. I would like to get the associated System.RuntimeType (in this case System.String) } I've searched the web, but most of the advice seems outdated: PythonType.UnderlyingSystemType is internal, so I can't access it. http://lists.ironpython.com/pipermail/users-ironpython.com/2007-December/006130.html I'm not sure what "Ops" is. I suspect it is related to the namespace IronPython.Runtime.Operations, but I can't find an equivalent class/function in there (although there is quite a bit there, so I may have missed it). http://lists.ironpython.com/pipermail/users-ironpython.com/2005-May/000668.html Any help would be greatly appreciated. Thanks, Alex From dinov at microsoft.com Thu Apr 9 18:19:17 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 9 Apr 2009 09:19:17 -0700 Subject: [IronPython] RuntimeType from PythonType in C# code In-Reply-To: <2c77c440904090914x9ca588j5f5c1c6656070c3@mail.gmail.com> References: <2c77c440904090914x9ca588j5f5c1c6656070c3@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23555726F04D74@NA-EXMSG-C102.redmond.corp.microsoft.com> There is an implicit conversion from PythonType -> Type. So (Type)(PythonType)o will work here. Alternately you can just strongly type a function in C# as taking a Type and call that from Python and the conversion will happen automatically. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Alex News > Sent: Thursday, April 09, 2009 9:14 AM > To: users at lists.ironpython.com > Subject: [IronPython] RuntimeType from PythonType in C# code > > I have embedded IronPython 2.01 into my C# application, and am > extremely impressed by the ease of integration and the > interoperability with the .NET types. However I am a bit stumped by > something that probably is quite simple. > > 1) In a python script, I import one of my application types. > 2) From that script I call a function implemented in C#. I pass in > the type (not an instance of the type) > 3) My C# function sees a PythonType. I would like to get the > associated RuntimeType, but can't figure out how to do so. > > For example (using a system type): > > python: > from System import String > myfunction(String) # calls C# delegate defined below > > C#: > delegate(object o) > { > // o is of type PythonType. I would like to get the associated > System.RuntimeType (in this case System.String) > } > > I've searched the web, but most of the advice seems outdated: > > PythonType.UnderlyingSystemType is internal, so I can't access it. > http://lists.ironpython.com/pipermail/users-ironpython.com/2007- > December/006130.html > > I'm not sure what "Ops" is. I suspect it is related to the namespace > IronPython.Runtime.Operations, but I can't find an equivalent > class/function in there (although there is quite a bit there, so I may > have missed it). > http://lists.ironpython.com/pipermail/users-ironpython.com/2005- > May/000668.html > > Any help would be greatly appreciated. > > Thanks, > Alex > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From anleewxs at gmail.com Thu Apr 9 19:41:49 2009 From: anleewxs at gmail.com (Alex News) Date: Thu, 9 Apr 2009 13:41:49 -0400 Subject: [IronPython] RuntimeType from PythonType in C# code In-Reply-To: <350E7D38B6D819428718949920EC23555726F04D74@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <2c77c440904090914x9ca588j5f5c1c6656070c3@mail.gmail.com> <350E7D38B6D819428718949920EC23555726F04D74@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <2c77c440904091041x36b84972iba70d79eaf1bf807@mail.gmail.com> Excellent! Thanks. On Thu, Apr 9, 2009 at 12:19 PM, Dino Viehland wrote: > There is an implicit conversion from PythonType -> Type. ?So (Type)(PythonType)o will work here. ?Alternately you can just strongly type a function in C# as taking a Type and call that from Python and the conversion will happen automatically. > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Alex News >> Sent: Thursday, April 09, 2009 9:14 AM >> To: users at lists.ironpython.com >> Subject: [IronPython] RuntimeType from PythonType in C# code >> >> I have embedded IronPython 2.01 into my C# application, and am >> extremely impressed by the ease of integration and the >> interoperability with the .NET types. ?However I am a bit stumped by >> something that probably is quite simple. >> >> 1) In a python script, I import one of my application types. >> 2) From that script I call a function implemented in C#. ?I pass in >> the type (not an instance of the type) >> 3) My C# function sees a PythonType. ?I would like to get the >> associated RuntimeType, but can't figure out how to do so. >> >> For example (using a system type): >> >> python: >> from System import String >> myfunction(String) ?# calls C# delegate defined below >> >> C#: >> delegate(object o) >> { >> ? // o is of type PythonType. ?I would like to get the associated >> System.RuntimeType ?(in this case System.String) >> } >> >> I've searched the web, but most of the advice seems outdated: >> >> PythonType.UnderlyingSystemType is internal, so I can't access it. >> http://lists.ironpython.com/pipermail/users-ironpython.com/2007- >> December/006130.html >> >> I'm not sure what "Ops" is. ?I suspect it is related to the namespace >> IronPython.Runtime.Operations, but I can't find an equivalent >> class/function in there (although there is quite a bit there, so I may >> have missed it). >> http://lists.ironpython.com/pipermail/users-ironpython.com/2005- >> May/000668.html >> >> Any help would be greatly appreciated. >> >> Thanks, >> Alex >> _______________________________________________ >> 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 daftspaniel at gmail.com Thu Apr 9 21:28:10 2009 From: daftspaniel at gmail.com (Davy Mitchell) Date: Thu, 9 Apr 2009 20:28:10 +0100 Subject: [IronPython] Modifying The PYC Stub EXE In-Reply-To: References: <20253b0c0904050354s2a951d54ne285883fc4ea51aa@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD161C@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904061057y753d5976u33d97289b769ae30@mail.gmail.com> <350E7D38B6D819428718949920EC23555726DD19DE@NA-EXMSG-C102.redmond.corp.microsoft.com> <20253b0c0904081310o419fde0fp25b31189402b2fc5@mail.gmail.com> <20253b0c0904081338j77214de1ue3a8066ab9ae23ef@mail.gmail.com> Message-ID: <20253b0c0904091228g1ecda059g702a48a32ea193bd@mail.gmail.com> For the archives, this is raised as: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21987 On Thu, Apr 9, 2009 at 4:42 PM, Dave Fugate wrote: > Pyc.py is now in TFS on CodePlex, $/IronPython/IronPython_Main/Tools/Scripts/pyc.py, and a few related tests have been added to our checkin system ensuring this doesn't get broken in the future. > > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell > Sent: Wednesday, April 08, 2009 1:39 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Modifying The PYC Stub EXE > > Dave - +1 :-) > > On Wed, Apr 8, 2009 at 9:19 PM, Dave Fugate wrote: >> I've been working on making this happen for a few days now. ?It should be available in the IronPython_Main branch on CodePlex's TFS server within a day or so. >> >> Dave >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell >> Sent: Wednesday, April 08, 2009 1:11 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Modifying The PYC Stub EXE >> >> >> Is PYC ever likely to become part of the standard install? >> >> >> _______________________________________________ >> 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 curt at hagenlocher.org Thu Apr 9 22:57:50 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 9 Apr 2009 13:57:50 -0700 Subject: [IronPython] IronPython Studio Xaml editor issue In-Reply-To: References: Message-ID: Has it ever worked for you or have you always gotten this error? On Wed, Apr 8, 2009 at 11:34 AM, Daryl Hendricks wrote: > Hello, > > I'm running into a problem where I can't use the XAML editor in the > isolated version of IronPython Studio. The error I'm getting is "Package > 'Microsoft.VisualStudio.Xaml' has failed to load ( GUID = > {E58C2A8B-BCC4-4559-AD59-D62EB6D58A22} )" Can anyone offer some guidance as > to how to fix this? The XAML displays but the designer is not available. > > > > Thanks in advance > > > > > > _______________________________________________ > 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 curt at hagenlocher.org Thu Apr 9 23:00:09 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 9 Apr 2009 14:00:09 -0700 Subject: [IronPython] with_statement in IronPython for ASP.Net? In-Reply-To: <8bd92c0e0904031201t6925995aub0a85416bfafa42e@mail.gmail.com> References: <8bd92c0e0904031201t6925995aub0a85416bfafa42e@mail.gmail.com> Message-ID: IronPython 2 targets CPython 2.5 compatibility. In 2.5, you need the __future__ line in order to use the "with" statement. It's quite possible that this wasn't implemented yet in that alpha or beta of IronPython. It's in 2.6 where you don't need the "from __future__ import with_statement". On Fri, Apr 3, 2009 at 12:01 PM, Adam Brand wrote: > Using IronPython for ASP.Net, trying to use: > from __future__ import with_statement > > ...get the message: > future feature is not defined:with_statement > > Have put the __future__.py file in the directory that py file is in as well > as my lib folder. > > Any ideas? I saw some references to needing to put the switch -X:Python25, > but I think that was for earlier versions of IPY. AFAIK the IP for ASP.NETis IronPython 2, Alpha 1...I'm thinking that one shouldn't need the switch? > > > Thanks, > Adam > > _______________________________________________ > 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 adamb at silverkeytech.com Fri Apr 10 00:25:53 2009 From: adamb at silverkeytech.com (Adam Brand) Date: Thu, 9 Apr 2009 15:25:53 -0700 Subject: [IronPython] with_statement in IronPython for ASP.Net? In-Reply-To: References: <8bd92c0e0904031201t6925995aub0a85416bfafa42e@mail.gmail.com> Message-ID: <022701c9b962$2669eee0$733dcca0$@com> Yeah this is a really weird issue; Jimmy mentioned he would look into it. Will post back to the list when we find out what the deal was. Adam Adam Brand SilverKey Technologies From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Thursday, April 09, 2009 2:00 PM To: Discussion of IronPython Subject: Re: [IronPython] with_statement in IronPython for ASP.Net? IronPython 2 targets CPython 2.5 compatibility. In 2.5, you need the __future__ line in order to use the "with" statement. It's quite possible that this wasn't implemented yet in that alpha or beta of IronPython. It's in 2.6 where you don't need the "from __future__ import with_statement". On Fri, Apr 3, 2009 at 12:01 PM, Adam Brand wrote: Using IronPython for ASP.Net, trying to use: from __future__ import with_statement ...get the message: future feature is not defined:with_statement Have put the __future__.py file in the directory that py file is in as well as my lib folder. Any ideas? I saw some references to needing to put the switch -X:Python25, but I think that was for earlier versions of IPY. AFAIK the IP for ASP.NET is IronPython 2, Alpha 1...I'm thinking that one shouldn't need the switch? Thanks, Adam _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Fri Apr 10 20:17:22 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 10 Apr 2009 19:17:22 +0100 Subject: [IronPython] IronPython in Action Out! Message-ID: <49DF8D32.2000402@voidspace.org.uk> Hello all, *Finally* IronPython in Action is out. This is the first English language book on IronPython and is now in stock with Manning and Amazon.com and on the Safari bookshelf. You can get all the details from: * http://www.ironpythoninaction.com It covers a whole range of topics, with introductions to Python and .NET, using various Python libraries and .NET framework classes, web development with ASP.NET, Silverlight and web services, plus topics like WPF, testing, metaprogramming, system administration, embedding IronPython in .NET applications and so on. The foreword is by Jim Hugunin and Dino Viehland is the technical editor. Many thanks to all those who helped, including those who gave feedback during the early access program. All the best, Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From Shri.Borde at microsoft.com Fri Apr 10 21:09:55 2009 From: Shri.Borde at microsoft.com (Shri Borde) Date: Fri, 10 Apr 2009 12:09:55 -0700 Subject: [IronPython] IronPython in Action Out! In-Reply-To: <49DF8D32.2000402@voidspace.org.uk> References: <49DF8D32.2000402@voidspace.org.uk> Message-ID: <710DF26F214D2B4BB94287123FFE980A2E162FC3FA@NA-EXMSG-C104.redmond.corp.microsoft.com> Congratulations! This is very exciting! -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, April 10, 2009 11:17 AM To: Discussion of IronPython Subject: [IronPython] IronPython in Action Out! Hello all, *Finally* IronPython in Action is out. This is the first English language book on IronPython and is now in stock with Manning and Amazon.com and on the Safari bookshelf. You can get all the details from: * http://www.ironpythoninaction.com It covers a whole range of topics, with introductions to Python and .NET, using various Python libraries and .NET framework classes, web development with ASP.NET, Silverlight and web services, plus topics like WPF, testing, metaprogramming, system administration, embedding IronPython in .NET applications and so on. The foreword is by Jim Hugunin and Dino Viehland is the technical editor. Many thanks to all those who helped, including those who gave feedback during the early access program. All the best, Michael Foord -- 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 g3scom at gmail.com Sat Apr 11 03:48:04 2009 From: g3scom at gmail.com (David Seruyange) Date: Fri, 10 Apr 2009 18:48:04 -0700 Subject: [IronPython] IronPython in Action Out! In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2E162FC3FA@NA-EXMSG-C104.redmond.corp.microsoft.com> References: <49DF8D32.2000402@voidspace.org.uk> <710DF26F214D2B4BB94287123FFE980A2E162FC3FA@NA-EXMSG-C104.redmond.corp.microsoft.com> Message-ID: Congrats although I was able to get a copy early (about 2 weeks ago) directly from Manning. Paid full price, I hope that somehow trickles back to you :) David On Fri, Apr 10, 2009 at 12:09 PM, Shri Borde wrote: > Congratulations! This is very exciting! > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, April 10, 2009 11:17 AM > To: Discussion of IronPython > Subject: [IronPython] IronPython in Action Out! > > Hello all, > > *Finally* IronPython in Action is out. This is the first English > language book on IronPython and is now in stock with Manning and > Amazon.com and on the Safari bookshelf. You can get all the details from: > > * http://www.ironpythoninaction.com > > It covers a whole range of topics, with introductions to Python and > .NET, using various Python libraries and .NET framework classes, web > development with ASP.NET, Silverlight and web services, plus topics like > WPF, testing, metaprogramming, system administration, embedding > IronPython in .NET applications and so on. > > The foreword is by Jim Hugunin and Dino Viehland is the technical editor. > > Many thanks to all those who helped, including those who gave feedback > during the early access program. > > All the best, > > Michael Foord > > -- > 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 fuzzyman at voidspace.org.uk Sat Apr 11 03:53:59 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 11 Apr 2009 02:53:59 +0100 Subject: [IronPython] IronPython in Action Out! In-Reply-To: References: <49DF8D32.2000402@voidspace.org.uk> <710DF26F214D2B4BB94287123FFE980A2E162FC3FA@NA-EXMSG-C104.redmond.corp.microsoft.com> Message-ID: <49DFF837.9000903@voidspace.org.uk> David Seruyange wrote: > Congrats although I was able to get a copy early (about 2 weeks ago) > directly from Manning. Paid full price, I hope that somehow trickles > back to you :) Some proportion comes back - god knows no-one writes technical books to get rich though! I do slightly better if you buy it through one of the links on http://www.ironpythoninaction.com/ It has been a long journey getting to this point, so at the moment all that matters is people reading it - and hopefully finding it useful! All the best, Michael > > David > > On Fri, Apr 10, 2009 at 12:09 PM, Shri Borde > wrote: > > Congratulations! This is very exciting! > > -----Original Message----- > From: users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com > ] On Behalf Of Michael > Foord > Sent: Friday, April 10, 2009 11:17 AM > To: Discussion of IronPython > Subject: [IronPython] IronPython in Action Out! > > Hello all, > > *Finally* IronPython in Action is out. This is the first English > language book on IronPython and is now in stock with Manning and > Amazon.com and on the Safari bookshelf. You can get all the > details from: > > * http://www.ironpythoninaction.com > > It covers a whole range of topics, with introductions to Python and > .NET, using various Python libraries and .NET framework classes, web > development with ASP.NET , Silverlight and web > services, plus topics like > WPF, testing, metaprogramming, system administration, embedding > IronPython in .NET applications and so on. > > The foreword is by Jim Hugunin and Dino Viehland is the technical > editor. > > Many thanks to all those who helped, including those who gave feedback > during the early access program. > > All the best, > > Michael Foord > > -- > 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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 dhendricks at msn.com Sat Apr 11 04:12:45 2009 From: dhendricks at msn.com (Daryl Hendricks) Date: Fri, 10 Apr 2009 22:12:45 -0400 Subject: [IronPython] IronPython Studio Xaml editor issue Message-ID: Yep, it did work but I'm thinking that some of the VS and .NET updates since that point could have created a problem. >Has it ever worked for you or have you always gotten this error? > >On Wed, Apr 8, 2009 at 11:34 AM, Daryl Hendricks wrote: >> Hello, >> >> I'm running into a problem where I can't use the XAML editor in the >> isolated version of IronPython Studio. The error I'm getting is >> "Package 'Microsoft.VisualStudio.Xaml' has failed to load ( GUID = >> {E58C2A8B-BCC4-4559-AD59-D62EB6D58A22} )" Can anyone offer some >> guidance as to how to fix this? The XAML displays but the designer is not available. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Sat Apr 11 13:39:48 2009 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Sat, 11 Apr 2009 13:39:48 +0200 Subject: [IronPython] IronPython in Action Out! In-Reply-To: <49DFF837.9000903@voidspace.org.uk> References: <49DF8D32.2000402@voidspace.org.uk> <710DF26F214D2B4BB94287123FFE980A2E162FC3FA@NA-EXMSG-C104.redmond.corp.microsoft.com> <49DFF837.9000903@voidspace.org.uk> Message-ID: <8cd017b80904110439r69236b87m66f9a335bfdb3576@mail.gmail.com> Congratulation! On Sat, Apr 11, 2009 at 3:53 AM, Michael Foord wrote: > David Seruyange wrote: > >> Congrats although I was able to get a copy early (about 2 weeks ago) >> directly from Manning. Paid full price, I hope that somehow trickles back to >> you :) >> > > Some proportion comes back - god knows no-one writes technical books to get > rich though! I do slightly better if you buy it through one of the links on > http://www.ironpythoninaction.com/ > > It has been a long journey getting to this point, so at the moment all that > matters is people reading it - and hopefully finding it useful! > > All the best, > > Michael > > >> David >> >> On Fri, Apr 10, 2009 at 12:09 PM, Shri Borde > Shri.Borde at microsoft.com>> wrote: >> >> Congratulations! This is very exciting! >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com >> >> [mailto:users-bounces at lists.ironpython.com >> ] On Behalf Of Michael >> Foord >> Sent: Friday, April 10, 2009 11:17 AM >> To: Discussion of IronPython >> Subject: [IronPython] IronPython in Action Out! >> >> Hello all, >> >> *Finally* IronPython in Action is out. This is the first English >> language book on IronPython and is now in stock with Manning and >> Amazon.com and on the Safari bookshelf. You can get all the >> details from: >> >> * http://www.ironpythoninaction.com >> >> It covers a whole range of topics, with introductions to Python and >> .NET, using various Python libraries and .NET framework classes, web >> development with ASP.NET , Silverlight and web >> services, plus topics like >> WPF, testing, metaprogramming, system administration, embedding >> IronPython in .NET applications and so on. >> >> The foreword is by Jim Hugunin and Dino Viehland is the technical >> editor. >> >> Many thanks to all those who helped, including those who gave feedback >> during the early access program. >> >> All the best, >> >> Michael Foord >> >> -- >> 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 >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From anleewxs at gmail.com Sat Apr 11 19:10:42 2009 From: anleewxs at gmail.com (Alex News) Date: Sat, 11 Apr 2009 13:10:42 -0400 Subject: [IronPython] IronPython in Action Out! In-Reply-To: <49DFF837.9000903@voidspace.org.uk> References: <49DF8D32.2000402@voidspace.org.uk> <710DF26F214D2B4BB94287123FFE980A2E162FC3FA@NA-EXMSG-C104.redmond.corp.microsoft.com> <49DFF837.9000903@voidspace.org.uk> Message-ID: <2c77c440904111010u6b92718nc912151cd0030c01@mail.gmail.com> > Some proportion comes back - god knows no-one writes technical books to get > rich though! I do slightly better if you buy it through one of the links on > http://www.ironpythoninaction.com/ Done. I look forward to reading it! Alex On 4/10/09, Michael Foord wrote: > David Seruyange wrote: > > > Congrats although I was able to get a copy early (about 2 weeks ago) > directly from Manning. Paid full price, I hope that somehow trickles back to > you :) > > > > Some proportion comes back - god knows no-one writes technical books to get > rich though! I do slightly better if you buy it through one of the links on > http://www.ironpythoninaction.com/ > > It has been a long journey getting to this point, so at the moment all that > matters is people reading it - and hopefully finding it useful! > > All the best, > > Michael > > > > > > David > > > > On Fri, Apr 10, 2009 at 12:09 PM, Shri Borde > wrote: > > > > Congratulations! This is very exciting! > > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com > > > > [mailto:users-bounces at lists.ironpython.com > > ] On Behalf > Of Michael > > Foord > > Sent: Friday, April 10, 2009 11:17 AM > > To: Discussion of IronPython > > Subject: [IronPython] IronPython in Action Out! > > > > Hello all, > > > > *Finally* IronPython in Action is out. This is the first English > > language book on IronPython and is now in stock with Manning and > > Amazon.com and on the Safari bookshelf. You can get all the > > details from: > > > > * http://www.ironpythoninaction.com > > > > It covers a whole range of topics, with introductions to Python and > > .NET, using various Python libraries and .NET framework classes, web > > development with ASP.NET , Silverlight and web > > services, plus topics like > > WPF, testing, metaprogramming, system administration, embedding > > IronPython in .NET applications and so on. > > > > The foreword is by Jim Hugunin and Dino Viehland is the technical > > editor. > > > > Many thanks to all those who helped, including those who gave feedback > > during the early access program. > > > > All the best, > > > > Michael Foord > > > > -- > > 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 > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 adamb at silverkeytech.com Sat Apr 11 19:55:13 2009 From: adamb at silverkeytech.com (Adam Brand) Date: Sat, 11 Apr 2009 10:55:13 -0700 Subject: [IronPython] IronPython in Action Out! In-Reply-To: <2c77c440904111010u6b92718nc912151cd0030c01@mail.gmail.com> References: <49DF8D32.2000402@voidspace.org.uk> <710DF26F214D2B4BB94287123FFE980A2E162FC3FA@NA-EXMSG-C104.redmond.corp.microsoft.com> <49DFF837.9000903@voidspace.org.uk> <2c77c440904111010u6b92718nc912151cd0030c01@mail.gmail.com> Message-ID: <041401c9bace$ab706930$02513b90$@com> Also done! Looking forward to it. You might not get rich, but you could make some good money :-). 1. There were around 18,000 searches for "ironpython" in March in Google, another 2000 or so for related terms. (https://adwords.google.com/select/KeywordToolExternal). 2. Put up an Adwords campaign that takes people to a special landing page explaining what the book has to offer, testimonials, and a link to buy (promote the e-book pdf over the hard copy for instant gratification/better margin). Something like: http://www.perrymarshall.com/google/?gclid=CLPB_uKx6ZkCFcxL5QoduTpBPw but less cheesy/hard sell for a cynical technical audience and a direct CTA to buy. 3. Allow people to download some choice chapters for free from the landing page in #2, delivered via email (and agreeing to "opt in"). 4. Put the people in #3 on an "autoresponder" (chain) informative marketing campaign where you send them choice pages and tips; one email per day for five days, then one per week for four weeks, then one email per month until they unsubscribe. Aweber.com is good and cheap for this. 5. Profit :-) You should be able to get a good clickthrough rate with an ad that reads: Line1: IronPython in Action Line2: New Book with Rave Reviews Line3: Download Your Free Chapter Now ...so assume a 10% CTR. On the landing page, you should be able to get a 10% conversion rate between direct buys from the landing page (5%) and the chain email marketing campaign (5%). So 200 sales per month...if your average profit per book (ebook and regular) is $10 then you could bring in $2000 per month or $24K per year. Maybe more if you raise the price of the book ($39.99?). /end free Internet marketing advice Adam Adam Brand SilverKey Technologies -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Alex News Sent: Saturday, April 11, 2009 10:11 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython in Action Out! > Some proportion comes back - god knows no-one writes technical books to get > rich though! I do slightly better if you buy it through one of the links on > http://www.ironpythoninaction.com/ Done. I look forward to reading it! Alex On 4/10/09, Michael Foord wrote: > David Seruyange wrote: > > > Congrats although I was able to get a copy early (about 2 weeks ago) > directly from Manning. Paid full price, I hope that somehow trickles back to > you :) > > > > Some proportion comes back - god knows no-one writes technical books to get > rich though! I do slightly better if you buy it through one of the links on > http://www.ironpythoninaction.com/ > > It has been a long journey getting to this point, so at the moment all that > matters is people reading it - and hopefully finding it useful! > > All the best, > > Michael > > > > > > David > > > > On Fri, Apr 10, 2009 at 12:09 PM, Shri Borde > wrote: > > > > Congratulations! This is very exciting! > > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com > > > > [mailto:users-bounces at lists.ironpython.com > > ] On Behalf > Of Michael > > Foord > > Sent: Friday, April 10, 2009 11:17 AM > > To: Discussion of IronPython > > Subject: [IronPython] IronPython in Action Out! > > > > Hello all, > > > > *Finally* IronPython in Action is out. This is the first English > > language book on IronPython and is now in stock with Manning and > > Amazon.com and on the Safari bookshelf. You can get all the > > details from: > > > > * http://www.ironpythoninaction.com > > > > It covers a whole range of topics, with introductions to Python and > > .NET, using various Python libraries and .NET framework classes, web > > development with ASP.NET , Silverlight and web > > services, plus topics like > > WPF, testing, metaprogramming, system administration, embedding > > IronPython in .NET applications and so on. > > > > The foreword is by Jim Hugunin and Dino Viehland is the technical > > editor. > > > > Many thanks to all those who helped, including those who gave feedback > > during the early access program. > > > > All the best, > > > > Michael Foord > > > > -- > > 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 > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 From fuzzyman at voidspace.org.uk Sat Apr 11 20:12:50 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 11 Apr 2009 19:12:50 +0100 Subject: [IronPython] IronPython in Action Out! In-Reply-To: <041401c9bace$ab706930$02513b90$@com> References: <49DF8D32.2000402@voidspace.org.uk> <710DF26F214D2B4BB94287123FFE980A2E162FC3FA@NA-EXMSG-C104.redmond.corp.microsoft.com> <49DFF837.9000903@voidspace.org.uk> <2c77c440904111010u6b92718nc912151cd0030c01@mail.gmail.com> <041401c9bace$ab706930$02513b90$@com> Message-ID: <49E0DDA2.7010905@voidspace.org.uk> Adam Brand wrote: > Also done! Looking forward to it. > > You might not get rich, but you could make some good money :-). > > 1. There were around 18,000 searches for "ironpython" in March in Google, > another 2000 or so for related terms. > (https://adwords.google.com/select/KeywordToolExternal). > 2. Put up an Adwords campaign that takes people to a special landing page > explaining what the book has to offer, testimonials, and a link to buy > (promote the e-book pdf over the hard copy for instant gratification/better > margin). Something like: > http://www.perrymarshall.com/google/?gclid=CLPB_uKx6ZkCFcxL5QoduTpBPw but > less cheesy/hard sell for a cynical technical audience and a direct CTA to > buy. > Will look at this - thanks. > 3. Allow people to download some choice chapters for free from the landing > page in #2, delivered via email (and agreeing to "opt in"). > Already offering two chapters for free download. > 4. Put the people in #3 on an "autoresponder" (chain) informative marketing > campaign where you send them choice pages and tips; one email per day for > five days, then one per week for four weeks, then one email per month until > they unsubscribe. Aweber.com is good and cheap for this. > 5. Profit :-) > > You should be able to get a good clickthrough rate with an ad that reads: > Line1: IronPython in Action > Line2: New Book with Rave Reviews > Line3: Download Your Free Chapter Now > > ...so assume a 10% CTR. On the landing page, you should be able to get a 10% > conversion rate between direct buys from the landing page (5%) and the chain > email marketing campaign (5%). > > 10% ? Most advertising campaigns work at around 0.1% or so. > So 200 sales per month...if your average profit per book (ebook and regular) > is $10 then you could bring in $2000 per month or $24K per year. Maybe more > if you raise the price of the book ($39.99?). > I'm afraid I make nothing like $10 per book. That would amount to about 30% of gross - doubt you'll find many publishers offering that. All the best, Michael > /end free Internet marketing advice > > Adam > > Adam Brand > SilverKey Technologies > > > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Alex News > Sent: Saturday, April 11, 2009 10:11 AM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython in Action Out! > > >> Some proportion comes back - god knows no-one writes technical books to >> > get > >> rich though! I do slightly better if you buy it through one of the links >> > on > >> http://www.ironpythoninaction.com/ >> > > Done. I look forward to reading it! > > Alex > > > On 4/10/09, Michael Foord wrote: > >> David Seruyange wrote: >> >> >>> Congrats although I was able to get a copy early (about 2 weeks ago) >>> >> directly from Manning. Paid full price, I hope that somehow trickles back >> > to > >> you :) >> >> Some proportion comes back - god knows no-one writes technical books to >> > get > >> rich though! I do slightly better if you buy it through one of the links >> > on > >> http://www.ironpythoninaction.com/ >> >> It has been a long journey getting to this point, so at the moment all >> > that > >> matters is people reading it - and hopefully finding it useful! >> >> All the best, >> >> Michael >> >> >> >>> David >>> >>> On Fri, Apr 10, 2009 at 12:09 PM, Shri Borde >> >> > wrote: >> >>> Congratulations! This is very exciting! >>> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com >>> >>> [mailto:users-bounces at lists.ironpython.com >>> ] On Behalf >>> >> Of Michael >> >>> Foord >>> Sent: Friday, April 10, 2009 11:17 AM >>> To: Discussion of IronPython >>> Subject: [IronPython] IronPython in Action Out! >>> >>> Hello all, >>> >>> *Finally* IronPython in Action is out. This is the first English >>> language book on IronPython and is now in stock with Manning and >>> Amazon.com and on the Safari bookshelf. You can get all the >>> details from: >>> >>> * http://www.ironpythoninaction.com >>> >>> It covers a whole range of topics, with introductions to Python and >>> .NET, using various Python libraries and .NET framework classes, web >>> development with ASP.NET , Silverlight and web >>> services, plus topics like >>> WPF, testing, metaprogramming, system administration, embedding >>> IronPython in .NET applications and so on. >>> >>> The foreword is by Jim Hugunin and Dino Viehland is the technical >>> editor. >>> >>> Many thanks to all those who helped, including those who gave >>> > feedback > >>> during the early access program. >>> >>> All the best, >>> >>> Michael Foord >>> >>> -- >>> 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 >> >>> >>> >> ------------------------------------------------------------------------ >> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 mkelliott21 at gmail.com Sat Apr 11 21:32:59 2009 From: mkelliott21 at gmail.com (Michael Elliott) Date: Sat, 11 Apr 2009 15:32:59 -0400 Subject: [IronPython] IronPython in Action Out! In-Reply-To: <49DF8D32.2000402@voidspace.org.uk> References: <49DF8D32.2000402@voidspace.org.uk> Message-ID: Just wanted to say that I have had my book for a couple of weeks. It is a very good, very informative book. I have been "learning" Python and IronPythong for about 8 months now, and this books really help bring things along. The book is very well written, very good examples, and again, it has been a great help in my journey of learning. Thanks so much On Fri, Apr 10, 2009 at 2:17 PM, Michael Foord wrote: > Hello all, > > *Finally* IronPython in Action is out. This is the first English language > book on IronPython and is now in stock with Manning and Amazon.com and on > the Safari bookshelf. You can get all the details from: > > * http://www.ironpythoninaction.com > > It covers a whole range of topics, with introductions to Python and .NET, > using various Python libraries and .NET framework classes, web development > with ASP.NET, Silverlight and web services, plus topics like WPF, testing, > metaprogramming, system administration, embedding IronPython in .NET > applications and so on. > > The foreword is by Jim Hugunin and Dino Viehland is the technical editor. > > Many thanks to all those who helped, including those who gave feedback > during the early access program. > > All the best, > > Michael Foord > > -- > 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 adamb at silverkeytech.com Sat Apr 11 21:52:59 2009 From: adamb at silverkeytech.com (Adam Brand) Date: Sat, 11 Apr 2009 12:52:59 -0700 Subject: [IronPython] Main Utility of IronPython? Message-ID: <043201c9badf$1ed86020$5c892060$@com> What do you guys think people are using IronPython for, primarily? Web Apps? WinForms? Admin scripting? There were over 20,000 searches for IronPython last month. In comparison, IronRuby got 8,100. ASP.Net MVC got practically no searches. Why all the interest? What is the killer use case? I would think web apps, but I don't think that's backed up by the usage of IronPython for ASP.Net. The primary reason we use it is for web apps, where we feel there are productivity gains using IP for ASP.Net for front-end code and C# on the backend. This use case, though, requires people to use two different languages, which is a bit of a bar to raise where people mostly use C#. There had better be significant productivity boosts using IP for that to catch on. Thoughts on what IP's niche is and will be? Adam SilverKey Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.curtin at gmail.com Sat Apr 11 23:35:32 2009 From: brian.curtin at gmail.com (curtin@acm.org) Date: Sat, 11 Apr 2009 16:35:32 -0500 Subject: [IronPython] Main Utility of IronPython? In-Reply-To: <043201c9badf$1ed86020$5c892060$@com> References: <043201c9badf$1ed86020$5c892060$@com> Message-ID: I guess I don't really have a primary usage other than tinkering around, mostly. I'm looking to change that, though; my company has a great need for automated testing on one of our GUI applications, something I suspect others are probably in need of in environments like ours (C/C++ servers, C# GUI clients). I work on the server side and have a bunch of C extensions to expose our APIs to CPython (and IronPython via IronClad for tinkering on the side), but the GUI app that consumes my server's data is lacking in automation. A lot of the testing is still too manual intensive and time consuming. Michael Foord gave a good talk on functional testing of GUIs at PyCon which gave me that "aha!" moment. I've studied the details on his site [1] and am looking forward to helping that GUI team make use of something along those lines to make their lives easier, and make our software of a higher quality. ** As for what IronPython's niche is and will be? I'm not sure what it is now, but with the way Microsoft is pushing the pedal to the metal on dynamic languages, it could be anything in the future. Once this stuff is installed with Visual Studio I suspect it's all going to explode through the roof. Brian [1] http://www.voidspace.org.uk/python/articles/testing/index.shtml On Sat, Apr 11, 2009 at 2:52 PM, Adam Brand wrote: > What do you guys think people are using IronPython for, primarily? > > > > Web Apps? WinForms? Admin scripting? > > > > There were over 20,000 searches for IronPython last month. In comparison, > IronRuby got 8,100. ASP.Net MVC got practically no searches. Why all the > interest? What is the killer use case? > > > > I would think web apps, but I don?t think that?s backed up by the usage of > IronPython for ASP.Net. > > > > The primary reason we use it is for web apps, where we feel there are > productivity gains using IP for ASP.Net for front-end code and C# on the > backend. This use case, though, requires people to use two different > languages, which is a bit of a bar to raise where people mostly use C#. > There had better be significant productivity boosts using IP for that to > catch on. > > > > Thoughts on what IP?s niche is and will be? > > > > Adam > > SilverKey Technologies > > _______________________________________________ > 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 kfarmer at thuban.org Sun Apr 12 09:03:54 2009 From: kfarmer at thuban.org (Keith J. Farmer) Date: Sun, 12 Apr 2009 00:03:54 -0700 Subject: [IronPython] IronPython in Action Out! In-Reply-To: References: <49DF8D32.2000402@voidspace.org.uk> Message-ID: "IronPythong"? That brings images one shouldn't have on Easter. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Elliott Sent: Saturday, April 11, 2009 12:33 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython in Action Out! Just wanted to say that I have had my book for a couple of weeks. It is a very good, very informative book. I have been "learning" Python and IronPythong for about 8 months now, and this books really help bring things along. The book is very well written, very good examples, and again, it has been a great help in my journey of learning. Thanks so much On Fri, Apr 10, 2009 at 2:17 PM, Michael Foord wrote: Hello all, *Finally* IronPython in Action is out. This is the first English language book on IronPython and is now in stock with Manning and Amazon.com and on the Safari bookshelf. You can get all the details from: * http://www.ironpythoninaction.com It covers a whole range of topics, with introductions to Python and .NET, using various Python libraries and .NET framework classes, web development with ASP.NET, Silverlight and web services, plus topics like WPF, testing, metaprogramming, system administration, embedding IronPython in .NET applications and so on. The foreword is by Jim Hugunin and Dino Viehland is the technical editor. Many thanks to all those who helped, including those who gave feedback during the early access program. All the best, Michael Foord -- 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 daftspaniel at gmail.com Sun Apr 12 09:04:37 2009 From: daftspaniel at gmail.com (Davy Mitchell) Date: Sun, 12 Apr 2009 08:04:37 +0100 Subject: [IronPython] Main Utility of IronPython? In-Reply-To: References: <043201c9badf$1ed86020$5c892060$@com> Message-ID: <20253b0c0904120004p59ae6fc1r7014ca3bc7ea3271@mail.gmail.com> For me, I use IronPython for a number of reasons: 1) I can learn more .Net and Python at the same time. 2) The Framework is substantial and well maintained. In CPython I am frustrated by libraries getting out of sync (some 2.4, some 2.5 etc months apart). 3) Python is a good scripting language and it is currently the best and most mature one for .Net. 4) IronPython makes it easier to get the best out of Windows - it is a more natural fit than CPython. 5) Winforms is nicer than WxPython :-) 6) Silverlight is great for Python in a browser. Don't get me wrong - I have 3 versions of CPython installed too !! Cheers, Davy Mitchell On Sat, Apr 11, 2009 at 10:35 PM, curtin at acm.org wrote: > I guess I don't really have a primary usage other than tinkering around, > mostly. I'm looking to change that, though; my company has a great need for > automated testing on one of our GUI applications, something I suspect others > are probably in need of in environments like ours (C/C++ servers, C# GUI > clients). > > I work on the server side and have a bunch of C extensions to expose our > APIs to CPython (and IronPython via IronClad for tinkering on the side), but > the GUI app that consumes my server's data is lacking in automation. A lot > of the testing is still too manual intensive and time consuming. Michael > Foord gave a good talk on functional testing of GUIs at PyCon which gave me > that "aha!" moment. I've studied the details on his site [1] and am looking > forward to helping that GUI team make use of something along those lines to > make their lives easier, and make our software of a higher quality. > > As for what IronPython's niche is and will be? I'm not sure what it is now, > but with the way Microsoft is pushing the pedal to the metal on dynamic > languages, it could be anything in the future. Once this stuff is installed > with Visual Studio I suspect it's all going to explode through the roof. > > Brian > > > [1] http://www.voidspace.org.uk/python/articles/testing/index.shtml > > > On Sat, Apr 11, 2009 at 2:52 PM, Adam Brand wrote: >> >> What do you guys think people are using IronPython for, primarily? >> >> >> >> Web Apps? WinForms? Admin scripting? >> >> >> >> There were over 20,000 searches for IronPython last month. In comparison, >> IronRuby got 8,100. ?ASP.Net MVC got practically no searches. Why all the >> interest? What is the killer use case? >> >> >> >> I would think web apps, but I don?t think that?s backed up by the usage of >> IronPython for ASP.Net. >> >> >> >> The primary reason we use it is for web apps, where we feel there are >> productivity gains using IP for ASP.Net for front-end code and C# on the >> backend. This use case, though, requires people to use two different >> languages, which is a bit of a bar to raise where people mostly use C#. >> There had better be significant productivity boosts using IP for that to >> catch on. >> >> >> >> Thoughts on what IP?s niche is and will be? >> >> >> >> Adam >> >> SilverKey Technologies >> >> _______________________________________________ >> 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 kfarmer at thuban.org Sun Apr 12 09:04:35 2009 From: kfarmer at thuban.org (Keith J. Farmer) Date: Sun, 12 Apr 2009 00:04:35 -0700 Subject: [IronPython] IronPython in Action Out! In-Reply-To: <49E0DDA2.7010905@voidspace.org.uk> References: <49DF8D32.2000402@voidspace.org.uk> <710DF26F214D2B4BB94287123FFE980A2E162FC3FA@NA-EXMSG-C104.redmond.corp.microsoft.com> <49DFF837.9000903@voidspace.org.uk> <2c77c440904111010u6b92718nc912151cd0030c01@mail.gmail.com><041401c9bace$ab706930$02513b90$@com> <49E0DDA2.7010905@voidspace.org.uk> Message-ID: Translation: buy multiple copies. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Saturday, April 11, 2009 11:13 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython in Action Out! I'm afraid I make nothing like $10 per book. That would amount to about 30% of gross - doubt you'll find many publishers offering that. From mkelliott21 at gmail.com Sun Apr 12 13:14:32 2009 From: mkelliott21 at gmail.com (Michael Elliott) Date: Sun, 12 Apr 2009 07:14:32 -0400 Subject: [IronPython] IronPython in Action Out! In-Reply-To: References: <49DF8D32.2000402@voidspace.org.uk> Message-ID: yes ..... that is for sure ...... maybe i need to work on typing instead of IronPython ...... On Sun, Apr 12, 2009 at 3:03 AM, Keith J. Farmer wrote: > ?IronPythong?? That brings images one shouldn?t have on Easter. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Michael Elliott > *Sent:* Saturday, April 11, 2009 12:33 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] IronPython in Action Out! > > > > Just wanted to say that I have had my book for a couple of weeks. It is a > very good, very informative book. I have been "learning" Python and > IronPythong for about 8 months now, and this books really help bring things > along. > > > The book is very well written, very good examples, and again, it has been a > great help in my journey of learning. > > Thanks so much > > On Fri, Apr 10, 2009 at 2:17 PM, Michael Foord > wrote: > > Hello all, > > *Finally* IronPython in Action is out. This is the first English language > book on IronPython and is now in stock with Manning and Amazon.com and on > the Safari bookshelf. You can get all the details from: > > * http://www.ironpythoninaction.com > > It covers a whole range of topics, with introductions to Python and .NET, > using various Python libraries and .NET framework classes, web development > with ASP.NET, Silverlight and web services, plus topics like WPF, testing, > metaprogramming, system administration, embedding IronPython in .NET > applications and so on. > > The foreword is by Jim Hugunin and Dino Viehland is the technical editor. > > Many thanks to all those who helped, including those who gave feedback > during the early access program. > > All the best, > > Michael Foord > > -- > 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 m_tayseer82 at yahoo.com Sun Apr 12 13:15:59 2009 From: m_tayseer82 at yahoo.com (Mohammad Tayseer) Date: Sun, 12 Apr 2009 04:15:59 -0700 (PDT) Subject: [IronPython] Main Utility of IronPython? In-Reply-To: <20253b0c0904120004p59ae6fc1r7014ca3bc7ea3271@mail.gmail.com> References: <043201c9badf$1ed86020$5c892060$@com> <20253b0c0904120004p59ae6fc1r7014ca3bc7ea3271@mail.gmail.com> Message-ID: <300193.87406.qm@web31102.mail.mud.yahoo.com> I use Python mostly for scripting, screen-scraping and small web apps using Django. I use IronPython mostly for prototyping (sometimes) and for trying .net APIs, which is faster than searching Google & MSDN :) Mohammad Tayseer http://spellcoder.com/blogs/tayseer ________________________________ From: Davy Mitchell To: Discussion of IronPython Sent: Sunday, April 12, 2009 9:04:37 AM Subject: Re: [IronPython] Main Utility of IronPython? For me, I use IronPython for a number of reasons: 1) I can learn more .Net and Python at the same time. 2) The Framework is substantial and well maintained. In CPython I am frustrated by libraries getting out of sync (some 2.4, some 2.5 etc months apart). 3) Python is a good scripting language and it is currently the best and most mature one for .Net. 4) IronPython makes it easier to get the best out of Windows - it is a more natural fit than CPython. 5) Winforms is nicer than WxPython :-) 6) Silverlight is great for Python in a browser. Don't get me wrong - I have 3 versions of CPython installed too !! Cheers, Davy Mitchell On Sat, Apr 11, 2009 at 10:35 PM, curtin at acm.org wrote: > I guess I don't really have a primary usage other than tinkering around, > mostly. I'm looking to change that, though; my company has a great need for > automated testing on one of our GUI applications, something I suspect others > are probably in need of in environments like ours (C/C++ servers, C# GUI > clients). > > I work on the server side and have a bunch of C extensions to expose our > APIs to CPython (and IronPython via IronClad for tinkering on the side), but > the GUI app that consumes my server's data is lacking in automation. A lot > of the testing is still too manual intensive and time consuming. Michael > Foord gave a good talk on functional testing of GUIs at PyCon which gave me > that "aha!" moment. I've studied the details on his site [1] and am looking > forward to helping that GUI team make use of something along those lines to > make their lives easier, and make our software of a higher quality. > > As for what IronPython's niche is and will be? I'm not sure what it is now, > but with the way Microsoft is pushing the pedal to the metal on dynamic > languages, it could be anything in the future. Once this stuff is installed > with Visual Studio I suspect it's all going to explode through the roof. > > Brian > > > [1] http://www.voidspace.org.uk/python/articles/testing/index.shtml > > > On Sat, Apr 11, 2009 at 2:52 PM, Adam Brand wrote: >> >> What do you guys think people are using IronPython for, primarily? >> >> >> >> Web Apps? WinForms? Admin scripting? >> >> >> >> There were over 20,000 searches for IronPython last month. In comparison, >> IronRuby got 8,100. ASP.Net MVC got practically no searches. Why all the >> interest? What is the killer use case? >> >> >> >> I would think web apps, but I don?t think that?s backed up by the usage of >> IronPython for ASP.Net. >> >> >> >> The primary reason we use it is for web apps, where we feel there are >> productivity gains using IP for ASP.Net for front-end code and C# on the >> backend. This use case, though, requires people to use two different >> languages, which is a bit of a bar to raise where people mostly use C#. >> There had better be significant productivity boosts using IP for that to >> catch on. >> >> >> >> Thoughts on what IP?s niche is and will be? >> >> >> >> Adam >> >> SilverKey Technologies >> >> _______________________________________________ >> 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 m_tayseer82 at yahoo.com Sun Apr 12 14:36:27 2009 From: m_tayseer82 at yahoo.com (Mohammad Tayseer) Date: Sun, 12 Apr 2009 05:36:27 -0700 (PDT) Subject: [IronPython] Main Utility of IronPython? In-Reply-To: <300193.87406.qm@web31102.mail.mud.yahoo.com> References: <043201c9badf$1ed86020$5c892060$@com> <20253b0c0904120004p59ae6fc1r7014ca3bc7ea3271@mail.gmail.com> <300193.87406.qm@web31102.mail.mud.yahoo.com> Message-ID: <568232.88380.qm@web31101.mail.mud.yahoo.com> I'm really waiting for Django to run successfully on IronPython :) Mohammad Tayseer http://spellcoder.com/blogs/tayseer ________________________________ From: Mohammad Tayseer To: Discussion of IronPython Sent: Sunday, April 12, 2009 1:15:59 PM Subject: Re: [IronPython] Main Utility of IronPython? I use Python mostly for scripting, screen-scraping and small web apps using Django. I use IronPython mostly for prototyping (sometimes) and for trying .net APIs, which is faster than searching Google & MSDN :) Mohammad Tayseer http://spellcoder.com/blogs/tayseer ________________________________ From: Davy Mitchell To: Discussion of IronPython Sent: Sunday, April 12, 2009 9:04:37 AM Subject: Re: [IronPython] Main Utility of IronPython? For me, I use IronPython for a number of reasons: 1) I can learn more .Net and Python at the same time. 2) The Framework is substantial and well maintained. In CPython I am frustrated by libraries getting out of sync (some 2.4, some 2.5 etc months apart). 3) Python is a good scripting language and it is currently the best and most mature one for .Net. 4) IronPython makes it easier to get the best out of Windows - it is a more natural fit than CPython. 5) Winforms is nicer than WxPython :-) 6) Silverlight is great for Python in a browser. Don't get me wrong - I have 3 versions of CPython installed too !! Cheers, Davy Mitchell On Sat, Apr 11, 2009 at 10:35 PM, curtin at acm.org wrote: > I guess I don't really have a primary usage other than tinkering around, > mostly. I'm looking to change that, though; my company has a great need for > automated testing on one of our GUI applications, something I suspect others > are probably in need of in environments like ours (C/C++ servers, C# GUI > clients). > > I work on the server side and have a bunch of C extensions to expose our > APIs to CPython (and IronPython via IronClad for tinkering on the side), but > the GUI app that consumes my server's data is lacking in automation. A lot > of the testing is still too manual intensive and time consuming. Michael > Foord gave a good talk on functional testing of GUIs at PyCon which gave me > that "aha!" moment. I've studied the details on his site [1] and am looking > forward to helping that GUI team make use of something along those lines to > make their lives easier, and make our software of a higher quality. > > As for what IronPython's niche is and will be? I'm not sure what it is now, > but with the way Microsoft is pushing the pedal to the metal on dynamic > languages, it could be anything in the future. Once this stuff is installed > with Visual Studio I suspect it's all going to explode through the roof. > > Brian > > > [1] http://www.voidspace.org.uk/python/articles/testing/index.shtml > > > On Sat, Apr 11, 2009 at 2:52 PM, Adam Brand wrote: >> >> What do you guys think people are using IronPython for, primarily? >> >> >> >> Web Apps? WinForms? Admin scripting? >> >> >> >> There were over 20,000 searches for IronPython last month. In comparison, >> IronRuby got 8,100. ASP.Net MVC got practically no searches. Why all the >> interest? What is the killer use case? >> >> >> >> I would think web apps, but I don?t think that?s backed up by the usage of >> IronPython for ASP.Net. >> >> >> >> The primary reason we use it is for web apps, where we feel there are >> productivity gains using IP for ASP.Net for front-end code and C# on the >> backend. This use case, though, requires people to use two different >> languages, which is a bit of a bar to raise where people mostly use C#. >> There had better be significant productivity boosts using IP for that to >> catch on. >> >> >> >> Thoughts on what IP?s niche is and will be? >> >> >> >> Adam >> >> SilverKey Technologies >> >> _______________________________________________ >> 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 joesox at gmail.com Sun Apr 12 14:47:43 2009 From: joesox at gmail.com (JoeSox) Date: Sun, 12 Apr 2009 05:47:43 -0700 Subject: [IronPython] Main Utility of IronPython? In-Reply-To: <043201c9badf$1ed86020$5c892060$@com> References: <043201c9badf$1ed86020$5c892060$@com> Message-ID: <785694cd0904120547r43eae52do64ba1ad048a9755b@mail.gmail.com> Porting or wrapping Python apps/modules to a .NET environment. -- Joe On Sat, Apr 11, 2009 at 12:52 PM, Adam Brand wrote: > What do you guys think people are using IronPython for, primarily? > Thoughts on what IP?s niche is and will be? From empirebuilder at gmail.com Sun Apr 12 14:52:13 2009 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Sun, 12 Apr 2009 14:52:13 +0200 Subject: [IronPython] Main Utility of IronPython? In-Reply-To: <785694cd0904120547r43eae52do64ba1ad048a9755b@mail.gmail.com> References: <043201c9badf$1ed86020$5c892060$@com> <785694cd0904120547r43eae52do64ba1ad048a9755b@mail.gmail.com> Message-ID: <8cd017b80904120552g76dfc439ke803db7e532f60d4@mail.gmail.com> Is there anyone using IronPython to run their core business other than ResolveOne folks? On Sun, Apr 12, 2009 at 2:47 PM, JoeSox wrote: > Porting or wrapping Python apps/modules to a .NET environment. > > -- > Joe > > On Sat, Apr 11, 2009 at 12:52 PM, Adam Brand > wrote: > > What do you guys think people are using IronPython for, primarily? > > Thoughts on what IP?s niche is and will be? > _______________________________________________ > 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 vinjvinj at gmail.com Mon Apr 13 17:21:31 2009 From: vinjvinj at gmail.com (Vineet Jain (gmail)) Date: Mon, 13 Apr 2009 11:21:31 -0400 Subject: [IronPython] Problem with pickle.load of user defined classes created from cPython 2.5. Message-ID: <001e01c9bc4b$89fda3c0$9df8eb40$@com> I'm trying to load pickled user defined classes from iron python. The pickled object was created using cpython 2.5 on an ubuntu box. I can load them fine with cpython 2.5 on a windows box. However when I load them from ironpython I get the following incomplete stack trace: c:\trading\pytrade\modules\apiscripts\models>ipy test_pickle.py Traceback (most recent call last): File "test_pickle.py", line 20, in test_pickle.py File "test_pickle.py", line 13, in loadTrades File "c:\Program Files\IronPython 2.0.1\Lib\pickle.py", line 1370, in load File "c:\Program Files\IronPython 2.0.1\Lib\pickle.py", line 858, in load KeyError: [ Any ideas on how I can go about debugging this? Is pickle.load of user defined classes from cPython supported? Thanks, Vineet -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Apr 13 17:28:49 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 13 Apr 2009 16:28:49 +0100 Subject: [IronPython] Problem with pickle.load of user defined classes created from cPython 2.5. In-Reply-To: <001e01c9bc4b$89fda3c0$9df8eb40$@com> References: <001e01c9bc4b$89fda3c0$9df8eb40$@com> Message-ID: <49E35A31.4070700@voidspace.org.uk> Vineet Jain (gmail) wrote: > > I?m trying to load pickled user defined classes from iron python. The > pickled object was created using cpython 2.5 on an ubuntu box. I can > load them fine with cpython 2.5 on a windows box. However when I load > them from ironpython I get the following incomplete stack trace: > > c:\trading\pytrade\modules\apiscripts\models>ipy test_pickle.py > > Traceback (most recent call last): > > File "test_pickle.py", line 20, in test_pickle.py > > File "test_pickle.py", line 13, in loadTrades > > File "c:\Program Files\IronPython 2.0.1\Lib\pickle.py", line 1370, in load > > File "c:\Program Files\IronPython 2.0.1\Lib\pickle.py", line 858, in load > > KeyError: [ > > Any ideas on how I can go about debugging this? Is pickle.load of user > defined classes from cPython supported? > That isn't enough information to diagnose the problem. The short answer is that yes, IronPython does support the unpickling of user defined classes created in CPython: C:\compile>python Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from test import Test >>> from pickle import dumps >>> t = Test() >>> open('instance.pkl', 'wb').write(dumps(t)) >>> C:\compile>"C:\Program Files (x86)\IronPython 2.0.1\ipy.exe" IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3074 Type "help", "copyright", "credits" or "license" for more information. >>> import test >>> from pickle import loads >>> >>> t = loads(open('instance.pkl').read()) >>> t >>> In the example above the module test.py contains only: class Test(object): pass All the best, Michael > Thanks, > > Vineet > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 vinjvinj at gmail.com Mon Apr 13 20:08:12 2009 From: vinjvinj at gmail.com (Vineet Jain (gmail)) Date: Mon, 13 Apr 2009 14:08:12 -0400 Subject: [IronPython] Problem with pickle.load of user defined classes created from cPython 2.5. In-Reply-To: <49E35A31.4070700@voidspace.org.uk> References: <001e01c9bc4b$89fda3c0$9df8eb40$@com> <49E35A31.4070700@voidspace.org.uk> Message-ID: <002c01c9bc62$d2536f30$76fa4d90$@com> My mistake, it was not an ironpython specific error, I have been able to reproduce the error in cPython as well. The error in cPython is: KeyError: '[' While the error in iron python is: KeyError: [ Notice how the [ is between quotes in cPython, a small difference which threw me off. Thanks, Vineet -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, April 13, 2009 11:29 AM To: Discussion of IronPython Subject: Re: [IronPython] Problem with pickle.load of user defined classes created from cPython 2.5. Vineet Jain (gmail) wrote: > > I'm trying to load pickled user defined classes from iron python. The > pickled object was created using cpython 2.5 on an ubuntu box. I can > load them fine with cpython 2.5 on a windows box. However when I load > them from ironpython I get the following incomplete stack trace: > > c:\trading\pytrade\modules\apiscripts\models>ipy test_pickle.py > > Traceback (most recent call last): > > File "test_pickle.py", line 20, in test_pickle.py > > File "test_pickle.py", line 13, in loadTrades > > File "c:\Program Files\IronPython 2.0.1\Lib\pickle.py", line 1370, in load > > File "c:\Program Files\IronPython 2.0.1\Lib\pickle.py", line 858, in load > > KeyError: [ > > Any ideas on how I can go about debugging this? Is pickle.load of user > defined classes from cPython supported? > That isn't enough information to diagnose the problem. The short answer is that yes, IronPython does support the unpickling of user defined classes created in CPython: C:\compile>python Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from test import Test >>> from pickle import dumps >>> t = Test() >>> open('instance.pkl', 'wb').write(dumps(t)) >>> C:\compile>"C:\Program Files (x86)\IronPython 2.0.1\ipy.exe" IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3074 Type "help", "copyright", "credits" or "license" for more information. >>> import test >>> from pickle import loads >>> >>> t = loads(open('instance.pkl').read()) >>> t >>> In the example above the module test.py contains only: class Test(object): pass All the best, Michael > Thanks, > > Vineet > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 curt at hagenlocher.org Tue Apr 14 13:43:21 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 14 Apr 2009 04:43:21 -0700 Subject: [IronPython] IronPython Studio Xaml editor issue In-Reply-To: References: Message-ID: When something like this has happened to me once or twice in the past, I've never had much luck resolving it. I seem to recall that reinstalling VS fixed it for me one time, but not the other. :( On Fri, Apr 10, 2009 at 7:12 PM, Daryl Hendricks wrote: > Yep, it did work but I?m thinking that some of the VS and .NET updates > since that point could have created a problem. > > > > >Has it ever worked for you or have you always gotten this error? > > > > > >On Wed, Apr 8, 2009 at 11:34 AM, Daryl Hendricks > wrote: > > > > >> Hello, > > >> > > >> I'm running into a problem where I can't use the XAML editor in the > > >> isolated version of IronPython Studio. The error I'm getting is > > >> "Package 'Microsoft.VisualStudio.Xaml' has failed to load ( GUID = > > >> {E58C2A8B-BCC4-4559-AD59-D62EB6D58A22} )" Can anyone offer some > > >> guidance as to how to fix this? The XAML displays but the designer is > not available. > > > > > > > > > > _______________________________________________ > 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 anleewxs at gmail.com Tue Apr 14 16:32:23 2009 From: anleewxs at gmail.com (Alex News) Date: Tue, 14 Apr 2009 10:32:23 -0400 Subject: [IronPython] **kwargs and __getattr__ handling in csharp functions and classes? Message-ID: <2c77c440904140732y1fe0bf44p65062d5328de1043@mail.gmail.com> I would like to write some functions and classes in csharp that interact nicely python. I would like to write a function that can respond to keyword arguments, and a class that can dynamically resolve __getattr__. For the function I tried creating a function that takes a IronPython.Runtime.PythonDictionary, but did not work. For a class I tried creating a function that have a method __getattr__, but that failed too. I see there is a IronPython.Runtime.PythonFunction and some other interesting classes in the Runtime, but it is not apparent exactly how I could use them. I can, luckily, fudge much of what I want to do by creating small python classes and functions in python to proxy the values to underlying csharp classes. However thing would be cleaner if I could do it directly in csharp. Thanks in advance for any suggestions. Alex From dinov at microsoft.com Tue Apr 14 17:16:44 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 14 Apr 2009 08:16:44 -0700 Subject: [IronPython] **kwargs and __getattr__ handling in csharp functions and classes? In-Reply-To: <2c77c440904140732y1fe0bf44p65062d5328de1043@mail.gmail.com> References: <2c77c440904140732y1fe0bf44p65062d5328de1043@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23555727007687@NA-EXMSG-C102.redmond.corp.microsoft.com> For kwargs you need to decorate the function w/ a ParamDictionary attribute such as: public void __init__(CodeContext/*!*/ context, object o, [ParamDictionary] IAttributesCollection kwArgs) For __getattr__ IronPython will recognize a special name "GetBoundMember" method such as: using System; using System.Runtime.CompilerServices; public class Foo { [SpecialName] public object GetBoundMember (string name) { return name; } } You can also do "GetCustomMember" which is like __getattribute__. But for this one what you really want to do is inherit directly from the DynamicObject class and override TryGetMember. Then it'll work not only w/ Python but w/ other DLR based languages as well (e.g. C#, VB.NET, IronRuby, etc...). > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Alex News > Sent: Tuesday, April 14, 2009 7:32 AM > To: users at lists.ironpython.com > Subject: [IronPython] **kwargs and __getattr__ handling in csharp > functions and classes? > > I would like to write some functions and classes in csharp that > interact nicely python. I would like to write a function that can > respond to keyword arguments, and a class that can dynamically resolve > __getattr__. > > For the function I tried creating a function that takes a > IronPython.Runtime.PythonDictionary, but did not work. For a class I > tried creating a function that have a method __getattr__, but that > failed too. > > I see there is a IronPython.Runtime.PythonFunction and some other > interesting classes in the Runtime, but it is not apparent exactly how > I could use them. > > I can, luckily, fudge much of what I want to do by creating small > python classes and functions in python to proxy the values to > underlying csharp classes. However thing would be cleaner if I could > do it directly in csharp. > > Thanks in advance for any suggestions. > > Alex > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From anleewxs at gmail.com Tue Apr 14 17:31:51 2009 From: anleewxs at gmail.com (Alex News) Date: Tue, 14 Apr 2009 11:31:51 -0400 Subject: [IronPython] **kwargs and __getattr__ handling in csharp functions and classes? In-Reply-To: <350E7D38B6D819428718949920EC23555727007687@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <2c77c440904140732y1fe0bf44p65062d5328de1043@mail.gmail.com> <350E7D38B6D819428718949920EC23555727007687@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <2c77c440904140831p3eba4bc0r73bfc710655702c3@mail.gmail.com> Much appreciated, I will give that a try. In what namespace is DynamicObject declared? (I assume the required assemblies are already referenced if I'm pulling in IronPython). Thanks again, Alex On Tue, Apr 14, 2009 at 11:16 AM, Dino Viehland wrote: > For kwargs you need to decorate the function w/ a ParamDictionary attribute such as: > > public void __init__(CodeContext/*!*/ context, object o, [ParamDictionary] IAttributesCollection kwArgs) > > For __getattr__ IronPython will recognize a special name "GetBoundMember" method such as: > > using System; > using System.Runtime.CompilerServices; > > public class Foo { > ? ?[SpecialName] > ? ?public object GetBoundMember (string name) { > ? ? ? ?return name; > ? ?} > } > > > You can also do "GetCustomMember" which is like __getattribute__. ?But for this one what you really want to do is inherit directly from the DynamicObject class and override TryGetMember. ?Then it'll work not only w/ Python but w/ other DLR based languages as well (e.g. C#, VB.NET, IronRuby, etc...). > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Alex News >> Sent: Tuesday, April 14, 2009 7:32 AM >> To: users at lists.ironpython.com >> Subject: [IronPython] **kwargs and __getattr__ handling in csharp >> functions and classes? >> >> I would like to write some functions and classes in csharp that >> interact nicely python. ?I would like to write a function that can >> respond to keyword arguments, and a class that can dynamically resolve >> __getattr__. >> >> For the function I tried creating a function that takes a >> IronPython.Runtime.PythonDictionary, but did not work. ?For a class I >> tried creating a function that have a method __getattr__, but that >> failed too. >> >> I see there is a IronPython.Runtime.PythonFunction and some other >> interesting classes in the Runtime, but it is not apparent exactly how >> I could use them. >> >> I can, luckily, fudge much of what I want to do by creating small >> python classes and functions in python to proxy the values to >> underlying csharp classes. ?However thing would be cleaner if I could >> do it directly in csharp. >> >> Thanks in advance for any suggestions. >> >> Alex >> _______________________________________________ >> 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 curt at hagenlocher.org Tue Apr 14 18:12:09 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 14 Apr 2009 09:12:09 -0700 Subject: [IronPython] **kwargs and __getattr__ handling in csharp functions and classes? In-Reply-To: <2c77c440904140831p3eba4bc0r73bfc710655702c3@mail.gmail.com> References: <2c77c440904140732y1fe0bf44p65062d5328de1043@mail.gmail.com> <350E7D38B6D819428718949920EC23555727007687@NA-EXMSG-C102.redmond.corp.microsoft.com> <2c77c440904140831p3eba4bc0r73bfc710655702c3@mail.gmail.com> Message-ID: In current versions of IronPython, DynamicObject is in Microsoft.Scripting.Core as Microsoft.Scripting.DynamicObject. In .NET 4.0 System.Core, the same class will be called System.Dynamic.DynamicObject. (I just noticed this naming discrepancy today, and I think we should probably move it to at least Microsoft.*Dynamic* for the 2.6 release.) On Tue, Apr 14, 2009 at 8:31 AM, Alex News wrote: > Much appreciated, I will give that a try. In what namespace is > DynamicObject declared? (I assume the required assemblies are already > referenced if I'm pulling in IronPython). > > Thanks again, > Alex > > > On Tue, Apr 14, 2009 at 11:16 AM, Dino Viehland > wrote: > > For kwargs you need to decorate the function w/ a ParamDictionary > attribute such as: > > > > public void __init__(CodeContext/*!*/ context, object o, > [ParamDictionary] IAttributesCollection kwArgs) > > > > For __getattr__ IronPython will recognize a special name "GetBoundMember" > method such as: > > > > using System; > > using System.Runtime.CompilerServices; > > > > public class Foo { > > [SpecialName] > > public object GetBoundMember (string name) { > > return name; > > } > > } > > > > > > You can also do "GetCustomMember" which is like __getattribute__. But > for this one what you really want to do is inherit directly from the > DynamicObject class and override TryGetMember. Then it'll work not only w/ > Python but w/ other DLR based languages as well (e.g. C#, VB.NET, > IronRuby, etc...). > > > > > >> -----Original Message----- > >> From: users-bounces at lists.ironpython.com [mailto:users- > >> bounces at lists.ironpython.com] On Behalf Of Alex News > >> Sent: Tuesday, April 14, 2009 7:32 AM > >> To: users at lists.ironpython.com > >> Subject: [IronPython] **kwargs and __getattr__ handling in csharp > >> functions and classes? > >> > >> I would like to write some functions and classes in csharp that > >> interact nicely python. I would like to write a function that can > >> respond to keyword arguments, and a class that can dynamically resolve > >> __getattr__. > >> > >> For the function I tried creating a function that takes a > >> IronPython.Runtime.PythonDictionary, but did not work. For a class I > >> tried creating a function that have a method __getattr__, but that > >> failed too. > >> > >> I see there is a IronPython.Runtime.PythonFunction and some other > >> interesting classes in the Runtime, but it is not apparent exactly how > >> I could use them. > >> > >> I can, luckily, fudge much of what I want to do by creating small > >> python classes and functions in python to proxy the values to > >> underlying csharp classes. However thing would be cleaner if I could > >> do it directly in csharp. > >> > >> Thanks in advance for any suggestions. > >> > >> Alex > >> _______________________________________________ > >> 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 anleewxs at gmail.com Tue Apr 14 20:02:29 2009 From: anleewxs at gmail.com (Alex News) Date: Tue, 14 Apr 2009 14:02:29 -0400 Subject: [IronPython] **kwargs and __getattr__ handling in csharp functions and classes? In-Reply-To: References: <2c77c440904140732y1fe0bf44p65062d5328de1043@mail.gmail.com> <350E7D38B6D819428718949920EC23555727007687@NA-EXMSG-C102.redmond.corp.microsoft.com> <2c77c440904140831p3eba4bc0r73bfc710655702c3@mail.gmail.com> Message-ID: <2c77c440904141102l753818abn276f2b089a06d3a3@mail.gmail.com> Current IronPython = 2.01? I have Microsoft.Scripting.Core referenced, and can't find DynamicObject. There is an Microsoft.Scripting.Actions.IDynamicObject, and a Microsoft.Scripting.Runtime.IOldDynamicObject. I'm sure I'm missing something very basic. We are using .net 2.0.50727 SP1 On Tue, Apr 14, 2009 at 12:12 PM, Curt Hagenlocher wrote: > In current versions of IronPython, DynamicObject is in > Microsoft.Scripting.Core as Microsoft.Scripting.DynamicObject.? In .NET 4.0 > System.Core, the same class?will be called System.Dynamic.DynamicObject.? (I > just noticed this naming discrepancy today, and I think we should probably > move it to at least Microsoft.Dynamic for the 2.6 release.) > > On Tue, Apr 14, 2009 at 8:31 AM, Alex News wrote: >> >> Much appreciated, I will give that a try. ?In what namespace is >> DynamicObject declared? ?(I assume the required assemblies are already >> referenced if I'm pulling in IronPython). >> >> Thanks again, >> Alex >> >> >> On Tue, Apr 14, 2009 at 11:16 AM, Dino Viehland >> wrote: >> > For kwargs you need to decorate the function w/ a ParamDictionary >> > attribute such as: >> > >> > public void __init__(CodeContext/*!*/ context, object o, >> > [ParamDictionary] IAttributesCollection kwArgs) >> > >> > For __getattr__ IronPython will recognize a special name >> > "GetBoundMember" method such as: >> > >> > using System; >> > using System.Runtime.CompilerServices; >> > >> > public class Foo { >> > ? ?[SpecialName] >> > ? ?public object GetBoundMember (string name) { >> > ? ? ? ?return name; >> > ? ?} >> > } >> > >> > >> > You can also do "GetCustomMember" which is like __getattribute__. ?But >> > for this one what you really want to do is inherit directly from the >> > DynamicObject class and override TryGetMember. ?Then it'll work not only w/ >> > Python but w/ other DLR based languages as well (e.g. C#, VB.NET, IronRuby, >> > etc...). >> > >> > >> >> -----Original Message----- >> >> From: users-bounces at lists.ironpython.com [mailto:users- >> >> bounces at lists.ironpython.com] On Behalf Of Alex News >> >> Sent: Tuesday, April 14, 2009 7:32 AM >> >> To: users at lists.ironpython.com >> >> Subject: [IronPython] **kwargs and __getattr__ handling in csharp >> >> functions and classes? >> >> >> >> I would like to write some functions and classes in csharp that >> >> interact nicely python. ?I would like to write a function that can >> >> respond to keyword arguments, and a class that can dynamically resolve >> >> __getattr__. >> >> >> >> For the function I tried creating a function that takes a >> >> IronPython.Runtime.PythonDictionary, but did not work. ?For a class I >> >> tried creating a function that have a method __getattr__, but that >> >> failed too. >> >> >> >> I see there is a IronPython.Runtime.PythonFunction and some other >> >> interesting classes in the Runtime, but it is not apparent exactly how >> >> I could use them. >> >> >> >> I can, luckily, fudge much of what I want to do by creating small >> >> python classes and functions in python to proxy the values to >> >> underlying csharp classes. ?However thing would be cleaner if I could >> >> do it directly in csharp. >> >> >> >> Thanks in advance for any suggestions. >> >> >> >> Alex >> >> _______________________________________________ >> >> Users mailing list >> >> Users at lists.ironpython.com >> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.ironpython.com >> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From curt at hagenlocher.org Tue Apr 14 20:04:46 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 14 Apr 2009 11:04:46 -0700 Subject: [IronPython] **kwargs and __getattr__ handling in csharp functions and classes? In-Reply-To: <2c77c440904141102l753818abn276f2b089a06d3a3@mail.gmail.com> References: <2c77c440904140732y1fe0bf44p65062d5328de1043@mail.gmail.com> <350E7D38B6D819428718949920EC23555727007687@NA-EXMSG-C102.redmond.corp.microsoft.com> <2c77c440904140831p3eba4bc0r73bfc710655702c3@mail.gmail.com> <2c77c440904141102l753818abn276f2b089a06d3a3@mail.gmail.com> Message-ID: It should be Microsoft.Scripting.DynamicObject in 2.0. On Tue, Apr 14, 2009 at 11:02 AM, Alex News wrote: > Current IronPython = 2.01? I have Microsoft.Scripting.Core > referenced, and can't find DynamicObject. There is an > Microsoft.Scripting.Actions.IDynamicObject, and a > Microsoft.Scripting.Runtime.IOldDynamicObject. I'm sure I'm missing > something very basic. > > We are using .net 2.0.50727 SP1 > > > > > On Tue, Apr 14, 2009 at 12:12 PM, Curt Hagenlocher > wrote: > > In current versions of IronPython, DynamicObject is in > > Microsoft.Scripting.Core as Microsoft.Scripting.DynamicObject. In .NET > 4.0 > > System.Core, the same class will be called System.Dynamic.DynamicObject. > (I > > just noticed this naming discrepancy today, and I think we should > probably > > move it to at least Microsoft.Dynamic for the 2.6 release.) > > > > On Tue, Apr 14, 2009 at 8:31 AM, Alex News wrote: > >> > >> Much appreciated, I will give that a try. In what namespace is > >> DynamicObject declared? (I assume the required assemblies are already > >> referenced if I'm pulling in IronPython). > >> > >> Thanks again, > >> Alex > >> > >> > >> On Tue, Apr 14, 2009 at 11:16 AM, Dino Viehland > >> wrote: > >> > For kwargs you need to decorate the function w/ a ParamDictionary > >> > attribute such as: > >> > > >> > public void __init__(CodeContext/*!*/ context, object o, > >> > [ParamDictionary] IAttributesCollection kwArgs) > >> > > >> > For __getattr__ IronPython will recognize a special name > >> > "GetBoundMember" method such as: > >> > > >> > using System; > >> > using System.Runtime.CompilerServices; > >> > > >> > public class Foo { > >> > [SpecialName] > >> > public object GetBoundMember (string name) { > >> > return name; > >> > } > >> > } > >> > > >> > > >> > You can also do "GetCustomMember" which is like __getattribute__. But > >> > for this one what you really want to do is inherit directly from the > >> > DynamicObject class and override TryGetMember. Then it'll work not > only w/ > >> > Python but w/ other DLR based languages as well (e.g. C#, VB.NET, > IronRuby, > >> > etc...). > >> > > >> > > >> >> -----Original Message----- > >> >> From: users-bounces at lists.ironpython.com [mailto:users- > >> >> bounces at lists.ironpython.com] On Behalf Of Alex News > >> >> Sent: Tuesday, April 14, 2009 7:32 AM > >> >> To: users at lists.ironpython.com > >> >> Subject: [IronPython] **kwargs and __getattr__ handling in csharp > >> >> functions and classes? > >> >> > >> >> I would like to write some functions and classes in csharp that > >> >> interact nicely python. I would like to write a function that can > >> >> respond to keyword arguments, and a class that can dynamically > resolve > >> >> __getattr__. > >> >> > >> >> For the function I tried creating a function that takes a > >> >> IronPython.Runtime.PythonDictionary, but did not work. For a class I > >> >> tried creating a function that have a method __getattr__, but that > >> >> failed too. > >> >> > >> >> I see there is a IronPython.Runtime.PythonFunction and some other > >> >> interesting classes in the Runtime, but it is not apparent exactly > how > >> >> I could use them. > >> >> > >> >> I can, luckily, fudge much of what I want to do by creating small > >> >> python classes and functions in python to proxy the values to > >> >> underlying csharp classes. However thing would be cleaner if I could > >> >> do it directly in csharp. > >> >> > >> >> Thanks in advance for any suggestions. > >> >> > >> >> Alex > >> >> _______________________________________________ > >> >> 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 dinov at microsoft.com Tue Apr 14 20:31:50 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 14 Apr 2009 11:31:50 -0700 Subject: [IronPython] **kwargs and __getattr__ handling in csharp functions and classes? In-Reply-To: References: <2c77c440904140732y1fe0bf44p65062d5328de1043@mail.gmail.com> <350E7D38B6D819428718949920EC23555727007687@NA-EXMSG-C102.redmond.corp.microsoft.com> <2c77c440904140831p3eba4bc0r73bfc710655702c3@mail.gmail.com> <2c77c440904141102l753818abn276f2b089a06d3a3@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23555727007806@NA-EXMSG-C102.redmond.corp.microsoft.com> I think it might be just "Dynamic" in 2.0. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Tuesday, April 14, 2009 11:05 AM To: Discussion of IronPython Subject: Re: [IronPython] **kwargs and __getattr__ handling in csharp functions and classes? It should be Microsoft.Scripting.DynamicObject in 2.0. On Tue, Apr 14, 2009 at 11:02 AM, Alex News > wrote: Current IronPython = 2.01? I have Microsoft.Scripting.Core referenced, and can't find DynamicObject. There is an Microsoft.Scripting.Actions.IDynamicObject, and a Microsoft.Scripting.Runtime.IOldDynamicObject. I'm sure I'm missing something very basic. We are using .net 2.0.50727 SP1 On Tue, Apr 14, 2009 at 12:12 PM, Curt Hagenlocher > wrote: > In current versions of IronPython, DynamicObject is in > Microsoft.Scripting.Core as Microsoft.Scripting.DynamicObject. In .NET 4.0 > System.Core, the same class will be called System.Dynamic.DynamicObject. (I > just noticed this naming discrepancy today, and I think we should probably > move it to at least Microsoft.Dynamic for the 2.6 release.) > > On Tue, Apr 14, 2009 at 8:31 AM, Alex News > wrote: >> >> Much appreciated, I will give that a try. In what namespace is >> DynamicObject declared? (I assume the required assemblies are already >> referenced if I'm pulling in IronPython). >> >> Thanks again, >> Alex >> >> >> On Tue, Apr 14, 2009 at 11:16 AM, Dino Viehland > >> wrote: >> > For kwargs you need to decorate the function w/ a ParamDictionary >> > attribute such as: >> > >> > public void __init__(CodeContext/*!*/ context, object o, >> > [ParamDictionary] IAttributesCollection kwArgs) >> > >> > For __getattr__ IronPython will recognize a special name >> > "GetBoundMember" method such as: >> > >> > using System; >> > using System.Runtime.CompilerServices; >> > >> > public class Foo { >> > [SpecialName] >> > public object GetBoundMember (string name) { >> > return name; >> > } >> > } >> > >> > >> > You can also do "GetCustomMember" which is like __getattribute__. But >> > for this one what you really want to do is inherit directly from the >> > DynamicObject class and override TryGetMember. Then it'll work not only w/ >> > Python but w/ other DLR based languages as well (e.g. C#, VB.NET, IronRuby, >> > etc...). >> > >> > >> >> -----Original Message----- >> >> From: users-bounces at lists.ironpython.com [mailto:users- >> >> bounces at lists.ironpython.com] On Behalf Of Alex News >> >> Sent: Tuesday, April 14, 2009 7:32 AM >> >> To: users at lists.ironpython.com >> >> Subject: [IronPython] **kwargs and __getattr__ handling in csharp >> >> functions and classes? >> >> >> >> I would like to write some functions and classes in csharp that >> >> interact nicely python. I would like to write a function that can >> >> respond to keyword arguments, and a class that can dynamically resolve >> >> __getattr__. >> >> >> >> For the function I tried creating a function that takes a >> >> IronPython.Runtime.PythonDictionary, but did not work. For a class I >> >> tried creating a function that have a method __getattr__, but that >> >> failed too. >> >> >> >> I see there is a IronPython.Runtime.PythonFunction and some other >> >> interesting classes in the Runtime, but it is not apparent exactly how >> >> I could use them. >> >> >> >> I can, luckily, fudge much of what I want to do by creating small >> >> python classes and functions in python to proxy the values to >> >> underlying csharp classes. However thing would be cleaner if I could >> >> do it directly in csharp. >> >> >> >> Thanks in advance for any suggestions. >> >> >> >> Alex >> >> _______________________________________________ >> >> 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 anleewxs at gmail.com Tue Apr 14 20:58:58 2009 From: anleewxs at gmail.com (Alex News) Date: Tue, 14 Apr 2009 14:58:58 -0400 Subject: [IronPython] **kwargs and __getattr__ handling in csharp functions and classes? In-Reply-To: <350E7D38B6D819428718949920EC23555727007806@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <2c77c440904140732y1fe0bf44p65062d5328de1043@mail.gmail.com> <350E7D38B6D819428718949920EC23555727007687@NA-EXMSG-C102.redmond.corp.microsoft.com> <2c77c440904140831p3eba4bc0r73bfc710655702c3@mail.gmail.com> <2c77c440904141102l753818abn276f2b089a06d3a3@mail.gmail.com> <350E7D38B6D819428718949920EC23555727007806@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <2c77c440904141158p5521dee2ifc5b5e06f9d12777@mail.gmail.com> Well I am either suffering from severe user error, or it is not in the suggested locations. The best I could find was Microsoft.Scripting.Actions.Dynamic. It implements IDynamicObject. It does not have the aforementioned TryGetMember function to override, but does have a GetMember function to override. On Tue, Apr 14, 2009 at 2:31 PM, Dino Viehland wrote: > I think it might be just ?Dynamic? in 2.0. > > > > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher > Sent: Tuesday, April 14, 2009 11:05 AM > To: Discussion of IronPython > Subject: Re: [IronPython] **kwargs and __getattr__ handling in csharp > functions and classes? > > > > It should be Microsoft.Scripting.DynamicObject in 2.0. > > On Tue, Apr 14, 2009 at 11:02 AM, Alex News wrote: > > Current IronPython = 2.01? ?I have Microsoft.Scripting.Core > referenced, and can't find DynamicObject. ?There is an > Microsoft.Scripting.Actions.IDynamicObject, and a > Microsoft.Scripting.Runtime.IOldDynamicObject. ?I'm sure I'm missing > something very basic. > > We are using .net 2.0.50727 SP1 > > > > On Tue, Apr 14, 2009 at 12:12 PM, Curt Hagenlocher > wrote: >> In current versions of IronPython, DynamicObject is in >> Microsoft.Scripting.Core as Microsoft.Scripting.DynamicObject.? In .NET >> 4.0 >> System.Core, the same class?will be called System.Dynamic.DynamicObject. >> (I >> just noticed this naming discrepancy today, and I think we should probably >> move it to at least Microsoft.Dynamic for the 2.6 release.) >> >> On Tue, Apr 14, 2009 at 8:31 AM, Alex News wrote: >>> >>> Much appreciated, I will give that a try. ?In what namespace is >>> DynamicObject declared? ?(I assume the required assemblies are already >>> referenced if I'm pulling in IronPython). >>> >>> Thanks again, >>> Alex >>> >>> >>> On Tue, Apr 14, 2009 at 11:16 AM, Dino Viehland >>> wrote: >>> > For kwargs you need to decorate the function w/ a ParamDictionary >>> > attribute such as: >>> > >>> > public void __init__(CodeContext/*!*/ context, object o, >>> > [ParamDictionary] IAttributesCollection kwArgs) >>> > >>> > For __getattr__ IronPython will recognize a special name >>> > "GetBoundMember" method such as: >>> > >>> > using System; >>> > using System.Runtime.CompilerServices; >>> > >>> > public class Foo { >>> > ? ?[SpecialName] >>> > ? ?public object GetBoundMember (string name) { >>> > ? ? ? ?return name; >>> > ? ?} >>> > } >>> > >>> > >>> > You can also do "GetCustomMember" which is like __getattribute__. ?But >>> > for this one what you really want to do is inherit directly from the >>> > DynamicObject class and override TryGetMember. ?Then it'll work not >>> > only w/ >>> > Python but w/ other DLR based languages as well (e.g. C#, VB.NET, >>> > IronRuby, >>> > etc...). >>> > >>> > >>> >> -----Original Message----- >>> >> From: users-bounces at lists.ironpython.com [mailto:users- >>> >> bounces at lists.ironpython.com] On Behalf Of Alex News >>> >> Sent: Tuesday, April 14, 2009 7:32 AM >>> >> To: users at lists.ironpython.com >>> >> Subject: [IronPython] **kwargs and __getattr__ handling in csharp >>> >> functions and classes? >>> >> >>> >> I would like to write some functions and classes in csharp that >>> >> interact nicely python. ?I would like to write a function that can >>> >> respond to keyword arguments, and a class that can dynamically resolve >>> >> __getattr__. >>> >> >>> >> For the function I tried creating a function that takes a >>> >> IronPython.Runtime.PythonDictionary, but did not work. ?For a class I >>> >> tried creating a function that have a method __getattr__, but that >>> >> failed too. >>> >> >>> >> I see there is a IronPython.Runtime.PythonFunction and some other >>> >> interesting classes in the Runtime, but it is not apparent exactly how >>> >> I could use them. >>> >> >>> >> I can, luckily, fudge much of what I want to do by creating small >>> >> python classes and functions in python to proxy the values to >>> >> underlying csharp classes. ?However thing would be cleaner if I could >>> >> do it directly in csharp. >>> >> >>> >> Thanks in advance for any suggestions. >>> >> >>> >> Alex >>> >> _______________________________________________ >>> >> Users mailing list >>> >> Users at lists.ironpython.com >>> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> > >>> > _______________________________________________ >>> > Users mailing list >>> > Users at lists.ironpython.com >>> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> > >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From curt at hagenlocher.org Tue Apr 14 21:04:16 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 14 Apr 2009 12:04:16 -0700 Subject: [IronPython] **kwargs and __getattr__ handling in csharp functions and classes? In-Reply-To: <2c77c440904141158p5521dee2ifc5b5e06f9d12777@mail.gmail.com> References: <2c77c440904140732y1fe0bf44p65062d5328de1043@mail.gmail.com> <350E7D38B6D819428718949920EC23555727007687@NA-EXMSG-C102.redmond.corp.microsoft.com> <2c77c440904140831p3eba4bc0r73bfc710655702c3@mail.gmail.com> <2c77c440904141102l753818abn276f2b089a06d3a3@mail.gmail.com> <350E7D38B6D819428718949920EC23555727007806@NA-EXMSG-C102.redmond.corp.microsoft.com> <2c77c440904141158p5521dee2ifc5b5e06f9d12777@mail.gmail.com> Message-ID: No, that's the right class. Apparently, it's been changed a bit since ~late October when we branched off the 2.0 source. On Tue, Apr 14, 2009 at 11:58 AM, Alex News wrote: > Well I am either suffering from severe user error, or it is not in the > suggested locations. The best I could find was > Microsoft.Scripting.Actions.Dynamic. It implements IDynamicObject. > It does not have the aforementioned TryGetMember function to override, > but does have a GetMember function to override. > > > On Tue, Apr 14, 2009 at 2:31 PM, Dino Viehland > wrote: > > I think it might be just ?Dynamic? in 2.0. > > > > > > > > From: users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt > Hagenlocher > > Sent: Tuesday, April 14, 2009 11:05 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] **kwargs and __getattr__ handling in csharp > > functions and classes? > > > > > > > > It should be Microsoft.Scripting.DynamicObject in 2.0. > > > > On Tue, Apr 14, 2009 at 11:02 AM, Alex News wrote: > > > > Current IronPython = 2.01? I have Microsoft.Scripting.Core > > referenced, and can't find DynamicObject. There is an > > Microsoft.Scripting.Actions.IDynamicObject, and a > > Microsoft.Scripting.Runtime.IOldDynamicObject. I'm sure I'm missing > > something very basic. > > > > We are using .net 2.0.50727 SP1 > > > > > > > > On Tue, Apr 14, 2009 at 12:12 PM, Curt Hagenlocher > > > wrote: > >> In current versions of IronPython, DynamicObject is in > >> Microsoft.Scripting.Core as Microsoft.Scripting.DynamicObject. In .NET > >> 4.0 > >> System.Core, the same class will be called System.Dynamic.DynamicObject. > >> (I > >> just noticed this naming discrepancy today, and I think we should > probably > >> move it to at least Microsoft.Dynamic for the 2.6 release.) > >> > >> On Tue, Apr 14, 2009 at 8:31 AM, Alex News wrote: > >>> > >>> Much appreciated, I will give that a try. In what namespace is > >>> DynamicObject declared? (I assume the required assemblies are already > >>> referenced if I'm pulling in IronPython). > >>> > >>> Thanks again, > >>> Alex > >>> > >>> > >>> On Tue, Apr 14, 2009 at 11:16 AM, Dino Viehland > >>> wrote: > >>> > For kwargs you need to decorate the function w/ a ParamDictionary > >>> > attribute such as: > >>> > > >>> > public void __init__(CodeContext/*!*/ context, object o, > >>> > [ParamDictionary] IAttributesCollection kwArgs) > >>> > > >>> > For __getattr__ IronPython will recognize a special name > >>> > "GetBoundMember" method such as: > >>> > > >>> > using System; > >>> > using System.Runtime.CompilerServices; > >>> > > >>> > public class Foo { > >>> > [SpecialName] > >>> > public object GetBoundMember (string name) { > >>> > return name; > >>> > } > >>> > } > >>> > > >>> > > >>> > You can also do "GetCustomMember" which is like __getattribute__. > But > >>> > for this one what you really want to do is inherit directly from the > >>> > DynamicObject class and override TryGetMember. Then it'll work not > >>> > only w/ > >>> > Python but w/ other DLR based languages as well (e.g. C#, VB.NET > , > >>> > IronRuby, > >>> > etc...). > >>> > > >>> > > >>> >> -----Original Message----- > >>> >> From: users-bounces at lists.ironpython.com [mailto:users- > >>> >> bounces at lists.ironpython.com] On Behalf Of Alex News > >>> >> Sent: Tuesday, April 14, 2009 7:32 AM > >>> >> To: users at lists.ironpython.com > >>> >> Subject: [IronPython] **kwargs and __getattr__ handling in csharp > >>> >> functions and classes? > >>> >> > >>> >> I would like to write some functions and classes in csharp that > >>> >> interact nicely python. I would like to write a function that can > >>> >> respond to keyword arguments, and a class that can dynamically > resolve > >>> >> __getattr__. > >>> >> > >>> >> For the function I tried creating a function that takes a > >>> >> IronPython.Runtime.PythonDictionary, but did not work. For a class > I > >>> >> tried creating a function that have a method __getattr__, but that > >>> >> failed too. > >>> >> > >>> >> I see there is a IronPython.Runtime.PythonFunction and some other > >>> >> interesting classes in the Runtime, but it is not apparent exactly > how > >>> >> I could use them. > >>> >> > >>> >> I can, luckily, fudge much of what I want to do by creating small > >>> >> python classes and functions in python to proxy the values to > >>> >> underlying csharp classes. However thing would be cleaner if I > could > >>> >> do it directly in csharp. > >>> >> > >>> >> Thanks in advance for any suggestions. > >>> >> > >>> >> Alex > >>> >> _______________________________________________ > >>> >> 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 > > > > > _______________________________________________ > 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 tggagne at gmail.com Thu Apr 16 01:40:52 2009 From: tggagne at gmail.com (Thomas Gagne) Date: Wed, 15 Apr 2009 19:40:52 -0400 Subject: [IronPython] ipy.exe not found -- sorry, haven't programmed on windows since 90s Message-ID: <49E67084.1000101@gmail.com> I apologize for the next several questions. I'm want to play with a .net library but don't want to doit in C# or VB. I prefer dynamic languages. Anyway, I have a few questions I'm struggling to find complete examples for. First, in my test directory inside either cmd or powershell, ipy.exe isn't found when I enter it on the command line. I tried changing the PATH environment variable: setenv PATH=%PATH%;c:\Program Files\Iron Python 2.0.1\ and it shows in my environment, but still when I enter "ipy" at the command line it isn't found. What am I missing? Second, I need to add the directory with the DLLs of the library I want to play with. I think I need: import clr import sys sys.path = sys.path + ["c:\program files\syncfusion\essential studio\7.1.0.30\assemblies\3.5"] clr.AddReference("syncfusion.pdf.base") Does that make sense? If that's right, then I'm wondering how I can test to see if anything loaded, since PdfDocument() can't be found. -------------- next part -------------- A non-text attachment was scrubbed... Name: tggagne.vcf Type: text/x-vcard Size: 406 bytes Desc: not available URL: From dfugate at microsoft.com Thu Apr 16 02:10:16 2009 From: dfugate at microsoft.com (Dave Fugate) Date: Wed, 15 Apr 2009 17:10:16 -0700 Subject: [IronPython] ipy.exe not found -- sorry, haven't programmed on windows since 90s In-Reply-To: <49E67084.1000101@gmail.com> References: <49E67084.1000101@gmail.com> Message-ID: Add "%ProgramFiles%\IronPython 2.0.1 " to %PATH%, not "%ProgramFiles%\Iron Python 2.0.1". Also, change '"c:\program files\syncfusion\essential studio\7.1.0.30\assemblies\3.5"' to 'r"c:\program files\syncfusion\essential studio\7.1.0.30\assemblies\3.5"'. Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Thomas Gagne Sent: Wednesday, April 15, 2009 4:41 PM To: users at lists.ironpython.com Subject: [IronPython] ipy.exe not found -- sorry, haven't programmed on windows since 90s I apologize for the next several questions. I'm want to play with a .net library but don't want to doit in C# or VB. I prefer dynamic languages. Anyway, I have a few questions I'm struggling to find complete examples for. First, in my test directory inside either cmd or powershell, ipy.exe isn't found when I enter it on the command line. I tried changing the PATH environment variable: setenv PATH=%PATH%;c:\Program Files\Iron Python 2.0.1\ and it shows in my environment, but still when I enter "ipy" at the command line it isn't found. What am I missing? Second, I need to add the directory with the DLLs of the library I want to play with. I think I need: import clr import sys sys.path = sys.path + ["c:\program files\syncfusion\essential studio\7.1.0.30\assemblies\3.5"] clr.AddReference("syncfusion.pdf.base") Does that make sense? If that's right, then I'm wondering how I can test to see if anything loaded, since PdfDocument() can't be found. From tggagne at gmail.com Thu Apr 16 18:38:28 2009 From: tggagne at gmail.com (Thomas Gagne) Date: Thu, 16 Apr 2009 12:38:28 -0400 Subject: [IronPython] ipy.exe not found -- sorry, haven't programmed on windows since 90s In-Reply-To: References: <49E67084.1000101@gmail.com> Message-ID: <001c01c9beb1$c64b1cf0$52e156d0$@com> I was able to get my program working. I still haven't gotten around to fixing the ipy.exe path thing, but the code below does what I hoped it would---work. import clr import sys import System sys.path.append('c:\\program files\\ceTe Software\\DynamicPDF v5.0.2 for .NET\\bin\\') clr.AddReference('ceTe.DynamicPDF.35') from ceTe.DynamicPDF import * from ceTe.DynamicPDF.PageElements import * document = Document() document.Author = "Thomas Gagne" document.Title = "Hello" page = Page(PageSize.Letter, PageOrientation.Portrait, 54.0) label = Label("Hello, world!", 0, 0, 504, 100, Font.Helvetica, 18, TextAlign.Center) page.Elements.Add(label) document.Pages.Add(page) document.Draw ("helloWorld.pdf") System.Diagnostics.Process.Start("helloWorld.pdf") From fuzzyman at voidspace.org.uk Thu Apr 16 19:05:58 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 16 Apr 2009 18:05:58 +0100 Subject: [IronPython] InteractiveCode and function definitions Message-ID: <49E76576.2020701@voidspace.org.uk> Hello guys, We're trying to detect whether a section of code is complete (to mimic the behaviour of the interactive interpreter). First of all we tried using the Python standard library code module which provides interactive console classes. There are two outstanding bugs on codeplex (one reported by me today) which prevent this being an ideal solution: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064 http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881 The second approach was to create a ScriptSource and looking at the code properties to tell if the statement is complete or not (using IronPython 2.0.1). However we can never get it to return a ScriptParseResult.Complete for function definitions. Code below shows using \n for newlines but we have also tried with \r\n. >>> import clr >>> clr.AddReference('IronPython') >>> clr.AddReference('Microsoft.Scripting') >>> from IronPython.Hosting import Python >>> from Microsoft.Scripting import SourceCodeKind, ScriptCodeParseResult >>> >>> engine = Python.CreateEngine() >>> s = engine.CreateScriptSourceFromString('def f():\n print 1\n', 'foo', SourceCodeKind.InteractiveCode) >>> s.GetCodeProperties() >>> s = engine.CreateScriptSourceFromString('def f():\n print 1\n\n', 'foo', SourceCodeKind.InteractiveCode) >>> s.GetCodeProperties() >>> The DLR hosting spec has little helpful to say on the matter as far as I can tell. Looking at an example from Tomas it doesn't seem very different from what we're doing: http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/ Any clues as to what we are doing wrong or how to procede? Thanks Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From curt at hagenlocher.org Thu Apr 16 19:24:06 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 16 Apr 2009 10:24:06 -0700 Subject: [IronPython] InteractiveCode and function definitions In-Reply-To: <49E76576.2020701@voidspace.org.uk> References: <49E76576.2020701@voidspace.org.uk> Message-ID: "IncompleteStatement" means that the user is allowed to type more code. If you want to know whether or not it's a valid (complete) string, just check for it not being Invalid. A function definition is never "complete" in Python because there's never a terminating curly brace :). On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord wrote: > Hello guys, > > We're trying to detect whether a section of code is complete (to mimic the > behaviour of the interactive interpreter). > > First of all we tried using the Python standard library code module which > provides interactive console classes. There are two outstanding bugs on > codeplex (one reported by me today) which prevent this being an ideal > solution: > > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064 > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881 > > The second approach was to create a ScriptSource and looking at the code > properties to tell if the statement is complete or not (using IronPython > 2.0.1). However we can never get it to return a ScriptParseResult.Complete > for function definitions. Code below shows using \n for newlines but we have > also tried with \r\n. > > >>> import clr > >>> clr.AddReference('IronPython') > >>> clr.AddReference('Microsoft.Scripting') > >>> from IronPython.Hosting import Python > >>> from Microsoft.Scripting import SourceCodeKind, ScriptCodeParseResult > >>> > >>> engine = Python.CreateEngine() > >>> s = engine.CreateScriptSourceFromString('def f():\n print 1\n', 'foo', > SourceCodeKind.InteractiveCode) > >>> s.GetCodeProperties() > [IncompleteStatement]> > >>> s = engine.CreateScriptSourceFromString('def f():\n print 1\n\n', > 'foo', SourceCodeKind.InteractiveCode) > >>> s.GetCodeProperties() > [IncompleteStatement]> > >>> > > The DLR hosting spec has little helpful to say on the matter as far as I > can tell. > > Looking at an example from Tomas it doesn't seem very different from what > we're doing: > > http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/ > > Any clues as to what we are doing wrong or how to procede? > > Thanks > > 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 fuzzyman at voidspace.org.uk Thu Apr 16 19:36:19 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 16 Apr 2009 18:36:19 +0100 Subject: [IronPython] InteractiveCode and function definitions In-Reply-To: References: <49E76576.2020701@voidspace.org.uk> Message-ID: <49E76C93.3000200@voidspace.org.uk> Curt Hagenlocher wrote: > "IncompleteStatement" means that the user is allowed to type more > code. If you want to know whether or not it's a valid (complete) > string, just check for it not being Invalid. A function definition is > never "complete" in Python because there's never a terminating curly > brace :). But that isn't sufficient to implement an interactive interpreter on top of. This code conceptually is complete as far as an interactive interpreter is concerned: 'def f():\n print 1\n\n' It also means you can't distinguish between the previous kind of incomplete (which is incomplete because the user *could* type more code) and this kind of incomplete: 'a = """' or: 'a = (1 + 2 +' Which are both incomplete because the user *must* type more code. (Although the latter two give IncompleteToken - I wonder if that would be enough.) Because of the other IronPython bugs we can't use the code module and ScriptSource / ScriptParseResult doesn't give sufficient information. Any other ideas? Michael > > On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord > > wrote: > > Hello guys, > > We're trying to detect whether a section of code is complete (to > mimic the behaviour of the interactive interpreter). > > First of all we tried using the Python standard library code > module which provides interactive console classes. There are two > outstanding bugs on codeplex (one reported by me today) which > prevent this being an ideal solution: > > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064 > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881 > > The second approach was to create a ScriptSource and looking at > the code properties to tell if the statement is complete or not > (using IronPython 2.0.1). However we can never get it to return a > ScriptParseResult.Complete for function definitions. Code below > shows using \n for newlines but we have also tried with \r\n. > > >>> import clr > >>> clr.AddReference('IronPython') > >>> clr.AddReference('Microsoft.Scripting') > >>> from IronPython.Hosting import Python > >>> from Microsoft.Scripting import SourceCodeKind, > ScriptCodeParseResult > >>> > >>> engine = Python.CreateEngine() > >>> s = engine.CreateScriptSourceFromString('def f():\n print > 1\n', 'foo', SourceCodeKind.InteractiveCode) > >>> s.GetCodeProperties() > 0x000000000000003F [IncompleteStatement]> > >>> s = engine.CreateScriptSourceFromString('def f():\n print > 1\n\n', 'foo', SourceCodeKind.InteractiveCode) > >>> s.GetCodeProperties() > 0x0000000000000040 [IncompleteStatement]> > >>> > > The DLR hosting spec has little helpful to say on the matter as > far as I can tell. > > Looking at an example from Tomas it doesn't seem very different > from what we're doing: > > http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/ > > Any clues as to what we are doing wrong or how to procede? > > Thanks > > 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 From curt at hagenlocher.org Thu Apr 16 19:51:35 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 16 Apr 2009 10:51:35 -0700 Subject: [IronPython] InteractiveCode and function definitions In-Reply-To: <49E76C93.3000200@voidspace.org.uk> References: <49E76576.2020701@voidspace.org.uk> <49E76C93.3000200@voidspace.org.uk> Message-ID: That's only because you've decided to arbitrarily[*] define "\n\n" as being a signal to mean "complete". That's not part of the actual language specification. In fact, if I append "\n\n print 2\n\n" to that string, it's still a valid Python program. The key here is that "the user has entered a complete thought" is a property of the interpreter and not of the language. I might well decide that the "commit" key sequence is Control+E (as it is in SQL Server Management Studio) instead of "enter enter". My point is that it's not correct for IronPython to dictate the semantics of your interpreter. [*] Okay, "arbitrary" is a bit strong in that it's what python.exe and ipy.exe defines. :) On Thu, Apr 16, 2009 at 10:36 AM, Michael Foord wrote: > Curt Hagenlocher wrote: > >> "IncompleteStatement" means that the user is allowed to type more code. >> If you want to know whether or not it's a valid (complete) string, just >> check for it not being Invalid. A function definition is never "complete" >> in Python because there's never a terminating curly brace :). >> > > But that isn't sufficient to implement an interactive interpreter on top > of. This code conceptually is complete as far as an interactive interpreter > is concerned: > > 'def f():\n print 1\n\n' > > It also means you can't distinguish between the previous kind of incomplete > (which is incomplete because the user *could* type more code) and this kind > of incomplete: > > 'a = """' > > or: > > 'a = (1 + 2 +' > > Which are both incomplete because the user *must* type more code. (Although > the latter two give IncompleteToken - I wonder if that would be enough.) > > Because of the other IronPython bugs we can't use the code module and > ScriptSource / ScriptParseResult doesn't give sufficient information. Any > other ideas? > > Michael > > >> On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord < >> fuzzyman at voidspace.org.uk > wrote: >> >> Hello guys, >> >> We're trying to detect whether a section of code is complete (to >> mimic the behaviour of the interactive interpreter). >> >> First of all we tried using the Python standard library code >> module which provides interactive console classes. There are two >> outstanding bugs on codeplex (one reported by me today) which >> prevent this being an ideal solution: >> >> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064 >> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881 >> >> The second approach was to create a ScriptSource and looking at >> the code properties to tell if the statement is complete or not >> (using IronPython 2.0.1). However we can never get it to return a >> ScriptParseResult.Complete for function definitions. Code below >> shows using \n for newlines but we have also tried with \r\n. >> >> >>> import clr >> >>> clr.AddReference('IronPython') >> >>> clr.AddReference('Microsoft.Scripting') >> >>> from IronPython.Hosting import Python >> >>> from Microsoft.Scripting import SourceCodeKind, >> ScriptCodeParseResult >> >>> >> >>> engine = Python.CreateEngine() >> >>> s = engine.CreateScriptSourceFromString('def f():\n print >> 1\n', 'foo', SourceCodeKind.InteractiveCode) >> >>> s.GetCodeProperties() >> > 0x000000000000003F [IncompleteStatement]> >> >>> s = engine.CreateScriptSourceFromString('def f():\n print >> 1\n\n', 'foo', SourceCodeKind.InteractiveCode) >> >>> s.GetCodeProperties() >> > 0x0000000000000040 [IncompleteStatement]> >> >>> >> >> The DLR hosting spec has little helpful to say on the matter as >> far as I can tell. >> >> Looking at an example from Tomas it doesn't seem very different >> from what we're doing: >> >> http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/ >> >> Any clues as to what we are doing wrong or how to procede? >> >> Thanks >> >> 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 > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Apr 16 19:54:37 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 16 Apr 2009 18:54:37 +0100 Subject: [IronPython] InteractiveCode and function definitions In-Reply-To: References: <49E76576.2020701@voidspace.org.uk> <49E76C93.3000200@voidspace.org.uk> Message-ID: <49E770DD.1000600@voidspace.org.uk> Curt Hagenlocher wrote: > That's only because you've decided to arbitrarily[*] define "\n\n" as > being a signal to mean "complete". That's not part of the actual > language specification. It's the behaviour of the interactive interpreter though - which specifies something. It's also the specification adhered to by the code module for implementing interactive interpreters. > In fact, if I append "\n\n print 2\n\n" to that string, it's still a > valid Python program. The key here is that "the user has entered a > complete thought" is a property of the interpreter and not of the > language. I might well decide that the "commit" key sequence is > Control+E (as it is in SQL Server Management Studio) instead of "enter > enter". > > My point is that it's not correct for IronPython to dictate the > semantics of your interpreter. Fine, so do you have any suggestions as to how to replicate the behaviour of the interactive interpreter - whether or not it counts as a specification? Michael > > [*] Okay, "arbitrary" is a bit strong in that it's what python.exe and > ipy.exe defines. :) > > On Thu, Apr 16, 2009 at 10:36 AM, Michael Foord > > wrote: > > Curt Hagenlocher wrote: > > "IncompleteStatement" means that the user is allowed to type > more code. If you want to know whether or not it's a valid > (complete) string, just check for it not being Invalid. A > function definition is never "complete" in Python because > there's never a terminating curly brace :). > > > But that isn't sufficient to implement an interactive interpreter > on top of. This code conceptually is complete as far as an > interactive interpreter is concerned: > > > 'def f():\n print 1\n\n' > > It also means you can't distinguish between the previous kind of > incomplete (which is incomplete because the user *could* type more > code) and this kind of incomplete: > > 'a = """' > > or: > > 'a = (1 + 2 +' > > Which are both incomplete because the user *must* type more code. > (Although the latter two give IncompleteToken - I wonder if that > would be enough.) > > Because of the other IronPython bugs we can't use the code module > and ScriptSource / ScriptParseResult doesn't give sufficient > information. Any other ideas? > > Michael > > > On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord > > >> wrote: > > Hello guys, > > We're trying to detect whether a section of code is > complete (to > mimic the behaviour of the interactive interpreter). > > First of all we tried using the Python standard library code > module which provides interactive console classes. There > are two > outstanding bugs on codeplex (one reported by me today) which > prevent this being an ideal solution: > > > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064 > > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881 > > The second approach was to create a ScriptSource and looking at > the code properties to tell if the statement is complete or not > (using IronPython 2.0.1). However we can never get it to > return a > ScriptParseResult.Complete for function definitions. Code below > shows using \n for newlines but we have also tried with \r\n. > > >>> import clr > >>> clr.AddReference('IronPython') > >>> clr.AddReference('Microsoft.Scripting') > >>> from IronPython.Hosting import Python > >>> from Microsoft.Scripting import SourceCodeKind, > ScriptCodeParseResult > >>> > >>> engine = Python.CreateEngine() > >>> s = engine.CreateScriptSourceFromString('def f():\n print > 1\n', 'foo', SourceCodeKind.InteractiveCode) > >>> s.GetCodeProperties() > 0x000000000000003F [IncompleteStatement]> > >>> s = engine.CreateScriptSourceFromString('def f():\n print > 1\n\n', 'foo', SourceCodeKind.InteractiveCode) > >>> s.GetCodeProperties() > 0x0000000000000040 [IncompleteStatement]> > >>> > > The DLR hosting spec has little helpful to say on the matter as > far as I can tell. > > Looking at an example from Tomas it doesn't seem very different > from what we're doing: > > http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/ > > Any clues as to what we are doing wrong or how to procede? > > Thanks > > 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 > > > _______________________________________________ > 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 From dinov at microsoft.com Thu Apr 16 19:59:54 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 16 Apr 2009 10:59:54 -0700 Subject: [IronPython] InteractiveCode and function definitions In-Reply-To: <49E770DD.1000600@voidspace.org.uk> References: <49E76576.2020701@voidspace.org.uk> <49E76C93.3000200@voidspace.org.uk> <49E770DD.1000600@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC235557270080AA@NA-EXMSG-C102.redmond.corp.microsoft.com> I suggest explicitly checking for the final blank line. That's what our command line does. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, April 16, 2009 10:55 AM > To: Discussion of IronPython > Subject: Re: [IronPython] InteractiveCode and function definitions > > Curt Hagenlocher wrote: > > That's only because you've decided to arbitrarily[*] define "\n\n" as > > being a signal to mean "complete". That's not part of the actual > > language specification. > It's the behaviour of the interactive interpreter though - which > specifies something. It's also the specification adhered to by the code > module for implementing interactive interpreters. > > > In fact, if I append "\n\n print 2\n\n" to that string, it's still a > > valid Python program. The key here is that "the user has entered a > > complete thought" is a property of the interpreter and not of the > > language. I might well decide that the "commit" key sequence is > > Control+E (as it is in SQL Server Management Studio) instead of > "enter > > enter". > > > > My point is that it's not correct for IronPython to dictate the > > semantics of your interpreter. > > Fine, so do you have any suggestions as to how to replicate the > behaviour of the interactive interpreter - whether or not it counts as > a > specification? > > Michael > > > > > [*] Okay, "arbitrary" is a bit strong in that it's what python.exe > and > > ipy.exe defines. :) > > > > On Thu, Apr 16, 2009 at 10:36 AM, Michael Foord > > > wrote: > > > > Curt Hagenlocher wrote: > > > > "IncompleteStatement" means that the user is allowed to type > > more code. If you want to know whether or not it's a valid > > (complete) string, just check for it not being Invalid. A > > function definition is never "complete" in Python because > > there's never a terminating curly brace :). > > > > > > But that isn't sufficient to implement an interactive interpreter > > on top of. This code conceptually is complete as far as an > > interactive interpreter is concerned: > > > > > > 'def f():\n print 1\n\n' > > > > It also means you can't distinguish between the previous kind of > > incomplete (which is incomplete because the user *could* type > more > > code) and this kind of incomplete: > > > > 'a = """' > > > > or: > > > > 'a = (1 + 2 +' > > > > Which are both incomplete because the user *must* type more code. > > (Although the latter two give IncompleteToken - I wonder if that > > would be enough.) > > > > Because of the other IronPython bugs we can't use the code module > > and ScriptSource / ScriptParseResult doesn't give sufficient > > information. Any other ideas? > > > > Michael > > > > > > On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord > > > > > >> wrote: > > > > Hello guys, > > > > We're trying to detect whether a section of code is > > complete (to > > mimic the behaviour of the interactive interpreter). > > > > First of all we tried using the Python standard library > code > > module which provides interactive console classes. There > > are two > > outstanding bugs on codeplex (one reported by me today) > which > > prevent this being an ideal solution: > > > > > > > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064 > > > > > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881 > > > > The second approach was to create a ScriptSource and > looking at > > the code properties to tell if the statement is complete > or not > > (using IronPython 2.0.1). However we can never get it to > > return a > > ScriptParseResult.Complete for function definitions. Code > below > > shows using \n for newlines but we have also tried with > \r\n. > > > > >>> import clr > > >>> clr.AddReference('IronPython') > > >>> clr.AddReference('Microsoft.Scripting') > > >>> from IronPython.Hosting import Python > > >>> from Microsoft.Scripting import SourceCodeKind, > > ScriptCodeParseResult > > >>> > > >>> engine = Python.CreateEngine() > > >>> s = engine.CreateScriptSourceFromString('def f():\n > print > > 1\n', 'foo', SourceCodeKind.InteractiveCode) > > >>> s.GetCodeProperties() > > > 0x000000000000003F [IncompleteStatement]> > > >>> s = engine.CreateScriptSourceFromString('def f():\n > print > > 1\n\n', 'foo', SourceCodeKind.InteractiveCode) > > >>> s.GetCodeProperties() > > > 0x0000000000000040 [IncompleteStatement]> > > >>> > > > > The DLR hosting spec has little helpful to say on the > matter as > > far as I can tell. > > > > Looking at an example from Tomas it doesn't seem very > different > > from what we're doing: > > > > http://blog.tomasm.net/2009/04/15/python-says-hello-to- > ruby/ > > > > Any clues as to what we are doing wrong or how to procede? > > > > Thanks > > > > 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 > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From curt at hagenlocher.org Thu Apr 16 20:00:23 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 16 Apr 2009 11:00:23 -0700 Subject: [IronPython] InteractiveCode and function definitions In-Reply-To: <49E770DD.1000600@voidspace.org.uk> References: <49E76576.2020701@voidspace.org.uk> <49E76C93.3000200@voidspace.org.uk> <49E770DD.1000600@voidspace.org.uk> Message-ID: What I've done is to test explicitly for the blank line at the end in conjuction with the test for ScriptCodeParseResult.IncompleteStatement: completeThought = (result == ScriptCodeParseResult.Complete or result == ScriptCodeParseResult.Invalid or (result == ScriptCodeParseResult.IncompleteStatement and text.endswith('\n\n'))) On Thu, Apr 16, 2009 at 10:54 AM, Michael Foord wrote: > Curt Hagenlocher wrote: > >> That's only because you've decided to arbitrarily[*] define "\n\n" as >> being a signal to mean "complete". That's not part of the actual language >> specification. >> > It's the behaviour of the interactive interpreter though - which specifies > something. It's also the specification adhered to by the code module for > implementing interactive interpreters. > > In fact, if I append "\n\n print 2\n\n" to that string, it's still a valid >> Python program. The key here is that "the user has entered a complete >> thought" is a property of the interpreter and not of the language. I might >> well decide that the "commit" key sequence is Control+E (as it is in SQL >> Server Management Studio) instead of "enter enter". >> My point is that it's not correct for IronPython to dictate the semantics >> of your interpreter. >> > > Fine, so do you have any suggestions as to how to replicate the behaviour > of the interactive interpreter - whether or not it counts as a > specification? > > Michael > > [*] Okay, "arbitrary" is a bit strong in that it's what python.exe and >> ipy.exe defines. :) >> >> On Thu, Apr 16, 2009 at 10:36 AM, Michael Foord < >> fuzzyman at voidspace.org.uk > wrote: >> >> Curt Hagenlocher wrote: >> >> "IncompleteStatement" means that the user is allowed to type >> more code. If you want to know whether or not it's a valid >> (complete) string, just check for it not being Invalid. A >> function definition is never "complete" in Python because >> there's never a terminating curly brace :). >> >> >> But that isn't sufficient to implement an interactive interpreter >> on top of. This code conceptually is complete as far as an >> interactive interpreter is concerned: >> >> >> 'def f():\n print 1\n\n' >> >> It also means you can't distinguish between the previous kind of >> incomplete (which is incomplete because the user *could* type more >> code) and this kind of incomplete: >> >> 'a = """' >> >> or: >> >> 'a = (1 + 2 +' >> >> Which are both incomplete because the user *must* type more code. >> (Although the latter two give IncompleteToken - I wonder if that >> would be enough.) >> >> Because of the other IronPython bugs we can't use the code module >> and ScriptSource / ScriptParseResult doesn't give sufficient >> information. Any other ideas? >> >> Michael >> >> >> On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord >> >> > >> wrote: >> >> Hello guys, >> >> We're trying to detect whether a section of code is >> complete (to >> mimic the behaviour of the interactive interpreter). >> >> First of all we tried using the Python standard library code >> module which provides interactive console classes. There >> are two >> outstanding bugs on codeplex (one reported by me today) which >> prevent this being an ideal solution: >> >> >> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064 >> >> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881 >> >> The second approach was to create a ScriptSource and looking at >> the code properties to tell if the statement is complete or not >> (using IronPython 2.0.1). However we can never get it to >> return a >> ScriptParseResult.Complete for function definitions. Code below >> shows using \n for newlines but we have also tried with \r\n. >> >> >>> import clr >> >>> clr.AddReference('IronPython') >> >>> clr.AddReference('Microsoft.Scripting') >> >>> from IronPython.Hosting import Python >> >>> from Microsoft.Scripting import SourceCodeKind, >> ScriptCodeParseResult >> >>> >> >>> engine = Python.CreateEngine() >> >>> s = engine.CreateScriptSourceFromString('def f():\n print >> 1\n', 'foo', SourceCodeKind.InteractiveCode) >> >>> s.GetCodeProperties() >> > 0x000000000000003F [IncompleteStatement]> >> >>> s = engine.CreateScriptSourceFromString('def f():\n print >> 1\n\n', 'foo', SourceCodeKind.InteractiveCode) >> >>> s.GetCodeProperties() >> > 0x0000000000000040 [IncompleteStatement]> >> >>> >> >> The DLR hosting spec has little helpful to say on the matter as >> far as I can tell. >> >> Looking at an example from Tomas it doesn't seem very different >> from what we're doing: >> >> http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/ >> >> Any clues as to what we are doing wrong or how to procede? >> >> Thanks >> >> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Apr 16 20:01:48 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 16 Apr 2009 19:01:48 +0100 Subject: [IronPython] InteractiveCode and function definitions In-Reply-To: References: <49E76576.2020701@voidspace.org.uk> <49E76C93.3000200@voidspace.org.uk> <49E770DD.1000600@voidspace.org.uk> Message-ID: <49E7728C.8000203@voidspace.org.uk> Curt Hagenlocher wrote: > What I've done is to test explicitly for the blank line at the end in > conjuction with the test for ScriptCodeParseResult.IncompleteStatement: > > completeThought = (result == ScriptCodeParseResult.Complete or > result == ScriptCodeParseResult.Invalid or > (result == ScriptCodeParseResult.IncompleteStatement and > text.endswith('\n\n'))) Thanks guys - I've got a working implementation that seems to handle all the cases we need. Nice one. Michael > > On Thu, Apr 16, 2009 at 10:54 AM, Michael Foord > > wrote: > > Curt Hagenlocher wrote: > > That's only because you've decided to arbitrarily[*] define > "\n\n" as being a signal to mean "complete". That's not part > of the actual language specification. > > It's the behaviour of the interactive interpreter though - which > specifies something. It's also the specification adhered to by the > code module for implementing interactive interpreters. > > > In fact, if I append "\n\n print 2\n\n" to that string, it's > still a valid Python program. The key here is that "the user > has entered a complete thought" is a property of the > interpreter and not of the language. I might well decide that > the "commit" key sequence is Control+E (as it is in SQL Server > Management Studio) instead of "enter enter". > My point is that it's not correct for IronPython to dictate > the semantics of your interpreter. > > > Fine, so do you have any suggestions as to how to replicate the > behaviour of the interactive interpreter - whether or not it > counts as a specification? > > Michael > > [*] Okay, "arbitrary" is a bit strong in that it's what > python.exe and ipy.exe defines. :) > > On Thu, Apr 16, 2009 at 10:36 AM, Michael Foord > > >> wrote: > > Curt Hagenlocher wrote: > > "IncompleteStatement" means that the user is allowed to > type > more code. If you want to know whether or not it's a valid > (complete) string, just check for it not being Invalid. A > function definition is never "complete" in Python because > there's never a terminating curly brace :). > > > But that isn't sufficient to implement an interactive > interpreter > on top of. This code conceptually is complete as far as an > interactive interpreter is concerned: > > > 'def f():\n print 1\n\n' > > It also means you can't distinguish between the previous > kind of > incomplete (which is incomplete because the user *could* > type more > code) and this kind of incomplete: > > 'a = """' > > or: > > 'a = (1 + 2 +' > > Which are both incomplete because the user *must* type more > code. > (Although the latter two give IncompleteToken - I wonder if > that > would be enough.) > > Because of the other IronPython bugs we can't use the code > module > and ScriptSource / ScriptParseResult doesn't give sufficient > information. Any other ideas? > > Michael > > > On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord > > > > > >>> wrote: > > Hello guys, > > We're trying to detect whether a section of code is > complete (to > mimic the behaviour of the interactive interpreter). > > First of all we tried using the Python standard > library code > module which provides interactive console classes. There > are two > outstanding bugs on codeplex (one reported by me > today) which > prevent this being an ideal solution: > > > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064 > > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881 > > The second approach was to create a ScriptSource and > looking at > the code properties to tell if the statement is > complete or not > (using IronPython 2.0.1). However we can never get it to > return a > ScriptParseResult.Complete for function definitions. > Code below > shows using \n for newlines but we have also tried > with \r\n. > > >>> import clr > >>> clr.AddReference('IronPython') > >>> clr.AddReference('Microsoft.Scripting') > >>> from IronPython.Hosting import Python > >>> from Microsoft.Scripting import SourceCodeKind, > ScriptCodeParseResult > >>> > >>> engine = Python.CreateEngine() > >>> s = engine.CreateScriptSourceFromString('def > f():\n print > 1\n', 'foo', SourceCodeKind.InteractiveCode) > >>> s.GetCodeProperties() > 0x000000000000003F [IncompleteStatement]> > >>> s = engine.CreateScriptSourceFromString('def > f():\n print > 1\n\n', 'foo', SourceCodeKind.InteractiveCode) > >>> s.GetCodeProperties() > 0x0000000000000040 [IncompleteStatement]> > >>> > > The DLR hosting spec has little helpful to say on > the matter as > far as I can tell. > > Looking at an example from Tomas it doesn't seem > very different > from what we're doing: > > > http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/ > > Any clues as to what we are doing wrong or how to > procede? > > Thanks > > 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 > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 From adamb at silverkeytech.com Thu Apr 16 20:11:43 2009 From: adamb at silverkeytech.com (Adam Brand) Date: Thu, 16 Apr 2009 11:11:43 -0700 Subject: [IronPython] Announcing IronPython 2.6 Alpha 1 In-Reply-To: References: <918705E903F4714CB713D89AB5F1857D884DB20530@NA-EXMSG-C116.redmond.corp.microsoft.com> <49CBEECA.2080104@resolversystems.com> <8cd017b80903281309m4a1e2767n9003a4034a8b0113@mail.gmail.com> <064c01c9afe4$f736d560$e5a48020$@com> Message-ID: <8bd92c0e0904161111m344f0dc5v6d1834bc2e3eb510@mail.gmail.com> Is there any updated timeline on this? Looking forward to it :-). I'm sure you're swamped...if there is anything the community can do to speed this up please let us know. Thanks, Adam On Mon, Mar 30, 2009 at 4:44 PM, Jimmy Schementi < Jimmy.Schementi at microsoft.com> wrote: > A IronPython 2.6 version of the ASP.NET integration will be out shortly, > I have to get time to make a build and get it sent over to the ASP.NETteam. I?m working through some other things I need to get done first, but > assume two weeks. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Adam Brand > *Sent:* Saturday, March 28, 2009 1:37 PM > > *To:* 'Discussion of IronPython' > *Subject:* Re: [IronPython] Announcing IronPython 2.6 Alpha 1 > > > > Any update on the timeline for getting IronPython for ASP.Net updated? This > would make a world of difference for our IronPython-based web app. > > > > Adam > > > > Adam Brand > > SilverKey Technologies > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata > *Sent:* Saturday, March 28, 2009 1:09 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Announcing IronPython 2.6 Alpha 1 > > > > This is awesome. Web application can benefit from this "adaptive > compilation" approach a lot - especially for low trafficked sites. > > On Thu, Mar 26, 2009 at 11:08 PM, Giles Thomas < > giles.thomas at resolversystems.com> wrote: > > Dave, > > This is great news, congratulations to the IP team on this release! We'll > do a test-port of Resolver One early next week and will reply to the list > with any issues we find. > > > Cheers, > > Giles > > > Dave Fugate wrote: > > Hello Python Community, > > We?re pleased to announce the release of IronPython 2.6 Alpha 1. As you > might imagine, this release is all about supporting new CPython 2.6 features > such as the ?bytes? and ?bytearray? types (PEP 3112), decorators for classes > (PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET > version required for this release is the same as IronPython 2.0; namely .NET > 2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release > only a couple Alphas and Betas of IronPython 2.6. As such, it?s key that we > get your feedback on the release(s) quickly to incorporate requested > changes. > > Besides CPython 2.6 features, another significant change in this release is > that ipy.exe now uses ?adaptive compilation? by default. Adaptive > compilation is a technique in which IronPython: > > 1. Interprets and executes Python method calls up to /N/ times for a given > method. If you?re only going to execute a method a few times, it?s typically > faster to interpret the method instead of compiling and executing it > > 2. Compiles and executes the Python method call on the /N+1/ invocation of > the method. Compilation of a Python method is a heavyweight operation, but > we can reuse the result for subsequent invocations > > 3. Reuses the previously compiled method for new calls to the Python > method. This operation is much faster than interpreting the method call as > the method was already compiled in the previous step > > The reason for this change is that it provides a nice performance gain for > Python code containing lots of functions/methods that only get called a few > times. All this said, this feature is still undergoing active development > and as a consequence some Python scripts may actually run slower with it > turned on. For this reason, our old default mode of running Python scripts > is still available by passing the ?O or -D flags to ipy.exe. Any feedback on > how this new feature affects your IronPython applications performance-wise > would be greatly appreciated. > > There?s also a few minor changes since IronPython 2.0.1 that are worth > calling out here: > > ? IronPython.msi now installs NGEN?ed binaries by default > > ? IronPython.msi now offers a little more selection with respect to what > you?d like to install. For example, Silverlight templates are optional > > ? The default installation location of IronPython.msi no longer indicates > whether the 2.6 release is an Alpha, Beta, or a patched release. Future > IronPython 2.6 installations will replace previous 2.6 releases which will > be uninstalled automatically > > ? The -X:PreferComInteropAssembly flag has been removed. All COM interop is > now done through normal COM dispatch > > You can download IronPython 2.6 Alpha 1 at: > http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22982 > > The IronPython Team > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 > > > > > -- > nomadlife.org > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- Adam Brand Managing Partner SilverKey Technologies Direct: +1-312-239-6722 Main: +1-312-951-7525 Skype: adamsilverkey Email: adamb at silverkeytech.com www.silverkeytech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tggagne at gmail.com Thu Apr 16 21:57:05 2009 From: tggagne at gmail.com (Thomas Gagne) Date: Thu, 16 Apr 2009 15:57:05 -0400 Subject: [IronPython] ipy.exe not found -- sorry, haven't programmed on windows since 90s In-Reply-To: References: <49E67084.1000101@gmail.com> Message-ID: <000001c9becd$85d965c0$918c3140$@com> Hurray! The Path is now working! Thanks for your help. From Jimmy.Schementi at microsoft.com Fri Apr 17 21:11:46 2009 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Fri, 17 Apr 2009 19:11:46 +0000 Subject: [IronPython] Announcing IronPython 2.6 Alpha 1 In-Reply-To: <8bd92c0e0904161111m344f0dc5v6d1834bc2e3eb510@mail.gmail.com> References: <918705E903F4714CB713D89AB5F1857D884DB20530@NA-EXMSG-C116.redmond.corp.microsoft.com> <49CBEECA.2080104@resolversystems.com> <8cd017b80903281309m4a1e2767n9003a4034a8b0113@mail.gmail.com> <064c01c9afe4$f736d560$e5a48020$@com> <8bd92c0e0904161111m344f0dc5v6d1834bc2e3eb510@mail.gmail.com> Message-ID: I guess I really meant 3 weeks, because I was doing Lang.NET conference stuff all this past week. Sorry for the wait. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Adam Brand Sent: Thursday, April 16, 2009 11:12 AM To: Discussion of IronPython Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1 Is there any updated timeline on this? Looking forward to it :-). I'm sure you're swamped...if there is anything the community can do to speed this up please let us know. Thanks, Adam On Mon, Mar 30, 2009 at 4:44 PM, Jimmy Schementi > wrote: A IronPython 2.6 version of the ASP.NET integration will be out shortly, I have to get time to make a build and get it sent over to the ASP.NET team. I'm working through some other things I need to get done first, but assume two weeks. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Adam Brand Sent: Saturday, March 28, 2009 1:37 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1 Any update on the timeline for getting IronPython for ASP.Net updated? This would make a world of difference for our IronPython-based web app. Adam Adam Brand SilverKey Technologies From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata Sent: Saturday, March 28, 2009 1:09 PM To: Discussion of IronPython Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1 This is awesome. Web application can benefit from this "adaptive compilation" approach a lot - especially for low trafficked sites. On Thu, Mar 26, 2009 at 11:08 PM, Giles Thomas > wrote: Dave, This is great news, congratulations to the IP team on this release! We'll do a test-port of Resolver One early next week and will reply to the list with any issues we find. Cheers, Giles Dave Fugate wrote: Hello Python Community, We're pleased to announce the release of IronPython 2.6 Alpha 1. As you might imagine, this release is all about supporting new CPython 2.6 features such as the 'bytes' and 'bytearray' types (PEP 3112), decorators for classes (PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET version required for this release is the same as IronPython 2.0; namely .NET 2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release only a couple Alphas and Betas of IronPython 2.6. As such, it's key that we get your feedback on the release(s) quickly to incorporate requested changes. Besides CPython 2.6 features, another significant change in this release is that ipy.exe now uses "adaptive compilation" by default. Adaptive compilation is a technique in which IronPython: 1. Interprets and executes Python method calls up to /N/ times for a given method. If you're only going to execute a method a few times, it's typically faster to interpret the method instead of compiling and executing it 2. Compiles and executes the Python method call on the /N+1/ invocation of the method. Compilation of a Python method is a heavyweight operation, but we can reuse the result for subsequent invocations 3. Reuses the previously compiled method for new calls to the Python method. This operation is much faster than interpreting the method call as the method was already compiled in the previous step The reason for this change is that it provides a nice performance gain for Python code containing lots of functions/methods that only get called a few times. All this said, this feature is still undergoing active development and as a consequence some Python scripts may actually run slower with it turned on. For this reason, our old default mode of running Python scripts is still available by passing the -O or -D flags to ipy.exe. Any feedback on how this new feature affects your IronPython applications performance-wise would be greatly appreciated. There's also a few minor changes since IronPython 2.0.1 that are worth calling out here: * IronPython.msi now installs NGEN'ed binaries by default * IronPython.msi now offers a little more selection with respect to what you'd like to install. For example, Silverlight templates are optional * The default installation location of IronPython.msi no longer indicates whether the 2.6 release is an Alpha, Beta, or a patched release. Future IronPython 2.6 installations will replace previous 2.6 releases which will be uninstalled automatically * The -X:PreferComInteropAssembly flag has been removed. All COM interop is now done through normal COM dispatch You can download IronPython 2.6 Alpha 1 at: http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22982 The IronPython Team ------------------------------------------------------------------------ _______________________________________________ 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 -- nomadlife.org _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Adam Brand Managing Partner SilverKey Technologies Direct: +1-312-239-6722 Main: +1-312-951-7525 Skype: adamsilverkey Email: adamb at silverkeytech.com www.silverkeytech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamb at silverkeytech.com Fri Apr 17 21:45:07 2009 From: adamb at silverkeytech.com (Adam Brand) Date: Fri, 17 Apr 2009 12:45:07 -0700 Subject: [IronPython] Announcing IronPython 2.6 Alpha 1 In-Reply-To: References: <918705E903F4714CB713D89AB5F1857D884DB20530@NA-EXMSG-C116.redmond.corp.microsoft.com> <49CBEECA.2080104@resolversystems.com> <8cd017b80903281309m4a1e2767n9003a4034a8b0113@mail.gmail.com> <064c01c9afe4$f736d560$e5a48020$@com> <8bd92c0e0904161111m344f0dc5v6d1834bc2e3eb510@mail.gmail.com> Message-ID: <00ef01c9bf95$03aa3b10$0afeb130$@com> No worries.just excited to get it J. Thanks for continuing to work on it. Adam Adam Brand SilverKey Technologies From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jimmy Schementi Sent: Friday, April 17, 2009 12:12 PM To: Discussion of IronPython Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1 I guess I really meant 3 weeks, because I was doing Lang.NET conference stuff all this past week. Sorry for the wait. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Adam Brand Sent: Thursday, April 16, 2009 11:12 AM To: Discussion of IronPython Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1 Is there any updated timeline on this? Looking forward to it :-). I'm sure you're swamped...if there is anything the community can do to speed this up please let us know. Thanks, Adam On Mon, Mar 30, 2009 at 4:44 PM, Jimmy Schementi wrote: A IronPython 2.6 version of the ASP.NET integration will be out shortly, I have to get time to make a build and get it sent over to the ASP.NET team. I'm working through some other things I need to get done first, but assume two weeks. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Adam Brand Sent: Saturday, March 28, 2009 1:37 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1 Any update on the timeline for getting IronPython for ASP.Net updated? This would make a world of difference for our IronPython-based web app. Adam Adam Brand SilverKey Technologies From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata Sent: Saturday, March 28, 2009 1:09 PM To: Discussion of IronPython Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1 This is awesome. Web application can benefit from this "adaptive compilation" approach a lot - especially for low trafficked sites. On Thu, Mar 26, 2009 at 11:08 PM, Giles Thomas wrote: Dave, This is great news, congratulations to the IP team on this release! We'll do a test-port of Resolver One early next week and will reply to the list with any issues we find. Cheers, Giles Dave Fugate wrote: Hello Python Community, We're pleased to announce the release of IronPython 2.6 Alpha 1. As you might imagine, this release is all about supporting new CPython 2.6 features such as the 'bytes' and 'bytearray' types (PEP 3112), decorators for classes (PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET version required for this release is the same as IronPython 2.0; namely .NET 2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release only a couple Alphas and Betas of IronPython 2.6. As such, it's key that we get your feedback on the release(s) quickly to incorporate requested changes. Besides CPython 2.6 features, another significant change in this release is that ipy.exe now uses "adaptive compilation" by default. Adaptive compilation is a technique in which IronPython: 1. Interprets and executes Python method calls up to /N/ times for a given method. If you're only going to execute a method a few times, it's typically faster to interpret the method instead of compiling and executing it 2. Compiles and executes the Python method call on the /N+1/ invocation of the method. Compilation of a Python method is a heavyweight operation, but we can reuse the result for subsequent invocations 3. Reuses the previously compiled method for new calls to the Python method. This operation is much faster than interpreting the method call as the method was already compiled in the previous step The reason for this change is that it provides a nice performance gain for Python code containing lots of functions/methods that only get called a few times. All this said, this feature is still undergoing active development and as a consequence some Python scripts may actually run slower with it turned on. For this reason, our old default mode of running Python scripts is still available by passing the -O or -D flags to ipy.exe. Any feedback on how this new feature affects your IronPython applications performance-wise would be greatly appreciated. There's also a few minor changes since IronPython 2.0.1 that are worth calling out here: . IronPython.msi now installs NGEN'ed binaries by default . IronPython.msi now offers a little more selection with respect to what you'd like to install. For example, Silverlight templates are optional . The default installation location of IronPython.msi no longer indicates whether the 2.6 release is an Alpha, Beta, or a patched release. Future IronPython 2.6 installations will replace previous 2.6 releases which will be uninstalled automatically . The -X:PreferComInteropAssembly flag has been removed. All COM interop is now done through normal COM dispatch You can download IronPython 2.6 Alpha 1 at: http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22982 The IronPython Team ------------------------------------------------------------------------ _______________________________________________ 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 -- nomadlife.org _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Adam Brand Managing Partner SilverKey Technologies Direct: +1-312-239-6722 Main: +1-312-951-7525 Skype: adamsilverkey Email: adamb at silverkeytech.com www.silverkeytech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From omgomgomg at f2s.com Sat Apr 18 13:05:44 2009 From: omgomgomg at f2s.com (theoobe) Date: Sat, 18 Apr 2009 04:05:44 -0700 (PDT) Subject: [IronPython] Is it possible to set a maximum loop size for scripts? Message-ID: <23084739.post@talk.nabble.com> I have a C# application with IronPython scripting. I wonder, is it possible to prevent users from creating infinite loops in their scripts? So for example, if a script is executed which contains a loop, and loop is infinate, would it be possible for my C# application to detect this, perhaps by having a maximum loop cycle count? Thus preventing my application from hanging... I've tried googling around on this subject but I've had no joy. Maybe what I'm asking for isn't possible? Thanks alot! -- View this message in context: http://www.nabble.com/Is-it-possible-to-set-a-maximum-loop-size-for-scripts--tp23084739p23084739.html Sent from the IronPython mailing list archive at Nabble.com. From anleewxs at gmail.com Sat Apr 18 14:36:29 2009 From: anleewxs at gmail.com (Alex News) Date: Sat, 18 Apr 2009 08:36:29 -0400 Subject: [IronPython] Is it possible to set a maximum loop size for scripts? In-Reply-To: <23084739.post@talk.nabble.com> References: <23084739.post@talk.nabble.com> Message-ID: <2c77c440904180536r145477abs8a6125157142d1d4@mail.gmail.com> In the general case this isn't possible: http://en.wikipedia.org/wiki/Halting_problem Perhaps some sort of timeout logic would work for you? I.e. kill the script if it is still running after some predetermined amount of time. I do not know if IronPython has any such functionality built in, but it should be easy enough to roll your own. On 4/18/09, theoobe wrote: > > I have a C# application with IronPython scripting. I wonder, is it possible > to prevent users from creating infinite loops in their scripts? > > So for example, if a script is executed which contains a loop, and loop is > infinate, would it be possible for my C# application to detect this, perhaps > by having a maximum loop cycle count? Thus preventing my application from > hanging... > > I've tried googling around on this subject but I've had no joy. Maybe what > I'm asking for isn't possible? > > Thanks alot! > > -- > View this message in context: http://www.nabble.com/Is-it-possible-to-set-a-maximum-loop-size-for-scripts--tp23084739p23084739.html > Sent from the IronPython mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From fuzzyman at voidspace.org.uk Sat Apr 18 14:40:28 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 18 Apr 2009 13:40:28 +0100 Subject: [IronPython] Is it possible to set a maximum loop size for scripts? In-Reply-To: <2c77c440904180536r145477abs8a6125157142d1d4@mail.gmail.com> References: <23084739.post@talk.nabble.com> <2c77c440904180536r145477abs8a6125157142d1d4@mail.gmail.com> Message-ID: <49E9CA3C.5090100@voidspace.org.uk> Alex News wrote: > In the general case this isn't possible: > http://en.wikipedia.org/wiki/Halting_problem > > Well it's not strictly a halting problem. The question isn't whether it will *ever* terminate but just is it taking too long. IronPython doesn't include this functionality built in but it would be *possible* (theoretically) to count loops. I don't think it is a very useful approach though - a very tight loop can execute thousands of times in a second. > Perhaps some sort of timeout logic would work for you? I.e. kill the > script if it is still running after some predetermined amount of time. > I do not know if IronPython has any such functionality built in, but > it should be easy enough to roll your own. > > I agree - spin the code up in its own thread and kill it if it doesn't end within a preset maximum time. Michael > On 4/18/09, theoobe wrote: > >> I have a C# application with IronPython scripting. I wonder, is it possible >> to prevent users from creating infinite loops in their scripts? >> >> So for example, if a script is executed which contains a loop, and loop is >> infinate, would it be possible for my C# application to detect this, perhaps >> by having a maximum loop cycle count? Thus preventing my application from >> hanging... >> >> I've tried googling around on this subject but I've had no joy. Maybe what >> I'm asking for isn't possible? >> >> Thanks alot! >> >> -- >> View this message in context: http://www.nabble.com/Is-it-possible-to-set-a-maximum-loop-size-for-scripts--tp23084739p23084739.html >> Sent from the IronPython mailing list archive at Nabble.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 > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From fuzzyman at voidspace.org.uk Sat Apr 18 15:21:28 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 18 Apr 2009 14:21:28 +0100 Subject: [IronPython] Failing to find overload match when object is None Message-ID: <49E9D3D8.3060205@voidspace.org.uk> Hello guys, I saw a message on Twitter yesterday: Finding IronPython mildly annoying, with errors like: "TypeError: Multiple targets could match: AddFile(str), AddFile(FileInfo)" Needless to say the problem was that he was passing in None - which could match any of the overloads that take reference types. This has bitten me before. Would it be possible to make the error message more helpful where a match can't be found because an object passed in is None. As this code path would only be exercised if an exception is about to be raised it shouldn't need to slow down the normal cases of overload resolution. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From dinov at microsoft.com Sat Apr 18 19:36:43 2009 From: dinov at microsoft.com (Dino Viehland) Date: Sat, 18 Apr 2009 10:36:43 -0700 Subject: [IronPython] Failing to find overload match when object is None In-Reply-To: <49E9D3D8.3060205@voidspace.org.uk> References: <49E9D3D8.3060205@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC235557270C5C42@NA-EXMSG-C102.redmond.corp.microsoft.com> Yeah, I saw that too :( I think we can definitely add a message for None so that this gets better. At the very least we can report all of the types of arguments that we received so the None is at least in your face. In general we want to improve all of our error messages as they're frequently not good or useful for complicated overloads. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Saturday, April 18, 2009 6:21 AM > To: Discussion of IronPython > Subject: [IronPython] Failing to find overload match when object is > None > > Hello guys, > > I saw a message on Twitter yesterday: > > Finding IronPython mildly annoying, with errors like: "TypeError: > Multiple targets could match: AddFile(str), AddFile(FileInfo)" > > Needless to say the problem was that he was passing in None - which > could match any of the overloads that take reference types. This has > bitten me before. Would it be possible to make the error message more > helpful where a match can't be found because an object passed in is > None. > > As this code path would only be exercised if an exception is about to > be > raised it shouldn't need to slow down the normal cases of overload > resolution. > > 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 fuzzyman at voidspace.org.uk Mon Apr 20 12:34:22 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 20 Apr 2009 11:34:22 +0100 Subject: [IronPython] Compiling with Pyc for Silverlight Message-ID: <49EC4FAE.5030904@voidspace.org.uk> Hello guys, I'd like to modify Pyc to work with Silverlight. I tried it with simple modules and it works straightforwardly - but I have a report that it doesn't work with packages. I'll try it - but if anyone has any idea of how to modify the bytecode generation to target the CoreCLR it would be appreciated. As far as I can tell from looking at the source it isn't adding any direct references to the desktop assemblies. Any clues as to what changes I should make? (Other than running from Silverlight and serializing the generated assemblies from memory to base64 which I would prefer to avoid...). Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From dinov at microsoft.com Mon Apr 20 17:18:30 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 20 Apr 2009 08:18:30 -0700 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <49EC4FAE.5030904@voidspace.org.uk> References: <49EC4FAE.5030904@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> In theory there's just 1 IL re-write that's required for this to work. And that should be replacing the references to mscorlib/IronPython to point at the Silverlight versions. There's no way to directly have the written binaries target Silverlight because Reflection Emit has no cross-compilation support :(. Do you know what's happening when trying to import packages? > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, April 20, 2009 3:34 AM > To: Discussion of IronPython > Subject: [IronPython] Compiling with Pyc for Silverlight > > Hello guys, > > I'd like to modify Pyc to work with Silverlight. I tried it with simple > modules and it works straightforwardly - but I have a report that it > doesn't work with packages. > > I'll try it - but if anyone has any idea of how to modify the bytecode > generation to target the CoreCLR it would be appreciated. As far as I > can tell from looking at the source it isn't adding any direct > references to the desktop assemblies. Any clues as to what changes I > should make? (Other than running from Silverlight and serializing the > generated assemblies from memory to base64 which I would prefer to > avoid...). > > 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 fuzzyman at voidspace.org.uk Mon Apr 20 17:22:54 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 20 Apr 2009 16:22:54 +0100 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49EC934E.5080800@voidspace.org.uk> Dino Viehland wrote: > In theory there's just 1 IL re-write that's required for this to work. And that should be replacing the references to mscorlib/IronPython to point at the Silverlight versions. There's no way to directly have the written binaries target Silverlight because Reflection Emit has no cross-compilation support :(. > So I need to rewrite the IL after Pyc has generated it. OK - if I need help with that I'll come back. > Do you know what's happening when trying to import packages? > I still need to try it myself. All the best, Michael > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Monday, April 20, 2009 3:34 AM >> To: Discussion of IronPython >> Subject: [IronPython] Compiling with Pyc for Silverlight >> >> Hello guys, >> >> I'd like to modify Pyc to work with Silverlight. I tried it with simple >> modules and it works straightforwardly - but I have a report that it >> doesn't work with packages. >> >> I'll try it - but if anyone has any idea of how to modify the bytecode >> generation to target the CoreCLR it would be appreciated. As far as I >> can tell from looking at the source it isn't adding any direct >> references to the desktop assemblies. Any clues as to what changes I >> should make? (Other than running from Silverlight and serializing the >> generated assemblies from memory to base64 which I would prefer to >> avoid...). >> >> 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 From fuzzyman at voidspace.org.uk Mon Apr 20 21:43:15 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 20 Apr 2009 20:43:15 +0100 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49ECD053.8030105@voidspace.org.uk> Dino Viehland wrote: > In theory there's just 1 IL re-write that's required for this to work. And that should be replacing the references to mscorlib/IronPython to point at the Silverlight versions. There's no way to directly have the written binaries target Silverlight because Reflection Emit has no cross-compilation support :(. > I need to rewrite references to the IronPython / DLR assemblies to use the Silverlight versions and the same for mscorlib. Any pointers as to how I should start? > Do you know what's happening when trying to import packages? > > SystemError at app.py in app.py, line 7 ? SystemError: Could not load type 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. ? Hide Michael >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Monday, April 20, 2009 3:34 AM >> To: Discussion of IronPython >> Subject: [IronPython] Compiling with Pyc for Silverlight >> >> Hello guys, >> >> I'd like to modify Pyc to work with Silverlight. I tried it with simple >> modules and it works straightforwardly - but I have a report that it >> doesn't work with packages. >> >> I'll try it - but if anyone has any idea of how to modify the bytecode >> generation to target the CoreCLR it would be appreciated. As far as I >> can tell from looking at the source it isn't adding any direct >> references to the desktop assemblies. Any clues as to what changes I >> should make? (Other than running from Silverlight and serializing the >> generated assemblies from memory to base64 which I would prefer to >> avoid...). >> >> 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 From dinov at microsoft.com Mon Apr 20 22:19:15 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 20 Apr 2009 13:19:15 -0700 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <49ECD053.8030105@voidspace.org.uk> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> An easy starting point would be to use ildasm + a Python script + ilasm. There's also CCI (just released on CodePlex last week) or Cecil which could also probably both be used for the task. I can only assume this exception is coming from having the assembly identities being different - but it's strange because it does seem to be looking in the 2.0.5.0 assembly, which is Silverlight, and the type is definitely in there. Hopefully re-writing the binaries will make this go away. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, April 20, 2009 12:43 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Compiling with Pyc for Silverlight > > Dino Viehland wrote: > > In theory there's just 1 IL re-write that's required for this to > work. And that should be replacing the references to > mscorlib/IronPython to point at the Silverlight versions. There's no > way to directly have the written binaries target Silverlight because > Reflection Emit has no cross-compilation support :(. > > > > I need to rewrite references to the IronPython / DLR assemblies to use > the Silverlight versions and the same for mscorlib. > > Any pointers as to how I should start? > > > Do you know what's happening when trying to import packages? > > > > > > > SystemError > at app.py in app.py, line 7 ? SystemError: Could not load type > 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly > 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, > PublicKeyToken=31bf3856ad364e35'. ? Hide > > Michael > > >> -----Original Message----- > >> From: users-bounces at lists.ironpython.com [mailto:users- > >> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >> Sent: Monday, April 20, 2009 3:34 AM > >> To: Discussion of IronPython > >> Subject: [IronPython] Compiling with Pyc for Silverlight > >> > >> Hello guys, > >> > >> I'd like to modify Pyc to work with Silverlight. I tried it with > simple > >> modules and it works straightforwardly - but I have a report that it > >> doesn't work with packages. > >> > >> I'll try it - but if anyone has any idea of how to modify the > bytecode > >> generation to target the CoreCLR it would be appreciated. As far as > I > >> can tell from looking at the source it isn't adding any direct > >> references to the desktop assemblies. Any clues as to what changes I > >> should make? (Other than running from Silverlight and serializing > the > >> generated assemblies from memory to base64 which I would prefer to > >> avoid...). > >> > >> 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 > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Mon Apr 20 22:24:08 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 20 Apr 2009 21:24:08 +0100 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49ECD9E8.2080705@voidspace.org.uk> Dino Viehland wrote: > An easy starting point would be to use ildasm + a Python script + ilasm. There's also CCI (just released on CodePlex last week) or Cecil which could also probably both be used for the task. > I'll start with ildasm. I looked at Cecil but it was a bit low level. I've also been looking into the CompileModules source code. It doesn't look impossible to get this actually working on Silverlight and serialize out rather than try to save to disk (ScriptCode and ScriptCode.SaveToAssembly are all public where a lot of the work is done). I'll try ildasm first. Michael > I can only assume this exception is coming from having the assembly identities being different - but it's strange because it does seem to be looking in the 2.0.5.0 assembly, which is Silverlight, and the type is definitely in there. Hopefully re-writing the binaries will make this go away. > > > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Monday, April 20, 2009 12:43 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >> >> Dino Viehland wrote: >> >>> In theory there's just 1 IL re-write that's required for this to >>> >> work. And that should be replacing the references to >> mscorlib/IronPython to point at the Silverlight versions. There's no >> way to directly have the written binaries target Silverlight because >> Reflection Emit has no cross-compilation support :(. >> >> I need to rewrite references to the IronPython / DLR assemblies to use >> the Silverlight versions and the same for mscorlib. >> >> Any pointers as to how I should start? >> >> >>> Do you know what's happening when trying to import packages? >>> >>> >>> >> SystemError >> at app.py in app.py, line 7 ? SystemError: Could not load type >> 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly >> 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, >> PublicKeyToken=31bf3856ad364e35'. ? Hide >> >> Michael >> >> >>>> -----Original Message----- >>>> From: users-bounces at lists.ironpython.com [mailto:users- >>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord >>>> Sent: Monday, April 20, 2009 3:34 AM >>>> To: Discussion of IronPython >>>> Subject: [IronPython] Compiling with Pyc for Silverlight >>>> >>>> Hello guys, >>>> >>>> I'd like to modify Pyc to work with Silverlight. I tried it with >>>> >> simple >> >>>> modules and it works straightforwardly - but I have a report that it >>>> doesn't work with packages. >>>> >>>> I'll try it - but if anyone has any idea of how to modify the >>>> >> bytecode >> >>>> generation to target the CoreCLR it would be appreciated. As far as >>>> >> I >> >>>> can tell from looking at the source it isn't adding any direct >>>> references to the desktop assemblies. Any clues as to what changes I >>>> should make? (Other than running from Silverlight and serializing >>>> >> the >> >>>> generated assemblies from memory to base64 which I would prefer to >>>> avoid...). >>>> >>>> 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 >> >> >> _______________________________________________ >> 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 From dinov at microsoft.com Mon Apr 20 22:30:55 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 20 Apr 2009 13:30:55 -0700 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <49ECD9E8.2080705@voidspace.org.uk> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> How do you serialize the Assembly object? If it's easy enough we could presumably add this to support Silverlight natively - I'd love to have pre-compiled support there. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, April 20, 2009 1:24 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Compiling with Pyc for Silverlight > > Dino Viehland wrote: > > An easy starting point would be to use ildasm + a Python script + > ilasm. There's also CCI (just released on CodePlex last week) or Cecil > which could also probably both be used for the task. > > > > I'll start with ildasm. I looked at Cecil but it was a bit low level. > I've also been looking into the CompileModules source code. It doesn't > look impossible to get this actually working on Silverlight and > serialize out rather than try to save to disk (ScriptCode and > ScriptCode.SaveToAssembly are all public where a lot of the work is > done). > > I'll try ildasm first. > > Michael > > I can only assume this exception is coming from having the assembly > identities being different - but it's strange because it does seem to > be looking in the 2.0.5.0 assembly, which is Silverlight, and the type > is definitely in there. Hopefully re-writing the binaries will make > this go away. > > > > > > > > > >> -----Original Message----- > >> From: users-bounces at lists.ironpython.com [mailto:users- > >> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >> Sent: Monday, April 20, 2009 12:43 PM > >> To: Discussion of IronPython > >> Subject: Re: [IronPython] Compiling with Pyc for Silverlight > >> > >> Dino Viehland wrote: > >> > >>> In theory there's just 1 IL re-write that's required for this to > >>> > >> work. And that should be replacing the references to > >> mscorlib/IronPython to point at the Silverlight versions. There's > no > >> way to directly have the written binaries target Silverlight because > >> Reflection Emit has no cross-compilation support :(. > >> > >> I need to rewrite references to the IronPython / DLR assemblies to > use > >> the Silverlight versions and the same for mscorlib. > >> > >> Any pointers as to how I should start? > >> > >> > >>> Do you know what's happening when trying to import packages? > >>> > >>> > >>> > >> SystemError > >> at app.py in app.py, line 7 ? SystemError: Could not load type > >> 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly > >> 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, > >> PublicKeyToken=31bf3856ad364e35'. ? Hide > >> > >> Michael > >> > >> > >>>> -----Original Message----- > >>>> From: users-bounces at lists.ironpython.com [mailto:users- > >>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >>>> Sent: Monday, April 20, 2009 3:34 AM > >>>> To: Discussion of IronPython > >>>> Subject: [IronPython] Compiling with Pyc for Silverlight > >>>> > >>>> Hello guys, > >>>> > >>>> I'd like to modify Pyc to work with Silverlight. I tried it with > >>>> > >> simple > >> > >>>> modules and it works straightforwardly - but I have a report that > it > >>>> doesn't work with packages. > >>>> > >>>> I'll try it - but if anyone has any idea of how to modify the > >>>> > >> bytecode > >> > >>>> generation to target the CoreCLR it would be appreciated. As far > as > >>>> > >> I > >> > >>>> can tell from looking at the source it isn't adding any direct > >>>> references to the desktop assemblies. Any clues as to what changes > I > >>>> should make? (Other than running from Silverlight and serializing > >>>> > >> the > >> > >>>> generated assemblies from memory to base64 which I would prefer to > >>>> avoid...). > >>>> > >>>> 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 > >> > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Mon Apr 20 22:50:55 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 20 Apr 2009 21:50:55 +0100 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49ECE02F.60109@voidspace.org.uk> Dino Viehland wrote: > How do you serialize the Assembly object? If it's easy enough we could presumably > add this to support Silverlight natively - I'd love to have pre-compiled support > there. > > Well the Assembly type is marked with the SerializableAttribute so I was presuming to try something naive like a BinaryFormatter. This certainly doesn't blow up when you try it. Hmm... how to go from a binary format to a real assembly on disk is another question. Saving it as a file that can be deserialized back into an assembly object seems plausible but this isn't quite the same. I guess a full IL writer would be needed - which means back to Cecil and the like and seeing if parts of them could be run on Silverlight. *sigh* I'll look at ildasm... Michael >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Monday, April 20, 2009 1:24 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >> >> Dino Viehland wrote: >> >>> An easy starting point would be to use ildasm + a Python script + >>> >> ilasm. There's also CCI (just released on CodePlex last week) or Cecil >> which could also probably both be used for the task. >> >> I'll start with ildasm. I looked at Cecil but it was a bit low level. >> I've also been looking into the CompileModules source code. It doesn't >> look impossible to get this actually working on Silverlight and >> serialize out rather than try to save to disk (ScriptCode and >> ScriptCode.SaveToAssembly are all public where a lot of the work is >> done). >> >> I'll try ildasm first. >> >> Michael >> >>> I can only assume this exception is coming from having the assembly >>> >> identities being different - but it's strange because it does seem to >> be looking in the 2.0.5.0 assembly, which is Silverlight, and the type >> is definitely in there. Hopefully re-writing the binaries will make >> this go away. >> >>> >>> >>> >>>> -----Original Message----- >>>> From: users-bounces at lists.ironpython.com [mailto:users- >>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord >>>> Sent: Monday, April 20, 2009 12:43 PM >>>> To: Discussion of IronPython >>>> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >>>> >>>> Dino Viehland wrote: >>>> >>>> >>>>> In theory there's just 1 IL re-write that's required for this to >>>>> >>>>> >>>> work. And that should be replacing the references to >>>> mscorlib/IronPython to point at the Silverlight versions. There's >>>> >> no >> >>>> way to directly have the written binaries target Silverlight because >>>> Reflection Emit has no cross-compilation support :(. >>>> >>>> I need to rewrite references to the IronPython / DLR assemblies to >>>> >> use >> >>>> the Silverlight versions and the same for mscorlib. >>>> >>>> Any pointers as to how I should start? >>>> >>>> >>>> >>>>> Do you know what's happening when trying to import packages? >>>>> >>>>> >>>>> >>>>> >>>> SystemError >>>> at app.py in app.py, line 7 ? SystemError: Could not load type >>>> 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly >>>> 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, >>>> PublicKeyToken=31bf3856ad364e35'. ? Hide >>>> >>>> Michael >>>> >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: users-bounces at lists.ironpython.com [mailto:users- >>>>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord >>>>>> Sent: Monday, April 20, 2009 3:34 AM >>>>>> To: Discussion of IronPython >>>>>> Subject: [IronPython] Compiling with Pyc for Silverlight >>>>>> >>>>>> Hello guys, >>>>>> >>>>>> I'd like to modify Pyc to work with Silverlight. I tried it with >>>>>> >>>>>> >>>> simple >>>> >>>> >>>>>> modules and it works straightforwardly - but I have a report that >>>>>> >> it >> >>>>>> doesn't work with packages. >>>>>> >>>>>> I'll try it - but if anyone has any idea of how to modify the >>>>>> >>>>>> >>>> bytecode >>>> >>>> >>>>>> generation to target the CoreCLR it would be appreciated. As far >>>>>> >> as >> >>>> I >>>> >>>> >>>>>> can tell from looking at the source it isn't adding any direct >>>>>> references to the desktop assemblies. Any clues as to what changes >>>>>> >> I >> >>>>>> should make? (Other than running from Silverlight and serializing >>>>>> >>>>>> >>>> the >>>> >>>> >>>>>> generated assemblies from memory to base64 which I would prefer to >>>>>> avoid...). >>>>>> >>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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 From Marty.Nelson at symyx.com Mon Apr 20 23:05:59 2009 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Mon, 20 Apr 2009 14:05:59 -0700 Subject: [IronPython] assembly versioning in scripts Message-ID: <515335F32AA04440B3DE6FEA1993E9AD042626AA@srv-be-101.Symyx-IC.symyx.com> One of our developers asked me this question today, I don't have an answer, so any help would be appreciated: We came across an issue while testing the NuGenesis extension related to assembly versioning in scripts. The extension has a custom assembly, which is called by script: a = AssemblyCache.GetAssembly("Symyx.SDMS.NuGenesis.SN6, Version=1.2.3.4, Culture=neutral, PublicKeyToken=e5750cf9faec8249") clr.AddReference(a) from Symyx.SDMS.NuGenesis.SN6 import * We are adding reference to a version-specific assembly, and then we import from a namespace inside the assembly. We have two document templates - each of them calls a different version of the extension assembly from the script. After opening both templates within the same Notebook session, both versions of the assembly are in memory, and at this point the import call seems to import the version that was loaded the last time (as opposed to the one we reference by version in the script). Is there a way around this? ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb at nurv.fr Mon Apr 20 23:34:22 2009 From: jb at nurv.fr (Jb Evain) Date: Mon, 20 Apr 2009 23:34:22 +0200 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <49ECE02F.60109@voidspace.org.uk> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECE02F.60109@voidspace.org.uk> Message-ID: <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> Hey Michael, On 4/20/09, Michael Foord wrote: > I guess a full IL writer would be needed - which means back to Cecil and > the like and seeing if parts of them could be run on Silverlight. *sigh* You just want to change the references to an assembly from the desktop version to the SL version? With Cecil it's like: var assembly = AssemblyFactory.GetAssembly (file); foreach (var reference in assembly.MainModule.AssemblyReferences) { if (!IsTargetAssembly (reference)) continue; reference.Version = new Version (2, 0, 5, 0); } AssemblyFactory.SaveAssembly (assembly, file); Now it doesn't guarantee that the resulting assembly is coherent, visibility wise, as you may have used methods that are not visible or not existent in SL. -- Jb Evain From fuzzyman at voidspace.org.uk Mon Apr 20 23:51:36 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 20 Apr 2009 22:51:36 +0100 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECE02F.60109@voidspace.org.uk> <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> Message-ID: <49ECEE68.8030702@voidspace.org.uk> Jb Evain wrote: > Hey Michael, > > On 4/20/09, Michael Foord wrote: > >> I guess a full IL writer would be needed - which means back to Cecil and >> the like and seeing if parts of them could be run on Silverlight. *sigh* >> > > You just want to change the references to an assembly from the desktop > version to the SL version? With Cecil it's like: > > var assembly = AssemblyFactory.GetAssembly (file); > foreach (var reference in assembly.MainModule.AssemblyReferences) { > if (!IsTargetAssembly (reference)) > continue; > > reference.Version = new Version (2, 0, 5, 0); > } > AssemblyFactory.SaveAssembly (assembly, file); > > Now it doesn't guarantee that the resulting assembly is coherent, > visibility wise, as you may have used methods that are not visible or > not existent in SL. > > Thanks for that - if it would work it would be really useful, however... I think I've done the equivalent of this using ildasm / ilasm. I've disassembled the assembly to IL, then replaced the references with the references to Silverlight assemblies and re-assembled. The resulting assembly throws exactly the same error - which makes me think that the assemblies compiled by Pyc are using things that aren't available in Silverlight. *However* - Microsoft.Runtime.CompilerServices.StrongBox does exist in Silverlight. I think I'll try the whole process again just to see. My guess is that rewriting would require an intimate knowledge of the differences between the CoreCLR and standard .NET. I can't import it in a Silverlight application though (the following code does work on the desktop version of IronPython): import clr clr.AddReference('Microsoft.Scripting') clr.AddReference('Microsoft.Scripting.Core') from Microsoft.Runtime.CompilerServices import StrongBox ImportError: No module named Runtime Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From fuzzyman at voidspace.org.uk Tue Apr 21 00:06:58 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 20 Apr 2009 23:06:58 +0100 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <49ECEE68.8030702@voidspace.org.uk> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECE02F.60109@voidspace.org.uk> <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> <49ECEE68.8030702@voidspace.org.uk> Message-ID: <49ECF202.4080109@voidspace.org.uk> Michael Foord wrote: > Jb Evain wrote: >> Hey Michael, >> >> On 4/20/09, Michael Foord wrote: >> >>> I guess a full IL writer would be needed - which means back to >>> Cecil and >>> the like and seeing if parts of them could be run on Silverlight. >>> *sigh* >>> >> >> You just want to change the references to an assembly from the desktop >> version to the SL version? With Cecil it's like: >> >> var assembly = AssemblyFactory.GetAssembly (file); >> foreach (var reference in assembly.MainModule.AssemblyReferences) { >> if (!IsTargetAssembly (reference)) >> continue; >> >> reference.Version = new Version (2, 0, 5, 0); >> } >> AssemblyFactory.SaveAssembly (assembly, file); >> >> Now it doesn't guarantee that the resulting assembly is coherent, >> visibility wise, as you may have used methods that are not visible or >> not existent in SL. >> >> > Thanks for that - if it would work it would be really useful, however... > > I think I've done the equivalent of this using ildasm / ilasm. I've > disassembled the assembly to IL, then replaced the references with the > references to Silverlight assemblies and re-assembled. > > The resulting assembly throws exactly the same error - which makes me > think that the assemblies compiled by Pyc are using things that aren't > available in Silverlight. *However* - > Microsoft.Runtime.CompilerServices.StrongBox does exist in > Silverlight. I think I'll try the whole process again just to see. My > guess is that rewriting would require an intimate knowledge of the > differences between the CoreCLR and standard .NET. > No - I've rerun the whole process from compiling with Pyc through to replacing the references in the il and reassembling. Same error. Shame. SystemError: Could not load type 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.app.py Michael Foord > I can't import it in a Silverlight application though (the following > code does work on the desktop version of IronPython): > > import clr > clr.AddReference('Microsoft.Scripting') > clr.AddReference('Microsoft.Scripting.Core') > from Microsoft.Runtime.CompilerServices import StrongBox > > ImportError: No module named Runtime > > Michael > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From fuzzyman at voidspace.org.uk Tue Apr 21 00:12:11 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 20 Apr 2009 23:12:11 +0100 Subject: [IronPython] assembly versioning in scripts In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD042626AA@srv-be-101.Symyx-IC.symyx.com> References: <515335F32AA04440B3DE6FEA1993E9AD042626AA@srv-be-101.Symyx-IC.symyx.com> Message-ID: <49ECF33B.9080603@voidspace.org.uk> Marty Nelson wrote: > > One of our developers asked me this question today, I don?t have an > answer, so any help would be appreciated: > > We came across an issue while testing the NuGenesis extension related > to assembly versioning in scripts. The extension has a custom > assembly, which is called by script: > > a = AssemblyCache.GetAssembly("Symyx.SDMS.NuGenesis.SN6, > Version=1.2.3.4, Culture=neutral, PublicKeyToken=e5750cf9faec8249") > > clr.AddReference(a) > > from Symyx.SDMS.NuGenesis.SN6 import * > > We are adding reference to a version-specific assembly, and then we > import from a namespace inside the assembly. > > We have two document templates - each of them calls a different > version of the extension assembly from the script. After opening both > templates within the same Notebook session, both versions of the > assembly are in memory, and at this point the *import* call seems to > import the version that was loaded the last time (as opposed to the > one we reference by version in the script). Is there a way around this? > Instead of using imports could you fetch the classes you need (etc) from the assembly objects? Namespaces are normally available as attributes on the assembly objects from within IronPython. After doing clr.AddReference the assembly just loaded is usually the last in clr.References - alternatively you can load them directly with Assembly.Load. HTH Michael > ======= > Notice: This e-mail message, together with any attachments, contains > information of Symyx Technologies, Inc. or any of its affiliates or > subsidiaries that may be confidential, proprietary, copyrighted, > privileged and/or protected work product, and is meant solely for > the intended recipient. If you are not the intended recipient, and > have received this message in error, please contact the sender > immediately, permanently delete the original and any copies of this > email and any attachments thereto. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 curt at hagenlocher.org Tue Apr 21 00:13:29 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 20 Apr 2009 15:13:29 -0700 Subject: [IronPython] assembly versioning in scripts In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD042626AA@srv-be-101.Symyx-IC.symyx.com> References: <515335F32AA04440B3DE6FEA1993E9AD042626AA@srv-be-101.Symyx-IC.symyx.com> Message-ID: If "a" is an Assembly object, you should just be able to dot into it to get Types. So instead of clr.AddReference(a) from A.B.C.D import E you'd say E = a.A.B.C.D.E The Python import mechanism is global and not really consistent with having multiple "things" with the same name. On Mon, Apr 20, 2009 at 2:05 PM, Marty Nelson wrote: > One of our developers asked me this question today, I don?t have an > answer, so any help would be appreciated: > > > > We came across an issue while testing the NuGenesis extension related to > assembly versioning in scripts. The extension has a custom assembly, which > is called by script: > > > > a = > AssemblyCache.GetAssembly("Symyx.SDMS.NuGenesis.SN6, Version=1.2.3.4, > Culture=neutral, PublicKeyToken=e5750cf9faec8249") > > clr.AddReference(a) > > from Symyx.SDMS.NuGenesis.SN6 import * > > > > We are adding reference to a version-specific assembly, and then we import > from a namespace inside the assembly. > > > > We have two document templates - each of them calls a different version of > the extension assembly from the script. After opening both templates within > the same Notebook session, both versions of the assembly are in memory, and > at this point the *import* call seems to import the version that was > loaded the last time (as opposed to the one we reference by version in the > script). Is there a way around this? > > > > > > > ======= > Notice: This e-mail message, together with any attachments, contains > information of Symyx Technologies, Inc. or any of its affiliates or > subsidiaries that may be confidential, proprietary, copyrighted, > privileged and/or protected work product, and is meant solely for > the intended recipient. If you are not the intended recipient, and > have received this message in error, please contact the sender > immediately, permanently delete the original and any copies of this > email and any attachments thereto. > > _______________________________________________ > 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 Tue Apr 21 02:56:58 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 20 Apr 2009 17:56:58 -0700 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <49ECF202.4080109@voidspace.org.uk> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECE02F.60109@voidspace.org.uk> <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> <49ECEE68.8030702@voidspace.org.uk> <49ECF202.4080109@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC235557270C60D0@NA-EXMSG-C102.redmond.corp.microsoft.com> You're compiling to a DLL and then trying to import (vs compiling to an EXE)? > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, April 20, 2009 3:07 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Compiling with Pyc for Silverlight > > Michael Foord wrote: > > Jb Evain wrote: > >> Hey Michael, > >> > >> On 4/20/09, Michael Foord wrote: > >> > >>> I guess a full IL writer would be needed - which means back to > >>> Cecil and > >>> the like and seeing if parts of them could be run on Silverlight. > >>> *sigh* > >>> > >> > >> You just want to change the references to an assembly from the > desktop > >> version to the SL version? With Cecil it's like: > >> > >> var assembly = AssemblyFactory.GetAssembly (file); > >> foreach (var reference in assembly.MainModule.AssemblyReferences) { > >> if (!IsTargetAssembly (reference)) > >> continue; > >> > >> reference.Version = new Version (2, 0, 5, 0); > >> } > >> AssemblyFactory.SaveAssembly (assembly, file); > >> > >> Now it doesn't guarantee that the resulting assembly is coherent, > >> visibility wise, as you may have used methods that are not visible > or > >> not existent in SL. > >> > >> > > Thanks for that - if it would work it would be really useful, > however... > > > > I think I've done the equivalent of this using ildasm / ilasm. I've > > disassembled the assembly to IL, then replaced the references with > the > > references to Silverlight assemblies and re-assembled. > > > > The resulting assembly throws exactly the same error - which makes me > > think that the assemblies compiled by Pyc are using things that > aren't > > available in Silverlight. *However* - > > Microsoft.Runtime.CompilerServices.StrongBox does exist in > > Silverlight. I think I'll try the whole process again just to see. My > > guess is that rewriting would require an intimate knowledge of the > > differences between the CoreCLR and standard .NET. > > > > No - I've rerun the whole process from compiling with Pyc through to > replacing the references in the il and reassembling. Same error. Shame. > > SystemError: Could not load type > 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly > 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, > PublicKeyToken=31bf3856ad364e35'.app.py > > Michael Foord > > > I can't import it in a Silverlight application though (the following > > code does work on the desktop version of IronPython): > > > > import clr > > clr.AddReference('Microsoft.Scripting') > > clr.AddReference('Microsoft.Scripting.Core') > > from Microsoft.Runtime.CompilerServices import StrongBox > > > > ImportError: No module named Runtime > > > > 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 fuzzyman at voidspace.org.uk Tue Apr 21 11:40:57 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 21 Apr 2009 10:40:57 +0100 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <350E7D38B6D819428718949920EC235557270C60D0@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECE02F.60109@voidspace.org.uk> <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> <49ECEE68.8030702@voidspace.org.uk> <49ECF202.4080109@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C60D0@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49ED94A9.8070602@voidspace.org.uk> Dino Viehland wrote: > You're compiling to a DLL and then trying to import (vs compiling to an EXE)? > > Yes - it's support packages we're trying to compile. I would have thought that compiling an exe for Silverlight was a lost cause... :-) There are two motivations, mainly speeding up import time but also source code obfuscation. If the assembly is genuinely serializable then we may at least achieve the second, so long as it doesn't make import time worse. Michael >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Monday, April 20, 2009 3:07 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >> >> Michael Foord wrote: >> >>> Jb Evain wrote: >>> >>>> Hey Michael, >>>> >>>> On 4/20/09, Michael Foord wrote: >>>> >>>> >>>>> I guess a full IL writer would be needed - which means back to >>>>> Cecil and >>>>> the like and seeing if parts of them could be run on Silverlight. >>>>> *sigh* >>>>> >>>>> >>>> You just want to change the references to an assembly from the >>>> >> desktop >> >>>> version to the SL version? With Cecil it's like: >>>> >>>> var assembly = AssemblyFactory.GetAssembly (file); >>>> foreach (var reference in assembly.MainModule.AssemblyReferences) { >>>> if (!IsTargetAssembly (reference)) >>>> continue; >>>> >>>> reference.Version = new Version (2, 0, 5, 0); >>>> } >>>> AssemblyFactory.SaveAssembly (assembly, file); >>>> >>>> Now it doesn't guarantee that the resulting assembly is coherent, >>>> visibility wise, as you may have used methods that are not visible >>>> >> or >> >>>> not existent in SL. >>>> >>>> >>>> >>> Thanks for that - if it would work it would be really useful, >>> >> however... >> >>> I think I've done the equivalent of this using ildasm / ilasm. I've >>> disassembled the assembly to IL, then replaced the references with >>> >> the >> >>> references to Silverlight assemblies and re-assembled. >>> >>> The resulting assembly throws exactly the same error - which makes me >>> think that the assemblies compiled by Pyc are using things that >>> >> aren't >> >>> available in Silverlight. *However* - >>> Microsoft.Runtime.CompilerServices.StrongBox does exist in >>> Silverlight. I think I'll try the whole process again just to see. My >>> guess is that rewriting would require an intimate knowledge of the >>> differences between the CoreCLR and standard .NET. >>> >>> >> No - I've rerun the whole process from compiling with Pyc through to >> replacing the references in the il and reassembling. Same error. Shame. >> >> SystemError: Could not load type >> 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly >> 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, >> PublicKeyToken=31bf3856ad364e35'.app.py >> >> Michael Foord >> >> >>> I can't import it in a Silverlight application though (the following >>> code does work on the desktop version of IronPython): >>> >>> import clr >>> clr.AddReference('Microsoft.Scripting') >>> clr.AddReference('Microsoft.Scripting.Core') >>> from Microsoft.Runtime.CompilerServices import StrongBox >>> >>> ImportError: No module named Runtime >>> >>> 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/ From Jimmy.Schementi at microsoft.com Tue Apr 21 22:24:27 2009 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Tue, 21 Apr 2009 20:24:27 +0000 Subject: [IronPython] Is it possible to set a maximum loop size for scripts? In-Reply-To: <23084739.post@talk.nabble.com> References: <23084739.post@talk.nabble.com> Message-ID: > I have a C# application with IronPython scripting. I wonder, is it > possible to prevent users from creating infinite loops in their > scripts? > > So for example, if a script is executed which contains a loop, and loop > is infinite, would it be possible for my C# application to detect this, > perhaps by having a maximum loop cycle count? Thus preventing my > application from hanging... > > I've tried googling around on this subject but I've had no joy. Maybe > what I'm asking for isn't possible? There is no general solution: http://en.wikipedia.org/wiki/Halting_problem But you can stop your app from hanging by running scripts on another thread. You can also stop the thread after a certain amount of time, thus accomplishing a similar thing as a cycle count. However, again, there is no general solution. From dinov at microsoft.com Wed Apr 22 00:38:55 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 21 Apr 2009 15:38:55 -0700 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <49ED94A9.8070602@voidspace.org.uk> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECE02F.60109@voidspace.org.uk> <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> <49ECEE68.8030702@voidspace.org.uk> <49ECF202.4080109@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C60D0@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ED94A9.8070602@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC235557270C64F8@NA-EXMSG-C102.redmond.corp.microsoft.com> Do you have a simple repro XAP you can send me and I'll take a look? I'm not entirely sure I'll know what's going on as CoreCLR isn't the CLR I'm used to debugging but it's not that different :) > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Tuesday, April 21, 2009 2:41 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Compiling with Pyc for Silverlight > > Dino Viehland wrote: > > You're compiling to a DLL and then trying to import (vs compiling to > an EXE)? > > > > > > Yes - it's support packages we're trying to compile. I would have > thought that compiling an exe for Silverlight was a lost cause... :-) > > There are two motivations, mainly speeding up import time but also > source code obfuscation. If the assembly is genuinely serializable then > we may at least achieve the second, so long as it doesn't make import > time worse. > > Michael > > >> -----Original Message----- > >> From: users-bounces at lists.ironpython.com [mailto:users- > >> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >> Sent: Monday, April 20, 2009 3:07 PM > >> To: Discussion of IronPython > >> Subject: Re: [IronPython] Compiling with Pyc for Silverlight > >> > >> Michael Foord wrote: > >> > >>> Jb Evain wrote: > >>> > >>>> Hey Michael, > >>>> > >>>> On 4/20/09, Michael Foord wrote: > >>>> > >>>> > >>>>> I guess a full IL writer would be needed - which means back to > >>>>> Cecil and > >>>>> the like and seeing if parts of them could be run on Silverlight. > >>>>> *sigh* > >>>>> > >>>>> > >>>> You just want to change the references to an assembly from the > >>>> > >> desktop > >> > >>>> version to the SL version? With Cecil it's like: > >>>> > >>>> var assembly = AssemblyFactory.GetAssembly (file); > >>>> foreach (var reference in assembly.MainModule.AssemblyReferences) > { > >>>> if (!IsTargetAssembly (reference)) > >>>> continue; > >>>> > >>>> reference.Version = new Version (2, 0, 5, 0); > >>>> } > >>>> AssemblyFactory.SaveAssembly (assembly, file); > >>>> > >>>> Now it doesn't guarantee that the resulting assembly is coherent, > >>>> visibility wise, as you may have used methods that are not visible > >>>> > >> or > >> > >>>> not existent in SL. > >>>> > >>>> > >>>> > >>> Thanks for that - if it would work it would be really useful, > >>> > >> however... > >> > >>> I think I've done the equivalent of this using ildasm / ilasm. I've > >>> disassembled the assembly to IL, then replaced the references with > >>> > >> the > >> > >>> references to Silverlight assemblies and re-assembled. > >>> > >>> The resulting assembly throws exactly the same error - which makes > me > >>> think that the assemblies compiled by Pyc are using things that > >>> > >> aren't > >> > >>> available in Silverlight. *However* - > >>> Microsoft.Runtime.CompilerServices.StrongBox does exist in > >>> Silverlight. I think I'll try the whole process again just to see. > My > >>> guess is that rewriting would require an intimate knowledge of the > >>> differences between the CoreCLR and standard .NET. > >>> > >>> > >> No - I've rerun the whole process from compiling with Pyc through to > >> replacing the references in the il and reassembling. Same error. > Shame. > >> > >> SystemError: Could not load type > >> 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly > >> 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, > >> PublicKeyToken=31bf3856ad364e35'.app.py > >> > >> Michael Foord > >> > >> > >>> I can't import it in a Silverlight application though (the > following > >>> code does work on the desktop version of IronPython): > >>> > >>> import clr > >>> clr.AddReference('Microsoft.Scripting') > >>> clr.AddReference('Microsoft.Scripting.Core') > >>> from Microsoft.Runtime.CompilerServices import StrongBox > >>> > >>> ImportError: No module named Runtime > >>> > >>> 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/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Wed Apr 22 01:01:41 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 22 Apr 2009 00:01:41 +0100 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <350E7D38B6D819428718949920EC235557270C64F8@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECE02F.60109@voidspace.org.uk> <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> <49ECEE68.8030702@voidspace.org.uk> <49ECF202.4080109@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C60D0@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ED94A9.8070602@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C64F8@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49EE5055.2010605@voidspace.org.uk> Dino Viehland wrote: > Do you have a simple repro XAP you can send me and I'll take a look? > > I'm not entirely sure I'll know what's going on as CoreCLR isn't the > CLR I'm used to debugging but it's not that different :) > > Attached is a xap file. It has a very simple package compiled with Pyc - and importing it throws the same error. Michael >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Tuesday, April 21, 2009 2:41 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >> >> Dino Viehland wrote: >> >>> You're compiling to a DLL and then trying to import (vs compiling to >>> >> an EXE)? >> >>> >> Yes - it's support packages we're trying to compile. I would have >> thought that compiling an exe for Silverlight was a lost cause... :-) >> >> There are two motivations, mainly speeding up import time but also >> source code obfuscation. If the assembly is genuinely serializable then >> we may at least achieve the second, so long as it doesn't make import >> time worse. >> >> Michael >> >> >>>> -----Original Message----- >>>> From: users-bounces at lists.ironpython.com [mailto:users- >>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord >>>> Sent: Monday, April 20, 2009 3:07 PM >>>> To: Discussion of IronPython >>>> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >>>> >>>> Michael Foord wrote: >>>> >>>> >>>>> Jb Evain wrote: >>>>> >>>>> >>>>>> Hey Michael, >>>>>> >>>>>> On 4/20/09, Michael Foord wrote: >>>>>> >>>>>> >>>>>> >>>>>>> I guess a full IL writer would be needed - which means back to >>>>>>> Cecil and >>>>>>> the like and seeing if parts of them could be run on Silverlight. >>>>>>> *sigh* >>>>>>> >>>>>>> >>>>>>> >>>>>> You just want to change the references to an assembly from the >>>>>> >>>>>> >>>> desktop >>>> >>>> >>>>>> version to the SL version? With Cecil it's like: >>>>>> >>>>>> var assembly = AssemblyFactory.GetAssembly (file); >>>>>> foreach (var reference in assembly.MainModule.AssemblyReferences) >>>>>> >> { >> >>>>>> if (!IsTargetAssembly (reference)) >>>>>> continue; >>>>>> >>>>>> reference.Version = new Version (2, 0, 5, 0); >>>>>> } >>>>>> AssemblyFactory.SaveAssembly (assembly, file); >>>>>> >>>>>> Now it doesn't guarantee that the resulting assembly is coherent, >>>>>> visibility wise, as you may have used methods that are not visible >>>>>> >>>>>> >>>> or >>>> >>>> >>>>>> not existent in SL. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Thanks for that - if it would work it would be really useful, >>>>> >>>>> >>>> however... >>>> >>>> >>>>> I think I've done the equivalent of this using ildasm / ilasm. I've >>>>> disassembled the assembly to IL, then replaced the references with >>>>> >>>>> >>>> the >>>> >>>> >>>>> references to Silverlight assemblies and re-assembled. >>>>> >>>>> The resulting assembly throws exactly the same error - which makes >>>>> >> me >> >>>>> think that the assemblies compiled by Pyc are using things that >>>>> >>>>> >>>> aren't >>>> >>>> >>>>> available in Silverlight. *However* - >>>>> Microsoft.Runtime.CompilerServices.StrongBox does exist in >>>>> Silverlight. I think I'll try the whole process again just to see. >>>>> >> My >> >>>>> guess is that rewriting would require an intimate knowledge of the >>>>> differences between the CoreCLR and standard .NET. >>>>> >>>>> >>>>> >>>> No - I've rerun the whole process from compiling with Pyc through to >>>> replacing the references in the il and reassembling. Same error. >>>> >> Shame. >> >>>> SystemError: Could not load type >>>> 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly >>>> 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, >>>> PublicKeyToken=31bf3856ad364e35'.app.py >>>> >>>> Michael Foord >>>> >>>> >>>> >>>>> I can't import it in a Silverlight application though (the >>>>> >> following >> >>>>> code does work on the desktop version of IronPython): >>>>> >>>>> import clr >>>>> clr.AddReference('Microsoft.Scripting') >>>>> clr.AddReference('Microsoft.Scripting.Core') >>>>> from Microsoft.Runtime.CompilerServices import StrongBox >>>>> >>>>> ImportError: No module named Runtime >>>>> >>>>> 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/ >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: app.xap Type: application/octet-stream Size: 4987 bytes Desc: not available URL: From dinov at microsoft.com Wed Apr 22 01:21:28 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 21 Apr 2009 16:21:28 -0700 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <49EE5055.2010605@voidspace.org.uk> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECE02F.60109@voidspace.org.uk> <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> <49ECEE68.8030702@voidspace.org.uk> <49ECF202.4080109@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C60D0@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ED94A9.8070602@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C64F8@NA-EXMSG-C102.redmond.corp.microsoft.com> <49EE5055.2010605@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC235557270C6537@NA-EXMSG-C102.redmond.corp.microsoft.com> For some reason the re-write didn't work. After the re-write the new binary in ildasm should have a manifest that looks like: .assembly extern mscorlib { .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) .ver 2:0:5:0 } .assembly extern Microsoft.Scripting { .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) .ver 0:9:5:0 } .assembly extern IronPython { .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) .ver 2:0:5:0 } .assembly extern Microsoft.Scripting.Core { .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) .ver 0:9:5:0 } Where the key part is the 5's in all of the version strings. I did: ildasm froob.dll /out:froob.txt [updated version numbers] ilasm /DLL froob.txt /resource:froob.res /out:froob2.dll and it seems to work. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Tuesday, April 21, 2009 4:02 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Compiling with Pyc for Silverlight > > Dino Viehland wrote: > > Do you have a simple repro XAP you can send me and I'll take a look? > > > > I'm not entirely sure I'll know what's going on as CoreCLR isn't the > > CLR I'm used to debugging but it's not that different :) > > > > > Attached is a xap file. It has a very simple package compiled with Pyc > - and importing it throws the same error. > > Michael > > >> -----Original Message----- > >> From: users-bounces at lists.ironpython.com [mailto:users- > >> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >> Sent: Tuesday, April 21, 2009 2:41 AM > >> To: Discussion of IronPython > >> Subject: Re: [IronPython] Compiling with Pyc for Silverlight > >> > >> Dino Viehland wrote: > >> > >>> You're compiling to a DLL and then trying to import (vs compiling > to > >>> > >> an EXE)? > >> > >>> > >> Yes - it's support packages we're trying to compile. I would have > >> thought that compiling an exe for Silverlight was a lost cause... :- > ) > >> > >> There are two motivations, mainly speeding up import time but also > >> source code obfuscation. If the assembly is genuinely serializable > >> then we may at least achieve the second, so long as it doesn't make > >> import time worse. > >> > >> Michael > >> > >> > >>>> -----Original Message----- > >>>> From: users-bounces at lists.ironpython.com [mailto:users- > >>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >>>> Sent: Monday, April 20, 2009 3:07 PM > >>>> To: Discussion of IronPython > >>>> Subject: Re: [IronPython] Compiling with Pyc for Silverlight > >>>> > >>>> Michael Foord wrote: > >>>> > >>>> > >>>>> Jb Evain wrote: > >>>>> > >>>>> > >>>>>> Hey Michael, > >>>>>> > >>>>>> On 4/20/09, Michael Foord wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> I guess a full IL writer would be needed - which means back to > >>>>>>> Cecil and the like and seeing if parts of them could be run on > >>>>>>> Silverlight. > >>>>>>> *sigh* > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> You just want to change the references to an assembly from the > >>>>>> > >>>>>> > >>>> desktop > >>>> > >>>> > >>>>>> version to the SL version? With Cecil it's like: > >>>>>> > >>>>>> var assembly = AssemblyFactory.GetAssembly (file); foreach (var > >>>>>> reference in assembly.MainModule.AssemblyReferences) > >>>>>> > >> { > >> > >>>>>> if (!IsTargetAssembly (reference)) > >>>>>> continue; > >>>>>> > >>>>>> reference.Version = new Version (2, 0, 5, 0); } > >>>>>> AssemblyFactory.SaveAssembly (assembly, file); > >>>>>> > >>>>>> Now it doesn't guarantee that the resulting assembly is > coherent, > >>>>>> visibility wise, as you may have used methods that are not > >>>>>> visible > >>>>>> > >>>>>> > >>>> or > >>>> > >>>> > >>>>>> not existent in SL. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> Thanks for that - if it would work it would be really useful, > >>>>> > >>>>> > >>>> however... > >>>> > >>>> > >>>>> I think I've done the equivalent of this using ildasm / ilasm. > >>>>> I've disassembled the assembly to IL, then replaced the > references > >>>>> with > >>>>> > >>>>> > >>>> the > >>>> > >>>> > >>>>> references to Silverlight assemblies and re-assembled. > >>>>> > >>>>> The resulting assembly throws exactly the same error - which > makes > >>>>> > >> me > >> > >>>>> think that the assemblies compiled by Pyc are using things that > >>>>> > >>>>> > >>>> aren't > >>>> > >>>> > >>>>> available in Silverlight. *However* - > >>>>> Microsoft.Runtime.CompilerServices.StrongBox does exist in > >>>>> Silverlight. I think I'll try the whole process again just to > see. > >>>>> > >> My > >> > >>>>> guess is that rewriting would require an intimate knowledge of > the > >>>>> differences between the CoreCLR and standard .NET. > >>>>> > >>>>> > >>>>> > >>>> No - I've rerun the whole process from compiling with Pyc through > >>>> to replacing the references in the il and reassembling. Same > error. > >>>> > >> Shame. > >> > >>>> SystemError: Could not load type > >>>> 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly > >>>> 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, > >>>> PublicKeyToken=31bf3856ad364e35'.app.py > >>>> > >>>> Michael Foord > >>>> > >>>> > >>>> > >>>>> I can't import it in a Silverlight application though (the > >>>>> > >> following > >> > >>>>> code does work on the desktop version of IronPython): > >>>>> > >>>>> import clr > >>>>> clr.AddReference('Microsoft.Scripting') > >>>>> clr.AddReference('Microsoft.Scripting.Core') > >>>>> from Microsoft.Runtime.CompilerServices import StrongBox > >>>>> > >>>>> ImportError: No module named Runtime > >>>>> > >>>>> 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/ > >> > >> _______________________________________________ > >> 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 > From fuzzyman at voidspace.org.uk Wed Apr 22 01:23:24 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 22 Apr 2009 00:23:24 +0100 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <350E7D38B6D819428718949920EC235557270C6537@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECE02F.60109@voidspace.org.uk> <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> <49ECEE68.8030702@voidspace.org.uk> <49ECF202.4080109@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C60D0@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ED94A9.8070602@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C64F8@NA-EXMSG-C102.redmond.corp.microsoft.com> <49EE5055.2010605@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C6537@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49EE556C.70206@voidspace.org.uk> Dino Viehland wrote: > For some reason the re-write didn't work. I didn't rewrite that one. :-) > After the re-write the new binary in ildasm > should have a manifest that looks like: > > .assembly extern mscorlib > { > .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) > .ver 2:0:5:0 > } > .assembly extern Microsoft.Scripting > { > .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) > .ver 0:9:5:0 > } > .assembly extern IronPython > { > .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) > .ver 2:0:5:0 > } > .assembly extern Microsoft.Scripting.Core > { > .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) > .ver 0:9:5:0 > } > > Where the key part is the 5's in all of the version strings. I did: > > ildasm froob.dll /out:froob.txt > > [updated version numbers] > > ilasm /DLL froob.txt /resource:froob.res /out:froob2.dll > > and it seems to work. > > Hmm... I'll try that on the sample - but that's pretty much what I did earlier on the one that fails. Thanks for looking Dino. Michael >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Tuesday, April 21, 2009 4:02 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >> >> Dino Viehland wrote: >> >>> Do you have a simple repro XAP you can send me and I'll take a look? >>> >>> I'm not entirely sure I'll know what's going on as CoreCLR isn't the >>> CLR I'm used to debugging but it's not that different :) >>> >>> >>> >> Attached is a xap file. It has a very simple package compiled with Pyc >> - and importing it throws the same error. >> >> Michael >> >> >>>> -----Original Message----- >>>> From: users-bounces at lists.ironpython.com [mailto:users- >>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord >>>> Sent: Tuesday, April 21, 2009 2:41 AM >>>> To: Discussion of IronPython >>>> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >>>> >>>> Dino Viehland wrote: >>>> >>>> >>>>> You're compiling to a DLL and then trying to import (vs compiling >>>>> >> to >> >>>> an EXE)? >>>> >>>> >>>> Yes - it's support packages we're trying to compile. I would have >>>> thought that compiling an exe for Silverlight was a lost cause... :- >>>> >> ) >> >>>> There are two motivations, mainly speeding up import time but also >>>> source code obfuscation. If the assembly is genuinely serializable >>>> then we may at least achieve the second, so long as it doesn't make >>>> import time worse. >>>> >>>> Michael >>>> >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: users-bounces at lists.ironpython.com [mailto:users- >>>>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord >>>>>> Sent: Monday, April 20, 2009 3:07 PM >>>>>> To: Discussion of IronPython >>>>>> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >>>>>> >>>>>> Michael Foord wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Jb Evain wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hey Michael, >>>>>>>> >>>>>>>> On 4/20/09, Michael Foord wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I guess a full IL writer would be needed - which means back to >>>>>>>>> Cecil and the like and seeing if parts of them could be run on >>>>>>>>> Silverlight. >>>>>>>>> *sigh* >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> You just want to change the references to an assembly from the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> desktop >>>>>> >>>>>> >>>>>> >>>>>>>> version to the SL version? With Cecil it's like: >>>>>>>> >>>>>>>> var assembly = AssemblyFactory.GetAssembly (file); foreach (var >>>>>>>> reference in assembly.MainModule.AssemblyReferences) >>>>>>>> >>>>>>>> >>>> { >>>> >>>> >>>>>>>> if (!IsTargetAssembly (reference)) >>>>>>>> continue; >>>>>>>> >>>>>>>> reference.Version = new Version (2, 0, 5, 0); } >>>>>>>> AssemblyFactory.SaveAssembly (assembly, file); >>>>>>>> >>>>>>>> Now it doesn't guarantee that the resulting assembly is >>>>>>>> >> coherent, >> >>>>>>>> visibility wise, as you may have used methods that are not >>>>>>>> visible >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> or >>>>>> >>>>>> >>>>>> >>>>>>>> not existent in SL. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Thanks for that - if it would work it would be really useful, >>>>>>> >>>>>>> >>>>>>> >>>>>> however... >>>>>> >>>>>> >>>>>> >>>>>>> I think I've done the equivalent of this using ildasm / ilasm. >>>>>>> I've disassembled the assembly to IL, then replaced the >>>>>>> >> references >> >>>>>>> with >>>>>>> >>>>>>> >>>>>>> >>>>>> the >>>>>> >>>>>> >>>>>> >>>>>>> references to Silverlight assemblies and re-assembled. >>>>>>> >>>>>>> The resulting assembly throws exactly the same error - which >>>>>>> >> makes >> >>>> me >>>> >>>> >>>>>>> think that the assemblies compiled by Pyc are using things that >>>>>>> >>>>>>> >>>>>>> >>>>>> aren't >>>>>> >>>>>> >>>>>> >>>>>>> available in Silverlight. *However* - >>>>>>> Microsoft.Runtime.CompilerServices.StrongBox does exist in >>>>>>> Silverlight. I think I'll try the whole process again just to >>>>>>> >> see. >> >>>> My >>>> >>>> >>>>>>> guess is that rewriting would require an intimate knowledge of >>>>>>> >> the >> >>>>>>> differences between the CoreCLR and standard .NET. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> No - I've rerun the whole process from compiling with Pyc through >>>>>> to replacing the references in the il and reassembling. Same >>>>>> >> error. >> >>>> Shame. >>>> >>>> >>>>>> SystemError: Could not load type >>>>>> 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly >>>>>> 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, >>>>>> PublicKeyToken=31bf3856ad364e35'.app.py >>>>>> >>>>>> Michael Foord >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I can't import it in a Silverlight application though (the >>>>>>> >>>>>>> >>>> following >>>> >>>> >>>>>>> code does work on the desktop version of IronPython): >>>>>>> >>>>>>> import clr >>>>>>> clr.AddReference('Microsoft.Scripting') >>>>>>> clr.AddReference('Microsoft.Scripting.Core') >>>>>>> from Microsoft.Runtime.CompilerServices import StrongBox >>>>>>> >>>>>>> ImportError: No module named Runtime >>>>>>> >>>>>>> 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/ >>>> >>>> _______________________________________________ >>>> 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 >> >> > > _______________________________________________ > 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 wl2776 at gmail.com Thu Apr 23 10:44:51 2009 From: wl2776 at gmail.com (Vladimir Eremeev) Date: Thu, 23 Apr 2009 01:44:51 -0700 (PDT) Subject: [IronPython] Please, help to get started with .Net and IronPython. Message-ID: <23192785.post@talk.nabble.com> Hi all. I am trying to get started in programming with .Net and IronPython. I am involved in a project of developing a large application, written in C#. I have joined the project when it was already evolved, and have begun from extending other person's C++ code. This code implements an ActiveX component, which the main C# application loads and uses. This component represents a GUI form and some other processing functionality, related to playing and editing video files. Now I'd like to rewrite this form on IronPython, and extend the video processing functionality with running the mencoder executable (from the MPlayer project). However, I'd like to avoid much changes in the interface from my project part to the main C# application. Please, advice, how I should start and what main concepts should be. Another problem, which I have seen from my previous experiments with IPy is that when I add the reference to my IPy assembly to a C# project in the MS Visual Studio, my IPy functions get in the global namespace. I want to avoid this too. I remember, I've asked about this already, but, unfortunately, I've lost the reference. Thanks in advance for the help. -- View this message in context: http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23192785.html Sent from the IronPython mailing list archive at Nabble.com. From empirebuilder at gmail.com Thu Apr 23 10:47:42 2009 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Thu, 23 Apr 2009 10:47:42 +0200 Subject: [IronPython] Please, help to get started with .Net and IronPython. In-Reply-To: <23192785.post@talk.nabble.com> References: <23192785.post@talk.nabble.com> Message-ID: <8cd017b80904230147r3ed98e56ya3cb146eab3c0619@mail.gmail.com> Can I ask the reason why you want to rewrite portion of this application in IronPython? On Thu, Apr 23, 2009 at 10:44 AM, Vladimir Eremeev wrote: > > Hi all. > I am trying to get started in programming with .Net and IronPython. > > I am involved in a project of developing a large application, written in > C#. > I have joined the project when it was already evolved, and have begun from > extending other person's C++ code. This code implements an ActiveX > component, which the main C# application loads and uses. > > This component represents a GUI form and some other processing > functionality, related to playing and editing video files. > > Now I'd like to rewrite this form on IronPython, and extend the video > processing functionality with running the mencoder executable (from the > MPlayer project). > > However, I'd like to avoid much changes in the interface from my project > part to the main C# application. > > Please, advice, how I should start and what main concepts should be. > > Another problem, which I have seen from my previous experiments with IPy is > that when I add the reference to my IPy assembly to a C# project in the MS > Visual Studio, my IPy functions get in the global namespace. I want to > avoid > this too. I remember, I've asked about this already, but, unfortunately, > I've lost the reference. > > Thanks in advance for the help. > -- > View this message in context: > http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23192785.html > Sent from the IronPython mailing list archive at Nabble.com. > > _______________________________________________ > 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 wl2776 at gmail.com Thu Apr 23 11:00:28 2009 From: wl2776 at gmail.com (Vladimir Eremeev) Date: Thu, 23 Apr 2009 02:00:28 -0700 (PDT) Subject: [IronPython] Please, help to get started with .Net and IronPython. In-Reply-To: <8cd017b80904230147r3ed98e56ya3cb146eab3c0619@mail.gmail.com> References: <23192785.post@talk.nabble.com> <8cd017b80904230147r3ed98e56ya3cb146eab3c0619@mail.gmail.com> Message-ID: <23193038.post@talk.nabble.com> Dody Gunawinata wrote: > > Can I ask the reason why you want to rewrite portion of this application > in > IronPython? > I am tired fighting with memory leaks, data type conversions, etc. I don't like the C# language, its subjective. Just don't like. However, I have a basic understanding of it. And I want to improve my programming skills. -- View this message in context: http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23193038.html Sent from the IronPython mailing list archive at Nabble.com. From curt at hagenlocher.org Thu Apr 23 15:35:18 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 23 Apr 2009 06:35:18 -0700 Subject: [IronPython] Please, help to get started with .Net and IronPython. In-Reply-To: <23193038.post@talk.nabble.com> References: <23192785.post@talk.nabble.com> <8cd017b80904230147r3ed98e56ya3cb146eab3c0619@mail.gmail.com> <23193038.post@talk.nabble.com> Message-ID: It's great that you want to improve your skills. But I feel obliged to point out that IronPython -- and CPython, for that matter -- are about equally susceptible to memory leaks as C#. On Thu, Apr 23, 2009 at 2:00 AM, Vladimir Eremeev wrote: > > > Dody Gunawinata wrote: > > > > Can I ask the reason why you want to rewrite portion of this application > > in > > IronPython? > > > > I am tired fighting with memory leaks, data type conversions, etc. > > I don't like the C# language, its subjective. Just don't like. However, I > have a basic understanding of it. > And I want to improve my programming skills. > -- > View this message in context: > http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23193038.html > Sent from the IronPython mailing list archive at Nabble.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 empirebuilder at gmail.com Thu Apr 23 15:42:47 2009 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Thu, 23 Apr 2009 15:42:47 +0200 Subject: [IronPython] Please, help to get started with .Net and IronPython. In-Reply-To: <23193038.post@talk.nabble.com> References: <23192785.post@talk.nabble.com> <8cd017b80904230147r3ed98e56ya3cb146eab3c0619@mail.gmail.com> <23193038.post@talk.nabble.com> Message-ID: <8cd017b80904230642u7be6a5b1te3b08482db7d8a44@mail.gmail.com> This is a good starting point of reference http://www.ironpython.info/index.php/Contents for IronPython techniques for WinForms application. I would suggest you use IronPython in areas where you want to enhance the application, possibility in scripting the application or providing plugins. I would suggest rewriting the application in IronPython as the last option. Dody G. On Thu, Apr 23, 2009 at 11:00 AM, Vladimir Eremeev wrote: > > > Dody Gunawinata wrote: > > > > Can I ask the reason why you want to rewrite portion of this application > > in > > IronPython? > > > > I am tired fighting with memory leaks, data type conversions, etc. > > I don't like the C# language, its subjective. Just don't like. However, I > have a basic understanding of it. > And I want to improve my programming skills. > -- > View this message in context: > http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23193038.html > Sent from the IronPython mailing list archive at Nabble.com. > > _______________________________________________ > 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 william at resolversystems.com Thu Apr 23 15:43:22 2009 From: william at resolversystems.com (William Reade) Date: Thu, 23 Apr 2009 14:43:22 +0100 Subject: [IronPython] Please, help to get started with .Net and IronPython. In-Reply-To: References: <23192785.post@talk.nabble.com> <8cd017b80904230147r3ed98e56ya3cb146eab3c0619@mail.gmail.com> <23193038.post@talk.nabble.com> Message-ID: <49F0707A.3080807@resolversystems.com> I think he's rewriting a C++ component in IronPython, and wants to know how he can minimise the impact on the C# application which hosts it. Curt Hagenlocher wrote: > It's great that you want to improve your skills. But I feel obliged > to point out that IronPython -- and CPython, for that matter -- are > about equally susceptible to memory leaks as C#. > > On Thu, Apr 23, 2009 at 2:00 AM, Vladimir Eremeev > wrote: > > > > Dody Gunawinata wrote: > > > > Can I ask the reason why you want to rewrite portion of this > application > > in > > IronPython? > > > > I am tired fighting with memory leaks, data type conversions, etc. > > I don't like the C# language, its subjective. Just don't like. > However, I > have a basic understanding of it. > And I want to improve my programming skills. > -- > View this message in context: > http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23193038.html > Sent from the IronPython mailing list archive at Nabble.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 empirebuilder at gmail.com Thu Apr 23 16:00:24 2009 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Thu, 23 Apr 2009 16:00:24 +0200 Subject: [IronPython] Please, help to get started with .Net and IronPython. In-Reply-To: <49F0707A.3080807@resolversystems.com> References: <23192785.post@talk.nabble.com> <8cd017b80904230147r3ed98e56ya3cb146eab3c0619@mail.gmail.com> <23193038.post@talk.nabble.com> <49F0707A.3080807@resolversystems.com> Message-ID: <8cd017b80904230700o4282cd03jfcb7fe15a34ba11a@mail.gmail.com> Can IronPython be used in implementing an ActiveX component? This will be the shortest path if possible. Otherwise one way to do it is to declare a C# based interface, refactor the host application to use it and implement the interface in IP. http://stackoverflow.com/questions/695986/how-do-you-implement-an-interface-in-ironpython On Thu, Apr 23, 2009 at 3:43 PM, William Reade wrote: > I think he's rewriting a C++ component in IronPython, and wants to know how > he can minimise the impact on the C# application which hosts it. > > Curt Hagenlocher wrote: > >> It's great that you want to improve your skills. But I feel obliged to >> point out that IronPython -- and CPython, for that matter -- are about >> equally susceptible to memory leaks as C#. >> >> On Thu, Apr 23, 2009 at 2:00 AM, Vladimir Eremeev > wl2776 at gmail.com>> wrote: >> >> >> >> Dody Gunawinata wrote: >> > >> > Can I ask the reason why you want to rewrite portion of this >> application >> > in >> > IronPython? >> > >> >> I am tired fighting with memory leaks, data type conversions, etc. >> >> I don't like the C# language, its subjective. Just don't like. >> However, I >> have a basic understanding of it. >> And I want to improve my programming skills. >> -- >> View this message in context: >> >> http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23193038.html >> Sent from the IronPython mailing list archive at Nabble.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 > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Thu Apr 23 23:18:16 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 23 Apr 2009 14:18:16 -0700 Subject: [IronPython] Please, help to get started with .Net and IronPython. In-Reply-To: <8cd017b80904230700o4282cd03jfcb7fe15a34ba11a@mail.gmail.com> References: <23192785.post@talk.nabble.com> <8cd017b80904230147r3ed98e56ya3cb146eab3c0619@mail.gmail.com> <23193038.post@talk.nabble.com> <49F0707A.3080807@resolversystems.com> <8cd017b80904230700o4282cd03jfcb7fe15a34ba11a@mail.gmail.com> Message-ID: Implementing a COM component from IronPython isn't something you can reasonably due -- at a minimum, you either need to write a lot of IL yourself or use C# as glue. On Thu, Apr 23, 2009 at 7:00 AM, Dody Gunawinata wrote: > Can IronPython be used in implementing an ActiveX component? This will be > the shortest path if possible. Otherwise one way to do it is to declare a C# > based interface, refactor the host application to use it and implement the > interface in IP. > > http://stackoverflow.com/questions/695986/how-do-you-implement-an-interface-in-ironpython > > On Thu, Apr 23, 2009 at 3:43 PM, William Reade < > william at resolversystems.com> wrote: > >> I think he's rewriting a C++ component in IronPython, and wants to know >> how he can minimise the impact on the C# application which hosts it. >> >> Curt Hagenlocher wrote: >> >>> It's great that you want to improve your skills. But I feel obliged to >>> point out that IronPython -- and CPython, for that matter -- are about >>> equally susceptible to memory leaks as C#. >>> >>> On Thu, Apr 23, 2009 at 2:00 AM, Vladimir Eremeev >> wl2776 at gmail.com>> wrote: >>> >>> >>> >>> Dody Gunawinata wrote: >>> > >>> > Can I ask the reason why you want to rewrite portion of this >>> application >>> > in >>> > IronPython? >>> > >>> >>> I am tired fighting with memory leaks, data type conversions, etc. >>> >>> I don't like the C# language, its subjective. Just don't like. >>> However, I >>> have a basic understanding of it. >>> And I want to improve my programming skills. >>> -- >>> View this message in context: >>> >>> http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23193038.html >>> Sent from the IronPython mailing list archive at Nabble.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 >> > > > > -- > nomadlife.org > > > _______________________________________________ > 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 vernondcole at gmail.com Fri Apr 24 00:06:17 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Thu, 23 Apr 2009 16:06:17 -0600 Subject: [IronPython] Please, help to get started with .Net and IronPython. In-Reply-To: References: <23192785.post@talk.nabble.com> <8cd017b80904230147r3ed98e56ya3cb146eab3c0619@mail.gmail.com> <23193038.post@talk.nabble.com> <49F0707A.3080807@resolversystems.com> <8cd017b80904230700o4282cd03jfcb7fe15a34ba11a@mail.gmail.com> Message-ID: On the other hand, implementing a COM component in CPython using the pywin32 toolkit is fairly easy. Unless you have some other reason for choosing IronPython rather than CPython you may want to consider that. An example is published on page 68 of the book "Python Programming on Win32" by Mark Hammond. <> I have not investigated the possibility of re-compiling any of the C code portions of pywin32 as C# .NET components. My own little project (see adodbapi.sourceforge.net) is pure python, and works almost as well* in IronPython as under pywin32. However, it is a consumer, rather than a server, of COM. -- Vernon Cole (*) there was still one bug, last time I checked, which prevented IronPython from passing binary chunks as COM parameters. Perhaps it is fixed by now. On Thu, Apr 23, 2009 at 3:18 PM, Curt Hagenlocher wrote: > Implementing a COM component from IronPython isn't something you can > reasonably due -- at a minimum, you either need to write a lot of IL > yourself or use C# as glue. > > > On Thu, Apr 23, 2009 at 7:00 AM, Dody Gunawinata wrote: > >> Can IronPython be used in implementing an ActiveX component? This will be >> the shortest path if possible. Otherwise one way to do it is to declare a C# >> based interface, refactor the host application to use it and implement the >> interface in IP. >> >> http://stackoverflow.com/questions/695986/how-do-you-implement-an-interface-in-ironpython >> >> On Thu, Apr 23, 2009 at 3:43 PM, William Reade < >> william at resolversystems.com> wrote: >> >>> I think he's rewriting a C++ component in IronPython, and wants to know >>> how he can minimise the impact on the C# application which hosts it. >>> >>> Curt Hagenlocher wrote: >>> >>>> It's great that you want to improve your skills. But I feel obliged to >>>> point out that IronPython -- and CPython, for that matter -- are about >>>> equally susceptible to memory leaks as C#. >>>> >>>> On Thu, Apr 23, 2009 at 2:00 AM, Vladimir Eremeev >>> wl2776 at gmail.com>> wrote: >>>> >>>> >>>> >>>> Dody Gunawinata wrote: >>>> > >>>> > Can I ask the reason why you want to rewrite portion of this >>>> application >>>> > in >>>> > IronPython? >>>> > >>>> >>>> I am tired fighting with memory leaks, data type conversions, etc. >>>> >>>> I don't like the C# language, its subjective. Just don't like. >>>> However, I >>>> have a basic understanding of it. >>>> And I want to improve my programming skills. >>>> -- >>>> View this message in context: >>>> >>>> http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23193038.html >>>> Sent from the IronPython mailing list archive at Nabble.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 >>> >> >> >> >> -- >> nomadlife.org >> >> >> _______________________________________________ >> 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 wl2776 at gmail.com Fri Apr 24 08:40:43 2009 From: wl2776 at gmail.com (Vladimir Eremeev) Date: Thu, 23 Apr 2009 23:40:43 -0700 (PDT) Subject: [IronPython] Please, help to get started with .Net and IronPython. In-Reply-To: <49F0707A.3080807@resolversystems.com> References: <23192785.post@talk.nabble.com> <8cd017b80904230147r3ed98e56ya3cb146eab3c0619@mail.gmail.com> <23193038.post@talk.nabble.com> <49F0707A.3080807@resolversystems.com> Message-ID: <23210776.post@talk.nabble.com> William Reade wrote: > > I think he's rewriting a C++ component in IronPython, and wants to know > how he can minimise the impact on the C# application which hosts it. > That's right! Thank you. -- View this message in context: http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23210776.html Sent from the IronPython mailing list archive at Nabble.com. From rhinerfeld at yahoo.com Fri Apr 24 21:57:38 2009 From: rhinerfeld at yahoo.com (Richard Hinerfeld) Date: Fri, 24 Apr 2009 12:57:38 -0700 (PDT) Subject: [IronPython] Please, help to get started with .Net and IronPython. Message-ID: <445265.58270.qm@web45008.mail.sp1.yahoo.com> To extend IronPython 1.1 You need the source for IronPython and Visual studio 5. To extend the new Version of IronPython you need a new version of Visual studio. Also you can extend IronPython with C# which comes with the Visual studio environment. You can all this information from the IronPython Web site. Please note: You need to make sure that you are using WindowsXP with the latest service pack and all the .NET upgrades. The requirements are listed in the IronPython documentation. A good test for the correct development environment for building a given version of IronPython is to build a version of IronPython. Please also note ; If you are using a IronPython socket script to talk to a non-windows you will have a problem. IronPython uses the "Char" type to talk and receive information. In C# a Char is defined as 16-bits not 8. You need to use 'byte' type or modify the IronPython socket.cs file to fix this problem. Good Luck Richard D. Hinerfeld --- On Fri, 4/24/09, Vladimir Eremeev wrote: From: Vladimir Eremeev Subject: Re: [IronPython] Please, help to get started with .Net and IronPython. To: users at lists.ironpython.com Date: Friday, April 24, 2009, 2:40 AM William Reade wrote: > > I think he's rewriting a C++ component in IronPython, and wants to know > how he can minimise the impact on the C# application which hosts it. > That's right! Thank you. -- View this message in context: http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23210776.html Sent from the IronPython mailing list archive at Nabble.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 fuzzyman at voidspace.org.uk Sat Apr 25 20:37:10 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 25 Apr 2009 19:37:10 +0100 Subject: [IronPython] Please, help to get started with .Net and IronPython. In-Reply-To: <445265.58270.qm@web45008.mail.sp1.yahoo.com> References: <445265.58270.qm@web45008.mail.sp1.yahoo.com> Message-ID: <49F35856.5050706@voidspace.org.uk> Richard Hinerfeld wrote: > To extend IronPython 1.1 You need the source for IronPython and > Visual studio 5. To extend the new Version of IronPython you need a > new version of > You mean Visual Studio 2005 I assume, however Visual Studio 2008 will also work and you don't *need* the sources to IronPython to embed or extend IronPython. > Visual studio. Also you can extend IronPython with C# which comes with > the Visual studio environment. You can all this information from the > IronPython Web site. > Please note: > You need to make sure that you are using WindowsXP with the latest > service pack > and all the .NET upgrades. > Or windows Vista, or server 2008, or any of the platforms that Mono runs on. > The requirements are listed in the IronPython documentation. > A good test for the correct development environment for building a > given version of IronPython is to build a version of IronPython. > Please also note ; > If you are using a IronPython socket script to talk to a non-windows > you will have a > problem. IronPython uses the "Char" type to talk and receive > information. In C# a Char is defined as 16-bits not 8. You need to use > 'byte' type or modify the IronPython socket.cs file to fix this problem. > Really? Can you file a bug report on Codeplex that demonstrates the problem? On the other hand use the .NET bytes type with IronPython is fine. All the best, Michael Foord > > Good Luck > Richard D. Hinerfeld > > > --- On *Fri, 4/24/09, Vladimir Eremeev //* wrote: > > > From: Vladimir Eremeev > Subject: Re: [IronPython] Please, help to get started with .Net > and IronPython. > To: users at lists.ironpython.com > Date: Friday, April 24, 2009, 2:40 AM > > > > > William Reade wrote: > > > > I think he's rewriting a C++ component in IronPython, and wants > to know > > how he can minimise the impact on the C# application which hosts it. > > > > That's right! Thank you. > -- > View this message in context: > http://www.nabble.com/Please%2C-help-to-get-started-with-.Net-and-IronPython.-tp23192785p23210776.html > Sent from the IronPython mailing list archive at Nabble.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 > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From fuzzyman at voidspace.org.uk Mon Apr 27 01:35:22 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 27 Apr 2009 00:35:22 +0100 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <350E7D38B6D819428718949920EC235557270C6537@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECE02F.60109@voidspace.org.uk> <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> <49ECEE68.8030702@voidspace.org.uk> <49ECF202.4080109@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C60D0@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ED94A9.8070602@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C64F8@NA-EXMSG-C102.redmond.corp.microsoft.com> <49EE5055.2010605@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C6537@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49F4EFBA.7010006@voidspace.org.uk> Dino Viehland wrote: > For some reason the re-write didn't work. After the re-write the new binary in ildasm > should have a manifest that looks like: > > .assembly extern mscorlib > { > .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) > .ver 2:0:5:0 > } > .assembly extern Microsoft.Scripting > { > .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) > .ver 0:9:5:0 > } > .assembly extern IronPython > { > .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) > .ver 2:0:5:0 > } > .assembly extern Microsoft.Scripting.Core > { > .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) > .ver 0:9:5:0 > } > > Where the key part is the 5's in all of the version strings. I did: > > ildasm froob.dll /out:froob.txt > > [updated version numbers] > > ilasm /DLL froob.txt /resource:froob.res /out:froob2.dll > > and it seems to work. > Hmm... after I do the rewrite I *still* get the exception once I import from the assembly ("from froob import Smoog"). I wonder if this is because I'm on 64bit Vista? SystemError: Could not load type 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.app.py Michael Foord > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Tuesday, April 21, 2009 4:02 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >> >> Dino Viehland wrote: >> >>> Do you have a simple repro XAP you can send me and I'll take a look? >>> >>> I'm not entirely sure I'll know what's going on as CoreCLR isn't the >>> CLR I'm used to debugging but it's not that different :) >>> >>> >>> >> Attached is a xap file. It has a very simple package compiled with Pyc >> - and importing it throws the same error. >> >> Michael >> >> >>>> -----Original Message----- >>>> From: users-bounces at lists.ironpython.com [mailto:users- >>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord >>>> Sent: Tuesday, April 21, 2009 2:41 AM >>>> To: Discussion of IronPython >>>> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >>>> >>>> Dino Viehland wrote: >>>> >>>> >>>>> You're compiling to a DLL and then trying to import (vs compiling >>>>> >> to >> >>>> an EXE)? >>>> >>>> >>>> Yes - it's support packages we're trying to compile. I would have >>>> thought that compiling an exe for Silverlight was a lost cause... :- >>>> >> ) >> >>>> There are two motivations, mainly speeding up import time but also >>>> source code obfuscation. If the assembly is genuinely serializable >>>> then we may at least achieve the second, so long as it doesn't make >>>> import time worse. >>>> >>>> Michael >>>> >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: users-bounces at lists.ironpython.com [mailto:users- >>>>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord >>>>>> Sent: Monday, April 20, 2009 3:07 PM >>>>>> To: Discussion of IronPython >>>>>> Subject: Re: [IronPython] Compiling with Pyc for Silverlight >>>>>> >>>>>> Michael Foord wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Jb Evain wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hey Michael, >>>>>>>> >>>>>>>> On 4/20/09, Michael Foord wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I guess a full IL writer would be needed - which means back to >>>>>>>>> Cecil and the like and seeing if parts of them could be run on >>>>>>>>> Silverlight. >>>>>>>>> *sigh* >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> You just want to change the references to an assembly from the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> desktop >>>>>> >>>>>> >>>>>> >>>>>>>> version to the SL version? With Cecil it's like: >>>>>>>> >>>>>>>> var assembly = AssemblyFactory.GetAssembly (file); foreach (var >>>>>>>> reference in assembly.MainModule.AssemblyReferences) >>>>>>>> >>>>>>>> >>>> { >>>> >>>> >>>>>>>> if (!IsTargetAssembly (reference)) >>>>>>>> continue; >>>>>>>> >>>>>>>> reference.Version = new Version (2, 0, 5, 0); } >>>>>>>> AssemblyFactory.SaveAssembly (assembly, file); >>>>>>>> >>>>>>>> Now it doesn't guarantee that the resulting assembly is >>>>>>>> >> coherent, >> >>>>>>>> visibility wise, as you may have used methods that are not >>>>>>>> visible >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> or >>>>>> >>>>>> >>>>>> >>>>>>>> not existent in SL. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Thanks for that - if it would work it would be really useful, >>>>>>> >>>>>>> >>>>>>> >>>>>> however... >>>>>> >>>>>> >>>>>> >>>>>>> I think I've done the equivalent of this using ildasm / ilasm. >>>>>>> I've disassembled the assembly to IL, then replaced the >>>>>>> >> references >> >>>>>>> with >>>>>>> >>>>>>> >>>>>>> >>>>>> the >>>>>> >>>>>> >>>>>> >>>>>>> references to Silverlight assemblies and re-assembled. >>>>>>> >>>>>>> The resulting assembly throws exactly the same error - which >>>>>>> >> makes >> >>>> me >>>> >>>> >>>>>>> think that the assemblies compiled by Pyc are using things that >>>>>>> >>>>>>> >>>>>>> >>>>>> aren't >>>>>> >>>>>> >>>>>> >>>>>>> available in Silverlight. *However* - >>>>>>> Microsoft.Runtime.CompilerServices.StrongBox does exist in >>>>>>> Silverlight. I think I'll try the whole process again just to >>>>>>> >> see. >> >>>> My >>>> >>>> >>>>>>> guess is that rewriting would require an intimate knowledge of >>>>>>> >> the >> >>>>>>> differences between the CoreCLR and standard .NET. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> No - I've rerun the whole process from compiling with Pyc through >>>>>> to replacing the references in the il and reassembling. Same >>>>>> >> error. >> >>>> Shame. >>>> >>>> >>>>>> SystemError: Could not load type >>>>>> 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly >>>>>> 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, >>>>>> PublicKeyToken=31bf3856ad364e35'.app.py >>>>>> >>>>>> Michael Foord >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I can't import it in a Silverlight application though (the >>>>>>> >>>>>>> >>>> following >>>> >>>> >>>>>>> code does work on the desktop version of IronPython): >>>>>>> >>>>>>> import clr >>>>>>> clr.AddReference('Microsoft.Scripting') >>>>>>> clr.AddReference('Microsoft.Scripting.Core') >>>>>>> from Microsoft.Runtime.CompilerServices import StrongBox >>>>>>> >>>>>>> ImportError: No module named Runtime >>>>>>> >>>>>>> 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/ >>>> >>>> _______________________________________________ >>>> 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 >> >> > > _______________________________________________ > 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 fuzzyman at voidspace.org.uk Mon Apr 27 16:54:14 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 27 Apr 2009 15:54:14 +0100 Subject: [IronPython] Can't dir ArgIterator Message-ID: <49F5C716.4010408@voidspace.org.uk> Hello guys, From a standard install of IronPython 2.0.1 on Vista 64, calling dir on System.ArgIterator blows up: C:\compile>"C:\Program Files (x86)\IronPython 2.0.1\ipy.exe" -D -X:TabCompletion -X:ColorfulConsole IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3074 Type "help", "copyright", "credits" or "license" for more information. >>> from System import ArgIterator >>> dir(ArgIterator) Traceback (most recent call last): File "", line 1, in SystemError: An attempt was made to load a program with an incorrect format. (Ex ception from HRESULT: 0x8007000B) >>> Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From curt at hagenlocher.org Mon Apr 27 17:21:07 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 27 Apr 2009 08:21:07 -0700 Subject: [IronPython] Can't dir ArgIterator In-Reply-To: <49F5C716.4010408@voidspace.org.uk> References: <49F5C716.4010408@voidspace.org.uk> Message-ID: I ran into this a few months back and concluded that it was some kind of internal CLR issue. ArgIterator is a special type, most of whose methods are internal and/or unsafe, and the CLR doesn't seem to like it when we try to specialize a generic method using that type. Is there any particular goal you have where you're trying to use ArgIterator? On Mon, Apr 27, 2009 at 7:54 AM, Michael Foord wrote: > Hello guys, > > From a standard install of IronPython 2.0.1 on Vista 64, calling dir on > System.ArgIterator blows up: > > C:\compile>"C:\Program Files (x86)\IronPython 2.0.1\ipy.exe" -D > -X:TabCompletion > -X:ColorfulConsole > IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3074 > Type "help", "copyright", "credits" or "license" for more information. > >>> from System import ArgIterator > >>> dir(ArgIterator) > Traceback (most recent call last): > File "", line 1, in > SystemError: An attempt was made to load a program with an incorrect > format. (Ex > ception from HRESULT: 0x8007000B) > >>> > > > 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 fuzzyman at voidspace.org.uk Mon Apr 27 17:25:56 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 27 Apr 2009 16:25:56 +0100 Subject: [IronPython] Can't dir ArgIterator In-Reply-To: References: <49F5C716.4010408@voidspace.org.uk> Message-ID: <49F5CE84.4070606@voidspace.org.uk> Curt Hagenlocher wrote: > I ran into this a few months back and concluded that it was some kind > of internal CLR issue. ArgIterator is a special type, most of whose > methods are internal and/or unsafe, and the CLR doesn't seem to like > it when we try to specialize a generic method using that type. I'm using a Wing script to generate 'pi files' (interface files) to give me autocomplete on .NET assemblies and types. It introspects everything in the module and dies when it hits ArgIterator. I can put code in it to workaround it, but pthpththpbt... :-) Michael > > Is there any particular goal you have where you're trying to use > ArgIterator? > > On Mon, Apr 27, 2009 at 7:54 AM, Michael Foord > > wrote: > > Hello guys, > > >From a standard install of IronPython 2.0.1 on Vista 64, calling > dir on System.ArgIterator blows up: > > C:\compile>"C:\Program Files (x86)\IronPython 2.0.1\ipy.exe" -D > -X:TabCompletion > -X:ColorfulConsole > IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3074 > Type "help", "copyright", "credits" or "license" for more information. > >>> from System import ArgIterator > >>> dir(ArgIterator) > Traceback (most recent call last): > File "", line 1, in > SystemError: An attempt was made to load a program with an > incorrect format. (Ex > ception from HRESULT: 0x8007000B) > >>> > > > 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 From dfugate at microsoft.com Mon Apr 27 17:31:34 2009 From: dfugate at microsoft.com (Dave Fugate) Date: Mon, 27 Apr 2009 08:31:34 -0700 Subject: [IronPython] Can't dir ArgIterator In-Reply-To: <49F5CE84.4070606@voidspace.org.uk> References: <49F5C716.4010408@voidspace.org.uk> <49F5CE84.4070606@voidspace.org.uk> Message-ID: We already have a bug on this one. Please vote for http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=17235. Thanks, Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, April 27, 2009 8:26 AM To: Discussion of IronPython Subject: Re: [IronPython] Can't dir ArgIterator Curt Hagenlocher wrote: > I ran into this a few months back and concluded that it was some kind > of internal CLR issue. ArgIterator is a special type, most of whose > methods are internal and/or unsafe, and the CLR doesn't seem to like > it when we try to specialize a generic method using that type. I'm using a Wing script to generate 'pi files' (interface files) to give me autocomplete on .NET assemblies and types. It introspects everything in the module and dies when it hits ArgIterator. I can put code in it to workaround it, but pthpththpbt... :-) Michael > > Is there any particular goal you have where you're trying to use > ArgIterator? > > On Mon, Apr 27, 2009 at 7:54 AM, Michael Foord > > wrote: > > Hello guys, > > >From a standard install of IronPython 2.0.1 on Vista 64, calling > dir on System.ArgIterator blows up: > > C:\compile>"C:\Program Files (x86)\IronPython 2.0.1\ipy.exe" -D > -X:TabCompletion > -X:ColorfulConsole > IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3074 > Type "help", "copyright", "credits" or "license" for more information. > >>> from System import ArgIterator > >>> dir(ArgIterator) > Traceback (most recent call last): > File "", line 1, in > SystemError: An attempt was made to load a program with an > incorrect format. (Ex > ception from HRESULT: 0x8007000B) > >>> > > > 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 _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From curt at hagenlocher.org Mon Apr 27 17:32:32 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 27 Apr 2009 08:32:32 -0700 Subject: [IronPython] Can't dir ArgIterator In-Reply-To: <49F5CE84.4070606@voidspace.org.uk> References: <49F5C716.4010408@voidspace.org.uk> <49F5CE84.4070606@voidspace.org.uk> Message-ID: That's pretty much what we would have to do as well -- special-case based on the type name. It seems to be more trouble than it's worth. On Mon, Apr 27, 2009 at 8:25 AM, Michael Foord wrote: > Curt Hagenlocher wrote: > >> I ran into this a few months back and concluded that it was some kind of >> internal CLR issue. ArgIterator is a special type, most of whose methods are >> internal and/or unsafe, and the CLR doesn't seem to like it when we try to >> specialize a generic method using that type. >> > > I'm using a Wing script to generate 'pi files' (interface files) to give me > autocomplete on .NET assemblies and types. It introspects everything in the > module and dies when it hits ArgIterator. > > I can put code in it to workaround it, but pthpththpbt... :-) > > Michael > > >> Is there any particular goal you have where you're trying to use >> ArgIterator? >> >> On Mon, Apr 27, 2009 at 7:54 AM, Michael Foord > fuzzyman at voidspace.org.uk>> wrote: >> >> Hello guys, >> >> >From a standard install of IronPython 2.0.1 on Vista 64, calling >> dir on System.ArgIterator blows up: >> >> C:\compile>"C:\Program Files (x86)\IronPython 2.0.1\ipy.exe" -D >> -X:TabCompletion >> -X:ColorfulConsole >> IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3074 >> Type "help", "copyright", "credits" or "license" for more information. >> >>> from System import ArgIterator >> >>> dir(ArgIterator) >> Traceback (most recent call last): >> File "", line 1, in >> SystemError: An attempt was made to load a program with an >> incorrect format. (Ex >> ception from HRESULT: 0x8007000B) >> >>> >> >> >> 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 > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Apr 27 17:35:33 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 27 Apr 2009 16:35:33 +0100 Subject: [IronPython] Can't dir ArgIterator In-Reply-To: References: <49F5C716.4010408@voidspace.org.uk> <49F5CE84.4070606@voidspace.org.uk> Message-ID: <49F5D0C5.6040108@voidspace.org.uk> Curt Hagenlocher wrote: > That's pretty much what we would have to do as well -- special-case > based on the type name. It seems to be more trouble than it's worth. Based on type name or by catching the error? Catching the error and not propagating it to the user seems to be more robust - if it happens for this class then presumably it can happen elsewhere and calling dir really shouldn't raise an exception. Returning an empty list would be much more friendly. Anyway, I'll leave my workaround in place and vote for the issue. Michael > > On Mon, Apr 27, 2009 at 8:25 AM, Michael Foord > > wrote: > > Curt Hagenlocher wrote: > > I ran into this a few months back and concluded that it was > some kind of internal CLR issue. ArgIterator is a special > type, most of whose methods are internal and/or unsafe, and > the CLR doesn't seem to like it when we try to specialize a > generic method using that type. > > > I'm using a Wing script to generate 'pi files' (interface files) > to give me autocomplete on .NET assemblies and types. It > introspects everything in the module and dies when it hits > ArgIterator. > > I can put code in it to workaround it, but pthpththpbt... :-) > > Michael > > > Is there any particular goal you have where you're trying to > use ArgIterator? > > On Mon, Apr 27, 2009 at 7:54 AM, Michael Foord > > >> wrote: > > Hello guys, > > >From a standard install of IronPython 2.0.1 on Vista 64, > calling > dir on System.ArgIterator blows up: > > C:\compile>"C:\Program Files (x86)\IronPython 2.0.1\ipy.exe" -D > -X:TabCompletion > -X:ColorfulConsole > IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3074 > Type "help", "copyright", "credits" or "license" for more > information. > >>> from System import ArgIterator > >>> dir(ArgIterator) > Traceback (most recent call last): > File "", line 1, in > SystemError: An attempt was made to load a program with an > incorrect format. (Ex > ception from HRESULT: 0x8007000B) > >>> > > > 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 > > > _______________________________________________ > 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 From vernondcole at gmail.com Mon Apr 27 18:00:03 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Mon, 27 Apr 2009 10:00:03 -0600 Subject: [IronPython] pywin32 on Iron Python? Message-ID: This is an opinion poll... The portion of pywin32 which I maintain, adodbapi, will work in either CPython or IronPython. That was (relatively) easy, since it is written in pure Python. Pywin32 is a complete package which allows a python programmer to perform many Windows systems administration functions, or use native Windows features easily in an application program. While anything which can be done in pywin32 can also be done (perhaps with more difficulty) using .NET code, it seems that it would be convenient to have the same API available in either environment. This question is meaningful now, since work is starting on a second edition of the book "Python Programming on Win32" and we would like to know how much Iron Python information to include. Is there any interest in forking the pywin32 C code into C# so that the entire package can be run in a .NET environment using IronPython? -- Vernon Cole -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Apr 27 18:06:38 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 27 Apr 2009 17:06:38 +0100 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: Message-ID: <49F5D80E.6080609@voidspace.org.uk> Vernon Cole wrote: > This is an opinion poll... > > The portion of pywin32 which I maintain, adodbapi, will work in either > CPython or IronPython. That was (relatively) easy, since it is written > in pure Python. > > Pywin32 is a complete package which allows a python programmer to > perform many Windows systems administration functions, or use native > Windows features easily in an application program. While anything > which can be done in pywin32 can also be done (perhaps with more > difficulty) using .NET code, it seems that it would be convenient to > have the same API available in either environment. This question is > meaningful now, since work is starting on a second edition of the book > "Python Programming on Win32" and we would like to know how much Iron > Python information to include. > > Is there any interest in forking the pywin32 C code into C# so that > the entire package can be run in a .NET environment using IronPython? Providing the same API as a wrapper over C# would *definitely* be of interest. My guess is that some of what pywin32 does there is already a .NET wrapper available for (although there might be some API mismatch) and for a lot you will need to use P/Invoke. Another approach would be to rewrite pywin32 to use ctypes and then pywin32 would run on PyPy, Jython, Python *and* IronPython once Jeff Hardy has completed his port... All the best, Michael > -- > Vernon Cole > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 ivan at flanders.co.nz Mon Apr 27 20:24:37 2009 From: ivan at flanders.co.nz (Ivan Porto Carrero) Date: Mon, 27 Apr 2009 20:24:37 +0200 Subject: [IronPython] can't inherit?? Message-ID: it's a bad subject but I didn't know how else to call it. For the DynamicScriptControl somebody submitted an ironpython implementation in February but I only just now got round to adding it. And I have problems :) The link below has the line that fails for IronPython but works for IronRuby http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/DynamicScriptControl/ScriptConverter.cs#37 So the idea is that you read a script file containing a wpf/silverlight control. Because you cannot have DLR controls in WPF atm there is this dynamic script control to allow you to have DLR controls participate in XAML. So what happens in IronRuby is the following. The script converter generates a script that will set the properties and create an instance of the control. This control is then put into the XAML object graph. The script that is generated actually monkey patches the initialize method of the the control class to populate the control properties. The implementation that has been provided to me actually inherits of the first control to override the constructor and to do the proper initializations, only it doesn't work. it tells me that it cannot find the parent class I get an UnboundNameException and AFAICT I shouldn't get that. I'm using the latest nightly builds. The ruby implementation of the control http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/TestApplication/prefilled_text_box.rb the python implementation http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/TestApplication/prefilled_text_box.py The ruby code formatter (for monkey patching the control): http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/DynamicScriptControl/Formatters/RubyFormatter.cs The python code formatter: http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/DynamicScriptControl/Formatters/PythonFormatter.cs I'm pretty sure this is a 5 second fix for somebody that knows what they're doing with IronPython, so help help ... ;) Thanks --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero GSM: +32.486.787.582 Blog: http://flanders.co.nz Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) Steven Wright - "A lot of people are afraid of heights. Not me, I'm afraid of widths." -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Apr 27 20:41:48 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 27 Apr 2009 11:41:48 -0700 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: <49F5D80E.6080609@voidspace.org.uk> References: <49F5D80E.6080609@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> Not to rain on Jeff's parade but I too have been working on a CTypes implementation. I'll probably check the initial version into 2.6 in the next few days but there's still a lot more to go before it's a solid implementation. As of right now running test\test_ctypes.py reports 358 tests run w/ 75 failures and 195 errors. So that's only a 25% pass rate but I'm hoping we'll be able to get it all working in time for 2.6 beta 1. The current plan is to add it but not have it enabled by default (so import _ctypes will continue to fail). Once it's passing all or nearly all of the tests then it'll get flipped on and available by default. But I'm generally +1 on using ctypes for interop. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, April 27, 2009 9:07 AM > To: Discussion of IronPython > Subject: Re: [IronPython] pywin32 on Iron Python? > > Vernon Cole wrote: > > This is an opinion poll... > > > > The portion of pywin32 which I maintain, adodbapi, will work in > either > > CPython or IronPython. That was (relatively) easy, since it is > written > > in pure Python. > > > > Pywin32 is a complete package which allows a python programmer to > > perform many Windows systems administration functions, or use native > > Windows features easily in an application program. While anything > > which can be done in pywin32 can also be done (perhaps with more > > difficulty) using .NET code, it seems that it would be convenient to > > have the same API available in either environment. This question is > > meaningful now, since work is starting on a second edition of the > book > > "Python Programming on Win32" and we would like to know how much Iron > > Python information to include. > > > > Is there any interest in forking the pywin32 C code into C# so that > > the entire package can be run in a .NET environment using IronPython? > > Providing the same API as a wrapper over C# would *definitely* be of > interest. > > My guess is that some of what pywin32 does there is already a .NET > wrapper available for (although there might be some API mismatch) and > for a lot you will need to use P/Invoke. > > Another approach would be to rewrite pywin32 to use ctypes and then > pywin32 would run on PyPy, Jython, Python *and* IronPython once Jeff > Hardy has completed his port... > > All the best, > > Michael > > > -- > > Vernon Cole > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > 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 dfugate at microsoft.com Mon Apr 27 20:46:23 2009 From: dfugate at microsoft.com (Dave Fugate) Date: Mon, 27 Apr 2009 11:46:23 -0700 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> Message-ID: It just so happens that not too long ago we received permission from the Microsoft legal team to run pywin32's tests against IronPython. Late last week I started investigating which of pywin32's tests are appropriate to hook into our own source control checkin system. By this, I simply mean that future checkins which break an already working pywin32 test would not be allowed into the IronPython source tree. I think it's really awesome that Vernon took the initiative of getting abodbapi running under IronPython, and we would definitely hook up other pywin32 tests into our checkin system if they run under the latest developmental release of IronPython (e.g., 2.6 Alpha 1 at the moment). We'd actually like to able to contribute such changes back to pywin32 ourselves, but there are a few legal concerns currently holding us back. Thanks, Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, April 27, 2009 9:07 AM To: Discussion of IronPython Subject: Re: [IronPython] pywin32 on Iron Python? Vernon Cole wrote: > This is an opinion poll... > > The portion of pywin32 which I maintain, adodbapi, will work in either > CPython or IronPython. That was (relatively) easy, since it is written > in pure Python. > > Pywin32 is a complete package which allows a python programmer to > perform many Windows systems administration functions, or use native > Windows features easily in an application program. While anything > which can be done in pywin32 can also be done (perhaps with more > difficulty) using .NET code, it seems that it would be convenient to > have the same API available in either environment. This question is > meaningful now, since work is starting on a second edition of the book > "Python Programming on Win32" and we would like to know how much Iron > Python information to include. > > Is there any interest in forking the pywin32 C code into C# so that > the entire package can be run in a .NET environment using IronPython? Providing the same API as a wrapper over C# would *definitely* be of interest. My guess is that some of what pywin32 does there is already a .NET wrapper available for (although there might be some API mismatch) and for a lot you will need to use P/Invoke. Another approach would be to rewrite pywin32 to use ctypes and then pywin32 would run on PyPy, Jython, Python *and* IronPython once Jeff Hardy has completed his port... All the best, Michael > -- > Vernon Cole > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mon Apr 27 20:59:45 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 27 Apr 2009 11:59:45 -0700 Subject: [IronPython] Compiling with Pyc for Silverlight In-Reply-To: <49F4EFBA.7010006@voidspace.org.uk> References: <49EC4FAE.5030904@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5D13@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD053.8030105@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F46@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECD9E8.2080705@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C5F5C@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ECE02F.60109@voidspace.org.uk> <69f7d8470904201434i2746e74fs2bff4a482ff56066@mail.gmail.com> <49ECEE68.8030702@voidspace.org.uk> <49ECF202.4080109@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C60D0@NA-EXMSG-C102.redmond.corp.microsoft.com> <49ED94A9.8070602@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C64F8@NA-EXMSG-C102.redmond.corp.microsoft.com> <49EE5055.2010605@voidspace.org.uk> <350E7D38B6D819428718949920EC235557270C6537@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F4EFBA.7010006@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23555728B89892@NA-EXMSG-C102.redmond.corp.microsoft.com> I wouldn't expect 32-bit vs 64-bit to have much to do w/ it because Silverlight it all 32-bit. Here's my modified .dll - does this work for you? I put this in a tmp directory in " C:\Program Files\IronPython 2.0.1\Silverlight\bin\" and then have an index.html pointing to it via: ... ... And then I start it by doing: Chiron.exe /b:index.html And the output was: SomeClass __builtins__ __file__ __name__ In a big font. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Sunday, April 26, 2009 4:35 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Compiling with Pyc for Silverlight > > Dino Viehland wrote: > > For some reason the re-write didn't work. After the re-write the new > binary in ildasm > > should have a manifest that looks like: > > > > .assembly extern mscorlib > > { > > .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) > > .ver 2:0:5:0 > > } > > .assembly extern Microsoft.Scripting > > { > > .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) > > .ver 0:9:5:0 > > } > > .assembly extern IronPython > > { > > .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) > > .ver 2:0:5:0 > > } > > .assembly extern Microsoft.Scripting.Core > > { > > .publickeytoken = (31 BF 38 56 AD 36 4E 35 ) > > .ver 0:9:5:0 > > } > > > > Where the key part is the 5's in all of the version strings. I > did: > > > > ildasm froob.dll /out:froob.txt > > > > [updated version numbers] > > > > ilasm /DLL froob.txt /resource:froob.res /out:froob2.dll > > > > and it seems to work. > > > > Hmm... after I do the rewrite I *still* get the exception once I import > from the assembly ("from froob import Smoog"). I wonder if this is > because I'm on 64bit Vista? > > SystemError: Could not load type > 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly > 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, > PublicKeyToken=31bf3856ad364e35'.app.py > > Michael Foord > > > > > >> -----Original Message----- > >> From: users-bounces at lists.ironpython.com [mailto:users- > >> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >> Sent: Tuesday, April 21, 2009 4:02 PM > >> To: Discussion of IronPython > >> Subject: Re: [IronPython] Compiling with Pyc for Silverlight > >> > >> Dino Viehland wrote: > >> > >>> Do you have a simple repro XAP you can send me and I'll take a > look? > >>> > >>> I'm not entirely sure I'll know what's going on as CoreCLR isn't > the > >>> CLR I'm used to debugging but it's not that different :) > >>> > >>> > >>> > >> Attached is a xap file. It has a very simple package compiled with > Pyc > >> - and importing it throws the same error. > >> > >> Michael > >> > >> > >>>> -----Original Message----- > >>>> From: users-bounces at lists.ironpython.com [mailto:users- > >>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >>>> Sent: Tuesday, April 21, 2009 2:41 AM > >>>> To: Discussion of IronPython > >>>> Subject: Re: [IronPython] Compiling with Pyc for Silverlight > >>>> > >>>> Dino Viehland wrote: > >>>> > >>>> > >>>>> You're compiling to a DLL and then trying to import (vs compiling > >>>>> > >> to > >> > >>>> an EXE)? > >>>> > >>>> > >>>> Yes - it's support packages we're trying to compile. I would have > >>>> thought that compiling an exe for Silverlight was a lost cause... > :- > >>>> > >> ) > >> > >>>> There are two motivations, mainly speeding up import time but also > >>>> source code obfuscation. If the assembly is genuinely serializable > >>>> then we may at least achieve the second, so long as it doesn't > make > >>>> import time worse. > >>>> > >>>> Michael > >>>> > >>>> > >>>> > >>>>>> -----Original Message----- > >>>>>> From: users-bounces at lists.ironpython.com [mailto:users- > >>>>>> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >>>>>> Sent: Monday, April 20, 2009 3:07 PM > >>>>>> To: Discussion of IronPython > >>>>>> Subject: Re: [IronPython] Compiling with Pyc for Silverlight > >>>>>> > >>>>>> Michael Foord wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Jb Evain wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Hey Michael, > >>>>>>>> > >>>>>>>> On 4/20/09, Michael Foord wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> I guess a full IL writer would be needed - which means back > to > >>>>>>>>> Cecil and the like and seeing if parts of them could be run > on > >>>>>>>>> Silverlight. > >>>>>>>>> *sigh* > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> You just want to change the references to an assembly from the > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> desktop > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> version to the SL version? With Cecil it's like: > >>>>>>>> > >>>>>>>> var assembly = AssemblyFactory.GetAssembly (file); foreach > (var > >>>>>>>> reference in assembly.MainModule.AssemblyReferences) > >>>>>>>> > >>>>>>>> > >>>> { > >>>> > >>>> > >>>>>>>> if (!IsTargetAssembly (reference)) > >>>>>>>> continue; > >>>>>>>> > >>>>>>>> reference.Version = new Version (2, 0, 5, 0); } > >>>>>>>> AssemblyFactory.SaveAssembly (assembly, file); > >>>>>>>> > >>>>>>>> Now it doesn't guarantee that the resulting assembly is > >>>>>>>> > >> coherent, > >> > >>>>>>>> visibility wise, as you may have used methods that are not > >>>>>>>> visible > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> or > >>>>>> > >>>>>> > >>>>>> > >>>>>>>> not existent in SL. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> Thanks for that - if it would work it would be really useful, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> however... > >>>>>> > >>>>>> > >>>>>> > >>>>>>> I think I've done the equivalent of this using ildasm / ilasm. > >>>>>>> I've disassembled the assembly to IL, then replaced the > >>>>>>> > >> references > >> > >>>>>>> with > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> the > >>>>>> > >>>>>> > >>>>>> > >>>>>>> references to Silverlight assemblies and re-assembled. > >>>>>>> > >>>>>>> The resulting assembly throws exactly the same error - which > >>>>>>> > >> makes > >> > >>>> me > >>>> > >>>> > >>>>>>> think that the assemblies compiled by Pyc are using things that > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> aren't > >>>>>> > >>>>>> > >>>>>> > >>>>>>> available in Silverlight. *However* - > >>>>>>> Microsoft.Runtime.CompilerServices.StrongBox does exist in > >>>>>>> Silverlight. I think I'll try the whole process again just to > >>>>>>> > >> see. > >> > >>>> My > >>>> > >>>> > >>>>>>> guess is that rewriting would require an intimate knowledge of > >>>>>>> > >> the > >> > >>>>>>> differences between the CoreCLR and standard .NET. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> No - I've rerun the whole process from compiling with Pyc > through > >>>>>> to replacing the references in the il and reassembling. Same > >>>>>> > >> error. > >> > >>>> Shame. > >>>> > >>>> > >>>>>> SystemError: Could not load type > >>>>>> 'Microsoft.Runtime.CompilerServices.StrongBox`1' from assembly > >>>>>> 'Microsoft.Scripting.Core, Version=2.0.5.0, Culture=neutral, > >>>>>> PublicKeyToken=31bf3856ad364e35'.app.py > >>>>>> > >>>>>> Michael Foord > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> I can't import it in a Silverlight application though (the > >>>>>>> > >>>>>>> > >>>> following > >>>> > >>>> > >>>>>>> code does work on the desktop version of IronPython): > >>>>>>> > >>>>>>> import clr > >>>>>>> clr.AddReference('Microsoft.Scripting') > >>>>>>> clr.AddReference('Microsoft.Scripting.Core') > >>>>>>> from Microsoft.Runtime.CompilerServices import StrongBox > >>>>>>> > >>>>>>> ImportError: No module named Runtime > >>>>>>> > >>>>>>> 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/ > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > >> > > > > _______________________________________________ > > 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 -------------- A non-text attachment was scrubbed... Name: froob.zip Type: application/x-zip-compressed Size: 2894 bytes Desc: froob.zip URL: From jdhardy at gmail.com Mon Apr 27 21:02:54 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 27 Apr 2009 13:02:54 -0600 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: On Mon, Apr 27, 2009 at 12:41 PM, Dino Viehland wrote: > Not to rain on Jeff's parade but I too have been working on a CTypes > implementation. ?I'll probably check the initial version into 2.6 in the > next few days but there's still a lot more to go before it's a solid > implementation. Geez, Dino, you guys need to do a better job of making this info public. It's a bit frustrating not knowing what you guys are working on. I think the IronRuby guys have a page listing all of the libraries that need work and who's claimed them. They also allow for library contributions, so it's a bit of a different story. - Jeff From dinov at microsoft.com Mon Apr 27 21:30:31 2009 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 27 Apr 2009 12:30:31 -0700 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Sorry Jeff, you're right. I had started this a long time ago just as a fun thing to hack on every now and then and it's recently gotten good enough that it seems like it can make it into 2.6. So it's a bit of an oddball - even if we had a place for me to claim that I was working on it it's doubtful that I would have actually claimed it until about a week or two ago... The good news is there's no other surprises like this lurking - we've generally been focused on 2.6, bugs, and startup perf - but ctypes is the #1 feature request so it seemed worthy of working on it. Maybe we should add a 2.6 Plan page to the CodePlex site? I'm sure there's more information than just what new features we expect to be included that could go there. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Jeff Hardy > Sent: Monday, April 27, 2009 12:03 PM > To: Discussion of IronPython > Subject: Re: [IronPython] pywin32 on Iron Python? > > On Mon, Apr 27, 2009 at 12:41 PM, Dino Viehland > wrote: > > Not to rain on Jeff's parade but I too have been working on a CTypes > > implementation. ?I'll probably check the initial version into 2.6 in > the > > next few days but there's still a lot more to go before it's a solid > > implementation. > > Geez, Dino, you guys need to do a better job of making this info > public. It's a bit frustrating not knowing what you guys are working > on. > > I think the IronRuby guys have a page listing all of the libraries > that need work and who's claimed them. They also allow for library > contributions, so it's a bit of a different story. > > - Jeff > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jdhardy at gmail.com Tue Apr 28 01:48:44 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 27 Apr 2009 17:48:44 -0600 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: On Mon, Apr 27, 2009 at 1:30 PM, Dino Viehland wrote: > Sorry Jeff, you're right. ?I had started this a long time ago just as a fun thing > to hack on every now and then and it's recently gotten good enough that it seems > like it can make it into 2.6. ?So it's a bit of an oddball - even if we had a > place for me to claim that I was working on it it's doubtful that I would have > actually claimed it until about a week or two ago... That's about how I started, too (that, and I wanted to get the csvn bindings working), and about the same time I felt comfortable making it public. The problem as I see it is that you can't take any of the work I've done (on the off chance that my version has something novel ;)), and even once it's in the trunk, the only thing I can do to improve it is file bug reports. I know you have to go through the lawyers - and I can only imagine how much fun that must be - but I do wonder what the difference is between IR (which accepts library contributions) and IP (which doesn't). Is the plan to wait until the DLR is out of the IronPython tree, to avoid any IP issues with it? Or is it, like most things, simply too many things to do and not enough bodies? > > The good news is there's no other surprises like this lurking - we've generally > been focused on 2.6, bugs, and startup perf - but ctypes is the #1 feature > request so it seemed worthy of working on it. > > Maybe we should add a 2.6 Plan page to the CodePlex site? ?I'm sure there's more > information than just what new features we expect to be included that could > go there. I think a listing of what's planned to 2.6 would be great - especially the parts that aren't in 2.0 already. I assume all of the CPython 2.6 features will be in there, but what are the holes in IPy 2.0 that 2.6 is going to fill? Also, at least an estimated timeline - I've heard 'fall' as an estimate, but something a little more concrete would be nice :). - Jeff From fuzzyman at voidspace.org.uk Tue Apr 28 11:13:15 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 28 Apr 2009 10:13:15 +0100 Subject: [IronPython] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator) Message-ID: <49F6C8AB.7030401@voidspace.org.uk> Hello all, I've created a modified version of the 'generate_pi.py' which generates the interface files for .NET libraries. It is attached. At the moment it generates PI files for the following assemblies / namespaces (hardwired at the bottom of the code): System System.Data System.Drawing System.Windows.Forms To run it, create a new directory and add this to the 'Interface File Path' (File menu -> Preferences -> Source Analysis -> Advanced -> Insert). Then from the command line switch to this directory (if you are on Vista you will need to run cmd with admin privileges due to a defect explained below). Execute the command: ipy generate_pi_for_net.py This generates the pi files. It doesn't work *as well* on 64 bit windows because the .NET XML help files (or whatever they are called) are in a different location so the docstrings are not always available - which is why I am not just distributing the pi files yet. The script doesn't yet understand static properties on classes - so it actually *fetches* static properties rather than looking at the descriptor (which is available in the class __dict__ so should be easy to fix). This is what causes inadvertent registry lookups etc and therefore requires admin privileges. It doesn't yet understand multiple overloads. This may require a change to Wing or may not matter. It isn't yet able to do anything with the information about return types - which would allow Wing to know the type of objects returned by methods. This may be easy to add? It is late so I am going to bed. At some point I will explain the simple changes I had to make to the standard generate_pi.py script (although they are mostly straightforward). I will also do further work on it as it will be very useful to me... All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: generate_pi_for_net.py URL: From curt at hagenlocher.org Tue Apr 28 17:18:17 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 28 Apr 2009 08:18:17 -0700 Subject: [IronPython] can't inherit?? In-Reply-To: References: Message-ID: One immediately apparent problem is that the strategy for formatting the code that initializes attributes is completely broken for Python -- you need to know how far to indent each of the lines in the code and not just the first one. On Mon, Apr 27, 2009 at 11:24 AM, Ivan Porto Carrero wrote: > it's a bad subject but I didn't know how else to call it. > > For the DynamicScriptControl somebody submitted an ironpython > implementation in February but I only just now got round to adding it. > And I have problems :) > > The link below has the line that fails for IronPython but works for > IronRuby > > > http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/DynamicScriptControl/ScriptConverter.cs#37 > > So the idea is that you read a script file containing a wpf/silverlight > control. Because you cannot have DLR controls in WPF atm there is this > dynamic script control to allow you to have DLR controls participate in > XAML. > > So what happens in IronRuby is the following. > The script converter generates a script that will set the properties and > create an instance of the control. This control is then put into the XAML > object graph. > The script that is generated actually monkey patches the initialize method > of the the control class to populate the control properties. > > The implementation that has been provided to me actually inherits of the > first control to override the constructor and to do the proper > initializations, only it doesn't work. > it tells me that it cannot find the parent class I get an > UnboundNameException and AFAICT I shouldn't get that. > > I'm using the latest nightly builds. > > The ruby implementation of the control > > http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/TestApplication/prefilled_text_box.rb > > the python implementation > > http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/TestApplication/prefilled_text_box.py > > The ruby code formatter (for monkey patching the control): > > http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/DynamicScriptControl/Formatters/RubyFormatter.cs > > The python code formatter: > > http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/DynamicScriptControl/Formatters/PythonFormatter.cs > > > I'm pretty sure this is a 5 second fix for somebody that knows what they're > doing with IronPython, so help help ... ;) > > Thanks > > --- > Met vriendelijke groeten - Best regards - Salutations > Ivan Porto Carrero > GSM: +32.486.787.582 > Blog: http://flanders.co.nz > Twitter: http://twitter.com/casualjim > Author of IronRuby in Action (http://manning.com/carrero) > > Steven Wright - "A lot of people are afraid of heights. Not me, I'm afraid of widths." > _______________________________________________ > 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 Tue Apr 28 17:53:34 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 28 Apr 2009 08:53:34 -0700 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <350E7D38B6D819428718949920EC23555728B89BBC@NA-EXMSG-C102.redmond.corp.microsoft.com> The primary difference between IP and IR is just that IP is in the lucky spot of getting to push things one step further. This just reflects the reality that other teams within MS have taken a dependency on IronPython (e.g. Robotics, Intellipad, and most recently Navision - who knows what's next!). Therefore we get to fight the next battle of not only taking back contributions but also then redistributing those contributions as part of another MS product. So it's no longer about just us or our peers working on the DLR :( It sucks that we can't take your work back - I had many moments yesterday where I was wondering if you had implemented something already. I'll get started on a future releases plan page. Just as a teaser beta 1 is about a month away. We are a little bit shy about announcing a particular date - if we said 9/29/2009 or something and got it wrong we'd feel a little bit silly. But we can at least give a better idea of the road map (e.g. 2 betas, RC, then release sort of thing which is the plan) rather than saying an indeterminate amount of releases and we'll ship like we have in the past :) > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Jeff Hardy > Sent: Monday, April 27, 2009 4:49 PM > To: Discussion of IronPython > Subject: Re: [IronPython] pywin32 on Iron Python? > > On Mon, Apr 27, 2009 at 1:30 PM, Dino Viehland > wrote: > > Sorry Jeff, you're right. ?I had started this a long time ago just as > a fun thing > > to hack on every now and then and it's recently gotten good enough > that it seems > > like it can make it into 2.6. ?So it's a bit of an oddball - even if > we had a > > place for me to claim that I was working on it it's doubtful that I > would have > > actually claimed it until about a week or two ago... > > That's about how I started, too (that, and I wanted to get the csvn > bindings working), and about the same time I felt comfortable making > it public. > > The problem as I see it is that you can't take any of the work I've > done (on the off chance that my version has something novel ;)), and > even once it's in the trunk, the only thing I can do to improve it is > file bug reports. I know you have to go through the lawyers - and I > can only imagine how much fun that must be - but I do wonder what the > difference is between IR (which accepts library contributions) and IP > (which doesn't). > > Is the plan to wait until the DLR is out of the IronPython tree, to > avoid any IP issues with it? Or is it, like most things, simply too > many things to do and not enough bodies? > > > > > The good news is there's no other surprises like this lurking - we've > generally > > been focused on 2.6, bugs, and startup perf - but ctypes is the #1 > feature > > request so it seemed worthy of working on it. > > > > Maybe we should add a 2.6 Plan page to the CodePlex site? ?I'm sure > there's more > > information than just what new features we expect to be included that > could > > go there. > > I think a listing of what's planned to 2.6 would be great - especially > the parts that aren't in 2.0 already. I assume all of the CPython 2.6 > features will be in there, but what are the holes in IPy 2.0 that 2.6 > is going to fill? Also, at least an estimated timeline - I've heard > 'fall' as an estimate, but something a little more concrete would be > nice :). > > - Jeff > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dfugate at microsoft.com Tue Apr 28 18:37:46 2009 From: dfugate at microsoft.com (Dave Fugate) Date: Tue, 28 Apr 2009 09:37:46 -0700 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: Hi Jeff, we really do appreciate the work you did on ctypes. Unfortunately, we would indeed not be able to (currently) take the contribution or even look at it due to legal concerns. I realize it's fairly frustrating not being able to contribute back to IronPython and being limited to filing bug reports. That said, there is something extremely useful the community can do for IronPython that our team simply cannot: get 3rd party Python applications such as Django, pywin32, NumPy, etc running under IronPython. This could mean adapting something like adodbapi.py to utilize IronPython APIs similar to what Vernon Cole did, or re-implementing NumPy's C-based modules in C#. While it's quite difficult (impossible?) for anyone on our team to submit changes supporting IronPython back to other OSS projects, the rest of the IronPython Community happily doesn't have this limitation. If anyone wants to contribute in this manner, please just give us a heads up so we can obtain permission to add tests for the 3rd party app(s) to our checkin system. Also, if there's enough interest in this I can setup a wiki page on CodePlex to keep track of whose working on what... Thanks, Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Monday, April 27, 2009 4:49 PM To: Discussion of IronPython Subject: Re: [IronPython] pywin32 on Iron Python? On Mon, Apr 27, 2009 at 1:30 PM, Dino Viehland wrote: > Sorry Jeff, you're right. ?I had started this a long time ago just as a fun thing > to hack on every now and then and it's recently gotten good enough that it seems > like it can make it into 2.6. ?So it's a bit of an oddball - even if we had a > place for me to claim that I was working on it it's doubtful that I would have > actually claimed it until about a week or two ago... That's about how I started, too (that, and I wanted to get the csvn bindings working), and about the same time I felt comfortable making it public. The problem as I see it is that you can't take any of the work I've done (on the off chance that my version has something novel ;)), and even once it's in the trunk, the only thing I can do to improve it is file bug reports. I know you have to go through the lawyers - and I can only imagine how much fun that must be - but I do wonder what the difference is between IR (which accepts library contributions) and IP (which doesn't). Is the plan to wait until the DLR is out of the IronPython tree, to avoid any IP issues with it? Or is it, like most things, simply too many things to do and not enough bodies? > > The good news is there's no other surprises like this lurking - we've generally > been focused on 2.6, bugs, and startup perf - but ctypes is the #1 feature > request so it seemed worthy of working on it. > > Maybe we should add a 2.6 Plan page to the CodePlex site? ?I'm sure there's more > information than just what new features we expect to be included that could > go there. I think a listing of what's planned to 2.6 would be great - especially the parts that aren't in 2.0 already. I assume all of the CPython 2.6 features will be in there, but what are the holes in IPy 2.0 that 2.6 is going to fill? Also, at least an estimated timeline - I've heard 'fall' as an estimate, but something a little more concrete would be nice :). - Jeff _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Tue Apr 28 19:35:42 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 28 Apr 2009 18:35:42 +0100 Subject: [IronPython] Telling .NET classes from Python objects Message-ID: <49F73E6E.4080308@voidspace.org.uk> Hello guys, I'm continuing my work on generating pi files for the Wing IDE. Actually everything I encounter will be a .NET type, but in general what is the best way of telling if an object is a .NET type or a Python type? Obviously for the primitives it is a moot point - but I'm talking about user defined classes. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From ivan at flanders.co.nz Tue Apr 28 19:38:29 2009 From: ivan at flanders.co.nz (Ivan Porto Carrero) Date: Tue, 28 Apr 2009 19:38:29 +0200 Subject: [IronPython] Telling .NET classes from Python objects In-Reply-To: <49F73E6E.4080308@voidspace.org.uk> References: <49F73E6E.4080308@voidspace.org.uk> Message-ID: +1 for this question only I need it to implement different binding strategies in IronMVC. IronRuby in Action (http://manning.com/carrero) Winston Churchill - "The best argument against democracy is a five-minute conversation with the average voter." On Tue, Apr 28, 2009 at 7:35 PM, Michael Foord wrote: > Hello guys, > > I'm continuing my work on generating pi files for the Wing IDE. Actually > everything I encounter will be a .NET type, but in general what is the best > way of telling if an object is a .NET type or a Python type? > > Obviously for the primitives it is a moot point - but I'm talking about > user defined classes. > > 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 dinov at microsoft.com Tue Apr 28 19:40:40 2009 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 28 Apr 2009 10:40:40 -0700 Subject: [IronPython] Telling .NET classes from Python objects In-Reply-To: References: <49F73E6E.4080308@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23555728B89C75@NA-EXMSG-C102.redmond.corp.microsoft.com> Check to see if the object implements IPythonObject. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ivan Porto Carrero Sent: Tuesday, April 28, 2009 10:38 AM To: Discussion of IronPython; ironruby-core Subject: Re: [IronPython] Telling .NET classes from Python objects +1 for this question only I need it to implement different binding strategies in IronMVC. IronRuby in Action (http://manning.com/carrero) Winston Churchill - "The best argument against democracy is a five-minute conversation with the average voter." On Tue, Apr 28, 2009 at 7:35 PM, Michael Foord > wrote: Hello guys, I'm continuing my work on generating pi files for the Wing IDE. Actually everything I encounter will be a .NET type, but in general what is the best way of telling if an object is a .NET type or a Python type? Obviously for the primitives it is a moot point - but I'm talking about user defined classes. 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 jdhardy at gmail.com Wed Apr 29 01:17:29 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 28 Apr 2009 17:17:29 -0600 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: <350E7D38B6D819428718949920EC23555728B89BBC@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B89BBC@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: On Tue, Apr 28, 2009 at 9:53 AM, Dino Viehland wrote: > The primary difference between IP and IR is just that IP is in the > lucky spot of getting to push things one step further. ?This just > reflects the reality that other teams within MS have taken a > dependency on IronPython (e.g. Robotics, Intellipad, and most recently > Navision - who knows what's next!). ?Therefore we get to fight the > next battle of not only taking back contributions but also then > redistributing those contributions as part of another MS product. ?So > it's no longer about just us or our peers working on the DLR :( Ah! I didn't know that. I can see how that would complicate things. You can't turn a supertanker on a dime, I guess. > I'll get started on a future releases plan page. ?Just as a teaser beta 1 > is about a month away. ?We are a little bit shy about announcing > a particular date - if we said 9/29/2009 or something and got it wrong > we'd feel a little bit silly. ?But we can at least give a better idea > of the road map (e.g. 2 betas, RC, then release sort of thing which is > the plan) rather than saying an indeterminate amount of releases and > we'll ship like we have in the past :) Just do what the Win7 team did a pick a date so far in the future you can't miss it. :) The ~15 2.0 prereleases may have been a bit much, but at least the releases were predictably every ~6 weeks. If you document how many prereleases you plan and how long your cycles are, I can do the multiplication. - Jeff From jdhardy at gmail.com Wed Apr 29 01:32:14 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 28 Apr 2009 17:32:14 -0600 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: Hi Dave, On Tue, Apr 28, 2009 at 10:37 AM, Dave Fugate wrote: > That said, there is something extremely useful the community can do for IronPython that our team simply cannot: ?get 3rd party Python applications such as Django, pywin32, NumPy, etc running under IronPython. ?This could mean adapting something like adodbapi.py to utilize IronPython APIs similar to what Vernon Cole did, or re-implementing NumPy's C-based modules in C#. ?While it's quite difficult (impossible?) for anyone on our team to submit changes supporting IronPython back to other OSS projects, the rest of the IronPython Community happily doesn't have this limitation. The problem with this approach is that I don't really want to clutter up e.g. Django with workarounds for IP bugs that are actually incompatibilities with CPython - they should and will get fixed in IP at some point. If it's a legitimate platform difference, or an invalid assumption by Django, then it can be fixed there - but I've found very few of those relative to bugs in IP itself. Also, would it possible for you guys to revisit your commit messages? I would at least like to see a note in the CP commit messages when a particular CP issue has been fixed. > > If anyone wants to contribute in this manner, please just give us a heads up so we can obtain permission to add tests for the 3rd party app(s) to our checkin system. ?Also, if there's enough interest in this I can setup a wiki page on CodePlex to keep track of whose working on what... Now this is interesting! Last time I checked, Django's test suite was nowhere near passing - would the full test suite have to pass before you'd include it? There's some notes at http://www.ironpython.info/index.php/Application_Compatibility (and associated pages) that I haven't kept up to date. I really appreciate the work you guys are doing here. It can't be easy swimming against the tide all the time! - Jeff From harriv at gmail.com Wed Apr 29 10:21:26 2009 From: harriv at gmail.com (Harriv) Date: Wed, 29 Apr 2009 11:21:26 +0300 Subject: [IronPython] "IDLE like" functionality Message-ID: Hi, A beginner's question: Is there a tutorial/demo/sample project to show how embed "IDLE like" functionality in C# WinForms application? So basically I'd like to add interactive command line to my application, but of course all other features of IDLE (eg debugging, code editors etc) must be left out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at resolversystems.com Wed Apr 29 13:30:31 2009 From: william at resolversystems.com (William Reade) Date: Wed, 29 Apr 2009 12:30:31 +0100 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49F83A57.4010108@resolversystems.com> Dave Fugate wrote: > That said, there is something extremely useful the community can do for IronPython that our team simply cannot: get 3rd party Python applications such as Django, pywin32, NumPy, etc running under IronPython. This could mean adapting something like adodbapi.py to utilize IronPython APIs similar to what Vernon Cole did, or re-implementing NumPy's C-based modules in C#. NumPy works pretty well already (under ironclad*). I suspect that in circumstances where managedness is so important that the CPython numpy can't be used, one would be better off using a preexisting .NET library than trying to rewrite parts of NumPy. Also, I just performed a quick test on pywin32 under ironclad and, once I added the 'pythonwin', 'win32', and 'win32\lib' folders from site-packages to sys.path, was able to call win32api.GetComputerName without problems. Not all of it will work, but see the numpy-related footnote below. Cheers william * and if it doesn't do what you need, or if what you need is too slow, please let me know and I'll do my best to fix it :-) From daftspaniel at gmail.com Wed Apr 29 13:35:39 2009 From: daftspaniel at gmail.com (Davy Mitchell) Date: Wed, 29 Apr 2009 12:35:39 +0100 Subject: [IronPython] "IDLE like" functionality In-Reply-To: References: Message-ID: <20253b0c0904290435q459f5887s63da4adb16b724ac@mail.gmail.com> Hi Harriv, You could start by looking at http://www.ironpython.info/index.php/Contents#Tools_and_Utilities There's a couple of web and desktop IronPython shells there. Davy On Wed, Apr 29, 2009 at 9:21 AM, Harriv wrote: > Hi, > ?A beginner's question: Is there a tutorial/demo/sample project to show how > embed "IDLE like" functionality in C# WinForms application? > ?So basically I'd like to add interactive command line to my application, > but of course all other features of IDLE (eg debugging, code editors etc) > must be left out. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From fuzzyman at voidspace.org.uk Wed Apr 29 13:44:24 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 29 Apr 2009 12:44:24 +0100 Subject: [IronPython] "IDLE like" functionality In-Reply-To: <20253b0c0904290435q459f5887s63da4adb16b724ac@mail.gmail.com> References: <20253b0c0904290435q459f5887s63da4adb16b724ac@mail.gmail.com> Message-ID: <49F83D98.9060608@voidspace.org.uk> Davy Mitchell wrote: > Hi Harriv, > > You could start by looking at > http://www.ironpython.info/index.php/Contents#Tools_and_Utilities > > There's a couple of web and desktop IronPython shells there. > There is also IronTextBox which is an IronPython console in a Windows Forms TextBox You will probably need to update it for 2.0.1 but it is probably what you want. http://www.codeproject.com/KB/edit/irontextbox2.aspx Michael > Davy > > On Wed, Apr 29, 2009 at 9:21 AM, Harriv wrote: > >> Hi, >> A beginner's question: Is there a tutorial/demo/sample project to show how >> embed "IDLE like" functionality in C# WinForms application? >> So basically I'd like to add interactive command line to my application, >> but of course all other features of IDLE (eg debugging, code editors etc) >> must be left out. >> _______________________________________________ >> 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/ From mbk.lists at gmail.com Wed Apr 29 15:19:17 2009 From: mbk.lists at gmail.com (Mike Krell) Date: Wed, 29 Apr 2009 06:19:17 -0700 Subject: [IronPython] sys._getframe(n)? Message-ID: Is it true that the dev team is considering implementing sys._getframe(n) where n > 0? I'd love to see this since my understanding is that this is a stumbling block for running IronPython under IPython. Is there an issue number on CodePlex on this that I can vote for? Thanks, Mike From vernondcole at gmail.com Wed Apr 29 15:19:31 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Wed, 29 Apr 2009 07:19:31 -0600 Subject: [IronPython] "IDLE like" functionality In-Reply-To: References: Message-ID: Actually, the code editor for IDLE (and pythonwin) is written in Python, so no, it does not have to be left out. Since pythonwin is a native WinForms application, it would be a great example project for how to do it. If pywin32 were ported to IronPython it would be done. On Wed, Apr 29, 2009 at 2:21 AM, Harriv wrote: > Hi, > ?A beginner's question: Is there a tutorial/demo/sample project to show how > embed "IDLE like" functionality in C# WinForms application? > ?So basically I'd like to add interactive command line to my application, > but of course all other features of IDLE (eg debugging, code editors etc) > must be left out. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From fuzzyman at voidspace.org.uk Wed Apr 29 15:24:18 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 29 Apr 2009 14:24:18 +0100 Subject: [IronPython] "IDLE like" functionality In-Reply-To: References: Message-ID: <49F85502.9040206@voidspace.org.uk> Vernon Cole wrote: > Actually, the code editor for IDLE (and pythonwin) is written in > Python, so no, it does not have to be left out. IDLE uses Tkinter - which theoretically *might* work under Ironclad but unless there is a managed version of Tk/Tcl no-one is likely to port it. > Since pythonwin is a > native WinForms application, PythonWin does not use Windows Forms it uses win32. Michael > it would be a great example project for > how to do it. If pywin32 were ported to IronPython it would be done. > > On Wed, Apr 29, 2009 at 2:21 AM, Harriv wrote: > >> Hi, >> A beginner's question: Is there a tutorial/demo/sample project to show how >> embed "IDLE like" functionality in C# WinForms application? >> So basically I'd like to add interactive command line to my application, >> but of course all other features of IDLE (eg debugging, code editors etc) >> must be left out. >> _______________________________________________ >> 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/ From curt at hagenlocher.org Wed Apr 29 15:32:51 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 29 Apr 2009 06:32:51 -0700 Subject: [IronPython] "IDLE like" functionality In-Reply-To: <49F85502.9040206@voidspace.org.uk> References: <49F85502.9040206@voidspace.org.uk> Message-ID: "Eagle" is a managed version of TCL (that's also hosted on Codeplex) but I doubt that the more-important Tk part is there :). On Wed, Apr 29, 2009 at 6:24 AM, Michael Foord wrote: > Vernon Cole wrote: > >> Actually, the code editor for IDLE (and pythonwin) is written in >> Python, so no, it does not have to be left out. >> > > IDLE uses Tkinter - which theoretically *might* work under Ironclad but > unless there is a managed version of Tk/Tcl no-one is likely to port it. > > Since pythonwin is a >> native WinForms application, >> > PythonWin does not use Windows Forms it uses win32. > > Michael > >> it would be a great example project for >> how to do it. If pywin32 were ported to IronPython it would be done. >> >> On Wed, Apr 29, 2009 at 2:21 AM, Harriv wrote: >> >> >>> Hi, >>> A beginner's question: Is there a tutorial/demo/sample project to show >>> how >>> embed "IDLE like" functionality in C# WinForms application? >>> So basically I'd like to add interactive command line to my application, >>> but of course all other features of IDLE (eg debugging, code editors etc) >>> must be left out. >>> _______________________________________________ >>> 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/ > > > _______________________________________________ > 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 vernondcole at gmail.com Wed Apr 29 16:33:50 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Wed, 29 Apr 2009 08:33:50 -0600 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: On Tue, Apr 28, 2009 at 5:32 PM, Jeff Hardy wrote: > Hi Dave, > > On Tue, Apr 28, 2009 at 10:37 AM, Dave Fugate wrote: >> That said, there is something extremely useful the community can do for IronPython that our team simply cannot: ?get 3rd party Python applications such as Django, pywin32, NumPy, etc running under IronPython. ?This could mean adapting something like adodbapi.py to utilize IronPython APIs similar to what Vernon Cole did, or re-implementing NumPy's C-based modules in C#. ?While it's quite difficult (impossible?) for anyone on our team to submit changes supporting IronPython back to other OSS projects, the rest of the IronPython Community happily doesn't have this limitation. > Dave: My condolences on having to put up with the lawyers. I have to sleep with one, but at least she doesn't tell me who I can contribute code to. ;-) -- VC > The problem with this approach is that I don't really want to clutter > up e.g. Django with workarounds for IP bugs that are actually > incompatibilities with CPython - they should and will get fixed in IP > at some point. If it's a legitimate platform difference, or an invalid > assumption by Django, then it can be fixed there - but I've found very > few of those relative to bugs in IP itself. That's true. There is still one outstanding bug in adodbapi on iron which I hope will eventually be fixed in IPy. (see Work Item # 18222 -- August 2008) The workaround was just too large to use and would still have left the IPy COM implementation with a bug. When the COM bug gets fixed that last test failure will go away. There are other places where "if IronPython:" made sense and was used. (I also included simple workarounds for bugs like #18223.) -- VC > Also, would it possible for you guys to revisit your commit messages? > I would at least like to see a note in the CP commit messages when a > particular CP issue has been fixed. + 1. Maybe my bug has already been fixed and I don't know. -- VC > >> >> If anyone wants to contribute in this manner, please just give us a heads up so we can obtain permission to add tests for the 3rd party app(s) to our checkin system. ?Also, if there's enough interest in this I can setup a wiki page on CodePlex to keep track of whose working on what... +1 on the wiki page. > > Now this is interesting! Last time I checked, Django's test suite was > nowhere near passing - would the full test suite have to pass before > you'd include it? In other words, how good do we have to get? > I really appreciate the work you guys are doing here. It can't be easy > swimming against the tide all the time! > > - Jeff Amen! -- VC From fuzzyman at voidspace.org.uk Wed Apr 29 16:44:48 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 29 Apr 2009 15:44:48 +0100 Subject: [IronPython] [wingide-users] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator) In-Reply-To: <49F64584.70207@voidspace.org.uk> References: <49F64584.70207@voidspace.org.uk> Message-ID: <49F867E0.5060807@voidspace.org.uk> Hello all, Attached is an updated script for generating PI files to provide autocomplete on standard .NET objects. It now handles all the standard .NET member types (including static properties, enumeration fields, indexers, events and so on). It also recurses into sub-namespaces generating new pi-files for all of them. This script is hardcoded to add references to, and then generate PI files for: System System.Data System.Drawing System.Windows.Forms It generates 90 pi files (90 namespaces) taking up 24mb! The autocomplete it provides is awesome though. :-) I had to do a fair bit of violence to the standard generate_pi.py script so I *doubt* it is desirable to merge it back in. Obviously very happy for this to be included with Wing if you want, or merged if you think it is worth it. Is it ok for me to offer this for download from my site? If I make further changes I will email this list. The big thing to add is the return type for methods. Is it possible to specify return types for properties? (Currently any attribute without an obvious parallel in Python I have turned into a property in the PI files). The only real caveat with the current script (that I am aware of - bug reports and contributions welcomed) is that None is a common enumeration field member. This is invalid syntax in Python, so I rename these to None_. There are quite a few minor changes sprinkled through the code - plus the __main__ part of the script is very different. I have tried to mark changes with a # CHANGE: comment, but it should be relatively amenable to diffing anyway... For reference I was using IronPython 2.0.1, with .NET 3.5 installed and Wing 3.2beta 1. All the best, Michael Foord Michael Foord wrote: > Hello all, > > I've created a modified version of the 'generate_pi.py' which > generates the interface files for .NET libraries. It is attached. > > At the moment it generates PI files for the following assemblies / > namespaces (hardwired at the bottom of the code): > > System > System.Data > System.Drawing > System.Windows.Forms > > To run it, create a new directory and add this to the 'Interface File > Path' (File menu -> Preferences -> Source Analysis -> Advanced -> > Insert). > > Then from the command line switch to this directory (if you are on > Vista you will need to run cmd with admin privileges due to a defect > explained below). Execute the command: > > ipy generate_pi_for_net.py > > This generates the pi files. It doesn't work *as well* on 64 bit > windows because the .NET XML help files (or whatever they are called) > are in a different location so the docstrings are not always available > - which is why I am not just distributing the pi files yet. > > The script doesn't yet understand static properties on classes - so it > actually *fetches* static properties rather than looking at the > descriptor (which is available in the class __dict__ so should be easy > to fix). This is what causes inadvertent registry lookups etc and > therefore requires admin privileges. > > It doesn't yet understand multiple overloads. This may require a > change to Wing or may not matter. > > It isn't yet able to do anything with the information about return > types - which would allow Wing to know the type of objects returned by > methods. This may be easy to add? > > It is late so I am going to bed. At some point I will explain the > simple changes I had to make to the standard generate_pi.py script > (although they are mostly straightforward). I will also do further > work on it as it will be very useful to me... > > All the best, > > Michael > > ------------------------------------------------------------------------ > > _________________________________________________ > Wing IDE users list > http://wingware.com/lists/wingide -- http://www.ironpythoninaction.com/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: generate_pi_for_net.py URL: From vernondcole at gmail.com Wed Apr 29 16:51:59 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Wed, 29 Apr 2009 08:51:59 -0600 Subject: [IronPython] "IDLE like" functionality In-Reply-To: <49F85502.9040206@voidspace.org.uk> References: <49F85502.9040206@voidspace.org.uk> Message-ID: On Wed, Apr 29, 2009 at 7:24 AM, Michael Foord wrote: > Vernon Cole wrote: >> >> Actually, the code editor for IDLE (and pythonwin) is written in >> Python, so no, it does not have to be left out. > >> ?Since pythonwin is a >> native WinForms application, > > PythonWin does not use Windows Forms it uses win32. > > Michael >> Errr, Ummm, I didn't know there was a difference. Please educate me. (supply links if helpful) The longer I spend in this industry, the more I discover I don't know. -- VC From lukas.cenovsky at radiantsystems.com Wed Apr 29 16:57:10 2009 From: lukas.cenovsky at radiantsystems.com (Cenovsky, Lukas) Date: Wed, 29 Apr 2009 10:57:10 -0400 Subject: [IronPython] [wingide-users] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator) In-Reply-To: <49F867E0.5060807@voidspace.org.uk> References: <49F64584.70207@voidspace.org.uk> <49F867E0.5060807@voidspace.org.uk> Message-ID: Would be nice to have something similar for vim :-) -- -- Lukas > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Wednesday, April 29, 2009 4:45 PM > To: Wing Users > Cc: Discussion of IronPython > Subject: Re: [IronPython] [wingide-users] Using Wing IDE with > IronPython - autocomplete for .NET objects (PI file generator) > > Hello all, > > Attached is an updated script for generating PI files to provide > autocomplete on standard .NET objects. > > It now handles all the standard .NET member types (including static > properties, enumeration fields, indexers, events and so on). > > It also recurses into sub-namespaces generating new pi-files > for all of > them. > > This script is hardcoded to add references to, and then generate PI > files for: > > System > System.Data > System.Drawing > System.Windows.Forms > > It generates 90 pi files (90 namespaces) taking up 24mb! The > autocomplete it provides is awesome though. :-) > > I had to do a fair bit of violence to the standard > generate_pi.py script > so I *doubt* it is desirable to merge it back in. Obviously > very happy > for this to be included with Wing if you want, or merged if > you think it > is worth it. Is it ok for me to offer this for download from > my site? If > I make further changes I will email this list. > > The big thing to add is the return type for methods. > > Is it possible to specify return types for properties? (Currently any > attribute without an obvious parallel in Python I have turned into a > property in the PI files). > > The only real caveat with the current script (that I am aware > of - bug > reports and contributions welcomed) is that None is a common > enumeration > field member. This is invalid syntax in Python, so I rename > these to None_. > > There are quite a few minor changes sprinkled through the code - plus > the __main__ part of the script is very different. I have > tried to mark > changes with a # CHANGE: comment, but it should be relatively > amenable > to diffing anyway... > > For reference I was using IronPython 2.0.1, with .NET 3.5 > installed and > Wing 3.2beta 1. > > All the best, > > Michael Foord > > Michael Foord wrote: > > Hello all, > > > > I've created a modified version of the 'generate_pi.py' which > > generates the interface files for .NET libraries. It is attached. > > > > At the moment it generates PI files for the following assemblies / > > namespaces (hardwired at the bottom of the code): > > > > System > > System.Data > > System.Drawing > > System.Windows.Forms > > > > To run it, create a new directory and add this to the > 'Interface File > > Path' (File menu -> Preferences -> Source Analysis -> Advanced -> > > Insert). > > > > Then from the command line switch to this directory (if you are on > > Vista you will need to run cmd with admin privileges due to > a defect > > explained below). Execute the command: > > > > ipy generate_pi_for_net.py > > > > This generates the pi files. It doesn't work *as well* on 64 bit > > windows because the .NET XML help files (or whatever they > are called) > > are in a different location so the docstrings are not > always available > > - which is why I am not just distributing the pi files yet. > > > > The script doesn't yet understand static properties on > classes - so it > > actually *fetches* static properties rather than looking at the > > descriptor (which is available in the class __dict__ so > should be easy > > to fix). This is what causes inadvertent registry lookups etc and > > therefore requires admin privileges. > > > > It doesn't yet understand multiple overloads. This may require a > > change to Wing or may not matter. > > > > It isn't yet able to do anything with the information about return > > types - which would allow Wing to know the type of objects > returned by > > methods. This may be easy to add? > > > > It is late so I am going to bed. At some point I will explain the > > simple changes I had to make to the standard generate_pi.py script > > (although they are mostly straightforward). I will also do further > > work on it as it will be very useful to me... > > > > All the best, > > > > Michael > > > > > -------------------------------------------------------------- > ---------- > > > > _________________________________________________ > > Wing IDE users list > > http://wingware.com/lists/wingide > > > -- > http://www.ironpythoninaction.com/ > > From fuzzyman at voidspace.org.uk Wed Apr 29 16:58:19 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 29 Apr 2009 15:58:19 +0100 Subject: [IronPython] "IDLE like" functionality In-Reply-To: References: <49F85502.9040206@voidspace.org.uk> Message-ID: <49F86B0B.8080103@voidspace.org.uk> Vernon Cole wrote: > On Wed, Apr 29, 2009 at 7:24 AM, Michael Foord > wrote: > >> Vernon Cole wrote: >> >>> Actually, the code editor for IDLE (and pythonwin) is written in >>> Python, so no, it does not have to be left out. >>> >>> Since pythonwin is a >>> native WinForms application, >>> >> PythonWin does not use Windows Forms it uses win32. >> >> Michael >> > > Errr, Ummm, I didn't know there was a difference. > Please educate me. (supply links if helpful) > The longer I spend in this industry, the more I discover I don't know. > Windows Forms is .NET functionality layered on top of the Win32 APIs (using User32.dll, GDI+ etc). It introduces new controls and a whole programming model on top of those primitives. Pywin32 provides direct access to win32 and has nothing to do with Windows Forms. There are other complications with MFC (I've always assumed that was just a strict subset of what is loosely termed win32 - but I am playing fast and loose with terminology here). All the best, Michael Foord > -- > VC > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From fuzzyman at voidspace.org.uk Wed Apr 29 16:58:40 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 29 Apr 2009 15:58:40 +0100 Subject: [IronPython] [wingide-users] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator) In-Reply-To: References: <49F64584.70207@voidspace.org.uk> <49F867E0.5060807@voidspace.org.uk> Message-ID: <49F86B20.5020206@voidspace.org.uk> Cenovsky, Lukas wrote: > Would be nice to have something similar for vim :-) > > Go for it. :-) Michael > -- > -- Lukas > > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com >> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Wednesday, April 29, 2009 4:45 PM >> To: Wing Users >> Cc: Discussion of IronPython >> Subject: Re: [IronPython] [wingide-users] Using Wing IDE with >> IronPython - autocomplete for .NET objects (PI file generator) >> >> Hello all, >> >> Attached is an updated script for generating PI files to provide >> autocomplete on standard .NET objects. >> >> It now handles all the standard .NET member types (including static >> properties, enumeration fields, indexers, events and so on). >> >> It also recurses into sub-namespaces generating new pi-files >> for all of >> them. >> >> This script is hardcoded to add references to, and then generate PI >> files for: >> >> System >> System.Data >> System.Drawing >> System.Windows.Forms >> >> It generates 90 pi files (90 namespaces) taking up 24mb! The >> autocomplete it provides is awesome though. :-) >> >> I had to do a fair bit of violence to the standard >> generate_pi.py script >> so I *doubt* it is desirable to merge it back in. Obviously >> very happy >> for this to be included with Wing if you want, or merged if >> you think it >> is worth it. Is it ok for me to offer this for download from >> my site? If >> I make further changes I will email this list. >> >> The big thing to add is the return type for methods. >> >> Is it possible to specify return types for properties? (Currently any >> attribute without an obvious parallel in Python I have turned into a >> property in the PI files). >> >> The only real caveat with the current script (that I am aware >> of - bug >> reports and contributions welcomed) is that None is a common >> enumeration >> field member. This is invalid syntax in Python, so I rename >> these to None_. >> >> There are quite a few minor changes sprinkled through the code - plus >> the __main__ part of the script is very different. I have >> tried to mark >> changes with a # CHANGE: comment, but it should be relatively >> amenable >> to diffing anyway... >> >> For reference I was using IronPython 2.0.1, with .NET 3.5 >> installed and >> Wing 3.2beta 1. >> >> All the best, >> >> Michael Foord >> >> Michael Foord wrote: >> >>> Hello all, >>> >>> I've created a modified version of the 'generate_pi.py' which >>> generates the interface files for .NET libraries. It is attached. >>> >>> At the moment it generates PI files for the following assemblies / >>> namespaces (hardwired at the bottom of the code): >>> >>> System >>> System.Data >>> System.Drawing >>> System.Windows.Forms >>> >>> To run it, create a new directory and add this to the >>> >> 'Interface File >> >>> Path' (File menu -> Preferences -> Source Analysis -> Advanced -> >>> Insert). >>> >>> Then from the command line switch to this directory (if you are on >>> Vista you will need to run cmd with admin privileges due to >>> >> a defect >> >>> explained below). Execute the command: >>> >>> ipy generate_pi_for_net.py >>> >>> This generates the pi files. It doesn't work *as well* on 64 bit >>> windows because the .NET XML help files (or whatever they >>> >> are called) >> >>> are in a different location so the docstrings are not >>> >> always available >> >>> - which is why I am not just distributing the pi files yet. >>> >>> The script doesn't yet understand static properties on >>> >> classes - so it >> >>> actually *fetches* static properties rather than looking at the >>> descriptor (which is available in the class __dict__ so >>> >> should be easy >> >>> to fix). This is what causes inadvertent registry lookups etc and >>> therefore requires admin privileges. >>> >>> It doesn't yet understand multiple overloads. This may require a >>> change to Wing or may not matter. >>> >>> It isn't yet able to do anything with the information about return >>> types - which would allow Wing to know the type of objects >>> >> returned by >> >>> methods. This may be easy to add? >>> >>> It is late so I am going to bed. At some point I will explain the >>> simple changes I had to make to the standard generate_pi.py script >>> (although they are mostly straightforward). I will also do further >>> work on it as it will be very useful to me... >>> >>> All the best, >>> >>> Michael >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >> >>> _________________________________________________ >>> Wing IDE users list >>> http://wingware.com/lists/wingide >>> >> -- >> http://www.ironpythoninaction.com/ >> >> >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From daftspaniel at gmail.com Wed Apr 29 17:21:12 2009 From: daftspaniel at gmail.com (Davy Mitchell) Date: Wed, 29 Apr 2009 16:21:12 +0100 Subject: [IronPython] "IDLE like" functionality In-Reply-To: <49F86B0B.8080103@voidspace.org.uk> References: <49F85502.9040206@voidspace.org.uk> <49F86B0B.8080103@voidspace.org.uk> Message-ID: <20253b0c0904290821u58d97d52o9a685bc29add4aa@mail.gmail.com> MFC is a C++ wrapper for Win32. Made it more OO. Ah takes me back :-) !! Cheers, Davy From dinov at microsoft.com Wed Apr 29 17:33:31 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 29 Apr 2009 08:33:31 -0700 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <350E7D38B6D819428718949920EC23555728B8A052@NA-EXMSG-C102.redmond.corp.microsoft.com> On 18222 - I think ctypes will drive some changes to our buffer support making it more real. Right now it's close to useless :) There is some way for us to make types marshalable via COM ourselves so I think we'll be able to fix it eventually. I'm surprised that it's more of a problem than 18223 though. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Vernon Cole > Sent: Wednesday, April 29, 2009 7:34 AM > To: Discussion of IronPython > Subject: Re: [IronPython] pywin32 on Iron Python? > > On Tue, Apr 28, 2009 at 5:32 PM, Jeff Hardy wrote: > > Hi Dave, > > > > On Tue, Apr 28, 2009 at 10:37 AM, Dave Fugate > wrote: > >> That said, there is something extremely useful the community can do > for IronPython that our team simply cannot: ?get 3rd party Python > applications such as Django, pywin32, NumPy, etc running under > IronPython. ?This could mean adapting something like adodbapi.py to > utilize IronPython APIs similar to what Vernon Cole did, or re- > implementing NumPy's C-based modules in C#. ?While it's quite difficult > (impossible?) for anyone on our team to submit changes supporting > IronPython back to other OSS projects, the rest of the IronPython > Community happily doesn't have this limitation. > > > Dave: > My condolences on having to put up with the lawyers. I have to sleep > with one, but at least she doesn't tell me who I can contribute code > to. ;-) > -- VC > > > The problem with this approach is that I don't really want to clutter > > up e.g. Django with workarounds for IP bugs that are actually > > incompatibilities with CPython - they should and will get fixed in IP > > at some point. If it's a legitimate platform difference, or an > invalid > > assumption by Django, then it can be fixed there - but I've found > very > > few of those relative to bugs in IP itself. > > That's true. There is still one outstanding bug in adodbapi on iron > which I hope will eventually be fixed in IPy. (see Work Item # 18222 > -- August 2008) The workaround was just too large to use and would > still have left the IPy COM implementation with a bug. When the COM > bug gets fixed that last test failure will go away. There are other > places where "if IronPython:" made sense and was used. (I also > included simple workarounds for bugs like #18223.) > -- VC > > > Also, would it possible for you guys to revisit your commit messages? > > I would at least like to see a note in the CP commit messages when a > > particular CP issue has been fixed. > > + 1. Maybe my bug has already been fixed and I don't know. > -- VC > > > > >> > >> If anyone wants to contribute in this manner, please just give us a > heads up so we can obtain permission to add tests for the 3rd party > app(s) to our checkin system. ?Also, if there's enough interest in this > I can setup a wiki page on CodePlex to keep track of whose working on > what... > > +1 on the wiki page. > > > > Now this is interesting! Last time I checked, Django's test suite was > > nowhere near passing - would the full test suite have to pass before > > you'd include it? > > In other words, how good do we have to get? > > > I really appreciate the work you guys are doing here. It can't be > easy > > swimming against the tide all the time! > > > > - Jeff > Amen! > -- VC > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Wed Apr 29 17:34:38 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 29 Apr 2009 08:34:38 -0700 Subject: [IronPython] sys._getframe(n)? In-Reply-To: References: Message-ID: <350E7D38B6D819428718949920EC23555728B8A053@NA-EXMSG-C102.redmond.corp.microsoft.com> Yep, we're going to make it available via a command line option. The Interesting question is what does IPython need from frames? Does it need locals (which frequently won't be available), globals, the function or code, or something else? I think bug 1042 is the one to vote on: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=1042 > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Mike Krell > Sent: Wednesday, April 29, 2009 6:19 AM > To: Users at lists.ironpython.com > Subject: [IronPython] sys._getframe(n)? > > Is it true that the dev team is considering implementing > sys._getframe(n) where n > 0? I'd love to see this since my > understanding is that this is a stumbling block for running IronPython > under IPython. > > Is there an issue number on CodePlex on this that I can vote for? > > Thanks, > Mike > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Wed Apr 29 18:42:03 2009 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Thu, 30 Apr 2009 01:42:03 +0900 Subject: [IronPython] Running Scripts/generate.py on CPython Message-ID: <5b0248170904290942v8b49616r7a9a5e91c260d030@mail.gmail.com> Scripts/generate.py has a comment: "TODO: does it make sense to run this under CPython?". I think so. The following is how I did that: 1. Delete "import nt" at the top. It is imported later anyway. 2. Change root_dir and source_directories. (Because source layout is different, but change is easy.) 3. Uncomment lines under "TODO: does it make sense..." 4. Define basename as os.path.basename and System.IO.Path.GetFileName just like isdir. Use it later. Maybe change 1 and 4 can be made on IronPython? Also change code_text += "\n" to "\r\n" if you want to avoid line ending difference. -- Seo Sanghyeon From dfugate at microsoft.com Wed Apr 29 18:55:52 2009 From: dfugate at microsoft.com (Dave Fugate) Date: Wed, 29 Apr 2009 09:55:52 -0700 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: The technical bar for inclusion of 3rd party tests into our checkin system is pretty simple - the test process needs to emit a non-zero exit code when it fails. When some portion of a test fails under IronPython for whatever reason, we simply disable that portion. For example, we run around 200 CPython 2.6 test_*.py files for every IronPython checkin with roughly a thousand individual test cases in these modules disabled. With this in mind, it likely doesn't matter that most of Django's test suite does not pass => we can disable the broken stuff. As for inclusion of commit messages in the CodePlex source synchs, we'll look into this. It's a bit challenging as sometimes we work on getting IronPython running against/with the latest unannounced Microsoft technology (e.g., we had IronPython running under Silverlight months before Silverlight was publically announced) and this is often reflected in our checkin comments. Thanks, Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Vernon Cole Sent: Wednesday, April 29, 2009 7:34 AM To: Discussion of IronPython Subject: Re: [IronPython] pywin32 on Iron Python? On Tue, Apr 28, 2009 at 5:32 PM, Jeff Hardy wrote: > Hi Dave, > > On Tue, Apr 28, 2009 at 10:37 AM, Dave Fugate wrote: >> That said, there is something extremely useful the community can do for IronPython that our team simply cannot: ?get 3rd party Python applications such as Django, pywin32, NumPy, etc running under IronPython. ?This could mean adapting something like adodbapi.py to utilize IronPython APIs similar to what Vernon Cole did, or re-implementing NumPy's C-based modules in C#. ?While it's quite difficult (impossible?) for anyone on our team to submit changes supporting IronPython back to other OSS projects, the rest of the IronPython Community happily doesn't have this limitation. > Dave: My condolences on having to put up with the lawyers. I have to sleep with one, but at least she doesn't tell me who I can contribute code to. ;-) -- VC > The problem with this approach is that I don't really want to clutter > up e.g. Django with workarounds for IP bugs that are actually > incompatibilities with CPython - they should and will get fixed in IP > at some point. If it's a legitimate platform difference, or an invalid > assumption by Django, then it can be fixed there - but I've found very > few of those relative to bugs in IP itself. That's true. There is still one outstanding bug in adodbapi on iron which I hope will eventually be fixed in IPy. (see Work Item # 18222 -- August 2008) The workaround was just too large to use and would still have left the IPy COM implementation with a bug. When the COM bug gets fixed that last test failure will go away. There are other places where "if IronPython:" made sense and was used. (I also included simple workarounds for bugs like #18223.) -- VC > Also, would it possible for you guys to revisit your commit messages? > I would at least like to see a note in the CP commit messages when a > particular CP issue has been fixed. + 1. Maybe my bug has already been fixed and I don't know. -- VC > >> >> If anyone wants to contribute in this manner, please just give us a heads up so we can obtain permission to add tests for the 3rd party app(s) to our checkin system. ?Also, if there's enough interest in this I can setup a wiki page on CodePlex to keep track of whose working on what... +1 on the wiki page. > > Now this is interesting! Last time I checked, Django's test suite was > nowhere near passing - would the full test suite have to pass before > you'd include it? In other words, how good do we have to get? > I really appreciate the work you guys are doing here. It can't be easy > swimming against the tide all the time! > > - Jeff Amen! -- VC _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Wed Apr 29 19:47:30 2009 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Thu, 30 Apr 2009 02:47:30 +0900 Subject: [IronPython] Expression printing in interactive mode Message-ID: <5b0248170904291047j2857619fn8ee0223573f1d358@mail.gmail.com> In changeset 42603, a change was made to IronPython.Hosting.PythonCommandLine.RunOneInteraction, - SourceUnit su = Language.CreateSnippet(s, "", SourceCodeKind.InteractiveCode); + SourceUnit su = Language.CreateSnippet(s, "", (s.Contains(Environment.NewLine))? SourceCodeKind.Statements : SourceCodeKind.InteractiveCode); Why is this? It seems to me that s always contains newline, so its net effect is making all interactive code non-interactive. In Python, this means no expression is printed in interactive mode. -- Seo Sanghyeon From dinov at microsoft.com Wed Apr 29 20:13:12 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 29 Apr 2009 11:13:12 -0700 Subject: [IronPython] Expression printing in interactive mode In-Reply-To: <5b0248170904291047j2857619fn8ee0223573f1d358@mail.gmail.com> References: <5b0248170904291047j2857619fn8ee0223573f1d358@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23555728B8A15A@NA-EXMSG-C102.redmond.corp.microsoft.com> There was some internal work going on w/ running a remote console and it looks like this change was related to that. In Microsoft.Scripting.Hosting.Shell there's a comment added to its RunOneInteraction w/ the same change: /// We check if the code read is an interactive command or statements is by checking for NewLine /// If the code contains NewLine, it's a set of statements (most probably from SendToConsole) /// If the code does not contain a NewLine, it's an interactive command typed by the user at the prompt Looking at the code thought I'm guessing this is totally broken on Unix because in ReadStatement we append a newline, with a wonderful comment there: // Note that this does not use Environment.NewLine because some languages (eg. Python) only // recognize \n as a line terminator. b.Append("\n"); So this just happens to do the right thing on Windows due to the mismatches between the new lines being used. I guess we should actually be checking for more than one "\n". > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon > Sent: Wednesday, April 29, 2009 10:48 AM > To: Discussion of IronPython > Subject: [IronPython] Expression printing in interactive mode > > In changeset 42603, a change was made to > IronPython.Hosting.PythonCommandLine.RunOneInteraction, > > - SourceUnit su = Language.CreateSnippet(s, "", > SourceCodeKind.InteractiveCode); > + SourceUnit su = Language.CreateSnippet(s, "", > (s.Contains(Environment.NewLine))? SourceCodeKind.Statements : > SourceCodeKind.InteractiveCode); > > Why is this? It seems to me that s always contains newline, so its net > effect is making all interactive code non-interactive. In Python, this > means no expression is printed in interactive mode. > > -- > Seo Sanghyeon > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Wed Apr 29 20:19:27 2009 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Thu, 30 Apr 2009 03:19:27 +0900 Subject: [IronPython] Expression printing in interactive mode In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A15A@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <5b0248170904291047j2857619fn8ee0223573f1d358@mail.gmail.com> <350E7D38B6D819428718949920EC23555728B8A15A@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <5b0248170904291119j26657d8clb07a380cdef46db1@mail.gmail.com> 2009/4/30 Dino Viehland : > Looking at the code thought I'm guessing this is totally broken on > Unix because in ReadStatement we append a newline, with a > wonderful comment there: > > ? ? ? ? ? ? ? ?// Note that this does not use Environment.NewLine because some languages (eg. Python) only > ? ? ? ? ? ? ? ?// recognize \n as a line terminator. > ? ? ? ? ? ? ? ?b.Append("\n"); > > So this just happens to do the right thing on Windows due to the > mismatches between the new lines being used. Ah, mystery solved. So it worked by accident on systems where NewLine != \n... -- Seo Sanghyeon From dinov at microsoft.com Wed Apr 29 20:19:20 2009 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 29 Apr 2009 11:19:20 -0700 Subject: [IronPython] Expression printing in interactive mode In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A15A@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <5b0248170904291047j2857619fn8ee0223573f1d358@mail.gmail.com> <350E7D38B6D819428718949920EC23555728B8A15A@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <350E7D38B6D819428718949920EC23555728B8A167@NA-EXMSG-C102.redmond.corp.microsoft.com> Actually now that I think about it more than one \n isn't right either because that will change how we parse multi-line statements at the REPL. Maybe this should just be undone. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Wednesday, April 29, 2009 11:13 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Expression printing in interactive mode > > There was some internal work going on w/ running a remote console > and it looks like this change was related to that. In > Microsoft.Scripting.Hosting.Shell there's a comment added to its > RunOneInteraction w/ the same change: > > /// We check if the code read is an interactive command or > statements is by checking for NewLine > /// If the code contains NewLine, it's a set of statements > (most probably from SendToConsole) > /// If the code does not contain a NewLine, it's an interactive > command typed by the user at the prompt > > Looking at the code thought I'm guessing this is totally broken on > Unix because in ReadStatement we append a newline, with a > wonderful comment there: > > // Note that this does not use Environment.NewLine > because some languages (eg. Python) only > // recognize \n as a line terminator. > b.Append("\n"); > > So this just happens to do the right thing on Windows due to the > mismatches between the new lines being used. > > I guess we should actually be checking for more than one "\n". > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon > > Sent: Wednesday, April 29, 2009 10:48 AM > > To: Discussion of IronPython > > Subject: [IronPython] Expression printing in interactive mode > > > > In changeset 42603, a change was made to > > IronPython.Hosting.PythonCommandLine.RunOneInteraction, > > > > - SourceUnit su = Language.CreateSnippet(s, "", > > SourceCodeKind.InteractiveCode); > > + SourceUnit su = Language.CreateSnippet(s, "", > > (s.Contains(Environment.NewLine))? SourceCodeKind.Statements : > > SourceCodeKind.InteractiveCode); > > > > Why is this? It seems to me that s always contains newline, so its > net > > effect is making all interactive code non-interactive. In Python, > this > > means no expression is printed in interactive mode. > > > > -- > > Seo Sanghyeon > > _______________________________________________ > > 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 vernondcole at gmail.com Wed Apr 29 20:31:56 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Wed, 29 Apr 2009 12:31:56 -0600 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: When we make a major effort to make IPy work with a third party package, how shall we clue you to re-enable the tests? An announcement on this forum, or what? -- Vernon On Wed, Apr 29, 2009 at 10:55 AM, Dave Fugate wrote: > The technical bar for inclusion of 3rd party tests into our checkin system is pretty simple - the test process needs to emit a non-zero exit code when it fails. ?When some portion of a test fails under IronPython for whatever reason, we simply disable that portion. ?For example, we run around 200 CPython 2.6 test_*.py files for every IronPython checkin with roughly a thousand individual test cases in these modules disabled. ?With this in mind, it likely doesn't matter that most of Django's test suite does not pass => we can disable the broken stuff. > > As for inclusion of commit messages in the CodePlex source synchs, we'll look into this. ?It's a bit challenging as sometimes we work on getting IronPython running against/with the latest unannounced Microsoft technology (e.g., we had IronPython running under Silverlight months before Silverlight was publically announced) and this is often reflected in our checkin comments. > > Thanks, > > Dave > > From fuzzyman at voidspace.org.uk Wed Apr 29 20:32:49 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 29 Apr 2009 19:32:49 +0100 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <2FEF064E-504B-4452-8071-645118F678FA@voidspace.org.uk> -- http://www.ironpythoninaction.com On 29 Apr 2009, at 17:55, Dave Fugate wrote: > The technical bar for inclusion of 3rd party tests into our checkin > system is pretty simple - the test process needs to emit a non-zero > exit code when it fails. When some portion of a test fails under > IronPython for whatever reason, we simply disable that portion. For > example, we run around 200 CPython 2.6 test_*.py files for every > IronPython checkin with roughly a thousand individual test cases in > these modules disabled. With this in mind, it likely doesn't matter > that most of Django's test suite does not pass => we can disable the > broken stuff. > > As for inclusion of commit messages in the CodePlex source synchs, > we'll look into this. It's a bit challenging as sometimes we work > on getting IronPython running against/with the latest unannounced > Microsoft technology (e.g., we had IronPython running under > Silverlight months before Silverlight was publically announced) and > this is often reflected in our checkin comments. > I can't believe that editing / redacting commit messages is an impossible challenge. :-) It really would be very useful. Michael > Thanks, > > Dave > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com > ] On Behalf Of Vernon Cole > Sent: Wednesday, April 29, 2009 7:34 AM > To: Discussion of IronPython > Subject: Re: [IronPython] pywin32 on Iron Python? > > On Tue, Apr 28, 2009 at 5:32 PM, Jeff Hardy wrote: >> Hi Dave, >> >> On Tue, Apr 28, 2009 at 10:37 AM, Dave Fugate >> wrote: >>> That said, there is something extremely useful the community can >>> do for IronPython that our team simply cannot: get 3rd party >>> Python applications such as Django, pywin32, NumPy, etc running >>> under IronPython. This could mean adapting something like >>> adodbapi.py to utilize IronPython APIs similar to what Vernon Cole >>> did, or re-implementing NumPy's C-based modules in C#. While it's >>> quite difficult (impossible?) for anyone on our team to submit >>> changes supporting IronPython back to other OSS projects, the rest >>> of the IronPython Community happily doesn't have this limitation. >> > Dave: > My condolences on having to put up with the lawyers. I have to sleep > with one, but at least she doesn't tell me who I can contribute code > to. ;-) > -- VC > >> The problem with this approach is that I don't really want to clutter >> up e.g. Django with workarounds for IP bugs that are actually >> incompatibilities with CPython - they should and will get fixed in IP >> at some point. If it's a legitimate platform difference, or an >> invalid >> assumption by Django, then it can be fixed there - but I've found >> very >> few of those relative to bugs in IP itself. > > That's true. There is still one outstanding bug in adodbapi on iron > which I hope will eventually be fixed in IPy. (see Work Item # 18222 > -- August 2008) The workaround was just too large to use and would > still have left the IPy COM implementation with a bug. When the COM > bug gets fixed that last test failure will go away. There are other > places where "if IronPython:" made sense and was used. (I also > included simple workarounds for bugs like #18223.) > -- VC > >> Also, would it possible for you guys to revisit your commit messages? >> I would at least like to see a note in the CP commit messages when a >> particular CP issue has been fixed. > > + 1. Maybe my bug has already been fixed and I don't know. > -- VC > >> >>> >>> If anyone wants to contribute in this manner, please just give us >>> a heads up so we can obtain permission to add tests for the 3rd >>> party app(s) to our checkin system. Also, if there's enough >>> interest in this I can setup a wiki page on CodePlex to keep track >>> of whose working on what... > > +1 on the wiki page. >> >> Now this is interesting! Last time I checked, Django's test suite was >> nowhere near passing - would the full test suite have to pass before >> you'd include it? > > In other words, how good do we have to get? > >> I really appreciate the work you guys are doing here. It can't be >> easy >> swimming against the tide all the time! >> >> - Jeff > Amen! > -- VC > _______________________________________________ > 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 jdhardy at gmail.com Wed Apr 29 20:37:24 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Wed, 29 Apr 2009 12:37:24 -0600 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: On Wed, Apr 29, 2009 at 10:55 AM, Dave Fugate wrote: > The technical bar for inclusion of 3rd party tests into our checkin system is pretty simple - the test process needs to emit a non-zero exit code when it fails. ?When some portion of a test fails under IronPython for whatever reason, we simply disable that portion. ?For example, we run around 200 CPython 2.6 test_*.py files for every IronPython checkin with roughly a thousand individual test cases in these modules disabled. ?With this in mind, it likely doesn't matter that most of Django's test suite does not pass => we can disable the broken stuff. In the case of Django, many of the tests depnd on a database. Is there anyway for you guys to handle that, or would you only be able to run the tests that don't need a db? You could use SQLite, but that requires an sqlite module, and you're back into 3rd party code again. > > As for inclusion of commit messages in the CodePlex source synchs, we'll look into this. ?It's a bit challenging as sometimes we work on getting IronPython running against/with the latest unannounced Microsoft technology (e.g., we had IronPython running under Silverlight months before Silverlight was publically announced) and this is often reflected in our checkin comments. My thought was that anything safe for public consumption could be prefixed with "cp:"(or whatever), but that might depend on how much munging there is between your internal repo and Codeplex. Or you could work off the Codeplex repo for real, and use a seperate one for the sekrit stuff :). - Jeff From sanxiyn at gmail.com Wed Apr 29 20:40:17 2009 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Thu, 30 Apr 2009 03:40:17 +0900 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: <2FEF064E-504B-4452-8071-645118F678FA@voidspace.org.uk> References: <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> <2FEF064E-504B-4452-8071-645118F678FA@voidspace.org.uk> Message-ID: <5b0248170904291140l3beadd81m4c1ddb2293b3d381@mail.gmail.com> 2009/4/30 Michael Foord : > I can't believe that editing / redacting commit messages is an impossible > challenge. :-) No, but *automating* editing/redacting commit message will be well nigh impossible challenge. :( -- Seo Sanghyeon From vernondcole at gmail.com Wed Apr 29 20:57:47 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Wed, 29 Apr 2009 12:57:47 -0600 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A052@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49F5D80E.6080609@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B8A052@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: On Wed, Apr 29, 2009 at 9:33 AM, Dino Viehland wrote: > On 18222 - I think ctypes will drive some changes to our buffer support > making it more real. ?Right now it's close to useless :) ?There is some > way for us to make types marshalable via COM ourselves so I think > we'll be able to fix it eventually. ?I'm surprised that it's more of > a problem than 18223 though. > As Jeff said, it's a question of cluttering up the code. pywin32 C code does a lot of work converting Python objects into/from COM compatible types. IronPython COM calls do not have the extra layer of help. For example, in adodbapi the workaround for 18223 is: elif isinstance(elem, longType) and onIronPython: # Iron Python Long s = SystemDecimal(elem) # feature workaround for IPy 2.0 p.Value = s else: p.Value=elem Note that when converted to Python 3, this effectively becomes: elif isinstance(elem, int) and onIronPython: # Iron Python integer s = SystemDecimal(elem) # feature workaround for IPy 2.0 p.Value = s else: p.Value=elem so that ALL integers will be run thru SystemDecimal before use as a COM parameter. Clearly this will need to be fixed before IronPython 3.0... -- Vernon From fuzzyman at voidspace.org.uk Wed Apr 29 21:24:06 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 29 Apr 2009 20:24:06 +0100 Subject: [IronPython] pywin32 on Iron Python? In-Reply-To: <5b0248170904291140l3beadd81m4c1ddb2293b3d381@mail.gmail.com> References: <350E7D38B6D819428718949920EC23555728B8986C@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B898CF@NA-EXMSG-C102.redmond.corp.microsoft.com> <2FEF064E-504B-4452-8071-645118F678FA@voidspace.org.uk> <5b0248170904291140l3beadd81m4c1ddb2293b3d381@mail.gmail.com> Message-ID: <18B29A9F-860B-40D9-9CFC-1852DD4F0071@voidspace.org.uk> -- http://www.ironpythoninaction.com On 29 Apr 2009, at 19:40, Seo Sanghyeon wrote: > 2009/4/30 Michael Foord : >> I can't believe that editing / redacting commit messages is an >> impossible >> challenge. :-) > > No, but *automating* editing/redacting commit message will be well > nigh > impossible challenge. :( Coming up with a scheme so that non-public information can be automatically trimmed shouldn't be an impossible challenge. Even if it is these syncs happen once a day or so and they won't all need editing. Having 'secret' commit messages in an open source project is not good. Michael > > > -- > Seo Sanghyeon > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jlhouchin at gmail.com Thu Apr 30 01:43:00 2009 From: jlhouchin at gmail.com (Jimmie Houchin) Date: Wed, 29 Apr 2009 18:43:00 -0500 Subject: [IronPython] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator) In-Reply-To: <49F867E0.5060807@voidspace.org.uk> References: <49F64584.70207@voidspace.org.uk> <49F867E0.5060807@voidspace.org.uk> Message-ID: This sounds great. I am new to both IronPython, WingIDE and Windows development in general. One of the disappointing things with WingIDE for me is the total absence of autocompletion of .NET imports and also the DLL Assembly References I've added to access the libraries my app requires. Unfortunately, for most of what I would like, I believe it would require WingIDE to support the use of IronPython. Is this accurate? And if WingIDE did support the use of IronPython would it make what you are doing easier or possibly unnecessary? I am exploring my IDE options. So I am somewhat disappointed with WingIDE not providing autocompletion or any of the features for which I am explicitly needing to use IronPython for. Unfortunately I really haven't found anything that does provide autocompletion for the libraries I've imported via clr. Oh well. It is possible I've missed something. I would love to see WingIDE support IronPython and enabling autocompletion, debugging, etc. on .NET and clr imported libraries and modules. Thanks for doing this Michael. It will be a nice help. And also thanks for your book which I am working my way through. Jimmie Houchin Michael Foord wrote: > Hello all, > > Attached is an updated script for generating PI files to provide > autocomplete on standard .NET objects. > > It now handles all the standard .NET member types (including static > properties, enumeration fields, indexers, events and so on). > > It also recurses into sub-namespaces generating new pi-files for all of > them. > > This script is hardcoded to add references to, and then generate PI > files for: > > System > System.Data > System.Drawing > System.Windows.Forms > > It generates 90 pi files (90 namespaces) taking up 24mb! The > autocomplete it provides is awesome though. :-) > > I had to do a fair bit of violence to the standard generate_pi.py script > so I *doubt* it is desirable to merge it back in. Obviously very happy > for this to be included with Wing if you want, or merged if you think it > is worth it. Is it ok for me to offer this for download from my site? If > I make further changes I will email this list. > > The big thing to add is the return type for methods. > > Is it possible to specify return types for properties? (Currently any > attribute without an obvious parallel in Python I have turned into a > property in the PI files). > > The only real caveat with the current script (that I am aware of - bug > reports and contributions welcomed) is that None is a common enumeration > field member. This is invalid syntax in Python, so I rename these to None_. > > There are quite a few minor changes sprinkled through the code - plus > the __main__ part of the script is very different. I have tried to mark > changes with a # CHANGE: comment, but it should be relatively amenable > to diffing anyway... > > For reference I was using IronPython 2.0.1, with .NET 3.5 installed and > Wing 3.2beta 1. > > All the best, > > Michael Foord > > Michael Foord wrote: >> Hello all, >> >> I've created a modified version of the 'generate_pi.py' which >> generates the interface files for .NET libraries. It is attached. >> >> At the moment it generates PI files for the following assemblies / >> namespaces (hardwired at the bottom of the code): >> >> System >> System.Data >> System.Drawing >> System.Windows.Forms >> >> To run it, create a new directory and add this to the 'Interface File >> Path' (File menu -> Preferences -> Source Analysis -> Advanced -> >> Insert). >> >> Then from the command line switch to this directory (if you are on >> Vista you will need to run cmd with admin privileges due to a defect >> explained below). Execute the command: >> >> ipy generate_pi_for_net.py >> >> This generates the pi files. It doesn't work *as well* on 64 bit >> windows because the .NET XML help files (or whatever they are called) >> are in a different location so the docstrings are not always available >> - which is why I am not just distributing the pi files yet. >> >> The script doesn't yet understand static properties on classes - so it >> actually *fetches* static properties rather than looking at the >> descriptor (which is available in the class __dict__ so should be easy >> to fix). This is what causes inadvertent registry lookups etc and >> therefore requires admin privileges. >> >> It doesn't yet understand multiple overloads. This may require a >> change to Wing or may not matter. >> >> It isn't yet able to do anything with the information about return >> types - which would allow Wing to know the type of objects returned by >> methods. This may be easy to add? >> >> It is late so I am going to bed. At some point I will explain the >> simple changes I had to make to the standard generate_pi.py script >> (although they are mostly straightforward). I will also do further >> work on it as it will be very useful to me... >> >> All the best, >> >> Michael >> >> ------------------------------------------------------------------------ >> >> _________________________________________________ >> Wing IDE users list >> http://wingware.com/lists/wingide > > From mbk.lists at gmail.com Thu Apr 30 03:19:46 2009 From: mbk.lists at gmail.com (Mike Krell) Date: Wed, 29 Apr 2009 18:19:46 -0700 Subject: [IronPython] sys._getframe(n)? In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A053@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <350E7D38B6D819428718949920EC23555728B8A053@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: On Wed, Apr 29, 2009 at 8:34 AM, Dino Viehland wrote: > Yep, we're going to make it available via a command line option. ?The > Interesting question is what does IPython need from frames? ?Does it > need locals (which frequently won't be available), globals, the function > or code, or something else? I hadn't looked at the source until now, but a cursory glance suggests that it typically wants to evaluate expressions with the locals (and globals) from various stack frames. Could you discuss in a bit more detail why certain locals wouldn't be available that would otherwise be available in CPython? Mike From curt at hagenlocher.org Thu Apr 30 05:28:08 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 29 Apr 2009 20:28:08 -0700 Subject: [IronPython] sys._getframe(n)? In-Reply-To: References: <350E7D38B6D819428718949920EC23555728B8A053@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: On Wed, Apr 29, 2009 at 6:19 PM, Mike Krell wrote: > > On Wed, Apr 29, 2009 at 8:34 AM, Dino Viehland wrote: >> Yep, we're going to make it available via a command line option. ?The >> Interesting question is what does IPython need from frames? ?Does it >> need locals (which frequently won't be available), globals, the function >> or code, or something else? > > I hadn't looked at the source until now, but a cursory glance suggests > that it typically wants to evaluate expressions with the locals (and > globals) from various stack frames. ?Could you discuss in a bit more > detail why certain locals wouldn't be available that would otherwise > be available in CPython? I don't know the exact answer but I won't let that stop me from replying. :) I'll just rely on Dino correcting anything I say that is wrong... IronPython is a compiler that ultimately produces MSIL. If it determines that a particular local variable doesn't need to be accessed from outside the local scope -- that is, if it's not closed over and there is no exec or locals() which could target it -- then that variable simply becomes a local value on the IL stack. The CLR StackFrame object doesn't give us access to the associated locals, so we have no way of accessing them from outside (except through CLR debug APIs, which aren't really applicable for this type of use). In principle, IronPython could optionally use a less-efficient representation for locals that would allow us to expose them all of them through the Python stack frame. I don't know how serious a performance penalty this would exact, but I imagine it's not small. The Unladen Swallow project is likely to face similar tradeoffs. -- Curt Hagenlocher curt at hagenlocher.org From william at resolversystems.com Thu Apr 30 13:02:31 2009 From: william at resolversystems.com (William Reade) Date: Thu, 30 Apr 2009 12:02:31 +0100 Subject: [IronPython] Control event ids Message-ID: <49F98547.3040801@resolversystems.com> Hi List ---------------------------- >>> import clr >>> clr.AddReference('System.Windows.Forms') >>> from System.Windows.Forms import TabControl >>> t = TabControl() >>> t.MouseDown == t.MouseDown False >>> t.MouseDown is t.MouseDown False >>> ---------------------------- This behaviour makes it extremely cumbersome to detach from events (some events, anyway; I'm pretty certain that I've seen events which don't exhibit this behaviour, but I can't remember what they are). Is this an IronPython bug, or have I got a broken mental model of what should be happening? Cheers William From curt at hagenlocher.org Thu Apr 30 15:00:28 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 30 Apr 2009 06:00:28 -0700 Subject: [IronPython] Control event ids In-Reply-To: <49F98547.3040801@resolversystems.com> References: <49F98547.3040801@resolversystems.com> Message-ID: On Thu, Apr 30, 2009 at 4:02 AM, William Reade wrote: > Is this an IronPython bug, or have I got a broken mental model of what > should be happening? CLR events are not objects but endpoints, so you can't really do "objectey" things with them. > This behaviour makes it extremely cumbersome to detach from events > (some events, anyway; I'm pretty certain that I've seen events which > don't exhibit this behaviour, but I can't remember what they are). An example of this would be useful. -- Curt Hagenlocher curt at hagenlocher.org From fuzzyman at voidspace.org.uk Thu Apr 30 15:09:07 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 14:09:07 +0100 Subject: [IronPython] Crash with Action and reflection question Message-ID: <49F9A2F3.3050001@voidspace.org.uk> Hello all, The following seems to crash the IronPython 2.0.1 interpreter: >>> from System import Action >>> Action(lambda: foo) Obviously it's invalid - but it kills the interpreter rather than raising an exception. I'm doing some introspection and I'd like to work out the return types of methods of .NET objects. One route would be to parse the docstring. :-) Another way would be to get the MethodInfo. For an arbitrary .NET type from inside IronPython how do I get a System.Type instance representing the type? (I'd quite like an answer to that question - but if you also have a suggestion as to a better way that would be great as well...) Thanks Michael -- http://www.ironpythoninaction.com/ From curt at hagenlocher.org Thu Apr 30 15:19:24 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 30 Apr 2009 06:19:24 -0700 Subject: [IronPython] Crash with Action and reflection question In-Reply-To: <49F9A2F3.3050001@voidspace.org.uk> References: <49F9A2F3.3050001@voidspace.org.uk> Message-ID: On Thu, Apr 30, 2009 at 6:09 AM, Michael Foord wrote: > > The following seems to crash the IronPython 2.0.1 interpreter: > >>>> from System import Action >>>> Action(lambda: foo) > > Obviously it's invalid - but it kills the interpreter rather than raising an > exception. It's been fixed for 2.6 (http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=19133). If it's a fix that you want for the 2.0 branch, feel free to open another item on Codeplex :). > Another way would be to get the MethodInfo. For an arbitrary .NET type from > inside IronPython how do I get a System.Type instance representing the type? You mean like this? from System.Collections.Generic import List runtimeType = clr.GetClrType(List) -- Curt Hagenlocher curt at hagenlocher.org From fuzzyman at voidspace.org.uk Thu Apr 30 15:23:04 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 14:23:04 +0100 Subject: [IronPython] Crash with Action and reflection question In-Reply-To: References: <49F9A2F3.3050001@voidspace.org.uk> Message-ID: <49F9A638.8030609@voidspace.org.uk> Curt Hagenlocher wrote: > On Thu, Apr 30, 2009 at 6:09 AM, Michael Foord > wrote: > >> The following seems to crash the IronPython 2.0.1 interpreter: >> >> >>>>> from System import Action >>>>> Action(lambda: foo) >>>>> >> Obviously it's invalid - but it kills the interpreter rather than raising an >> exception. >> > > It's been fixed for 2.6 > (http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=19133). > If it's a fix that you want for the 2.0 branch, feel free to open > another item on Codeplex :). > > Thanks - not massively worried about. >> Another way would be to get the MethodInfo. For an arbitrary .NET type from >> inside IronPython how do I get a System.Type instance representing the type? >> > > You mean like this? > from System.Collections.Generic import List > runtimeType = clr.GetClrType(List) > Exactly! Thank you. I need you on IM so I can bug you with these questions more easily... :-) Michael > -- > Curt Hagenlocher > curt at hagenlocher.org > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From fuzzyman at voidspace.org.uk Thu Apr 30 16:32:21 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 15:32:21 +0100 Subject: [IronPython] [wingide-users] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator) In-Reply-To: <49F867E0.5060807@voidspace.org.uk> References: <49F64584.70207@voidspace.org.uk> <49F867E0.5060807@voidspace.org.uk> Message-ID: <49F9B675.7090604@voidspace.org.uk> Hello all, Another update to the PI file generator for .NET objects. This one adds return type annotations for methods. It means that if you do something like: from System import Guid g = Guid.NewGuid() Wing knowsthat "g" is a Guid and provides the correct auto-complete members for it. This is *great*. See previous instructions on how to use the script. It now takes quite a *long* time to generate all 90 PI files. :-) There is a caveat with this currently: Many methods return types that are defined in other namespaces (especially types defined in System). Because those types are in another PI file, Wing doesn't recognise them. I'll work out how to fix this ("from System import *" at the top of each PI file might catch most cases). Secondly return types can currently return things like Array[int]() the indexing will cause Wing to effectively ignore the return type - so I should change this to Array(). Still - getting there step-by-step and this is already enormously useful to me. I'm currently using a truly horrible regular expression to pull the return type out of the docstring... I'll write this all up into a proper 'HOWTO: IronPython in Wing' once I have time. All the best, Michael Michael Foord wrote: > Hello all, > > Attached is an updated script for generating PI files to provide > autocomplete on standard .NET objects. > > It now handles all the standard .NET member types (including static > properties, enumeration fields, indexers, events and so on). > > It also recurses into sub-namespaces generating new pi-files for all > of them. > > This script is hardcoded to add references to, and then generate PI > files for: > > System > System.Data > System.Drawing > System.Windows.Forms > > It generates 90 pi files (90 namespaces) taking up 24mb! The > autocomplete it provides is awesome though. :-) > > I had to do a fair bit of violence to the standard generate_pi.py > script so I *doubt* it is desirable to merge it back in. Obviously > very happy for this to be included with Wing if you want, or merged if > you think it is worth it. Is it ok for me to offer this for download > from my site? If I make further changes I will email this list. > > The big thing to add is the return type for methods. > > Is it possible to specify return types for properties? (Currently any > attribute without an obvious parallel in Python I have turned into a > property in the PI files). > > The only real caveat with the current script (that I am aware of - bug > reports and contributions welcomed) is that None is a common > enumeration field member. This is invalid syntax in Python, so I > rename these to None_. > > There are quite a few minor changes sprinkled through the code - plus > the __main__ part of the script is very different. I have tried to > mark changes with a # CHANGE: comment, but it should be relatively > amenable to diffing anyway... > > For reference I was using IronPython 2.0.1, with .NET 3.5 installed > and Wing 3.2beta 1. > > All the best, > > Michael Foord > > Michael Foord wrote: >> Hello all, >> >> I've created a modified version of the 'generate_pi.py' which >> generates the interface files for .NET libraries. It is attached. >> >> At the moment it generates PI files for the following assemblies / >> namespaces (hardwired at the bottom of the code): >> >> System >> System.Data >> System.Drawing >> System.Windows.Forms >> >> To run it, create a new directory and add this to the 'Interface File >> Path' (File menu -> Preferences -> Source Analysis -> Advanced -> >> Insert). >> >> Then from the command line switch to this directory (if you are on >> Vista you will need to run cmd with admin privileges due to a defect >> explained below). Execute the command: >> >> ipy generate_pi_for_net.py >> >> This generates the pi files. It doesn't work *as well* on 64 bit >> windows because the .NET XML help files (or whatever they are called) >> are in a different location so the docstrings are not always >> available - which is why I am not just distributing the pi files yet. >> >> The script doesn't yet understand static properties on classes - so >> it actually *fetches* static properties rather than looking at the >> descriptor (which is available in the class __dict__ so should be >> easy to fix). This is what causes inadvertent registry lookups etc >> and therefore requires admin privileges. >> >> It doesn't yet understand multiple overloads. This may require a >> change to Wing or may not matter. >> >> It isn't yet able to do anything with the information about return >> types - which would allow Wing to know the type of objects returned >> by methods. This may be easy to add? >> >> It is late so I am going to bed. At some point I will explain the >> simple changes I had to make to the standard generate_pi.py script >> (although they are mostly straightforward). I will also do further >> work on it as it will be very useful to me... >> >> All the best, >> >> Michael >> >> ------------------------------------------------------------------------ >> >> _________________________________________________ >> Wing IDE users list >> http://wingware.com/lists/wingide > > > ------------------------------------------------------------------------ > > _________________________________________________ > Wing IDE users list > http://wingware.com/lists/wingide -- http://www.ironpythoninaction.com/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: generate_pi_for_net.py URL: From kristian.jaksch at gmail.com Thu Apr 30 17:00:40 2009 From: kristian.jaksch at gmail.com (Kristian Jaksch) Date: Thu, 30 Apr 2009 17:00:40 +0200 Subject: [IronPython] Is Silverlight 3 beta supported in Ironpython yet? Message-ID: <1dab55500904300800v7e714b8cma04272593eb0972e@mail.gmail.com> Does Ironpython support Silverlight 3 beta yet? /Kristian -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas.cenovsky at radiantsystems.com Thu Apr 30 17:01:51 2009 From: lukas.cenovsky at radiantsystems.com (Cenovsky, Lukas) Date: Thu, 30 Apr 2009 11:01:51 -0400 Subject: [IronPython] Crash with Action and reflection question In-Reply-To: References: <49F9A2F3.3050001@voidspace.org.uk> Message-ID: > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt > Hagenlocher > Sent: Thursday, April 30, 2009 3:19 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Crash with Action and reflection question > > > Another way would be to get the MethodInfo. For an > arbitrary .NET type from > > inside IronPython how do I get a System.Type instance > representing the type? > > You mean like this? > from System.Collections.Generic import List > runtimeType = clr.GetClrType(List) Cool - I need it too :-) -- -- Lukas From fuzzyman at voidspace.org.uk Thu Apr 30 17:10:51 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 16:10:51 +0100 Subject: [IronPython] Docstrings on stuff in clr module Message-ID: <49F9BF7B.5050207@voidspace.org.uk> Hello IronPython team, Could we please have better docstrings on some of the stuff in the clr module. Specifically: Module docstring: """ module() module(dict dictionary) module(module parent, dict dictionary) module(module parent, dict dictionary, bool isVisible) """ def AddReferenceToTypeLibrary(arg0, arg1): """ AddReferenceToTypeLibrary(CodeContext context, object rcw) AddReferenceToTypeLibrary(CodeContext context, Guid typeLibGuid) """ pass class ArgChecker(object): """ ArgChecker(Array[object] prms) """ def CompileModules(arg0, arg1, arg2, arg3=None): """ CompileModules(CodeContext context, str assemblyName, dict kwArgs, Array[str] filenames) """ pass def Deserialize(arg0, arg1): """ object Deserialize(str serializationFormat, str data) """ return object() def GetClrType(arg0): """ Type GetClrType(Type type) """ return Type() def GetCurrentRuntime(arg0): """ ScriptDomainManager GetCurrentRuntime(CodeContext context) """ return ScriptDomainManager() def GetDynamicType(arg0): """ type GetDynamicType(Type t) """ return type() def GetPythonType(arg0): """ type GetPythonType(Type t) """ return type() def LoadTypeLibrary(arg0, arg1): """ ComTypeLibInfo LoadTypeLibrary(CodeContext context, object rcw) ComTypeLibInfo LoadTypeLibrary(CodeContext context, Guid typeLibGuid) """ return ComTypeLibInfo() class Reference(object): """ StrongBox[T]() StrongBox[T](T value) """ class ReferencesList(List[Assembly]): """ ReferencesList() """ class ReturnChecker(object): """ ReturnChecker(object returnType) """ class RuntimeArgChecker(PythonTypeSlot): """ RuntimeArgChecker(object function, Array[object] expectedArgs) RuntimeArgChecker(object instance, object function, Array[object] expectedArgs) """ class RuntimeReturnChecker(PythonTypeSlot): """ RuntimeReturnChecker(object function, object expectedReturn) RuntimeReturnChecker(object instance, object function, object expectedReturn) """ def GetAttribute(self, arg0, arg1): """ object GetAttribute(self, object instance, object owner) """ return object() def Self(arg): """ object Self() """ return object() def Serialize(arg0): """ tuple Serialize(object self) """ return tuple() def SetCommandDispatcher(arg0, arg1): """ CommandDispatcher SetCommandDispatcher(CodeContext context, CommandDispatcher dispatcher) """ return CommandDispatcher() def Use(arg0, arg1): """ object Use(CodeContext context, str name) object Use(CodeContext context, str path, str language) """ return object() def accepts(arg0=None): """ object accepts(Array[object] types) """ return object() def returns(arg0): """ object returns(object type) """ return object() (Above from the Wing PI file generated for the clr module.) :-) Thanks Michael -- http://www.ironpythoninaction.com/ From stephen.p.lepisto at intel.com Thu Apr 30 17:26:23 2009 From: stephen.p.lepisto at intel.com (Lepisto, Stephen P) Date: Thu, 30 Apr 2009 08:26:23 -0700 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process Message-ID: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> Hello, everyone! I am working on an service manager application that provides embedded python support through a small set of generalized classes: PythonService, PythonSession, and PythonClass. A client application asks the service manager for the PythonService object and then asks the PythonService object for a new PythonSession object. The PythonSession object is used to access embedded python through a small set of generalized methods. The PythonClass object is used to wrap a python class instance. The key requirement in this is each client must have its own python session, independent of any other sessions currently running. I've got this to work with CPython (specifically, python 2.5.4), by careful use of the global interpreter lock and swapping the thread state. IronPython 2.0.1 has a nicer way of implementing all of this by using the CreateEngine() to create a new python engine. However, in IronPython I've run into what appears to be a significant limitation that may prevent me from using IronPython in this particular situation as an embedded language. The limitation is when I import a python package from disk into IronPython (using IronPython.Hosting.Python.ImportModule()) in one session and then import the same package into a different session, it turns out that both sessions are pulling from the same module's scope. That is, if I make changes to the module's scope in one session (for example, changing a global variable), that change appears in the other session. After tracing execution in the IronPython 2.0.1 code, it turns out that a module is cached in the LanguageContext (PythonContext) object, which in turn is a singleton in DLR, as it is associated with the language type. This is okay if an application is embedding IronPython itself but in my scenario, this prevents multiple discrete python sessions in a single application. Ideally, I would expect to see the system state be stored in the python engine (ScriptEngine) or python runtime (ScriptRuntime) objects. Is there a way around this limitation? Can I somehow create a unique PythonContext object for each of my python sessions so I get a completely discrete python instance in each session with no crosstalk? Or do I have to resort to modifying the IronPython source to accomplish this (which I'm loathe to do since then I would have to maintain it going forward)? Thank you for your time and consideration in this matter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Apr 30 17:54:36 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Apr 2009 08:54:36 -0700 Subject: [IronPython] Docstrings on stuff in clr module In-Reply-To: <49F9BF7B.5050207@voidspace.org.uk> References: <49F9BF7B.5050207@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23555728B8A496@NA-EXMSG-C102.redmond.corp.microsoft.com> Yes - I've opened a bug (22235 - http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). I want to generally improve the doc strings everywhere. I've slowly been pushing on this and my ultimate goal is to get all of the doc strings moved into XML comments and then we can read them from there. Then we just need to go through a big push and add XML doc comments everywhere :) If other people have APIs they want doc strings on please add them to the comments. But I can see clr being particularly problematic as it otherwise lacks documentation. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, April 30, 2009 8:11 AM > To: Discussion of IronPython > Subject: [IronPython] Docstrings on stuff in clr module > > Hello IronPython team, > > Could we please have better docstrings on some of the stuff in the clr > module. Specifically: > > Module docstring: """ module() > module(dict dictionary) > module(module parent, dict dictionary) > module(module parent, dict dictionary, bool isVisible) > """ > > def AddReferenceToTypeLibrary(arg0, arg1): > """ AddReferenceToTypeLibrary(CodeContext context, object rcw) > AddReferenceToTypeLibrary(CodeContext context, Guid typeLibGuid) """ > pass > > class ArgChecker(object): > """ ArgChecker(Array[object] prms) > """ > > > def CompileModules(arg0, arg1, arg2, arg3=None): > """ CompileModules(CodeContext context, str assemblyName, dict > kwArgs, > Array[str] filenames) """ > pass > > def Deserialize(arg0, arg1): > """ object Deserialize(str serializationFormat, str data) """ > return object() > > def GetClrType(arg0): > """ Type GetClrType(Type type) """ > return Type() > > def GetCurrentRuntime(arg0): > """ ScriptDomainManager GetCurrentRuntime(CodeContext context) """ > return ScriptDomainManager() > > def GetDynamicType(arg0): > """ type GetDynamicType(Type t) """ > return type() > > def GetPythonType(arg0): > """ type GetPythonType(Type t) """ > return type() > > def LoadTypeLibrary(arg0, arg1): > """ ComTypeLibInfo LoadTypeLibrary(CodeContext context, object rcw) > ComTypeLibInfo LoadTypeLibrary(CodeContext context, Guid typeLibGuid) > """ > return ComTypeLibInfo() > > class Reference(object): > """ StrongBox[T]() > StrongBox[T](T value) > """ > > class ReferencesList(List[Assembly]): > """ ReferencesList() > """ > > class ReturnChecker(object): > """ ReturnChecker(object returnType) > """ > > class RuntimeArgChecker(PythonTypeSlot): > """ RuntimeArgChecker(object function, Array[object] expectedArgs) > RuntimeArgChecker(object instance, object function, Array[object] > expectedArgs) > """ > > class RuntimeReturnChecker(PythonTypeSlot): > """ RuntimeReturnChecker(object function, object expectedReturn) > RuntimeReturnChecker(object instance, object function, object > expectedReturn) > """ > def GetAttribute(self, arg0, arg1): > """ object GetAttribute(self, object instance, object owner) """ > return object() > > > def Self(arg): > """ object Self() """ > return object() > > def Serialize(arg0): > """ tuple Serialize(object self) """ > return tuple() > > def SetCommandDispatcher(arg0, arg1): > """ CommandDispatcher SetCommandDispatcher(CodeContext context, > CommandDispatcher dispatcher) """ > return CommandDispatcher() > > def Use(arg0, arg1): > """ object Use(CodeContext context, str name) > object Use(CodeContext context, str path, str language) """ > return object() > > def accepts(arg0=None): > """ object accepts(Array[object] types) """ > return object() > > def returns(arg0): > """ object returns(object type) """ > return object() > > (Above from the Wing PI file generated for the clr module.) > > :-) > > Thanks > > Michael > > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Thu Apr 30 17:56:25 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Apr 2009 08:56:25 -0700 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> Message-ID: <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> You mention CreateEngine but are you also creating multiple runtimes? You're only allowed 1 ScriptEngine of a given type per ScriptRuntime. So you should create a new ScriptRuntime and then get the Python engine for each runtime and then be isolated. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Lepisto, Stephen P Sent: Thursday, April 30, 2009 8:26 AM To: users at lists.ironpython.com Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process Hello, everyone! I am working on an service manager application that provides embedded python support through a small set of generalized classes: PythonService, PythonSession, and PythonClass. A client application asks the service manager for the PythonService object and then asks the PythonService object for a new PythonSession object. The PythonSession object is used to access embedded python through a small set of generalized methods. The PythonClass object is used to wrap a python class instance. The key requirement in this is each client must have its own python session, independent of any other sessions currently running. I've got this to work with CPython (specifically, python 2.5.4), by careful use of the global interpreter lock and swapping the thread state. IronPython 2.0.1 has a nicer way of implementing all of this by using the CreateEngine() to create a new python engine. However, in IronPython I've run into what appears to be a significant limitation that may prevent me from using IronPython in this particular situation as an embedded language. The limitation is when I import a python package from disk into IronPython (using IronPython.Hosting.Python.ImportModule()) in one session and then import the same package into a different session, it turns out that both sessions are pulling from the same module's scope. That is, if I make changes to the module's scope in one session (for example, changing a global variable), that change appears in the other session. After tracing execution in the IronPython 2.0.1 code, it turns out that a module is cached in the LanguageContext (PythonContext) object, which in turn is a singleton in DLR, as it is associated with the language type. This is okay if an application is embedding IronPython itself but in my scenario, this prevents multiple discrete python sessions in a single application. Ideally, I would expect to see the system state be stored in the python engine (ScriptEngine) or python runtime (ScriptRuntime) objects. Is there a way around this limitation? Can I somehow create a unique PythonContext object for each of my python sessions so I get a completely discrete python instance in each session with no crosstalk? Or do I have to resort to modifying the IronPython source to accomplish this (which I'm loathe to do since then I would have to maintain it going forward)? Thank you for your time and consideration in this matter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Apr 30 18:08:27 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 17:08:27 +0100 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49F9CCFB.8040601@voidspace.org.uk> Dino Viehland wrote: > > You mention CreateEngine but are you also creating multiple runtimes? > You?re only allowed 1 ScriptEngine of a given type per ScriptRuntime. > So you should create a new ScriptRuntime and then get the Python > engine for each runtime and then be isolated. > If you call Python.CreateEngine() twice it gives you two different engine objects with what *appear* to be different runtimes. If you then call Python.ImportModule for the same module but passing in the two different engines, you get two different (non-identical objects) ScriptScopes - but changes in one are reflected in the other. Is CreateEngine not the correct way to get isolated engines? Michael > *From:* users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto, > Stephen P > *Sent:* Thursday, April 30, 2009 8:26 AM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > Hello, everyone! > > I am working on an service manager application that provides embedded > python support through a small set of generalized classes: > PythonService, PythonSession, and PythonClass. A client application > asks the service manager for the PythonService object and then asks > the PythonService object for a new PythonSession object. The > PythonSession object is used to access embedded python through a small > set of generalized methods. The PythonClass object is used to wrap a > python class instance. > > The key requirement in this is each client must have its own python > session, independent of any other sessions currently running. I?ve got > this to work with CPython (specifically, python 2.5.4), by careful use > of the global interpreter lock and swapping the thread state. > IronPython 2.0.1 has a nicer way of implementing all of this by using > the CreateEngine() to create a new python engine. However, in > IronPython I?ve run into what appears to be a significant limitation > that may prevent me from using IronPython in this particular situation > as an embedded language. > > The limitation is when I import a python package from disk into > IronPython (using IronPython.Hosting.Python.ImportModule()) in one > session and then import the same package into a different session, it > turns out that both sessions are pulling from the same module?s scope. > That is, if I make changes to the module?s scope in one session (for > example, changing a global variable), that change appears in the other > session. > > After tracing execution in the IronPython 2.0.1 code, it turns out > that a module is cached in the LanguageContext (PythonContext) object, > which in turn is a singleton in DLR, as it is associated with the > language type. This is okay if an application is embedding IronPython > itself but in my scenario, this prevents multiple discrete python > sessions in a single application. Ideally, I would expect to see the > system state be stored in the python engine (ScriptEngine) or python > runtime (ScriptRuntime) objects. > > Is there a way around this limitation? Can I somehow create a unique > PythonContext object for each of my python sessions so I get a > completely discrete python instance in each session with no crosstalk? > Or do I have to resort to modifying the IronPython source to > accomplish this (which I?m loathe to do since then I would have to > maintain it going forward)? > > Thank you for your time and consideration in this matter. > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From fuzzyman at voidspace.org.uk Thu Apr 30 18:11:19 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 17:11:19 +0100 Subject: [IronPython] Docstrings on stuff in clr module In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A496@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49F9BF7B.5050207@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A496@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49F9CDA7.7030901@voidspace.org.uk> Dino Viehland wrote: > Yes - I've opened a bug (22235 - http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). > > I want to generally improve the doc strings everywhere. I've slowly > been pushing on this and my ultimate goal is to get all of the doc > strings moved into XML comments and then we can read them from there. > > Then we just need to go through a big push and add XML doc comments > everywhere :) > > If other people have APIs they want doc strings on please add them > to the comments. But I can see clr being particularly problematic > as it otherwise lacks documentation. > Thanks Dino. Yes it was particularly the lack of documentation for the clr module that I was hoping to alleviate. Docstrings in XML. Well I never... Michael > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Thursday, April 30, 2009 8:11 AM >> To: Discussion of IronPython >> Subject: [IronPython] Docstrings on stuff in clr module >> >> Hello IronPython team, >> >> Could we please have better docstrings on some of the stuff in the clr >> module. Specifically: >> >> Module docstring: """ module() >> module(dict dictionary) >> module(module parent, dict dictionary) >> module(module parent, dict dictionary, bool isVisible) >> """ >> >> def AddReferenceToTypeLibrary(arg0, arg1): >> """ AddReferenceToTypeLibrary(CodeContext context, object rcw) >> AddReferenceToTypeLibrary(CodeContext context, Guid typeLibGuid) """ >> pass >> >> class ArgChecker(object): >> """ ArgChecker(Array[object] prms) >> """ >> >> >> def CompileModules(arg0, arg1, arg2, arg3=None): >> """ CompileModules(CodeContext context, str assemblyName, dict >> kwArgs, >> Array[str] filenames) """ >> pass >> >> def Deserialize(arg0, arg1): >> """ object Deserialize(str serializationFormat, str data) """ >> return object() >> >> def GetClrType(arg0): >> """ Type GetClrType(Type type) """ >> return Type() >> >> def GetCurrentRuntime(arg0): >> """ ScriptDomainManager GetCurrentRuntime(CodeContext context) """ >> return ScriptDomainManager() >> >> def GetDynamicType(arg0): >> """ type GetDynamicType(Type t) """ >> return type() >> >> def GetPythonType(arg0): >> """ type GetPythonType(Type t) """ >> return type() >> >> def LoadTypeLibrary(arg0, arg1): >> """ ComTypeLibInfo LoadTypeLibrary(CodeContext context, object rcw) >> ComTypeLibInfo LoadTypeLibrary(CodeContext context, Guid typeLibGuid) >> """ >> return ComTypeLibInfo() >> >> class Reference(object): >> """ StrongBox[T]() >> StrongBox[T](T value) >> """ >> >> class ReferencesList(List[Assembly]): >> """ ReferencesList() >> """ >> >> class ReturnChecker(object): >> """ ReturnChecker(object returnType) >> """ >> >> class RuntimeArgChecker(PythonTypeSlot): >> """ RuntimeArgChecker(object function, Array[object] expectedArgs) >> RuntimeArgChecker(object instance, object function, Array[object] >> expectedArgs) >> """ >> >> class RuntimeReturnChecker(PythonTypeSlot): >> """ RuntimeReturnChecker(object function, object expectedReturn) >> RuntimeReturnChecker(object instance, object function, object >> expectedReturn) >> """ >> def GetAttribute(self, arg0, arg1): >> """ object GetAttribute(self, object instance, object owner) """ >> return object() >> >> >> def Self(arg): >> """ object Self() """ >> return object() >> >> def Serialize(arg0): >> """ tuple Serialize(object self) """ >> return tuple() >> >> def SetCommandDispatcher(arg0, arg1): >> """ CommandDispatcher SetCommandDispatcher(CodeContext context, >> CommandDispatcher dispatcher) """ >> return CommandDispatcher() >> >> def Use(arg0, arg1): >> """ object Use(CodeContext context, str name) >> object Use(CodeContext context, str path, str language) """ >> return object() >> >> def accepts(arg0=None): >> """ object accepts(Array[object] types) """ >> return object() >> >> def returns(arg0): >> """ object returns(object type) """ >> return object() >> >> (Above from the Wing PI file generated for the clr module.) >> >> :-) >> >> Thanks >> >> Michael >> >> >> >> -- >> http://www.ironpythoninaction.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 > -- http://www.ironpythoninaction.com/ From curt at hagenlocher.org Thu Apr 30 18:19:12 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 30 Apr 2009 09:19:12 -0700 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: <49F9CCFB.8040601@voidspace.org.uk> References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9CCFB.8040601@voidspace.org.uk> Message-ID: On Thu, Apr 30, 2009 at 9:08 AM, Michael Foord wrote: > Is CreateEngine not the correct way to get isolated engines? Yes, but it looks like ImportModule is importing into some kind of shared state. -- Curt Hagenlocher curt at hagenlocher.org From JDM at MarchRay.net Thu Apr 30 18:20:19 2009 From: JDM at MarchRay.net (Jonathan March) Date: Thu, 30 Apr 2009 11:20:19 -0500 Subject: [IronPython] Docstrings on stuff in clr module In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A496@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49F9BF7B.5050207@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A496@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: Is there a standardized protocol for XML docstrings? Then what software would you use to process them? On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland wrote: > Yes - I've opened a bug (22235 - > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). > > I want to generally improve the doc strings everywhere. I've slowly > been pushing on this and my ultimate goal is to get all of the doc > strings moved into XML comments and then we can read them from there. > > Then we just need to go through a big push and add XML doc comments > everywhere :) > > If other people have APIs they want doc strings on please add them > to the comments. But I can see clr being particularly problematic > as it otherwise lacks documentation. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Apr 30 18:19:04 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Apr 2009 09:19:04 -0700 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: <49F9CCFB.8040601@voidspace.org.uk> References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9CCFB.8040601@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23555728B8A4B9@NA-EXMSG-C102.redmond.corp.microsoft.com> Oh, Python.CreateEngine will give you independent engines as it'll create a new runtime each time. I was thinking this was one of the normal DLR hosting APIs but I guess there is no create engine there, just GetEngine. Stephen, do you have a small simple repro for this? If you're using Python.CreateEngine it should just work. The PythonContext is one to one w/ the ScriptEngine so it's the right spot for the state to live. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, April 30, 2009 9:08 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > Dino Viehland wrote: > > > > You mention CreateEngine but are you also creating multiple runtimes? > > You're only allowed 1 ScriptEngine of a given type per ScriptRuntime. > > So you should create a new ScriptRuntime and then get the Python > > engine for each runtime and then be isolated. > > > > If you call Python.CreateEngine() twice it gives you two different > engine objects with what *appear* to be different runtimes. > > If you then call Python.ImportModule for the same module but passing in > the two different engines, you get two different (non-identical > objects) > ScriptScopes - but changes in one are reflected in the other. > > Is CreateEngine not the correct way to get isolated engines? > > Michael > > > *From:* users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto, > > Stephen P > > *Sent:* Thursday, April 30, 2009 8:26 AM > > *To:* users at lists.ironpython.com > > *Subject:* [IronPython] Question on Multiple Discrete IronPython > > sessions in a single process > > > > Hello, everyone! > > > > I am working on an service manager application that provides embedded > > python support through a small set of generalized classes: > > PythonService, PythonSession, and PythonClass. A client application > > asks the service manager for the PythonService object and then asks > > the PythonService object for a new PythonSession object. The > > PythonSession object is used to access embedded python through a > small > > set of generalized methods. The PythonClass object is used to wrap a > > python class instance. > > > > The key requirement in this is each client must have its own python > > session, independent of any other sessions currently running. I've > got > > this to work with CPython (specifically, python 2.5.4), by careful > use > > of the global interpreter lock and swapping the thread state. > > IronPython 2.0.1 has a nicer way of implementing all of this by using > > the CreateEngine() to create a new python engine. However, in > > IronPython I've run into what appears to be a significant limitation > > that may prevent me from using IronPython in this particular > situation > > as an embedded language. > > > > The limitation is when I import a python package from disk into > > IronPython (using IronPython.Hosting.Python.ImportModule()) in one > > session and then import the same package into a different session, it > > turns out that both sessions are pulling from the same module's > scope. > > That is, if I make changes to the module's scope in one session (for > > example, changing a global variable), that change appears in the > other > > session. > > > > After tracing execution in the IronPython 2.0.1 code, it turns out > > that a module is cached in the LanguageContext (PythonContext) > object, > > which in turn is a singleton in DLR, as it is associated with the > > language type. This is okay if an application is embedding IronPython > > itself but in my scenario, this prevents multiple discrete python > > sessions in a single application. Ideally, I would expect to see the > > system state be stored in the python engine (ScriptEngine) or python > > runtime (ScriptRuntime) objects. > > > > Is there a way around this limitation? Can I somehow create a unique > > PythonContext object for each of my python sessions so I get a > > completely discrete python instance in each session with no > crosstalk? > > Or do I have to resort to modifying the IronPython source to > > accomplish this (which I'm loathe to do since then I would have to > > maintain it going forward)? > > > > Thank you for your time and consideration in this matter. > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Thu Apr 30 18:27:54 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Apr 2009 09:27:54 -0700 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: <49F9CCFB.8040601@voidspace.org.uk> References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9CCFB.8040601@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23555728B8A4CC@NA-EXMSG-C102.redmond.corp.microsoft.com> And this works for me: using System; using IronPython.Hosting; using Microsoft.Scripting.Hosting; class foo { static void Main(string[] args) { var engine = Python.CreateEngine(); ScriptScope scope1 = engine.ImportModule("foo"); var engine2 = Python.CreateEngine(); ScriptScope scope2 = engine2.ImportModule("foo"); scope1.SetVariable("foo", 42); object res; if(scope2.TryGetVariable("foo", out res)) { Console.WriteLine(res); } else { Console.WriteLine("no foo"); } } } Foo.py: print 'hello' Printing out: hello hello no foo > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, April 30, 2009 9:08 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > Dino Viehland wrote: > > > > You mention CreateEngine but are you also creating multiple runtimes? > > You're only allowed 1 ScriptEngine of a given type per ScriptRuntime. > > So you should create a new ScriptRuntime and then get the Python > > engine for each runtime and then be isolated. > > > > If you call Python.CreateEngine() twice it gives you two different > engine objects with what *appear* to be different runtimes. > > If you then call Python.ImportModule for the same module but passing in > the two different engines, you get two different (non-identical > objects) > ScriptScopes - but changes in one are reflected in the other. > > Is CreateEngine not the correct way to get isolated engines? > > Michael > > > *From:* users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto, > > Stephen P > > *Sent:* Thursday, April 30, 2009 8:26 AM > > *To:* users at lists.ironpython.com > > *Subject:* [IronPython] Question on Multiple Discrete IronPython > > sessions in a single process > > > > Hello, everyone! > > > > I am working on an service manager application that provides embedded > > python support through a small set of generalized classes: > > PythonService, PythonSession, and PythonClass. A client application > > asks the service manager for the PythonService object and then asks > > the PythonService object for a new PythonSession object. The > > PythonSession object is used to access embedded python through a > small > > set of generalized methods. The PythonClass object is used to wrap a > > python class instance. > > > > The key requirement in this is each client must have its own python > > session, independent of any other sessions currently running. I've > got > > this to work with CPython (specifically, python 2.5.4), by careful > use > > of the global interpreter lock and swapping the thread state. > > IronPython 2.0.1 has a nicer way of implementing all of this by using > > the CreateEngine() to create a new python engine. However, in > > IronPython I've run into what appears to be a significant limitation > > that may prevent me from using IronPython in this particular > situation > > as an embedded language. > > > > The limitation is when I import a python package from disk into > > IronPython (using IronPython.Hosting.Python.ImportModule()) in one > > session and then import the same package into a different session, it > > turns out that both sessions are pulling from the same module's > scope. > > That is, if I make changes to the module's scope in one session (for > > example, changing a global variable), that change appears in the > other > > session. > > > > After tracing execution in the IronPython 2.0.1 code, it turns out > > that a module is cached in the LanguageContext (PythonContext) > object, > > which in turn is a singleton in DLR, as it is associated with the > > language type. This is okay if an application is embedding IronPython > > itself but in my scenario, this prevents multiple discrete python > > sessions in a single application. Ideally, I would expect to see the > > system state be stored in the python engine (ScriptEngine) or python > > runtime (ScriptRuntime) objects. > > > > Is there a way around this limitation? Can I somehow create a unique > > PythonContext object for each of my python sessions so I get a > > completely discrete python instance in each session with no > crosstalk? > > Or do I have to resort to modifying the IronPython source to > > accomplish this (which I'm loathe to do since then I would have to > > maintain it going forward)? > > > > Thank you for your time and consideration in this matter. > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Thu Apr 30 18:46:43 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 17:46:43 +0100 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A4CC@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9CCFB.8040601@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A4CC@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49F9D5F3.6040408@voidspace.org.uk> Dino Viehland wrote: > And this works for me: > I just did the equivalent, from *inside* IronPython which may make a difference, with the 'os' module and got the opposite result: >>> import clr >>> clr.AddReference('IronPython') >>> from IronPython.Hosting import Python# >>> e1 = Python.CreateEngine() >>> e2 = Python.CreateEngine() >>> >>> os1 = Python.ImportModule(e1, 'os') >>> os2 = Python.ImportModule(e2, 'os') >>> >>> os1 >>> os1 is os2 False >>> os1.SetVariable('foo', 'bar') >>> os2.GetVariable('foo') 'bar' >>> All the best, Michael > using System; > using IronPython.Hosting; > using Microsoft.Scripting.Hosting; > > class foo { > static void Main(string[] args) > { > var engine = Python.CreateEngine(); > ScriptScope scope1 = engine.ImportModule("foo"); > > var engine2 = Python.CreateEngine(); > ScriptScope scope2 = engine2.ImportModule("foo"); > > scope1.SetVariable("foo", 42); > object res; > if(scope2.TryGetVariable("foo", out res)) { > Console.WriteLine(res); > } else { > Console.WriteLine("no foo"); > } > } > } > > Foo.py: > print 'hello' > > Printing out: > > hello > hello > no foo > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Thursday, April 30, 2009 9:08 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Question on Multiple Discrete IronPython >> sessions in a single process >> >> Dino Viehland wrote: >> >>> You mention CreateEngine but are you also creating multiple runtimes? >>> You're only allowed 1 ScriptEngine of a given type per ScriptRuntime. >>> So you should create a new ScriptRuntime and then get the Python >>> engine for each runtime and then be isolated. >>> >>> >> If you call Python.CreateEngine() twice it gives you two different >> engine objects with what *appear* to be different runtimes. >> >> If you then call Python.ImportModule for the same module but passing in >> the two different engines, you get two different (non-identical >> objects) >> ScriptScopes - but changes in one are reflected in the other. >> >> Is CreateEngine not the correct way to get isolated engines? >> >> Michael >> >> >>> *From:* users-bounces at lists.ironpython.com >>> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto, >>> Stephen P >>> *Sent:* Thursday, April 30, 2009 8:26 AM >>> *To:* users at lists.ironpython.com >>> *Subject:* [IronPython] Question on Multiple Discrete IronPython >>> sessions in a single process >>> >>> Hello, everyone! >>> >>> I am working on an service manager application that provides embedded >>> python support through a small set of generalized classes: >>> PythonService, PythonSession, and PythonClass. A client application >>> asks the service manager for the PythonService object and then asks >>> the PythonService object for a new PythonSession object. The >>> PythonSession object is used to access embedded python through a >>> >> small >> >>> set of generalized methods. The PythonClass object is used to wrap a >>> python class instance. >>> >>> The key requirement in this is each client must have its own python >>> session, independent of any other sessions currently running. I've >>> >> got >> >>> this to work with CPython (specifically, python 2.5.4), by careful >>> >> use >> >>> of the global interpreter lock and swapping the thread state. >>> IronPython 2.0.1 has a nicer way of implementing all of this by using >>> the CreateEngine() to create a new python engine. However, in >>> IronPython I've run into what appears to be a significant limitation >>> that may prevent me from using IronPython in this particular >>> >> situation >> >>> as an embedded language. >>> >>> The limitation is when I import a python package from disk into >>> IronPython (using IronPython.Hosting.Python.ImportModule()) in one >>> session and then import the same package into a different session, it >>> turns out that both sessions are pulling from the same module's >>> >> scope. >> >>> That is, if I make changes to the module's scope in one session (for >>> example, changing a global variable), that change appears in the >>> >> other >> >>> session. >>> >>> After tracing execution in the IronPython 2.0.1 code, it turns out >>> that a module is cached in the LanguageContext (PythonContext) >>> >> object, >> >>> which in turn is a singleton in DLR, as it is associated with the >>> language type. This is okay if an application is embedding IronPython >>> itself but in my scenario, this prevents multiple discrete python >>> sessions in a single application. Ideally, I would expect to see the >>> system state be stored in the python engine (ScriptEngine) or python >>> runtime (ScriptRuntime) objects. >>> >>> Is there a way around this limitation? Can I somehow create a unique >>> PythonContext object for each of my python sessions so I get a >>> completely discrete python instance in each session with no >>> >> crosstalk? >> >>> Or do I have to resort to modifying the IronPython source to >>> accomplish this (which I'm loathe to do since then I would have to >>> maintain it going forward)? >>> >>> Thank you for your time and consideration in this matter. >>> >>> --------------------------------------------------------------------- >>> >> --- >> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >> -- >> http://www.ironpythoninaction.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 > -- http://www.ironpythoninaction.com/ From Jimmy.Schementi at microsoft.com Thu Apr 30 18:49:14 2009 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Thu, 30 Apr 2009 16:49:14 +0000 Subject: [IronPython] Is Silverlight 3 beta supported in Ironpython yet? In-Reply-To: <1dab55500904300800v7e714b8cma04272593eb0972e@mail.gmail.com> References: <1dab55500904300800v7e714b8cma04272593eb0972e@mail.gmail.com> Message-ID: <0047ECBFA2E0DF4A834AA369282A5AFC02C937@tk5ex14mbxc105.redmond.corp.microsoft.com> Yes, the binaries that ship in IronPython will work in SL3 Beta just fine. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kristian Jaksch Sent: Thursday, April 30, 2009 8:01 AM To: users at lists.ironpython.com Subject: [IronPython] Is Silverlight 3 beta supported in Ironpython yet? Does Ironpython support Silverlight 3 beta yet? /Kristian -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Apr 30 18:37:36 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Apr 2009 09:37:36 -0700 Subject: [IronPython] Docstrings on stuff in clr module In-Reply-To: References: <49F9BF7B.5050207@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A496@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <350E7D38B6D819428718949920EC23555728B8A4D8@NA-EXMSG-C102.redmond.corp.microsoft.com> There's the format the compiler generates w/ the /doc: option - I'm not sure how standardized it is but it's at least consistent :) When you install the .NET framework SDK you get XML doc files for all of the .NET framework installed into %WINDIR%\Microsoft.NET\Framework\v2.0.50727\en\... (or some other language instead of en). We already support reading and producing __doc__ from these XML files (using .NET's xml reading support and just looking for the values we know we need to pull out) it's just that we do something different for IronPython's own doc strings. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan March Sent: Thursday, April 30, 2009 9:20 AM To: Discussion of IronPython Subject: Re: [IronPython] Docstrings on stuff in clr module Is there a standardized protocol for XML docstrings? Then what software would you use to process them? On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland > wrote: Yes - I've opened a bug (22235 - http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). I want to generally improve the doc strings everywhere. I've slowly been pushing on this and my ultimate goal is to get all of the doc strings moved into XML comments and then we can read them from there. Then we just need to go through a big push and add XML doc comments everywhere :) If other people have APIs they want doc strings on please add them to the comments. But I can see clr being particularly problematic as it otherwise lacks documentation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Apr 30 18:52:02 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 17:52:02 +0100 Subject: [IronPython] Docstrings on stuff in clr module In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A4D8@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49F9BF7B.5050207@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A496@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B8A4D8@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49F9D732.3090108@voidspace.org.uk> Dino Viehland wrote: > > There?s the format the compiler generates w/ the /doc: option ? I?m > not sure how standardized it is but it?s at least consistent J When > you install the .NET framework SDK you get XML doc files for all of > the .NET framework installed into > %WINDIR%\Microsoft.NET\Framework\v2.0.50727\en\... (or some other > language instead of en). > > We already support reading and producing __doc__ from these XML files > (using .NET?s xml reading support and just looking for the values we > know we need to pull out) it?s just that we do something different for > IronPython?s own doc strings. > Yes - and those docstrings on the .NET types are *very* useful. :-) (So thanks for the integration.) I now get them in the Wing IDE source assistant when I am working with .NET objects. Michael > *From:* users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Jonathan March > *Sent:* Thursday, April 30, 2009 9:20 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Docstrings on stuff in clr module > > Is there a standardized protocol for XML docstrings? > Then what software would you use to process them? > > On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland > wrote: > > Yes - I've opened a bug (22235 - > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). > > I want to generally improve the doc strings everywhere. I've slowly > been pushing on this and my ultimate goal is to get all of the doc > strings moved into XML comments and then we can read them from there. > > Then we just need to go through a big push and add XML doc comments > everywhere :) > > If other people have APIs they want doc strings on please add them > to the comments. But I can see clr being particularly problematic > as it otherwise lacks documentation. > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From stephen.p.lepisto at intel.com Thu Apr 30 19:10:05 2009 From: stephen.p.lepisto at intel.com (Lepisto, Stephen P) Date: Thu, 30 Apr 2009 10:10:05 -0700 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A4CC@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9CCFB.8040601@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A4CC@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5E26@orsmsx510.amr.corp.intel.com> Dino, That example you provided produced the following output under IronPython 2.0.1: hello 42 In other words, the two sessions appear to be sharing the same module in IronPython 2.0.1. Are you using a later version of IronPython where this might be fixed? -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Thursday, April 30, 2009 9:28 AM To: Discussion of IronPython Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process And this works for me: using System; using IronPython.Hosting; using Microsoft.Scripting.Hosting; class foo { static void Main(string[] args) { var engine = Python.CreateEngine(); ScriptScope scope1 = engine.ImportModule("foo"); var engine2 = Python.CreateEngine(); ScriptScope scope2 = engine2.ImportModule("foo"); scope1.SetVariable("foo", 42); object res; if(scope2.TryGetVariable("foo", out res)) { Console.WriteLine(res); } else { Console.WriteLine("no foo"); } } } Foo.py: print 'hello' Printing out: hello hello no foo > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, April 30, 2009 9:08 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > Dino Viehland wrote: > > > > You mention CreateEngine but are you also creating multiple runtimes? > > You're only allowed 1 ScriptEngine of a given type per ScriptRuntime. > > So you should create a new ScriptRuntime and then get the Python > > engine for each runtime and then be isolated. > > > > If you call Python.CreateEngine() twice it gives you two different > engine objects with what *appear* to be different runtimes. > > If you then call Python.ImportModule for the same module but passing in > the two different engines, you get two different (non-identical > objects) > ScriptScopes - but changes in one are reflected in the other. > > Is CreateEngine not the correct way to get isolated engines? > > Michael > > > *From:* users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto, > > Stephen P > > *Sent:* Thursday, April 30, 2009 8:26 AM > > *To:* users at lists.ironpython.com > > *Subject:* [IronPython] Question on Multiple Discrete IronPython > > sessions in a single process > > > > Hello, everyone! > > > > I am working on an service manager application that provides embedded > > python support through a small set of generalized classes: > > PythonService, PythonSession, and PythonClass. A client application > > asks the service manager for the PythonService object and then asks > > the PythonService object for a new PythonSession object. The > > PythonSession object is used to access embedded python through a > small > > set of generalized methods. The PythonClass object is used to wrap a > > python class instance. > > > > The key requirement in this is each client must have its own python > > session, independent of any other sessions currently running. I've > got > > this to work with CPython (specifically, python 2.5.4), by careful > use > > of the global interpreter lock and swapping the thread state. > > IronPython 2.0.1 has a nicer way of implementing all of this by using > > the CreateEngine() to create a new python engine. However, in > > IronPython I've run into what appears to be a significant limitation > > that may prevent me from using IronPython in this particular > situation > > as an embedded language. > > > > The limitation is when I import a python package from disk into > > IronPython (using IronPython.Hosting.Python.ImportModule()) in one > > session and then import the same package into a different session, it > > turns out that both sessions are pulling from the same module's > scope. > > That is, if I make changes to the module's scope in one session (for > > example, changing a global variable), that change appears in the > other > > session. > > > > After tracing execution in the IronPython 2.0.1 code, it turns out > > that a module is cached in the LanguageContext (PythonContext) > object, > > which in turn is a singleton in DLR, as it is associated with the > > language type. This is okay if an application is embedding IronPython > > itself but in my scenario, this prevents multiple discrete python > > sessions in a single application. Ideally, I would expect to see the > > system state be stored in the python engine (ScriptEngine) or python > > runtime (ScriptRuntime) objects. > > > > Is there a way around this limitation? Can I somehow create a unique > > PythonContext object for each of my python sessions so I get a > > completely discrete python instance in each session with no > crosstalk? > > Or do I have to resort to modifying the IronPython source to > > accomplish this (which I'm loathe to do since then I would have to > > maintain it going forward)? > > > > Thank you for your time and consideration in this matter. > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Thu Apr 30 19:14:42 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Apr 2009 10:14:42 -0700 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: <49F9D5F3.6040408@voidspace.org.uk> References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9CCFB.8040601@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A4CC@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9D5F3.6040408@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23555728B8A51D@NA-EXMSG-C102.redmond.corp.microsoft.com> Ok, it's broken on 2.0.1 but not on 2.6. I've opened a 2.0.2 bug: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239 > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, April 30, 2009 9:47 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > Dino Viehland wrote: > > And this works for me: > > > > I just did the equivalent, from *inside* IronPython which may make a > difference, with the 'os' module and got the opposite result: > > >>> import clr > >>> clr.AddReference('IronPython') > >>> from IronPython.Hosting import Python# > >>> e1 = Python.CreateEngine() > >>> e2 = Python.CreateEngine() > >>> > >>> os1 = Python.ImportModule(e1, 'os') > >>> os2 = Python.ImportModule(e2, 'os') > >>> > >>> os1 > [Microsoft > .Scripting.Hosting.ScriptScope]> > >>> os1 is os2 > False > >>> os1.SetVariable('foo', 'bar') > >>> os2.GetVariable('foo') > 'bar' > >>> > > > All the best, > > Michael > > > using System; > > using IronPython.Hosting; > > using Microsoft.Scripting.Hosting; > > > > class foo { > > static void Main(string[] args) > > { > > var engine = Python.CreateEngine(); > > ScriptScope scope1 = engine.ImportModule("foo"); > > > > var engine2 = Python.CreateEngine(); > > ScriptScope scope2 = engine2.ImportModule("foo"); > > > > scope1.SetVariable("foo", 42); > > object res; > > if(scope2.TryGetVariable("foo", out res)) { > > Console.WriteLine(res); > > } else { > > Console.WriteLine("no foo"); > > } > > } > > } > > > > Foo.py: > > print 'hello' > > > > Printing out: > > > > hello > > hello > > no foo > > > > > >> -----Original Message----- > >> From: users-bounces at lists.ironpython.com [mailto:users- > >> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >> Sent: Thursday, April 30, 2009 9:08 AM > >> To: Discussion of IronPython > >> Subject: Re: [IronPython] Question on Multiple Discrete IronPython > >> sessions in a single process > >> > >> Dino Viehland wrote: > >> > >>> You mention CreateEngine but are you also creating multiple > runtimes? > >>> You're only allowed 1 ScriptEngine of a given type per > ScriptRuntime. > >>> So you should create a new ScriptRuntime and then get the Python > >>> engine for each runtime and then be isolated. > >>> > >>> > >> If you call Python.CreateEngine() twice it gives you two different > >> engine objects with what *appear* to be different runtimes. > >> > >> If you then call Python.ImportModule for the same module but passing > in > >> the two different engines, you get two different (non-identical > >> objects) > >> ScriptScopes - but changes in one are reflected in the other. > >> > >> Is CreateEngine not the correct way to get isolated engines? > >> > >> Michael > >> > >> > >>> *From:* users-bounces at lists.ironpython.com > >>> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto, > >>> Stephen P > >>> *Sent:* Thursday, April 30, 2009 8:26 AM > >>> *To:* users at lists.ironpython.com > >>> *Subject:* [IronPython] Question on Multiple Discrete IronPython > >>> sessions in a single process > >>> > >>> Hello, everyone! > >>> > >>> I am working on an service manager application that provides > embedded > >>> python support through a small set of generalized classes: > >>> PythonService, PythonSession, and PythonClass. A client application > >>> asks the service manager for the PythonService object and then asks > >>> the PythonService object for a new PythonSession object. The > >>> PythonSession object is used to access embedded python through a > >>> > >> small > >> > >>> set of generalized methods. The PythonClass object is used to wrap > a > >>> python class instance. > >>> > >>> The key requirement in this is each client must have its own python > >>> session, independent of any other sessions currently running. I've > >>> > >> got > >> > >>> this to work with CPython (specifically, python 2.5.4), by careful > >>> > >> use > >> > >>> of the global interpreter lock and swapping the thread state. > >>> IronPython 2.0.1 has a nicer way of implementing all of this by > using > >>> the CreateEngine() to create a new python engine. However, in > >>> IronPython I've run into what appears to be a significant > limitation > >>> that may prevent me from using IronPython in this particular > >>> > >> situation > >> > >>> as an embedded language. > >>> > >>> The limitation is when I import a python package from disk into > >>> IronPython (using IronPython.Hosting.Python.ImportModule()) in one > >>> session and then import the same package into a different session, > it > >>> turns out that both sessions are pulling from the same module's > >>> > >> scope. > >> > >>> That is, if I make changes to the module's scope in one session > (for > >>> example, changing a global variable), that change appears in the > >>> > >> other > >> > >>> session. > >>> > >>> After tracing execution in the IronPython 2.0.1 code, it turns out > >>> that a module is cached in the LanguageContext (PythonContext) > >>> > >> object, > >> > >>> which in turn is a singleton in DLR, as it is associated with the > >>> language type. This is okay if an application is embedding > IronPython > >>> itself but in my scenario, this prevents multiple discrete python > >>> sessions in a single application. Ideally, I would expect to see > the > >>> system state be stored in the python engine (ScriptEngine) or > python > >>> runtime (ScriptRuntime) objects. > >>> > >>> Is there a way around this limitation? Can I somehow create a > unique > >>> PythonContext object for each of my python sessions so I get a > >>> completely discrete python instance in each session with no > >>> > >> crosstalk? > >> > >>> Or do I have to resort to modifying the IronPython source to > >>> accomplish this (which I'm loathe to do since then I would have to > >>> maintain it going forward)? > >>> > >>> Thank you for your time and consideration in this matter. > >>> > >>> ------------------------------------------------------------------- > -- > >>> > >> --- > >> > >>> _______________________________________________ > >>> Users mailing list > >>> Users at lists.ironpython.com > >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >>> > >>> > >> -- > >> http://www.ironpythoninaction.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 > > > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Thu Apr 30 19:16:59 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Apr 2009 10:16:59 -0700 Subject: [IronPython] 2.6 Release Plan Message-ID: <350E7D38B6D819428718949920EC23555728B8A522@NA-EXMSG-C102.redmond.corp.microsoft.com> Based upon the feedback from the mailing list here's the 2.6 release plan and list of new features: http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Plan Let me know if you have any questions or think there's areas we should include more info on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Apr 30 19:23:21 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Apr 2009 10:23:21 -0700 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5E26@orsmsx510.amr.corp.intel.com> References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9CCFB.8040601@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A4CC@NA-EXMSG-C102.redmond.corp.microsoft.com> <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5E26@orsmsx510.amr.corp.intel.com> Message-ID: <350E7D38B6D819428718949920EC23555728B8A52A@NA-EXMSG-C102.redmond.corp.microsoft.com> Looks like our threads crossed. Yep, I was using the current 2.6 branch. I opened a bug to fix this in 2.0.2 (http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239). Thanks for reporting this - this is a very bad bug. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Lepisto, Stephen P > Sent: Thursday, April 30, 2009 10:10 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > Dino, > > That example you provided produced the following output under > IronPython 2.0.1: > > hello > 42 > > In other words, the two sessions appear to be sharing the same module > in IronPython 2.0.1. > > Are you using a later version of IronPython where this might be fixed? > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Thursday, April 30, 2009 9:28 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > And this works for me: > > using System; > using IronPython.Hosting; > using Microsoft.Scripting.Hosting; > > class foo { > static void Main(string[] args) > { > var engine = Python.CreateEngine(); > ScriptScope scope1 = engine.ImportModule("foo"); > > var engine2 = Python.CreateEngine(); > ScriptScope scope2 = engine2.ImportModule("foo"); > > scope1.SetVariable("foo", 42); > object res; > if(scope2.TryGetVariable("foo", out res)) { > Console.WriteLine(res); > } else { > Console.WriteLine("no foo"); > } > } > } > > Foo.py: > print 'hello' > > Printing out: > > hello > hello > no foo > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of Michael Foord > > Sent: Thursday, April 30, 2009 9:08 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > > sessions in a single process > > > > Dino Viehland wrote: > > > > > > You mention CreateEngine but are you also creating multiple > runtimes? > > > You're only allowed 1 ScriptEngine of a given type per > ScriptRuntime. > > > So you should create a new ScriptRuntime and then get the Python > > > engine for each runtime and then be isolated. > > > > > > > If you call Python.CreateEngine() twice it gives you two different > > engine objects with what *appear* to be different runtimes. > > > > If you then call Python.ImportModule for the same module but passing > in > > the two different engines, you get two different (non-identical > > objects) > > ScriptScopes - but changes in one are reflected in the other. > > > > Is CreateEngine not the correct way to get isolated engines? > > > > Michael > > > > > *From:* users-bounces at lists.ironpython.com > > > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto, > > > Stephen P > > > *Sent:* Thursday, April 30, 2009 8:26 AM > > > *To:* users at lists.ironpython.com > > > *Subject:* [IronPython] Question on Multiple Discrete IronPython > > > sessions in a single process > > > > > > Hello, everyone! > > > > > > I am working on an service manager application that provides > embedded > > > python support through a small set of generalized classes: > > > PythonService, PythonSession, and PythonClass. A client application > > > asks the service manager for the PythonService object and then asks > > > the PythonService object for a new PythonSession object. The > > > PythonSession object is used to access embedded python through a > > small > > > set of generalized methods. The PythonClass object is used to wrap > a > > > python class instance. > > > > > > The key requirement in this is each client must have its own python > > > session, independent of any other sessions currently running. I've > > got > > > this to work with CPython (specifically, python 2.5.4), by careful > > use > > > of the global interpreter lock and swapping the thread state. > > > IronPython 2.0.1 has a nicer way of implementing all of this by > using > > > the CreateEngine() to create a new python engine. However, in > > > IronPython I've run into what appears to be a significant > limitation > > > that may prevent me from using IronPython in this particular > > situation > > > as an embedded language. > > > > > > The limitation is when I import a python package from disk into > > > IronPython (using IronPython.Hosting.Python.ImportModule()) in one > > > session and then import the same package into a different session, > it > > > turns out that both sessions are pulling from the same module's > > scope. > > > That is, if I make changes to the module's scope in one session > (for > > > example, changing a global variable), that change appears in the > > other > > > session. > > > > > > After tracing execution in the IronPython 2.0.1 code, it turns out > > > that a module is cached in the LanguageContext (PythonContext) > > object, > > > which in turn is a singleton in DLR, as it is associated with the > > > language type. This is okay if an application is embedding > IronPython > > > itself but in my scenario, this prevents multiple discrete python > > > sessions in a single application. Ideally, I would expect to see > the > > > system state be stored in the python engine (ScriptEngine) or > python > > > runtime (ScriptRuntime) objects. > > > > > > Is there a way around this limitation? Can I somehow create a > unique > > > PythonContext object for each of my python sessions so I get a > > > completely discrete python instance in each session with no > > crosstalk? > > > Or do I have to resort to modifying the IronPython source to > > > accomplish this (which I'm loathe to do since then I would have to > > > maintain it going forward)? > > > > > > Thank you for your time and consideration in this matter. > > > > > > ------------------------------------------------------------------- > -- > > --- > > > > > > _______________________________________________ > > > Users mailing list > > > Users at lists.ironpython.com > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > -- > > http://www.ironpythoninaction.com/ > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From stephen.p.lepisto at intel.com Thu Apr 30 19:25:51 2009 From: stephen.p.lepisto at intel.com (Lepisto, Stephen P) Date: Thu, 30 Apr 2009 10:25:51 -0700 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A52A@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9CCFB.8040601@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A4CC@NA-EXMSG-C102.redmond.corp.microsoft.com> <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5E26@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A52A@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <6AF28EB9F93A354894F2F3916DF6F96E0C6E82C1BA@orsmsx510.amr.corp.intel.com> I voted for fixing the bug. In the meantime, I will be putting on hold the use of IronPython as an embedded language in my project until this is fixed or IronPython 2.6 is released (if I can convince my manager and team it's a good idea to move to python 2.6 but it will affect a lot of people). Thank you for the prompt responses! -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Thursday, April 30, 2009 10:23 AM To: Discussion of IronPython Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process Looks like our threads crossed. Yep, I was using the current 2.6 branch. I opened a bug to fix this in 2.0.2 (http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239). Thanks for reporting this - this is a very bad bug. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Lepisto, Stephen P > Sent: Thursday, April 30, 2009 10:10 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > Dino, > > That example you provided produced the following output under > IronPython 2.0.1: > > hello > 42 > > In other words, the two sessions appear to be sharing the same module > in IronPython 2.0.1. > > Are you using a later version of IronPython where this might be fixed? > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Thursday, April 30, 2009 9:28 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > And this works for me: > > using System; > using IronPython.Hosting; > using Microsoft.Scripting.Hosting; > > class foo { > static void Main(string[] args) > { > var engine = Python.CreateEngine(); > ScriptScope scope1 = engine.ImportModule("foo"); > > var engine2 = Python.CreateEngine(); > ScriptScope scope2 = engine2.ImportModule("foo"); > > scope1.SetVariable("foo", 42); > object res; > if(scope2.TryGetVariable("foo", out res)) { > Console.WriteLine(res); > } else { > Console.WriteLine("no foo"); > } > } > } > > Foo.py: > print 'hello' > > Printing out: > > hello > hello > no foo > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of Michael Foord > > Sent: Thursday, April 30, 2009 9:08 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > > sessions in a single process > > > > Dino Viehland wrote: > > > > > > You mention CreateEngine but are you also creating multiple > runtimes? > > > You're only allowed 1 ScriptEngine of a given type per > ScriptRuntime. > > > So you should create a new ScriptRuntime and then get the Python > > > engine for each runtime and then be isolated. > > > > > > > If you call Python.CreateEngine() twice it gives you two different > > engine objects with what *appear* to be different runtimes. > > > > If you then call Python.ImportModule for the same module but passing > in > > the two different engines, you get two different (non-identical > > objects) > > ScriptScopes - but changes in one are reflected in the other. > > > > Is CreateEngine not the correct way to get isolated engines? > > > > Michael > > > > > *From:* users-bounces at lists.ironpython.com > > > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto, > > > Stephen P > > > *Sent:* Thursday, April 30, 2009 8:26 AM > > > *To:* users at lists.ironpython.com > > > *Subject:* [IronPython] Question on Multiple Discrete IronPython > > > sessions in a single process > > > > > > Hello, everyone! > > > > > > I am working on an service manager application that provides > embedded > > > python support through a small set of generalized classes: > > > PythonService, PythonSession, and PythonClass. A client application > > > asks the service manager for the PythonService object and then asks > > > the PythonService object for a new PythonSession object. The > > > PythonSession object is used to access embedded python through a > > small > > > set of generalized methods. The PythonClass object is used to wrap > a > > > python class instance. > > > > > > The key requirement in this is each client must have its own python > > > session, independent of any other sessions currently running. I've > > got > > > this to work with CPython (specifically, python 2.5.4), by careful > > use > > > of the global interpreter lock and swapping the thread state. > > > IronPython 2.0.1 has a nicer way of implementing all of this by > using > > > the CreateEngine() to create a new python engine. However, in > > > IronPython I've run into what appears to be a significant > limitation > > > that may prevent me from using IronPython in this particular > > situation > > > as an embedded language. > > > > > > The limitation is when I import a python package from disk into > > > IronPython (using IronPython.Hosting.Python.ImportModule()) in one > > > session and then import the same package into a different session, > it > > > turns out that both sessions are pulling from the same module's > > scope. > > > That is, if I make changes to the module's scope in one session > (for > > > example, changing a global variable), that change appears in the > > other > > > session. > > > > > > After tracing execution in the IronPython 2.0.1 code, it turns out > > > that a module is cached in the LanguageContext (PythonContext) > > object, > > > which in turn is a singleton in DLR, as it is associated with the > > > language type. This is okay if an application is embedding > IronPython > > > itself but in my scenario, this prevents multiple discrete python > > > sessions in a single application. Ideally, I would expect to see > the > > > system state be stored in the python engine (ScriptEngine) or > python > > > runtime (ScriptRuntime) objects. > > > > > > Is there a way around this limitation? Can I somehow create a > unique > > > PythonContext object for each of my python sessions so I get a > > > completely discrete python instance in each session with no > > crosstalk? > > > Or do I have to resort to modifying the IronPython source to > > > accomplish this (which I'm loathe to do since then I would have to > > > maintain it going forward)? > > > > > > Thank you for your time and consideration in this matter. > > > > > > ------------------------------------------------------------------- > -- > > --- > > > > > > _______________________________________________ > > > Users mailing list > > > Users at lists.ironpython.com > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > -- > > http://www.ironpythoninaction.com/ > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From curt at hagenlocher.org Thu Apr 30 19:30:38 2009 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 30 Apr 2009 10:30:38 -0700 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: <6AF28EB9F93A354894F2F3916DF6F96E0C6E82C1BA@orsmsx510.amr.corp.intel.com> References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9CCFB.8040601@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A4CC@NA-EXMSG-C102.redmond.corp.microsoft.com> <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5E26@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A52A@NA-EXMSG-C102.redmond.corp.microsoft.com> <6AF28EB9F93A354894F2F3916DF6F96E0C6E82C1BA@orsmsx510.amr.corp.intel.com> Message-ID: If you import by executing the text "import " against the ScriptEngine instead of using the import API, you will avoid this particular incarnation of the bug. On Thu, Apr 30, 2009 at 10:25 AM, Lepisto, Stephen P < stephen.p.lepisto at intel.com> wrote: > I voted for fixing the bug. In the meantime, I will be putting on hold the > use of IronPython as an embedded language in my project until this is fixed > or IronPython 2.6 is released (if I can convince my manager and team it's a > good idea to move to python 2.6 but it will affect a lot of people). > > Thank you for the prompt responses! > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Thursday, April 30, 2009 10:23 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions > in a single process > > Looks like our threads crossed. Yep, I was using the current 2.6 branch. > > I opened a bug to fix this in 2.0.2 ( > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239). > > Thanks for reporting this - this is a very bad bug. > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of Lepisto, Stephen P > > Sent: Thursday, April 30, 2009 10:10 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > > sessions in a single process > > > > Dino, > > > > That example you provided produced the following output under > > IronPython 2.0.1: > > > > hello > > 42 > > > > In other words, the two sessions appear to be sharing the same module > > in IronPython 2.0.1. > > > > Are you using a later version of IronPython where this might be fixed? > > > > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > > Sent: Thursday, April 30, 2009 9:28 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > > sessions in a single process > > > > And this works for me: > > > > using System; > > using IronPython.Hosting; > > using Microsoft.Scripting.Hosting; > > > > class foo { > > static void Main(string[] args) > > { > > var engine = Python.CreateEngine(); > > ScriptScope scope1 = engine.ImportModule("foo"); > > > > var engine2 = Python.CreateEngine(); > > ScriptScope scope2 = engine2.ImportModule("foo"); > > > > scope1.SetVariable("foo", 42); > > object res; > > if(scope2.TryGetVariable("foo", out res)) { > > Console.WriteLine(res); > > } else { > > Console.WriteLine("no foo"); > > } > > } > > } > > > > Foo.py: > > print 'hello' > > > > Printing out: > > > > hello > > hello > > no foo > > > > > -----Original Message----- > > > From: users-bounces at lists.ironpython.com [mailto:users- > > > bounces at lists.ironpython.com] On Behalf Of Michael Foord > > > Sent: Thursday, April 30, 2009 9:08 AM > > > To: Discussion of IronPython > > > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > > > sessions in a single process > > > > > > Dino Viehland wrote: > > > > > > > > You mention CreateEngine but are you also creating multiple > > runtimes? > > > > You're only allowed 1 ScriptEngine of a given type per > > ScriptRuntime. > > > > So you should create a new ScriptRuntime and then get the Python > > > > engine for each runtime and then be isolated. > > > > > > > > > > If you call Python.CreateEngine() twice it gives you two different > > > engine objects with what *appear* to be different runtimes. > > > > > > If you then call Python.ImportModule for the same module but passing > > in > > > the two different engines, you get two different (non-identical > > > objects) > > > ScriptScopes - but changes in one are reflected in the other. > > > > > > Is CreateEngine not the correct way to get isolated engines? > > > > > > Michael > > > > > > > *From:* users-bounces at lists.ironpython.com > > > > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto, > > > > Stephen P > > > > *Sent:* Thursday, April 30, 2009 8:26 AM > > > > *To:* users at lists.ironpython.com > > > > *Subject:* [IronPython] Question on Multiple Discrete IronPython > > > > sessions in a single process > > > > > > > > Hello, everyone! > > > > > > > > I am working on an service manager application that provides > > embedded > > > > python support through a small set of generalized classes: > > > > PythonService, PythonSession, and PythonClass. A client application > > > > asks the service manager for the PythonService object and then asks > > > > the PythonService object for a new PythonSession object. The > > > > PythonSession object is used to access embedded python through a > > > small > > > > set of generalized methods. The PythonClass object is used to wrap > > a > > > > python class instance. > > > > > > > > The key requirement in this is each client must have its own python > > > > session, independent of any other sessions currently running. I've > > > got > > > > this to work with CPython (specifically, python 2.5.4), by careful > > > use > > > > of the global interpreter lock and swapping the thread state. > > > > IronPython 2.0.1 has a nicer way of implementing all of this by > > using > > > > the CreateEngine() to create a new python engine. However, in > > > > IronPython I've run into what appears to be a significant > > limitation > > > > that may prevent me from using IronPython in this particular > > > situation > > > > as an embedded language. > > > > > > > > The limitation is when I import a python package from disk into > > > > IronPython (using IronPython.Hosting.Python.ImportModule()) in one > > > > session and then import the same package into a different session, > > it > > > > turns out that both sessions are pulling from the same module's > > > scope. > > > > That is, if I make changes to the module's scope in one session > > (for > > > > example, changing a global variable), that change appears in the > > > other > > > > session. > > > > > > > > After tracing execution in the IronPython 2.0.1 code, it turns out > > > > that a module is cached in the LanguageContext (PythonContext) > > > object, > > > > which in turn is a singleton in DLR, as it is associated with the > > > > language type. This is okay if an application is embedding > > IronPython > > > > itself but in my scenario, this prevents multiple discrete python > > > > sessions in a single application. Ideally, I would expect to see > > the > > > > system state be stored in the python engine (ScriptEngine) or > > python > > > > runtime (ScriptRuntime) objects. > > > > > > > > Is there a way around this limitation? Can I somehow create a > > unique > > > > PythonContext object for each of my python sessions so I get a > > > > completely discrete python instance in each session with no > > > crosstalk? > > > > Or do I have to resort to modifying the IronPython source to > > > > accomplish this (which I'm loathe to do since then I would have to > > > > maintain it going forward)? > > > > > > > > Thank you for your time and consideration in this matter. > > > > > > > > ------------------------------------------------------------------- > > -- > > > --- > > > > > > > > _______________________________________________ > > > > Users mailing list > > > > Users at lists.ironpython.com > > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > > > > > -- > > > http://www.ironpythoninaction.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 stephen.p.lepisto at intel.com Thu Apr 30 19:53:16 2009 From: stephen.p.lepisto at intel.com (Lepisto, Stephen P) Date: Thu, 30 Apr 2009 10:53:16 -0700 Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process In-Reply-To: References: <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5C25@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A499@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9CCFB.8040601@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A4CC@NA-EXMSG-C102.redmond.corp.microsoft.com> <6AF28EB9F93A354894F2F3916DF6F96E0C6E7C5E26@orsmsx510.amr.corp.intel.com> <350E7D38B6D819428718949920EC23555728B8A52A@NA-EXMSG-C102.redmond.corp.microsoft.com> <6AF28EB9F93A354894F2F3916DF6F96E0C6E82C1BA@orsmsx510.amr.corp.intel.com> Message-ID: <6AF28EB9F93A354894F2F3916DF6F96E0C6E82C237@orsmsx510.amr.corp.intel.com> Curt, thanks for the tip. In my tests, I needed to use "from import *" since I needed the attributes in the module to be in the current scope. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Thursday, April 30, 2009 10:31 AM To: Discussion of IronPython Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process If you import by executing the text "import " against the ScriptEngine instead of using the import API, you will avoid this particular incarnation of the bug. On Thu, Apr 30, 2009 at 10:25 AM, Lepisto, Stephen P > wrote: I voted for fixing the bug. In the meantime, I will be putting on hold the use of IronPython as an embedded language in my project until this is fixed or IronPython 2.6 is released (if I can convince my manager and team it's a good idea to move to python 2.6 but it will affect a lot of people). Thank you for the prompt responses! -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Thursday, April 30, 2009 10:23 AM To: Discussion of IronPython Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process Looks like our threads crossed. Yep, I was using the current 2.6 branch. I opened a bug to fix this in 2.0.2 (http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239). Thanks for reporting this - this is a very bad bug. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Lepisto, Stephen P > Sent: Thursday, April 30, 2009 10:10 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > Dino, > > That example you provided produced the following output under > IronPython 2.0.1: > > hello > 42 > > In other words, the two sessions appear to be sharing the same module > in IronPython 2.0.1. > > Are you using a later version of IronPython where this might be fixed? > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Thursday, April 30, 2009 9:28 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > sessions in a single process > > And this works for me: > > using System; > using IronPython.Hosting; > using Microsoft.Scripting.Hosting; > > class foo { > static void Main(string[] args) > { > var engine = Python.CreateEngine(); > ScriptScope scope1 = engine.ImportModule("foo"); > > var engine2 = Python.CreateEngine(); > ScriptScope scope2 = engine2.ImportModule("foo"); > > scope1.SetVariable("foo", 42); > object res; > if(scope2.TryGetVariable("foo", out res)) { > Console.WriteLine(res); > } else { > Console.WriteLine("no foo"); > } > } > } > > Foo.py: > print 'hello' > > Printing out: > > hello > hello > no foo > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of Michael Foord > > Sent: Thursday, April 30, 2009 9:08 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Question on Multiple Discrete IronPython > > sessions in a single process > > > > Dino Viehland wrote: > > > > > > You mention CreateEngine but are you also creating multiple > runtimes? > > > You're only allowed 1 ScriptEngine of a given type per > ScriptRuntime. > > > So you should create a new ScriptRuntime and then get the Python > > > engine for each runtime and then be isolated. > > > > > > > If you call Python.CreateEngine() twice it gives you two different > > engine objects with what *appear* to be different runtimes. > > > > If you then call Python.ImportModule for the same module but passing > in > > the two different engines, you get two different (non-identical > > objects) > > ScriptScopes - but changes in one are reflected in the other. > > > > Is CreateEngine not the correct way to get isolated engines? > > > > Michael > > > > > *From:* users-bounces at lists.ironpython.com > > > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Lepisto, > > > Stephen P > > > *Sent:* Thursday, April 30, 2009 8:26 AM > > > *To:* users at lists.ironpython.com > > > *Subject:* [IronPython] Question on Multiple Discrete IronPython > > > sessions in a single process > > > > > > Hello, everyone! > > > > > > I am working on an service manager application that provides > embedded > > > python support through a small set of generalized classes: > > > PythonService, PythonSession, and PythonClass. A client application > > > asks the service manager for the PythonService object and then asks > > > the PythonService object for a new PythonSession object. The > > > PythonSession object is used to access embedded python through a > > small > > > set of generalized methods. The PythonClass object is used to wrap > a > > > python class instance. > > > > > > The key requirement in this is each client must have its own python > > > session, independent of any other sessions currently running. I've > > got > > > this to work with CPython (specifically, python 2.5.4), by careful > > use > > > of the global interpreter lock and swapping the thread state. > > > IronPython 2.0.1 has a nicer way of implementing all of this by > using > > > the CreateEngine() to create a new python engine. However, in > > > IronPython I've run into what appears to be a significant > limitation > > > that may prevent me from using IronPython in this particular > > situation > > > as an embedded language. > > > > > > The limitation is when I import a python package from disk into > > > IronPython (using IronPython.Hosting.Python.ImportModule()) in one > > > session and then import the same package into a different session, > it > > > turns out that both sessions are pulling from the same module's > > scope. > > > That is, if I make changes to the module's scope in one session > (for > > > example, changing a global variable), that change appears in the > > other > > > session. > > > > > > After tracing execution in the IronPython 2.0.1 code, it turns out > > > that a module is cached in the LanguageContext (PythonContext) > > object, > > > which in turn is a singleton in DLR, as it is associated with the > > > language type. This is okay if an application is embedding > IronPython > > > itself but in my scenario, this prevents multiple discrete python > > > sessions in a single application. Ideally, I would expect to see > the > > > system state be stored in the python engine (ScriptEngine) or > python > > > runtime (ScriptRuntime) objects. > > > > > > Is there a way around this limitation? Can I somehow create a > unique > > > PythonContext object for each of my python sessions so I get a > > > completely discrete python instance in each session with no > > crosstalk? > > > Or do I have to resort to modifying the IronPython source to > > > accomplish this (which I'm loathe to do since then I would have to > > > maintain it going forward)? > > > > > > Thank you for your time and consideration in this matter. > > > > > > ------------------------------------------------------------------- > -- > > --- > > > > > > _______________________________________________ > > > Users mailing list > > > Users at lists.ironpython.com > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > -- > > http://www.ironpythoninaction.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 JDM at MarchRay.net Thu Apr 30 20:09:42 2009 From: JDM at MarchRay.net (Jonathan March) Date: Thu, 30 Apr 2009 13:09:42 -0500 Subject: [IronPython] Docstrings on stuff in clr module In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A4D8@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <49F9BF7B.5050207@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A496@NA-EXMSG-C102.redmond.corp.microsoft.com> <350E7D38B6D819428718949920EC23555728B8A4D8@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: Thanks! --- .NET newb On Thu, Apr 30, 2009 at 11:37 AM, Dino Viehland wrote: > There?s the format the compiler generates w/ the /doc: option ? I?m not > sure how standardized it is but it?s at least consistent J When you > install the .NET framework SDK you get XML doc files for all of the .NET > framework installed into %WINDIR%\Microsoft.NET\Framework\v2.0.50727\en\... > (or some other language instead of en). > > > > We already support reading and producing __doc__ from these XML files > (using .NET?s xml reading support and just looking for the values we know we > need to pull out) it?s just that we do something different for IronPython?s > own doc strings. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Jonathan March > *Sent:* Thursday, April 30, 2009 9:20 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Docstrings on stuff in clr module > > > > Is there a standardized protocol for XML docstrings? > Then what software would you use to process them? > > On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland > wrote: > > Yes - I've opened a bug (22235 - > http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). > > I want to generally improve the doc strings everywhere. I've slowly > been pushing on this and my ultimate goal is to get all of the doc > strings moved into XML comments and then we can read them from there. > > Then we just need to go through a big push and add XML doc comments > everywhere :) > > If other people have APIs they want doc strings on please add them > to the comments. But I can see clr being particularly problematic > as it otherwise lacks documentation. > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Apr 30 21:25:35 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 20:25:35 +0100 Subject: [IronPython] 2.6 Release Plan In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A522@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <350E7D38B6D819428718949920EC23555728B8A522@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49F9FB2F.8040802@voidspace.org.uk> Dino Viehland wrote: > > Based upon the feedback from the mailing list here?s the 2.6 release > plan and list of new features: > > http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Plan > > Let me know if you have any questions or think there?s areas we should > include more info on. > The profiler API that Curt blogged about isn't on this list. Is it an oversight or has it been dropped? I notice that there is no mention of sys._getframe; does this mean it definitely won't be something we see in 2.6? Shame there is still no sign of the csv module. ;-) Anyway - thanks for the schedule, very helpful. All the best, Michael Foord > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu Apr 30 21:40:02 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Apr 2009 12:40:02 -0700 Subject: [IronPython] 2.6 Release Plan In-Reply-To: <49F9FB2F.8040802@voidspace.org.uk> References: <350E7D38B6D819428718949920EC23555728B8A522@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9FB2F.8040802@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23555728B8A604@NA-EXMSG-C102.redmond.corp.microsoft.com> Both of those are just oversights - thanks for the reminder. I do have an implementation of _getframe I've just held off on checking it in while I try and figure out if I can make it faster someway. Harry had been playing with around implementing a csv module. If he manages to get it all done then we'll include it. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, April 30, 2009 12:26 PM > To: Discussion of IronPython > Subject: Re: [IronPython] 2.6 Release Plan > > Dino Viehland wrote: > > > > Based upon the feedback from the mailing list here's the 2.6 release > > plan and list of new features: > > > > > http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Pla > n > > > > Let me know if you have any questions or think there's areas we > should > > include more info on. > > > > The profiler API that Curt blogged about isn't on this list. Is it an > oversight or has it been dropped? > > I notice that there is no mention of sys._getframe; does this mean it > definitely won't be something we see in 2.6? > > Shame there is still no sign of the csv module. ;-) > > Anyway - thanks for the schedule, very helpful. > > All the best, > > Michael Foord > > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > 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 fuzzyman at voidspace.org.uk Thu Apr 30 21:45:59 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 20:45:59 +0100 Subject: [IronPython] 2.6 Release Plan In-Reply-To: <350E7D38B6D819428718949920EC23555728B8A604@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <350E7D38B6D819428718949920EC23555728B8A522@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9FB2F.8040802@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A604@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49F9FFF7.4030703@voidspace.org.uk> Dino Viehland wrote: > Both of those are just oversights - thanks for the > reminder. I do have an implementation of _getframe I've > just held off on checking it in while I try and figure > out if I can make it faster someway. > > Harry had been playing with around implementing a csv module. > If he manages to get it all done then we'll include it. > > All great news - thanks! Michael >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Thursday, April 30, 2009 12:26 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] 2.6 Release Plan >> >> Dino Viehland wrote: >> >>> Based upon the feedback from the mailing list here's the 2.6 release >>> plan and list of new features: >>> >>> >>> >> http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Pla >> n >> >>> Let me know if you have any questions or think there's areas we >>> >> should >> >>> include more info on. >>> >>> >> The profiler API that Curt blogged about isn't on this list. Is it an >> oversight or has it been dropped? >> >> I notice that there is no mention of sys._getframe; does this mean it >> definitely won't be something we see in 2.6? >> >> Shame there is still no sign of the csv module. ;-) >> >> Anyway - thanks for the schedule, very helpful. >> >> All the best, >> >> Michael Foord >> >> >> >> >>> --------------------------------------------------------------------- >>> >> --- >> >>> _______________________________________________ >>> 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 > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From fuzzyman at voidspace.org.uk Thu Apr 30 21:58:25 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 20:58:25 +0100 Subject: [IronPython] 2.6 Release Plan In-Reply-To: <49F9FFF7.4030703@voidspace.org.uk> References: <350E7D38B6D819428718949920EC23555728B8A522@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9FB2F.8040802@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A604@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9FFF7.4030703@voidspace.org.uk> Message-ID: <49FA02E1.4010508@voidspace.org.uk> Michael Foord wrote: > Dino Viehland wrote: >> Both of those are just oversights - thanks for the >> reminder. I do have an implementation of _getframe I've >> just held off on checking it in while I try and figure >> out if I can make it faster someway. >> >> Harry had been playing with around implementing a csv module. If he >> manages to get it all done then we'll include it. >> > > All great news - thanks! Oh, and when is 2.0.2 coming? You had to know this question was coming right? :-) Michael > > Michael > > >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users- >>> bounces at lists.ironpython.com] On Behalf Of Michael Foord >>> Sent: Thursday, April 30, 2009 12:26 PM >>> To: Discussion of IronPython >>> Subject: Re: [IronPython] 2.6 Release Plan >>> >>> Dino Viehland wrote: >>> >>>> Based upon the feedback from the mailing list here's the 2.6 release >>>> plan and list of new features: >>>> >>>> >>>> >>> http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Pla >>> n >>> >>>> Let me know if you have any questions or think there's areas we >>>> >>> should >>> >>>> include more info on. >>>> >>>> >>> The profiler API that Curt blogged about isn't on this list. Is it an >>> oversight or has it been dropped? >>> >>> I notice that there is no mention of sys._getframe; does this mean it >>> definitely won't be something we see in 2.6? >>> >>> Shame there is still no sign of the csv module. ;-) >>> >>> Anyway - thanks for the schedule, very helpful. >>> >>> All the best, >>> >>> Michael Foord >>> >>> >>> >>> >>>> --------------------------------------------------------------------- >>>> >>> --- >>> >>>> _______________________________________________ >>>> 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 >> > > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From dinov at microsoft.com Thu Apr 30 22:18:08 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Apr 2009 13:18:08 -0700 Subject: [IronPython] 2.6 Release Plan In-Reply-To: <49FA02E1.4010508@voidspace.org.uk> References: <350E7D38B6D819428718949920EC23555728B8A522@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9FB2F.8040802@voidspace.org.uk> <350E7D38B6D819428718949920EC23555728B8A604@NA-EXMSG-C102.redmond.corp.microsoft.com> <49F9FFF7.4030703@voidspace.org.uk> <49FA02E1.4010508@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23555728EEE543@NA-EXMSG-C102.redmond.corp.microsoft.com> Sigh, I've been putting it off trying to get all the goodies into 2.6. Now would be a good time to ask what people would like to see fixed. And if I had to take a guess I'd say it'd be a little bit after 2.6B1 but I should discuss it with the team :) > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, April 30, 2009 12:58 PM > To: Discussion of IronPython > Subject: Re: [IronPython] 2.6 Release Plan > > Michael Foord wrote: > > Dino Viehland wrote: > >> Both of those are just oversights - thanks for the > >> reminder. I do have an implementation of _getframe I've > >> just held off on checking it in while I try and figure > >> out if I can make it faster someway. > >> > >> Harry had been playing with around implementing a csv module. If he > >> manages to get it all done then we'll include it. > >> > > > > All great news - thanks! > > Oh, and when is 2.0.2 coming? > > You had to know this question was coming right? :-) > > Michael > > > > > Michael > > > > > >>> -----Original Message----- > >>> From: users-bounces at lists.ironpython.com [mailto:users- > >>> bounces at lists.ironpython.com] On Behalf Of Michael Foord > >>> Sent: Thursday, April 30, 2009 12:26 PM > >>> To: Discussion of IronPython > >>> Subject: Re: [IronPython] 2.6 Release Plan > >>> > >>> Dino Viehland wrote: > >>> > >>>> Based upon the feedback from the mailing list here's the 2.6 > release > >>>> plan and list of new features: > >>>> > >>>> > >>>> > >>> > http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Pla > >>> n > >>> > >>>> Let me know if you have any questions or think there's areas we > >>>> > >>> should > >>> > >>>> include more info on. > >>>> > >>>> > >>> The profiler API that Curt blogged about isn't on this list. Is it > an > >>> oversight or has it been dropped? > >>> > >>> I notice that there is no mention of sys._getframe; does this mean > it > >>> definitely won't be something we see in 2.6? > >>> > >>> Shame there is still no sign of the csv module. ;-) > >>> > >>> Anyway - thanks for the schedule, very helpful. > >>> > >>> All the best, > >>> > >>> Michael Foord > >>> > >>> > >>> > >>> > >>>> ------------------------------------------------------------------ > --- > >>>> > >>> --- > >>> > >>>> _______________________________________________ > >>>> 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 > >> > > > > > > > -- > 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 Thu Apr 30 22:23:08 2009 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Apr 2009 13:23:08 -0700 Subject: [IronPython] 2.0.2 Bugs Message-ID: <350E7D38B6D819428718949920EC23555728EEE550@NA-EXMSG-C102.redmond.corp.microsoft.com> Michael just brought this up on another thread but I thought I'd make it obvious. Let us know what bugs you particularly want to see fixed in 2.0.2. Nominate them here and we'll collect the list and try to fix as many as possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harriv at gmail.com Thu Apr 30 22:37:45 2009 From: harriv at gmail.com (Harriv) Date: Thu, 30 Apr 2009 23:37:45 +0300 Subject: [IronPython] "IDLE like" functionality In-Reply-To: <49F83D98.9060608@voidspace.org.uk> References: <20253b0c0904290435q459f5887s63da4adb16b724ac@mail.gmail.com> <49F83D98.9060608@voidspace.org.uk> Message-ID: Davy, Thanks.IronTextBox is just what I needed. It needed some minor changes to get running on latest IronPython version but so far looking good. On Wed, Apr 29, 2009 at 2:44 PM, Michael Foord wrote: > > There is also IronTextBox which is an IronPython console in a Windows Forms > TextBox > > You will probably need to update it for 2.0.1 but it is probably what you > want. > > http://www.codeproject.com/KB/edit/irontextbox2.aspx > > Michael >> >> Davy >> >> On Wed, Apr 29, 2009 at 9:21 AM, Harriv wrote: >> >>> >>> Hi, >>> ?A beginner's question: Is there a tutorial/demo/sample project to show >>> how >>> embed "IDLE like" functionality in C# WinForms application? >>> ?So basically I'd like to add interactive command line to my application, >>> but of course all other features of IDLE (eg debugging, code editors etc) >>> must be left out. >>> _______________________________________________ >>> 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/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From fuzzyman at voidspace.org.uk Thu Apr 30 22:50:53 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Apr 2009 21:50:53 +0100 Subject: [IronPython] 2.0.2 Bugs In-Reply-To: <350E7D38B6D819428718949920EC23555728EEE550@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <350E7D38B6D819428718949920EC23555728EEE550@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <49FA0F2D.5080507@voidspace.org.uk> Dino Viehland wrote: > > Michael just brought this up on another thread but I thought I?d make > it obvious. > > Let us know what bugs you particularly want to see fixed in 2.0.2. > Nominate them here and we?ll collect the list and try to fix as many > as possible. > Below are the ones I'm aware of that have affected Resolver One or that I feel are important. :-) Issue 21715 __file__ incorrect for Pyc compiled modules (!!!! important) Issue 19656 module name lookup broken Issue 22235 docstrings Issue 22239 modules aren't isolated Issue 21574 import thread safety Issue 21947 None + '' Issue 21929 os.listdir('') (A particularly annoying one) - also issue 20603 which is probably the same issue Issue 21659 Unicode subclasses with non string input in constructor. (Marked as fixed but probably not in 2.0!) Issue 21445 IronPython 2.0.1 hang Issue 21422 Traceback truncation + issue 20051 Issue 20275 str subclasses not treated as strings Issue 20236 unhelpful help for type Issue 19724 convert callable to delegate There are two other issues that might be suitable that I can't find the numbers for: Passing '\' to InteractiveConsole.runsource Repr of SyntaxError messages unchanged when a newline is added (breaks the code module). It would be really good to fix the various Pyc bugs - like sys.argv not being passed through correctly. Michael > ------------------------------------------------------------------------ > > _______________________________________________ > 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 daftspaniel at gmail.com Thu Apr 30 23:15:24 2009 From: daftspaniel at gmail.com (Davy Mitchell) Date: Thu, 30 Apr 2009 22:15:24 +0100 Subject: [IronPython] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator) In-Reply-To: References: <49F64584.70207@voidspace.org.uk> <49F867E0.5060807@voidspace.org.uk> Message-ID: <20253b0c0904301415q6ed73dabucc6ee71b61f98de4@mail.gmail.com> On Thu, Apr 30, 2009 at 12:43 AM, Jimmie Houchin wrote: > This sounds great. I am new to both IronPython, WingIDE and Windows > development in general. Interesting to see how much developers want autocomplete! I tried to start adding this to DIE tonight but was struggling with the code editor component. Unfortunately the project looks a little stagnant. Does anyone know of any other good free syntax highlighting .net editor components? Thanks, Davy Mitchell http://code.google.com/p/davysironpythoneditor/