From anders.elfgren at avalanchestudios.se Fri Aug 1 13:25:26 2008 From: anders.elfgren at avalanchestudios.se (Anders Elfgren) Date: Fri, 1 Aug 2008 13:25:26 +0200 Subject: [IronPython] Using a c library as a dll or assembly In-Reply-To: References: <698E8783CC407F4EB0DC9E994B6D4540906D64@nut.avalanchestudios.se> Message-ID: <698E8783CC407F4EB0DC9E994B6D4540906DC5@nut.avalanchestudios.se> Hi, thanks for the comments! In this case, I'm not trying to access a class, just a simple function that takes a string (char* ) and returns an int. I was hoping that would make it easier. I've compiled the dll with /CLR and I can load it like this: import clr clr.AddReference("System.Windows.Forms") clr.LoadAssemblyByName("AdfDll_R.dll") However, I still can't access anything inside it. Do I need to do something more? (if I try to load a dll that doesn't exist I get an error, so I'm assuming that there's not a problem with my dll). I've tried adding an import but I just get No module named AdfDll_R. The function is declared as: #ifdef __cplusplus extern "C" { #endif uint32 AdfHash(const char *str); } But when I try to call it, it doesn't work: NameError: name 'AdfHash' not defined I'm exporting the functions using a def file that looks (pretty much) like this: LIBRARY AdfDll_R EXPORTS ; from Adf.h AdfHash I'm using IronPython 1.1.1, but if it helps I'll be glad to change to another version. /Anders ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: den 31 juli 2008 20:21 To: Discussion of IronPython Subject: Re: [IronPython] Using a c library as a dll or assembly It wouldn't be sufficient to recompile with /clr. When you do that, your classes don't automatically become managed classes. You would still need to either modify your classes or to create wrappers using C++/CLI (http://en.wikipedia.org/wiki/C%2B%2B/CLI). In order for a C++ class to be visible to IronPython, it would need to be declared as a "ref class" -- you can see more about that at the referenced Wikipedia article. On Thu, Jul 31, 2008 at 9:22 AM, Anders Elfgren wrote: Hi, First let me say that I'm new to Iron Python, but at least I've read this in the FAQ.. :) Q: How do I build and call into PYD libraries? A: IronPython does not support using PYDs built for CPython since they leverage implementation details of CPython. You can get a similar effect for new "PYD"s you would like to implement by writing them in C# or VB and building a DLL for .NET. That said, I've got some questions to see if what I'm doing is possible anyway. We've got a c library of which most of the code has also been written in Python. We want to create an editor using .net forms which we can use to edit some files, and to do that we need some data structures that exist in this library. My current idea is to interface against the python library using IronPython, and then accessing the datastructures through that in C# (although if absolutely necessary, we could write the editor in IronPython too). The thing that is standing against me now is that one function that exists a small C dll. Since IronPython can't access this (unless this has changed since the FAQ was written?), I was thinking that maybe I can compile the dll using the /clr flag and thus get a .net assembly. Would I then be able to use the function? The Python code just tries to import it: import AvHash And then use it.. def AdfHash(str): return AvHash.HashString(str) At the import statement, this error is raised: Traceback (most recent call last): File X:\ctg\libs\ADF\main\common\modeditor.ipy, line 20, in Initialize File , line 0, in __import__##4 File X:\ctg\libs\ADF\main\common\AdfLib.py, line 1, in Initialize File , line 0, in __import__##4 ImportError: No module named AvHash Or is there some other solution? I've just started researching how to interface between C/C#/Python/IronPython so there may well be things I haven't heard of... I hope I've made my problem clear, thanks for any responses. :) /Anders _______________________________________________ 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 desleo at gmail.com Fri Aug 1 14:29:02 2008 From: desleo at gmail.com (Leo Carbajal) Date: Fri, 1 Aug 2008 07:29:02 -0500 Subject: [IronPython] Sandboxing using AppDomains In-Reply-To: <8FAE2A142FCABE4EB6B37348D78A9BFE0273D83F@XAEXG.GRAPECITY.NET> References: <8FAE2A142FCABE4EB6B37348D78A9BFE0273D83F@XAEXG.GRAPECITY.NET> Message-ID: I had seen that series, though I admit I missed the posts on not using deny. Still rather leaves me in a bind, I guess I'll just have to see how passing object references works through an AppDomain. --- LC 2008/7/31 Han Kejing > Hi, Leo, > > Maybe follows document is helpful for you. > > http://blogs.msdn.com/shawnfa/archive/2005/08/08/449050.aspx > > > > PermissionSet.Deny is not safe. User code may use PermissionSet.Assert to > get the power easily. > > > > > > > > ---------------------------------------------------------------- > > Follow my heart > > *Colin Han** **@* *MultiRow Developer Team (A Strong Team)* > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Leo Carbajal > *Sent:* 2008?7?31? 10:07 > *To:* Users at lists.ironpython.com > *Subject:* [IronPython] Sandboxing using AppDomains > > > > Howdy all, > > I know this is a topic that comes up again and again but I was hoping I > could get a bit of understanding from someone. > > So, like many others, I'm looking to get IPy to work in a relatively safe > environment. My application is a game-server and exposes many entry points > for user created scripts to essentially extend the game's reactions. Because > these scripts are open to the public I need to be sure that it cannot do > nasty things like delete all the script files, my app or anything else on > the server, access my other non-exposed functions, etc. > > Anyway, so after reading up a little on AppDomains it sounds like running > IPy through one could be a little prohibitive. I'm not really passing > value-types to work on, I'm allowing the scripts to directly access and > modify the objects themselves. I guess I'm not sure if what I want to do > will even work, and I haven't had a chance to put together a test. The use > of scripting in the application is extensive so I worry that I may have to > scale back - or risk having someone one day using a little reflection to > snoop out my app's API and calling functions that the scriptShell was never > intended to be able to use. > > Would using permission.Deny for the permissions I want to disallow be > enough to keep things safe? I.E. something like: > > //elsewhere > private static PermissionSet ps = new PermissionSet(PermissionState.None); > ps.AddPermission(new > SecurityPermission(SecurityPermissionFlag.Execution)); > ps.AddPermission(new > FileIOPermission(FileIOPermissionAccess.PathDiscovery | > FileIOPermissionAccess.Read, Path)); > > public static void PlayFirstFile(Item caller) > { > locals.Add("Artifact", new ScriptableItem(caller)); > string script = (Path + "script.py"); > ps.Deny(); > engine.ExecuteFile(script, engine.DefaultModule, locals); > locals.Clear(); > } > > ScriptableItem, by the way, is a class wrapper to hide private methods in > Item after I found out that passing something as a template doesn't work to > occlude methods\properties I don't want called. =\ > > I'm a little lost when it comes to all this security stuff, I could really > use a bit of explanation and would really appreciate any help that can come > this way. > > I'm using IronPython 1.1.2 as I haven't had the chance to sit down and > really play with 2.0, it seems a bit more convoluted to set-up but thats > entirely a from-the-outside perspective at the moment. > > --- > LC > > _______________________________________________ > 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 anders.elfgren at avalanchestudios.se Fri Aug 1 16:36:57 2008 From: anders.elfgren at avalanchestudios.se (Anders Elfgren) Date: Fri, 1 Aug 2008 16:36:57 +0200 Subject: [IronPython] Using a c library as a dll or assembly In-Reply-To: <698E8783CC407F4EB0DC9E994B6D4540906DC5@nut.avalanchestudios.se> References: <698E8783CC407F4EB0DC9E994B6D4540906D64@nut.avalanchestudios.se> <698E8783CC407F4EB0DC9E994B6D4540906DC5@nut.avalanchestudios.se> Message-ID: <698E8783CC407F4EB0DC9E994B6D4540906DFB@nut.avalanchestudios.se> I've got a bit more figured out I think. I think I've got ahold of the function (although since I haven't been able to run it yet, I'm not sure). The function I'm going to call is UInt32 HashString(SByte*) Where the argument is a string, but the problem is that it wants it as an SByte*, and I'm not sure how to convert a System.String to that. I'm guessing that TypeConverter can do the trick for me, but I'm not sure how to use it. I'm also not sure how to use the Invoke method, so any help here is greatly appreciated! Here's my ugly magic: import clr clr.AddReference("System") clr.AddReference("System.ComponentModel") clr.AddReferenceByName("AdfDll_R.dll") clr.LoadAssemblyByName("AdfDll_R.dll") ass = clr.References[3] module = ass.GetModules()[0] hashfunc = module.GetMethod("HashString") ### This is the function I want to call import System from System.ComponentModel import TypeConverter strArray = System.Array[str](["String"]) sbyte = TypeConverter.ConvertTo( ### WHAT GOES HERE? ### ) h = hashfunc.Invoke( None, strArray ) ### Is this the correct way to call it? h should be an int after this. I'm not sure why I can access HashString, but not many of the other functions that exist in the dll. The AdfDll.def file doesn't seem to do anything - but then I'm using /CLR so maybe that explains it. /Anders ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Anders Elfgren Sent: den 1 augusti 2008 13:25 To: Discussion of IronPython Subject: Re: [IronPython] Using a c library as a dll or assembly Hi, thanks for the comments! In this case, I'm not trying to access a class, just a simple function that takes a string (char* ) and returns an int. I was hoping that would make it easier. I've compiled the dll with /CLR and I can load it like this: import clr clr.AddReference("System.Windows.Forms") clr.LoadAssemblyByName("AdfDll_R.dll") However, I still can't access anything inside it. Do I need to do something more? (if I try to load a dll that doesn't exist I get an error, so I'm assuming that there's not a problem with my dll). I've tried adding an import but I just get No module named AdfDll_R. The function is declared as: #ifdef __cplusplus extern "C" { #endif uint32 AdfHash(const char *str); } But when I try to call it, it doesn't work: NameError: name 'AdfHash' not defined I'm exporting the functions using a def file that looks (pretty much) like this: LIBRARY AdfDll_R EXPORTS ; from Adf.h AdfHash I'm using IronPython 1.1.1, but if it helps I'll be glad to change to another version. /Anders ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: den 31 juli 2008 20:21 To: Discussion of IronPython Subject: Re: [IronPython] Using a c library as a dll or assembly It wouldn't be sufficient to recompile with /clr. When you do that, your classes don't automatically become managed classes. You would still need to either modify your classes or to create wrappers using C++/CLI (http://en.wikipedia.org/wiki/C%2B%2B/CLI). In order for a C++ class to be visible to IronPython, it would need to be declared as a "ref class" -- you can see more about that at the referenced Wikipedia article. On Thu, Jul 31, 2008 at 9:22 AM, Anders Elfgren wrote: Hi, First let me say that I'm new to Iron Python, but at least I've read this in the FAQ.. :) Q: How do I build and call into PYD libraries? A: IronPython does not support using PYDs built for CPython since they leverage implementation details of CPython. You can get a similar effect for new "PYD"s you would like to implement by writing them in C# or VB and building a DLL for .NET. That said, I've got some questions to see if what I'm doing is possible anyway. We've got a c library of which most of the code has also been written in Python. We want to create an editor using .net forms which we can use to edit some files, and to do that we need some data structures that exist in this library. My current idea is to interface against the python library using IronPython, and then accessing the datastructures through that in C# (although if absolutely necessary, we could write the editor in IronPython too). The thing that is standing against me now is that one function that exists a small C dll. Since IronPython can't access this (unless this has changed since the FAQ was written?), I was thinking that maybe I can compile the dll using the /clr flag and thus get a .net assembly. Would I then be able to use the function? The Python code just tries to import it: import AvHash And then use it.. def AdfHash(str): return AvHash.HashString(str) At the import statement, this error is raised: Traceback (most recent call last): File X:\ctg\libs\ADF\main\common\modeditor.ipy, line 20, in Initialize File , line 0, in __import__##4 File X:\ctg\libs\ADF\main\common\AdfLib.py, line 1, in Initialize File , line 0, in __import__##4 ImportError: No module named AvHash Or is there some other solution? I've just started researching how to interface between C/C#/Python/IronPython so there may well be things I haven't heard of... I hope I've made my problem clear, thanks for any responses. :) /Anders _______________________________________________ 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 Fri Aug 1 16:38:51 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 1 Aug 2008 07:38:51 -0700 Subject: [IronPython] Using a c library as a dll or assembly In-Reply-To: <698E8783CC407F4EB0DC9E994B6D4540906DC5@nut.avalanchestudios.se> References: <698E8783CC407F4EB0DC9E994B6D4540906D64@nut.avalanchestudios.se> <698E8783CC407F4EB0DC9E994B6D4540906DC5@nut.avalanchestudios.se> Message-ID: Here's how I think I would do it. Add a class definition to your C source that looks something like this: using namespace System::Runtime::InteropServices; ref class Exported { public: static int AdfHash(String^ str) { const char* str2 = (char*)(void*)Marshal::StringToHGlobalAnsi(str); int result = ::AdfHash(str2); Marshal::FreeHGlobal((System::IntPtr)(void*)str2); return result; } } You should then be able to import the Exported class from the assembly and access AdfHash through it. You'll need to write a similar wrapper for every function you want to export. Disclaimer: I've never actually used either Managed C++ or C++/CLI except to write small test cases. On Fri, Aug 1, 2008 at 4:25 AM, Anders Elfgren < anders.elfgren at avalanchestudios.se> wrote: > Hi, thanks for the comments! > In this case, I'm not trying to access a class, just a simple function that > takes a string (char* ) and returns an int. I was hoping that would make it > easier. > > I've compiled the dll with /CLR and I can load it like this: > > import clr > clr.AddReference("System.Windows.Forms") > clr.LoadAssemblyByName("AdfDll_R.dll") > > However, I still can't access anything inside it. Do I need to do something > more? (if I try to load a dll that doesn't exist I get an error, so I'm > assuming that there's not a problem with my dll). I've tried adding an > import but I just get No module named AdfDll_R. > > > The function is declared as: > > #ifdef __cplusplus > extern "C" { > #endif > > uint32 AdfHash(const char *str); > > } > > But when I try to call it, it doesn't work: > NameError: name 'AdfHash' not defined > > > > I'm exporting the functions using a def file that looks (pretty much) like > this: > LIBRARY AdfDll_R > EXPORTS > > ; from Adf.h > AdfHash > > I'm using IronPython 1.1.1, but if it helps I'll be glad to change to > another version. > > /Anders > > ------------------------------ > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Curt Hagenlocher > *Sent:* den 31 juli 2008 20:21 > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Using a c library as a dll or assembly > > It wouldn't be sufficient to recompile with /clr. When you do that, > your classes don't automatically become managed classes. You would still > need to either modify your classes or to create wrappers using C++/CLI ( > http://en.wikipedia.org/wiki/C%2B%2B/CLI). In order for a C++ class to be > visible to IronPython, it would need to be declared as a "ref class" -- you > can see more about that at the referenced Wikipedia article. > > > On Thu, Jul 31, 2008 at 9:22 AM, Anders Elfgren < > anders.elfgren at avalanchestudios.se> wrote: > >> Hi, >> >> First let me say that I'm new to Iron Python, but at least I've read this >> in the FAQ.. :) >> >> Q: How do I build and call into *PYD* libraries? >> A: *IronPython* does not support using PYDs built for CPython since they >> leverage implementation details of CPython. You can get a similar effect >> for new "*PYD*"s you would like to implement by writing them in C# or VB >> and building a DLL for .NET. >> >> That said, I've got some questions to see if what I'm doing is possible >> anyway. >> >> We've got a c library of which most of the code has also been written in >> Python. We want to create an editor using .net forms which we can use to >> edit some files, and to do that we need some data structures that exist in >> this library. >> >> My current idea is to interface against the python library using >> IronPython, and then accessing the datastructures through that in C# >> (although if absolutely necessary, we could write the editor in IronPython >> too). The thing that is standing against me now is that one function that >> exists a small C dll. Since IronPython can't access this (unless this has >> changed since the FAQ was written?), I was thinking that maybe I can compile >> the dll using the /clr flag and thus get a .net assembly. Would I then be >> able to use the function? >> >> The Python code just tries to import it: >> import AvHash >> >> And then use it.. >> def AdfHash(str): >> return AvHash.HashString(str) >> >> >> At the import statement, this error is raised: >> Traceback (most recent call last): >> File X:\ctg\libs\ADF\main\common\modeditor.ipy, line 20, in Initialize >> File , line 0, in __import__##4 >> File X:\ctg\libs\ADF\main\common\AdfLib.py, line 1, in Initialize >> File , line 0, in __import__##4 >> ImportError: No module named AvHash >> >> >> >> Or is there some other solution? I've just started researching how to >> interface between C/C#/Python/IronPython so there may well be things I >> haven't heard of... >> I hope I've made my problem clear, thanks for any responses. :) >> >> /Anders >> >> >> _______________________________________________ >> 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 twpage at gmail.com Fri Aug 1 17:33:07 2008 From: twpage at gmail.com (Todd Page) Date: Fri, 1 Aug 2008 11:33:07 -0400 Subject: [IronPython] Creating Excel Add-in with Iron Python Message-ID: Hi guys, Just starting to get into IronPython and have been poking around for the last few days; but I'm hoping someone can help. Basically, I want to take some python (IronPython) code, compile it to a dll (or xll?) and have it function like an add-in for excel. So, I could code functions in python and just call them as worksheet functions in excel. This is greatly preferable to writing VBA!! Can anyone point me in the right direction? After days of googling all I seem to have is 10-12 open tabs and still no concrete answer. Any help is appreciated, thanks! twp -------------- next part -------------- An HTML attachment was scrubbed... URL: From twpage at gmail.com Fri Aug 1 17:36:01 2008 From: twpage at gmail.com (Todd Page) Date: Fri, 1 Aug 2008 11:36:01 -0400 Subject: [IronPython] Creating Excel Add-in with Iron Python Message-ID: Hi guys, Just starting to get into IronPython and have been poking around for the last few days; but I'm hoping someone can help. Basically, I want to take some python (IronPython) code, compile it to a dll (or xll?) and have it function like an add-in for excel. So, I could code functions in python and just call them as worksheet functions in excel. This is greatly preferable to writing VBA!! Can anyone point me in the right direction? After days of googling all I seem to have is 10-12 open tabs and still no concrete answer. Any help is appreciated, thanks! twp -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Fri Aug 1 17:51:21 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 1 Aug 2008 08:51:21 -0700 Subject: [IronPython] Sandboxing using AppDomains In-Reply-To: References: <8FAE2A142FCABE4EB6B37348D78A9BFE0273D83F@XAEXG.GRAPECITY.NET> Message-ID: <7AD436E4270DD54A94238001769C2227012C9376BF0D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> One thing I?ll point out is in 2.0 we?ve done a bunch of work to make working with a remote app domain pretty easy. You can create the ScriptRuntime in the remote domain and get back a ScriptEngine which lives in the remote domain. All of the calls on the hosting APIs use serializable / MBRO objects so that they?re safe to use from a remoting standpoint. Also ObjectOperations provides versions of the APIs that work with ObjectHandle?s instead of raw objects. So all you have to watch out for is making sure the objects you?re sending across the wire are MBRO or Serializable. That being said we still have a few bugs which prevent you from creating a completely untrusted domain and loading the ScriptRuntime over there. Those should be getting resolved fairly soon though but won?t be in 2.0 Beta 4 :(. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Leo Carbajal Sent: Friday, August 01, 2008 5:29 AM To: Discussion of IronPython Subject: Re: [IronPython] Sandboxing using AppDomains I had seen that series, though I admit I missed the posts on not using deny. Still rather leaves me in a bind, I guess I'll just have to see how passing object references works through an AppDomain. --- LC 2008/7/31 Han Kejing > Hi, Leo, Maybe follows document is helpful for you. http://blogs.msdn.com/shawnfa/archive/2005/08/08/449050.aspx PermissionSet.Deny is not safe. User code may use PermissionSet.Assert to get the power easily. ---------------------------------------------------------------- Follow my heart Colin Han @ MultiRow Developer Team (A Strong Team) From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Leo Carbajal Sent: 2008?7?31? 10:07 To: Users at lists.ironpython.com Subject: [IronPython] Sandboxing using AppDomains Howdy all, I know this is a topic that comes up again and again but I was hoping I could get a bit of understanding from someone. So, like many others, I'm looking to get IPy to work in a relatively safe environment. My application is a game-server and exposes many entry points for user created scripts to essentially extend the game's reactions. Because these scripts are open to the public I need to be sure that it cannot do nasty things like delete all the script files, my app or anything else on the server, access my other non-exposed functions, etc. Anyway, so after reading up a little on AppDomains it sounds like running IPy through one could be a little prohibitive. I'm not really passing value-types to work on, I'm allowing the scripts to directly access and modify the objects themselves. I guess I'm not sure if what I want to do will even work, and I haven't had a chance to put together a test. The use of scripting in the application is extensive so I worry that I may have to scale back - or risk having someone one day using a little reflection to snoop out my app's API and calling functions that the scriptShell was never intended to be able to use. Would using permission.Deny for the permissions I want to disallow be enough to keep things safe? I.E. something like: //elsewhere private static PermissionSet ps = new PermissionSet(PermissionState.None); ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution)); ps.AddPermission(new FileIOPermission(FileIOPermissionAccess.PathDiscovery | FileIOPermissionAccess.Read, Path)); public static void PlayFirstFile(Item caller) { locals.Add("Artifact", new ScriptableItem(caller)); string script = (Path + "script.py"); ps.Deny(); engine.ExecuteFile(script, engine.DefaultModule, locals); locals.Clear(); } ScriptableItem, by the way, is a class wrapper to hide private methods in Item after I found out that passing something as a template doesn't work to occlude methods\properties I don't want called. =\ I'm a little lost when it comes to all this security stuff, I could really use a bit of explanation and would really appreciate any help that can come this way. I'm using IronPython 1.1.2 as I haven't had the chance to sit down and really play with 2.0, it seems a bit more convoluted to set-up but thats entirely a from-the-outside perspective at the moment. --- LC _______________________________________________ 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 seshapv at microsoft.com Fri Aug 1 18:46:55 2008 From: seshapv at microsoft.com (Seshadri Pillailokam Vijayaraghavan) Date: Fri, 1 Aug 2008 09:46:55 -0700 Subject: [IronPython] Creating Excel Add-in with Iron Python In-Reply-To: References: Message-ID: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A08F@NA-EXMSG-C112.redmond.corp.microsoft.com> Couple of weeks back I wrote a Addin for VS that does something similar to what you are describing. It was intended as a demo\sample on how to use the DLR Hosting API. It is basically a simple addin for VS that routes all events to a python function defined in a '.py' file. Take a look at this - http://blogs.msdn.com/seshadripv/archive/2008/07/17/dlr-hosting-sample-write-event-handlers-for-vs-in-ironpython.aspx. If you think this is along the lines of what you want to do, let me know. I also started writing a similar thing for excel but didn't go through with it. I could probably share that with you if you are interested. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Todd Page Sent: Friday, August 01, 2008 8:36 AM To: users at lists.ironpython.com Subject: [IronPython] Creating Excel Add-in with Iron Python Hi guys, Just starting to get into IronPython and have been poking around for the last few days; but I'm hoping someone can help. Basically, I want to take some python (IronPython) code, compile it to a dll (or xll?) and have it function like an add-in for excel. So, I could code functions in python and just call them as worksheet functions in excel. This is greatly preferable to writing VBA!! Can anyone point me in the right direction? After days of googling all I seem to have is 10-12 open tabs and still no concrete answer. Any help is appreciated, thanks! twp -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Fri Aug 1 18:50:51 2008 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Fri, 01 Aug 2008 17:50:51 +0100 Subject: [IronPython] Creating Excel Add-in with Iron Python In-Reply-To: References: Message-ID: <48933EEB.2060008@resolversystems.com> Hi Todd, I don't know if you came across us in your googling, but we have a spreadsheet (free for non-commercial use) that you can script in IronPython. It's not Excel - we like to think it's better :-) - but hopefully it will be useful for you. There's a description here and you can download it from Best regards, Giles Todd Page wrote: > Hi guys, > > Just starting to get into IronPython and have been poking around for > the last few days; but I'm hoping someone can help. Basically, I want > to take some python (IronPython) code, compile it to a dll (or xll?) > and have it function like an add-in for excel. So, I could code > functions in python and just call them as worksheet functions in > excel. This is greatly preferable to writing VBA!! > > Can anyone point me in the right direction? After days of googling all > I seem to have is 10-12 open tabs and still no concrete answer. Any > help is appreciated, thanks! > > twp > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Fri Aug 1 18:56:38 2008 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Fri, 01 Aug 2008 17:56:38 +0100 Subject: [IronPython] IronPython Code Coverage - any options? In-Reply-To: <426ada670807311354n2dae668buf9245dfad37b8bd3@mail.gmail.com> References: <426ada670807311354n2dae668buf9245dfad37b8bd3@mail.gmail.com> Message-ID: <48934046.1060506@resolversystems.com> Hi Carl, Unfortunately we've not yet found a code coverage tool we can use - though to be honest, we've not done much in-depth searching since Michael posted on the topic. Best regards, Giles Carl Trachte wrote: > Hello, > > I just did a Google search and found Michael Foord's blog post on > coverage tools, among other things test related: > http://www.voidspace.org.uk/python/weblog/arch_d7_2006_06_17.shtml > > Has anything else come up since then? Does (if I can ask) Resolver > use a code coverage tool? > > I'm just getting started testing with unitttest and I'd like to gauge > my progress as I implement testing in more of my code. > > Thanks a ton for any information you can provide. > > Carl T. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From curt at hagenlocher.org Fri Aug 1 20:12:40 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 1 Aug 2008 11:12:40 -0700 Subject: [IronPython] IronPython Code Coverage - any options? In-Reply-To: <426ada670807311354n2dae668buf9245dfad37b8bd3@mail.gmail.com> References: <426ada670807311354n2dae668buf9245dfad37b8bd3@mail.gmail.com> Message-ID: The situation hasn't changed since that blog post. We don't currently support the ast module or sys.settrace, and we don't expect to do so in the 2.0 release either. On Thu, Jul 31, 2008 at 1:54 PM, Carl Trachte wrote: > Hello, > > I just did a Google search and found Michael Foord's blog post on > coverage tools, among other things test related: > http://www.voidspace.org.uk/python/weblog/arch_d7_2006_06_17.shtml > > Has anything else come up since then? Does (if I can ask) Resolver > use a code coverage tool? > > I'm just getting started testing with unitttest and I'd like to gauge > my progress as I implement testing in more of my code. > > Thanks a ton for any information you can provide. > > Carl T. > _______________________________________________ > 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 ctrachte at gmail.com Fri Aug 1 21:04:30 2008 From: ctrachte at gmail.com (Carl Trachte) Date: Fri, 1 Aug 2008 12:04:30 -0700 Subject: [IronPython] IronPython Code Coverage - any options? In-Reply-To: References: <426ada670807311354n2dae668buf9245dfad37b8bd3@mail.gmail.com> Message-ID: <426ada670808011204h1fce8854t1545c4ed4a0018dc@mail.gmail.com> On Fri, Aug 1, 2008 at 11:12 AM, Curt Hagenlocher wrote: > The situation hasn't changed since that blog post. We don't currently > support the ast module or sys.settrace, and we don't expect to do so in the > 2.0 release either. > > On Thu, Jul 31, 2008 at 1:54 PM, Carl Trachte wrote: >> >> Hello, >> >> I just did a Google search and found Michael Foord's blog post on >> coverage tools, among other things test related: >> http://www.voidspace.org.uk/python/weblog/arch_d7_2006_06_17.shtml >> >> Has anything else come up since then? Does (if I can ask) Resolver >> use a code coverage tool? >> >> I'm just getting started testing with unitttest and I'd like to gauge >> my progress as I implement testing in more of my code. >> >> Thanks a ton for any information you can provide. >> >> Carl T. >> _______________________________________________ >> 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 > > Thanks for the replies, gentlemen. I've got plenty of unittesting to do before it's 100% complete, so there's lots of time to look into other options. Carl T. From twpage at gmail.com Fri Aug 1 22:22:27 2008 From: twpage at gmail.com (Todd Page) Date: Fri, 1 Aug 2008 16:22:27 -0400 Subject: [IronPython] Creating Excel Add-in with Iron Python Message-ID: Hi Giles, I actually did see the Resolver system... it looks pretty slick! I'm putting that on my 'to check out' list but I'm not sure if it is -exactly- what I am looking for. Basically, I am looking to write my own code in Iron Python and compile it into an excel add-in (DLL, or XLL? not sure yet). That way I can just distribute the add-in to various users. My current alternative is to create a COM server in python, but those are harder to distribute on machines that are "locked down" (e.g. windows non-administrators). I think an excel add-in would be the easiest way to go. I've seen others use C# to compile excel add-ins and I'm just wondering if I can do the same thing in IronPython? Thanks! ~ Todd On Fri, Aug 1, 2008 at 4:11 PM, wrote: > Message: 1 > Date: Fri, 01 Aug 2008 17:50:51 +0100 > From: Giles Thomas > Subject: Re: [IronPython] Creating Excel Add-in with Iron Python > To: Discussion of IronPython > Message-ID: <48933EEB.2060008 at resolversystems.com> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Hi Todd, > > I don't know if you came across us in your googling, but we have a > spreadsheet (free for non-commercial use) that you can script in > IronPython. It's not Excel - we like to think it's better :-) - but > hopefully it will be useful for you. > > There's a description here > and you can > download it from > > > Best regards, > > Giles > -------------- next part -------------- An HTML attachment was scrubbed... URL: From desleo at gmail.com Sat Aug 2 03:18:50 2008 From: desleo at gmail.com (Leo Carbajal) Date: Fri, 1 Aug 2008 20:18:50 -0500 Subject: [IronPython] Sandboxing using AppDomains In-Reply-To: <7AD436E4270DD54A94238001769C2227012C9376BF0D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <8FAE2A142FCABE4EB6B37348D78A9BFE0273D83F@XAEXG.GRAPECITY.NET> <7AD436E4270DD54A94238001769C2227012C9376BF0D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: I will have to try it out, then. At the very worst I can always set up the shell and then apply the proper permissions (or lack thereof) later when its supported, I doubt my own project will be going live any time soon anyway so a little leeway in testing is no big deal. Now to wrap my head around the new hosting API, maybe a third read through on the docs will help. =\ 2008/8/1 Dino Viehland > One thing I'll point out is in 2.0 we've done a bunch of work to make > working with a remote app domain pretty easy. You can create the > ScriptRuntime in the remote domain and get back a ScriptEngine which lives > in the remote domain. All of the calls on the hosting APIs use serializable > / MBRO objects so that they're safe to use from a remoting standpoint. Also > ObjectOperations provides versions of the APIs that work with ObjectHandle's > instead of raw objects. So all you have to watch out for is making sure the > objects you're sending across the wire are MBRO or Serializable. > > > > That being said we still have a few bugs which prevent you from creating a > completely untrusted domain and loading the ScriptRuntime over there. Those > should be getting resolved fairly soon though but won't be in 2.0 Beta 4 L > . > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Leo Carbajal > *Sent:* Friday, August 01, 2008 5:29 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Sandboxing using AppDomains > > > > I had seen that series, though I admit I missed the posts on not using > deny. Still rather leaves me in a bind, I guess I'll just have to see how > passing object references works through an AppDomain. > > --- > LC > > 2008/7/31 Han Kejing > > Hi, Leo, > > Maybe follows document is helpful for you. > > http://blogs.msdn.com/shawnfa/archive/2005/08/08/449050.aspx > > > > PermissionSet.Deny is not safe. User code may use PermissionSet.Assert to > get the power easily. > > > > > > > > ---------------------------------------------------------------- > > Follow my heart > > *Colin Han @* *MultiRow Developer Team (A Strong Team)* > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Leo Carbajal > *Sent:* 2008?7?31? 10:07 > *To:* Users at lists.ironpython.com > *Subject:* [IronPython] Sandboxing using AppDomains > > > > Howdy all, > > I know this is a topic that comes up again and again but I was hoping I > could get a bit of understanding from someone. > > So, like many others, I'm looking to get IPy to work in a relatively safe > environment. My application is a game-server and exposes many entry points > for user created scripts to essentially extend the game's reactions. Because > these scripts are open to the public I need to be sure that it cannot do > nasty things like delete all the script files, my app or anything else on > the server, access my other non-exposed functions, etc. > > Anyway, so after reading up a little on AppDomains it sounds like running > IPy through one could be a little prohibitive. I'm not really passing > value-types to work on, I'm allowing the scripts to directly access and > modify the objects themselves. I guess I'm not sure if what I want to do > will even work, and I haven't had a chance to put together a test. The use > of scripting in the application is extensive so I worry that I may have to > scale back - or risk having someone one day using a little reflection to > snoop out my app's API and calling functions that the scriptShell was never > intended to be able to use. > > Would using permission.Deny for the permissions I want to disallow be > enough to keep things safe? I.E. something like: > > //elsewhere > private static PermissionSet ps = new PermissionSet(PermissionState.None); > ps.AddPermission(new > SecurityPermission(SecurityPermissionFlag.Execution)); > ps.AddPermission(new > FileIOPermission(FileIOPermissionAccess.PathDiscovery | > FileIOPermissionAccess.Read, Path)); > > public static void PlayFirstFile(Item caller) > { > locals.Add("Artifact", new ScriptableItem(caller)); > string script = (Path + "script.py"); > ps.Deny(); > engine.ExecuteFile(script, engine.DefaultModule, locals); > locals.Clear(); > } > > ScriptableItem, by the way, is a class wrapper to hide private methods in > Item after I found out that passing something as a template doesn't work to > occlude methods?properties I don't want called. =? > > I'm a little lost when it comes to all this security stuff, I could really > use a bit of explanation and would really appreciate any help that can come > this way. > > I'm using IronPython 1.1.2 as I haven't had the chance to sit down and > really play with 2.0, it seems a bit more convoluted to set-up but thats > entirely a from-the-outside perspective at the moment. > > --- > LC > > > _______________________________________________ > 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 seshapv at microsoft.com Sun Aug 3 07:27:33 2008 From: seshapv at microsoft.com (Seshadri Pillailokam Vijayaraghavan) Date: Sat, 2 Aug 2008 22:27:33 -0700 Subject: [IronPython] Security of DLR host In-Reply-To: References: Message-ID: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A36E@NA-EXMSG-C112.redmond.corp.microsoft.com> [Including the de facto Hosting API mailing list - IronPython Discussions] Hi All, Is what Pavel is asking possible? Can DLR hosts selectively ban imports? Thanks Sesh -----Original Message----- From: pavel.savara at gmail.com [mailto:pavel.savara at gmail.com] Sent: Saturday, August 02, 2008 6:24 PM To: Seshadri Pillailokam Vijayaraghavan Subject: (DLR Hosting and related stuff...) : Security of DLR host Importance: High Hi, I would like to run untrusted scripts inside of DLR (for example js in Silverlight). How to restrict access of the scripts ? How do I ban imports e.g. System.Windows.Application ? I already know how to construct ScriptScope and run js inside (from C# code). Learned from your articles. ;-) Thanks Pavel From pavel.savara at gmail.com Sun Aug 3 10:03:24 2008 From: pavel.savara at gmail.com (=?UTF-8?Q?Pavel_=C5=A0avara?=) Date: Sun, 3 Aug 2008 10:03:24 +0200 Subject: [IronPython] Security of DLR host In-Reply-To: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A36E@NA-EXMSG-C112.redmond.corp.microsoft.com> References: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A36E@NA-EXMSG-C112.redmond.corp.microsoft.com> Message-ID: <62ddb6fb0808030103q36fae5f2le9ce8b8cf4f756e5@mail.gmail.com> Hi all on the list, I found one answer on your group already. http://lists.ironpython.com/pipermail/users-ironpython.com/2008-March/006721.html Unfortunately it seems to me that for silverlight there is no AppDomain.CreateDomain() So I'm looking for another solution. 1) I could try to ban all scripts containing "import". Could I somehow extend parser or should I search the script upfront ? Is there some parser event which I could subscribe ? 2) Is there any hook in the engine which I can use to ban calling access points ? Type resolver for example ? To paint whole picture for you I will give you more about use-case. I would like to create Racetrack in silverlight http://en.wikipedia.org/wiki/Racetrack_(game) But instead of playing by players I would like to let programmers to drive cars with scripts. When I will store scripts on server repository we could have contest. The problem is that programmers will tend to cheat as much as possible. Thanks for advices Pavel On Sun, Aug 3, 2008 at 7:27 AM, Seshadri Pillailokam Vijayaraghavan wrote: > [Including the de facto Hosting API mailing list - IronPython Discussions] > > Hi All, > > Is what Pavel is asking possible? Can DLR hosts selectively ban imports? > > Thanks > Sesh > > -----Original Message----- > From: pavel.savara at gmail.com [mailto:pavel.savara at gmail.com] > Sent: Saturday, August 02, 2008 6:24 PM > To: Seshadri Pillailokam Vijayaraghavan > Subject: (DLR Hosting and related stuff...) : Security of DLR host > Importance: High > > > Hi, > > I would like to run untrusted scripts inside of DLR (for example js in Silverlight). How to restrict access of the scripts ? How do I ban imports e.g. System.Windows.Application ? I already know how to construct ScriptScope and run js inside (from C# code). Learned from your articles. ;-) > > Thanks Pavel > From asaf at itstructures.com Sun Aug 3 12:31:03 2008 From: asaf at itstructures.com (Asaf Kleinbort) Date: Sun, 3 Aug 2008 13:31:03 +0300 Subject: [IronPython] Performance issue when calling a function with **kw Message-ID: <00bb01c8f554$09b78820$1d269860$@com> Hi all, I am new to this list, so I'll first introduce myself. I am working at IT Structures (www.itstructures.com) in Israel. Our service Is written in C#, but most of the backend implementation is written in IronPython. While doing performance analysis of our application, I came across the following interesting bug (?): Calling a function with **kw takes about 10 times more time than calling a function with a simple dictionary. The difference exists also in cpython but there the differences is hardly noticed. Here is a code snippet to clarify: . def func_kw(kw): return sum(kw.itervalues()) def func(**kw): return sum(kw.itervalues()) def measure(n): dct = {'1':2,'2':2,'3':2,'4':2,'5':2,'6':2} start = time.clock() for i in xrange(n): func_kw(dct) duration_without = time.clock()-start start = time.clock() for i in xrange(n): func(**dct) duration_with = time.clock()-start return (duration_without,duration_with) . Running measure(10**6) 10 times in a loop and calculating the mean we get the following results (in seconds): In IronPython: WITH **KW: mean=5.56493157650, stddev=0.0649572929575. WITHOUT: mean=0.86113346808, stddev=0.0142532589459. In Python: WITH **KW: mean=1.70669562131, stddev=0.0230977726849. WITHOUT: mean=0.782945815118, stddev=0.00572116553432. (IronPython version: IronPython 1.1.1 (1.1.1) on .NET 2.0.50727.1433 Python version: Python 2.5.1) Does anyone know if this is going to improve in version 2.0? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Sun Aug 3 12:47:24 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sun, 3 Aug 2008 19:47:24 +0900 Subject: [IronPython] Performance issue when calling a function with **kw In-Reply-To: <00bb01c8f554$09b78820$1d269860$@com> References: <00bb01c8f554$09b78820$1d269860$@com> Message-ID: <5b0248170808030347v45016c94t35345fb7d4d12ead@mail.gmail.com> 2008/8/3 Asaf Kleinbort : > Calling a function with **kw takes about 10 times more time than calling a > function with a simple dictionary. The difference exists also in cpython > but there the differences is hardly noticed. > > Does anyone know if this is going to improve in version 2.0? As far as I can tell IronPython 2 does not improve this case. However, IronPython 2 does improve *seq case, more than a factor of two, compared to IronPython 1. I have a plan to do a comprehensive benchmark of call sequences for CPython, IronPython 1, and IronPython 2, based on callbench developed in PyPy. Ah, procrastination... -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Sun Aug 3 16:48:35 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 03 Aug 2008 15:48:35 +0100 Subject: [IronPython] Security of DLR host In-Reply-To: <62ddb6fb0808030103q36fae5f2le9ce8b8cf4f756e5@mail.gmail.com> References: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A36E@NA-EXMSG-C112.redmond.corp.microsoft.com> <62ddb6fb0808030103q36fae5f2le9ce8b8cf4f756e5@mail.gmail.com> Message-ID: <4895C543.2020301@voidspace.org.uk> Pavel ?avara wrote: > Hi all on the list, > > I found one answer on your group already. > http://lists.ironpython.com/pipermail/users-ironpython.com/2008-March/006721.html > > Unfortunately it seems to me that for silverlight there is no > AppDomain.CreateDomain() > > So I'm looking for another solution. > > 1) I could try to ban all scripts containing "import". Could I somehow > extend parser or should I search the script upfront ? > Is there some parser event which I could subscribe ? > > 2) Is there any hook in the engine which I can use to ban calling > access points ? Type resolver for example ? > > A solution based on banning import statements at the parser / ast level will fail - because there are always other techniques to access the same functionality. With Silverlight you can use the Platform Adaptation Layer to control imports though. The DLR hosting specs has some details on this (Silverlight uses the PAL so that imports are resolved by searching inside the xap file - a modified PAL could ban imports altogether). Michael > To paint whole picture for you I will give you more about use-case. > > I would like to create Racetrack in silverlight > http://en.wikipedia.org/wiki/Racetrack_(game) > But instead of playing by players I would like to let programmers to > drive cars with scripts. When I will store scripts on server > repository we could have contest. The problem is that programmers will > tend to cheat as much as possible. > > Thanks for advices > Pavel > > On Sun, Aug 3, 2008 at 7:27 AM, Seshadri Pillailokam Vijayaraghavan > wrote: > >> [Including the de facto Hosting API mailing list - IronPython Discussions] >> >> Hi All, >> >> Is what Pavel is asking possible? Can DLR hosts selectively ban imports? >> >> Thanks >> Sesh >> >> -----Original Message----- >> From: pavel.savara at gmail.com [mailto:pavel.savara at gmail.com] >> Sent: Saturday, August 02, 2008 6:24 PM >> To: Seshadri Pillailokam Vijayaraghavan >> Subject: (DLR Hosting and related stuff...) : Security of DLR host >> Importance: High >> >> >> Hi, >> >> I would like to run untrusted scripts inside of DLR (for example js in Silverlight). How to restrict access of the scripts ? How do I ban imports e.g. System.Windows.Application ? I already know how to construct ScriptScope and run js inside (from C# code). Learned from your articles. ;-) >> >> Thanks Pavel >> >> > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From pavel.savara at gmail.com Sun Aug 3 17:39:28 2008 From: pavel.savara at gmail.com (=?UTF-8?Q?Pavel_=C5=A0avara?=) Date: Sun, 3 Aug 2008 17:39:28 +0200 Subject: [IronPython] Security of DLR host In-Reply-To: <4895C543.2020301@voidspace.org.uk> References: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A36E@NA-EXMSG-C112.redmond.corp.microsoft.com> <62ddb6fb0808030103q36fae5f2le9ce8b8cf4f756e5@mail.gmail.com> <4895C543.2020301@voidspace.org.uk> Message-ID: <62ddb6fb0808030839j28c099a8t1855c1f3ebbc1666@mail.gmail.com> > With Silverlight you can use the Platform Adaptation Layer to control > imports though. The DLR hosting specs has some details on this (Silverlight > uses the PAL so that imports are resolved by searching inside the xap file - > a modified PAL could ban imports altogether). Michael, I looked at your articles about that on voidspace. Unfortunately in last sdl-sdk things look different. There is no direct way how to change PAL anymore. Pavel From fuzzyman at voidspace.org.uk Sun Aug 3 17:42:51 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 03 Aug 2008 16:42:51 +0100 Subject: [IronPython] Security of DLR host In-Reply-To: <62ddb6fb0808030839j28c099a8t1855c1f3ebbc1666@mail.gmail.com> References: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A36E@NA-EXMSG-C112.redmond.corp.microsoft.com> <62ddb6fb0808030103q36fae5f2le9ce8b8cf4f756e5@mail.gmail.com> <4895C543.2020301@voidspace.org.uk> <62ddb6fb0808030839j28c099a8t1855c1f3ebbc1666@mail.gmail.com> Message-ID: <4895D1FB.20206@voidspace.org.uk> Pavel ?avara wrote: >> With Silverlight you can use the Platform Adaptation Layer to control >> imports though. The DLR hosting specs has some details on this (Silverlight >> uses the PAL so that imports are resolved by searching inside the xap file - >> a modified PAL could ban imports altogether). >> > > Michael, > > I looked at your articles about that on voidspace. Unfortunately in > last sdl-sdk things look different. > There is no direct way how to change PAL anymore. > > Have you read the DLR hosting spec? (That old article of mine on the PAL will be updated soon (I thought it already was!) - there is no need to do any of that tinkering for what the article was trying to achieve.) Michael > Pavel > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From pavel.savara at gmail.com Sun Aug 3 20:32:04 2008 From: pavel.savara at gmail.com (=?UTF-8?Q?Pavel_=C5=A0avara?=) Date: Sun, 3 Aug 2008 20:32:04 +0200 Subject: [IronPython] Security of DLR host In-Reply-To: <4895D1FB.20206@voidspace.org.uk> References: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A36E@NA-EXMSG-C112.redmond.corp.microsoft.com> <62ddb6fb0808030103q36fae5f2le9ce8b8cf4f756e5@mail.gmail.com> <4895C543.2020301@voidspace.org.uk> <62ddb6fb0808030839j28c099a8t1855c1f3ebbc1666@mail.gmail.com> <4895D1FB.20206@voidspace.org.uk> Message-ID: <62ddb6fb0808031132s2af9f39cya4717d74328d4683@mail.gmail.com> > Have you read the DLR hosting spec? (That old article of mine on the PAL > will be updated soon (I thought it already was!) - there is no need to do > any of that tinkering for what the article was trying to achieve.) Yes. Now I can understand API, however not implementation. Now I'm able to construct my own BrowserScriptHost and BrowserPAL. But on the PAL is only LoadAssembly to override. For Import("System.Windows.Application") it does nothing as the assembly is already loaded. So catching Import was not good idea. Also because we could navigate there to Application.Current without import, right ? I would rather like to ban namespaces now. For known (already loaded) namespaces I could easily recognize them. All other namespaces are allowed (defined by script or allowed by host). I seen something simillar on SecurityManager.checkPackageAccess() in Java. In hosting spec I seen something like Scope and seen some Globals.Dict in debugger which contains them somehow. .... I'm lost in the complexity of stuff inside, sorry for lameness. I also thinking about dynamic code similar to var current = typeof (System.Windows.Application).GetField("Current", BindingFlags.Static); That should also invoke checkPackageAccess() As was already pointed out there are probably several ways how to compromise the scripting host by malicious code. I think that analysis by someone more educated than me would be very useful. Do you thing we still could find some way how to secure it ? Is my security scenario serious enough to become requirement for DLR ? Should I open issue on codeplex for it ? Thanks Pavel > Michael > >> Pavel >> _______________________________________________ >> 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/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.theotherdelia.co.uk/ > http://www.resolverhacks.net/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dan.eloff at gmail.com Sun Aug 3 23:12:34 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Sun, 3 Aug 2008 16:12:34 -0500 Subject: [IronPython] loading an image in silverlight, in xaml, from the .xap In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A32845D4A07EA2@NA-EXMSG-C116.redmond.corp.microsoft.com> References: <4817b6fc0807112352n11f18dfexb6f7acb9fbfe69dd@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A32845D4A07EA2@NA-EXMSG-C116.redmond.corp.microsoft.com> Message-ID: <4817b6fc0808031412n4070028ct460da31eca172243@mail.gmail.com> It loads the image in IE7 just fine, which is better than I ever got it to do. It must be the use of LoadComponent? Does that mean that it never works when using XamlReader.Load ? Because I could never get that to work, and that's a major problem. Everything in my interface except the root element is either created in code or with XamlReader.Load. From what I gather, that means I cannot put images, fonts, etc in my xap file. Thanks for taking the time to look into this. -Dan On Thu, Jul 31, 2008 at 3:39 AM, Jimmy Schementi wrote: > Dan, > > http://silverlight.net/forums/p/17003/76203.aspx#76203 > > You're definitely not doing anything wrong. Here's a repro of your issue: > > http://jimmy.schementi.com/silverlight/xaml-image-bug/ > > The crazy thing is this only repros in Firefox3, and is perfectly fine in IE8! Even crazier, I just made a C# project with the Silverlight VS tools, and it worked both in FF3 and IE8, ugh. There's nothing fundamentally different about the 2, so I'm a little confused. I'm trying to make a minimal C# repro and figure out who to blame, me or the SL team. =P > > ~js > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Dan Eloff >> Sent: Friday, July 11, 2008 11:53 PM >> To: Discussion of IronPython >> Subject: [IronPython] loading an image in silverlight, in xaml, from >> the .xap >> >> I cannot load an image from in the xap file via uri. >> >> This one has been bugging me for a long time now. I think it must have >> something to do with a difference between a Chiron xap and a VS built >> xap. >> >> Could someone on the silverlight team (Jimmy!) please take a look at >> the demo project and tell me what I'm doing wrong? >> >> http://silverlight.net/forums/t/17003.aspx >> >> Thanks, >> -Dan >> _______________________________________________ >> 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 Mon Aug 4 17:18:00 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 4 Aug 2008 08:18:00 -0700 Subject: [IronPython] Performance issue when calling a function with **kw In-Reply-To: <00bb01c8f554$09b78820$1d269860$@com> References: <00bb01c8f554$09b78820$1d269860$@com> Message-ID: There is a bit of extra code that's run when there are keyword arguments, but I don't think it should make this kind of difference. Please file a bug report in CodePlex at http://www.codeplex.com/IronPython/WorkItem/List.aspx. On Sun, Aug 3, 2008 at 3:31 AM, Asaf Kleinbort wrote: > Hi all, > > I am new to this list, so I'll first introduce myself. > > I am working at *IT Structures* (www.itstructures.com) in Israel. Our > service Is written in C#, but most of the backend implementation is written > in IronPython. > > While doing performance analysis of our application, I came across the > following interesting bug (?): > > > > Calling a function with **kw takes about 10 times more time than calling a > function with a simple dictionary. The difference exists also in cpython > but there the differences is hardly noticed. > > > > Here is a code snippet to clarify: > > ? > > *def func_kw(kw):* > > * return sum(kw.itervalues())* > > * * > > *def func(**kw):* > > * return sum(kw.itervalues())* > > * * > > *def measure(n):* > > * dct = {'1':2,'2':2,'3':2,'4':2,'5':2,'6':2}* > > * start = time.clock()* > > * for i in xrange(n):* > > * func_kw(dct)* > > * duration_without = time.clock()-start* > > * start = time.clock()* > > * for i in xrange(n):* > > * func(**dct)* > > * duration_with = time.clock()-start* > > * return (duration_without,duration_with)* > > *?* > > > > Running measure(10**6) 10 times in a loop and calculating the mean we get > the following results (in seconds): > > > > *In IronPython:* > > *WITH **KW: mean=5.56493157650, stddev=0.0649572929575.* > > *WITHOUT: mean=0.86113346808, stddev=0.0142532589459.* > > > > *In Python:* > > * WITH **KW: mean=1.70669562131, stddev=0.0230977726849.* > > * WITHOUT: mean=0.782945815118, stddev=0.00572116553432. * > > * * > > *(*IronPython version: IronPython 1.1.1 (1.1.1) on .NET 2.0.50727.1433 > > Python version: Python 2.5.1) > > > > Does anyone know if this is going to improve in version 2.0? > > _______________________________________________ > 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 Jimmy.Schementi at microsoft.com Mon Aug 4 23:40:26 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Mon, 4 Aug 2008 14:40:26 -0700 Subject: [IronPython] loading an image in silverlight, in xaml, from the .xap In-Reply-To: <4817b6fc0808031412n4070028ct460da31eca172243@mail.gmail.com> References: <4817b6fc0807112352n11f18dfexb6f7acb9fbfe69dd@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A32845D4A07EA2@NA-EXMSG-C116.redmond.corp.microsoft.com> <4817b6fc0808031412n4070028ct460da31eca172243@mail.gmail.com> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A32845D4AEA80D@NA-EXMSG-C116.redmond.corp.microsoft.com> > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dan Eloff > Sent: Sunday, August 03, 2008 2:13 PM > To: Discussion of IronPython > Subject: Re: [IronPython] loading an image in silverlight, in xaml, > from the .xap > > It loads the image in IE7 just fine, which is better than I ever got > it to do. It must be the use of LoadComponent? Yep, LoadComponent actually has knowledge of the XAP file and looks in there to resolve URLs first. XamlReader.Load doesn't know about the XAP, so it never looks in there. > Does that mean that it never works when using XamlReader.Load ? > Because I could never get that to work, and that's a major problem. > Everything in my interface except the root element is either created > in code or with XamlReader.Load. From what I gather, that means I > cannot put images, fonts, etc in my xap file. It does seem like a stupid limitation, so let me poke around and see if there's a solution. > Thanks for taking the time to look into this. > > -Dan FYI, I make a C# app that works fine in FF3, so it may be my fault. Again, I'll put this on my todo list. Even better, if you make sure to log a bug on codeplex.com/sdlsdk, I'll be sure to get to it. ~js > On Thu, Jul 31, 2008 at 3:39 AM, Jimmy Schementi > wrote: > > Dan, > > > > http://silverlight.net/forums/p/17003/76203.aspx#76203 > > > > You're definitely not doing anything wrong. Here's a repro of your > issue: > > > > http://jimmy.schementi.com/silverlight/xaml-image-bug/ > > > > The crazy thing is this only repros in Firefox3, and is perfectly > fine in IE8! Even crazier, I just made a C# project with the > Silverlight VS tools, and it worked both in FF3 and IE8, ugh. There's > nothing fundamentally different about the 2, so I'm a little confused. > I'm trying to make a minimal C# repro and figure out who to blame, me > or the SL team. =P > > > > ~js > > > >> -----Original Message----- > >> From: users-bounces at lists.ironpython.com [mailto:users- > >> bounces at lists.ironpython.com] On Behalf Of Dan Eloff > >> Sent: Friday, July 11, 2008 11:53 PM > >> To: Discussion of IronPython > >> Subject: [IronPython] loading an image in silverlight, in xaml, from > >> the .xap > >> > >> I cannot load an image from in the xap file via uri. > >> > >> This one has been bugging me for a long time now. I think it must > have > >> something to do with a difference between a Chiron xap and a VS > built > >> xap. > >> > >> Could someone on the silverlight team (Jimmy!) please take a look at > >> the demo project and tell me what I'm doing wrong? > >> > >> http://silverlight.net/forums/t/17003.aspx > >> > >> Thanks, > >> -Dan > >> _______________________________________________ > >> 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 maxyaffe at comcast.net Tue Aug 5 04:06:26 2008 From: maxyaffe at comcast.net (Max R. Yaffe) Date: Mon, 4 Aug 2008 22:06:26 -0400 Subject: [IronPython] Roadmap and updates Message-ID: <20080805020356.CAA2048002@diego.dreamhost.com> Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, however, seems to deprecate WinForms. I'm worried that IronPython and Microsoft are going to cut WinForms adrift just when I'm about to make a major investment in it. This might be the best approach for Microsoft because it seems the "community" is mainly interested in pictures, sounds, and the web. But I need something more classical. I'd appreciate your comments and direction. Max Yaffe Gamry Instruments, Inc. From kfarmer at thuban.org Tue Aug 5 04:21:37 2008 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 4 Aug 2008 19:21:37 -0700 Subject: [IronPython] Roadmap and updates References: <20080805020356.CAA2048002@diego.dreamhost.com> Message-ID: The question of Python + ? aside, I think your assessment of Silverlight is missing a couple points. Yes, Silverlight has been demoed with lots of pretty pictures, but the truth is that Silverlight is, fundamentally, a mini-CLR that runs in the browser (at least, Silverlight 2 certainly is -- I tend to ignore Silverlight 1). You can use it to write full-blown applications that run client-side, which can retrieve data from a back end. Don't let the sexy graphical displays obscure that simple, powerful fact. Consider a web page that has javascript making calls into a GUI-less Silverlight app -- Silverlight then becomes something of a high-speed resource (that is much more useful and powerful than random-ajax-toolkit). Yes, Silverlight is currently lacking in some basic controls, but those are currently being worked on both by Microsoft as well as third parties. See, for example: http://wpfwonderland.wordpress.com/2008/06/06/silverlight-2-beta-2-now-with-more-controls/ http://www.c-sharpcorner.com/UploadFile/nipuntomar/DataBindingSilverlightWCFService07152008011652AM/DataBindingSilverlightWCFService.aspx http://www.infragistics.com/hot/silverlight.aspx#InfragisticsandSilverlight I feel your pain on XAML -- I'm not the happiest with it, but you don't have to work in XAML if you don't want to. I'm pretty certain you could (as Petzold's book demonstrates for WPF) work XAML-free. You could also use the Silverlight tooling available in, for example, Expression. ________________________________ From: users-bounces at lists.ironpython.com on behalf of Max R. Yaffe Sent: Mon 8/4/2008 7:06 PM To: users at lists.ironpython.com Subject: [IronPython] Roadmap and updates Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, however, seems to deprecate WinForms. I'm worried that IronPython and Microsoft are going to cut WinForms adrift just when I'm about to make a major investment in it. This might be the best approach for Microsoft because it seems the "community" is mainly interested in pictures, sounds, and the web. But I need something more classical. I'd appreciate your comments and direction. Max Yaffe Gamry Instruments, Inc. _______________________________________________ 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 Tue Aug 5 04:50:32 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 4 Aug 2008 19:50:32 -0700 Subject: [IronPython] Roadmap and updates In-Reply-To: <20080805020356.CAA2048002@diego.dreamhost.com> References: <20080805020356.CAA2048002@diego.dreamhost.com> Message-ID: XAML is really just an XML-based object persistence format. It's not directly tied to the display technology that it's mostly used for, which is "WPF" or "Windows Presentation Foundation". It's really WPF that should be compared to Windows Forms -- you can use WPF without writing a single line of XAML (or having the designer write it on your behalf). If you're used to using the Win32 API or a thin wrapper over it like MFC, then Windows Forms is a lot closer to what you know already. That's because Windows Forms itself is a (somewhat thicker) wrapper over the same Win32 API. By contrast, WPF is a UI framework that's been redesigned from the ground up. Individual elements on a WPF window aren't represented by an window handle; there's only one HWND at the top which effectively provides a blank canvas for WPF to draw on. There are probably hundreds of thousands of applications built on USER32.DLL and/or Windows Forms. The odds that Microsoft abandons all of these applications are pretty low -- it is the applications, after all, that make the platform what it is. And although WPF is in many respects a much better-to-develop-for architecture than Windows Forms, it also isn't perhaps quite as mature -- and there are a few things that are still more easily done using Windows Forms than WPF, particularly in a line-of-business-style application. With respect to IronPython, we don't have much to say about the platform as a whole. You can execute just about any .NET code from within IronPython -- whether that's Windows Forms, WPF, WCF, WF, Managed DirectX or the CLR-based technologies that are just being invented now. So as long as Windows Forms exists, you'll be able to use it from IronPython. If your specific concern is related solely to Harry's comment about the Visual Studio integration work being more difficult for the Windows Forms designer than for the WPF designer, then I think you've read a little too much into what he said. Our intent is to support the Windows Forms designer. It may be that -- due to its quirks -- we're not able to do so in the early previews of the work, but I don't think that any of us would consider the integration done if it was WPF-only. Until then, you can always do what I understand Resolver Systems did: save your forms as C# and manually copy the generated code into your Python classes. The initialization code is so generic and predictable that you don't have to do much more than lop the semicolons off the ends of the lines. Disclaimer: I am a Microsoft employee, but I have absolutely no inside knowledge on any of the topics I've written on here other than those related directly to IronPython. On Mon, Aug 4, 2008 at 7:06 PM, Max R. Yaffe wrote: > Note: I originally wrote this to Harry Pierson directly who asked that I > post it publically. I hope it doesn't come off as too inflamatory. > > Harry - Thanks for the roadmap and the latest update. It clarifies a > particular issue that I'm having with deciding whether to adopt Iron Python > and .Net for that matter. My particular application is a scientific > instrument control and data analysis package. It runs on Windows now using > various older MS technologies (dating back to Windows 2.3!). It will not > need to run from a web browser, mainly because of the requirements for > instrument control. The application is highly scripted using a dynamic > language of my own devising derived from Smalltalk and remarkably similar > to > Python. > > I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my > technology. However, I wanted to see what Microsoft had to offer. > WinForms > + Python seems to be the best fit for my technology because of the need to > manipulate data tables and my desire to avoid the web. Silverlight just > doesn't offer me any advantage and seems to be directed at pretty pictures > and sounds. It also doesn't seem to handle the kinds of user/data > interaction I need. XAML also doesn't seem to offer any advantage for my > code, or if it does, it certainly isn't clear what it might be other than a > YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, > however, seems to deprecate WinForms. I'm worried that IronPython and > Microsoft are going to cut WinForms adrift just when I'm about to make a > major investment in it. This might be the best approach for Microsoft > because it seems the "community" is mainly interested in pictures, sounds, > and the web. But I need something more classical. > > I'd appreciate your comments and direction. > > Max Yaffe > Gamry Instruments, Inc. > > _______________________________________________ > 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 hrhan at att.net Tue Aug 5 05:03:55 2008 From: hrhan at att.net (Howard Hansen) Date: Mon, 04 Aug 2008 22:03:55 -0500 Subject: [IronPython] Roadmap and updates In-Reply-To: <20080805020356.CAA2048002@diego.dreamhost.com> References: <20080805020356.CAA2048002@diego.dreamhost.com> Message-ID: <4897C31B.6070703@att.net> Max R. Yaffe wrote: > Note: I originally wrote this to Harry Pierson directly who asked that I > post it publically. I hope it doesn't come off as too inflamatory. > > Harry - Thanks for the roadmap and the latest update. It clarifies a > particular issue that I'm having with deciding whether to adopt Iron Python > and .Net for that matter. My particular application is a scientific > instrument control and data analysis package. It runs on Windows now using > various older MS technologies (dating back to Windows 2.3!). It will not > need to run from a web browser, mainly because of the requirements for > instrument control. The application is highly scripted using a dynamic > language of my own devising derived from Smalltalk and remarkably similar to > Python. > > I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my > technology. However, I wanted to see what Microsoft had to offer. WinForms > + Python seems to be the best fit for my technology because of the need to > manipulate data tables and my desire to avoid the web. Silverlight just > doesn't offer me any advantage and seems to be directed at pretty pictures > and sounds. It also doesn't seem to handle the kinds of user/data > interaction I need. XAML also doesn't seem to offer any advantage for my > code, or if it does, it certainly isn't clear what it might be other than a > YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, > however, seems to deprecate WinForms. I'm worried that IronPython and > Microsoft are going to cut WinForms adrift just when I'm about to make a > major investment in it. This might be the best approach for Microsoft > because it seems the "community" is mainly interested in pictures, sounds, > and the web. But I need something more classical. > > I'd appreciate your comments and direction. > > Max Yaffe > Gamry Instruments, Inc. > I am wondering why you haven't looked at WPF, Windows Presentation Foundation, and IronPython. You can develop your interface in WPF without using XAML and IronPython will eventually be compatible with Cpython 2.5. Howard > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From dblank at brynmawr.edu Tue Aug 5 05:04:53 2008 From: dblank at brynmawr.edu (Douglas Blank) Date: Mon, 4 Aug 2008 23:04:53 -0400 (EDT) Subject: [IronPython] Roadmap and updates In-Reply-To: Message-ID: <2034347242.440081217905493228.JavaMail.root@ganesh.brynmawr.edu> ----- "Curt Hagenlocher" wrote: > The initialization code is so generic and predictable > that you don't have to do much more than lop the semicolons off the > ends of the lines. Of course, you don't even have to do that as Python allows semicolons on the ends :) Another way to answer your question, Max, is that Mono supports WinForms too. We are working on a similar project, but I think IronPython + WinForms is where we will be for a few years. But, we aren't writing our base libraries in Python anymore, but C#. That way it still looks the same in Python, but the the other DLR languages can use them too. And you can use other alternate operating systems. I predict that there will be a huge number of DLR languages in the next few years, and your uses can switch languages while keeping the base libraries, if you write in C#. -Doug > Disclaimer: I am a Microsoft employee, but I have absolutely no inside > knowledge on any of the topics I've written on here other than those > related directly to IronPython. > > On Mon, Aug 4, 2008 at 7:06 PM, Max R. Yaffe < maxyaffe at comcast.net > > wrote: > > > Note: I originally wrote this to Harry Pierson directly who asked that > I > post it publically. I hope it doesn't come off as too inflamatory. > > Harry - Thanks for the roadmap and the latest update. It clarifies a > particular issue that I'm having with deciding whether to adopt Iron > Python > and .Net for that matter. My particular application is a scientific > instrument control and data analysis package. It runs on Windows now > using > various older MS technologies (dating back to Windows 2.3!). It will > not > need to run from a web browser, mainly because of the requirements for > instrument control. The application is highly scripted using a dynamic > language of my own devising derived from Smalltalk and remarkably > similar to > Python. > > I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to > updating my > technology. However, I wanted to see what Microsoft had to offer. > WinForms > + Python seems to be the best fit for my technology because of the > need to > manipulate data tables and my desire to avoid the web. Silverlight > just > doesn't offer me any advantage and seems to be directed at pretty > pictures > and sounds. It also doesn't seem to handle the kinds of user/data > interaction I need. XAML also doesn't seem to offer any advantage for > my > code, or if it does, it certainly isn't clear what it might be other > than a > YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, > however, seems to deprecate WinForms. I'm worried that IronPython and > Microsoft are going to cut WinForms adrift just when I'm about to make > a > major investment in it. This might be the best approach for Microsoft > because it seems the "community" is mainly interested in pictures, > sounds, > and the web. But I need something more classical. > > I'd appreciate your comments and direction. > > Max Yaffe > Gamry Instruments, Inc. > > _______________________________________________ > 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 Aug 5 06:00:41 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 4 Aug 2008 21:00:41 -0700 Subject: [IronPython] Security of DLR host In-Reply-To: <62ddb6fb0808030839j28c099a8t1855c1f3ebbc1666@mail.gmail.com> References: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A36E@NA-EXMSG-C112.redmond.corp.microsoft.com> <62ddb6fb0808030103q36fae5f2le9ce8b8cf4f756e5@mail.gmail.com> <4895C543.2020301@voidspace.org.uk> <62ddb6fb0808030839j28c099a8t1855c1f3ebbc1666@mail.gmail.com> Message-ID: On Sun, Aug 3, 2008 at 8:39 AM, Pavel ?avara wrote: > > With Silverlight you can use the Platform Adaptation Layer to control > > imports though. The DLR hosting specs has some details on this > (Silverlight > > uses the PAL so that imports are resolved by searching inside the xap > file - > > a modified PAL could ban imports altogether). > > I looked at your articles about that on voidspace. Unfortunately in > last sdl-sdk things look different. > There is no direct way how to change PAL anymore. In what will be released shortly as the next beta of IronPython, you replace the PAL by deriving a custom class from ScriptHost and overriding the PlatformAdaptationLayer property. When you create a ScriptRuntime, you specify the host by setting ScriptRuntimeSetup.HostType to equal the type of your derived class. That's exactly what the Microsoft.Scripting.Silverlight project does. It's quite possible that this was already how it worked in the previous beta, but I don't have those sources handy. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jimmy.Schementi at microsoft.com Tue Aug 5 08:36:58 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Mon, 4 Aug 2008 23:36:58 -0700 Subject: [IronPython] Security of DLR host In-Reply-To: References: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A36E@NA-EXMSG-C112.redmond.corp.microsoft.com> <62ddb6fb0808030103q36fae5f2le9ce8b8cf4f756e5@mail.gmail.com> <4895C543.2020301@voidspace.org.uk> <62ddb6fb0808030839j28c099a8t1855c1f3ebbc1666@mail.gmail.com> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A32845D4AEA9CB@NA-EXMSG-C116.redmond.corp.microsoft.com> Curt, that's how the previous beta worked, so things haven't really changed. I think what Paval means is that there's a child PAL, in SL's case a BrowserPAL, which inherits from PlatformAdaptationLayer. In Silverlight we also had a BrowserScriptHost, which inherited from ScriptHost, and ScriptRuntimeSetup.HostType is set to that BrowserScriptHost instance. Anyway, things are the same ... =P ~js From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Monday, August 04, 2008 9:01 PM To: Discussion of IronPython Subject: Re: [IronPython] Security of DLR host On Sun, Aug 3, 2008 at 8:39 AM, Pavel ?avara > wrote: > With Silverlight you can use the Platform Adaptation Layer to control > imports though. The DLR hosting specs has some details on this (Silverlight > uses the PAL so that imports are resolved by searching inside the xap file - > a modified PAL could ban imports altogether). I looked at your articles about that on voidspace. Unfortunately in last sdl-sdk things look different. There is no direct way how to change PAL anymore. In what will be released shortly as the next beta of IronPython, you replace the PAL by deriving a custom class from ScriptHost and overriding the PlatformAdaptationLayer property. When you create a ScriptRuntime, you specify the host by setting ScriptRuntimeSetup.HostType to equal the type of your derived class. That's exactly what the Microsoft.Scripting.Silverlight project does. It's quite possible that this was already how it worked in the previous beta, but I don't have those sources handy. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh at defuze.org Tue Aug 5 09:04:39 2008 From: sh at defuze.org (Sylvain Hellegouarch) Date: Tue, 5 Aug 2008 09:04:39 +0200 (CEST) Subject: [IronPython] Roadmap and updates In-Reply-To: <20080805020356.CAA2048002@diego.dreamhost.com> References: <20080805020356.CAA2048002@diego.dreamhost.com> Message-ID: <50952.195.101.247.164.1217919879.squirrel@mail1.webfaction.com> Hi, > Note: I originally wrote this to Harry Pierson directly who asked that I > post it publically. I hope it doesn't come off as too inflamatory. > > Harry - Thanks for the roadmap and the latest update. It clarifies a > particular issue that I'm having with deciding whether to adopt Iron > Python > and .Net for that matter. My particular application is a scientific > instrument control and data analysis package. It runs on Windows now > using > various older MS technologies (dating back to Windows 2.3!). It will not > need to run from a web browser, mainly because of the requirements for > instrument control. The application is highly scripted using a dynamic > language of my own devising derived from Smalltalk and remarkably similar > to > Python. > > I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my > technology. However, I wanted to see what Microsoft had to offer. > WinForms > + Python seems to be the best fit for my technology because of the need to > manipulate data tables and my desire to avoid the web. Silverlight just > doesn't offer me any advantage and seems to be directed at pretty pictures > and sounds. It also doesn't seem to handle the kinds of user/data > interaction I need. XAML also doesn't seem to offer any advantage for my > code, or if it does, it certainly isn't clear what it might be other than > a > YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, > however, seems to deprecate WinForms. I'm worried that IronPython and > Microsoft are going to cut WinForms adrift just when I'm about to make a > major investment in it. This might be the best approach for Microsoft > because it seems the "community" is mainly interested in pictures, sounds, > and the web. But I need something more classical. > > I'd appreciate your comments and direction. > I will not comment on the state of Silverlight or XAML as I don't use them but I've been using the PyQt4+Python2.5 combination for some time and it's been working great. My main concern with IronPython at this stage is its inability to offer a clear view of its capacity to support pure Python libraries. I keep running in shortcomings or bugs [1] that make me nervous about investing time in IP when using existing pure Python libraries. I do understand IP is still in beta and bugs are expected at this stage but not having an up-to-date grid of what is officially implemented, supported, worked on is rather frustrating. In other words, if you start from scratch then IP+.NET is a solid choice but if you already have a large bunch of Python code I would personally be very careful as you might end up having to spend quite a lot of time in debugging the reason why your code isn't working as expected, opening tickets on CodePlex and never hearing about their progress again until they are potentially fixed. I do not want to sound like I downplay the IP team work, not at all, but the lack of visibility is not playing in their favor in my opinion. Writing code is one thing, giving recurrent feedback is sometimes worth more ;) I believe IP is worth the interest but keep in mind the product is still rather a long way. - Sylvain [1] http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17561 It might not sound like it but that bug was quite hard to track down because of the rather poor traceback information provided by IP as well as the fact that the IndexError, though a consequence of the bug, wasn't immediate to correlate back to the bug itself. -- Sylvain Hellegouarch http://www.defuze.org From sh at defuze.org Tue Aug 5 09:24:09 2008 From: sh at defuze.org (Sylvain Hellegouarch) Date: Tue, 5 Aug 2008 09:24:09 +0200 (CEST) Subject: [IronPython] Roadmap and updates In-Reply-To: <50952.195.101.247.164.1217919879.squirrel@mail1.webfaction.com> References: <20080805020356.CAA2048002@diego.dreamhost.com> <50952.195.101.247.164.1217919879.squirrel@mail1.webfaction.com> Message-ID: <53533.195.101.247.164.1217921049.squirrel@mail1.webfaction.com> > I do not want to sound like I downplay the IP team work, not at all, but > the lack of visibility is not playing in their favor in my opinion. > Writing code is one thing, giving recurrent feedback is sometimes worth > more ;) > I wanted to reiterate that I don't downplay the IP team's work. They've been very responsive and friendly to the community. However, visibility is sometimes lacking (mind you like many other large OSS projects ;)). I do realize as well that if I don't ask questions, I won't have answers... - Sylvain -- Sylvain Hellegouarch http://www.defuze.org From giles.thomas at resolversystems.com Tue Aug 5 12:33:07 2008 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Tue, 05 Aug 2008 11:33:07 +0100 Subject: [IronPython] Roadmap and updates In-Reply-To: References: <20080805020356.CAA2048002@diego.dreamhost.com> Message-ID: <48982C63.9030701@resolversystems.com> Curt Hagenlocher wrote: > Until then, you can always do what I understand Resolver Systems > did: save your forms as C# and manually copy the generated code > into your Python classes. The initialization code is so generic and > predictable that you don't have to do much more than lop the > semicolons off the ends of the lines. Not quite - we generate C# base classes from Visual Studio, then write IronPython subclasses to add the behaviour. Cheers, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From fuzzyman at voidspace.org.uk Tue Aug 5 12:36:56 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 05 Aug 2008 11:36:56 +0100 Subject: [IronPython] Roadmap and updates In-Reply-To: <48982C63.9030701@resolversystems.com> References: <20080805020356.CAA2048002@diego.dreamhost.com> <48982C63.9030701@resolversystems.com> Message-ID: <48982D48.6040803@voidspace.org.uk> Giles Thomas wrote: > Curt Hagenlocher wrote: >> Until then, you can always do what I understand Resolver Systems did: >> save your forms as C# and manually copy the generated code into your >> Python classes. The initialization code is so generic and >> predictable that you don't have to do much more than lop the >> semicolons off the ends of the lines. > > Not quite - we generate C# base classes from Visual Studio, then write > IronPython subclasses to add the behaviour. > This means that we can always edit the forms in the designer - and because the generated code is in C# no-one feels tempted to tinker with it... As Giles says, all the actual behaviour is implemented in Python - we just use the designer for the layout. Michael > Cheers, > > Giles > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.ironpython.info/ From curt at hagenlocher.org Tue Aug 5 14:30:52 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 5 Aug 2008 05:30:52 -0700 Subject: [IronPython] Roadmap and updates In-Reply-To: <48982C63.9030701@resolversystems.com> References: <20080805020356.CAA2048002@diego.dreamhost.com> <48982C63.9030701@resolversystems.com> Message-ID: On Tue, Aug 5, 2008 at 3:33 AM, Giles Thomas < giles.thomas at resolversystems.com> wrote: > Curt Hagenlocher wrote: > >> Until then, you can always do what I understand Resolver Systems did: save >> your forms as C# and manually copy the generated code into your Python >> classes. The initialization code is so generic and predictable that you >> don't have to do much more than lop the semicolons off the ends of the >> lines. >> > > Not quite - we generate C# base classes from Visual Studio, then write > IronPython subclasses to add the behaviour. > Thanks for the clarification. I was misremembering the quoted mail at http://www.mail-archive.com/users-ironpython.com at lists.ironpython.com/msg00451.html . -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.elfgren at avalanchestudios.se Tue Aug 5 16:49:30 2008 From: anders.elfgren at avalanchestudios.se (Anders Elfgren) Date: Tue, 5 Aug 2008 16:49:30 +0200 Subject: [IronPython] Using a c library as a dll or assembly In-Reply-To: References: <698E8783CC407F4EB0DC9E994B6D4540906D64@nut.avalanchestudios.se><698E8783CC407F4EB0DC9E994B6D4540906DC5@nut.avalanchestudios.se> Message-ID: <698E8783CC407F4EB0DC9E994B6D45409070CB@nut.avalanchestudios.se> Thanks a bunch! Seems I've gotten past my current problems. My next question, and I think I've heard something about this, but I'm not sure... Now that I've got my python code hooked up to ironpython, there shouldn't be anything that's python anymore, so to speak, right? I mean, when I import a python module using ironpython, it's all .net. My question is: What is the best way to access these classes in C#? Is it possible? I want to build up a gui containing data from the classes I've instantiated, and it would be nicer to do that in C# using VS. Another (unrelated) question: What's the best way to debug IronPython programs? "print-debugging" is not very effective. (maybe this deserves a mail thread of its own) /Anders ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: den 1 augusti 2008 16:39 To: Discussion of IronPython Subject: Re: [IronPython] Using a c library as a dll or assembly Here's how I think I would do it. Add a class definition to your C source that looks something like this: using namespace System::Runtime::InteropServices; ref class Exported { public: static int AdfHash(String^ str) { const char* str2 = (char*)(void*)Marshal::StringToHGlobalAnsi(str); int result = ::AdfHash(str2); Marshal::FreeHGlobal((System::IntPtr)(void*)str2); return result; } } You should then be able to import the Exported class from the assembly and access AdfHash through it. You'll need to write a similar wrapper for every function you want to export. Disclaimer: I've never actually used either Managed C++ or C++/CLI except to write small test cases. On Fri, Aug 1, 2008 at 4:25 AM, Anders Elfgren wrote: Hi, thanks for the comments! In this case, I'm not trying to access a class, just a simple function that takes a string (char* ) and returns an int. I was hoping that would make it easier. I've compiled the dll with /CLR and I can load it like this: import clr clr.AddReference("System.Windows.Forms") clr.LoadAssemblyByName("AdfDll_R.dll") However, I still can't access anything inside it. Do I need to do something more? (if I try to load a dll that doesn't exist I get an error, so I'm assuming that there's not a problem with my dll). I've tried adding an import but I just get No module named AdfDll_R. The function is declared as: #ifdef __cplusplus extern "C" { #endif uint32 AdfHash(const char *str); } But when I try to call it, it doesn't work: NameError: name 'AdfHash' not defined I'm exporting the functions using a def file that looks (pretty much) like this: LIBRARY AdfDll_R EXPORTS ; from Adf.h AdfHash I'm using IronPython 1.1.1, but if it helps I'll be glad to change to another version. /Anders ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: den 31 juli 2008 20:21 To: Discussion of IronPython Subject: Re: [IronPython] Using a c library as a dll or assembly It wouldn't be sufficient to recompile with /clr. When you do that, your classes don't automatically become managed classes. You would still need to either modify your classes or to create wrappers using C++/CLI (http://en.wikipedia.org/wiki/C%2B%2B/CLI). In order for a C++ class to be visible to IronPython, it would need to be declared as a "ref class" -- you can see more about that at the referenced Wikipedia article. On Thu, Jul 31, 2008 at 9:22 AM, Anders Elfgren wrote: Hi, First let me say that I'm new to Iron Python, but at least I've read this in the FAQ.. :) Q: How do I build and call into PYD libraries? A: IronPython does not support using PYDs built for CPython since they leverage implementation details of CPython. You can get a similar effect for new "PYD"s you would like to implement by writing them in C# or VB and building a DLL for .NET. That said, I've got some questions to see if what I'm doing is possible anyway. We've got a c library of which most of the code has also been written in Python. We want to create an editor using .net forms which we can use to edit some files, and to do that we need some data structures that exist in this library. My current idea is to interface against the python library using IronPython, and then accessing the datastructures through that in C# (although if absolutely necessary, we could write the editor in IronPython too). The thing that is standing against me now is that one function that exists a small C dll. Since IronPython can't access this (unless this has changed since the FAQ was written?), I was thinking that maybe I can compile the dll using the /clr flag and thus get a .net assembly. Would I then be able to use the function? The Python code just tries to import it: import AvHash And then use it.. def AdfHash(str): return AvHash.HashString(str) At the import statement, this error is raised: Traceback (most recent call last): File X:\ctg\libs\ADF\main\common\modeditor.ipy, line 20, in Initialize File , line 0, in __import__##4 File X:\ctg\libs\ADF\main\common\AdfLib.py, line 1, in Initialize File , line 0, in __import__##4 ImportError: No module named AvHash Or is there some other solution? I've just started researching how to interface between C/C#/Python/IronPython so there may well be things I haven't heard of... I hope I've made my problem clear, thanks for any responses. :) /Anders _______________________________________________ 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 curt at hagenlocher.org Tue Aug 5 17:46:58 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 5 Aug 2008 08:46:58 -0700 Subject: [IronPython] Using a c library as a dll or assembly In-Reply-To: <698E8783CC407F4EB0DC9E994B6D45409070CB@nut.avalanchestudios.se> References: <698E8783CC407F4EB0DC9E994B6D4540906D64@nut.avalanchestudios.se> <698E8783CC407F4EB0DC9E994B6D4540906DC5@nut.avalanchestudios.se> <698E8783CC407F4EB0DC9E994B6D45409070CB@nut.avalanchestudios.se> Message-ID: It's much easier to use C# (or other .NET) code from IronPython than vice versa. In order to call your Python code from a C# app, you'll need to use the hosting interface. This has changed substantially between IronPython 1.x and IronPython 2.0, so you'll need to decide which you're targeting before you invest too much time into it. A good resource for this and other IronPython-related stuff is the IronPython cookbook. Go to http://www.ironpython.info/index.php/Contents and scroll down to "Embedding" for this particular topic. On Tue, Aug 5, 2008 at 7:49 AM, Anders Elfgren < anders.elfgren at avalanchestudios.se> wrote: > Thanks a bunch! > > Seems I've gotten past my current problems. > > My next question, and I think I've heard something about this, but I'm not > sure... > Now that I've got my python code hooked up to ironpython, there shouldn't > be anything that's python anymore, so to speak, right? I mean, when I import > a python module using ironpython, it's all .net. > > My question is: What is the best way to access these classes in C#? Is it > possible? I want to build up a gui containing data from the classes I've > instantiated, and it would be nicer to do that in C# using VS. > > Another (unrelated) question: What's the best way to debug IronPython > programs? "print-debugging" is not very effective. (maybe this deserves a > mail thread of its own) > > /Anders > > ------------------------------ > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Curt Hagenlocher > *Sent:* den 1 augusti 2008 16:39 > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Using a c library as a dll or assembly > > Here's how I think I would do it. Add a class definition to your C > source that looks something like this: > > using namespace System::Runtime::InteropServices; > > ref class Exported { > public: > static int AdfHash(String^ str) { > const char* str2 = (char*)(void*)Marshal::StringToHGlobalAnsi(str); > int result = ::AdfHash(str2); > Marshal::FreeHGlobal((System::IntPtr)(void*)str2); > return result; > } > } > You should then be able to import the Exported class from the assembly and > access AdfHash through it. You'll need to write a similar wrapper for every > function you want to export. > > Disclaimer: I've never actually used either Managed C++ or C++/CLI except > to write small test cases. > > On Fri, Aug 1, 2008 at 4:25 AM, Anders Elfgren < > anders.elfgren at avalanchestudios.se> wrote: > >> Hi, thanks for the comments! >> In this case, I'm not trying to access a class, just a simple function >> that takes a string (char* ) and returns an int. I was hoping that would >> make it easier. >> >> I've compiled the dll with /CLR and I can load it like this: >> >> import clr >> clr.AddReference("System.Windows.Forms") >> clr.LoadAssemblyByName("AdfDll_R.dll") >> >> However, I still can't access anything inside it. Do I need to do >> something more? (if I try to load a dll that doesn't exist I get an error, >> so I'm assuming that there's not a problem with my dll). I've tried adding >> an import but I just get No module named AdfDll_R. >> >> >> The function is declared as: >> >> #ifdef __cplusplus >> extern "C" { >> #endif >> >> uint32 AdfHash(const char *str); >> >> } >> >> But when I try to call it, it doesn't work: >> NameError: name 'AdfHash' not defined >> >> >> >> I'm exporting the functions using a def file that looks (pretty much) like >> this: >> LIBRARY AdfDll_R >> EXPORTS >> >> ; from Adf.h >> AdfHash >> >> I'm using IronPython 1.1.1, but if it helps I'll be glad to change to >> another version. >> >> /Anders >> >> ------------------------------ >> *From:* users-bounces at lists.ironpython.com [mailto: >> users-bounces at lists.ironpython.com] *On Behalf Of *Curt Hagenlocher >> *Sent:* den 31 juli 2008 20:21 >> *To:* Discussion of IronPython >> *Subject:* Re: [IronPython] Using a c library as a dll or assembly >> >> It wouldn't be sufficient to recompile with /clr. When you do that, >> your classes don't automatically become managed classes. You would still >> need to either modify your classes or to create wrappers using C++/CLI ( >> http://en.wikipedia.org/wiki/C%2B%2B/CLI). In order for a C++ class to >> be visible to IronPython, it would need to be declared as a "ref class" -- >> you can see more about that at the referenced Wikipedia article. >> >> >> On Thu, Jul 31, 2008 at 9:22 AM, Anders Elfgren < >> anders.elfgren at avalanchestudios.se> wrote: >> >>> Hi, >>> >>> First let me say that I'm new to Iron Python, but at least I've read this >>> in the FAQ.. :) >>> >>> Q: How do I build and call into *PYD* libraries? >>> A: *IronPython* does not support using PYDs built for CPython since they >>> leverage implementation details of CPython. You can get a similar effect >>> for new "*PYD*"s you would like to implement by writing them in C# or VB >>> and building a DLL for .NET. >>> >>> That said, I've got some questions to see if what I'm doing is possible >>> anyway. >>> >>> We've got a c library of which most of the code has also been written in >>> Python. We want to create an editor using .net forms which we can use to >>> edit some files, and to do that we need some data structures that exist in >>> this library. >>> >>> My current idea is to interface against the python library using >>> IronPython, and then accessing the datastructures through that in C# >>> (although if absolutely necessary, we could write the editor in IronPython >>> too). The thing that is standing against me now is that one function that >>> exists a small C dll. Since IronPython can't access this (unless this has >>> changed since the FAQ was written?), I was thinking that maybe I can compile >>> the dll using the /clr flag and thus get a .net assembly. Would I then be >>> able to use the function? >>> >>> The Python code just tries to import it: >>> import AvHash >>> >>> And then use it.. >>> def AdfHash(str): >>> return AvHash.HashString(str) >>> >>> >>> At the import statement, this error is raised: >>> Traceback (most recent call last): >>> File X:\ctg\libs\ADF\main\common\modeditor.ipy, line 20, in Initialize >>> File , line 0, in __import__##4 >>> File X:\ctg\libs\ADF\main\common\AdfLib.py, line 1, in Initialize >>> File , line 0, in __import__##4 >>> ImportError: No module named AvHash >>> >>> >>> >>> Or is there some other solution? I've just started researching how to >>> interface between C/C#/Python/IronPython so there may well be things I >>> haven't heard of... >>> I hope I've made my problem clear, thanks for any responses. :) >>> >>> /Anders >>> >>> >>> _______________________________________________ >>> 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 exchange.microsoft.com Tue Aug 5 21:27:30 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 5 Aug 2008 12:27:30 -0700 Subject: [IronPython] Performance issue when calling a function with **kw In-Reply-To: <5b0248170808030347v45016c94t35345fb7d4d12ead@mail.gmail.com> References: <00bb01c8f554$09b78820$1d269860$@com> <5b0248170808030347v45016c94t35345fb7d4d12ead@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227012C9376C371@DF-GRTDANE-MSG.exchange.corp.microsoft.com> On my machine it is about 40% faster in 2.0 than 1.1.1 but still about 2x slower than CPython: Current 2.0 bits: (0.930676873737, 3.53996855746) 1.1.1: (1.07254462509, 6.25653658496) CPython 2.5.2: (0.83603013790858893, 1.8179086308455403) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Sunday, August 03, 2008 3:47 AM To: Discussion of IronPython Subject: Re: [IronPython] Performance issue when calling a function with **kw 2008/8/3 Asaf Kleinbort : > Calling a function with **kw takes about 10 times more time than calling a > function with a simple dictionary. The difference exists also in cpython > but there the differences is hardly noticed. > > Does anyone know if this is going to improve in version 2.0? As far as I can tell IronPython 2 does not improve this case. However, IronPython 2 does improve *seq case, more than a factor of two, compared to IronPython 1. I have a plan to do a comprehensive benchmark of call sequences for CPython, IronPython 1, and IronPython 2, based on callbench developed in PyPy. Ah, procrastination... -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From pavel.savara at gmail.com Tue Aug 5 22:25:56 2008 From: pavel.savara at gmail.com (=?UTF-8?Q?Pavel_=C5=A0avara?=) Date: Tue, 5 Aug 2008 22:25:56 +0200 Subject: [IronPython] Security of DLR host In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A32845D4AEA9CB@NA-EXMSG-C116.redmond.corp.microsoft.com> References: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A36E@NA-EXMSG-C112.redmond.corp.microsoft.com> <62ddb6fb0808030103q36fae5f2le9ce8b8cf4f756e5@mail.gmail.com> <4895C543.2020301@voidspace.org.uk> <62ddb6fb0808030839j28c099a8t1855c1f3ebbc1666@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A32845D4AEA9CB@NA-EXMSG-C116.redmond.corp.microsoft.com> Message-ID: <62ddb6fb0808051325l7cca7399ucba5bc6b4c71d5a4@mail.gmail.com> > Anyway, things are the same ? =P Anyway, it switching and subclassing of PAL is useless for me because assembly is already loaded. Please see the other post I sent 2 days ago to this thread. My questions now are: 1) Is there any other idea ? 2) Is security of coreCLR able to manage security between different user assemblies ? Could I lower thread privileges before calling another (but untrusted) assembly code ? Could I at least ban access to security critical methods ? I don't think so, but maybe I missed something. 3) Could be IL generated by DLR somehow intercepted (for security reasons) ? Thanks Pavel. From huzi_1982 at hotmail.com Wed Aug 6 01:45:52 2008 From: huzi_1982 at hotmail.com (Huzaifa) Date: Tue, 5 Aug 2008 16:45:52 -0700 (PDT) Subject: [IronPython] IronPython.Runtime.Exceptions.ImportException: No module named System Message-ID: <18841986.post@talk.nabble.com> I am trying this code , and it is giving me this exception "IronPython.Runtime.Exceptions.ImportException: No module named System" input = _scriptEngine.CreateScriptSourceFromString ( @"import clr from System import * clr.AddReferenceToFile("ABC.dll') ", System.Scripting.SourceCodeKind.Statements); input.Execute (defaultScope); IronPython.Runtime.Exceptions.ImportException: No module named System I think it is not able to find the location of System.dll. If it would be Py 1.1 i could do like this _pyEngine.Sys.path.Add(path); but how to do it in 2.0 -- View this message in context: http://www.nabble.com/IronPython.Runtime.Exceptions.ImportException%3A-No-module-named-System-tp18841986p18841986.html Sent from the IronPython mailing list archive at Nabble.com. From dinov at exchange.microsoft.com Wed Aug 6 01:48:21 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 5 Aug 2008 16:48:21 -0700 Subject: [IronPython] IronPython.Runtime.Exceptions.ImportException: No module named System In-Reply-To: <18841986.post@talk.nabble.com> References: <18841986.post@talk.nabble.com> Message-ID: <7AD436E4270DD54A94238001769C2227012C9376C430@DF-GRTDANE-MSG.exchange.corp.microsoft.com> You need to add the DLLs you want to be available for importing. We used to add System/mscorlib for you but don't anymore. I suggest doing yourScriptRuntime.LoadAssembly(typeof(System.Diagnostics.Debug).Assembly); -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Huzaifa Sent: Tuesday, August 05, 2008 4:46 PM To: users at lists.ironpython.com Subject: [IronPython] IronPython.Runtime.Exceptions.ImportException: No module named System I am trying this code , and it is giving me this exception "IronPython.Runtime.Exceptions.ImportException: No module named System" input = _scriptEngine.CreateScriptSourceFromString ( @"import clr from System import * clr.AddReferenceToFile("ABC.dll') ", System.Scripting.SourceCodeKind.Statements); input.Execute (defaultScope); IronPython.Runtime.Exceptions.ImportException: No module named System I think it is not able to find the location of System.dll. If it would be Py 1.1 i could do like this _pyEngine.Sys.path.Add(path); but how to do it in 2.0 -- View this message in context: http://www.nabble.com/IronPython.Runtime.Exceptions.ImportException%3A-No-module-named-System-tp18841986p18841986.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 srivatsn at microsoft.com Wed Aug 6 01:55:54 2008 From: srivatsn at microsoft.com (Srivatsn Narayanan) Date: Tue, 5 Aug 2008 16:55:54 -0700 Subject: [IronPython] Announcing IronPython 2.0 Beta4 Message-ID: Hello IronPython Community, I'm pleased to announce IronPython 2.0 Beta4. We have fixed around 50 bugs(~45 of them reported on Codeplex and ~5 reported internally). Apart from these bug fixes, the following are the highlights of this release: * This release ships with a MSI installer that installs IronPython along with the Python Standard Library. It is now dual-licensed with IronPython shipping under MS-PL and the python standard library shipping under the Python Software Foundation license. This means that existing python libraries are readily available after installation and makes for a better out-of-the-box experience of using existing CPython libraries. A zip file containing the binaries is still available as before. * Static compilation of python files is now supported again and the pyc.py sample has been updated to use the newer version. * IDispatch-based cominterop is now the default mode as opposed to generating interop assemblies for interacting with COM components. This is a change that might break some existing scripts. One can switch back to the old behavior by setting the environment variable COREDLR_PreferComInteropAssembly. Read this blog for more details on this feature. * Apart from the Silverlight binaries and Chiron, the templates and tools to create a barebones app are included as well. This is in the Silverlight\Script folder. * Performance degrades that were reported in Beta 3 have been fixed. The following Codeplex items have been closed since IronPython 2.0 Beta3: * nt.popen(...) breaks where ... consists of cmd.exe commands * globals().fromkeys(...) broken * globals().Values enumerator broken * Trivial: nt.tempnam("", None) broken * Trivial: Remove exceptions.OverflowWarning * New-style class dicts (dictproxy) cannot be used for C# methods with IDictionary parameters * Negative: ipyw.exe run w/o args crashes * 'dictproxy' object has no attribute 'copy' * class.__dict__ (dictproxy) doesn't support .get * repr() of a UserList containing another userList is wrong * NaN == NaN * DBNull should implement __nonzero__ that always returns false. * IP implementation of _sha512 has extra module attributes * Dir on textbox raises exception * re.compile(...).match(...) does not permit certain integer pos/endpos keyword parameter values * re.compile(...).match(...).groupdict() broken WRT to unnamed groups * re.match(..., ...).regs is nearly always incorrect * datetime.datetime.fromtimestamp() is not POSIX timestamp * Trivial: Charset name * datetime.datetime.utcfromtimestamp() * datetime.datetime.isoformat() has no parameter * nt.fstat(...) broken * Python25: __hash__ returning longs broken on old style classes WRT CPython 2.5 * Trivial: IronPython converts -0x80000000 to a long (should be int) * -X:TabCompletion broken in IP2.0A1 WRT simple variable expansion * import socket * TypeError: staticmethod is not callable when overriding __new__ in old+new derived type * using the PropertyGrid class - SelectedObject issue * new.classobj fails with "TypeError: __bases__ items must be classes (got type)" * dict(...) broken on new style class dictionaries (dictproxy) * IronPython should not implement _weakref.proxy.__eq__ * nt.stat(someDirectory) is broken * Trivial: Implement 'file(...).mode' * Trivial: os.chmod followed by os.unlink fails * os.umask does not exist * Regular Expression incompatibility * co_filename in code objects is None * Trivial: help(clr.AddReference) not helpful * tb_line member of Traceback objects is incorrect * Valid regex under CPython will fail with IronPython * time.timezone has different semantic than in cpython * IronPython 2.0B2 cannot iterate over an IEnumerable returned from a C# method using yield * Implement os.system (nt.system) * cStringIO 1-arg .read() and .readlines() broken * Trivial: id should return int or long, not Int64 We'd like to thank everyone in the community who reported these bugs: jdhardy, Wilberforce, Eloff, Sakesun Roykiattisak, Chuck Jacobs, haypo, eshaish, arman0, nivaldo, krosavcheg, Davy Mitchell, luntain, William Reade, tatwright, Christian Muirhead, sdahlbac, Eric Wyler, dubnerm, Paulfelix, chadaustin and jjlee. We've also closed these bugs that were reported internally: * misc string related bugs from c-python25 test * Trivial: Debug.Assert: locals() in the interactive mode * Implement warnings for -Qwarn and -Qwarnall * StackOverflowException when exec "a[0]==7" for Ironpython, but Cpython can work * Helper stubs shown in Python stack traces You can download IronPython 2.0 Beta 4 at: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=14353 The IronPython Team IMPORTANT NOTES ToyScript, a small scripting language built on top of the DLR, is merely a DLR sample and not some new scripting language Microsoft has created. Also, ToyScript is not intended to be distributed with IronPython on a permanent basis. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Wed Aug 6 02:21:04 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 6 Aug 2008 09:21:04 +0900 Subject: [IronPython] Performance issue when calling a function with **kw In-Reply-To: <7AD436E4270DD54A94238001769C2227012C9376C371@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <00bb01c8f554$09b78820$1d269860$@com> <5b0248170808030347v45016c94t35345fb7d4d12ead@mail.gmail.com> <7AD436E4270DD54A94238001769C2227012C9376C371@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <5b0248170808051721q1b4adf40mc63d986cd679cf94@mail.gmail.com> 2008/8/6 Dino Viehland : > On my machine it is about 40% faster in 2.0 than 1.1.1 but still about 2x slower than CPython I don't see this speedup on Mono. I should file a Mono perf bug. -- Seo Sanghyeon From sanxiyn at gmail.com Wed Aug 6 02:26:02 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 6 Aug 2008 09:26:02 +0900 Subject: [IronPython] Security of DLR host In-Reply-To: <62ddb6fb0808051325l7cca7399ucba5bc6b4c71d5a4@mail.gmail.com> References: <4F06AAB8EC03C349A5D6D0A797C4881C40B5B6A36E@NA-EXMSG-C112.redmond.corp.microsoft.com> <62ddb6fb0808030103q36fae5f2le9ce8b8cf4f756e5@mail.gmail.com> <4895C543.2020301@voidspace.org.uk> <62ddb6fb0808030839j28c099a8t1855c1f3ebbc1666@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A32845D4AEA9CB@NA-EXMSG-C116.redmond.corp.microsoft.com> <62ddb6fb0808051325l7cca7399ucba5bc6b4c71d5a4@mail.gmail.com> Message-ID: <5b0248170808051726j7b70aa7u65c1b5c7e06c3646@mail.gmail.com> 2008/8/6 Pavel ?avara : > 3) Could be IL generated by DLR somehow intercepted (for security reasons) ? This is definitely possible but probably outside of the scope of DLR. (Therefore you may be required to edit the source code yourself.) -- Seo Sanghyeon From sanxiyn at gmail.com Wed Aug 6 02:29:29 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 6 Aug 2008 09:29:29 +0900 Subject: [IronPython] Using a c library as a dll or assembly In-Reply-To: <698E8783CC407F4EB0DC9E994B6D45409070CB@nut.avalanchestudios.se> References: <698E8783CC407F4EB0DC9E994B6D4540906D64@nut.avalanchestudios.se> <698E8783CC407F4EB0DC9E994B6D4540906DC5@nut.avalanchestudios.se> <698E8783CC407F4EB0DC9E994B6D45409070CB@nut.avalanchestudios.se> Message-ID: <5b0248170808051729x296d0048v7a5562c4bb3f52bd@mail.gmail.com> 2008/8/5 Anders Elfgren : > Another (unrelated) question: What's the best way to debug IronPython > programs? "print-debugging" is not very effective. (maybe this deserves a > mail thread of its own) I believe you can debug IronPython programs with standard CLR debuggers, since IronPython generates all necessary debug symbols. For example, you should be able to use Visual Studio to debug IronPython programs. -- Seo Sanghyeon From jdhardy at gmail.com Wed Aug 6 04:52:36 2008 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 5 Aug 2008 20:52:36 -0600 Subject: [IronPython] NWSGI 0.4 released Message-ID: To coincide with the release of IronPython 2.0b4, NWSGI (http://codeplex.com/NWSGI) has been updated to version 0.4. This version also brings improvements to configuration and performance. IronPython itself has improved dramatically (kudos to the team for a fantastic job) and is now capable of running parts of Django, although some workarounds are still required. I can make it through the tutorial, and once I get some testing with 2.0b4 done I'll post patches as well. I'm going to start testing against some other applications as well, and post the results on my blog - jdhardy.blogspot.com - as well as the compatibilty pages on ironpython.info. -Jeff From redmoon17 at gmail.com Wed Aug 6 04:56:56 2008 From: redmoon17 at gmail.com (Kevin Chu) Date: Wed, 6 Aug 2008 10:56:56 +0800 Subject: [IronPython] Announcing IronPython 2.0 Beta4 In-Reply-To: References: Message-ID: <41d7f4a90808051956g28247c1eo312d9f329503a12@mail.gmail.com> include sqlite3 Python Standard Library*,* but* *can't support sqlite3* * On Wed, Aug 6, 2008 at 7:55 AM, Srivatsn Narayanan wrote: > Hello IronPython Community, > > > > I'm pleased to announce IronPython 2.0 *Beta4*. We have fixed around 50 > bugs(~45 of them reported on Codeplex and ~5 reported internally). Apart > from these bug fixes, the following are the highlights of this release: > > ? This release ships with a MSI installer that installs IronPython > along with the *Python Standard Library*. It is now dual-licensed with > IronPython shipping under MS-PL and the python standard library shipping > under the Python Software Foundation license. This means that existing > python libraries are readily available after installation and makes for a > better out-of-the-box experience of using existing CPython libraries. A zip > file containing the binaries is still available as before. > > ? Static compilation of python files is now supported again and > the pyc.py sample has been updated to use the newer version. > > ? IDispatch-based cominterop is now the default mode as opposed to > generating interop assemblies for interacting with COM components. This is a > change that might break some existing scripts. One can switch back to the > old behavior by setting the environment variable > COREDLR_PreferComInteropAssembly. Read this blogfor more details on this feature. > > ? Apart from the Silverlight binaries and Chiron, the templates > and tools to create a barebones app are included as well. This is in the > Silverlight\Script folder. > > ? Performance degrades that were reported in Beta 3 have been > fixed. > > > > The following Codeplex items have been closed since IronPython 2.0 Beta3: > > ? nt.popen(...) breaks where ... consists of cmd.exe commands > > ? globals().fromkeys(...) broken > > ? globals().Values enumerator broken > > ? Trivial: nt.tempnam("", None) broken > > ? Trivial: Remove exceptions.OverflowWarning > > ? New-style class dicts (dictproxy) cannot be used for C# methods > with IDictionary parameters > > ? Negative: ipyw.exe run w/o args crashes > > ? 'dictproxy' object has no attribute 'copy' > > ? class.__dict__ (dictproxy) doesn't support .get > > ? repr() of a UserList containing another userList is wrong > > ? NaN == NaN > > ? DBNull should implement __nonzero__ that always returns false. > > ? IP implementation of _sha512 has extra module attributes > > ? Dir on textbox raises exception > > ? re.compile(...).match(...) does not permit certain integer > pos/endpos keyword parameter values > > ? re.compile(...).match(...).groupdict() broken WRT to unnamed > groups > > ? re.match(..., ...).regs is nearly always incorrect > > ? datetime.datetime.fromtimestamp() is not POSIX timestamp > > ? Trivial: Charset name > > ? datetime.datetime.utcfromtimestamp() > > ? datetime.datetime.isoformat() has no parameter > > ? nt.fstat(...) broken > > ? Python25: __hash__ returning longs broken on old style classes > WRT CPython 2.5 > > ? Trivial: IronPython converts -0x80000000 to a long (should be > int) > > ? -X:TabCompletion broken in IP2.0A1 WRT simple variable expansion > > ? import socket > > ? TypeError: staticmethod is not callable when overriding __new__ > in old+new derived type > > ? using the PropertyGrid class - SelectedObject issue > > ? new.classobj fails with "TypeError: __bases__ items must be > classes (got type)" > > ? dict(...) broken on new style class dictionaries (dictproxy) > > ? IronPython should not implement _weakref.proxy.__eq__ > > ? nt.stat(someDirectory) is broken > > ? Trivial: Implement 'file(...).mode' > > ? Trivial: os.chmod followed by os.unlink fails > > ? os.umask does not exist > > ? Regular Expression incompatibility > > ? co_filename in code objects is None > > ? Trivial: help(clr.AddReference) not helpful > > ? tb_line member of Traceback objects is incorrect > > ? Valid regex under CPython will fail with IronPython > > ? time.timezone has different semantic than in cpython > > ? IronPython 2.0B2 cannot iterate over an IEnumerable returned > from a C# method using yield > > ? Implement os.system (nt.system) > > ? cStringIO 1-arg .read() and .readlines() broken > > ? Trivial: id should return int or long, not Int64 > > > > We'd like to thank everyone in the community who reported these bugs: > jdhardy, Wilberforce, Eloff, Sakesun Roykiattisak, Chuck Jacobs, haypo, > eshaish, arman0, nivaldo, krosavcheg, Davy Mitchell, luntain, William Reade, > tatwright, Christian Muirhead, sdahlbac, Eric Wyler, dubnerm, Paulfelix, > chadaustin and jjlee. > > > > We've also closed these bugs that were reported internally: > > ? misc string related bugs from c-python25 test > > ? Trivial: Debug.Assert: locals() in the interactive mode > > ? Implement warnings for -Qwarn and -Qwarnall > > ? StackOverflowException when exec "a[0]==7" for Ironpython, but > Cpython can work > > ? Helper stubs shown in Python stack traces > > > > You can download IronPython 2.0 Beta 4 at: > http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=14353 > > > > The IronPython Team > > > > IMPORTANT NOTES > > ToyScript, a small scripting language built on top of the DLR, is merely a > DLR sample and not some new scripting language Microsoft has created. Also, > ToyScript is not intended to be distributed with IronPython on a permanent > basis. > > > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Wed Aug 6 05:00:12 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 5 Aug 2008 20:00:12 -0700 Subject: [IronPython] NWSGI 0.4 released In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C2227012C9376C477@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Just out of curiosity what version of Django? -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Tuesday, August 05, 2008 7:53 PM To: Discussion of IronPython Subject: [IronPython] NWSGI 0.4 released To coincide with the release of IronPython 2.0b4, NWSGI (http://codeplex.com/NWSGI) has been updated to version 0.4. This version also brings improvements to configuration and performance. IronPython itself has improved dramatically (kudos to the team for a fantastic job) and is now capable of running parts of Django, although some workarounds are still required. I can make it through the tutorial, and once I get some testing with 2.0b4 done I'll post patches as well. I'm going to start testing against some other applications as well, and post the results on my blog - jdhardy.blogspot.com - as well as the compatibilty pages on ironpython.info. -Jeff _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Wed Aug 6 05:06:19 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 5 Aug 2008 20:06:19 -0700 Subject: [IronPython] NWSGI 0.4 released In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C2227012C9376C478@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Oh, and regarding your blog which insists I sign in to post :) You can set MultipleActiveResultSets=True in the connection string to get around the cursor problem. That's what I did w/ my provider when I was working on Django compat over at http://blogs.msdn.com/dinoviehland/archive/2008/03/17/ironpython-ms-sql-and-pep-249.aspx I'm not sure if there's some horrible performance implications from that but it at least is a short term work around. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Tuesday, August 05, 2008 7:53 PM To: Discussion of IronPython Subject: [IronPython] NWSGI 0.4 released To coincide with the release of IronPython 2.0b4, NWSGI (http://codeplex.com/NWSGI) has been updated to version 0.4. This version also brings improvements to configuration and performance. IronPython itself has improved dramatically (kudos to the team for a fantastic job) and is now capable of running parts of Django, although some workarounds are still required. I can make it through the tutorial, and once I get some testing with 2.0b4 done I'll post patches as well. I'm going to start testing against some other applications as well, and post the results on my blog - jdhardy.blogspot.com - as well as the compatibilty pages on ironpython.info. -Jeff _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From curt at hagenlocher.org Wed Aug 6 05:16:51 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 5 Aug 2008 20:16:51 -0700 Subject: [IronPython] Announcing IronPython 2.0 Beta4 In-Reply-To: <41d7f4a90808051956g28247c1eo312d9f329503a12@mail.gmail.com> References: <41d7f4a90808051956g28247c1eo312d9f329503a12@mail.gmail.com> Message-ID: On Tue, Aug 5, 2008 at 7:56 PM, Kevin Chu wrote: > > include sqlite3 Python Standard Library, but can't support sqlite3 We haven't removed the modules that aren't expected to be supported in the final version of IronPython 2.0. -- Curt Hagenlocher curt at hagenlocher.org From nytrokiss at gmail.com Wed Aug 6 05:26:11 2008 From: nytrokiss at gmail.com (James Matthews) Date: Tue, 5 Aug 2008 20:26:11 -0700 Subject: [IronPython] NWSGI 0.4 released In-Reply-To: <7AD436E4270DD54A94238001769C2227012C9376C478@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C2227012C9376C478@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <8a6b8e350808052026x74946999x2df21ed57970b771@mail.gmail.com> Try to hit django 1.0 it looks really nice! On Tue, Aug 5, 2008 at 8:06 PM, Dino Viehland wrote: > Oh, and regarding your blog which insists I sign in to post :) You can set > MultipleActiveResultSets=True in the connection string to get around the > cursor problem. That's what I did w/ my provider when I was working on > Django compat over at > http://blogs.msdn.com/dinoviehland/archive/2008/03/17/ironpython-ms-sql-and-pep-249.aspx > > I'm not sure if there's some horrible performance implications from that > but it at least is a short term work around. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy > Sent: Tuesday, August 05, 2008 7:53 PM > To: Discussion of IronPython > Subject: [IronPython] NWSGI 0.4 released > > To coincide with the release of IronPython 2.0b4, NWSGI > (http://codeplex.com/NWSGI) has been updated to version 0.4. This > version also brings improvements to configuration and performance. > > IronPython itself has improved dramatically (kudos to the team for a > fantastic job) and is now capable of running parts of Django, although > some workarounds are still required. I can make it through the > tutorial, and once I get some testing with 2.0b4 done I'll post > patches as well. > > I'm going to start testing against some other applications as well, > and post the results on my blog - jdhardy.blogspot.com - as well as > the compatibilty pages on ironpython.info. > > -Jeff > _______________________________________________ > 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.jewelerslounge.com http://www.goldwatches.com/mens/cufflinks.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Wed Aug 6 05:51:30 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 5 Aug 2008 20:51:30 -0700 Subject: [IronPython] Roadmap and updates In-Reply-To: <53533.195.101.247.164.1217921049.squirrel@mail1.webfaction.com> References: <20080805020356.CAA2048002@diego.dreamhost.com> <50952.195.101.247.164.1217919879.squirrel@mail1.webfaction.com> <53533.195.101.247.164.1217921049.squirrel@mail1.webfaction.com> Message-ID: <7AD436E4270DD54A94238001769C2227012C9376C482@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Yeah, regarding the bugs... We do have a current backlog (~50) of untriaged bugs. We're continuing to go through them and hopefully we'll make good progress at our team meeting on Friday. Our plan for 2.0 is to fix all Medium & High Priority bugs on CodePlex so that's the key thing to watch as we flip bugs from Proposed -> Active. In particular the bug you referenced in your earlier post is likely to be rated high/medium - it's a core Python language compat issue and we usually prioritize those. Also questions are great - I have a list of things to blog about but responding to questions is always much easier :) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch Sent: Tuesday, August 05, 2008 12:24 AM To: Discussion of IronPython Subject: Re: [IronPython] Roadmap and updates > I do not want to sound like I downplay the IP team work, not at all, but > the lack of visibility is not playing in their favor in my opinion. > Writing code is one thing, giving recurrent feedback is sometimes worth > more ;) > I wanted to reiterate that I don't downplay the IP team's work. They've been very responsive and friendly to the community. However, visibility is sometimes lacking (mind you like many other large OSS projects ;)). I do realize as well that if I don't ask questions, I won't have answers... - Sylvain -- Sylvain Hellegouarch http://www.defuze.org _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From zh_jiang at hotmail.com Wed Aug 6 08:25:14 2008 From: zh_jiang at hotmail.com (Jiang Zhang) Date: Tue, 5 Aug 2008 23:25:14 -0700 Subject: [IronPython] 2.0 Beta 4 MSI setup error. Message-ID: The MSI refuses to install with message: "requires .NET framework 2.0 SP1". I am pretty sure that there are SP1 on the two machines I tried. They both have XP SP3. They all have the following .NET framework versions: 1.1 2.0 SP1 3.0 SP1 3.5 Thanks! -J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From v-blji at microsoft.com Wed Aug 6 08:34:35 2008 From: v-blji at microsoft.com (BlueTzar Ji (Wicresoft)) Date: Wed, 6 Aug 2008 14:34:35 +0800 Subject: [IronPython] Why IronPython4.0b must need .net 2.0sp1 if I have 3.5 Message-ID: <67B5036FC1DABC41A2D495288477B8C91D41F570E3@AA-EXMSG-C421.southpacific.corp.microsoft.com> Today, I try to play with IronPython 4.0b, but when I install it, it popups a window and says "IronPython 2.0 Beta4 requires .NET Framework 2.0. SP1". My machine is vista32 with Visual studio 08, so I have .NET Framework 3.5, I do not know why IronPython must work with .net 2.0&sp1 even I have .NET 3.5, and I wander why I can't install .NET 2.0 sp1 too. Thanks, BlueTzar -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh at defuze.org Wed Aug 6 08:47:34 2008 From: sh at defuze.org (Sylvain Hellegouarch) Date: Wed, 6 Aug 2008 08:47:34 +0200 (CEST) Subject: [IronPython] 2.0 Beta 4 MSI setup error. In-Reply-To: References: Message-ID: <35727.195.101.247.164.1218005254.squirrel@mail1.webfaction.com> I'm hijacking this thread as I also have errors with this release. The installation went fine but I get an unhandled exception when starting ipy.exe which terminates the process immediately. Hey for once I've sent a report to Microsoft about it though ;) Does this release require a specific version of .NET BTW? i'll try the zip package just in case. - Sylvain > > The MSI refuses to install with message: "requires .NET framework 2.0 > SP1". > I am pretty sure that there are SP1 on the two machines I tried. They > both have XP SP3. > > They all have the following .NET framework versions: > 1.1 > 2.0 SP1 > 3.0 SP1 > 3.5 > > Thanks! > -J._______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Sylvain Hellegouarch http://www.defuze.org From sh at defuze.org Wed Aug 6 08:49:46 2008 From: sh at defuze.org (Sylvain Hellegouarch) Date: Wed, 6 Aug 2008 08:49:46 +0200 (CEST) Subject: [IronPython] 2.0 Beta 4 MSI setup error. In-Reply-To: <35727.195.101.247.164.1218005254.squirrel@mail1.webfaction.com> References: <35727.195.101.247.164.1218005254.squirrel@mail1.webfaction.com> Message-ID: <35992.195.101.247.164.1218005386.squirrel@mail1.webfaction.com> > I'm hijacking this thread as I also have errors with this release. The > installation went fine but I get an unhandled exception when starting > ipy.exe which terminates the process immediately. > > Hey for once I've sent a report to Microsoft about it though ;) > > Does this release require a specific version of .NET BTW? i'll try the zip > package just in case. FYI, the zip package has the same behavior. - Sylvain -- Sylvain Hellegouarch http://www.defuze.org From sanxiyn at gmail.com Wed Aug 6 08:50:33 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 6 Aug 2008 15:50:33 +0900 Subject: [IronPython] NWSGI 0.4 released In-Reply-To: References: Message-ID: <5b0248170808052350w32b712edy2c0cf9a9f51fd171@mail.gmail.com> 2008/8/6 Jeff Hardy : > I'm going to start testing against some other applications as well, > and post the results on my blog - jdhardy.blogspot.com - as well as > the compatibilty pages on ironpython.info. Once Django is working, I think you should try Pinax as well. Pinax is a collection of applications built on Django. http://pinaxproject.com/ -- Seo Sanghyeon From sh at defuze.org Wed Aug 6 09:27:04 2008 From: sh at defuze.org (Sylvain Hellegouarch) Date: Wed, 6 Aug 2008 09:27:04 +0200 (CEST) Subject: [IronPython] 2.0 Beta 4 MSI setup error. In-Reply-To: <35992.195.101.247.164.1218005386.squirrel@mail1.webfaction.com> References: <35727.195.101.247.164.1218005254.squirrel@mail1.webfaction.com> <35992.195.101.247.164.1218005386.squirrel@mail1.webfaction.com> Message-ID: <41682.195.101.247.164.1218007624.squirrel@mail1.webfaction.com> > >> I'm hijacking this thread as I also have errors with this release. The >> installation went fine but I get an unhandled exception when starting >> ipy.exe which terminates the process immediately. >> >> Hey for once I've sent a report to Microsoft about it though ;) >> >> Does this release require a specific version of .NET BTW? i'll try the >> zip >> package just in case. > > FYI, the zip package has the same behavior. > After upgrading to .NET 3.5, the zip package decided to work fine without crashing. However I can't install the MSI any longer due to the same SP1 requirement others have had which prevents the installation from even starting. - Sylvain -- Sylvain Hellegouarch http://www.defuze.org From daftspaniel at gmail.com Wed Aug 6 09:44:27 2008 From: daftspaniel at gmail.com (Davy Mitchell) Date: Wed, 6 Aug 2008 08:44:27 +0100 Subject: [IronPython] 2.0 Beta 4 MSI setup error. In-Reply-To: References: Message-ID: <20253b0c0808060044v1e6f9683yfcbf79c1fbe0b605@mail.gmail.com> Ditto here. XP SP3 .Net 2.0 SP1 and 3.5 Cheers, Davy -- Davy Mitchell Blog - http://daftspaniel.blogspot.com Twitter - http://twitter.com/daftspaniel Skype - daftspaniel http://needgod.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Harry.Pierson at microsoft.com Wed Aug 6 10:16:59 2008 From: Harry.Pierson at microsoft.com (Harry Pierson) Date: Wed, 6 Aug 2008 01:16:59 -0700 Subject: [IronPython] Roadmap and updates In-Reply-To: <20080805020356.CAA2048002@diego.dreamhost.com> References: <20080805020356.CAA2048002@diego.dreamhost.com> Message-ID: This was my original response to Max: With regard to WinForms, my recent roadmap post was specifically talking to the integration of IPy into the WinForms designer, not into WinForms itself. You can write IPy 2.0 apps right now that use WinForms, you just have to do it by hand as of right now. The technology that we're "cutting adrift" (to use your term) is the CodeDom parser that's used by the WinForms designer in the VSX sample. The CodeDom model assumes static typing, which obviously doesn't mesh well with IronPython. We end up doing some tricks to embed type information into the generated python code so we can recreate the types when we round trip between code and designer views. My understanding (Dino?) is that we built that code only for WinForms integration support, we're the only MS language that has a CodeDom parser, and the code is not something we're interested in maintaining in the long term. However, while we have cut the CodeDom parser code, there are other ways of integrating into the WinForms designer. Neither VB nor C# use the CodeDom parser method today, even though obviously both are statically typed. I don't know what the other integration options are personally, but we will be investigating them so that when we ship our production quality VS integration for IPy, we will have WinForms designer support. I'm sorry if that wasn't clear in my blog post. As soon as we have a better idea on our WinForms integration strategy, we'll make sure to talk about it. As for MS cutting the WinForms model loose, I think we're encouraging folks to move to WPF, but given the sheer amount of WinForms code out there I have a hard time imagining them cutting support for it. Harry -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Max R. Yaffe Sent: Monday, August 04, 2008 7:06 PM To: users at lists.ironpython.com Subject: [IronPython] Roadmap and updates Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, however, seems to deprecate WinForms. I'm worried that IronPython and Microsoft are going to cut WinForms adrift just when I'm about to make a major investment in it. This might be the best approach for Microsoft because it seems the "community" is mainly interested in pictures, sounds, and the web. But I need something more classical. I'd appreciate your comments and direction. Max Yaffe Gamry Instruments, Inc. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Wed Aug 6 12:08:21 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 06 Aug 2008 11:08:21 +0100 Subject: [IronPython] Roadmap and updates In-Reply-To: References: <20080805020356.CAA2048002@diego.dreamhost.com> Message-ID: <48997815.8000400@voidspace.org.uk> Harry Pierson wrote: > [...] > As for MS cutting the WinForms model loose, I think we're encouraging folks to move to WPF, but given the sheer amount of WinForms code out there I have a hard time imagining them cutting support for it. > > And in fact IIRC .NET 2.0 SP1 included at least one new winforms controls. Michael > Harry > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Max R. Yaffe > Sent: Monday, August 04, 2008 7:06 PM > To: users at lists.ironpython.com > Subject: [IronPython] Roadmap and updates > > Note: I originally wrote this to Harry Pierson directly who asked that I > post it publically. I hope it doesn't come off as too inflamatory. > > Harry - Thanks for the roadmap and the latest update. It clarifies a > particular issue that I'm having with deciding whether to adopt Iron Python > and .Net for that matter. My particular application is a scientific > instrument control and data analysis package. It runs on Windows now using > various older MS technologies (dating back to Windows 2.3!). It will not > need to run from a web browser, mainly because of the requirements for > instrument control. The application is highly scripted using a dynamic > language of my own devising derived from Smalltalk and remarkably similar to > Python. > > I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my > technology. However, I wanted to see what Microsoft had to offer. WinForms > + Python seems to be the best fit for my technology because of the need to > manipulate data tables and my desire to avoid the web. Silverlight just > doesn't offer me any advantage and seems to be directed at pretty pictures > and sounds. It also doesn't seem to handle the kinds of user/data > interaction I need. XAML also doesn't seem to offer any advantage for my > code, or if it does, it certainly isn't clear what it might be other than a > YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, > however, seems to deprecate WinForms. I'm worried that IronPython and > Microsoft are going to cut WinForms adrift just when I'm about to make a > major investment in it. This might be the best approach for Microsoft > because it seems the "community" is mainly interested in pictures, sounds, > and the web. But I need something more classical. > > I'd appreciate your comments and direction. > > Max Yaffe > Gamry Instruments, Inc. > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From fuzzyman at voidspace.org.uk Wed Aug 6 12:10:28 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 06 Aug 2008 11:10:28 +0100 Subject: [IronPython] Announcing IronPython 2.0 Beta4 In-Reply-To: References: <41d7f4a90808051956g28247c1eo312d9f329503a12@mail.gmail.com> Message-ID: <48997894.7090308@voidspace.org.uk> Curt Hagenlocher wrote: > On Tue, Aug 5, 2008 at 7:56 PM, Kevin Chu wrote: > >> include sqlite3 Python Standard Library, but can't support sqlite3 >> > > We haven't removed the modules that aren't expected to be supported in > the final version of IronPython 2.0. > Including the standard library is a *great* step - congratulations and thanks. Removing modules that could never work *might* be helpful - much more important though is to start applying patches (to modules like inspect for example) so that they *can* work. :-) Michael Foord > -- > 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/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From fuzzyman at voidspace.org.uk Wed Aug 6 12:13:14 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 06 Aug 2008 11:13:14 +0100 Subject: [IronPython] IronPython.Runtime.Exceptions.ImportException: No module named System In-Reply-To: <7AD436E4270DD54A94238001769C2227012C9376C430@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <18841986.post@talk.nabble.com> <7AD436E4270DD54A94238001769C2227012C9376C430@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4899793A.80302@voidspace.org.uk> Dino Viehland wrote: > You need to add the DLLs you want to be available for importing. We used to add System/mscorlib for you but don't anymore. I suggest doing yourScriptRuntime.LoadAssembly(typeof(System.Diagnostics.Debug).Assembly); > > What is the reason for not adding System? It creates an incompatibility between scripts run with 'ipy.exe' and scripts executed in an embedded environment. It has also been a cause of several questions on this list... Personally I can't see how it is useful to not add this by default, but maybe there is a reason? Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Huzaifa > Sent: Tuesday, August 05, 2008 4:46 PM > To: users at lists.ironpython.com > Subject: [IronPython] IronPython.Runtime.Exceptions.ImportException: No module named System > > > I am trying this code , and it is giving me this exception > "IronPython.Runtime.Exceptions.ImportException: No module named System" > > input = _scriptEngine.CreateScriptSourceFromString ( > > @"import clr > from System import * > clr.AddReferenceToFile("ABC.dll') > ", System.Scripting.SourceCodeKind.Statements); > > input.Execute (defaultScope); > > IronPython.Runtime.Exceptions.ImportException: No module named System > > I think it is not able to find the location of System.dll. If it would be Py > 1.1 i could do like this > _pyEngine.Sys.path.Add(path); > > but how to do it in 2.0 > -- > View this message in context: http://www.nabble.com/IronPython.Runtime.Exceptions.ImportException%3A-No-module-named-System-tp18841986p18841986.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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From fuzzyman at voidspace.org.uk Wed Aug 6 13:16:34 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 06 Aug 2008 12:16:34 +0100 Subject: [IronPython] 2.0 Beta 4 MSI setup error. In-Reply-To: References: Message-ID: <48998812.6050703@voidspace.org.uk> Jiang Zhang wrote: > > The MSI refuses to install with message: "requires .NET framework 2.0 > SP1". > I am pretty sure that there are SP1 on the two machines I tried. > They both have XP SP3. > > They all have the following .NET framework versions: > 1.1 > 2.0 SP1 > 3.0 SP1 > 3.5 > Yup - further confirmation. I run the msi and it tells me it requires .NET 2 SP1. I run the .NET 2 SP1 installer and it tells me that it is already installed (I do have .NET 3.5 installed). Again on XP SP3. Michael > Thanks! > -J. > ------------------------------------------------------------------------ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From Harry.Pierson at microsoft.com Wed Aug 6 16:50:02 2008 From: Harry.Pierson at microsoft.com (Harry Pierson) Date: Wed, 6 Aug 2008 07:50:02 -0700 Subject: [IronPython] Announcing IronPython 2.0 Beta4 In-Reply-To: <48997894.7090308@voidspace.org.uk> References: <41d7f4a90808051956g28247c1eo312d9f329503a12@mail.gmail.com> <48997894.7090308@voidspace.org.uk> Message-ID: >From my soon to be posted blog on B4: I mentioned a couple of weeks ago that I've been spending a lot of time with lawyers, and this is the first step towards making the IronPython project as open as possible. Note the use of the word "first" in that previous statement. In other words, I've got more lawyers to talk to. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Wednesday, August 06, 2008 3:10 AM To: Discussion of IronPython Subject: Re: [IronPython] Announcing IronPython 2.0 Beta4 Curt Hagenlocher wrote: > On Tue, Aug 5, 2008 at 7:56 PM, Kevin Chu wrote: > >> include sqlite3 Python Standard Library, but can't support sqlite3 >> > > We haven't removed the modules that aren't expected to be supported in > the final version of IronPython 2.0. > Including the standard library is a *great* step - congratulations and thanks. Removing modules that could never work *might* be helpful - much more important though is to start applying patches (to modules like inspect for example) so that they *can* work. :-) Michael Foord > -- > 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/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From curt at hagenlocher.org Wed Aug 6 17:05:29 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 6 Aug 2008 08:05:29 -0700 Subject: [IronPython] IronPython.Runtime.Exceptions.ImportException: No module named System In-Reply-To: <4899793A.80302@voidspace.org.uk> References: <18841986.post@talk.nabble.com> <7AD436E4270DD54A94238001769C2227012C9376C430@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4899793A.80302@voidspace.org.uk> Message-ID: On Wed, Aug 6, 2008 at 3:13 AM, Michael Foord wrote: > > What is the reason for not adding System? It creates an incompatibility > between scripts run with 'ipy.exe' and scripts executed in an embedded > environment. It has also been a cause of several questions on this list... I sympathize, having both asked the question (back in February) and answered it at least twice. But the DLR is a shared module being used by potentially many languages, and it would be bad design to make this decision for all of them -- if for no other reason than the added startup time. -- Curt Hagenlocher curt at hagenlocher.org From David.Lawler at franke.com Wed Aug 6 17:14:41 2008 From: David.Lawler at franke.com (David.Lawler at franke.com) Date: Wed, 6 Aug 2008 11:14:41 -0400 Subject: [IronPython] pyc.py for IP 2b4 In-Reply-To: Message-ID: Does anyone know where this updated sample referred to in the announcement can be found? Thanks, David From mbarnett at uniserve.com Wed Aug 6 18:16:23 2008 From: mbarnett at uniserve.com (mbarnett at uniserve.com) Date: Wed, 6 Aug 2008 09:16:23 -0700 Subject: [IronPython] IP2B4 and MDbg support? In-Reply-To: References: <41d7f4a90808051956g28247c1eo312d9f329503a12@mail.gmail.com> <48997894.7090308@voidspace.org.uk> Message-ID: <1218039383.4899ce5705520@members.uniserve.com> Congratulations on the release of IP2B4! I have a quick question with respect to IP2 and MDbg - will MDbg be updated to work with the DLR? I know there are a few issues using a debugger with dynamic languages, but not insurmountable as MDbg is a great base to work from (thanks to Mike Stall!) My point is that for folks that are implementing tooling around the DLR (e.g. consoles, IDE's, and possibly new dynamic languages), having a debugger would seem to be desirable... http://softwareindustrialization.com/WebbasedDLRIDEWithMDbgDebugger.aspx Thanks, Mitch From srivatsn at microsoft.com Wed Aug 6 18:45:49 2008 From: srivatsn at microsoft.com (Srivatsn Narayanan) Date: Wed, 6 Aug 2008 09:45:49 -0700 Subject: [IronPython] 2.0 Beta 4 MSI setup error. In-Reply-To: <48998812.6050703@voidspace.org.uk> References: <48998812.6050703@voidspace.org.uk> Message-ID: It's now fixed and has been uploaded to codeplex. It was checking for the .net version to be greater than 2.0.50727.1434 whereas on XP SP3 it is actually 2.0.50727.1433. I'm sorry about the snafu. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Wednesday, August 06, 2008 4:17 AM To: Discussion of IronPython Subject: Re: [IronPython] 2.0 Beta 4 MSI setup error. Jiang Zhang wrote: > > The MSI refuses to install with message: "requires .NET framework 2.0 > SP1". > I am pretty sure that there are SP1 on the two machines I tried. > They both have XP SP3. > > They all have the following .NET framework versions: > 1.1 > 2.0 SP1 > 3.0 SP1 > 3.5 > Yup - further confirmation. I run the msi and it tells me it requires .NET 2 SP1. I run the .NET 2 SP1 installer and it tells me that it is already installed (I do have .NET 3.5 installed). Again on XP SP3. Michael > Thanks! > -J. > ------------------------------------------------------------------------ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Wed Aug 6 22:38:26 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 6 Aug 2008 13:38:26 -0700 Subject: [IronPython] Roadmap and updates In-Reply-To: <50952.195.101.247.164.1217919879.squirrel@mail1.webfaction.com> References: <20080805020356.CAA2048002@diego.dreamhost.com> <50952.195.101.247.164.1217919879.squirrel@mail1.webfaction.com> Message-ID: <7AD436E4270DD54A94238001769C2227012C9376C571@DF-GRTDANE-MSG.exchange.corp.microsoft.com> FYI one thing that might help on the debugging side is the -X:ExceptionDetail command line option to ipy.exe. This is particular useful if you're getting something like a NullReferenceException or IndexError's because usually it leads right to the culprit. In this case that displays this stack trace: at IronPython.Runtime.Operations.PythonTypeOps.CallWorker(CodeContext context, PythonType dt, IAttributesCollection kwArgs, Object[] args) in C:\Product\3\Merlin\Main\Languages\IronPython\IronPytho n\Runtime\Operations\PythonTypeOps.cs:line 97 at IronPython.Runtime.Types.PythonType.Call(CodeContext context, IAttributesCollection kwArgs, Object[] args) in C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Runtime\Types\PythonType.cs :line 272 at _stub_$37##27(Closure , CallSite , CodeContext , Object , String , Object , Object ) at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] ) at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line 272 at System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up dateDelegates.Generated.cs:line 55 at _stub_$36##26(Closure , CallSite , CodeContext , Object , String , Object , Object ) at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] ) at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line 272 at System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up dateDelegates.Generated.cs:line 55 at $20$9.$20(Closure , Scope , LanguageContext ) in :line 7 at Microsoft.Scripting.ScriptCode.InvokeTarget(LambdaExpression code, Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line 88 at Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression code, Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\OptimizedScriptCode.cs:line 71 at Microsoft.Scripting.ScriptCode.Run(Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line 80 at IronPython.Hosting.PythonCommandLine.<>c__DisplayClass1.b__0() in C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Hosting\PythonCommandLine.cs:line 370 IndexError: Index was outside the bounds of the array. As you can see the top of the stack is the CallWorker and the problem here is that we're just not putting the arg name in the right index in the array. So something like that might be obvious enough to fix w/o a repro - or it might be pretty easy for us to come up w/ a repro ourselves when we see the call stack. If we had instead been throwing the exception from one of the _stub_ methods then we'd definitely need a repro as that's generated code and it's not immediately obvious what is going on. Anyway, this bug appears to be trivial fixed so it'll be in the next release. Thanks for the bug report and easy repro! -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch Sent: Tuesday, August 05, 2008 12:05 AM To: maxyaffe at comcast.net; Discussion of IronPython Subject: Re: [IronPython] Roadmap and updates Hi, > Note: I originally wrote this to Harry Pierson directly who asked that I > post it publically. I hope it doesn't come off as too inflamatory. > > Harry - Thanks for the roadmap and the latest update. It clarifies a > particular issue that I'm having with deciding whether to adopt Iron > Python > and .Net for that matter. My particular application is a scientific > instrument control and data analysis package. It runs on Windows now > using > various older MS technologies (dating back to Windows 2.3!). It will not > need to run from a web browser, mainly because of the requirements for > instrument control. The application is highly scripted using a dynamic > language of my own devising derived from Smalltalk and remarkably similar > to > Python. > > I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my > technology. However, I wanted to see what Microsoft had to offer. > WinForms > + Python seems to be the best fit for my technology because of the need to > manipulate data tables and my desire to avoid the web. Silverlight just > doesn't offer me any advantage and seems to be directed at pretty pictures > and sounds. It also doesn't seem to handle the kinds of user/data > interaction I need. XAML also doesn't seem to offer any advantage for my > code, or if it does, it certainly isn't clear what it might be other than > a > YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, > however, seems to deprecate WinForms. I'm worried that IronPython and > Microsoft are going to cut WinForms adrift just when I'm about to make a > major investment in it. This might be the best approach for Microsoft > because it seems the "community" is mainly interested in pictures, sounds, > and the web. But I need something more classical. > > I'd appreciate your comments and direction. > I will not comment on the state of Silverlight or XAML as I don't use them but I've been using the PyQt4+Python2.5 combination for some time and it's been working great. My main concern with IronPython at this stage is its inability to offer a clear view of its capacity to support pure Python libraries. I keep running in shortcomings or bugs [1] that make me nervous about investing time in IP when using existing pure Python libraries. I do understand IP is still in beta and bugs are expected at this stage but not having an up-to-date grid of what is officially implemented, supported, worked on is rather frustrating. In other words, if you start from scratch then IP+.NET is a solid choice but if you already have a large bunch of Python code I would personally be very careful as you might end up having to spend quite a lot of time in debugging the reason why your code isn't working as expected, opening tickets on CodePlex and never hearing about their progress again until they are potentially fixed. I do not want to sound like I downplay the IP team work, not at all, but the lack of visibility is not playing in their favor in my opinion. Writing code is one thing, giving recurrent feedback is sometimes worth more ;) I believe IP is worth the interest but keep in mind the product is still rather a long way. - Sylvain [1] http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17561 It might not sound like it but that bug was quite hard to track down because of the rather poor traceback information provided by IP as well as the fact that the IndexError, though a consequence of the bug, wasn't immediate to correlate back to the bug itself. -- Sylvain Hellegouarch http://www.defuze.org _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sh at defuze.org Wed Aug 6 22:53:02 2008 From: sh at defuze.org (Sylvain Hellegouarch) Date: Wed, 6 Aug 2008 22:53:02 +0200 (CEST) Subject: [IronPython] Roadmap and updates In-Reply-To: <7AD436E4270DD54A94238001769C2227012C9376C571@DF-GRTDANE-MSG.exchange. corp.microsoft.com> References: <20080805020356.CAA2048002@diego.dreamhost.com> <50952.195.101.247.164.1217919879.squirrel@mail1.webfaction.com> <7AD436E4270DD54A94238001769C2227012C9376C571@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <3765.82.229.61.197.1218055982.squirrel@mail1.webfaction.com> Thanks Dino. I'll keep the flag in mind for the future. One question for my curioristy, why not reporting the whole exception by default? If I were to run production code and that an error occurred I would like to know the context but might not afford to run the code again. At least it would make sense while IP is in beta to have it enabled IMO. Thanks also for getting this bug fixed, that'll put one step closer to get Kamaelia working which would be fantastic as I've written a bunch of code like XMPP client library using it. That'd be fun to have it working on IP. Thanks again, - Sylvain > FYI one thing that might help on the debugging side is the > -X:ExceptionDetail command line option to ipy.exe. This is particular > useful if you're getting something like a NullReferenceException or > IndexError's because usually it leads right to the culprit. In this case > that displays this stack trace: > > at IronPython.Runtime.Operations.PythonTypeOps.CallWorker(CodeContext > context, PythonType dt, IAttributesCollection kwArgs, Object[] args) in > C:\Product\3\Merlin\Main\Languages\IronPython\IronPytho > n\Runtime\Operations\PythonTypeOps.cs:line 97 > at IronPython.Runtime.Types.PythonType.Call(CodeContext context, > IAttributesCollection kwArgs, Object[] args) in > C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Runtime\Types\PythonType.cs > :line 272 > at _stub_$37##27(Closure , CallSite , CodeContext , Object , String , > Object , Object ) > at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] ) > at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) > in > c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line > 272 > at > System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite > site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in > c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up > dateDelegates.Generated.cs:line 55 > at _stub_$36##26(Closure , CallSite , CodeContext , Object , String , > Object , Object ) > at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] ) > at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) > in > c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line > 272 > at > System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite > site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in > c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up > dateDelegates.Generated.cs:line 55 > at $20$9.$20(Closure , Scope , LanguageContext ) in > :line 7 > at Microsoft.Scripting.ScriptCode.InvokeTarget(LambdaExpression code, > Scope scope) in > C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line > 88 > at > Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression > code, Scope scope) in > C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\OptimizedScriptCode.cs:line > 71 > at Microsoft.Scripting.ScriptCode.Run(Scope scope) in > C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line > 80 > at > IronPython.Hosting.PythonCommandLine.<>c__DisplayClass1.b__0() > in > C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Hosting\PythonCommandLine.cs:line > 370 > IndexError: Index was outside the bounds of the array. > > As you can see the top of the stack is the CallWorker and the problem here > is that we're just not putting the arg name in the right index in the > array. So something like that might be obvious enough to fix w/o a repro > - or it might be pretty easy for us to come up w/ a repro ourselves when > we see the call stack. If we had instead been throwing the exception from > one of the _stub_ methods then we'd definitely need a repro as that's > generated code and it's not immediately obvious what is going on. > > Anyway, this bug appears to be trivial fixed so it'll be in the next > release. Thanks for the bug report and easy repro! > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain > Hellegouarch > Sent: Tuesday, August 05, 2008 12:05 AM > To: maxyaffe at comcast.net; Discussion of IronPython > Subject: Re: [IronPython] Roadmap and updates > > Hi, > > >> Note: I originally wrote this to Harry Pierson directly who asked that >> I >> post it publically. I hope it doesn't come off as too inflamatory. >> >> Harry - Thanks for the roadmap and the latest update. It clarifies a >> particular issue that I'm having with deciding whether to adopt Iron >> Python >> and .Net for that matter. My particular application is a scientific >> instrument control and data analysis package. It runs on Windows now >> using >> various older MS technologies (dating back to Windows 2.3!). It will >> not >> need to run from a web browser, mainly because of the requirements for >> instrument control. The application is highly scripted using a dynamic >> language of my own devising derived from Smalltalk and remarkably >> similar >> to >> Python. >> >> I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating >> my >> technology. However, I wanted to see what Microsoft had to offer. >> WinForms >> + Python seems to be the best fit for my technology because of the need >> to >> manipulate data tables and my desire to avoid the web. Silverlight just >> doesn't offer me any advantage and seems to be directed at pretty >> pictures >> and sounds. It also doesn't seem to handle the kinds of user/data >> interaction I need. XAML also doesn't seem to offer any advantage for >> my >> code, or if it does, it certainly isn't clear what it might be other >> than >> a >> YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, >> however, seems to deprecate WinForms. I'm worried that IronPython and >> Microsoft are going to cut WinForms adrift just when I'm about to make a >> major investment in it. This might be the best approach for Microsoft >> because it seems the "community" is mainly interested in pictures, >> sounds, >> and the web. But I need something more classical. >> >> I'd appreciate your comments and direction. >> > > I will not comment on the state of Silverlight or XAML as I don't use them > but I've been using the PyQt4+Python2.5 combination for some time and it's > been working great. My main concern with IronPython at this stage is its > inability to offer a clear view of its capacity to support pure Python > libraries. > > I keep running in shortcomings or bugs [1] that make me nervous about > investing time in IP when using existing pure Python libraries. I do > understand IP is still in beta and bugs are expected at this stage but not > having an up-to-date grid of what is officially implemented, supported, > worked on is rather frustrating. > > In other words, if you start from scratch then IP+.NET is a solid choice > but if you already have a large bunch of Python code I would personally be > very careful as you might end up having to spend quite a lot of time in > debugging the reason why your code isn't working as expected, opening > tickets on CodePlex and never hearing about their progress again until > they are potentially fixed. > > I do not want to sound like I downplay the IP team work, not at all, but > the lack of visibility is not playing in their favor in my opinion. > Writing code is one thing, giving recurrent feedback is sometimes worth > more ;) > > I believe IP is worth the interest but keep in mind the product is still > rather a long way. > > - Sylvain > > [1] http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17561 > > It might not sound like it but that bug was quite hard to track down > because of the rather poor traceback information provided by IP as well as > the fact that the IndexError, though a consequence of the bug, wasn't > immediate to correlate back to the bug itself. > > > > > -- > Sylvain Hellegouarch > http://www.defuze.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 > -- Sylvain Hellegouarch http://www.defuze.org From dinov at exchange.microsoft.com Wed Aug 6 22:59:26 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 6 Aug 2008 13:59:26 -0700 Subject: [IronPython] Roadmap and updates In-Reply-To: <3765.82.229.61.197.1218055982.squirrel@mail1.webfaction.com> References: <20080805020356.CAA2048002@diego.dreamhost.com> <50952.195.101.247.164.1217919879.squirrel@mail1.webfaction.com> <7AD436E4270DD54A94238001769C2227012C9376C571@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <3765.82.229.61.197.1218055982.squirrel@mail1.webfaction.com> Message-ID: <7AD436E4270DD54A94238001769C2227012C9376C57C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> There's really two reasons. The first is that we try to match CPython for our output including our error messages. The second is that the exception is usually triggered from user code and that can be understood by looking at the stack trace w/o a bunch of internal Python implementation details being show. Enabling it for betas might make sense but we intend to only have 1 more beta release so I'm not sure how much value that would add right now and it might cause confusion as we switch between the two modes. It'd also prevent people from reporting errors about the error reporting :) But if there was a strong desire to see that we could consider it. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch Sent: Wednesday, August 06, 2008 1:53 PM To: Discussion of IronPython Subject: Re: [IronPython] Roadmap and updates Thanks Dino. I'll keep the flag in mind for the future. One question for my curioristy, why not reporting the whole exception by default? If I were to run production code and that an error occurred I would like to know the context but might not afford to run the code again. At least it would make sense while IP is in beta to have it enabled IMO. Thanks also for getting this bug fixed, that'll put one step closer to get Kamaelia working which would be fantastic as I've written a bunch of code like XMPP client library using it. That'd be fun to have it working on IP. Thanks again, - Sylvain > FYI one thing that might help on the debugging side is the > -X:ExceptionDetail command line option to ipy.exe. This is particular > useful if you're getting something like a NullReferenceException or > IndexError's because usually it leads right to the culprit. In this case > that displays this stack trace: > > at IronPython.Runtime.Operations.PythonTypeOps.CallWorker(CodeContext > context, PythonType dt, IAttributesCollection kwArgs, Object[] args) in > C:\Product\3\Merlin\Main\Languages\IronPython\IronPytho > n\Runtime\Operations\PythonTypeOps.cs:line 97 > at IronPython.Runtime.Types.PythonType.Call(CodeContext context, > IAttributesCollection kwArgs, Object[] args) in > C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Runtime\Types\PythonType.cs > :line 272 > at _stub_$37##27(Closure , CallSite , CodeContext , Object , String , > Object , Object ) > at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] ) > at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) > in > c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line > 272 > at > System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite > site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in > c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up > dateDelegates.Generated.cs:line 55 > at _stub_$36##26(Closure , CallSite , CodeContext , Object , String , > Object , Object ) > at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] ) > at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) > in > c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line > 272 > at > System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite > site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in > c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up > dateDelegates.Generated.cs:line 55 > at $20$9.$20(Closure , Scope , LanguageContext ) in > :line 7 > at Microsoft.Scripting.ScriptCode.InvokeTarget(LambdaExpression code, > Scope scope) in > C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line > 88 > at > Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression > code, Scope scope) in > C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\OptimizedScriptCode.cs:line > 71 > at Microsoft.Scripting.ScriptCode.Run(Scope scope) in > C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line > 80 > at > IronPython.Hosting.PythonCommandLine.<>c__DisplayClass1.b__0() > in > C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Hosting\PythonCommandLine.cs:line > 370 > IndexError: Index was outside the bounds of the array. > > As you can see the top of the stack is the CallWorker and the problem here > is that we're just not putting the arg name in the right index in the > array. So something like that might be obvious enough to fix w/o a repro > - or it might be pretty easy for us to come up w/ a repro ourselves when > we see the call stack. If we had instead been throwing the exception from > one of the _stub_ methods then we'd definitely need a repro as that's > generated code and it's not immediately obvious what is going on. > > Anyway, this bug appears to be trivial fixed so it'll be in the next > release. Thanks for the bug report and easy repro! > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain > Hellegouarch > Sent: Tuesday, August 05, 2008 12:05 AM > To: maxyaffe at comcast.net; Discussion of IronPython > Subject: Re: [IronPython] Roadmap and updates > > Hi, > > >> Note: I originally wrote this to Harry Pierson directly who asked that >> I >> post it publically. I hope it doesn't come off as too inflamatory. >> >> Harry - Thanks for the roadmap and the latest update. It clarifies a >> particular issue that I'm having with deciding whether to adopt Iron >> Python >> and .Net for that matter. My particular application is a scientific >> instrument control and data analysis package. It runs on Windows now >> using >> various older MS technologies (dating back to Windows 2.3!). It will >> not >> need to run from a web browser, mainly because of the requirements for >> instrument control. The application is highly scripted using a dynamic >> language of my own devising derived from Smalltalk and remarkably >> similar >> to >> Python. >> >> I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating >> my >> technology. However, I wanted to see what Microsoft had to offer. >> WinForms >> + Python seems to be the best fit for my technology because of the need >> to >> manipulate data tables and my desire to avoid the web. Silverlight just >> doesn't offer me any advantage and seems to be directed at pretty >> pictures >> and sounds. It also doesn't seem to handle the kinds of user/data >> interaction I need. XAML also doesn't seem to offer any advantage for >> my >> code, or if it does, it certainly isn't clear what it might be other >> than >> a >> YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, >> however, seems to deprecate WinForms. I'm worried that IronPython and >> Microsoft are going to cut WinForms adrift just when I'm about to make a >> major investment in it. This might be the best approach for Microsoft >> because it seems the "community" is mainly interested in pictures, >> sounds, >> and the web. But I need something more classical. >> >> I'd appreciate your comments and direction. >> > > I will not comment on the state of Silverlight or XAML as I don't use them > but I've been using the PyQt4+Python2.5 combination for some time and it's > been working great. My main concern with IronPython at this stage is its > inability to offer a clear view of its capacity to support pure Python > libraries. > > I keep running in shortcomings or bugs [1] that make me nervous about > investing time in IP when using existing pure Python libraries. I do > understand IP is still in beta and bugs are expected at this stage but not > having an up-to-date grid of what is officially implemented, supported, > worked on is rather frustrating. > > In other words, if you start from scratch then IP+.NET is a solid choice > but if you already have a large bunch of Python code I would personally be > very careful as you might end up having to spend quite a lot of time in > debugging the reason why your code isn't working as expected, opening > tickets on CodePlex and never hearing about their progress again until > they are potentially fixed. > > I do not want to sound like I downplay the IP team work, not at all, but > the lack of visibility is not playing in their favor in my opinion. > Writing code is one thing, giving recurrent feedback is sometimes worth > more ;) > > I believe IP is worth the interest but keep in mind the product is still > rather a long way. > > - Sylvain > > [1] http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17561 > > It might not sound like it but that bug was quite hard to track down > because of the rather poor traceback information provided by IP as well as > the fact that the IndexError, though a consequence of the bug, wasn't > immediate to correlate back to the bug itself. > > > > > -- > Sylvain Hellegouarch > http://www.defuze.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 > -- Sylvain Hellegouarch http://www.defuze.org _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jdhardy at gmail.com Thu Aug 7 01:02:08 2008 From: jdhardy at gmail.com (Jeff Hardy) Date: Wed, 6 Aug 2008 17:02:08 -0600 Subject: [IronPython] NWSGI 0.4 released In-Reply-To: <7AD436E4270DD54A94238001769C2227012C9376C477@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C2227012C9376C477@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: On Tue, Aug 5, 2008 at 9:00 PM, Dino Viehland wrote: > Just out of curiosity what version of Django? > The trunk. r8207 is the last one I tested. -Jeff From jdhardy at gmail.com Thu Aug 7 01:07:38 2008 From: jdhardy at gmail.com (Jeff Hardy) Date: Wed, 6 Aug 2008 17:07:38 -0600 Subject: [IronPython] NWSGI 0.4 released In-Reply-To: <7AD436E4270DD54A94238001769C2227012C9376C478@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C2227012C9376C478@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: On Tue, Aug 5, 2008 at 9:06 PM, Dino Viehland wrote: > Oh, and regarding your blog which insists I sign in to post :) Not anymore! > You can set MultipleActiveResultSets=True in the connection string to get around the cursor problem. That's > what I did w/ my provider when I was working on Django compat over at > http://blogs.msdn.com/dinoviehland/archive/2008/03/17/ironpython-ms-sql-and-pep-249.aspx I saw that and tried it out but MARS didn't seem to work (other than causing a different error message). -Jeff From jdhardy at gmail.com Thu Aug 7 01:46:33 2008 From: jdhardy at gmail.com (Jeff Hardy) Date: Wed, 6 Aug 2008 17:46:33 -0600 Subject: [IronPython] NWSGI 0.4 released In-Reply-To: References: <7AD436E4270DD54A94238001769C2227012C9376C478@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: Dino, If transactions aren't being used I can get it working -- incidently, your code never actually initializes a transaction, so that's why it worked :). Now to get it working with transactions... -Jeff On Wed, Aug 6, 2008 at 5:07 PM, Jeff Hardy wrote: > On Tue, Aug 5, 2008 at 9:06 PM, Dino Viehland > wrote: >> Oh, and regarding your blog which insists I sign in to post :) > Not anymore! > >> You can set MultipleActiveResultSets=True in the connection string to get around the cursor problem. That's >> what I did w/ my provider when I was working on Django compat over at >> http://blogs.msdn.com/dinoviehland/archive/2008/03/17/ironpython-ms-sql-and-pep-249.aspx > > I saw that and tried it out but MARS didn't seem to work (other than > causing a different error message). > > -Jeff > From fuzzyman at voidspace.org.uk Thu Aug 7 12:03:51 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 07 Aug 2008 11:03:51 +0100 Subject: [IronPython] Announcing IronPython 2.0 Beta4 In-Reply-To: References: <41d7f4a90808051956g28247c1eo312d9f329503a12@mail.gmail.com> <48997894.7090308@voidspace.org.uk> Message-ID: <489AC887.6050807@voidspace.org.uk> Harry Pierson wrote: > >From my soon to be posted blog on B4: > > I mentioned a couple of weeks ago that I've been spending a lot of time with lawyers, and this is the first step towards making the IronPython project as open as possible. Note the use of the word "first" in that previous statement. In other words, I've got more lawyers to talk to. > Congratulations on this step Harry, it's great! And good luck for the next steps... Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Wednesday, August 06, 2008 3:10 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Announcing IronPython 2.0 Beta4 > > Curt Hagenlocher wrote: > >> On Tue, Aug 5, 2008 at 7:56 PM, Kevin Chu wrote: >> >> >>> include sqlite3 Python Standard Library, but can't support sqlite3 >>> >>> >> We haven't removed the modules that aren't expected to be supported in >> the final version of IronPython 2.0. >> >> > Including the standard library is a *great* step - congratulations and > thanks. > > Removing modules that could never work *might* be helpful - much more > important though is to start applying patches (to modules like inspect > for example) so that they *can* work. :-) > > Michael Foord > > >> -- >> 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/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From curt at hagenlocher.org Thu Aug 7 13:54:27 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 7 Aug 2008 04:54:27 -0700 Subject: [IronPython] IP2B4 and MDbg support? In-Reply-To: <1218039383.4899ce5705520@members.uniserve.com> References: <41d7f4a90808051956g28247c1eo312d9f329503a12@mail.gmail.com> <48997894.7090308@voidspace.org.uk> <1218039383.4899ce5705520@members.uniserve.com> Message-ID: We're not going to do anything specific to support MDbg (or vice versa, as far as I know) -- but we shouldn't have to. IronPython emits the same kind of line number metadata that C# emits, so any managed debugger ought to be able to follow right along. On Wed, Aug 6, 2008 at 9:16 AM, wrote: > Congratulations on the release of IP2B4! > > I have a quick question with respect to IP2 and MDbg - will MDbg be updated > to > work with the DLR? I know there are a few issues using a debugger with > dynamic > languages, but not insurmountable as MDbg is a great base to work from > (thanks > to Mike Stall!) > > My point is that for folks that are implementing tooling around the DLR > (e.g. > consoles, IDE's, and possibly new dynamic languages), having a debugger > would > seem to be desirable... > > http://softwareindustrialization.com/WebbasedDLRIDEWithMDbgDebugger.aspx > > > Thanks, > > Mitch > _______________________________________________ > 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 mbarnett at uniserve.com Thu Aug 7 14:40:57 2008 From: mbarnett at uniserve.com (mbarnett at uniserve.com) Date: Thu, 7 Aug 2008 05:40:57 -0700 Subject: [IronPython] IP2B4 and MDbg support? In-Reply-To: References: <41d7f4a90808051956g28247c1eo312d9f329503a12@mail.gmail.com> <48997894.7090308@voidspace.org.uk> <1218039383.4899ce5705520@members.uniserve.com> Message-ID: <1218112857.489aed59737f1@members.uniserve.com> Thanks Curt, I should referenced the following link: http://forums.msdn.microsoft.com/en-US/netfxtoolsdev/thread/34b32f85-13cf-4613- 86a5-3d2464661530/ Mike Stall mentions that there may be a MDbg parser problem with dynamic languages and hints that there might be an updated release of MDbg that fixes this. I was just following up on this... Thanks, Mitch Quoting Curt Hagenlocher : > We're not going to do anything specific to support MDbg (or vice versa, as > far as I know) -- but we shouldn't have to. IronPython emits the same kind > of line number metadata that C# emits, so any managed debugger ought to be > able to follow right along. > > On Wed, Aug 6, 2008 at 9:16 AM, wrote: > > > Congratulations on the release of IP2B4! > > > > I have a quick question with respect to IP2 and MDbg - will MDbg be > updated > > to > > work with the DLR? I know there are a few issues using a debugger with > > dynamic > > languages, but not insurmountable as MDbg is a great base to work from > > (thanks > > to Mike Stall!) > > > > My point is that for folks that are implementing tooling around the DLR > > (e.g. > > consoles, IDE's, and possibly new dynamic languages), having a debugger > > would > > seem to be desirable... > > > > http://softwareindustrialization.com/WebbasedDLRIDEWithMDbgDebugger.aspx > > > > > > Thanks, > > > > Mitch > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > From fuzzyman at voidspace.org.uk Thu Aug 7 14:52:23 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 07 Aug 2008 13:52:23 +0100 Subject: [IronPython] pyc.py sample Message-ID: <489AF007.4060801@voidspace.org.uk> Hello guys, The IronPython 2.0b4 release notes state: # Static compilation of python files is now supported again and the pyc.py sample has been updated to use the newer version. Where is the updated sample? I can't find it... As samples are updated for IronPython 2 it would make sense to move them into the installer (in their own directory on the start menu entry for IronPython). Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From curt at hagenlocher.org Thu Aug 7 14:58:04 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 7 Aug 2008 05:58:04 -0700 Subject: [IronPython] IP2B4 and MDbg support? In-Reply-To: <1218112857.489aed59737f1@members.uniserve.com> References: <41d7f4a90808051956g28247c1eo312d9f329503a12@mail.gmail.com> <48997894.7090308@voidspace.org.uk> <1218039383.4899ce5705520@members.uniserve.com> <1218112857.489aed59737f1@members.uniserve.com> Message-ID: Ah. Well, that's a question for Mike, then -- as far as I know, he's not on this list. On Thu, Aug 7, 2008 at 5:40 AM, wrote: > Thanks Curt, I should referenced the following link: > > > http://forums.msdn.microsoft.com/en-US/netfxtoolsdev/thread/34b32f85-13cf-4613- > 86a5-3d2464661530/ > > Mike Stall mentions that there may be a MDbg parser problem with dynamic > languages and hints that there might be an updated release of MDbg that > fixes > this. I was just following up on this... > > Thanks, > > Mitch > > > Quoting Curt Hagenlocher : > > > We're not going to do anything specific to support MDbg (or vice versa, > as > > far as I know) -- but we shouldn't have to. IronPython emits the same > kind > > of line number metadata that C# emits, so any managed debugger ought to > be > > able to follow right along. > > > > On Wed, Aug 6, 2008 at 9:16 AM, wrote: > > > > > Congratulations on the release of IP2B4! > > > > > > I have a quick question with respect to IP2 and MDbg - will MDbg be > > updated > > > to > > > work with the DLR? I know there are a few issues using a debugger with > > > dynamic > > > languages, but not insurmountable as MDbg is a great base to work from > > > (thanks > > > to Mike Stall!) > > > > > > My point is that for folks that are implementing tooling around the DLR > > > (e.g. > > > consoles, IDE's, and possibly new dynamic languages), having a > debugger > > > would > > > seem to be desirable... > > > > > > > http://softwareindustrialization.com/WebbasedDLRIDEWithMDbgDebugger.aspx > > > > > > > > > Thanks, > > > > > > Mitch > > > _______________________________________________ > > > 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 Aug 7 15:02:21 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 07 Aug 2008 14:02:21 +0100 Subject: [IronPython] Standard Library Inclusion - C Extension Modules Message-ID: <489AF25D.6060507@voidspace.org.uk> Hello all, Rather than simply stripping modules that rely on C extensions, can we view it as a bug that the C extension hasn't been ported... For example, could sqlite be ported with a compatibility shim and System.Data.SQLite? http://sqlite.phxsoftware.com/ Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From sanxiyn at gmail.com Thu Aug 7 15:06:28 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 7 Aug 2008 22:06:28 +0900 Subject: [IronPython] Standard Library Inclusion - C Extension Modules In-Reply-To: <489AF25D.6060507@voidspace.org.uk> References: <489AF25D.6060507@voidspace.org.uk> Message-ID: <5b0248170808070606i5e36ca31v6f88e58fa52bc6e@mail.gmail.com> 2008/8/7 Michael Foord : > For example, could sqlite be ported with a compatibility shim and > System.Data.SQLite? > http://sqlite.phxsoftware.com/ I must mention pyexpat here, which a lot of Python XML tools rely on, and which has been available as a compatibility shim around System.Xml since 2005 from FePy. -- Seo Sanghyeon From jdhardy at gmail.com Thu Aug 7 15:53:42 2008 From: jdhardy at gmail.com (Jeff Hardy) Date: Thu, 7 Aug 2008 07:53:42 -0600 Subject: [IronPython] Standard Library Inclusion - C Extension Modules In-Reply-To: <489AF25D.6060507@voidspace.org.uk> References: <489AF25D.6060507@voidspace.org.uk> Message-ID: > For example, could sqlite be ported with a compatibility shim and > System.Data.SQLite? > http://sqlite.phxsoftware.com/ I've actually written such a thing while working with Django, based on Seo's db work in FePy. It completely replaces the sqlite3 module instead of being a shim as it was much easier that way. It's not complete, but it works for Django - I had written a much more cemplete one, but I seem to have misplaced the code :(. -Jeff > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From curt at hagenlocher.org Thu Aug 7 16:26:40 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 7 Aug 2008 07:26:40 -0700 Subject: [IronPython] Standard Library Inclusion - C Extension Modules In-Reply-To: <5b0248170808070606i5e36ca31v6f88e58fa52bc6e@mail.gmail.com> References: <489AF25D.6060507@voidspace.org.uk> <5b0248170808070606i5e36ca31v6f88e58fa52bc6e@mail.gmail.com> Message-ID: On Thu, Aug 7, 2008 at 6:06 AM, Sanghyeon Seo wrote: > > 2008/8/7 Michael Foord : > > For example, could sqlite be ported with a compatibility shim and > > System.Data.SQLite? > > http://sqlite.phxsoftware.com/ > > I must mention pyexpat here, which a lot of Python XML tools rely on, > and which has been available as a compatibility shim around System.Xml > since 2005 from FePy. Feel free to report any missing binary extensions on CodePlex as a feature request. Seo's example is a simpler one. Harry is working on is getting legal approval for accepting community contributions into the modules. Once that's done (no ETA, I'm afraid), Seo would sign a contributor agreement and we could include his pyexpat compatibility shim. The sqlite example is more complicated for two reasons: 1) There wouldn't be any point in doing it unless we could distribute the referenced third-party project as well. This probably gives Harry the opportunity for a whole new round of quality time with lawyers. 2) The DLL in question is mixed-mode, so we need a story for how to properly load the functionality when running as a 64-bit process. -- Curt Hagenlocher curt at hagenlocher.org From fuzzyman at voidspace.org.uk Thu Aug 7 18:20:14 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 07 Aug 2008 17:20:14 +0100 Subject: [IronPython] PyCon UK Wiki Page: IronPython Tutorial Message-ID: <489B20BE.2000508@voidspace.org.uk> Hello all, PyCon UK starts with a tutorial day, when you have the opportunity to attend two half day tutorials for only ?30. We have some great tutorials lined up: http://pyconuk.org/timetable.html Christian Muirhead, Menno Smits and myself will be holding an IronPython tutorial in the morning session. I've put up a page on the PyCon UK wiki showing: * The topics we intend to cover * The pre-requisites (bring a laptop - you will be coding!) http://www.pyconuk.org/community/IronPythonTutorial There is also a space for you to request additional topics if there is anything you particularly want us to cover. If you are intending to come to the tutorial there is also space on the page for you to put your name. If you do come, please check the pre-requisites again as we are still deciding (for example) what databases we will be able to support. (It is likely that we will support MySQL, SQL Server and Postgres and we may also support sqlite.) Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From dfugate at microsoft.com Thu Aug 7 19:07:26 2008 From: dfugate at microsoft.com (Dave Fugate) Date: Thu, 7 Aug 2008 10:07:26 -0700 Subject: [IronPython] pyc.py sample In-Reply-To: <489AF007.4060801@voidspace.org.uk> References: <489AF007.4060801@voidspace.org.uk> Message-ID: Hi Michael, this seems like as good of a time as any to shed some light on our thoughts around the IronPython samples. First Pyc - Pyc.py was indeed updated for IronPython 2.x in our internal TFS repository last month, but as most people are already aware we don't reship the samples with every minor release of IronPython. The main reason we do this (at least from my perspective) is testing. Most of the samples are GUI-based and need to be tested by hand which is quite time consuming. By cutting the samples out of minor IronPython releases, we're able to release IronPython in quicker intervals and focus more test time on new features as opposed to samples verification. Regardless, we believe this sample depicts a vital aspect of IronPython functionality and will do a one-time 2.0B4 release of Pyc on www.codeplex.com/IronPython sometime today to get feedback. As for inclusion of the samples into the installer for IronPython 2.0, our current plan is actually to follow what we did with IronPython 1.0. That is, we'll release the samples shortly after 2.0 ships. The fundamental reason for doing this is that delaying samples work lets us put more effort into improving the quality of ipy.exe and the core IronPython documentation. Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, August 07, 2008 5:52 AM To: Discussion of IronPython Subject: [IronPython] pyc.py sample Hello guys, The IronPython 2.0b4 release notes state: # Static compilation of python files is now supported again and the pyc.py sample has been updated to use the newer version. Where is the updated sample? I can't find it... As samples are updated for IronPython 2 it would make sense to move them into the installer (in their own directory on the start menu entry for IronPython). Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Thu Aug 7 19:15:30 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 07 Aug 2008 18:15:30 +0100 Subject: [IronPython] pyc.py sample In-Reply-To: References: <489AF007.4060801@voidspace.org.uk> Message-ID: <489B2DB2.3050207@voidspace.org.uk> Dave Fugate wrote: > Hi Michael, this seems like as good of a time as any to shed some light on our thoughts around the IronPython samples. First Pyc - Pyc.py was indeed updated for IronPython 2.x in our internal TFS repository last month, but as most people are already aware we don't reship the samples with every minor release of IronPython. The main reason we do this (at least from my perspective) is testing. Most of the samples are GUI-based and need to be tested by hand which is quite time consuming. Testing GUI applications - particularly windows forms based ones - is a process amenable to automation. We have a few hundred automated 'functional tests' for Resolver One and I can highly recommend it. > By cutting the samples out of minor IronPython releases, we're able to release IronPython in quicker intervals and focus more test time on new features as opposed to samples verification. Regardless, we believe this sample depicts a vital aspect of IronPython functionality and will do a one-time 2.0B4 release of Pyc on www.codeplex.com/IronPython sometime today to get feedback. > > As for inclusion of the samples into the installer for IronPython 2.0, our current plan is actually to follow what we did with IronPython 1.0. That is, we'll release the samples shortly after 2.0 ships. The fundamental reason for doing this is that delaying samples work lets us put more effort into improving the quality of ipy.exe and the core IronPython documentation. > Ok. May I suggest not including sample updates in IronPython release notes if they have their own release cycle... :-) Michael > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, August 07, 2008 5:52 AM > To: Discussion of IronPython > Subject: [IronPython] pyc.py sample > > Hello guys, > > The IronPython 2.0b4 release notes state: > > # Static compilation of python files is now supported again and the pyc.py > sample has been updated to use the newer version. > > Where is the updated sample? I can't find it... > > As samples are updated for IronPython 2 it would make sense to move them > into the installer (in their own directory on the start menu entry for > IronPython). > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://wwww.theotherdelia.co.uk/ From srivatsn at microsoft.com Thu Aug 7 19:19:55 2008 From: srivatsn at microsoft.com (Srivatsn Narayanan) Date: Thu, 7 Aug 2008 10:19:55 -0700 Subject: [IronPython] pyc.py sample In-Reply-To: <489B2DB2.3050207@voidspace.org.uk> References: <489AF007.4060801@voidspace.org.uk> <489B2DB2.3050207@voidspace.org.uk> Message-ID: >Ok. May I suggest not including sample updates in IronPython release >notes if they have their own release cycle... :-) Yes my fault there. I didn't know about the separate release cycle for samples. I'm learning... :) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, August 07, 2008 10:16 AM To: Discussion of IronPython Subject: Re: [IronPython] pyc.py sample Dave Fugate wrote: > Hi Michael, this seems like as good of a time as any to shed some light on our thoughts around the IronPython samples. First Pyc - Pyc.py was indeed updated for IronPython 2.x in our internal TFS repository last month, but as most people are already aware we don't reship the samples with every minor release of IronPython. The main reason we do this (at least from my perspective) is testing. Most of the samples are GUI-based and need to be tested by hand which is quite time consuming. Testing GUI applications - particularly windows forms based ones - is a process amenable to automation. We have a few hundred automated 'functional tests' for Resolver One and I can highly recommend it. > By cutting the samples out of minor IronPython releases, we're able to release IronPython in quicker intervals and focus more test time on new features as opposed to samples verification. Regardless, we believe this sample depicts a vital aspect of IronPython functionality and will do a one-time 2.0B4 release of Pyc on www.codeplex.com/IronPython sometime today to get feedback. > > As for inclusion of the samples into the installer for IronPython 2.0, our current plan is actually to follow what we did with IronPython 1.0. That is, we'll release the samples shortly after 2.0 ships. The fundamental reason for doing this is that delaying samples work lets us put more effort into improving the quality of ipy.exe and the core IronPython documentation. > Ok. May I suggest not including sample updates in IronPython release notes if they have their own release cycle... :-) Michael > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, August 07, 2008 5:52 AM > To: Discussion of IronPython > Subject: [IronPython] pyc.py sample > > Hello guys, > > The IronPython 2.0b4 release notes state: > > # Static compilation of python files is now supported again and the pyc.py > sample has been updated to use the newer version. > > Where is the updated sample? I can't find it... > > As samples are updated for IronPython 2 it would make sense to move them > into the installer (in their own directory on the start menu entry for > IronPython). > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://wwww.theotherdelia.co.uk/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Thu Aug 7 20:14:29 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 07 Aug 2008 19:14:29 +0100 Subject: [IronPython] pyc.py sample In-Reply-To: References: <489AF007.4060801@voidspace.org.uk> <489B2DB2.3050207@voidspace.org.uk> Message-ID: <489B3B85.3010604@voidspace.org.uk> Srivatsn Narayanan wrote: >> Ok. May I suggest not including sample updates in IronPython release >> notes if they have their own release cycle... :-) >> > Yes my fault there. I didn't know about the separate release cycle for samples. I'm learning... :) > Are you generally responsible for doing new releases Sri? (Is this a promotion or punishment...) Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, August 07, 2008 10:16 AM > To: Discussion of IronPython > Subject: Re: [IronPython] pyc.py sample > > Dave Fugate wrote: > >> Hi Michael, this seems like as good of a time as any to shed some light on our thoughts around the IronPython samples. First Pyc - Pyc.py was indeed updated for IronPython 2.x in our internal TFS repository last month, but as most people are already aware we don't reship the samples with every minor release of IronPython. The main reason we do this (at least from my perspective) is testing. Most of the samples are GUI-based and need to be tested by hand which is quite time consuming. >> > > Testing GUI applications - particularly windows forms based ones - is a > process amenable to automation. We have a few hundred automated > 'functional tests' for Resolver One and I can highly recommend it. > > >> By cutting the samples out of minor IronPython releases, we're able to release IronPython in quicker intervals and focus more test time on new features as opposed to samples verification. Regardless, we believe this sample depicts a vital aspect of IronPython functionality and will do a one-time 2.0B4 release of Pyc on www.codeplex.com/IronPython sometime today to get feedback. >> >> As for inclusion of the samples into the installer for IronPython 2.0, our current plan is actually to follow what we did with IronPython 1.0. That is, we'll release the samples shortly after 2.0 ships. The fundamental reason for doing this is that delaying samples work lets us put more effort into improving the quality of ipy.exe and the core IronPython documentation. >> >> > Ok. May I suggest not including sample updates in IronPython release > notes if they have their own release cycle... :-) > > Michael > > > >> Dave >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Thursday, August 07, 2008 5:52 AM >> To: Discussion of IronPython >> Subject: [IronPython] pyc.py sample >> >> Hello guys, >> >> The IronPython 2.0b4 release notes state: >> >> # Static compilation of python files is now supported again and the pyc.py >> sample has been updated to use the newer version. >> >> Where is the updated sample? I can't find it... >> >> As samples are updated for IronPython 2 it would make sense to move them >> into the installer (in their own directory on the start menu entry for >> IronPython). >> >> Michael >> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/ >> http://www.trypython.org/ >> http://www.ironpython.info/ >> http://www.resolverhacks.net/ >> http://www.theotherdelia.co.uk/ >> >> _______________________________________________ >> 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/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://wwww.theotherdelia.co.uk/ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://wwww.theotherdelia.co.uk/ From dan.eloff at gmail.com Thu Aug 7 20:17:49 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Thu, 7 Aug 2008 13:17:49 -0500 Subject: [IronPython] loading an image in silverlight, in xaml, from the .xap In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A32845D4AEA80D@NA-EXMSG-C116.redmond.corp.microsoft.com> References: <4817b6fc0807112352n11f18dfexb6f7acb9fbfe69dd@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A32845D4A07EA2@NA-EXMSG-C116.redmond.corp.microsoft.com> <4817b6fc0808031412n4070028ct460da31eca172243@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A32845D4AEA80D@NA-EXMSG-C116.redmond.corp.microsoft.com> Message-ID: <4817b6fc0808071117j131d21eehd1f4faca00338f43@mail.gmail.com> On Mon, Aug 4, 2008 at 4:40 PM, Jimmy Schementi wrote: >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Dan Eloff >> Sent: Sunday, August 03, 2008 2:13 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] loading an image in silverlight, in xaml, >> from the .xap >> >> It loads the image in IE7 just fine, which is better than I ever got >> it to do. It must be the use of LoadComponent? > > Yep, LoadComponent actually has knowledge of the XAP file and looks in there to resolve URLs first. XamlReader.Load doesn't know about the XAP, so it never looks in there. In my opinion, keeping in mind I know nothing about the silverlight code, is that HttpWebRequest should know about the XAP so that requests for /resource always check the XAP first. If HttpWebRequest is used internally to load images, fonts, etc then LoadXaml and LoadComponent will just work. It would produce the most consistent behavior, if /urls mean something special, they should keep that meaning in as many places as possible. I opened an issue here: http://www.codeplex.com/sdlsdk/WorkItem/View.aspx?WorkItemId=10945 Good luck, -Dan >> Does that mean that it never works when using XamlReader.Load ? >> Because I could never get that to work, and that's a major problem. >> Everything in my interface except the root element is either created >> in code or with XamlReader.Load. From what I gather, that means I >> cannot put images, fonts, etc in my xap file. > > It does seem like a stupid limitation, so let me poke around and see if there's a solution. > >> Thanks for taking the time to look into this. >> >> -Dan > > FYI, I make a C# app that works fine in FF3, so it may be my fault. Again, I'll put this on my todo list. Even better, if you make sure to log a bug on codeplex.com/sdlsdk, I'll be sure to get to it. > > ~js > >> On Thu, Jul 31, 2008 at 3:39 AM, Jimmy Schementi >> wrote: >> > Dan, >> > >> > http://silverlight.net/forums/p/17003/76203.aspx#76203 >> > >> > You're definitely not doing anything wrong. Here's a repro of your >> issue: >> > >> > http://jimmy.schementi.com/silverlight/xaml-image-bug/ >> > >> > The crazy thing is this only repros in Firefox3, and is perfectly >> fine in IE8! Even crazier, I just made a C# project with the >> Silverlight VS tools, and it worked both in FF3 and IE8, ugh. There's >> nothing fundamentally different about the 2, so I'm a little confused. >> I'm trying to make a minimal C# repro and figure out who to blame, me >> or the SL team. =P >> > >> > ~js >> > >> >> -----Original Message----- >> >> From: users-bounces at lists.ironpython.com [mailto:users- >> >> bounces at lists.ironpython.com] On Behalf Of Dan Eloff >> >> Sent: Friday, July 11, 2008 11:53 PM >> >> To: Discussion of IronPython >> >> Subject: [IronPython] loading an image in silverlight, in xaml, from >> >> the .xap >> >> >> >> I cannot load an image from in the xap file via uri. >> >> >> >> This one has been bugging me for a long time now. I think it must >> have >> >> something to do with a difference between a Chiron xap and a VS >> built >> >> xap. >> >> >> >> Could someone on the silverlight team (Jimmy!) please take a look at >> >> the demo project and tell me what I'm doing wrong? >> >> >> >> http://silverlight.net/forums/t/17003.aspx >> >> >> >> Thanks, >> >> -Dan >> >> _______________________________________________ >> >> 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 srivatsn at microsoft.com Thu Aug 7 20:50:03 2008 From: srivatsn at microsoft.com (Srivatsn Narayanan) Date: Thu, 7 Aug 2008 11:50:03 -0700 Subject: [IronPython] pyc.py sample In-Reply-To: <489B3B85.3010604@voidspace.org.uk> References: <489AF007.4060801@voidspace.org.uk> <489B2DB2.3050207@voidspace.org.uk> <489B3B85.3010604@voidspace.org.uk> Message-ID: Promotion or punishment? Well.. as Obi-Wan would say it all depends greatly on our point of view :) No Dave and I just share it out between us based on whoever is free(er) at that point. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, August 07, 2008 11:14 AM To: Discussion of IronPython Subject: Re: [IronPython] pyc.py sample Srivatsn Narayanan wrote: >> Ok. May I suggest not including sample updates in IronPython release >> notes if they have their own release cycle... :-) >> > Yes my fault there. I didn't know about the separate release cycle for samples. I'm learning... :) > Are you generally responsible for doing new releases Sri? (Is this a promotion or punishment...) Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, August 07, 2008 10:16 AM > To: Discussion of IronPython > Subject: Re: [IronPython] pyc.py sample > > Dave Fugate wrote: > >> Hi Michael, this seems like as good of a time as any to shed some light on our thoughts around the IronPython samples. First Pyc - Pyc.py was indeed updated for IronPython 2.x in our internal TFS repository last month, but as most people are already aware we don't reship the samples with every minor release of IronPython. The main reason we do this (at least from my perspective) is testing. Most of the samples are GUI-based and need to be tested by hand which is quite time consuming. >> > > Testing GUI applications - particularly windows forms based ones - is a > process amenable to automation. We have a few hundred automated > 'functional tests' for Resolver One and I can highly recommend it. > > >> By cutting the samples out of minor IronPython releases, we're able to release IronPython in quicker intervals and focus more test time on new features as opposed to samples verification. Regardless, we believe this sample depicts a vital aspect of IronPython functionality and will do a one-time 2.0B4 release of Pyc on www.codeplex.com/IronPython sometime today to get feedback. >> >> As for inclusion of the samples into the installer for IronPython 2.0, our current plan is actually to follow what we did with IronPython 1.0. That is, we'll release the samples shortly after 2.0 ships. The fundamental reason for doing this is that delaying samples work lets us put more effort into improving the quality of ipy.exe and the core IronPython documentation. >> >> > Ok. May I suggest not including sample updates in IronPython release > notes if they have their own release cycle... :-) > > Michael > > > >> Dave >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Thursday, August 07, 2008 5:52 AM >> To: Discussion of IronPython >> Subject: [IronPython] pyc.py sample >> >> Hello guys, >> >> The IronPython 2.0b4 release notes state: >> >> # Static compilation of python files is now supported again and the pyc.py >> sample has been updated to use the newer version. >> >> Where is the updated sample? I can't find it... >> >> As samples are updated for IronPython 2 it would make sense to move them >> into the installer (in their own directory on the start menu entry for >> IronPython). >> >> Michael >> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/ >> http://www.trypython.org/ >> http://www.ironpython.info/ >> http://www.resolverhacks.net/ >> http://www.theotherdelia.co.uk/ >> >> _______________________________________________ >> 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/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://wwww.theotherdelia.co.uk/ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://wwww.theotherdelia.co.uk/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From daftspaniel at gmail.com Thu Aug 7 21:53:55 2008 From: daftspaniel at gmail.com (Davy Mitchell) Date: Thu, 7 Aug 2008 20:53:55 +0100 Subject: [IronPython] Deprecation warning on Windows Form Double Buffered Message-ID: <20253b0c0808071253p320332ceod7959a93905887fb@mail.gmail.com> Hi All, With the following code I am getting a warning: DeprecationWarning: Accessing protected method DoubleBuffered from non-derived type Form *import clr clr.AddReference('System.Windows.Forms') from System import * from System.Windows.Forms import * class LDForm(Form): def __init__(self): self.DoubleBuffered = True def __call__(self): Application.EnableVisualStyles() Application.Run(self) LDForm()()* Is this related to the import changes? I've not been doing much Pythoning lately so sorry if I have missed something... Thanks, Davy -- Davy Mitchell Blog - http://daftspaniel.blogspot.com Twitter - http://twitter.com/daftspaniel Skype - daftspaniel http://needgod.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.cerecke at telogis.com Thu Aug 7 22:05:09 2008 From: carl.cerecke at telogis.com (Carl Cerecke) Date: Fri, 8 Aug 2008 08:05:09 +1200 Subject: [IronPython] Standard Library Inclusion - C Extension Modules In-Reply-To: References: <489AF25D.6060507@voidspace.org.uk> <5b0248170808070606i5e36ca31v6f88e58fa52bc6e@mail.gmail.com> Message-ID: <92fc6620808071305y2e95fdf9o520e6647ba5df9b9@mail.gmail.com> On Fri, Aug 8, 2008 at 2:26 AM, Curt Hagenlocher wrote: > The sqlite example is more complicated for two reasons: > 1) There wouldn't be any point in doing it unless we could distribute > the referenced third-party project as well. This probably gives Harry > the opportunity for a whole new round of quality time with lawyers. Here's an extract from the sqlite source code: ** The author disclaims copyright to this source code. In place of ** a legal notice, here is a blessing: ** ** May you do good and not evil. ** May you find forgiveness for yourself and forgive others. ** May you share freely, never taking more than you give. How can a lawyer have problems with that? Unless it's problems with their conscience :) Cheers, Carl. -- Carl Cerecke, PhD Senior Software Engineer Telogis, Intelligent Location Technology Level 2, Building 2 1 Show Place Addington CHRISTCHURCH New Zealand Phone: +64 03 339 2825 ext 208 Fax: +64 03 339 4537 Email: carl.cerecke at telogis.com This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. From dinov at exchange.microsoft.com Thu Aug 7 22:09:16 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 7 Aug 2008 13:09:16 -0700 Subject: [IronPython] Deprecation warning on Windows Form Double Buffered In-Reply-To: <20253b0c0808071253p320332ceod7959a93905887fb@mail.gmail.com> References: <20253b0c0808071253p320332ceod7959a93905887fb@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227012C9376C76E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> The warning is overly aggressive in this case - the warning is removed for the next release and your code will still work so you can ignore it. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Thursday, August 07, 2008 12:54 PM To: Discussion of IronPython Subject: [IronPython] Deprecation warning on Windows Form Double Buffered Hi All, With the following code I am getting a warning: DeprecationWarning: Accessing protected method DoubleBuffered from non-derived type Form import clr clr.AddReference('System.Windows.Forms') from System import * from System.Windows.Forms import * class LDForm(Form): def __init__(self): self.DoubleBuffered = True def __call__(self): Application.EnableVisualStyles() Application.Run(self) LDForm()() Is this related to the import changes? I've not been doing much Pythoning lately so sorry if I have missed something... Thanks, Davy -- Davy Mitchell Blog - http://daftspaniel.blogspot.com Twitter - http://twitter.com/daftspaniel Skype - daftspaniel http://needgod.com ________________________________ Sample disclaimer text -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Thu Aug 7 22:17:23 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 7 Aug 2008 13:17:23 -0700 Subject: [IronPython] Standard Library Inclusion - C Extension Modules In-Reply-To: References: <489AF25D.6060507@voidspace.org.uk> <5b0248170808070606i5e36ca31v6f88e58fa52bc6e@mail.gmail.com> Message-ID: I had a brief discussion about this with Harry and want to add a few things. On Thu, Aug 7, 2008 at 7:26 AM, Curt Hagenlocher wrote: > > Seo's example is a simpler one. Harry is working on is getting legal > approval for accepting community contributions into the modules. Once > that's done (no ETA, I'm afraid), Seo would sign a contributor > agreement and we could include his pyexpat compatibility shim. There's another approach that would allow us to accept this code today. If Seo contributes this back to the PSF, we can pick it up from the CPython codebase. The change could be implemented by modifying test\test_pyexpat.py and xml\parsers\expat.py and using "if sys.platform == 'cli'" as needed. I don't know how open the PSF will be to this, but we intend to make similar submissions once *that* particular project makes it through legal... > The sqlite example is more complicated for two reasons: > 1) There wouldn't be any point in doing it unless we could distribute > the referenced third-party project as well. This probably gives Harry > the opportunity for a whole new round of quality time with lawyers. The chances of this happening are extremely small. If someone wants to contribute _sqlite code that they wrote themselves, we'll be happy to take it when we're ready for contributions. But accepting third-party code into the distribution is a different can of worms that we're not interested in tackling at this time. There's nothing to prevent this from being implemented as an external community project, though. -- Curt Hagenlocher curt at hagenlocher.org From daftspaniel at gmail.com Thu Aug 7 22:22:45 2008 From: daftspaniel at gmail.com (Davy Mitchell) Date: Thu, 7 Aug 2008 21:22:45 +0100 Subject: [IronPython] Deprecation warning on Windows Form Double Buffered In-Reply-To: <7AD436E4270DD54A94238001769C2227012C9376C76E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <20253b0c0808071253p320332ceod7959a93905887fb@mail.gmail.com> <7AD436E4270DD54A94238001769C2227012C9376C76E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <20253b0c0808071322s20a43a23i3cf3deddc4a6df5@mail.gmail.com> Thanks Dino - that's good to know! On Thu, Aug 7, 2008 at 9:09 PM, Dino Viehland wrote: > The warning is overly aggressive in this case ? the warning is removed > for the next release and your code will still work so you can ignore it. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Davy Mitchell > *Sent:* Thursday, August 07, 2008 12:54 PM > *To:* Discussion of IronPython > *Subject:* [IronPython] Deprecation warning on Windows Form Double > Buffered > > > > Hi All, > > With the following code I am getting a warning: > > DeprecationWarning: Accessing protected method DoubleBuffered from > non-derived type Form > > *import clr > clr.AddReference('System.Windows.Forms') > from System import * > from System.Windows.Forms import * > class LDForm(Form): > > def __init__(self): > self.DoubleBuffered = True > def __call__(self): > Application.EnableVisualStyles() > Application.Run(self) > > LDForm()()* > > Is this related to the import changes? I've not been doing much Pythoning > lately so sorry if I have missed something... > > Thanks, > Davy > > -- > Davy Mitchell > Blog - http://daftspaniel.blogspot.com > Twitter - http://twitter.com/daftspaniel > Skype - daftspaniel http://needgod.com > > ------------------------------ > Sample disclaimer text > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- Davy Mitchell Blog - http://daftspaniel.blogspot.com Twitter - http://twitter.com/daftspaniel Skype - daftspaniel http://needgod.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Aug 7 22:24:40 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 07 Aug 2008 21:24:40 +0100 Subject: [IronPython] Standard Library Inclusion - C Extension Modules In-Reply-To: References: <489AF25D.6060507@voidspace.org.uk> <5b0248170808070606i5e36ca31v6f88e58fa52bc6e@mail.gmail.com> Message-ID: <489B5A08.207@voidspace.org.uk> Curt Hagenlocher wrote: > I had a brief discussion about this with Harry and want to add a few things. > > On Thu, Aug 7, 2008 at 7:26 AM, Curt Hagenlocher wrote: > >> Seo's example is a simpler one. Harry is working on is getting legal >> approval for accepting community contributions into the modules. Once >> that's done (no ETA, I'm afraid), Seo would sign a contributor >> agreement and we could include his pyexpat compatibility shim. >> > > There's another approach that would allow us to accept this code > today. If Seo contributes this back to the PSF, we can pick it up > from the CPython codebase. The change could be implemented by > modifying test\test_pyexpat.py and xml\parsers\expat.py and using "if > sys.platform == 'cli'" as needed. I don't know how open the PSF will > be to this, but we intend to make similar submissions once *that* > particular project makes it through legal... > > >> The sqlite example is more complicated for two reasons: >> 1) There wouldn't be any point in doing it unless we could distribute >> the referenced third-party project as well. This probably gives Harry >> the opportunity for a whole new round of quality time with lawyers. >> > > Actually - there is *no* requirement for you to distribute the third party code. That wouldn't make the compatibility layer pointless, it would still be extremely useful. Michael > The chances of this happening are extremely small. If someone wants > to contribute _sqlite code that they wrote themselves, we'll be happy > to take it when we're ready for contributions. But accepting > third-party code into the distribution is a different can of worms > that we're not interested in tackling at this time. > > There's nothing to prevent this from being implemented as an external > community project, though. > > -- > 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/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From curt at hagenlocher.org Thu Aug 7 22:40:26 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 7 Aug 2008 13:40:26 -0700 Subject: [IronPython] Standard Library Inclusion - C Extension Modules In-Reply-To: <489B5A08.207@voidspace.org.uk> References: <489AF25D.6060507@voidspace.org.uk> <5b0248170808070606i5e36ca31v6f88e58fa52bc6e@mail.gmail.com> <489B5A08.207@voidspace.org.uk> Message-ID: On Thu, Aug 7, 2008 at 1:24 PM, Michael Foord wrote: > Curt Hagenlocher wrote: > >> The sqlite example is more complicated for two reasons: >> 1) There wouldn't be any point in doing it unless we could distribute >> the referenced third-party project as well. > > Actually - there is *no* requirement for you to distribute the third party > code. That wouldn't make the compatibility layer pointless, it would still > be extremely useful. My feeling is that you may as well download an entire package if you're going to need to download any single part of it. I'd rather not deliver a feature that doesn't work at all "out-of-the-box". But I imagine we'd reconsider this if there's enough demand for it. -- Curt Hagenlocher curt at hagenlocher.org From srivatsn at microsoft.com Fri Aug 8 00:18:28 2008 From: srivatsn at microsoft.com (Srivatsn Narayanan) Date: Thu, 7 Aug 2008 15:18:28 -0700 Subject: [IronPython] pyc.py sample In-Reply-To: References: <489AF007.4060801@voidspace.org.uk> <489B2DB2.3050207@voidspace.org.uk> <489B3B85.3010604@voidspace.org.uk> Message-ID: The sample has been uploaded to Codeplex and is available in the Beta4 release page - http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=14353 -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Srivatsn Narayanan Sent: Thursday, August 07, 2008 11:50 AM To: Discussion of IronPython Subject: Re: [IronPython] pyc.py sample Promotion or punishment? Well.. as Obi-Wan would say it all depends greatly on our point of view :) No Dave and I just share it out between us based on whoever is free(er) at that point. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, August 07, 2008 11:14 AM To: Discussion of IronPython Subject: Re: [IronPython] pyc.py sample Srivatsn Narayanan wrote: >> Ok. May I suggest not including sample updates in IronPython release >> notes if they have their own release cycle... :-) >> > Yes my fault there. I didn't know about the separate release cycle for samples. I'm learning... :) > Are you generally responsible for doing new releases Sri? (Is this a promotion or punishment...) Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, August 07, 2008 10:16 AM > To: Discussion of IronPython > Subject: Re: [IronPython] pyc.py sample > > Dave Fugate wrote: > >> Hi Michael, this seems like as good of a time as any to shed some light on our thoughts around the IronPython samples. First Pyc - Pyc.py was indeed updated for IronPython 2.x in our internal TFS repository last month, but as most people are already aware we don't reship the samples with every minor release of IronPython. The main reason we do this (at least from my perspective) is testing. Most of the samples are GUI-based and need to be tested by hand which is quite time consuming. >> > > Testing GUI applications - particularly windows forms based ones - is a > process amenable to automation. We have a few hundred automated > 'functional tests' for Resolver One and I can highly recommend it. > > >> By cutting the samples out of minor IronPython releases, we're able to release IronPython in quicker intervals and focus more test time on new features as opposed to samples verification. Regardless, we believe this sample depicts a vital aspect of IronPython functionality and will do a one-time 2.0B4 release of Pyc on www.codeplex.com/IronPython sometime today to get feedback. >> >> As for inclusion of the samples into the installer for IronPython 2.0, our current plan is actually to follow what we did with IronPython 1.0. That is, we'll release the samples shortly after 2.0 ships. The fundamental reason for doing this is that delaying samples work lets us put more effort into improving the quality of ipy.exe and the core IronPython documentation. >> >> > Ok. May I suggest not including sample updates in IronPython release > notes if they have their own release cycle... :-) > > Michael > > > >> Dave >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Thursday, August 07, 2008 5:52 AM >> To: Discussion of IronPython >> Subject: [IronPython] pyc.py sample >> >> Hello guys, >> >> The IronPython 2.0b4 release notes state: >> >> # Static compilation of python files is now supported again and the pyc.py >> sample has been updated to use the newer version. >> >> Where is the updated sample? I can't find it... >> >> As samples are updated for IronPython 2 it would make sense to move them >> into the installer (in their own directory on the start menu entry for >> IronPython). >> >> Michael >> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/ >> http://www.trypython.org/ >> http://www.ironpython.info/ >> http://www.resolverhacks.net/ >> http://www.theotherdelia.co.uk/ >> >> _______________________________________________ >> 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/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://wwww.theotherdelia.co.uk/ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://wwww.theotherdelia.co.uk/ _______________________________________________ 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 Fri Aug 8 00:24:30 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 07 Aug 2008 23:24:30 +0100 Subject: [IronPython] pyc.py sample In-Reply-To: References: <489AF007.4060801@voidspace.org.uk> <489B2DB2.3050207@voidspace.org.uk> <489B3B85.3010604@voidspace.org.uk> Message-ID: <489B761E.3090103@voidspace.org.uk> Srivatsn Narayanan wrote: > The sample has been uploaded to Codeplex and is available in the Beta4 release page - http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=14353 > > Cool - thanks! Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Srivatsn Narayanan > Sent: Thursday, August 07, 2008 11:50 AM > To: Discussion of IronPython > Subject: Re: [IronPython] pyc.py sample > > Promotion or punishment? Well.. as Obi-Wan would say it all depends greatly on our point of view :) > > No Dave and I just share it out between us based on whoever is free(er) at that point. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, August 07, 2008 11:14 AM > To: Discussion of IronPython > Subject: Re: [IronPython] pyc.py sample > > Srivatsn Narayanan wrote: > >>> Ok. May I suggest not including sample updates in IronPython release >>> notes if they have their own release cycle... :-) >>> >>> >> Yes my fault there. I didn't know about the separate release cycle for samples. I'm learning... :) >> >> > > Are you generally responsible for doing new releases Sri? (Is this a > promotion or punishment...) > > Michael > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Thursday, August 07, 2008 10:16 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] pyc.py sample >> >> Dave Fugate wrote: >> >> >>> Hi Michael, this seems like as good of a time as any to shed some light on our thoughts around the IronPython samples. First Pyc - Pyc.py was indeed updated for IronPython 2.x in our internal TFS repository last month, but as most people are already aware we don't reship the samples with every minor release of IronPython. The main reason we do this (at least from my perspective) is testing. Most of the samples are GUI-based and need to be tested by hand which is quite time consuming. >>> >>> >> Testing GUI applications - particularly windows forms based ones - is a >> process amenable to automation. We have a few hundred automated >> 'functional tests' for Resolver One and I can highly recommend it. >> >> >> >>> By cutting the samples out of minor IronPython releases, we're able to release IronPython in quicker intervals and focus more test time on new features as opposed to samples verification. Regardless, we believe this sample depicts a vital aspect of IronPython functionality and will do a one-time 2.0B4 release of Pyc on www.codeplex.com/IronPython sometime today to get feedback. >>> >>> As for inclusion of the samples into the installer for IronPython 2.0, our current plan is actually to follow what we did with IronPython 1.0. That is, we'll release the samples shortly after 2.0 ships. The fundamental reason for doing this is that delaying samples work lets us put more effort into improving the quality of ipy.exe and the core IronPython documentation. >>> >>> >>> >> Ok. May I suggest not including sample updates in IronPython release >> notes if they have their own release cycle... :-) >> >> Michael >> >> >> >> >>> Dave >>> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >>> Sent: Thursday, August 07, 2008 5:52 AM >>> To: Discussion of IronPython >>> Subject: [IronPython] pyc.py sample >>> >>> Hello guys, >>> >>> The IronPython 2.0b4 release notes state: >>> >>> # Static compilation of python files is now supported again and the pyc.py >>> sample has been updated to use the newer version. >>> >>> Where is the updated sample? I can't find it... >>> >>> As samples are updated for IronPython 2 it would make sense to move them >>> into the installer (in their own directory on the start menu entry for >>> IronPython). >>> >>> Michael >>> >>> -- >>> http://www.ironpythoninaction.com/ >>> http://www.voidspace.org.uk/ >>> http://www.trypython.org/ >>> http://www.ironpython.info/ >>> http://www.resolverhacks.net/ >>> http://www.theotherdelia.co.uk/ >>> >>> _______________________________________________ >>> 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/ >> http://www.trypython.org/ >> http://www.ironpython.info/ >> http://www.resolverhacks.net/ >> http://wwww.theotherdelia.co.uk/ >> >> _______________________________________________ >> 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/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://wwww.theotherdelia.co.uk/ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From sanxiyn at gmail.com Fri Aug 8 13:00:35 2008 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 8 Aug 2008 20:00:35 +0900 Subject: [IronPython] Who's who in IronPython world Message-ID: <5b0248170808080400p620a73b5m73dd8a6651b6f3fe@mail.gmail.com> I've started a wiki page on IronPython Cookbook to collect info regarding who's who in IronPython world. http://www.ironpython.info/index.php/People It would be awesome if some Microsoft people can clarify the team's organizational structures, job titles, current list of team members, etc. Other people on the list, feel free to list your name there. -- Seo Sanghyeon From gllfnc at hotmail.it Fri Aug 8 14:36:30 2008 From: gllfnc at hotmail.it (Francesco Gallo) Date: Fri, 8 Aug 2008 14:36:30 +0200 Subject: [IronPython] Info Install IronPythonStudio Message-ID: Hi ... a question: why can achieve only projects WPF? And not console application as described in the screencast instead? -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Lawler at franke.com Fri Aug 8 16:57:38 2008 From: David.Lawler at franke.com (David.Lawler at franke.com) Date: Fri, 8 Aug 2008 10:57:38 -0400 Subject: [IronPython] Interesting problems with compiling IP2 programs.... Message-ID: Unfortunately, now you will be 'punished' for releasing pyc.py. The following code does some funny things when compiled: print "1" import clr print "2" import os print "3" print os.getcwd() import sys print "4" print sys.version This works fine if you launch it as a script with IP2. You get: 1 2 3 C:\Documents and Settings\LD003\My Documents\Python Projects\CompileProblem 4 2.5.0 (IronPython 2.0 Beta (2.0.0.4000) on .NET 2.0.50727.1433) >Exit code: 0 If you compile it and shove os.py and ntpath.py into the directory it lives in (along with the required dll's).... you get: 1 2 and then the program hangs....eats memory....and eventually dies with a StackOverflowException. if you comment out import os, print "3", print os.getcwd() you get: 1 2 4 2.5.0 () not exactly the same result. For me this is not an urgent fix....for other folks....you are warned. Regards, David From curt at hagenlocher.org Fri Aug 8 17:46:00 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 8 Aug 2008 08:46:00 -0700 Subject: [IronPython] Who's who in IronPython world In-Reply-To: <5b0248170808080400p620a73b5m73dd8a6651b6f3fe@mail.gmail.com> References: <5b0248170808080400p620a73b5m73dd8a6651b6f3fe@mail.gmail.com> Message-ID: On Fri, Aug 8, 2008 at 4:00 AM, Sanghyeon Seo wrote: > > It would be awesome if some Microsoft people can clarify the team's > organizational structures, job titles, current list of team members, > etc. I've updated what's there somewhat, but the premise that there's a clean separation between IronRuby and IronPython isn't quite true. The "GO team" (GO stands for Growth Opportunities) consists of IronPython, IronRuby and F# (which I'll henceforth omit). Shri is the dev lead for the team, Dave Remy is the PM lead for the team and there is currently no test lead. The developers are Oleg, Dino, Tomas Matousek and myself. Dino is the main IronPython dev and Tomas is the main IronRuby dev. I work on the internals of both and Oleg is working on the VS integration for both. The testers are Dave Fugate, Srivatsn, and Jim Deville. Until now, they've been Python / Python / Ruby, respectively, but that's subject to change as projects hit various stages in their lifecycle. Harry is the PM on IronPython, John Lam is the PM on IronRuby and Jimmy is the PM for Silverlight integration. I'm a little less clear on how the responsibilities are divided on the DLR team, and there are quite a few people working on the DLR who aren't listed. -- Curt Hagenlocher curt at hagenlocher.org From dinov at exchange.microsoft.com Fri Aug 8 18:02:00 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 8 Aug 2008 09:02:00 -0700 Subject: [IronPython] Who's who in IronPython world In-Reply-To: References: <5b0248170808080400p620a73b5m73dd8a6651b6f3fe@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227012C9376C880@DF-GRTDANE-MSG.exchange.corp.microsoft.com> And of course not to forget Jim Hugunin :) He's now the architect for GO, DLR, and some general VS languages input as well. Also our team is no longer part of the CLR - we're now in the Visual Studio org. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Friday, August 08, 2008 8:46 AM To: Discussion of IronPython Subject: Re: [IronPython] Who's who in IronPython world On Fri, Aug 8, 2008 at 4:00 AM, Sanghyeon Seo wrote: > > It would be awesome if some Microsoft people can clarify the team's > organizational structures, job titles, current list of team members, > etc. I've updated what's there somewhat, but the premise that there's a clean separation between IronRuby and IronPython isn't quite true. The "GO team" (GO stands for Growth Opportunities) consists of IronPython, IronRuby and F# (which I'll henceforth omit). Shri is the dev lead for the team, Dave Remy is the PM lead for the team and there is currently no test lead. The developers are Oleg, Dino, Tomas Matousek and myself. Dino is the main IronPython dev and Tomas is the main IronRuby dev. I work on the internals of both and Oleg is working on the VS integration for both. The testers are Dave Fugate, Srivatsn, and Jim Deville. Until now, they've been Python / Python / Ruby, respectively, but that's subject to change as projects hit various stages in their lifecycle. Harry is the PM on IronPython, John Lam is the PM on IronRuby and Jimmy is the PM for Silverlight integration. I'm a little less clear on how the responsibilities are divided on the DLR team, and there are quite a few people working on the DLR who aren't listed. -- Curt Hagenlocher curt at hagenlocher.org _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com Sample disclaimer text From olegtk at microsoft.com Fri Aug 8 18:11:28 2008 From: olegtk at microsoft.com (Oleg Tkachenko) Date: Fri, 8 Aug 2008 09:11:28 -0700 Subject: [IronPython] Info Install IronPythonStudio In-Reply-To: References: Message-ID: Hmmm, I need more information to suggest anything. Am I right that when you create new project you see only WPF application template in the new project dialog? What version IronPython Studio you are talking about (isolated/integrated) and what is your environment (if Visual Studio then which one)? -- Oleg From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Francesco Gallo Sent: Friday, August 08, 2008 5:37 AM To: users at lists.ironpython.com Subject: [IronPython] Info Install IronPythonStudio Hi ... a question: why can achieve only projects WPF? And not console application as described in the screencast instead? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Fri Aug 8 18:30:32 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 08 Aug 2008 17:30:32 +0100 Subject: [IronPython] Who's who in IronPython world In-Reply-To: References: <5b0248170808080400p620a73b5m73dd8a6651b6f3fe@mail.gmail.com> Message-ID: <489C74A8.3000505@voidspace.org.uk> Curt Hagenlocher wrote: > On Fri, Aug 8, 2008 at 4:00 AM, Sanghyeon Seo wrote: > >> It would be awesome if some Microsoft people can clarify the team's >> organizational structures, job titles, current list of team members, >> etc. >> > > I've updated what's there somewhat, but the premise that there's a > clean separation between IronRuby and IronPython isn't quite true. > > The "GO team" (GO stands for Growth Opportunities) consists of > IronPython, IronRuby and F# (which I'll henceforth omit). Shri is the > dev lead for the team, Dave Remy is the PM lead for the team and there > is currently no test lead. The developers are Oleg, Dino, Tomas > Matousek and myself. Dino is the main IronPython dev and Tomas is the > main IronRuby dev. I work on the internals of both and Oleg is > working on the VS integration for both. The testers are Dave Fugate, > Srivatsn, and Jim Deville. Until now, they've been Python / Python / > Ruby, respectively, but that's subject to change as projects hit > various stages in their lifecycle. Harry is the PM on IronPython, > John Lam is the PM on IronRuby and Jimmy is the PM for Silverlight > integration. > > I'm a little less clear on how the responsibilities are divided on the > DLR team, and there are quite a few people working on the DLR who > aren't listed. > > That sounds like a great addition to the page - with the omitted people added of course... (and thanks for the updates you have already made.) 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/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From dfugate at microsoft.com Fri Aug 8 20:33:31 2008 From: dfugate at microsoft.com (Dave Fugate) Date: Fri, 8 Aug 2008 11:33:31 -0700 Subject: [IronPython] IronPython 1.1.2 In-Reply-To: <7346A825E148B049A9AD1D3ED46A2D911A48CA0B6A@NA-EXMSG-C106.redmond.corp.microsoft.com> References: <7346A825E148B049A9AD1D3ED46A2D911A48CA098F@NA-EXMSG-C106.redmond.corp.microsoft.com> <5F42453283142A448EB8AD5B34FCFC6D0115031BEBA1@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <7346A825E148B049A9AD1D3ED46A2D911A48CA0A39@NA-EXMSG-C106.redmond.corp.microsoft.com> <7AD436E4270DD54A94238001769C2227010FC838B92C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <7346A825E148B049A9AD1D3ED46A2D911A48CA0B6A@NA-EXMSG-C106.redmond.corp.microsoft.com> Message-ID: Hello IronPython Community, It's been several weeks since we released IronPython 1.1.2 RC1 and this build does not appear to have caused any new issues. As a result I'm pleased to announce the release of IronPython 1.1.2. IronPython v1.1.2 is a minor update in which we fixed the most requested CodePlex bugs and also a handful of trivial bugs. In total twenty-one bugs have been resolved for 1.1.2. It's worth noting that this included the implementation of the "_winreg" CPython module and a few performance improvements in targeted areas. Please also note that there are two potentially breaking changes in this release: [PicExportError] * nt.unlink will now throw an exception if the file doesn't exist, as it does in CPython [PicExportError] * The signature of IronPython.Runtime.Operations.Ops.Id() has changed and it now returns an object instead of long. This maps to the id() function in Python. Note that there is no change for Python caused by this and only code which is directly calling Ops.Id from a statically typed language like C# or VB will be affected. The following CodePlex Work Items were closed: * 16368 1.1.2: nt.access is missing * 16402 1.1.2: implement _winreg module * 15105 1.1.2: endpos is zero in IronPython 1.1.1 * 16335 1.1.2: Event handlers can cause circular references and leak memory * 16337 1.1.2: Trivial: Implement float.__lt__(float) * 16338 1.1.2: Using lambda in class definition will add into the * 16342 1.1.2: calling base class __call__ invokes constructor instead * 16343 1.1.2: problem with __slots__ and __init__ in new-style classes * 16347 1.1.2: Trivial: popen shouldn't open new window * 16348 1.1.2: Removes the inexistent file did not throw OSError in IP * 16350 1.1.2: int() doesn't convert representable longs to int * 16351 1.1.2: dict.update doesn't take keyword arguments - differs from CPython * 16353 1.1.2: Trivial: int('0x20', 16) fails to parse, long too * 16355 1.1.2: unpacking single element tuples in for-statement, listcomp and generator * 16356 1.1.2: socket.getnameinfo(...) broken under Vista * 16360 1.1.2: Class with slots and getattr not compatible * 16363 1.1.2: Can't call method w/ nullable as 1st argument w/ greater than 5 arguments * 16364 1.1.2: Backport fix for compiled regular expressions * 16365 1.1.2: Tuple hashing improvements * 16366 1.1.2: PyCF_DONT_IMPLY_DEDENT support in compile * 16749 1.1.2 (Trivial): Modifier of PythonEngine.DefaultCompilerContext(..) We'd like to thank everyone in the community who contributed to these bugs: Ronnie Maor, jackeyoo, sanxiyn, Michael Foord, Kamil Dworakowski, lthompson, romank, Jeff Brown, rridge, David Fraser, pobrien, ebaklund. You can download IronPython 1.1.2 from http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=IronPython&ReleaseId=11275. The IronPython Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Fri Aug 8 20:37:41 2008 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Fri, 08 Aug 2008 19:37:41 +0100 Subject: [IronPython] IronPython 1.1.2 In-Reply-To: References: <7346A825E148B049A9AD1D3ED46A2D911A48CA098F@NA-EXMSG-C106.redmond.corp.microsoft.com> <5F42453283142A448EB8AD5B34FCFC6D0115031BEBA1@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <7346A825E148B049A9AD1D3ED46A2D911A48CA0A39@NA-EXMSG-C106.redmond.corp.microsoft.com> <7AD436E4270DD54A94238001769C2227010FC838B92C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <7346A825E148B049A9AD1D3ED46A2D911A48CA0B6A@NA-EXMSG-C106.redmond.corp.microsoft.com> Message-ID: <489C9275.1060108@resolversystems.com> Dave, Congratulations on getting from RC1 to release without any need for bugfix builds :-) We're just about to release version 1.2 of Resolver One, so we'll port our codebase over to IP 1.1.2 as soon as that's out of the door. Regards, and thanks! Giles Dave Fugate wrote: > > Hello IronPython Community, > > It's been several weeks since we released IronPython 1.1.2 RC1 and > this build does not appear to have caused any new issues. As a result > I'm pleased to announce the release of IronPython 1.1.2. > > > > IronPython v1.1.2 is a minor update in which we fixed the most > requested CodePlex bugs and also a handful of trivial bugs. In total > twenty-one bugs have been resolved for 1.1.2. It's worth noting that > this included the implementation of the "_winreg" CPython module and a > few performance improvements in targeted areas. Please also note that > there are two potentially breaking changes in this release: > > * ? nt.unlink will now throw an exception if the file doesn't exist, > as it does in CPython > > * ? The signature of IronPython.Runtime.Operations.Ops.Id() has > changed and it now returns an object instead of long. This maps to the > id() function in Python. Note that there is no change for Python > caused by this and only code which is directly calling Ops.Id from a > statically typed language like C# or VB will be affected. > > The following CodePlex Work Items were closed: > > ? 16368 1.1.2: nt.access is missing > > ? 16402 1.1.2: implement _winreg module > > ? 15105 1.1.2: endpos is zero in IronPython 1.1.1 > > ? 16335 1.1.2: Event handlers can cause circular references and leak > memory > > ? 16337 1.1.2: Trivial: Implement float.__lt__(float) > > ? 16338 1.1.2: Using lambda in class definition will add > into the > > ? 16342 1.1.2: calling base class __call__ invokes constructor instead > > ? 16343 1.1.2: problem with __slots__ and __init__ in new-style classes > > ? 16347 1.1.2: Trivial: popen shouldn't open new window > > ? 16348 1.1.2: Removes the inexistent file did not throw OSError in IP > > ? 16350 1.1.2: int() doesn't convert representable longs to int > > ? 16351 1.1.2: dict.update doesn't take keyword arguments - differs > from CPython > > ? 16353 1.1.2: Trivial: int('0x20', 16) fails to parse, long too > > ? 16355 1.1.2: unpacking single element tuples in for-statement, > listcomp and generator > > ? 16356 1.1.2: socket.getnameinfo(...) broken under Vista > > ? 16360 1.1.2: Class with slots and getattr not compatible > > ? 16363 1.1.2: Can't call method w/ nullable as 1st argument w/ > greater than 5 arguments > > ? 16364 1.1.2: Backport fix for compiled regular expressions > > ? 16365 1.1.2: Tuple hashing improvements > > ? 16366 1.1.2: PyCF_DONT_IMPLY_DEDENT support in compile > > ? 16749 1.1.2 (Trivial): Modifier of > PythonEngine.DefaultCompilerContext(..) > > > > We'd like to thank everyone in the community who contributed to these > bugs: Ronnie Maor, jackeyoo, sanxiyn, Michael Foord, Kamil > Dworakowski, lthompson, romank, Jeff Brown, rridge, David Fraser, > pobrien, ebaklund. > > > You can download IronPython 1.1.2 from > http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=IronPython&ReleaseId=11275 > . > > > The IronPython Team > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From srivatsn at microsoft.com Fri Aug 8 22:48:32 2008 From: srivatsn at microsoft.com (Srivatsn Narayanan) Date: Fri, 8 Aug 2008 13:48:32 -0700 Subject: [IronPython] Interesting problems with compiling IP2 programs.... In-Reply-To: References: Message-ID: Looks like this has already been fixed in the latest sources. This reproes with the beta4 binaries but works fine with the latest binaries from our depot (once I have thrown in stat.py and userdict.py anyway). There was an import related checkin that went in this Monday. That might have fixed this I believe. The latest sources are up on codeplex. So if you wish you could sync and try it out. Thanks for reporting this. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David.Lawler at franke.com Sent: Friday, August 08, 2008 7:58 AM To: Discussion of IronPython Subject: [IronPython] Interesting problems with compiling IP2 programs.... Unfortunately, now you will be 'punished' for releasing pyc.py. The following code does some funny things when compiled: print "1" import clr print "2" import os print "3" print os.getcwd() import sys print "4" print sys.version This works fine if you launch it as a script with IP2. You get: 1 2 3 C:\Documents and Settings\LD003\My Documents\Python Projects\CompileProblem 4 2.5.0 (IronPython 2.0 Beta (2.0.0.4000) on .NET 2.0.50727.1433) >Exit code: 0 If you compile it and shove os.py and ntpath.py into the directory it lives in (along with the required dll's).... you get: 1 2 and then the program hangs....eats memory....and eventually dies with a StackOverflowException. if you comment out import os, print "3", print os.getcwd() you get: 1 2 4 2.5.0 () not exactly the same result. For me this is not an urgent fix....for other folks....you are warned. Regards, David _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From olegtk at microsoft.com Sat Aug 9 00:37:46 2008 From: olegtk at microsoft.com (Oleg Tkachenko) Date: Fri, 8 Aug 2008 15:37:46 -0700 Subject: [IronPython] VS Shell Addin for IronPython Studio In-Reply-To: References: Message-ID: Sorry it took so long, but looks like you are the first person ever tried to do so :) Here is an authoritative answer from the VSX team: http://blogs.msdn.com/vsxteam/archive/2008/08/08/enabling-add-ins-in-your-isolated-vs-shell.aspx -- Oleg From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Stephens Sent: Monday, July 21, 2008 10:10 AM To: Discussion of IronPython Subject: [IronPython] VS Shell Addin for IronPython Studio I'm not sure if this is the right place to ask but I thought I would pose it here and if need be it can be redirected. I am trying to build an Addin for IronPython Studio. No matter what I try Iron Python Studio wont see my addin (despite them being turned on). I have setup a VM where I installed PythonStudio in standalone mode. I have constructed a folder in C:\Documents and Settings\michael\My Documents\IronPython Studio\Addins for my addins. I know the xml is being parsed in this directory because if I build invalid xml IronPython Studio throws an error. I have tried every combination of xml versions that I can think of. If anyone has any ideas I would love to hear them! I have attached the files below. Michael Stephens Electrical Engineering Graduate Student University of Wyoming falcon at uwyo.edu or 89iroc at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sat Aug 9 00:53:28 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 08 Aug 2008 23:53:28 +0100 Subject: [IronPython] Who's who in IronPython world In-Reply-To: References: <5b0248170808080400p620a73b5m73dd8a6651b6f3fe@mail.gmail.com> Message-ID: <489CCE68.4070209@voidspace.org.uk> Curt Hagenlocher wrote: > On Fri, Aug 8, 2008 at 4:00 AM, Sanghyeon Seo wrote: > >> It would be awesome if some Microsoft people can clarify the team's >> organizational structures, job titles, current list of team members, >> etc. >> > > I've updated what's there somewhat, but the premise that there's a > clean separation between IronRuby and IronPython isn't quite true. > > The "GO team" (GO stands for Growth Opportunities) consists of > IronPython, IronRuby and F# (which I'll henceforth omit). Shri is the > dev lead for the team, Dave Remy is the PM lead for the team and there > is currently no test lead. The developers are Oleg, Dino, Tomas > Matousek and myself. Dino is the main IronPython dev and Tomas is the > main IronRuby dev. I work on the internals of both and Oleg is > working on the VS integration for both. The testers are Dave Fugate, > Srivatsn, and Jim Deville. Until now, they've been Python / Python / > Ruby, respectively, but that's subject to change as projects hit > various stages in their lifecycle. Harry is the PM on IronPython, > John Lam is the PM on IronRuby and Jimmy is the PM for Silverlight > integration. > > I'm a little less clear on how the responsibilities are divided on the > DLR team, and there are quite a few people working on the DLR who > aren't listed. > I've updated the page based on this. http://www.ironpython.info/index.php/People#Microsoft 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/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From fuzzyman at voidspace.org.uk Sat Aug 9 01:18:34 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 09 Aug 2008 00:18:34 +0100 Subject: [IronPython] Silverlight on the Codeplex Site Message-ID: <489CD44A.6000509@voidspace.org.uk> The IronPython Codeplex site proudly announces: Silverlight v1.1 Alpha includes IronPython support! Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From huzi_1982 at hotmail.com Sat Aug 9 02:19:58 2008 From: huzi_1982 at hotmail.com (Huzaifa) Date: Fri, 8 Aug 2008 17:19:58 -0700 (PDT) Subject: [IronPython] IAttributesInjector In-Reply-To: <7AD436E4270DD54A94238001769C2227012C9376B89A@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <18701101.post@talk.nabble.com> <8FAE2A142FCABE4EB6B37348D78A9BFE02705AD9@XAEXG.GRAPECITY.NET> <18718581.post@talk.nabble.com> <7AD436E4270DD54A94238001769C2227012C9376B89A@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <18900900.post@talk.nabble.com> Sample working example will be helpful Dino Viehland wrote: > > It's located in Microsoft.Scripting.dll (not to be confused w/ > Microsoft.Scripting.Core.dll). > > The way you use this is you apply the assembly level attribute like: > > [assembly: ExtensionType(typeof(String), typeof(MyStringExtensions))] > > And then you define MyStringExtensions: > > public static class MyStringExtensions { > [SpecialName] > public static string GetCustomMember(string self, string name) { > return name; > } > > [SpecialName] > public static void SetMember(string self, string name, object > value) { > Console.WriteLine("Set called, {0}, {1}", name, value); > } > } > > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Huzaifa > Sent: Tuesday, July 29, 2008 11:31 AM > To: users at lists.ironpython.com > Subject: Re: [IronPython] IAttributesInjector > > > I could not find it "Microsoft.Scripting.Runtime.ExtensionTypeAttribute" > > Han Kejing wrote: >> >> Maybe is the "Microsoft.Scripting.Runtime.ExtensionTypeAttribute" >> attribute. >> You can found some simples in IronPythonTest project. >> >> ---------------------------------------------------------------- >> Follow my heart >> Colin Han @ GrapeCity >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com >> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Huzaifa >> Sent: 2008?7?29? 15:26 >> To: users at lists.ironpython.com >> Subject: [IronPython] IAttributesInjector >> >> >> I can not find this interface in ironpython 2.0 .What is the alternative >> if >> this interface have been removed. >> -- >> View this message in context: >> http://www.nabble.com/IAttributesInjector-tp18701101p18701101.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 >> >> > > -- > View this message in context: > http://www.nabble.com/IAttributesInjector-tp18701101p18718581.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 > > -- View this message in context: http://www.nabble.com/IAttributesInjector-tp18701101p18900900.html Sent from the IronPython mailing list archive at Nabble.com. From taozuhong at qq.com Sat Aug 9 09:08:08 2008 From: taozuhong at qq.com (=?ISO-8859-1?B?QW5keS5UYW8=?=) Date: Sat, 9 Aug 2008 15:08:08 +0800 Subject: [IronPython] Is there a way to create a new ScriptScope that inherits from global ScriptScope? Message-ID: HI guys, Is there a way to create a new ScriptScope that inherits from global ScriptScope? I want to do it like this: first step: expose some object model to global scope and some global variables; second step: execute task script in independ scope to avoid modify global objects and variables. thanks in advanced. ------------------ Andy Tao -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sat Aug 9 21:29:21 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 09 Aug 2008 20:29:21 +0100 Subject: [IronPython] IronPython 2.0B4 Docs Message-ID: <489DF011.3030400@voidspace.org.uk> Hello guys, Previous IronPython 2 releases have included a 'Docs' distribution which includes the 'Microsoft.Scripting.chm' document. This is missing from the 2.0B4 release. Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From seshapv at microsoft.com Sun Aug 10 06:18:29 2008 From: seshapv at microsoft.com (Seshadri Pillailokam Vijayaraghavan) Date: Sat, 9 Aug 2008 21:18:29 -0700 Subject: [IronPython] Is there a way to create a new ScriptScope that inherits from global ScriptScope? In-Reply-To: References: Message-ID: <4F06AAB8EC03C349A5D6D0A797C4881C40B5CB3729@NA-EXMSG-C112.redmond.corp.microsoft.com> Currently there isn't a way to create a new ScriptScope object based on an existing one. If I understand your query correctly, you can do what you want by iterating over the items of an existing object and copy them over the newer one as soon as your create a new one. Won't this work for you? ScriptScope newScope = _pyEng.CreateScope(); foreach (var item in existingScope.Items) { newScope.SetVariable(item.Key, item.Value); } Thanks sesh From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Andy.Tao Sent: Saturday, August 09, 2008 12:08 AM To: Users Subject: [IronPython] Is there a way to create a new ScriptScope that inherits from global ScriptScope? HI guys, Is there a way to create a new ScriptScope that inherits from global ScriptScope? I want to do it like this: first step: expose some object model to global scope and some global variables; second step: execute task script in independ scope to avoid modify global objects and variables. thanks in advanced. ------------------ Andy Tao -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Sun Aug 10 08:59:40 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Sat, 9 Aug 2008 23:59:40 -0700 Subject: [IronPython] Silverlight on the Codeplex Site In-Reply-To: <489CD44A.6000509@voidspace.org.uk> References: <489CD44A.6000509@voidspace.org.uk> Message-ID: Well, it did! Thanks for pointing that out; I've removed that now-useless bit of information. On Fri, Aug 8, 2008 at 4:18 PM, Michael Foord wrote: > The IronPython Codeplex site proudly announces: > > Silverlight v1.1 Alpha includes IronPython support! > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.theotherdelia.co.uk/ > http://www.resolverhacks.net/ > > _______________________________________________ > 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 huzi_1982 at hotmail.com Sun Aug 10 10:22:20 2008 From: huzi_1982 at hotmail.com (Huzaifa) Date: Sun, 10 Aug 2008 01:22:20 -0700 (PDT) Subject: [IronPython] System.Scripting.Runtime.UnboundNameException Message-ID: <18911599.post@talk.nabble.com> i am trying this code and it is giving me exception "$exception {"name 'name' is not defined"} System.Exception {System.Scripting.Runtime.UnboundNameException} " CODE: ScriptRuntime env = ScriptRuntime.Create ( ); ScriptScope defaultScope = env.CreateScope ( ); ScriptEngine curEngine = env.GetEngine ("py"); ScriptSource input; env.LoadAssembly (typeof (System.Diagnostics.Debug).Assembly); env.Globals.SetVariable("name","Huzaifa"); input = curEngine.CreateScriptSourceFromString ( @"import clr from System import * from System.Windows.Forms import * MessageBox.Show(name) ", SourceCodeKind.Statements); input.Execute (defaultScope); -- View this message in context: http://www.nabble.com/System.Scripting.Runtime.UnboundNameException-tp18911599p18911599.html Sent from the IronPython mailing list archive at Nabble.com. From curt at hagenlocher.org Sun Aug 10 10:31:46 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Sun, 10 Aug 2008 01:31:46 -0700 Subject: [IronPython] System.Scripting.Runtime.UnboundNameException In-Reply-To: <18911599.post@talk.nabble.com> References: <18911599.post@talk.nabble.com> Message-ID: A hosting API global is not the same as a Python global. After all, Python globals aren't really global; they're scoped to the module you're in. I can't provide sample code offhand, but to do what you want, you'll need to do something like the following steps: 1) Create an empty script scope 2) Set the "name" variable in that scope 3) Load your source into that already-created scope instead of creating a new one. There are probably better ways to structure this code, but it looks like you're just working out a test program so I won't be pedantic about it. In this sample code, you also haven't loaded System.Windows.Forms.dll; you can do that either through Python with clr.AddReference or from the hosting code with env.LoadAssembly. On Sun, Aug 10, 2008 at 1:22 AM, Huzaifa wrote: > > i am trying this code and it is giving me exception > "$exception {"name 'name' is not defined"} System.Exception > {System.Scripting.Runtime.UnboundNameException} > " > CODE: > > ScriptRuntime env = ScriptRuntime.Create ( ); > ScriptScope defaultScope = env.CreateScope ( ); > ScriptEngine curEngine = env.GetEngine ("py"); > ScriptSource input; > > env.LoadAssembly (typeof (System.Diagnostics.Debug).Assembly); > env.Globals.SetVariable("name","Huzaifa"); > > input = curEngine.CreateScriptSourceFromString ( > @"import clr > from System import * > from System.Windows.Forms import * > > MessageBox.Show(name) > ", SourceCodeKind.Statements); > > input.Execute (defaultScope); > > > -- > View this message in context: > http://www.nabble.com/System.Scripting.Runtime.UnboundNameException-tp18911599p18911599.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 r.worbis at cubido.at Sun Aug 10 17:21:37 2008 From: r.worbis at cubido.at (Rainer Worbis) Date: Sun, 10 Aug 2008 17:21:37 +0200 Subject: [IronPython] Is there a way to create a new ScriptScopethat inherits from global ScriptScope? In-Reply-To: <4F06AAB8EC03C349A5D6D0A797C4881C40B5CB3729@NA-EXMSG-C112.redmond.corp.microsoft.com> References: <4F06AAB8EC03C349A5D6D0A797C4881C40B5CB3729@NA-EXMSG-C112.redmond.corp.microsoft.com> Message-ID: <676F9CCC1D1D3242BE4B133746E3807E4F3FBC@XARA.cubido.linz> Hi, i had the same problem (hierarchical script scopes) and solved it by implementing my own SymbolDictionary (exactly BaseSymbolDictionary) So I can use the vars defined along the hierarchy like in scopes in c#. Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Seshadri Pillailokam Vijayaraghavan Gesendet: Sonntag, 10. August 2008 06:18 An: Discussion of IronPython Betreff: Re: [IronPython] Is there a way to create a new ScriptScopethat inherits from global ScriptScope? Currently there isn't a way to create a new ScriptScope object based on an existing one. If I understand your query correctly, you can do what you want by iterating over the items of an existing object and copy them over the newer one as soon as your create a new one. Won't this work for you? ScriptScope newScope = _pyEng.CreateScope(); foreach (var item in existingScope.Items) { newScope.SetVariable(item.Key, item.Value); } Thanks sesh From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Andy.Tao Sent: Saturday, August 09, 2008 12:08 AM To: Users Subject: [IronPython] Is there a way to create a new ScriptScope that inherits from global ScriptScope? HI guys, Is there a way to create a new ScriptScope that inherits from global ScriptScope? I want to do it like this: first step: expose some object model to global scope and some global variables; second step: execute task script in independ scope to avoid modify global objects and variables. thanks in advanced. ------------------ Andy Tao -------------- next part -------------- An HTML attachment was scrubbed... URL: From seshapv at microsoft.com Sun Aug 10 19:20:15 2008 From: seshapv at microsoft.com (Seshadri Pillailokam Vijayaraghavan) Date: Sun, 10 Aug 2008 10:20:15 -0700 Subject: [IronPython] System.Scripting.Runtime.UnboundNameException In-Reply-To: References: <18911599.post@talk.nabble.com> Message-ID: <4F06AAB8EC03C349A5D6D0A797C4881C532AD395D2@NA-EXMSG-C112.redmond.corp.microsoft.com> The following edit to your code snippet would give you what you want Comment out the current SetVariables call //env.Globals.SetVariable("name", "Huzaifa"); //Load the Forms assembly and set the variable in your defaultScope obj. env.LoadAssembly(typeof(System.Windows.Forms.MessageBox).Assembly); defaultScope.SetVariable("name", "Huzaifa"); From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Sunday, August 10, 2008 1:32 AM To: Discussion of IronPython Subject: Re: [IronPython] System.Scripting.Runtime.UnboundNameException A hosting API global is not the same as a Python global. After all, Python globals aren't really global; they're scoped to the module you're in. I can't provide sample code offhand, but to do what you want, you'll need to do something like the following steps: 1) Create an empty script scope 2) Set the "name" variable in that scope 3) Load your source into that already-created scope instead of creating a new one. There are probably better ways to structure this code, but it looks like you're just working out a test program so I won't be pedantic about it. In this sample code, you also haven't loaded System.Windows.Forms.dll; you can do that either through Python with clr.AddReference or from the hosting code with env.LoadAssembly. On Sun, Aug 10, 2008 at 1:22 AM, Huzaifa > wrote: i am trying this code and it is giving me exception "$exception {"name 'name' is not defined"} System.Exception {System.Scripting.Runtime.UnboundNameException} " CODE: ScriptRuntime env = ScriptRuntime.Create ( ); ScriptScope defaultScope = env.CreateScope ( ); ScriptEngine curEngine = env.GetEngine ("py"); ScriptSource input; env.LoadAssembly (typeof (System.Diagnostics.Debug).Assembly); env.Globals.SetVariable("name","Huzaifa"); input = curEngine.CreateScriptSourceFromString ( @"import clr from System import * from System.Windows.Forms import * MessageBox.Show(name) ", SourceCodeKind.Statements); input.Execute (defaultScope); -- View this message in context: http://www.nabble.com/System.Scripting.Runtime.UnboundNameException-tp18911599p18911599.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 dfugate at microsoft.com Sun Aug 10 20:29:01 2008 From: dfugate at microsoft.com (Dave Fugate) Date: Sun, 10 Aug 2008 11:29:01 -0700 Subject: [IronPython] IronPython 2.0B4 Docs In-Reply-To: <489DF011.3030400@voidspace.org.uk> References: <489DF011.3030400@voidspace.org.uk> Message-ID: Hi Michael, I knew we forgot to mention something in the release notes but just couldn't put my finger on it. Thanks for spotting this. The omission of IronPython-2.0B4-Doc.zip which included Microsoft.Scripting.chm from IP 2.0B4 was actually intentional. Microsoft.Scripting.chm has been out of date for some time, but more importantly contains documentation specific to the DLR that's not particularly useful to IronPython users (e.g., "Microsoft.Scripting.Ast" namespace). This API reference library hasn't disappeared entirely though - in the near future there's going to be a site for all things DLR... ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Michael Foord [fuzzyman at voidspace.org.uk] Sent: Saturday, August 09, 2008 12:29 PM To: Discussion of IronPython Subject: [IronPython] IronPython 2.0B4 Docs Hello guys, Previous IronPython 2 releases have included a 'Docs' distribution which includes the 'Microsoft.Scripting.chm' document. This is missing from the 2.0B4 release. Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Sun Aug 10 20:58:40 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 10 Aug 2008 19:58:40 +0100 Subject: [IronPython] IronPython 2.0B4 Docs In-Reply-To: References: <489DF011.3030400@voidspace.org.uk> Message-ID: <489F3A60.30908@voidspace.org.uk> Dave Fugate wrote: > Hi Michael, I knew we forgot to mention something in the release notes but just couldn't put my finger on it. Thanks for spotting this. > > Ok. Michael > The omission of IronPython-2.0B4-Doc.zip which included Microsoft.Scripting.chm from IP 2.0B4 was actually intentional. Microsoft.Scripting.chm has been out of date for some time, but more importantly contains documentation specific to the DLR that's not particularly useful to IronPython users (e.g., "Microsoft.Scripting.Ast" namespace). This API reference library hasn't disappeared entirely though - in the near future there's going to be a site for all things DLR... > > ________________________________________ > From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Michael Foord [fuzzyman at voidspace.org.uk] > Sent: Saturday, August 09, 2008 12:29 PM > To: Discussion of IronPython > Subject: [IronPython] IronPython 2.0B4 Docs > > Hello guys, > > Previous IronPython 2 releases have included a 'Docs' distribution which > includes the 'Microsoft.Scripting.chm' document. This is missing from > the 2.0B4 release. > > Michael Foord > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.theotherdelia.co.uk/ > http://www.resolverhacks.net/ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From petersonjm1 at gmail.com Mon Aug 11 13:39:10 2008 From: petersonjm1 at gmail.com (Joshua Peterson) Date: Mon, 11 Aug 2008 07:39:10 -0400 Subject: [IronPython] IronPython Studio with Visual Studio 2005 Message-ID: <2a03b9790808110439ib22814as9b663153a4f532d9@mail.gmail.com> Ideally, I would like to be able to debug IronPython code in Visual Studio 2005. I have used the IronPython integration sample in the Visual Studio 2005 SDK, although I have not had success deploying it as a stand-alone MSI package. So I was wondering if it is possible to integrate IronPython Studio with Visual Studio 2005. Has anyone attempted to use Iron Python Studio with Visual Studio 2005? Is his even an option? Are there older releases of IronPython Studio that work with Visual Studio 2005? Thanks. Josh -- Rejoice always. Pray without ceasing. In all circumstances give thanks, for this is the will of God for you in Christ Jesus. -- 1 Thes. 5:16-18 NAB -- I am the living bread that came down from heaven; whoever eats this bread will live forever; and the bread that I will give is my flesh for the life of the world. -- John 6:51 NAB -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian2.schmidt at gmx.de Mon Aug 11 13:41:50 2008 From: christian2.schmidt at gmx.de (Christian Schmidt) Date: Mon, 11 Aug 2008 13:41:50 +0200 Subject: [IronPython] IP 2: Execute multiple expression in different scopes Message-ID: <48A0257E.7030405@gmx.de> Hi, I'm trying to figure out the best way to embed IP 2 expressions into C# to implement the following: I have given a scope that consists of an IList and a mapping of the list's indices to a name. Now I want to evaluate several expressions within this scope. After this, the scope changes, but the mapping stays the same, only the IList changes. Then again the expressions are evaluated. What is the right way to do it? // Input IEnumerable> data = ... IList names = { "a", "b", "c" }; IList pyexpressions = { "a+b", "sqrt(b*c)" }; // expected Output delegate object MyEval(IList row); IList expressions; // IP 2 magic // ??? // Calculate foreach(IList row in data) foreach(MyEval expression in expressions) object obj = expression(row); // ... Thanks, Christian From fuzzyman at voidspace.org.uk Mon Aug 11 16:25:31 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 11 Aug 2008 15:25:31 +0100 Subject: [IronPython] IronPython Studio with Visual Studio 2005 In-Reply-To: <2a03b9790808110439ib22814as9b663153a4f532d9@mail.gmail.com> References: <2a03b9790808110439ib22814as9b663153a4f532d9@mail.gmail.com> Message-ID: <48A04BDB.3040204@voidspace.org.uk> Hello Joshua, The stand-alone Visual Studio packages use the Visual Studio shell, which is tied to Visual Studio 2008. IronPythonStudio can run integrated with Visual Studio, but because it uses the shell that means VS 2008 and not 2005. There is VS 2005 integration with IronPython through the SDK, but as you have discovered that isn't a standalone package (and requires VS 2005 Pro). So the short answer to your question is 'no' I'm afraid. Michael Joshua Peterson wrote: > Ideally, I would like to be able to debug IronPython code in Visual > Studio 2005. I have used the IronPython integration sample in the > Visual Studio 2005 SDK, although I have not had success deploying it > as a stand-alone MSI package. So I was wondering if it is possible to > integrate IronPython Studio with Visual Studio 2005. > > Has anyone attempted to use Iron Python Studio with Visual Studio > 2005? Is his even an option? Are there older releases of IronPython > Studio that work with Visual Studio 2005? Thanks. > > Josh > > -- > Rejoice always. Pray without ceasing. In all circumstances give > thanks, for this is the will of God for you in Christ Jesus. -- 1 > Thes. 5:16-18 NAB > -- > I am the living bread that came down from heaven; whoever eats this > bread will live forever; and the bread that I will give is my flesh > for the life of the world. -- John 6:51 NAB > ------------------------------------------------------------------------ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From petersonjm1 at gmail.com Mon Aug 11 16:38:25 2008 From: petersonjm1 at gmail.com (Joshua Peterson) Date: Mon, 11 Aug 2008 10:38:25 -0400 Subject: [IronPython] IronPython Studio with Visual Studio 2005 In-Reply-To: <48A04BDB.3040204@voidspace.org.uk> References: <2a03b9790808110439ib22814as9b663153a4f532d9@mail.gmail.com> <48A04BDB.3040204@voidspace.org.uk> Message-ID: <2a03b9790808110738y231c5259s58aacf6afa8c9e32@mail.gmail.com> Michael, Thanks for the information, I appreciate it. Josh On Mon, Aug 11, 2008 at 10:25 AM, Michael Foord wrote: > Hello Joshua, > > The stand-alone Visual Studio packages use the Visual Studio shell, which > is tied to Visual Studio 2008. IronPythonStudio can run integrated with > Visual Studio, but because it uses the shell that means VS 2008 and not > 2005. > > There is VS 2005 integration with IronPython through the SDK, but as you > have discovered that isn't a standalone package (and requires VS 2005 Pro). > > So the short answer to your question is 'no' I'm afraid. > > Michael > > Joshua Peterson wrote: > >> Ideally, I would like to be able to debug IronPython code in Visual Studio >> 2005. I have used the IronPython integration sample in the Visual Studio >> 2005 SDK, although I have not had success deploying it as a stand-alone MSI >> package. So I was wondering if it is possible to integrate IronPython >> Studio with Visual Studio 2005. >> >> Has anyone attempted to use Iron Python Studio with Visual Studio 2005? >> Is his even an option? Are there older releases of IronPython Studio that >> work with Visual Studio 2005? Thanks. >> >> Josh >> >> -- >> Rejoice always. Pray without ceasing. In all circumstances give thanks, >> for this is the will of God for you in Christ Jesus. -- 1 Thes. 5:16-18 NAB >> -- >> I am the living bread that came down from heaven; whoever eats this bread >> will live forever; and the bread that I will give is my flesh for the life >> of the world. -- John 6:51 NAB >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Rejoice always. Pray without ceasing. In all circumstances give thanks, for this is the will of God for you in Christ Jesus. -- 1 Thes. 5:16-18 NAB -- I am the living bread that came down from heaven; whoever eats this bread will live forever; and the bread that I will give is my flesh for the life of the world. -- John 6:51 NAB -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianhgross at gmail.com Mon Aug 11 17:34:34 2008 From: christianhgross at gmail.com (Christian Gross) Date: Mon, 11 Aug 2008 17:34:34 +0200 Subject: [IronPython] Creating Excel Add-in with Iron Python Message-ID: <48A05C0A.9010901@gmail.com> >Just starting to get into IronPython and have been poking around for the last few days; but I'm hoping someone can help. Basically, I want to take some python (IronPython) code, compile it to a dll (or xll?) and have it function like an add-in for excel. So, I could code functions in python and just call them as worksheet functions in excel. This is greatly preferable to writing VBA!! There are a couple of solutions. The first is ExcelDNA, which creates an XLL extension object based on a .NET class library. The second solution is Add-In express. Using the Add-in Express solution you can create any type of excel extension that will call into your Python class library. Though you might need to do some work to get everything to work out properly. I have used both and I like both. Christian From christianhgross at gmail.com Mon Aug 11 17:48:30 2008 From: christianhgross at gmail.com (Christian Gross) Date: Mon, 11 Aug 2008 17:48:30 +0200 Subject: [IronPython] Are there anyone had embedded IronPython or other dynamic language into a biz solution Message-ID: <48A05F4E.8020309@gmail.com> Hi A bit late, but I here goes. I write custom trading systems that use Excel as a Front End. These days my customers are pushing me further to create a backtesting platform, and optimization. This means I will be dealing with millions upon millions of records. My initial intention was to use Excel VBA, but for records in these dimensions it is simply not possible. With C# I can easily run through this code, but exposing a C# layer to my customers (eg NinjaTrader) is asking too much. Hence I chose IronPython. I had used it in the past and found it to be pretty good and did some initial integration tests and it worked out pretty well. Why Excel? After a very long and deliberate decision process I chose it because with Excel and IronPython a developer can extend their application to use TA-Lib, or QuantLib without having me to write an explicit layer. Simply put I can focus on the simulation, optimization, and strategy implementations. Christian Gross From daftspaniel at gmail.com Mon Aug 11 22:00:57 2008 From: daftspaniel at gmail.com (Davy Mitchell) Date: Mon, 11 Aug 2008 21:00:57 +0100 Subject: [IronPython] Documentation for CallTarget0 Message-ID: <20253b0c0808111300l48215587tfd034e46ad0f07ba@mail.gmail.com> Hi Folks, Sorry Google is failing me... is there Documentation for CallTarget0 somewhere? Thanks, Davy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Mon Aug 11 22:19:52 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Tue, 12 Aug 2008 05:19:52 +0900 Subject: [IronPython] Horrible performance regression of exec on IP2 Message-ID: <5b0248170808111319s16c46acdm4e70ac028238f267@mail.gmail.com> This is just to let you know that I filed a CodePlex issue on this topic. Please comment (and vote!) there. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17781 In particular, I am interested in the result of execfib.py on .NET. Current data is on Mono. -- Seo Sanghyeon From curt at hagenlocher.org Mon Aug 11 22:27:02 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 11 Aug 2008 13:27:02 -0700 Subject: [IronPython] Documentation for CallTarget0 In-Reply-To: <20253b0c0808111300l48215587tfd034e46ad0f07ba@mail.gmail.com> References: <20253b0c0808111300l48215587tfd034e46ad0f07ba@mail.gmail.com> Message-ID: It's defined in PythonCallTargets.cs; the definition is simply "public delegate object CallTarget0();". That is, it's a delegate with no arguments. On Mon, Aug 11, 2008 at 1:00 PM, Davy Mitchell wrote: > Hi Folks, > > Sorry Google is failing me... is there Documentation for CallTarget0 > somewhere? > > Thanks, > Davy > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Mon Aug 11 22:28:34 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 11 Aug 2008 13:28:34 -0700 Subject: [IronPython] Horrible performance regression of exec on IP2 In-Reply-To: <5b0248170808111319s16c46acdm4e70ac028238f267@mail.gmail.com> References: <5b0248170808111319s16c46acdm4e70ac028238f267@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222701336D9D53FE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> This is probably because we'll interpret code that is executed using exec. So anything very computationally heavy will be slow in exec. Maybe we need a way to disable that. If you want to see what it'd be like if we weren't interpreting you could use compile() first. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon Sent: Monday, August 11, 2008 1:20 PM To: users at lists.ironpython.com Subject: [IronPython] Horrible performance regression of exec on IP2 This is just to let you know that I filed a CodePlex issue on this topic. Please comment (and vote!) there. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17781 In particular, I am interested in the result of execfib.py on .NET. Current data is on Mono. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com Sample disclaimer text From Shri.Borde at microsoft.com Mon Aug 11 22:56:38 2008 From: Shri.Borde at microsoft.com (Shri Borde) Date: Mon, 11 Aug 2008 13:56:38 -0700 Subject: [IronPython] Horrible performance regression of exec on IP2 In-Reply-To: <7AD436E4270DD54A94238001769C222701336D9D5417@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <5b0248170808111319s16c46acdm4e70ac028238f267@mail.gmail.com> <7AD436E4270DD54A94238001769C222701336D9D53FE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4168443C59202E43A8B8CC579FE7F3140F8621B1F4@NA-EXMSG-C107.redmond.corp.microsoft.com> <7AD436E4270DD54A94238001769C222701336D9D5417@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4168443C59202E43A8B8CC579FE7F3140F8621B1FA@NA-EXMSG-C107.redmond.corp.microsoft.com> Done Thanks, Shri -----Original Message----- From: Dino Viehland Sent: Monday, August 11, 2008 1:54 PM To: Shri Borde Subject: RE: [IronPython] Horrible performance regression of exec on IP2 Sounds like a good plan - do you want to add those comments to the bug? :) -----Original Message----- From: Shri Borde Sent: Monday, August 11, 2008 1:53 PM To: Dino Viehland Subject: RE: [IronPython] Horrible performance regression of exec on IP2 I believe that when Jacob enabled interpretation for exec, we used to compile code for exec if it had loops in it. That code no longer seems to be around, and now we will interpret the same. We could put back that heuristic. It would not help with Seo's example as it has a recursive function definition, but we can add class and function definitions to the list of heuristics as well. We could restrict interpretation to straight line code consisting of statements - which would still satisfy the main scenario of good per fro exec/evaling of simple code snippets. Thanks, Shri -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, August 11, 2008 1:29 PM To: Discussion of IronPython Subject: Re: [IronPython] Horrible performance regression of exec on IP2 This is probably because we'll interpret code that is executed using exec. So anything very computationally heavy will be slow in exec. Maybe we need a way to disable that. If you want to see what it'd be like if we weren't interpreting you could use compile() first. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon Sent: Monday, August 11, 2008 1:20 PM To: users at lists.ironpython.com Subject: [IronPython] Horrible performance regression of exec on IP2 This is just to let you know that I filed a CodePlex issue on this topic. Please comment (and vote!) there. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17781 In particular, I am interested in the result of execfib.py on .NET. Current data is on Mono. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com Sample disclaimer text _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Mon Aug 11 22:59:32 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Tue, 12 Aug 2008 05:59:32 +0900 Subject: [IronPython] Horrible performance regression of exec on IP2 In-Reply-To: <7AD436E4270DD54A94238001769C222701336D9D53FE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <5b0248170808111319s16c46acdm4e70ac028238f267@mail.gmail.com> <7AD436E4270DD54A94238001769C222701336D9D53FE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <5b0248170808111359l23c9c7b9t4c4e862a745c0986@mail.gmail.com> 2008/8/12 Dino Viehland : > This is probably because we'll interpret code that is executed using exec. So anything very computationally heavy will be slow in exec. Maybe we need a way to disable that. Argh, I was using exec as a poor man's macro tool. Exactly computationally heavy code was roop-unrolled using exec. You can guess why I was very disappointed... -- Seo Sanghyeon From dinov at exchange.microsoft.com Mon Aug 11 23:01:11 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 11 Aug 2008 14:01:11 -0700 Subject: [IronPython] Horrible performance regression of exec on IP2 In-Reply-To: <5b0248170808111359l23c9c7b9t4c4e862a745c0986@mail.gmail.com> References: <5b0248170808111319s16c46acdm4e70ac028238f267@mail.gmail.com> <7AD436E4270DD54A94238001769C222701336D9D53FE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <5b0248170808111359l23c9c7b9t4c4e862a745c0986@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222701336D9D541B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Shri just suggested (off-line and on the bug) that we detect non-straight line code and actually compile it. We used to have logic around to do that so it shouldn't be too hard to bring it back and make this work more as expected :) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon Sent: Monday, August 11, 2008 2:00 PM To: Discussion of IronPython Subject: Re: [IronPython] Horrible performance regression of exec on IP2 2008/8/12 Dino Viehland : > This is probably because we'll interpret code that is executed using exec. So anything very computationally heavy will be slow in exec. Maybe we need a way to disable that. Argh, I was using exec as a poor man's macro tool. Exactly computationally heavy code was roop-unrolled using exec. You can guess why I was very disappointed... -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com Sample disclaimer text From Tomas.Matousek at microsoft.com Mon Aug 11 23:04:03 2008 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Mon, 11 Aug 2008 14:04:03 -0700 Subject: [IronPython] Horrible performance regression of exec on IP2 In-Reply-To: <4168443C59202E43A8B8CC579FE7F3140F8621B1FA@NA-EXMSG-C107.redmond.corp.microsoft.com> References: <5b0248170808111319s16c46acdm4e70ac028238f267@mail.gmail.com> <7AD436E4270DD54A94238001769C222701336D9D53FE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4168443C59202E43A8B8CC579FE7F3140F8621B1F4@NA-EXMSG-C107.redmond.corp.microsoft.com> <7AD436E4270DD54A94238001769C222701336D9D5417@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4168443C59202E43A8B8CC579FE7F3140F8621B1FA@NA-EXMSG-C107.redmond.corp.microsoft.com> Message-ID: The heuristics for function definitions won't actually be a good one. You actually *want* function and classes definitions to be evaluated since they are executed once unless you reload a module. We should really have a counter on methods that counts the number of calls and compile the code if the counter reaches some threshold. Tomas -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Shri Borde Sent: Monday, August 11, 2008 1:57 PM To: Dino Viehland; Discussion of IronPython Subject: Re: [IronPython] Horrible performance regression of exec on IP2 Done Thanks, Shri -----Original Message----- From: Dino Viehland Sent: Monday, August 11, 2008 1:54 PM To: Shri Borde Subject: RE: [IronPython] Horrible performance regression of exec on IP2 Sounds like a good plan - do you want to add those comments to the bug? :) -----Original Message----- From: Shri Borde Sent: Monday, August 11, 2008 1:53 PM To: Dino Viehland Subject: RE: [IronPython] Horrible performance regression of exec on IP2 I believe that when Jacob enabled interpretation for exec, we used to compile code for exec if it had loops in it. That code no longer seems to be around, and now we will interpret the same. We could put back that heuristic. It would not help with Seo's example as it has a recursive function definition, but we can add class and function definitions to the list of heuristics as well. We could restrict interpretation to straight line code consisting of statements - which would still satisfy the main scenario of good per fro exec/evaling of simple code snippets. Thanks, Shri -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, August 11, 2008 1:29 PM To: Discussion of IronPython Subject: Re: [IronPython] Horrible performance regression of exec on IP2 This is probably because we'll interpret code that is executed using exec. So anything very computationally heavy will be slow in exec. Maybe we need a way to disable that. If you want to see what it'd be like if we weren't interpreting you could use compile() first. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon Sent: Monday, August 11, 2008 1:20 PM To: users at lists.ironpython.com Subject: [IronPython] Horrible performance regression of exec on IP2 This is just to let you know that I filed a CodePlex issue on this topic. Please comment (and vote!) there. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17781 In particular, I am interested in the result of execfib.py on .NET. Current data is on Mono. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com Sample disclaimer text _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Mon Aug 11 23:07:00 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 11 Aug 2008 14:07:00 -0700 Subject: [IronPython] Horrible performance regression of exec on IP2 In-Reply-To: References: <5b0248170808111319s16c46acdm4e70ac028238f267@mail.gmail.com> <7AD436E4270DD54A94238001769C222701336D9D53FE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4168443C59202E43A8B8CC579FE7F3140F8621B1F4@NA-EXMSG-C107.redmond.corp.microsoft.com> <7AD436E4270DD54A94238001769C222701336D9D5417@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4168443C59202E43A8B8CC579FE7F3140F8621B1FA@NA-EXMSG-C107.redmond.corp.microsoft.com> Message-ID: <7AD436E4270DD54A94238001769C222701336D9D5424@DF-GRTDANE-MSG.exchange.corp.microsoft.com> My guess would be if a function is being defined in exec it's more likely to be used multiple times then if the code had no function definitions. It's probably a better heuristic then we have today (which is none) :) I agree we really need some hybrid interpretation/compile mode but that's not likely to happen in 2.0 :(. -----Original Message----- From: Tomas Matousek Sent: Monday, August 11, 2008 2:04 PM To: Discussion of IronPython; Dino Viehland Subject: RE: [IronPython] Horrible performance regression of exec on IP2 The heuristics for function definitions won't actually be a good one. You actually *want* function and classes definitions to be evaluated since they are executed once unless you reload a module. We should really have a counter on methods that counts the number of calls and compile the code if the counter reaches some threshold. Tomas -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Shri Borde Sent: Monday, August 11, 2008 1:57 PM To: Dino Viehland; Discussion of IronPython Subject: Re: [IronPython] Horrible performance regression of exec on IP2 Done Thanks, Shri -----Original Message----- From: Dino Viehland Sent: Monday, August 11, 2008 1:54 PM To: Shri Borde Subject: RE: [IronPython] Horrible performance regression of exec on IP2 Sounds like a good plan - do you want to add those comments to the bug? :) -----Original Message----- From: Shri Borde Sent: Monday, August 11, 2008 1:53 PM To: Dino Viehland Subject: RE: [IronPython] Horrible performance regression of exec on IP2 I believe that when Jacob enabled interpretation for exec, we used to compile code for exec if it had loops in it. That code no longer seems to be around, and now we will interpret the same. We could put back that heuristic. It would not help with Seo's example as it has a recursive function definition, but we can add class and function definitions to the list of heuristics as well. We could restrict interpretation to straight line code consisting of statements - which would still satisfy the main scenario of good per fro exec/evaling of simple code snippets. Thanks, Shri -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, August 11, 2008 1:29 PM To: Discussion of IronPython Subject: Re: [IronPython] Horrible performance regression of exec on IP2 This is probably because we'll interpret code that is executed using exec. So anything very computationally heavy will be slow in exec. Maybe we need a way to disable that. If you want to see what it'd be like if we weren't interpreting you could use compile() first. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon Sent: Monday, August 11, 2008 1:20 PM To: users at lists.ironpython.com Subject: [IronPython] Horrible performance regression of exec on IP2 This is just to let you know that I filed a CodePlex issue on this topic. Please comment (and vote!) there. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17781 In particular, I am interested in the result of execfib.py on .NET. Current data is on Mono. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com Sample disclaimer text _______________________________________________ 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 Sample disclaimer text From daftspaniel at gmail.com Tue Aug 12 08:41:41 2008 From: daftspaniel at gmail.com (Davy Mitchell) Date: Tue, 12 Aug 2008 07:41:41 +0100 Subject: [IronPython] Documentation for CallTarget0 In-Reply-To: References: <20253b0c0808111300l48215587tfd034e46ad0f07ba@mail.gmail.com> Message-ID: <20253b0c0808112341h4fcf5a68h68cbe3778d6bbff@mail.gmail.com> Thanks Curt. The sample I was looking at ( http://www.ironpython.info/index.php/Invoking_onto_the_GUI_(Control)_Thread) was using: from IronPython.Runtime.Calls import CallTarget0 Poking around IronPython assemblies I found the following worked on 2.0B4: import clr clr.AddReference('IronPython') from IronPython.Compiler import CallTarget0 Thanks, Davy Mitchell On Mon, Aug 11, 2008 at 9:27 PM, Curt Hagenlocher wrote: > It's defined in PythonCallTargets.cs; the definition is simply "public > delegate object CallTarget0();". That is, it's a delegate with no > arguments. > On Mon, Aug 11, 2008 at 1:00 PM, Davy Mitchell wrote: > >> Hi Folks, >> >> Sorry Google is failing me... is there Documentation for CallTarget0 >> somewhere? >> >> Thanks, >> Davy >> >> _______________________________________________ >> 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 ronnie.maor at gmail.com Tue Aug 12 22:09:35 2008 From: ronnie.maor at gmail.com (Ronnie Maor) Date: Tue, 12 Aug 2008 23:09:35 +0300 Subject: [IronPython] int64/long incompatibility in dictionary lookup Message-ID: <2fd6b9d0808121309y5b07dd79l8cf0c8f94e9003b8@mail.gmail.com> Hi all, is the following a known issue? >>> x = System.Int64(8591464408876390743) >>> y = long(x) >>> x == y True >>> d = {x:3} >>> d[x] 3 >>> d[y] Traceback (most recent call last): File "", line 1, in KeyError: 8591464408876390743 happens in both IPy 1.1.2 and 2.0b4 thanks Ronnie -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Tue Aug 12 22:34:57 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 12 Aug 2008 13:34:57 -0700 Subject: [IronPython] int64/long incompatibility in dictionary lookup In-Reply-To: <2fd6b9d0808121309y5b07dd79l8cf0c8f94e9003b8@mail.gmail.com> References: <2fd6b9d0808121309y5b07dd79l8cf0c8f94e9003b8@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222701336D9D5532@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I don't think it's a known issue - but it's because we don't have code that unifies the Int64's hashing w/ long's hashing though. We should probably add that for a smoother .NET interop story. I've filed this as CodePlex bug #17799 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17799). Thanks for the report. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ronnie Maor Sent: Tuesday, August 12, 2008 1:10 PM To: Discussion of IronPython Subject: [IronPython] int64/long incompatibility in dictionary lookup Hi all, is the following a known issue? >>> x = System.Int64(8591464408876390743) >>> y = long(x) >>> x == y True >>> d = {x:3} >>> d[x] 3 >>> d[y] Traceback (most recent call last): File "", line 1, in KeyError: 8591464408876390743 happens in both IPy 1.1.2 and 2.0b4 thanks Ronnie ________________________________ Sample disclaimer text -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronnie.maor at gmail.com Tue Aug 12 23:15:34 2008 From: ronnie.maor at gmail.com (Ronnie Maor) Date: Wed, 13 Aug 2008 00:15:34 +0300 Subject: [IronPython] int64/long incompatibility in dictionary lookup In-Reply-To: <7AD436E4270DD54A94238001769C222701336D9D5532@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <2fd6b9d0808121309y5b07dd79l8cf0c8f94e9003b8@mail.gmail.com> <7AD436E4270DD54A94238001769C222701336D9D5532@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <2fd6b9d0808121415x2dd09638p8274dbc7641d5808@mail.gmail.com> of course it's the hashing... in my defense it's past my bed time, so not thinking very clearly :-) we've changed the way we interact with NHibernate recently, and keep bumping into this issue now. The NHibernate domain objects are C# (NHibernate can't work with python objects), and we now cache them in some places by their Int64 IDs, so this happens a lot. We can work around it by casting to long, but it's very error prone, since we need to do it in several places. In short, would be very happy if you could unify the hashing for 2.0 thanks On Tue, Aug 12, 2008 at 11:34 PM, Dino Viehland < dinov at exchange.microsoft.com> wrote: > I don't think it's a known issue ? but it's because we don't have code > that unifies the Int64's hashing w/ long's hashing though. We should > probably add that for a smoother .NET interop story. > > > > I've filed this as CodePlex bug #17799 ( > http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17799). > Thanks for the report. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Ronnie Maor > *Sent:* Tuesday, August 12, 2008 1:10 PM > *To:* Discussion of IronPython > *Subject:* [IronPython] int64/long incompatibility in dictionary lookup > > > > Hi all, > > is the following a known issue? > > >>> x = System.Int64(8591464408876390743) > >>> y = long(x) > >>> x == y > True > >>> d = {x:3} > >>> d[x] > 3 > >>> d[y] > Traceback (most recent call last): > File "", line 1, in > KeyError: 8591464408876390743 > > happens in both IPy 1.1.2 and 2.0b4 > > thanks > Ronnie > > ------------------------------ > Sample disclaimer text > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Wed Aug 13 00:52:21 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 12 Aug 2008 15:52:21 -0700 Subject: [IronPython] int64/long incompatibility in dictionary lookup In-Reply-To: <2fd6b9d0808121415x2dd09638p8274dbc7641d5808@mail.gmail.com> References: <2fd6b9d0808121309y5b07dd79l8cf0c8f94e9003b8@mail.gmail.com> <7AD436E4270DD54A94238001769C222701336D9D5532@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <2fd6b9d0808121415x2dd09638p8274dbc7641d5808@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222701336D9D5568@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I strongly suspect we'll fix this for the next release. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ronnie Maor Sent: Tuesday, August 12, 2008 2:16 PM To: Discussion of IronPython Subject: Re: [IronPython] int64/long incompatibility in dictionary lookup of course it's the hashing... in my defense it's past my bed time, so not thinking very clearly :-) we've changed the way we interact with NHibernate recently, and keep bumping into this issue now. The NHibernate domain objects are C# (NHibernate can't work with python objects), and we now cache them in some places by their Int64 IDs, so this happens a lot. We can work around it by casting to long, but it's very error prone, since we need to do it in several places. In short, would be very happy if you could unify the hashing for 2.0 thanks On Tue, Aug 12, 2008 at 11:34 PM, Dino Viehland > wrote: I don't think it's a known issue - but it's because we don't have code that unifies the Int64's hashing w/ long's hashing though. We should probably add that for a smoother .NET interop story. I've filed this as CodePlex bug #17799 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17799). Thanks for the report. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ronnie Maor Sent: Tuesday, August 12, 2008 1:10 PM To: Discussion of IronPython Subject: [IronPython] int64/long incompatibility in dictionary lookup Hi all, is the following a known issue? >>> x = System.Int64(8591464408876390743) >>> y = long(x) >>> x == y True >>> d = {x:3} >>> d[x] 3 >>> d[y] Traceback (most recent call last): File "", line 1, in KeyError: 8591464408876390743 happens in both IPy 1.1.2 and 2.0b4 thanks Ronnie ________________________________ Sample disclaimer text _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ________________________________ Sample disclaimer text -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzonatas at dzonux.net Wed Aug 13 22:26:07 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Wed, 13 Aug 2008 13:26:07 -0700 Subject: [IronPython] Simple script to update nant build for 2.0B3+ Message-ID: <48A3435F.4030102@dzonux.net> I noticed with version 2.0B3 that a recursive options on the makefile and nant builds would not work since files had to be specifically included in the build. Attached is a build script to help update a nant build file from sources listed in the *.csprojs. It'll probably need to be updated with current build options, but at least it accomplishes the tedious part. This is based on a nant build file found at http://fepy.svn.sourceforge.net/viewvc/fepy/trunk/patches/latest/patch-nant-build?revision=588&view=markup I hope this script at least helps to build under Mono. -------------- next part -------------- A non-text attachment was scrubbed... Name: build.build.py Type: text/x-python Size: 4225 bytes Desc: not available URL: From dzonatas at dzonux.net Wed Aug 13 23:17:41 2008 From: dzonatas at dzonux.net (Dzonatas) Date: Wed, 13 Aug 2008 14:17:41 -0700 Subject: [IronPython] Simple script to update nant build for 2.0B3+ In-Reply-To: <48A3435F.4030102@dzonux.net> References: <48A3435F.4030102@dzonux.net> Message-ID: <48A34F75.2020203@dzonux.net> Looks like a hard indent got mixed in somehow, re-attaching to fix it. Dzonatas wrote: > I noticed with version 2.0B3 that a recursive options on the makefile > and nant builds would not work since files had to be specifically > included in the build. Attached is a build script to help update a > nant build file from sources listed in the *.csprojs. It'll probably > need to be updated with current build options, but at least it > accomplishes the tedious part. > > This is based on a nant build file found at > http://fepy.svn.sourceforge.net/viewvc/fepy/trunk/patches/latest/patch-nant-build?revision=588&view=markup > > > I hope this script at least helps to build under Mono. > -------------- next part -------------- A non-text attachment was scrubbed... Name: build.build.py Type: text/x-python Size: 4228 bytes Desc: not available URL: From michael.foord at resolversystems.com Thu Aug 14 15:15:03 2008 From: michael.foord at resolversystems.com (Michael Foord) Date: Thu, 14 Aug 2008 14:15:03 +0100 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 Message-ID: <48A42FD7.5090509@resolversystems.com> Hello all, I've ported Resolver One to run on IronPython 2 Beta 4 to check for any potential problems (we will only do a *proper* port once IP 2 is out of beta). The basic porting was straightforward and several bugs have been fixed since IP 2 B3 - many thanks to the IronPython team. The good news is that Resolver One is only 30-50% slower than Resolver One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) Resolver One is fairly heavily optimised around the performance hotspots of IronPython 1, so we expect to have to do a fair bit of profiling and refactoring to readjust to the performance profile of IP 2. Having said that, there are a few oddities (and the areas that slow down vary tremendously depending on which spreadsheet we use to benchmark it - making it fairly difficult to track down the hotspots). We have one particular phase of spreadsheet calculation that takes 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing some micro-benchmarking to try and identify the hotspot. I've certainly found part of the problem. For those that are interested I've attached the very basic microbenchmarks I've been using. The nice thing is that in *general* IP2 does outperform IP1. The results that stand out in the other direction are: Using sets with custom classes (that define '__eq__', '__ne__' and '__hash__') seems to be 6 times slower in IronPython 2. Adding lists together is about 50% slower. Defining functions seems to be 25% slower and defining old style classes about 33% slower. (Creating instances of new style classes is massively faster though - thanks!) The code I used to test sets (sets2.py) is as follows: from System import DateTime class Thing(object): def __init__(self, val): self.val = val def __eq__(self, other): return self.val == other.val def __neq__(self): return not self.__eq__(other) def __hash__(self): return hash(self.val) def test(s): a = set() for i in xrange(100000): a.add(Thing(i)) a.add(Thing(i+1)) Thing(i) in a Thing(i+2) in a return (DateTime.Now -s).TotalMilliseconds s = DateTime.Now print test(s) Interestingly the time taken is exactly the same if I remove the definition of '__hash__'. The full set of results below: Results in milliseconds with a granularity of about 15ms and so an accuracy of +/- ~60ms. All testing with 10 000 000 operations unless otherwise stated. Empty loop (overhead): IP1: 421.9 IP2: 438 Create instance newstyle: IP1: 20360 IP2: 1109 Create instance oldstyle: IP1: 3766 IP2: 3359 Function call: IP1: 937 IP2: 906 Create function: 25% slower IP1: 2828 IP2: 3640 Define newstyle (1 000 000): IP1: 42047 IP2: 20484 Define oldstyle (1 000 000): 33% slower IP1: 1781 IP2: 2671 Comparing (== and !=): IP1: 278597 IP2: 117662 Sets (with numbers): IP1: 37095 IP2: 30860 Lists (10 000): 50% slower IP1: 10422 IP2: 16109 Recursion (10 000): IP1: 1125 IP2: 1000 Sets2 (100 000): 600% slower IP1: 4984 IP2: 30547 I'll be doing more as the 600% slow down for sets and the 50% slow down for lists accounts for some of the dependency analysis problem but not all of it. Many Thanks Michael Foord -- http://www.resolversystems.com http://www.ironpythoninaction.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: comparing.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: createfunction.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: createnewstyle.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: createoldstyle.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: definenewstyle.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: defineoldstyle.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: emptytest.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: functioncall.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lists.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: recursion.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sets2.py URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sets.py URL: From fuzzyman at voidspace.org.uk Thu Aug 14 16:16:37 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 14 Aug 2008 15:16:37 +0100 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <48A42FD7.5090509@resolversystems.com> References: <48A42FD7.5090509@resolversystems.com> Message-ID: <48A43E45.4060300@voidspace.org.uk> It looks like 2-3 seconds of the 5-6 seconds slowdown in dependency analysis is due to the way I resolved a weird cyclic import problem (one that we didn't have in IP1 but due to the spaghetti like imports in that part of our code I can't reproduce on its own with IP2). I moved an import into the body of a function that is used heavily - moving that and resolving the problem another way saves about 2-3 seconds. In IronPython (1 & 2) reimporting a module that has already been imported is much more expensive than in CPython. That now accounts for almost all of the extra time in the dependency analysis - now onto tracking down what looks like overhead in our main execution loop. (Executing the spreadsheet code itself is no slower in IP2 but the framework around it seems to be suffering.) Michael Michael Foord wrote: > Hello all, > > I've ported Resolver One to run on IronPython 2 Beta 4 to check for > any potential problems (we will only do a *proper* port once IP 2 is > out of beta). > > The basic porting was straightforward and several bugs have been fixed > since IP 2 B3 - many thanks to the IronPython team. > > The good news is that Resolver One is only 30-50% slower than Resolver > One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) > Resolver One is fairly heavily optimised around the performance > hotspots of IronPython 1, so we expect to have to do a fair bit of > profiling and refactoring to readjust to the performance profile of IP 2. > > Having said that, there are a few oddities (and the areas that slow > down vary tremendously depending on which spreadsheet we use to > benchmark it - making it fairly difficult to track down the hotspots). > > We have one particular phase of spreadsheet calculation that takes > 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing > some micro-benchmarking to try and identify the hotspot. I've > certainly found part of the problem. > > For those that are interested I've attached the very basic > microbenchmarks I've been using. The nice thing is that in *general* > IP2 does outperform IP1. > > The results that stand out in the other direction are: > > Using sets with custom classes (that define '__eq__', '__ne__' and > '__hash__') seems to be 6 times slower in IronPython 2. > > Adding lists together is about 50% slower. > > Defining functions seems to be 25% slower and defining old style > classes about 33% slower. (Creating instances of new style classes is > massively faster though - thanks!) > > The code I used to test sets (sets2.py) is as follows: > > from System import DateTime > > class Thing(object): > def __init__(self, val): > self.val = val > def __eq__(self, other): > return self.val == other.val > > def __neq__(self): > return not self.__eq__(other) > def __hash__(self): > return hash(self.val) > def test(s): > a = set() > for i in xrange(100000): > a.add(Thing(i)) > a.add(Thing(i+1)) > Thing(i) in a > Thing(i+2) in a > return (DateTime.Now -s).TotalMilliseconds > s = DateTime.Now > print test(s) > > > Interestingly the time taken is exactly the same if I remove the > definition of '__hash__'. > > The full set of results below: > > Results in milliseconds with a granularity of about 15ms and so an > accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > Empty loop (overhead): > IP1: 421.9 > IP2: 438 > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Function call: > IP1: 937 > IP2: 906 > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Sets (with numbers): > IP1: 37095 > IP2: 30860 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > > Sets2 (100 000): 600% slower > IP1: 4984 > IP2: 30547 > > > I'll be doing more as the 600% slow down for sets and the 50% slow > down for lists accounts for some of the dependency analysis problem > but not all of it. > > Many Thanks > > Michael Foord > -- > http://www.resolversystems.com > 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/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From fuzzyman at voidspace.org.uk Thu Aug 14 16:45:42 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 14 Aug 2008 15:45:42 +0100 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <48A42FD7.5090509@resolversystems.com> References: <48A42FD7.5090509@resolversystems.com> Message-ID: <48A44516.9060700@voidspace.org.uk> It looks like I've found the slowdown in our execution framework. It is caused by extra overhead in the IronPython engine API. If I created a compiled code object and execute it in a module with IronPython 1 a million times (code shown below) - it takes 1.5 seconds. The equivalent (please check the code in case it *isn't* the equivalent) takes 115 seconds in IronPython 2! IP1 code: from System import DateTime import clr clr.AddReference('IronPython') from IronPython.Hosting import PythonEngine engine = PythonEngine() engine.DefaultModule.Globals['__name__'] = '__main__' module = engine.DefaultModule code = 'a = 3\nb = a\n' compiled = engine.Compile(code, 'module') def test(s): for i in xrange(1000000): compiled.Execute(module) return (DateTime.Now - s).TotalMilliseconds print test(DateTime.Now) Equivalent for IronPython 2: from System import DateTime import clr clr.AddReference('Microsoft.Scripting') clr.AddReference('Microsoft.Scripting.Core') from System.Scripting import SourceCodeKind from Microsoft.Scripting.Hosting import ScriptRuntime runtime = ScriptRuntime.Create() engine = runtime.GetEngine("py") scope = engine.CreateScope() scope.SetVariable('__name__', '__main__') code = 'a = 3\nb = a\n' source = engine.CreateScriptSourceFromString(code, SourceCodeKind.Statements) compiled = source.Compile() def test(s): for i in xrange(1000000): compiled.Execute(scope) return (DateTime.Now - s).TotalMilliseconds print test(DateTime.Now) If there is a better way to do this in IP 2 then please let me know... :-) Michael Michael Foord wrote: > Hello all, > > I've ported Resolver One to run on IronPython 2 Beta 4 to check for > any potential problems (we will only do a *proper* port once IP 2 is > out of beta). > > The basic porting was straightforward and several bugs have been fixed > since IP 2 B3 - many thanks to the IronPython team. > > The good news is that Resolver One is only 30-50% slower than Resolver > One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) > Resolver One is fairly heavily optimised around the performance > hotspots of IronPython 1, so we expect to have to do a fair bit of > profiling and refactoring to readjust to the performance profile of IP 2. > > Having said that, there are a few oddities (and the areas that slow > down vary tremendously depending on which spreadsheet we use to > benchmark it - making it fairly difficult to track down the hotspots). > > We have one particular phase of spreadsheet calculation that takes > 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing > some micro-benchmarking to try and identify the hotspot. I've > certainly found part of the problem. > > For those that are interested I've attached the very basic > microbenchmarks I've been using. The nice thing is that in *general* > IP2 does outperform IP1. > > The results that stand out in the other direction are: > > Using sets with custom classes (that define '__eq__', '__ne__' and > '__hash__') seems to be 6 times slower in IronPython 2. > > Adding lists together is about 50% slower. > > Defining functions seems to be 25% slower and defining old style > classes about 33% slower. (Creating instances of new style classes is > massively faster though - thanks!) > > The code I used to test sets (sets2.py) is as follows: > > from System import DateTime > > class Thing(object): > def __init__(self, val): > self.val = val > def __eq__(self, other): > return self.val == other.val > > def __neq__(self): > return not self.__eq__(other) > def __hash__(self): > return hash(self.val) > def test(s): > a = set() > for i in xrange(100000): > a.add(Thing(i)) > a.add(Thing(i+1)) > Thing(i) in a > Thing(i+2) in a > return (DateTime.Now -s).TotalMilliseconds > s = DateTime.Now > print test(s) > > > Interestingly the time taken is exactly the same if I remove the > definition of '__hash__'. > > The full set of results below: > > Results in milliseconds with a granularity of about 15ms and so an > accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > Empty loop (overhead): > IP1: 421.9 > IP2: 438 > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Function call: > IP1: 937 > IP2: 906 > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Sets (with numbers): > IP1: 37095 > IP2: 30860 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > > Sets2 (100 000): 600% slower > IP1: 4984 > IP2: 30547 > > > I'll be doing more as the 600% slow down for sets and the 50% slow > down for lists accounts for some of the dependency analysis problem > but not all of it. > > Many Thanks > > Michael Foord > -- > http://www.resolversystems.com > 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/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From fuzzyman at voidspace.org.uk Thu Aug 14 16:48:04 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 14 Aug 2008 15:48:04 +0100 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <48A44516.9060700@voidspace.org.uk> References: <48A42FD7.5090509@resolversystems.com> <48A44516.9060700@voidspace.org.uk> Message-ID: <48A445A4.2070300@voidspace.org.uk> Oh - plus it looks like exception handling is about 40% slower in IronPython 2: from System import DateTime class CustomError(Exception): pass def test(s): for i in xrange(100000): try: raise CustomError('ow') except CustomError, e: pass return (DateTime.Now - s).TotalMilliseconds print test(DateTime.Now) IP1: 4703ms IP2: 6125ms Michael Michael Foord wrote: > It looks like I've found the slowdown in our execution framework. It > is caused by extra overhead in the IronPython engine API. > > If I created a compiled code object and execute it in a module with > IronPython 1 a million times (code shown below) - it takes 1.5 seconds. > > The equivalent (please check the code in case it *isn't* the > equivalent) takes 115 seconds in IronPython 2! > > IP1 code: > from System import DateTime > import clr > clr.AddReference('IronPython') > from IronPython.Hosting import PythonEngine > engine = PythonEngine() > engine.DefaultModule.Globals['__name__'] = '__main__' > module = engine.DefaultModule > > code = 'a = 3\nb = a\n' > compiled = engine.Compile(code, 'module') > > def test(s): > for i in xrange(1000000): > compiled.Execute(module) > return (DateTime.Now - s).TotalMilliseconds > print test(DateTime.Now) > > > > Equivalent for IronPython 2: > > from System import DateTime > import clr > clr.AddReference('Microsoft.Scripting') > clr.AddReference('Microsoft.Scripting.Core') > from System.Scripting import SourceCodeKind > from Microsoft.Scripting.Hosting import ScriptRuntime > > runtime = ScriptRuntime.Create() > engine = runtime.GetEngine("py") > scope = engine.CreateScope() > > scope.SetVariable('__name__', '__main__') > > code = 'a = 3\nb = a\n' > source = engine.CreateScriptSourceFromString(code, > SourceCodeKind.Statements) > compiled = source.Compile() > > def test(s): > for i in xrange(1000000): > compiled.Execute(scope) > return (DateTime.Now - s).TotalMilliseconds > print test(DateTime.Now) > > > If there is a better way to do this in IP 2 then please let me know... > :-) > > Michael > > > Michael Foord wrote: >> Hello all, >> >> I've ported Resolver One to run on IronPython 2 Beta 4 to check for >> any potential problems (we will only do a *proper* port once IP 2 is >> out of beta). >> >> The basic porting was straightforward and several bugs have been >> fixed since IP 2 B3 - many thanks to the IronPython team. >> >> The good news is that Resolver One is only 30-50% slower than >> Resolver One on IronPython 1! (It was 300 - 400% slower on top of IP >> 2 B3.) Resolver One is fairly heavily optimised around the >> performance hotspots of IronPython 1, so we expect to have to do a >> fair bit of profiling and refactoring to readjust to the performance >> profile of IP 2. >> >> Having said that, there are a few oddities (and the areas that slow >> down vary tremendously depending on which spreadsheet we use to >> benchmark it - making it fairly difficult to track down the hotspots). >> >> We have one particular phase of spreadsheet calculation that takes >> 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing >> some micro-benchmarking to try and identify the hotspot. I've >> certainly found part of the problem. >> >> For those that are interested I've attached the very basic >> microbenchmarks I've been using. The nice thing is that in *general* >> IP2 does outperform IP1. >> >> The results that stand out in the other direction are: >> >> Using sets with custom classes (that define '__eq__', '__ne__' and >> '__hash__') seems to be 6 times slower in IronPython 2. >> >> Adding lists together is about 50% slower. >> >> Defining functions seems to be 25% slower and defining old style >> classes about 33% slower. (Creating instances of new style classes is >> massively faster though - thanks!) >> >> The code I used to test sets (sets2.py) is as follows: >> >> from System import DateTime >> >> class Thing(object): >> def __init__(self, val): >> self.val = val >> def __eq__(self, other): >> return self.val == other.val >> >> def __neq__(self): >> return not self.__eq__(other) >> def __hash__(self): >> return hash(self.val) >> def test(s): >> a = set() >> for i in xrange(100000): >> a.add(Thing(i)) >> a.add(Thing(i+1)) >> Thing(i) in a >> Thing(i+2) in a >> return (DateTime.Now -s).TotalMilliseconds >> s = DateTime.Now >> print test(s) >> >> >> Interestingly the time taken is exactly the same if I remove the >> definition of '__hash__'. >> >> The full set of results below: >> >> Results in milliseconds with a granularity of about 15ms and so an >> accuracy of +/- ~60ms. >> All testing with 10 000 000 operations unless otherwise stated. >> >> Empty loop (overhead): >> IP1: 421.9 >> IP2: 438 >> Create instance newstyle: >> IP1: 20360 >> IP2: 1109 >> Create instance oldstyle: >> IP1: 3766 >> IP2: 3359 >> Function call: >> IP1: 937 >> IP2: 906 >> Create function: 25% slower >> IP1: 2828 >> IP2: 3640 >> Define newstyle (1 000 000): >> IP1: 42047 >> IP2: 20484 >> Define oldstyle (1 000 000): 33% slower >> IP1: 1781 >> IP2: 2671 >> >> Comparing (== and !=): >> IP1: 278597 >> IP2: 117662 >> Sets (with numbers): >> IP1: 37095 >> IP2: 30860 >> >> Lists (10 000): 50% slower >> IP1: 10422 >> IP2: 16109 >> >> Recursion (10 000): >> IP1: 1125 >> IP2: 1000 >> >> Sets2 (100 000): 600% slower >> IP1: 4984 >> IP2: 30547 >> >> >> I'll be doing more as the 600% slow down for sets and the 50% slow >> down for lists accounts for some of the dependency analysis problem >> but not all of it. >> >> Many Thanks >> >> Michael Foord >> -- >> http://www.resolversystems.com >> 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/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From fuzzyman at voidspace.org.uk Thu Aug 14 18:41:56 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 14 Aug 2008 17:41:56 +0100 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <48A42FD7.5090509@resolversystems.com> References: <48A42FD7.5090509@resolversystems.com> Message-ID: <48A46054.2040600@voidspace.org.uk> Just for fun I also compared with CPython. The results are interesting, I'll turn it into a blog post of course... Results in milliseconds with a granularity of about 15ms and so an accuracy of +/- ~60ms. All testing with 10 000 000 operations unless otherwise stated. The version of Python I compared against was Python 2.4. Empty loop (overhead): IP1: 422 IP2: 438 Py: 3578 Create instance newstyle: IP1: 20360 IP2: 1109 Py: 4063 Create instance oldstyle: IP1: 3766 IP2: 3359 Py: 4797 Function call: IP1: 937 IP2: 906 Py: 3313 Create function: 25% slower IP1: 2828 IP2: 3640 Py: 2766 Define newstyle (1 000 000): IP1: 42047 IP2: 20484 Py: 23921 Define oldstyle (1 000 000): 33% slower IP1: 1781 IP2: 2671 Py: 2108 Comparing (== and !=): IP1: 278597 IP2: 117662 Py: 62423 Sets: IP1: 37095 IP2: 30860 Py: 8047 Lists (10 000): 50% slower IP1: 10422 IP2: 16109 Py: 6094 Recursion (10 000): IP1: 1125 IP2: 1000 Py: 3609 Sets2 (100 000): 500% slower IP1: 4984 IP2: 30547 Py: 1203 func_with_args: IP1: 6312 IP2: 5906 Py: 11250 method_with_args: IP1: 20594 IP2: 11813 Py: 14875 method_with_kwargs: IP1: 27953 IP2: 11187 Py: 20032 import: 15% slower IP1: 28469 IP2: 32000 Py: 25782 global: 20% slower IP1: 1047 IP2: 1203 Py: 4141 Exceptions (100000): 40% slower IP1: 4703 IP2: 6125 Py: 266 Engine execution: 8000% slower!! IP1: 1600 IP2: 115002 Michael Foord wrote: > Hello all, > > I've ported Resolver One to run on IronPython 2 Beta 4 to check for > any potential problems (we will only do a *proper* port once IP 2 is > out of beta). > > The basic porting was straightforward and several bugs have been fixed > since IP 2 B3 - many thanks to the IronPython team. > > The good news is that Resolver One is only 30-50% slower than Resolver > One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) > Resolver One is fairly heavily optimised around the performance > hotspots of IronPython 1, so we expect to have to do a fair bit of > profiling and refactoring to readjust to the performance profile of IP 2. > > Having said that, there are a few oddities (and the areas that slow > down vary tremendously depending on which spreadsheet we use to > benchmark it - making it fairly difficult to track down the hotspots). > > We have one particular phase of spreadsheet calculation that takes > 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing > some micro-benchmarking to try and identify the hotspot. I've > certainly found part of the problem. > > For those that are interested I've attached the very basic > microbenchmarks I've been using. The nice thing is that in *general* > IP2 does outperform IP1. > > The results that stand out in the other direction are: > > Using sets with custom classes (that define '__eq__', '__ne__' and > '__hash__') seems to be 6 times slower in IronPython 2. > > Adding lists together is about 50% slower. > > Defining functions seems to be 25% slower and defining old style > classes about 33% slower. (Creating instances of new style classes is > massively faster though - thanks!) > > The code I used to test sets (sets2.py) is as follows: > > from System import DateTime > > class Thing(object): > def __init__(self, val): > self.val = val > def __eq__(self, other): > return self.val == other.val > > def __neq__(self): > return not self.__eq__(other) > def __hash__(self): > return hash(self.val) > def test(s): > a = set() > for i in xrange(100000): > a.add(Thing(i)) > a.add(Thing(i+1)) > Thing(i) in a > Thing(i+2) in a > return (DateTime.Now -s).TotalMilliseconds > s = DateTime.Now > print test(s) > > > Interestingly the time taken is exactly the same if I remove the > definition of '__hash__'. > > The full set of results below: > > Results in milliseconds with a granularity of about 15ms and so an > accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > Empty loop (overhead): > IP1: 421.9 > IP2: 438 > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Function call: > IP1: 937 > IP2: 906 > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Sets (with numbers): > IP1: 37095 > IP2: 30860 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > > Sets2 (100 000): 600% slower > IP1: 4984 > IP2: 30547 > > > I'll be doing more as the 600% slow down for sets and the 50% slow > down for lists accounts for some of the dependency analysis problem > but not all of it. > > Many Thanks > > Michael Foord > -- > http://www.resolversystems.com > 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/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ip2tests.zip Type: application/octet-stream Size: 7272 bytes Desc: not available URL: From dinov at exchange.microsoft.com Thu Aug 14 18:43:10 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 14 Aug 2008 09:43:10 -0700 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <48A42FD7.5090509@resolversystems.com> References: <48A42FD7.5090509@resolversystems.com> Message-ID: <7AD436E4270DD54A94238001769C222701336E4BA76C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Awesome information! I'll start taking a look through all of this and let you know what I can improve. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, August 14, 2008 6:15 AM To: Discussion of IronPython Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 Hello all, I've ported Resolver One to run on IronPython 2 Beta 4 to check for any potential problems (we will only do a *proper* port once IP 2 is out of beta). The basic porting was straightforward and several bugs have been fixed since IP 2 B3 - many thanks to the IronPython team. The good news is that Resolver One is only 30-50% slower than Resolver One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) Resolver One is fairly heavily optimised around the performance hotspots of IronPython 1, so we expect to have to do a fair bit of profiling and refactoring to readjust to the performance profile of IP 2. Having said that, there are a few oddities (and the areas that slow down vary tremendously depending on which spreadsheet we use to benchmark it - making it fairly difficult to track down the hotspots). We have one particular phase of spreadsheet calculation that takes 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing some micro-benchmarking to try and identify the hotspot. I've certainly found part of the problem. For those that are interested I've attached the very basic microbenchmarks I've been using. The nice thing is that in *general* IP2 does outperform IP1. The results that stand out in the other direction are: Using sets with custom classes (that define '__eq__', '__ne__' and '__hash__') seems to be 6 times slower in IronPython 2. Adding lists together is about 50% slower. Defining functions seems to be 25% slower and defining old style classes about 33% slower. (Creating instances of new style classes is massively faster though - thanks!) The code I used to test sets (sets2.py) is as follows: from System import DateTime class Thing(object): def __init__(self, val): self.val = val def __eq__(self, other): return self.val == other.val def __neq__(self): return not self.__eq__(other) def __hash__(self): return hash(self.val) def test(s): a = set() for i in xrange(100000): a.add(Thing(i)) a.add(Thing(i+1)) Thing(i) in a Thing(i+2) in a return (DateTime.Now -s).TotalMilliseconds s = DateTime.Now print test(s) Interestingly the time taken is exactly the same if I remove the definition of '__hash__'. The full set of results below: Results in milliseconds with a granularity of about 15ms and so an accuracy of +/- ~60ms. All testing with 10 000 000 operations unless otherwise stated. Empty loop (overhead): IP1: 421.9 IP2: 438 Create instance newstyle: IP1: 20360 IP2: 1109 Create instance oldstyle: IP1: 3766 IP2: 3359 Function call: IP1: 937 IP2: 906 Create function: 25% slower IP1: 2828 IP2: 3640 Define newstyle (1 000 000): IP1: 42047 IP2: 20484 Define oldstyle (1 000 000): 33% slower IP1: 1781 IP2: 2671 Comparing (== and !=): IP1: 278597 IP2: 117662 Sets (with numbers): IP1: 37095 IP2: 30860 Lists (10 000): 50% slower IP1: 10422 IP2: 16109 Recursion (10 000): IP1: 1125 IP2: 1000 Sets2 (100 000): 600% slower IP1: 4984 IP2: 30547 I'll be doing more as the 600% slow down for sets and the 50% slow down for lists accounts for some of the dependency analysis problem but not all of it. Many Thanks Michael Foord -- http://www.resolversystems.com http://www.ironpythoninaction.com Sample disclaimer text From curt at hagenlocher.org Thu Aug 14 18:50:11 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 14 Aug 2008 09:50:11 -0700 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <48A46054.2040600@voidspace.org.uk> References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> Message-ID: On Thu, Aug 14, 2008 at 9:41 AM, Michael Foord wrote: > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Py: 23921 > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > Py: 2108 We're trying to encourage people to use new-style classes so that they're better prepared for Python 3.0. *wink* -- Curt Hagenlocher curt at hagenlocher.org From dinov at exchange.microsoft.com Thu Aug 14 19:50:08 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 14 Aug 2008 10:50:08 -0700 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <48A46054.2040600@voidspace.org.uk> References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222701336E4BA78D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> BTW time.clock() is what I usually use to measure which works on both CPython and IronPython. On Ipy we use the .NET Stopwatch class which uses a high resolution counter if it's available. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, August 14, 2008 9:42 AM To: Discussion of IronPython Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 Just for fun I also compared with CPython. The results are interesting, I'll turn it into a blog post of course... Results in milliseconds with a granularity of about 15ms and so an accuracy of +/- ~60ms. All testing with 10 000 000 operations unless otherwise stated. The version of Python I compared against was Python 2.4. Empty loop (overhead): IP1: 422 IP2: 438 Py: 3578 Create instance newstyle: IP1: 20360 IP2: 1109 Py: 4063 Create instance oldstyle: IP1: 3766 IP2: 3359 Py: 4797 Function call: IP1: 937 IP2: 906 Py: 3313 Create function: 25% slower IP1: 2828 IP2: 3640 Py: 2766 Define newstyle (1 000 000): IP1: 42047 IP2: 20484 Py: 23921 Define oldstyle (1 000 000): 33% slower IP1: 1781 IP2: 2671 Py: 2108 Comparing (== and !=): IP1: 278597 IP2: 117662 Py: 62423 Sets: IP1: 37095 IP2: 30860 Py: 8047 Lists (10 000): 50% slower IP1: 10422 IP2: 16109 Py: 6094 Recursion (10 000): IP1: 1125 IP2: 1000 Py: 3609 Sets2 (100 000): 500% slower IP1: 4984 IP2: 30547 Py: 1203 func_with_args: IP1: 6312 IP2: 5906 Py: 11250 method_with_args: IP1: 20594 IP2: 11813 Py: 14875 method_with_kwargs: IP1: 27953 IP2: 11187 Py: 20032 import: 15% slower IP1: 28469 IP2: 32000 Py: 25782 global: 20% slower IP1: 1047 IP2: 1203 Py: 4141 Exceptions (100000): 40% slower IP1: 4703 IP2: 6125 Py: 266 Engine execution: 8000% slower!! IP1: 1600 IP2: 115002 Michael Foord wrote: > Hello all, > > I've ported Resolver One to run on IronPython 2 Beta 4 to check for > any potential problems (we will only do a *proper* port once IP 2 is > out of beta). > > The basic porting was straightforward and several bugs have been fixed > since IP 2 B3 - many thanks to the IronPython team. > > The good news is that Resolver One is only 30-50% slower than Resolver > One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) > Resolver One is fairly heavily optimised around the performance > hotspots of IronPython 1, so we expect to have to do a fair bit of > profiling and refactoring to readjust to the performance profile of IP 2. > > Having said that, there are a few oddities (and the areas that slow > down vary tremendously depending on which spreadsheet we use to > benchmark it - making it fairly difficult to track down the hotspots). > > We have one particular phase of spreadsheet calculation that takes > 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing > some micro-benchmarking to try and identify the hotspot. I've > certainly found part of the problem. > > For those that are interested I've attached the very basic > microbenchmarks I've been using. The nice thing is that in *general* > IP2 does outperform IP1. > > The results that stand out in the other direction are: > > Using sets with custom classes (that define '__eq__', '__ne__' and > '__hash__') seems to be 6 times slower in IronPython 2. > > Adding lists together is about 50% slower. > > Defining functions seems to be 25% slower and defining old style > classes about 33% slower. (Creating instances of new style classes is > massively faster though - thanks!) > > The code I used to test sets (sets2.py) is as follows: > > from System import DateTime > > class Thing(object): > def __init__(self, val): > self.val = val > def __eq__(self, other): > return self.val == other.val > > def __neq__(self): > return not self.__eq__(other) > def __hash__(self): > return hash(self.val) > def test(s): > a = set() > for i in xrange(100000): > a.add(Thing(i)) > a.add(Thing(i+1)) > Thing(i) in a > Thing(i+2) in a > return (DateTime.Now -s).TotalMilliseconds > s = DateTime.Now > print test(s) > > > Interestingly the time taken is exactly the same if I remove the > definition of '__hash__'. > > The full set of results below: > > Results in milliseconds with a granularity of about 15ms and so an > accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > Empty loop (overhead): > IP1: 421.9 > IP2: 438 > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Function call: > IP1: 937 > IP2: 906 > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Sets (with numbers): > IP1: 37095 > IP2: 30860 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > > Sets2 (100 000): 600% slower > IP1: 4984 > IP2: 30547 > > > I'll be doing more as the 600% slow down for sets and the 50% slow > down for lists accounts for some of the dependency analysis problem > but not all of it. > > Many Thanks > > Michael Foord > -- > http://www.resolversystems.com > 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/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ Sample disclaimer text From sanxiyn at gmail.com Thu Aug 14 20:01:36 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Fri, 15 Aug 2008 03:01:36 +0900 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <7AD436E4270DD54A94238001769C222701336E4BA78D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> <7AD436E4270DD54A94238001769C222701336E4BA78D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <5b0248170808141101i3dfba005me5f9aa9d605c5249@mail.gmail.com> 2008/8/15 Dino Viehland : > BTW time.clock() is what I usually use to measure which works on both CPython and IronPython. On Ipy we use the .NET Stopwatch class which uses a high resolution counter if it's available. This is what you should do. Python Library Reference says: http://docs.python.org/lib/module-time.html#l2h-2819 clock() ... in any case, this is the function to use for benchmarking Python or timing algorithms. -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Thu Aug 14 20:08:52 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 14 Aug 2008 19:08:52 +0100 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <7AD436E4270DD54A94238001769C222701336E4BA78D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> <7AD436E4270DD54A94238001769C222701336E4BA78D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <48A474B4.7090407@voidspace.org.uk> Dino Viehland wrote: > BTW time.clock() is what I usually use to measure which works on both CPython and IronPython. On Ipy we use the .NET Stopwatch class which uses a high resolution counter if it's available. > I was looking for operations that had got an order of magnitude slower or so - so I thought 15ms was fine, although using time.clock would have made the tests portable to CPython without having to implement a fake System module. Thanks. Oh, do you handle the .NET stopwatch reporting time going backwards on AMD dual core processors? ;-) From all these emails the compiled code execution overhead and the set problem are the ones that are really hammering Resolver One. The slow down in exception handling and adding / extending lists are also factors, but not so much. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, August 14, 2008 9:42 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 > > Just for fun I also compared with CPython. The results are interesting, I'll turn it into a blog post of course... > > Results in milliseconds with a granularity of about 15ms and so an accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > The version of Python I compared against was Python 2.4. > > Empty loop (overhead): > IP1: 422 > IP2: 438 > Py: 3578 > > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Py: 4063 > > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Py: 4797 > > Function call: > IP1: 937 > IP2: 906 > Py: 3313 > > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Py: 2766 > > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Py: 23921 > > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > Py: 2108 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Py: 62423 > > Sets: > IP1: 37095 > IP2: 30860 > Py: 8047 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > Py: 6094 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > Py: 3609 > > Sets2 (100 000): 500% slower > IP1: 4984 > IP2: 30547 > Py: 1203 > > func_with_args: > IP1: 6312 > IP2: 5906 > Py: 11250 > > method_with_args: > IP1: 20594 > IP2: 11813 > Py: 14875 > > method_with_kwargs: > IP1: 27953 > IP2: 11187 > Py: 20032 > > import: 15% slower > IP1: 28469 > IP2: 32000 > Py: 25782 > > global: 20% slower > IP1: 1047 > IP2: 1203 > Py: 4141 > > Exceptions (100000): 40% slower > IP1: 4703 > IP2: 6125 > Py: 266 > > Engine execution: 8000% slower!! > IP1: 1600 > IP2: 115002 > > > Michael Foord wrote: > >> Hello all, >> >> I've ported Resolver One to run on IronPython 2 Beta 4 to check for >> any potential problems (we will only do a *proper* port once IP 2 is >> out of beta). >> >> The basic porting was straightforward and several bugs have been fixed >> since IP 2 B3 - many thanks to the IronPython team. >> >> The good news is that Resolver One is only 30-50% slower than Resolver >> One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) >> Resolver One is fairly heavily optimised around the performance >> hotspots of IronPython 1, so we expect to have to do a fair bit of >> profiling and refactoring to readjust to the performance profile of IP 2. >> >> Having said that, there are a few oddities (and the areas that slow >> down vary tremendously depending on which spreadsheet we use to >> benchmark it - making it fairly difficult to track down the hotspots). >> >> We have one particular phase of spreadsheet calculation that takes >> 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing >> some micro-benchmarking to try and identify the hotspot. I've >> certainly found part of the problem. >> >> For those that are interested I've attached the very basic >> microbenchmarks I've been using. The nice thing is that in *general* >> IP2 does outperform IP1. >> >> The results that stand out in the other direction are: >> >> Using sets with custom classes (that define '__eq__', '__ne__' and >> '__hash__') seems to be 6 times slower in IronPython 2. >> >> Adding lists together is about 50% slower. >> >> Defining functions seems to be 25% slower and defining old style >> classes about 33% slower. (Creating instances of new style classes is >> massively faster though - thanks!) >> >> The code I used to test sets (sets2.py) is as follows: >> >> from System import DateTime >> >> class Thing(object): >> def __init__(self, val): >> self.val = val >> def __eq__(self, other): >> return self.val == other.val >> >> def __neq__(self): >> return not self.__eq__(other) >> def __hash__(self): >> return hash(self.val) >> def test(s): >> a = set() >> for i in xrange(100000): >> a.add(Thing(i)) >> a.add(Thing(i+1)) >> Thing(i) in a >> Thing(i+2) in a >> return (DateTime.Now -s).TotalMilliseconds >> s = DateTime.Now >> print test(s) >> >> >> Interestingly the time taken is exactly the same if I remove the >> definition of '__hash__'. >> >> The full set of results below: >> >> Results in milliseconds with a granularity of about 15ms and so an >> accuracy of +/- ~60ms. >> All testing with 10 000 000 operations unless otherwise stated. >> >> Empty loop (overhead): >> IP1: 421.9 >> IP2: 438 >> Create instance newstyle: >> IP1: 20360 >> IP2: 1109 >> Create instance oldstyle: >> IP1: 3766 >> IP2: 3359 >> Function call: >> IP1: 937 >> IP2: 906 >> Create function: 25% slower >> IP1: 2828 >> IP2: 3640 >> Define newstyle (1 000 000): >> IP1: 42047 >> IP2: 20484 >> Define oldstyle (1 000 000): 33% slower >> IP1: 1781 >> IP2: 2671 >> >> Comparing (== and !=): >> IP1: 278597 >> IP2: 117662 >> Sets (with numbers): >> IP1: 37095 >> IP2: 30860 >> >> Lists (10 000): 50% slower >> IP1: 10422 >> IP2: 16109 >> >> Recursion (10 000): >> IP1: 1125 >> IP2: 1000 >> >> Sets2 (100 000): 600% slower >> IP1: 4984 >> IP2: 30547 >> >> >> I'll be doing more as the 600% slow down for sets and the 50% slow >> down for lists accounts for some of the dependency analysis problem >> but not all of it. >> >> Many Thanks >> >> Michael Foord >> -- >> http://www.resolversystems.com >> 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/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > > Sample disclaimer text > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://wwww.theotherdelia.co.uk/ From curt at hagenlocher.org Thu Aug 14 22:27:05 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 14 Aug 2008 13:27:05 -0700 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <48A46054.2040600@voidspace.org.uk> References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> Message-ID: Can you tell us about the environment you're running these tests in? Most interesting are the specific OS and the version of mscorwks.dll. On Thu, Aug 14, 2008 at 9:41 AM, Michael Foord wrote: > Just for fun I also compared with CPython. The results are interesting, > I'll turn it into a blog post of course... > > Results in milliseconds with a granularity of about 15ms and so an accuracy > of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > The version of Python I compared against was Python 2.4. > > Empty loop (overhead): > IP1: 422 > IP2: 438 > Py: 3578 > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Py: 4063 > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Py: 4797 > Function call: > IP1: 937 > IP2: 906 > Py: 3313 > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Py: 2766 > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Py: 23921 > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > Py: 2108 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Py: 62423 > Sets: > IP1: 37095 > IP2: 30860 > Py: 8047 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > Py: 6094 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > Py: 3609 > Sets2 (100 000): 500% slower > IP1: 4984 > IP2: 30547 > Py: 1203 > > func_with_args: > IP1: 6312 > IP2: 5906 > Py: 11250 > > method_with_args: > IP1: 20594 > IP2: 11813 > Py: 14875 > method_with_kwargs: > IP1: 27953 > IP2: 11187 > Py: 20032 > import: 15% slower > IP1: 28469 > IP2: 32000 > Py: 25782 > > global: 20% slower > IP1: 1047 > IP2: 1203 > Py: 4141 > > Exceptions (100000): 40% slower > IP1: 4703 > IP2: 6125 > Py: 266 > Engine execution: 8000% slower!! > IP1: 1600 > IP2: 115002 > > > Michael Foord wrote: > >> Hello all, >> >> I've ported Resolver One to run on IronPython 2 Beta 4 to check for any >> potential problems (we will only do a *proper* port once IP 2 is out of >> beta). >> >> The basic porting was straightforward and several bugs have been fixed >> since IP 2 B3 - many thanks to the IronPython team. >> >> The good news is that Resolver One is only 30-50% slower than Resolver One >> on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) Resolver One >> is fairly heavily optimised around the performance hotspots of IronPython 1, >> so we expect to have to do a fair bit of profiling and refactoring to >> readjust to the performance profile of IP 2. >> >> Having said that, there are a few oddities (and the areas that slow down >> vary tremendously depending on which spreadsheet we use to benchmark it - >> making it fairly difficult to track down the hotspots). >> >> We have one particular phase of spreadsheet calculation that takes >> 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing some >> micro-benchmarking to try and identify the hotspot. I've certainly found >> part of the problem. >> >> For those that are interested I've attached the very basic microbenchmarks >> I've been using. The nice thing is that in *general* IP2 does outperform >> IP1. >> >> The results that stand out in the other direction are: >> >> Using sets with custom classes (that define '__eq__', '__ne__' and >> '__hash__') seems to be 6 times slower in IronPython 2. >> >> Adding lists together is about 50% slower. >> >> Defining functions seems to be 25% slower and defining old style classes >> about 33% slower. (Creating instances of new style classes is massively >> faster though - thanks!) >> >> The code I used to test sets (sets2.py) is as follows: >> >> from System import DateTime >> >> class Thing(object): >> def __init__(self, val): >> self.val = val >> def __eq__(self, other): >> return self.val == other.val >> >> def __neq__(self): >> return not self.__eq__(other) >> def __hash__(self): >> return hash(self.val) >> def test(s): >> a = set() >> for i in xrange(100000): >> a.add(Thing(i)) >> a.add(Thing(i+1)) >> Thing(i) in a >> Thing(i+2) in a >> return (DateTime.Now -s).TotalMilliseconds >> s = DateTime.Now >> print test(s) >> >> >> Interestingly the time taken is exactly the same if I remove the >> definition of '__hash__'. >> >> The full set of results below: >> >> Results in milliseconds with a granularity of about 15ms and so an >> accuracy of +/- ~60ms. >> All testing with 10 000 000 operations unless otherwise stated. >> >> Empty loop (overhead): >> IP1: 421.9 >> IP2: 438 >> Create instance newstyle: >> IP1: 20360 >> IP2: 1109 >> Create instance oldstyle: >> IP1: 3766 >> IP2: 3359 >> Function call: >> IP1: 937 >> IP2: 906 >> Create function: 25% slower >> IP1: 2828 >> IP2: 3640 >> Define newstyle (1 000 000): >> IP1: 42047 >> IP2: 20484 >> Define oldstyle (1 000 000): 33% slower >> IP1: 1781 >> IP2: 2671 >> >> Comparing (== and !=): >> IP1: 278597 >> IP2: 117662 >> Sets (with numbers): >> IP1: 37095 >> IP2: 30860 >> >> Lists (10 000): 50% slower >> IP1: 10422 >> IP2: 16109 >> >> Recursion (10 000): >> IP1: 1125 >> IP2: 1000 >> Sets2 (100 000): 600% slower >> IP1: 4984 >> IP2: 30547 >> >> >> I'll be doing more as the 600% slow down for sets and the 50% slow down >> for lists accounts for some of the dependency analysis problem but not all >> of it. >> >> Many Thanks >> >> Michael Foord >> -- >> http://www.resolversystems.com >> 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/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > > _______________________________________________ > 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 davidjensen at usa.net Thu Aug 14 22:49:26 2008 From: davidjensen at usa.net (David Jensen) Date: Thu, 14 Aug 2008 16:49:26 -0400 Subject: [IronPython] speed of ip compiled Message-ID: <077mHNuWA0210S01.1218746966@cmsweb01.cms.usa.net> I would like to know if I write python standard programs and compile them into an exe using IP1 or IP2, how much faster would it be than standard python. Also, how much faster is interpreted IP1 or IP2 than standard python running as an interpreter? David Jensen From fuzzyman at voidspace.org.uk Thu Aug 14 22:54:27 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 14 Aug 2008 21:54:27 +0100 Subject: [IronPython] speed of ip compiled In-Reply-To: <077mHNuWA0210S01.1218746966@cmsweb01.cms.usa.net> References: <077mHNuWA0210S01.1218746966@cmsweb01.cms.usa.net> Message-ID: <48A49B83.7010306@voidspace.org.uk> David Jensen wrote: > I would like to know if I write python standard programs and compile them into > an exe using IP1 or IP2, how much faster would it be than standard python. > > Also, how much faster is interpreted IP1 or IP2 than standard python running > as an interpreter? > > > Try it and find out. Earlier today I posted some micro-benchmarks showing how IronPython (compiling to exe will make no difference to execution speed with IronPython) is faster than CPython for some things, and slower for others. Michael > David Jensen > > > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From kfarmer at thuban.org Thu Aug 14 23:33:30 2008 From: kfarmer at thuban.org (Keith J. Farmer) Date: Thu, 14 Aug 2008 14:33:30 -0700 Subject: [IronPython] speed of ip compiled References: <077mHNuWA0210S01.1218746966@cmsweb01.cms.usa.net> <48A49B83.7010306@voidspace.org.uk> Message-ID: Michael demonstrates a very good point: if the question is "perf?", the only useful answer is "experiment!". There are so many factors that go into it, down to the machine and the environment it presents, that it's generally quicker and more informative to write a simple program and take several measurements, than it is to try to speculate your way through it (obviously idiotic algorithms notwithstanding). As Michael points out, the speed difference is also non-uniform across the API, so even an algorithm that improves perf on one platform may regress it in another. It also follows, then, that you also should state the experimental conditions when you quote the numbers. ________________________________ From: users-bounces at lists.ironpython.com on behalf of Michael Foord Sent: Thu 8/14/2008 1:54 PM To: Discussion of IronPython Subject: Re: [IronPython] speed of ip compiled David Jensen wrote: > I would like to know if I write python standard programs and compile them into > an exe using IP1 or IP2, how much faster would it be than standard python. > > Also, how much faster is interpreted IP1 or IP2 than standard python running > as an interpreter? > > > Try it and find out. Earlier today I posted some micro-benchmarks showing how IronPython (compiling to exe will make no difference to execution speed with IronPython) is faster than CPython for some things, and slower for others. Michael > David Jensen > > > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ _______________________________________________ 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 Aug 14 23:34:23 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 14 Aug 2008 22:34:23 +0100 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> Message-ID: <48A4A4DF.9060908@voidspace.org.uk> Curt Hagenlocher wrote: > Can you tell us about the environment you're running these tests in? > Most interesting are the specific OS and the version of mscorwks.dll. > It's Win XP SP 3. What's the easiest way of telling you the specific version of mscorwks.dll? I'll get you more details from work tomorrow. Michael > On Thu, Aug 14, 2008 at 9:41 AM, Michael Foord > > wrote: > > Just for fun I also compared with CPython. The results are > interesting, I'll turn it into a blog post of course... > > > Results in milliseconds with a granularity of about 15ms and so an > accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > The version of Python I compared against was Python 2.4. > > Empty loop (overhead): > IP1: 422 > IP2: 438 > Py: 3578 > > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Py: 4063 > > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Py: 4797 > > Function call: > IP1: 937 > IP2: 906 > Py: 3313 > > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Py: 2766 > > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Py: 23921 > > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > Py: 2108 > > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Py: 62423 > Sets: > IP1: 37095 > IP2: 30860 > Py: 8047 > > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > Py: 6094 > > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > Py: 3609 > > Sets2 (100 000): 500% slower > IP1: 4984 > IP2: 30547 > Py: 1203 > > func_with_args: > IP1: 6312 > IP2: 5906 > Py: 11250 > > method_with_args: > IP1: 20594 > IP2: 11813 > Py: 14875 > method_with_kwargs: > IP1: 27953 > IP2: 11187 > Py: 20032 > import: 15% slower > IP1: 28469 > IP2: 32000 > Py: 25782 > > global: 20% slower > IP1: 1047 > IP2: 1203 > Py: 4141 > > Exceptions (100000): 40% slower > IP1: 4703 > IP2: 6125 > Py: 266 > Engine execution: 8000% slower!! > IP1: 1600 > IP2: 115002 > > > Michael Foord wrote: > > Hello all, > > I've ported Resolver One to run on IronPython 2 Beta 4 to > check for any potential problems (we will only do a *proper* > port once IP 2 is out of beta). > > The basic porting was straightforward and several bugs have > been fixed since IP 2 B3 - many thanks to the IronPython team. > > The good news is that Resolver One is only 30-50% slower than > Resolver One on IronPython 1! (It was 300 - 400% slower on top > of IP 2 B3.) Resolver One is fairly heavily optimised around > the performance hotspots of IronPython 1, so we expect to have > to do a fair bit of profiling and refactoring to readjust to > the performance profile of IP 2. > > Having said that, there are a few oddities (and the areas that > slow down vary tremendously depending on which spreadsheet we > use to benchmark it - making it fairly difficult to track down > the hotspots). > > We have one particular phase of spreadsheet calculation that > takes 0.4seconds on IP1 and around 6 seconds on IP2, so I have > been doing some micro-benchmarking to try and identify the > hotspot. I've certainly found part of the problem. > > For those that are interested I've attached the very basic > microbenchmarks I've been using. The nice thing is that in > *general* IP2 does outperform IP1. > > The results that stand out in the other direction are: > > Using sets with custom classes (that define '__eq__', '__ne__' > and '__hash__') seems to be 6 times slower in IronPython 2. > > Adding lists together is about 50% slower. > > Defining functions seems to be 25% slower and defining old > style classes about 33% slower. (Creating instances of new > style classes is massively faster though - thanks!) > > The code I used to test sets (sets2.py) is as follows: > > from System import DateTime > > class Thing(object): > def __init__(self, val): > self.val = val > def __eq__(self, other): > return self.val == other.val > > def __neq__(self): > return not self.__eq__(other) > def __hash__(self): > return hash(self.val) > def test(s): > a = set() > for i in xrange(100000): > a.add(Thing(i)) > a.add(Thing(i+1)) > Thing(i) in a > Thing(i+2) in a > return (DateTime.Now -s).TotalMilliseconds > s = DateTime.Now > print test(s) > > > Interestingly the time taken is exactly the same if I remove > the definition of '__hash__'. > > The full set of results below: > > Results in milliseconds with a granularity of about 15ms and > so an accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > Empty loop (overhead): > IP1: 421.9 > IP2: 438 > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Function call: > IP1: 937 > IP2: 906 > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Sets (with numbers): > IP1: 37095 > IP2: 30860 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > Sets2 (100 000): 600% slower > IP1: 4984 > IP2: 30547 > > > I'll be doing more as the 600% slow down for sets and the 50% > slow down for lists accounts for some of the dependency > analysis problem but not all of it. > > Many Thanks > > Michael Foord > -- > http://www.resolversystems.com > 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/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From dinov at exchange.microsoft.com Thu Aug 14 23:44:04 2008 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 14 Aug 2008 14:44:04 -0700 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <48A4A4DF.9060908@voidspace.org.uk> References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> <48A4A4DF.9060908@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222701336E4BA7E1@DF-GRTDANE-MSG.exchange.corp.microsoft.com> IronPython displays it when it starts up on the first line: "... on .NET 2.0.50727.3031" -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, August 14, 2008 2:34 PM To: Discussion of IronPython Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 Curt Hagenlocher wrote: > Can you tell us about the environment you're running these tests in? > Most interesting are the specific OS and the version of mscorwks.dll. > It's Win XP SP 3. What's the easiest way of telling you the specific version of mscorwks.dll? I'll get you more details from work tomorrow. Michael > On Thu, Aug 14, 2008 at 9:41 AM, Michael Foord > > wrote: > > Just for fun I also compared with CPython. The results are > interesting, I'll turn it into a blog post of course... > > > Results in milliseconds with a granularity of about 15ms and so an > accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > The version of Python I compared against was Python 2.4. > > Empty loop (overhead): > IP1: 422 > IP2: 438 > Py: 3578 > > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Py: 4063 > > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Py: 4797 > > Function call: > IP1: 937 > IP2: 906 > Py: 3313 > > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Py: 2766 > > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Py: 23921 > > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > Py: 2108 > > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Py: 62423 > Sets: > IP1: 37095 > IP2: 30860 > Py: 8047 > > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > Py: 6094 > > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > Py: 3609 > > Sets2 (100 000): 500% slower > IP1: 4984 > IP2: 30547 > Py: 1203 > > func_with_args: > IP1: 6312 > IP2: 5906 > Py: 11250 > > method_with_args: > IP1: 20594 > IP2: 11813 > Py: 14875 > method_with_kwargs: > IP1: 27953 > IP2: 11187 > Py: 20032 > import: 15% slower > IP1: 28469 > IP2: 32000 > Py: 25782 > > global: 20% slower > IP1: 1047 > IP2: 1203 > Py: 4141 > > Exceptions (100000): 40% slower > IP1: 4703 > IP2: 6125 > Py: 266 > Engine execution: 8000% slower!! > IP1: 1600 > IP2: 115002 > > > Michael Foord wrote: > > Hello all, > > I've ported Resolver One to run on IronPython 2 Beta 4 to > check for any potential problems (we will only do a *proper* > port once IP 2 is out of beta). > > The basic porting was straightforward and several bugs have > been fixed since IP 2 B3 - many thanks to the IronPython team. > > The good news is that Resolver One is only 30-50% slower than > Resolver One on IronPython 1! (It was 300 - 400% slower on top > of IP 2 B3.) Resolver One is fairly heavily optimised around > the performance hotspots of IronPython 1, so we expect to have > to do a fair bit of profiling and refactoring to readjust to > the performance profile of IP 2. > > Having said that, there are a few oddities (and the areas that > slow down vary tremendously depending on which spreadsheet we > use to benchmark it - making it fairly difficult to track down > the hotspots). > > We have one particular phase of spreadsheet calculation that > takes 0.4seconds on IP1 and around 6 seconds on IP2, so I have > been doing some micro-benchmarking to try and identify the > hotspot. I've certainly found part of the problem. > > For those that are interested I've attached the very basic > microbenchmarks I've been using. The nice thing is that in > *general* IP2 does outperform IP1. > > The results that stand out in the other direction are: > > Using sets with custom classes (that define '__eq__', '__ne__' > and '__hash__') seems to be 6 times slower in IronPython 2. > > Adding lists together is about 50% slower. > > Defining functions seems to be 25% slower and defining old > style classes about 33% slower. (Creating instances of new > style classes is massively faster though - thanks!) > > The code I used to test sets (sets2.py) is as follows: > > from System import DateTime > > class Thing(object): > def __init__(self, val): > self.val = val > def __eq__(self, other): > return self.val == other.val > > def __neq__(self): > return not self.__eq__(other) > def __hash__(self): > return hash(self.val) > def test(s): > a = set() > for i in xrange(100000): > a.add(Thing(i)) > a.add(Thing(i+1)) > Thing(i) in a > Thing(i+2) in a > return (DateTime.Now -s).TotalMilliseconds > s = DateTime.Now > print test(s) > > > Interestingly the time taken is exactly the same if I remove > the definition of '__hash__'. > > The full set of results below: > > Results in milliseconds with a granularity of about 15ms and > so an accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > Empty loop (overhead): > IP1: 421.9 > IP2: 438 > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Function call: > IP1: 937 > IP2: 906 > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Sets (with numbers): > IP1: 37095 > IP2: 30860 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > Sets2 (100 000): 600% slower > IP1: 4984 > IP2: 30547 > > > I'll be doing more as the 600% slow down for sets and the 50% > slow down for lists accounts for some of the dependency > analysis problem but not all of it. > > Many Thanks > > Michael Foord > -- > http://www.resolversystems.com > 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/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com Sample disclaimer text From empirebuilder at gmail.com Fri Aug 15 10:18:20 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Fri, 15 Aug 2008 11:18:20 +0300 Subject: [IronPython] IronPython 2 Beta 4 and .Net 3.5 Message-ID: <8cd017b80808150118sc81bc00sa2ca7180ceaf744a@mail.gmail.com> Try the following code with a .Net 3.5 setting using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace ClassLibrary1 { public class Class1 { public void Do() { Func f = () => "" ; } } } *This is what I got* Error 36 The type 'System.Func' exists in both 'C:\Users\Adam\Desktop\IronPython-2.0B4\Bin\Debug\Microsoft.Scripting.Core.dll' and 'C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll' C:\Users\Adam\Desktop\IronPython-2.0B4\Src\ClassLibrary1\Class1.cs 12 13 ClassLibrary1 -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From orestis at resolversystems.com Fri Aug 15 11:25:05 2008 From: orestis at resolversystems.com (Orestis Markou) Date: Fri, 15 Aug 2008 10:25:05 +0100 Subject: [IronPython] Patched, profiling IronPython executable? Message-ID: <48A54B71.9070900@resolversystems.com> Hi, following all the discussion about profiling etc, I was poking around in IP1.1.2 source code, trying to find out if there is a 'bottleneck' of sorts, that all function calls are threaded through. My thinking was that it would be then possible to surround this with profiling information, logging time taken etc. and compile a profiling ipy.exe. From my venture, I think that ICallable is what I should be looking for. I see that it has many implementors, but I guess FastCallable (in all its generated glory) should capture a lot of the cases, right? Am I even on the right track here? Orestis Markou From dinov at microsoft.com Fri Aug 15 18:37:12 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 15 Aug 2008 09:37:12 -0700 Subject: [IronPython] IronPython 2 Beta 4 and .Net 3.5 In-Reply-To: <8cd017b80808150118sc81bc00sa2ca7180ceaf744a@mail.gmail.com> References: <8cd017b80808150118sc81bc00sa2ca7180ceaf744a@mail.gmail.com> Message-ID: You'll need to alias Microsoft.Scripting.Core.dll when you're building a 3.5 project. From the command line this is Csc /reference:MSCore=Microsoft.Scripting.Core.dll ... And then you can refer to these namespaces as starting w/ MSCore. Alternately you can leave out the System.Core assemblies and the C# compiler will use the version that is present in MS.Core. This would be: Csc /noconfig ... This works because MS.Core includes most of the basic LINQ stuff for expression trees - it's just missing all of the fun extension methods. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata Sent: Friday, August 15, 2008 1:18 AM To: users at lists.ironpython.com Subject: [IronPython] IronPython 2 Beta 4 and .Net 3.5 Try the following code with a .Net 3.5 setting using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace ClassLibrary1 { public class Class1 { public void Do() { Func f = () => "" ; } } } This is what I got Error 36 The type 'System.Func' exists in both 'C:\Users\Adam\Desktop\IronPython-2.0B4\Bin\Debug\Microsoft.Scripting.Core.dll' and 'C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll' C:\Users\Adam\Desktop\IronPython-2.0B4\Src\ClassLibrary1\Class1.cs 12 13 ClassLibrary1 -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From sridhar.ratna at gmail.com Fri Aug 15 18:41:44 2008 From: sridhar.ratna at gmail.com (Sridhar Ratnakumar) Date: Fri, 15 Aug 2008 09:41:44 -0700 Subject: [IronPython] IronPython 2 Beta 4 and .Net 3.5 In-Reply-To: References: <8cd017b80808150118sc81bc00sa2ca7180ceaf744a@mail.gmail.com> Message-ID: <7c73a13a0808150941j34b65409l7123ce7d2281ee11@mail.gmail.com> On Fri, Aug 15, 2008 at 9:37 AM, Dino Viehland wrote: > You'll need to alias Microsoft.Scripting.Core.dll when you're building a 3.5 > project. From the command line this is > > Csc /reference:MSCore=Microsoft.Scripting.Core.dll ? Any idea how to do this in Visual Studio? From dinov at microsoft.com Fri Aug 15 18:43:38 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 15 Aug 2008 09:43:38 -0700 Subject: [IronPython] Patched, profiling IronPython executable? In-Reply-To: <48A54B71.9070900@resolversystems.com> References: <48A54B71.9070900@resolversystems.com> Message-ID: FastCallable's certainly the right spot if anything will come close. My main concern is that it'll probably leave a lot of stuff out... In 2.0 this is actually easier. You could modify the DLR in MetaAction.cs to wrap every single dynamic operation - whether that be addition, calling something, getting a member, etc... There's a method called GetMetaObjectRule and it has: Expression body = rewriter.VisitNode(AddReturn(binding.Expression, retType)); You could modify this to be something like: Expression tmp = Expression.Variable(body.Type); body = Expression.Scope( Expression.Call( Expression.Comma( Expression.Call(typeof(MyType).GetMethod("Enter")), // MyType is some public type somewhere... Expression.Assign(tmp, body), Expression.Call(typeof(MyType).GetMethod("Exit")), tmp ) ), tmp ) ); And you'd get information on every call - warning, this code was compiled with Outlook. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Orestis Markou Sent: Friday, August 15, 2008 2:25 AM To: users at lists.ironpython.com Subject: [IronPython] Patched, profiling IronPython executable? Hi, following all the discussion about profiling etc, I was poking around in IP1.1.2 source code, trying to find out if there is a 'bottleneck' of sorts, that all function calls are threaded through. My thinking was that it would be then possible to surround this with profiling information, logging time taken etc. and compile a profiling ipy.exe. From my venture, I think that ICallable is what I should be looking for. I see that it has many implementors, but I guess FastCallable (in all its generated glory) should capture a lot of the cases, right? Am I even on the right track here? Orestis Markou _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Fri Aug 15 18:47:30 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 15 Aug 2008 09:47:30 -0700 Subject: [IronPython] IronPython 2 Beta 4 and .Net 3.5 In-Reply-To: <7c73a13a0808150941j34b65409l7123ce7d2281ee11@mail.gmail.com> References: <8cd017b80808150118sc81bc00sa2ca7180ceaf744a@mail.gmail.com> <7c73a13a0808150941j34b65409l7123ce7d2281ee11@mail.gmail.com> Message-ID: For the aliased references it looks like if you go to properties for the individual reference in the solution explorer there's an Alisies property. For noconfig I'm not sure - it might require editing the .csproj file directly. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sridhar Ratnakumar Sent: Friday, August 15, 2008 9:42 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2 Beta 4 and .Net 3.5 On Fri, Aug 15, 2008 at 9:37 AM, Dino Viehland wrote: > You'll need to alias Microsoft.Scripting.Core.dll when you're building a 3.5 > project. From the command line this is > > Csc /reference:MSCore=Microsoft.Scripting.Core.dll ... Any idea how to do this in Visual Studio? _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From orestis at resolversystems.com Fri Aug 15 18:51:32 2008 From: orestis at resolversystems.com (Orestis Markou) Date: Fri, 15 Aug 2008 17:51:32 +0100 Subject: [IronPython] Patched, profiling IronPython executable? In-Reply-To: References: <48A54B71.9070900@resolversystems.com> Message-ID: <48A5B414.5080605@resolversystems.com> Thanks, I'll have a look at that. Hopefully it will help the effort of porting Resolver One to IP2. Dino Viehland wrote: > FastCallable's certainly the right spot if anything will come close. My main concern is that it'll probably leave a lot of stuff out... > > In 2.0 this is actually easier. You could modify the DLR in MetaAction.cs to wrap every single dynamic operation - whether that be addition, calling something, getting a member, etc... There's a method called GetMetaObjectRule and it has: > > Expression body = rewriter.VisitNode(AddReturn(binding.Expression, retType)); > > You could modify this to be something like: > > Expression tmp = Expression.Variable(body.Type); > body = Expression.Scope( > Expression.Call( > Expression.Comma( > Expression.Call(typeof(MyType).GetMethod("Enter")), // MyType is some public type somewhere... > Expression.Assign(tmp, body), > Expression.Call(typeof(MyType).GetMethod("Exit")), > tmp > ) > ), > tmp > ) > ); > > And you'd get information on every call - warning, this code was compiled with Outlook. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Orestis Markou > Sent: Friday, August 15, 2008 2:25 AM > To: users at lists.ironpython.com > Subject: [IronPython] Patched, profiling IronPython executable? > > Hi, > > following all the discussion about profiling etc, I was poking around in > IP1.1.2 source code, trying to find out if there is a 'bottleneck' of > sorts, that all function calls are threaded through. My thinking was > that it would be then possible to surround this with profiling > information, logging time taken etc. and compile a profiling ipy.exe. > > From my venture, I think that ICallable is what I should be looking > for. I see that it has many implementors, but I guess FastCallable (in > all its generated glory) should capture a lot of the cases, right? > > Am I even on the right track here? > > Orestis Markou > _______________________________________________ > 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 Fri Aug 15 19:50:01 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Fri, 15 Aug 2008 20:50:01 +0300 Subject: [IronPython] IronPython 2 Beta 4 and .Net 3.5 In-Reply-To: References: <8cd017b80808150118sc81bc00sa2ca7180ceaf744a@mail.gmail.com> <7c73a13a0808150941j34b65409l7123ce7d2281ee11@mail.gmail.com> Message-ID: <8cd017b80808151050n152106a1n5b6b6eb5fa784a2f@mail.gmail.com> Ah cool. I forgot this little feature of C# 2.0. Thanks a lot. Dody G. On Fri, Aug 15, 2008 at 7:47 PM, Dino Viehland wrote: > For the aliased references it looks like if you go to properties for the > individual reference in the solution explorer there's an Alisies property. > > For noconfig I'm not sure - it might require editing the .csproj file > directly. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Sridhar Ratnakumar > Sent: Friday, August 15, 2008 9:42 AM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython 2 Beta 4 and .Net 3.5 > > On Fri, Aug 15, 2008 at 9:37 AM, Dino Viehland > wrote: > > You'll need to alias Microsoft.Scripting.Core.dll when you're building a > 3.5 > > project. From the command line this is > > > > Csc /reference:MSCore=Microsoft.Scripting.Core.dll ... > > Any idea how to do this in Visual Studio? > _______________________________________________ > 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 dinov at microsoft.com Fri Aug 15 20:09:23 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 15 Aug 2008 11:09:23 -0700 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <48A46054.2040600@voidspace.org.uk> References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> Message-ID: Ok, I looked into a bunch of these and here's what I've discovered so far and other random comments... Exceptions (100000): 40% slower IP1: 4703 IP2: 6125 Py: 266 I haven't looked at this one yet. I do know that we have a number of bug fixes for our exception handling which will slow it down though. I don't consider this to be a high priority though. If we wanted to focus on exception perf I think we'd want to do something radical rather than small tweaks to the existing code. If there's certain scenarios where exception perf is critical though it'd be interesting to hear about those and if we can do anything to improve them. Engine execution: 8000% slower!! IP1: 1600 IP2: 115002 This is just a silly bug. We're doing a tree re-write of the AST and we do that every time through. Caching that re-write gets us back to 1.x performance. I have a fix for this. Create function: 25% slower IP1: 2828 IP2: 3640 Py: 2766 Part of this is from a bug fix but the fix could be more efficient. In 1.x we don't look up __module__ from the global scope. In 2.x we do this lookup but it searches all scopes - which isn't even correct. But we can do a direct lookup which is a little faster - so I have a partial fix for this. This will still be a little slower than 1.x though. Define oldstyle (1 000 000): 33% slower IP1: 1781 IP2: 2671 Py: 2108 Is this critical? I'd rather just live w/ the slowness rather than fixing something that will be gone in 3.x :) Lists (10 000): 50% slower IP1: 10422 IP2: 16109 Py: 6094 The primary issue here is that adding 2 lists ends up creating a new list whose storage is the exact size needed for storing the two lists. When you append to it after adding it we need to allocate a brand new array - and you're not dealing with small arrays here. We can add a little extra space depending on the size of the array to minimize the chance of needing a re-size. That gets us to about 10% slower than CPython. I'm also going to add a strongly typed extend overload which should make those calls a little faster. Sets2 (100 000): 500% slower IP1: 4984 IP2: 30547 Py: 1203 This one I actually cannot repro yet (I've tried it on 3 machines but they've all been Vista). I'm going to try next on a Srv 2k3 machine and see if I can track it down. But more information would be useful. Comparing (== and !=): IP1: 278597 IP2: 117662 This one is actually pretty interesting (even though we're faster in 2.x) - there's an issue with the test here. You've defined "__neq__" instead of "__ne__". That causes the != comparison to ultimately compare based upon object identity - which is extremely slow. There might be some things we can do to make the object identity comparison faster (For example recognizing that we're doing equality and just need a eq or ne answer rather than a 1, -1, 0 comparison value). But I'm going to assume comparing on object identity isn't very important right now - let me know if I'm wrong. But switching this to __ne__ causes us to be a little faster than CPython. They have a great advantage on object identity comparisons - they can just use the objects address. I was also curious what happens to this case if we use __slots__. That identified yet another massive performance regression which I have a fix for - creating instances that have __slots__ defined is horribly slow. With that bug fixed and using slots and __ne__ instead of __neq__ we can actually run this over 2x faster than CPython (on Vista x86 .NET 3.5SP1 on a 2.4ghz Core 2 w/ 4gb of RAM). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, August 14, 2008 9:42 AM To: Discussion of IronPython Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 Just for fun I also compared with CPython. The results are interesting, I'll turn it into a blog post of course... Results in milliseconds with a granularity of about 15ms and so an accuracy of +/- ~60ms. All testing with 10 000 000 operations unless otherwise stated. The version of Python I compared against was Python 2.4. Empty loop (overhead): IP1: 422 IP2: 438 Py: 3578 Create instance newstyle: IP1: 20360 IP2: 1109 Py: 4063 Create instance oldstyle: IP1: 3766 IP2: 3359 Py: 4797 Function call: IP1: 937 IP2: 906 Py: 3313 Create function: 25% slower IP1: 2828 IP2: 3640 Py: 2766 Define newstyle (1 000 000): IP1: 42047 IP2: 20484 Py: 23921 Define oldstyle (1 000 000): 33% slower IP1: 1781 IP2: 2671 Py: 2108 Comparing (== and !=): IP1: 278597 IP2: 117662 Py: 62423 Sets: IP1: 37095 IP2: 30860 Py: 8047 Lists (10 000): 50% slower IP1: 10422 IP2: 16109 Py: 6094 Recursion (10 000): IP1: 1125 IP2: 1000 Py: 3609 Sets2 (100 000): 500% slower IP1: 4984 IP2: 30547 Py: 1203 func_with_args: IP1: 6312 IP2: 5906 Py: 11250 method_with_args: IP1: 20594 IP2: 11813 Py: 14875 method_with_kwargs: IP1: 27953 IP2: 11187 Py: 20032 import: 15% slower IP1: 28469 IP2: 32000 Py: 25782 global: 20% slower IP1: 1047 IP2: 1203 Py: 4141 Exceptions (100000): 40% slower IP1: 4703 IP2: 6125 Py: 266 Engine execution: 8000% slower!! IP1: 1600 IP2: 115002 Michael Foord wrote: > Hello all, > > I've ported Resolver One to run on IronPython 2 Beta 4 to check for > any potential problems (we will only do a *proper* port once IP 2 is > out of beta). > > The basic porting was straightforward and several bugs have been fixed > since IP 2 B3 - many thanks to the IronPython team. > > The good news is that Resolver One is only 30-50% slower than Resolver > One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) > Resolver One is fairly heavily optimised around the performance > hotspots of IronPython 1, so we expect to have to do a fair bit of > profiling and refactoring to readjust to the performance profile of IP 2. > > Having said that, there are a few oddities (and the areas that slow > down vary tremendously depending on which spreadsheet we use to > benchmark it - making it fairly difficult to track down the hotspots). > > We have one particular phase of spreadsheet calculation that takes > 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing > some micro-benchmarking to try and identify the hotspot. I've > certainly found part of the problem. > > For those that are interested I've attached the very basic > microbenchmarks I've been using. The nice thing is that in *general* > IP2 does outperform IP1. > > The results that stand out in the other direction are: > > Using sets with custom classes (that define '__eq__', '__ne__' and > '__hash__') seems to be 6 times slower in IronPython 2. > > Adding lists together is about 50% slower. > > Defining functions seems to be 25% slower and defining old style > classes about 33% slower. (Creating instances of new style classes is > massively faster though - thanks!) > > The code I used to test sets (sets2.py) is as follows: > > from System import DateTime > > class Thing(object): > def __init__(self, val): > self.val = val > def __eq__(self, other): > return self.val == other.val > > def __neq__(self): > return not self.__eq__(other) > def __hash__(self): > return hash(self.val) > def test(s): > a = set() > for i in xrange(100000): > a.add(Thing(i)) > a.add(Thing(i+1)) > Thing(i) in a > Thing(i+2) in a > return (DateTime.Now -s).TotalMilliseconds > s = DateTime.Now > print test(s) > > > Interestingly the time taken is exactly the same if I remove the > definition of '__hash__'. > > The full set of results below: > > Results in milliseconds with a granularity of about 15ms and so an > accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > Empty loop (overhead): > IP1: 421.9 > IP2: 438 > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Function call: > IP1: 937 > IP2: 906 > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Sets (with numbers): > IP1: 37095 > IP2: 30860 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > > Sets2 (100 000): 600% slower > IP1: 4984 > IP2: 30547 > > > I'll be doing more as the 600% slow down for sets and the 50% slow > down for lists accounts for some of the dependency analysis problem > but not all of it. > > Many Thanks > > Michael Foord > -- > http://www.resolversystems.com > 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/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From fuzzyman at voidspace.org.uk Fri Aug 15 20:40:31 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 15 Aug 2008 19:40:31 +0100 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> Message-ID: <48A5CD9F.3070608@voidspace.org.uk> Dino Viehland wrote: > Ok, I looked into a bunch of these and here's what I've discovered so far and other random comments... > > Exceptions (100000): 40% slower > IP1: 4703 > IP2: 6125 > Py: 266 > > I haven't looked at this one yet. I do know that we have a number of bug fixes for our exception handling which will slow it down though. I don't consider this to be a high priority though. If we wanted to focus on exception perf I think we'd want to do something radical rather than small tweaks to the existing code. If there's certain scenarios where exception perf is critical though it'd be interesting to hear about those and if we can do anything to improve them. > > I can look at this. > Engine execution: 8000% slower!! > IP1: 1600 > IP2: 115002 > > This is just a silly bug. We're doing a tree re-write of the AST and we do that every time through. Caching that re-write gets us back to 1.x performance. I have a fix for this. > Great! (1.x performance was very impressive.) > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Py: 2766 > > Part of this is from a bug fix but the fix could be more efficient. In 1.x we don't look up __module__ from the global scope. In 2.x we do this lookup but it searches all scopes - which isn't even correct. But we can do a direct lookup which is a little faster - so I have a partial fix for this. This will still be a little slower than 1.x though. > > Ok. > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > Py: 2108 > > Is this critical? I'd rather just live w/ the slowness rather than fixing something that will be gone in 3.x :) > > Not a problem for us - I merely noted it. In 1.x we needed to switch a few classes to old style for performance reasons (but we don't repeatedly redefine them - it was instantiation time). In 2.x we will need to switch back (which is great). > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > Py: 6094 > > The primary issue here is that adding 2 lists ends up creating a new list whose storage is the exact size needed for storing the two lists. When you append to it after adding it we need to allocate a brand new array - and you're not dealing with small arrays here. We can add a little extra space depending on the size of the array to minimize the chance of needing a re-size. That gets us to about 10% slower than CPython. I'm also going to add a strongly typed extend overload which should make those calls a little faster. > > Python lists will typically grow to always have a lot of space. Creating a list with no extra space seems like a problem. My benchmark for this was unrealistic though (we add lists and extend them a lot - but typically they're nothing like that size). > Sets2 (100 000): 500% slower > IP1: 4984 > IP2: 30547 > Py: 1203 > > This one I actually cannot repro yet (I've tried it on 3 machines but they've all been Vista). I'm going to try next on a Srv 2k3 machine and see if I can track it down. But more information would be useful. > Hmmm... I wonder if it is an oddity with my machine. Unfortunately I am not at work today and can't repeat it. I've just run it on Vista (.NET 2.0.50727.3053) running under VMWare Fusion (but on a kick-arse machine). IP1.1.2: 3515 IP2.0B4: 2516 I need to rerun the whole Resolver port on someone else's machine. > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > > This one is actually pretty interesting (even though we're faster in 2.x) - there's an issue with the test here. You've defined "__neq__" instead of "__ne__". Ha! Oops. :-) > That causes the != comparison to ultimately compare based upon object identity - which is extremely slow. There might be some things we can do to make the object identity comparison faster (For example recognizing that we're doing equality and just need a eq or ne answer rather than a 1, -1, 0 comparison value). But I'm going to assume comparing on object identity isn't very important right now - let me know if I'm wrong. We do use identity comparison a lot - but I'm not sure if it is in performance critical parts of our code. I can review this. > But switching this to __ne__ causes us to be a little faster than CPython. They have a great advantage on object identity comparisons - they can just use the objects address. > > Sure. > I was also curious what happens to this case if we use __slots__. That identified yet another massive performance regression which I have a fix for - creating instances that have __slots__ defined is horribly slow. With that bug fixed and using slots and __ne__ instead of __neq__ we can actually run this over 2x faster than CPython (on Vista x86 .NET 3.5SP1 on a 2.4ghz Core 2 w/ 4gb of RAM). > > Cool. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, August 14, 2008 9:42 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 > > Just for fun I also compared with CPython. The results are interesting, I'll turn it into a blog post of course... > > Results in milliseconds with a granularity of about 15ms and so an accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > The version of Python I compared against was Python 2.4. > > Empty loop (overhead): > IP1: 422 > IP2: 438 > Py: 3578 > > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Py: 4063 > > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Py: 4797 > > Function call: > IP1: 937 > IP2: 906 > Py: 3313 > > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Py: 2766 > > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Py: 23921 > > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > Py: 2108 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Py: 62423 > > Sets: > IP1: 37095 > IP2: 30860 > Py: 8047 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > Py: 6094 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > Py: 3609 > > Sets2 (100 000): 500% slower > IP1: 4984 > IP2: 30547 > Py: 1203 > > func_with_args: > IP1: 6312 > IP2: 5906 > Py: 11250 > > method_with_args: > IP1: 20594 > IP2: 11813 > Py: 14875 > > method_with_kwargs: > IP1: 27953 > IP2: 11187 > Py: 20032 > > import: 15% slower > IP1: 28469 > IP2: 32000 > Py: 25782 > > global: 20% slower > IP1: 1047 > IP2: 1203 > Py: 4141 > > Exceptions (100000): 40% slower > IP1: 4703 > IP2: 6125 > Py: 266 > > Engine execution: 8000% slower!! > IP1: 1600 > IP2: 115002 > > > Michael Foord wrote: > >> Hello all, >> >> I've ported Resolver One to run on IronPython 2 Beta 4 to check for >> any potential problems (we will only do a *proper* port once IP 2 is >> out of beta). >> >> The basic porting was straightforward and several bugs have been fixed >> since IP 2 B3 - many thanks to the IronPython team. >> >> The good news is that Resolver One is only 30-50% slower than Resolver >> One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) >> Resolver One is fairly heavily optimised around the performance >> hotspots of IronPython 1, so we expect to have to do a fair bit of >> profiling and refactoring to readjust to the performance profile of IP 2. >> >> Having said that, there are a few oddities (and the areas that slow >> down vary tremendously depending on which spreadsheet we use to >> benchmark it - making it fairly difficult to track down the hotspots). >> >> We have one particular phase of spreadsheet calculation that takes >> 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing >> some micro-benchmarking to try and identify the hotspot. I've >> certainly found part of the problem. >> >> For those that are interested I've attached the very basic >> microbenchmarks I've been using. The nice thing is that in *general* >> IP2 does outperform IP1. >> >> The results that stand out in the other direction are: >> >> Using sets with custom classes (that define '__eq__', '__ne__' and >> '__hash__') seems to be 6 times slower in IronPython 2. >> >> Adding lists together is about 50% slower. >> >> Defining functions seems to be 25% slower and defining old style >> classes about 33% slower. (Creating instances of new style classes is >> massively faster though - thanks!) >> >> The code I used to test sets (sets2.py) is as follows: >> >> from System import DateTime >> >> class Thing(object): >> def __init__(self, val): >> self.val = val >> def __eq__(self, other): >> return self.val == other.val >> >> def __neq__(self): >> return not self.__eq__(other) >> def __hash__(self): >> return hash(self.val) >> def test(s): >> a = set() >> for i in xrange(100000): >> a.add(Thing(i)) >> a.add(Thing(i+1)) >> Thing(i) in a >> Thing(i+2) in a >> return (DateTime.Now -s).TotalMilliseconds >> s = DateTime.Now >> print test(s) >> >> >> Interestingly the time taken is exactly the same if I remove the >> definition of '__hash__'. >> >> The full set of results below: >> >> Results in milliseconds with a granularity of about 15ms and so an >> accuracy of +/- ~60ms. >> All testing with 10 000 000 operations unless otherwise stated. >> >> Empty loop (overhead): >> IP1: 421.9 >> IP2: 438 >> Create instance newstyle: >> IP1: 20360 >> IP2: 1109 >> Create instance oldstyle: >> IP1: 3766 >> IP2: 3359 >> Function call: >> IP1: 937 >> IP2: 906 >> Create function: 25% slower >> IP1: 2828 >> IP2: 3640 >> Define newstyle (1 000 000): >> IP1: 42047 >> IP2: 20484 >> Define oldstyle (1 000 000): 33% slower >> IP1: 1781 >> IP2: 2671 >> >> Comparing (== and !=): >> IP1: 278597 >> IP2: 117662 >> Sets (with numbers): >> IP1: 37095 >> IP2: 30860 >> >> Lists (10 000): 50% slower >> IP1: 10422 >> IP2: 16109 >> >> Recursion (10 000): >> IP1: 1125 >> IP2: 1000 >> >> Sets2 (100 000): 600% slower >> IP1: 4984 >> IP2: 30547 >> >> >> I'll be doing more as the 600% slow down for sets and the 50% slow >> down for lists accounts for some of the dependency analysis problem >> but not all of it. >> >> Many Thanks >> >> Michael Foord >> -- >> http://www.resolversystems.com >> 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/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From Shri.Borde at microsoft.com Fri Aug 15 21:14:47 2008 From: Shri.Borde at microsoft.com (Shri Borde) Date: Fri, 15 Aug 2008 12:14:47 -0700 Subject: [IronPython] Patched, profiling IronPython executable? In-Reply-To: <48A5B414.5080605@resolversystems.com> References: <48A54B71.9070900@resolversystems.com> <48A5B414.5080605@resolversystems.com> Message-ID: <4168443C59202E43A8B8CC579FE7F3140F8621B97D@NA-EXMSG-C107.redmond.corp.microsoft.com> Have you tried using the VS profiler on a precompiled dll? I don't know how well it works, but VS profiler needs IL on disk, and with precompilation, you have that. There is still IL generated on the fly for rules, but you might be able to get some reasonable numbers. Thanks, Shri -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Orestis Markou Sent: Friday, August 15, 2008 9:52 AM To: Discussion of IronPython Subject: Re: [IronPython] Patched, profiling IronPython executable? Thanks, I'll have a look at that. Hopefully it will help the effort of porting Resolver One to IP2. Dino Viehland wrote: > FastCallable's certainly the right spot if anything will come close. My main concern is that it'll probably leave a lot of stuff out... > > In 2.0 this is actually easier. You could modify the DLR in MetaAction.cs to wrap every single dynamic operation - whether that be addition, calling something, getting a member, etc... There's a method called GetMetaObjectRule and it has: > > Expression body = rewriter.VisitNode(AddReturn(binding.Expression, retType)); > > You could modify this to be something like: > > Expression tmp = Expression.Variable(body.Type); > body = Expression.Scope( > Expression.Call( > Expression.Comma( > Expression.Call(typeof(MyType).GetMethod("Enter")), // MyType is some public type somewhere... > Expression.Assign(tmp, body), > Expression.Call(typeof(MyType).GetMethod("Exit")), > tmp > ) > ), > tmp > ) > ); > > And you'd get information on every call - warning, this code was compiled with Outlook. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Orestis Markou > Sent: Friday, August 15, 2008 2:25 AM > To: users at lists.ironpython.com > Subject: [IronPython] Patched, profiling IronPython executable? > > Hi, > > following all the discussion about profiling etc, I was poking around in > IP1.1.2 source code, trying to find out if there is a 'bottleneck' of > sorts, that all function calls are threaded through. My thinking was > that it would be then possible to surround this with profiling > information, logging time taken etc. and compile a profiling ipy.exe. > > From my venture, I think that ICallable is what I should be looking > for. I see that it has many implementors, but I guess FastCallable (in > all its generated glory) should capture a lot of the cases, right? > > Am I even on the right track here? > > Orestis Markou > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at gmail.com Mon Aug 18 15:20:51 2008 From: fuzzyman at gmail.com (Michael Foord) Date: Mon, 18 Aug 2008 06:20:51 -0700 (PDT) Subject: [IronPython] DLRConsole for Silverlight 2Beta2 Message-ID: Hello all, Is there an updated version of the DLRConsole for Silverlight 2 Beta 2 online? I did a bit of hunting around and could only find the 2b1 version over at silverlight.net. I'd like to be able to link to a live version. Michael Foord -- http://www.ironpythoninaction.com/ From fernandoacorreia at gmail.com Mon Aug 18 20:53:32 2008 From: fernandoacorreia at gmail.com (Fernando Correia) Date: Mon, 18 Aug 2008 15:53:32 -0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) Message-ID: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> I'm getting lots of trouble trying to upgrade a C# project that embedds IronPython from Beta 1 to Beta 4. We target the 3.5 framework. The project has some assemblies and a website. I was able to make the assemblies compile by adding a reference to Microsoft.Scripting.Core and setting the alias to MSCore. In the source code where I use IronPython I inserted this line: extern alias MSCore. But in the website that uses these assemblies, I am getting 244 errors like this: The predefined type 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\website\4ab7ec98\acce05f3\assembly\dl3\b6dd741b\00e0903e_70f2c801\microsoft.scripting.core.DLL' and also: 'ExtensionAttribute' is ambiguous in the namespace 'System.Runtime.CompilerServices'. InternalXmlHelper.vb. I can't see a way to assign an alias to a reference in the website, since Microsoft.Scripting.Core.dll is just copied to the Bin directory. I think I have the latest version of the framework. Even installed the Visual Studio 2008 Service Pack today, along with .NET Framework 3.5 SP1. It seems I am stuck with Beta 1... can someone give me some help? From empirebuilder at gmail.com Mon Aug 18 23:01:03 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 00:01:03 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> Message-ID: <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> I'm having the same problem. That makes the two of us :) I'm trying to migrate from Beta 2 to Beta 4. Still diggin' Dody G. On Mon, Aug 18, 2008 at 9:53 PM, Fernando Correia < fernandoacorreia at gmail.com> wrote: > I'm getting lots of trouble trying to upgrade a C# project that > embedds IronPython from Beta 1 to Beta 4. We target the 3.5 framework. > > The project has some assemblies and a website. I was able to make the > assemblies compile by adding a reference to Microsoft.Scripting.Core > and setting the alias to MSCore. In the source code where I use > IronPython I inserted this line: extern alias MSCore. > > But in the website that uses these assemblies, I am getting 244 errors > like this: The predefined type > 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in > multiple assemblies in the global alias; using definition from > 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET > > Files\website\4ab7ec98\acce05f3\assembly\dl3\b6dd741b\00e0903e_70f2c801\microsoft.scripting.core.DLL' > > and also: 'ExtensionAttribute' is ambiguous in the namespace > 'System.Runtime.CompilerServices'. InternalXmlHelper.vb. > > I can't see a way to assign an alias to a reference in the website, > since Microsoft.Scripting.Core.dll is just copied to the Bin > directory. > > I think I have the latest version of the framework. Even installed the > Visual Studio 2008 Service Pack today, along with .NET Framework 3.5 > SP1. > > It seems I am stuck with Beta 1... can someone give me some help? > _______________________________________________ > 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 dfugate at microsoft.com Mon Aug 18 23:42:41 2008 From: dfugate at microsoft.com (Dave Fugate) Date: Mon, 18 Aug 2008 14:42:41 -0700 Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes Message-ID: Hi everyone, one of the things the IronPython test team does daily is run a set of standardized benchmarks against the latest internal build of IronPython. We're in the process of reevaluating the platforms we measure these benchmarks on with the end goal of increasing the number of tests we can run. For example, if we could cut x64 Vista from the list of platforms, the x64 Vista machine(s) could be reimaged to run new benchmarks we wouldn't have had the resources for before. Alternatively, we might reimage the x64 Vista machine(s) as some other platform we don't currently test under. Of course in such a scenario we'd still run other classifications of tests under x64 Vista. I wanted to hear peoples' opinions on the importance of measuring IronPython performance under x64 Windows OSes before we make any decisions on this. First off, how many people out there are actually running IronPython under a 64-bit OS? Would it be sufficient for us to report news on IronPython performance in terms of 32-bit platforms? Thanks, The IronPython Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidnei at enfoldsystems.com Tue Aug 19 00:12:28 2008 From: sidnei at enfoldsystems.com (Sidnei da Silva) Date: Mon, 18 Aug 2008 19:12:28 -0300 Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes In-Reply-To: References: Message-ID: Hi Dave, On Mon, Aug 18, 2008 at 6:42 PM, Dave Fugate wrote: > Hi everyone, one of the things the IronPython test team does daily is run a > set of standardized benchmarks against the latest internal build of > IronPython. We're in the process of reevaluating the platforms we measure > these benchmarks on with the end goal of increasing the number of tests we > can run. For example, if we could cut x64 Vista from the list of platforms, > the x64 Vista machine(s) could be reimaged to run new benchmarks we wouldn't > have had the resources for before. Alternatively, we might reimage the x64 > Vista machine(s) as some other platform we don't currently test under. Of > course in such a scenario we'd still run other classifications of tests > under x64 Vista. > > I wanted to hear peoples' opinions on the importance of measuring IronPython > performance under x64 Windows OSes before we make any decisions on this. > First off, how many people out there are actually running IronPython under a > 64-bit OS? Would it be sufficient for us to report news on IronPython > performance in terms of 32-bit platforms? > While I am not running IronPythone *yet* on either 32 or 64 bit of anything, we are working on porting some other python applications to run on x64. One such application runs as a mix of ISAPI Filter/Extension, and as such we learned that if IIS is running on 64-bit mode your ISAPI Filter/Extension must as well. I am not sure if IronPython is affected by that too. I've also heard that some Server 2008 editions are 64-bit only too. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 From rhinerfeld at yahoo.com Tue Aug 19 00:25:27 2008 From: rhinerfeld at yahoo.com (Richard Hinerfeld) Date: Mon, 18 Aug 2008 15:25:27 -0700 (PDT) Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes Message-ID: <953466.98001.qm@web45003.mail.sp1.yahoo.com> Sorry I have been using only 32-bit systems such as XP. However, I did integrate CanBus support using a double set of Dlls. ----- Original Message ---- From: Dave Fugate To: Discussion of IronPython Sent: Monday, August 18, 2008 5:42:41 PM Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes Hi everyone, one of the things the IronPython test team does daily is run a set of standardized benchmarks against the latest internal build of IronPython. We?re in the process of reevaluating the platforms we measure these benchmarks on with the end goal of increasing the number of tests we can run. For example, if we could cut x64 Vista from the list of platforms, the x64 Vista machine(s) could be reimaged to run new benchmarks we wouldn?t have had the resources for before. Alternatively, we might reimage the x64 Vista machine(s) as some other platform we don?t currently test under. Of course in such a scenario we?d still run other classifications of tests under x64 Vista. I wanted to hear peoples? opinions on the importance of measuring IronPython performance under x64 Windows OSes before we make any decisions on this. First off, how many people out there are actually running IronPython under a 64-bit OS? Would it be sufficient for us to report news on IronPython performance in terms of 32-bit platforms? Thanks, The IronPython Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Aug 19 00:30:52 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 18 Aug 2008 15:30:52 -0700 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> The only thing I can think of is to explicitly provide the list of assemblies (which I believe you can do through config) and exclude System.Core - of course that only works if you're not using any of the new features. I haven't tried it though so maybe that doesn't work :(... But I do believe ASP.NET via CodeDom is passing /noconfig to the compiler. Another idea would be to lock your project back to .NET 2.0. There's a new CompilerVersion tag that needs to be specified via config that was added w/ .NET 3.5. You can set the version there to v2.0 and we'll then use the original C# 2.0 compiler. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata Sent: Monday, August 18, 2008 2:01 PM To: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) I'm having the same problem. That makes the two of us :) I'm trying to migrate from Beta 2 to Beta 4. Still diggin' Dody G. On Mon, Aug 18, 2008 at 9:53 PM, Fernando Correia > wrote: I'm getting lots of trouble trying to upgrade a C# project that embedds IronPython from Beta 1 to Beta 4. We target the 3.5 framework. The project has some assemblies and a website. I was able to make the assemblies compile by adding a reference to Microsoft.Scripting.Core and setting the alias to MSCore. In the source code where I use IronPython I inserted this line: extern alias MSCore. But in the website that uses these assemblies, I am getting 244 errors like this: The predefined type 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\website\4ab7ec98\acce05f3\assembly\dl3\b6dd741b\00e0903e_70f2c801\microsoft.scripting.core.DLL' and also: 'ExtensionAttribute' is ambiguous in the namespace 'System.Runtime.CompilerServices'. InternalXmlHelper.vb. I can't see a way to assign an alias to a reference in the website, since Microsoft.Scripting.Core.dll is just copied to the Bin directory. I think I have the latest version of the framework. Even installed the Visual Studio 2008 Service Pack today, along with .NET Framework 3.5 SP1. It seems I am stuck with Beta 1... can someone give me some help? _______________________________________________ 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 fernandoacorreia at gmail.com Tue Aug 19 00:59:20 2008 From: fernandoacorreia at gmail.com (Fernando Correia) Date: Mon, 18 Aug 2008 19:59:20 -0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> Dino, thanks for the ideas, but I'd rather not do anything too drastic like that. I have a complex application that can be extended by other DLLs and it has to behave like a standard .NET 3.5 app. I'm trying to implement scripting on top of that, so scripting will have to fit in... 2008/8/18 Dino Viehland : > The only thing I can think of is to explicitly provide the list of > assemblies (which I believe you can do through config) and exclude > System.Core ? of course that only works if you're not using any of the new > features. I haven't tried it though so maybe that doesn't work L? But I do > believe ASP.NET via CodeDom is passing /noconfig to the compiler. > > Another idea would be to lock your project back to .NET 2.0. There's a new > CompilerVersion tag that needs to be specified via config that was added w/ > .NET 3.5. You can set the version there to v2.0 and we'll then use the > original C# 2.0 compiler. From dan.eloff at gmail.com Tue Aug 19 03:50:18 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Mon, 18 Aug 2008 20:50:18 -0500 Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes In-Reply-To: References: Message-ID: <4817b6fc0808181850w113dfc1fi849c903aa2ec4864@mail.gmail.com> I run IronPython on x64 Vista, but mostly only in Silverlight, which correct me if I'm wrong, is 32bit only. So right now, I don't care about x64 Vista. But when Silverlight runs in x64 it will matter to me. There will probably be more x64 vista desktop users out there than Mac and Linux combined by that time. I don't use IronPython in a server context, I prefer to run linux servers with CPython, and IronPython on Mono doesn't quite make the grade in my opinion (largely the fault of Mono). But if I did, it would be x64, because I only use x64 servers. IMHO if you drop Vista x64 benchmarking, you'll have to bring it back probably within the next two years, because x64 is the way of the future. I'd be concerned that if you leave it completely alone you'll have a lot of subtle x64 performance degrades happen over that time frame, and not be competitive on x64 when it matters. But I suppose a lot of it comes down to what you would do with those extra box(es) in the meantime? -Dan On Mon, Aug 18, 2008 at 4:42 PM, Dave Fugate wrote: > Hi everyone, one of the things the IronPython test team does daily is run a > set of standardized benchmarks against the latest internal build of > IronPython. We're in the process of reevaluating the platforms we measure > these benchmarks on with the end goal of increasing the number of tests we > can run. For example, if we could cut x64 Vista from the list of platforms, > the x64 Vista machine(s) could be reimaged to run new benchmarks we wouldn't > have had the resources for before. Alternatively, we might reimage the x64 > Vista machine(s) as some other platform we don't currently test under. Of > course in such a scenario we'd still run other classifications of tests > under x64 Vista. > > > > I wanted to hear peoples' opinions on the importance of measuring IronPython > performance under x64 Windows OSes before we make any decisions on this. > First off, how many people out there are actually running IronPython under a > 64-bit OS? Would it be sufficient for us to report news on IronPython > performance in terms of 32-bit platforms? > > > > Thanks, > > > > The IronPython Team > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From sanxiyn at gmail.com Tue Aug 19 04:01:27 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Tue, 19 Aug 2008 11:01:27 +0900 Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes In-Reply-To: <4817b6fc0808181850w113dfc1fi849c903aa2ec4864@mail.gmail.com> References: <4817b6fc0808181850w113dfc1fi849c903aa2ec4864@mail.gmail.com> Message-ID: <5b0248170808181901g132ceacfr8628f587b3800c91@mail.gmail.com> 2008/8/19 Dan Eloff : > I run IronPython on x64 Vista, but mostly only in Silverlight, which > correct me if I'm wrong, is 32bit only. So right now, I don't care > about x64 Vista. But when Silverlight runs in x64 it will matter to > me. There will probably be more x64 vista desktop users out there than > Mac and Linux combined by that time. I don't use IronPython in a > server context, I prefer to run linux servers with CPython, and > IronPython on Mono doesn't quite make the grade in my opinion (largely > the fault of Mono). But if I did, it would be x64, because I only use > x64 servers. Well said, but in that case (IronPython on x64 servers, and I assume which runs Linux), what you want is benchmark of Mono amd64 JIT, not Vista x64. -- Seo Sanghyeon From curt at hagenlocher.org Tue Aug 19 04:01:29 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 18 Aug 2008 19:01:29 -0700 Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes In-Reply-To: <4817b6fc0808181850w113dfc1fi849c903aa2ec4864@mail.gmail.com> References: <4817b6fc0808181850w113dfc1fi849c903aa2ec4864@mail.gmail.com> Message-ID: On Mon, Aug 18, 2008 at 6:50 PM, Dan Eloff wrote: > > I run IronPython on x64 Vista, but mostly only in Silverlight, which > correct me if I'm wrong, is 32bit only. So right now, I don't care > about x64 Vista. But when Silverlight runs in x64 it will matter to > me. By default, IE runs as a 32-bit application under x64. I don't know if Firefox even publishes a 64-bit version of their app for Windows, and I'm pretty sure that Apple and Opera don't provide 64-bit versions either. There's a sort of chicken-and-egg problem there with respect to plugins. Until vendors like Adobe (Flash), Microsoft (Silverlight) and Sun (Java) start providing their plugins in both 32-bit and 64-bit forms, the 64-bit browser makes for a significantly less usable web experience. I tried for a while a year ago (on general principles :) before giving up. But until people have an actual motivation in using a 64-bit browser under Windows, there's absolutely no incentive for any vendor to spend the money on the platform. Unless Windows 7 makes it possible to load 32-bit DLLs into 64-bit processes, I suspect the 32-bit browser will be with us for the better part of the next decade. -- Curt Hagenlocher curt at hagenlocher.org From curt at hagenlocher.org Tue Aug 19 04:32:22 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 18 Aug 2008 19:32:22 -0700 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <48A0257E.7030405@gmx.de> References: <48A0257E.7030405@gmx.de> Message-ID: I wouldn't say that there's any "right" way to do this, but given the requirements as stated, I'd probably build a single Python function that accepts all n attributes and returns m values, where n is the number of names/values and m is the number of expressions. So for the code below, I'd dynamically build a string that looks like this: def f(a, b, c): return [ a+b, sqrt(b*c), ] After executing this code into a ScriptScope, execute the "f" function bound to your parameters and the you should be able to enumerate over the result to pull out the individual values. I'm not sure if you can bind an IList directly to the function call -- you'd probably have to turn it into an object[] instead. And of course, you couldn't use a function like sqrt without importing it from the math module first. On Mon, Aug 11, 2008 at 4:41 AM, Christian Schmidt < christian2.schmidt at gmx.de> wrote: > Hi, > > I'm trying to figure out the best way to embed IP 2 expressions into C# to > implement the following: > I have given a scope that consists of an IList and a mapping of the > list's indices to a name. > Now I want to evaluate several expressions within this scope. > After this, the scope changes, but the mapping stays the same, only the > IList changes. Then again the expressions are evaluated. > > What is the right way to do it? > > // Input > IEnumerable> data = ... > IList names = { "a", "b", "c" }; > IList pyexpressions = { "a+b", "sqrt(b*c)" }; > > // expected Output > delegate object MyEval(IList row); > IList expressions; > > // IP 2 magic > // ??? > > // Calculate > foreach(IList row in data) > foreach(MyEval expression in expressions) > object obj = expression(row); > // ... > > > Thanks, > Christian > _______________________________________________ > 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 dan.eloff at gmail.com Tue Aug 19 05:34:55 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Mon, 18 Aug 2008 22:34:55 -0500 Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes In-Reply-To: References: <4817b6fc0808181850w113dfc1fi849c903aa2ec4864@mail.gmail.com> Message-ID: <4817b6fc0808182034v70a9e76fyb2db72cd83d20572@mail.gmail.com> On Mon, Aug 18, 2008 at 9:01 PM, Curt Hagenlocher wrote: > But until people have an actual motivation in using > a 64-bit browser under Windows, there's absolutely no incentive for > any vendor to spend the money on the platform. > Exactly. So my interest in IronPython x64 is extremely limited. I'd rather see your time and resources go to more pressing issues. Worry about the future when it gets here. -Dan From fuzzyman at voidspace.org.uk Tue Aug 19 09:12:29 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 19 Aug 2008 10:12:29 +0300 Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes In-Reply-To: References: Message-ID: <6f4025010808190012w475d7c2ha7d3d9a80151b6fb@mail.gmail.com> Hello guys, I run IronPython on Vista x64. Isn't 64bit supposed to be the future or something? :-) (I run Vista x64 in a virtual machine under Mac OS - but performance is very good. Visual Studio runs quite nicely.) I'd love to see more IronPython benchmarking (and the results published). Do you still benchmark with XP? (Still a phenomenally successful OS by all accounts). I'm not sure what the consequences of removing 64bit OSes from the benchmarks might be - .NET seems to nicely insulate programmers from the differences, except for things like P/Invoke of course. Performance is one area where it might make a difference though (it would be a shame to accidentally hose performance on 64bit machines and not realise - is this likely?) What about releasing the benchmark suite with a means to submit results including platform information - that way we can submit results back to you? (By email to the list I guess.) We could even setup some external 'buildbot' machines that automatically sync to codeplex. Anyway - I'd be happy to run benchmark suites occasionally. Michael 2008/8/19 Dave Fugate > Hi everyone, one of the things the IronPython test team does daily is run > a set of standardized benchmarks against the latest internal build of > IronPython. We're in the process of reevaluating the platforms we measure > these benchmarks on with the end goal of increasing the number of tests we > can run. For example, if we could cut x64 Vista from the list of platforms, > the x64 Vista machine(s) could be reimaged to run *new* benchmarks we > wouldn't have had the resources for before. Alternatively, we might reimage > the x64 Vista machine(s) as some other platform we don't currently test > under. Of course in such a scenario we'd still run other classifications of > tests under x64 Vista. > > > > I wanted to hear peoples' opinions on the importance of measuring > IronPython performance under x64 Windows OSes before we make any decisions > on this. First off, how many people out there are actually running > IronPython under a 64-bit OS? Would it be sufficient for us to report news > on IronPython performance in terms of 32-bit platforms? > > > > Thanks, > > > > The IronPython Team > > _______________________________________________ > 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/ http://www.ironpython.info/ http://www.resolverhacks.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dans at houmus.org Tue Aug 19 09:27:10 2008 From: dans at houmus.org (Dan Shechter) Date: Tue, 19 Aug 2008 10:27:10 +0300 Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes In-Reply-To: References: Message-ID: <004801c901cc$ff8b5f90$fea21eb0$@org> I use IP on x64 exclusively since I use it to eventually memory map huge data-sets (> 2GB) from the disk To process them. I agree with Michael Foord. Isn't x64 supposed to be the future or something? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dave Fugate Sent: Tuesday, August 19, 2008 00:43 To: Discussion of IronPython Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes Hi everyone, one of the things the IronPython test team does daily is run a set of standardized benchmarks against the latest internal build of IronPython. We're in the process of reevaluating the platforms we measure these benchmarks on with the end goal of increasing the number of tests we can run. For example, if we could cut x64 Vista from the list of platforms, the x64 Vista machine(s) could be reimaged to run new benchmarks we wouldn't have had the resources for before. Alternatively, we might reimage the x64 Vista machine(s) as some other platform we don't currently test under. Of course in such a scenario we'd still run other classifications of tests under x64 Vista. I wanted to hear peoples' opinions on the importance of measuring IronPython performance under x64 Windows OSes before we make any decisions on this. First off, how many people out there are actually running IronPython under a 64-bit OS? Would it be sufficient for us to report news on IronPython performance in terms of 32-bit platforms? Thanks, The IronPython Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jonathan.Hogg at kbcaim.com Tue Aug 19 09:44:24 2008 From: Jonathan.Hogg at kbcaim.com (Hogg, Jonathan) Date: Tue, 19 Aug 2008 08:44:24 +0100 Subject: [IronPython] Informal Poll: measuring IronPython performanceunder x64 OSes In-Reply-To: <004801c901cc$ff8b5f90$fea21eb0$@org> References: <004801c901cc$ff8b5f90$fea21eb0$@org> Message-ID: Perhaps it's just Vista that's not the future ;-) ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Shechter Sent: 19 August 2008 08:27 To: 'Discussion of IronPython' Subject: Re: [IronPython] Informal Poll: measuring IronPython performanceunder x64 OSes I use IP on x64 exclusively since I use it to eventually memory map huge data-sets (> 2GB) from the disk To process them. I agree with Michael Foord... Isn't x64 supposed to be the future or something? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dave Fugate Sent: Tuesday, August 19, 2008 00:43 To: Discussion of IronPython Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes Hi everyone, one of the things the IronPython test team does daily is run a set of standardized benchmarks against the latest internal build of IronPython. We're in the process of reevaluating the platforms we measure these benchmarks on with the end goal of increasing the number of tests we can run. For example, if we could cut x64 Vista from the list of platforms, the x64 Vista machine(s) could be reimaged to run new benchmarks we wouldn't have had the resources for before. Alternatively, we might reimage the x64 Vista machine(s) as some other platform we don't currently test under. Of course in such a scenario we'd still run other classifications of tests under x64 Vista. I wanted to hear peoples' opinions on the importance of measuring IronPython performance under x64 Windows OSes before we make any decisions on this. First off, how many people out there are actually running IronPython under a 64-bit OS? Would it be sufficient for us to report news on IronPython performance in terms of 32-bit platforms? Thanks, The IronPython Team -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of KBC Alternative Investment Management Limited or its affiliates, or any funds or accounts managed or advised by any of the aforementioned entities (together referred to as "KBC AIM"). This message does not create any obligation, contractual or otherwise, on the part of KBC AIM. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC AIM would enter into a transaction, or prices at which similar transactions may be carried on KBC AIM's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian2.schmidt at gmx.de Tue Aug 19 11:09:02 2008 From: christian2.schmidt at gmx.de (Christian Schmidt) Date: Tue, 19 Aug 2008 11:09:02 +0200 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: References: <48A0257E.7030405@gmx.de> Message-ID: <48AA8DAE.6050507@gmx.de> Hi Curt, thanks for your answer. It's an interesting idea, to hand over the items as function arguments. I was trying to add them to the ScriptScope. But I'm still stuck with calling the function: ScriptScope scope = ScriptRuntime.Create().GetEngine("py").CreateScope(); scope.Execute("from math import *"); scope.Execute(@" def process(a, b, c): return [a+b, sqrt(b*c)] "); object process = scope.GetVariable("process"); foreach(object[] row in data) object[] result = process(row); // ?? How do I call the function? I have some further question regarding this approach: 1. Will the function be interpreted on each call or is it compiled? 2. Is the number of arguments limited? I could have up to 200 arguments. Meanwhile I've tried the CustomSymbolDictionary way, but couldn't find any helpful tutorial. Thanks for your time, Christian From empirebuilder at gmail.com Tue Aug 19 11:32:19 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 12:32:19 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> Message-ID: <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> Hi Dino, There's a couple of problems here with this situation: - This pretty much locks up IronPython 2 from any .Net 3.5 based website. The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch of System.Core facilities in their code base. The nicest thing about .Net 3.5 is to be able to use LINQ on code behind and right now when I compile my application, I got a bunch of warnings about duplicated LINQ definition methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in code behind. - I think this will prevent the next IP for ASP.Net to be able to use .Net 3.5 libraries. Dody G. On Tue, Aug 19, 2008 at 1:59 AM, Fernando Correia < fernandoacorreia at gmail.com> wrote: > Dino, thanks for the ideas, but I'd rather not do anything too drastic > like that. I have a complex application that can be extended by other > DLLs and it has to behave like a standard .NET 3.5 app. I'm trying to > implement scripting on top of that, so scripting will have to fit > in... > > 2008/8/18 Dino Viehland : > > The only thing I can think of is to explicitly provide the list of > > assemblies (which I believe you can do through config) and exclude > > System.Core ? of course that only works if you're not using any of the > new > > features. I haven't tried it though so maybe that doesn't work L? But I > do > > believe ASP.NET via CodeDom is passing /noconfig to the compiler. > > > > Another idea would be to lock your project back to .NET 2.0. There's a > new > > CompilerVersion tag that needs to be specified via config that was added > w/ > > .NET 3.5. You can set the version there to v2.0 and we'll then use the > > original C# 2.0 compiler. > _______________________________________________ > 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 empirebuilder at gmail.com Tue Aug 19 12:26:10 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 13:26:10 +0300 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <48AA8DAE.6050507@gmx.de> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> Message-ID: <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> scope.GetVariable> ("Process") On Tue, Aug 19, 2008 at 12:09 PM, Christian Schmidt < christian2.schmidt at gmx.de> wrote: > Hi Curt, > > thanks for your answer. It's an interesting idea, to hand over the items as > function arguments. I was trying to add them to the ScriptScope. > > But I'm still stuck with calling the function: > > ScriptScope scope = > ScriptRuntime.Create().GetEngine("py").CreateScope(); > scope.Execute("from math import *"); > scope.Execute(@" > def process(a, b, c): > return [a+b, sqrt(b*c)] > "); > object process = scope.GetVariable("process"); > foreach(object[] row in data) > object[] result = process(row); // ?? > > How do I call the function? > > I have some further question regarding this approach: > > 1. Will the function be interpreted on each call or is it compiled? > 2. Is the number of arguments limited? I could have up to 200 arguments. > > Meanwhile I've tried the CustomSymbolDictionary way, but couldn't find any > helpful tutorial. > > Thanks for your time, > > Christian > _______________________________________________ > 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 christian2.schmidt at gmx.de Tue Aug 19 13:12:42 2008 From: christian2.schmidt at gmx.de (Christian Schmidt) Date: Tue, 19 Aug 2008 13:12:42 +0200 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> Message-ID: <48AAAAAA.7020300@gmx.de> Hi Dody, > scope.GetVariable> ("Process") The problem is that I do not know the number of arguments at compile time but at runtime. So I need something like Func. Anyway, this would only work if running on framework 3.5, which I can't because of the problems brought up by Fernando Correia - Func IIRC is only defined in .net 3.5, right? Thanks, Christian > On Tue, Aug 19, 2008 at 12:09 PM, Christian Schmidt > > wrote: > > Hi Curt, > > thanks for your answer. It's an interesting idea, to hand over the > items as function arguments. I was trying to add them to the > ScriptScope. > > But I'm still stuck with calling the function: > > ScriptScope scope = > ScriptRuntime.Create().GetEngine("py").CreateScope(); > scope.Execute("from math import *"); > scope.Execute(@" > def process(a, b, c): > return [a+b, sqrt(b*c)] > "); > object process = scope.GetVariable("process"); > foreach(object[] row in data) > object[] result = process(row); // ?? > > How do I call the function? > > I have some further question regarding this approach: > > 1. Will the function be interpreted on each call or is it compiled? > 2. Is the number of arguments limited? I could have up to 200 arguments. > > Meanwhile I've tried the CustomSymbolDictionary way, but couldn't > find any helpful tutorial. > > Thanks for your time, > > Christian > _______________________________________________ > 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 From empirebuilder at gmail.com Tue Aug 19 13:17:01 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 14:17:01 +0300 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <48AAAAAA.7020300@gmx.de> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> <48AAAAAA.7020300@gmx.de> Message-ID: <8cd017b80808190417g4139b03agcd57b466b66eab6c@mail.gmail.com> delegate object FunctionProcess(object[] params); scope.GetVariable ("Process") and modify your Python code to deal with the object[] params. On Tue, Aug 19, 2008 at 2:12 PM, Christian Schmidt < christian2.schmidt at gmx.de> wrote: > Hi Dody, > > scope.GetVariable> ("Process") >> > > The problem is that I do not know the number of arguments at compile time > but at runtime. So I need something like Func. > > Anyway, this would only work if running on framework 3.5, which I can't > because of the problems brought up by Fernando Correia - Func IIRC is only > defined in .net 3.5, right? > > Thanks, > Christian > > On Tue, Aug 19, 2008 at 12:09 PM, Christian Schmidt < >> christian2.schmidt at gmx.de > wrote: >> >> Hi Curt, >> >> thanks for your answer. It's an interesting idea, to hand over the >> items as function arguments. I was trying to add them to the >> ScriptScope. >> >> But I'm still stuck with calling the function: >> >> ScriptScope scope = >> ScriptRuntime.Create().GetEngine("py").CreateScope(); >> scope.Execute("from math import *"); >> scope.Execute(@" >> def process(a, b, c): >> return [a+b, sqrt(b*c)] >> "); >> object process = scope.GetVariable("process"); >> foreach(object[] row in data) >> object[] result = process(row); // ?? >> >> How do I call the function? >> >> I have some further question regarding this approach: >> >> 1. Will the function be interpreted on each call or is it compiled? >> 2. Is the number of arguments limited? I could have up to 200 >> arguments. >> >> Meanwhile I've tried the CustomSymbolDictionary way, but couldn't >> find any helpful tutorial. >> >> Thanks for your time, >> >> Christian >> _______________________________________________ >> 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 >> > > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Tue Aug 19 13:17:35 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 14:17:35 +0300 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <48AAAAAA.7020300@gmx.de> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> <48AAAAAA.7020300@gmx.de> Message-ID: <8cd017b80808190417i31d4b6b0ked7931c450df78ab@mail.gmail.com> If you are not using this in a .Net 3.5 website project, you can use alias to deal with this Beta 4 issue. On Tue, Aug 19, 2008 at 2:12 PM, Christian Schmidt < christian2.schmidt at gmx.de> wrote: > Hi Dody, > > scope.GetVariable> ("Process") >> > > The problem is that I do not know the number of arguments at compile time > but at runtime. So I need something like Func. > > Anyway, this would only work if running on framework 3.5, which I can't > because of the problems brought up by Fernando Correia - Func IIRC is only > defined in .net 3.5, right? > > Thanks, > Christian > > On Tue, Aug 19, 2008 at 12:09 PM, Christian Schmidt < >> christian2.schmidt at gmx.de > wrote: >> >> Hi Curt, >> >> thanks for your answer. It's an interesting idea, to hand over the >> items as function arguments. I was trying to add them to the >> ScriptScope. >> >> But I'm still stuck with calling the function: >> >> ScriptScope scope = >> ScriptRuntime.Create().GetEngine("py").CreateScope(); >> scope.Execute("from math import *"); >> scope.Execute(@" >> def process(a, b, c): >> return [a+b, sqrt(b*c)] >> "); >> object process = scope.GetVariable("process"); >> foreach(object[] row in data) >> object[] result = process(row); // ?? >> >> How do I call the function? >> >> I have some further question regarding this approach: >> >> 1. Will the function be interpreted on each call or is it compiled? >> 2. Is the number of arguments limited? I could have up to 200 >> arguments. >> >> Meanwhile I've tried the CustomSymbolDictionary way, but couldn't >> find any helpful tutorial. >> >> Thanks for your time, >> >> Christian >> _______________________________________________ >> 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 >> > > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fernandoacorreia at gmail.com Tue Aug 19 13:18:45 2008 From: fernandoacorreia at gmail.com (Fernando Correia) Date: Tue, 19 Aug 2008 08:18:45 -0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> Message-ID: <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> That's a huge issue for my project. I'm trying to leverage the DLR and IronPython on a ASP.NET application that targets 3.5. I hope there is a work-around. 2008/8/19 Dody Gunawinata : > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch of > System.Core facilities in their code base. The nicest thing about .Net 3.5 > is to be able to use LINQ on code behind and right now when I compile my > application, I got a bunch of warnings about duplicated LINQ definition > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > code behind. > > - I think this will prevent the next IP for ASP.Net to be able to use .Net > 3.5 libraries. From empirebuilder at gmail.com Tue Aug 19 13:28:27 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 14:28:27 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> Message-ID: <8cd017b80808190428n3a1d77dewf278843955d4cc1f@mail.gmail.com> Hi Fernando, Try to build the source yourself and manually refactor the System namespace in Microsoft.Scripting.Core assembly and deal with anything that blows up. This is the simplest workaround right now. I'll do that work today because yeah, my project is tied with this issue as well. I prefer this thing is addressed in the next beta because otherwise I have to do the namespace hack again and again. Dody G. On Tue, Aug 19, 2008 at 2:18 PM, Fernando Correia < fernandoacorreia at gmail.com> wrote: > That's a huge issue for my project. I'm trying to leverage the DLR and > IronPython on a ASP.NET application that targets 3.5. I hope there is > a work-around. > > 2008/8/19 Dody Gunawinata : > > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch > of > > System.Core facilities in their code base. The nicest thing about .Net > 3.5 > > is to be able to use LINQ on code behind and right now when I compile my > > application, I got a bunch of warnings about duplicated LINQ definition > > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > > code behind. > > > > - I think this will prevent the next IP for ASP.Net to be able to use > .Net > > 3.5 libraries. > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Tue Aug 19 14:25:48 2008 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Tue, 19 Aug 2008 13:25:48 +0100 Subject: [IronPython] Resolver One 1.2 released Message-ID: <48AABBCC.2050805@resolversystems.com> We are proud to announce the release of Resolver One, version 1.2 - still (we think) the largest IronPython application in the world, now running at 38,000 lines of production code backed up by 150,000 lines of unit and functional tests. Resolver One is a Rapid Application Development tool for analysing and presenting business data, using a familiar spreadsheet interface but with a powerful IronPython-based scripting capability that allows you to insert your own code directly into the recalculation loop. This version's headline feature is a new function called RunWorkbook that allows you to "call" one spreadsheet from another, passing in parameters and pulling out results - just like functions, but without having to code the function by hand. We've also added a whole bunch of usability enhancements - the full (long!) changelist is up on our website, or you can see a screencast: It's free for non-commercial use, so if you would like to take a look, you can download it from our website: (registration no longer required). Best regards, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From empirebuilder at gmail.com Tue Aug 19 14:54:42 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 15:54:42 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8140eff40808190459j7c85a939k2e5b2a8669a713dc@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> <8cd017b80808190428n3a1d77dewf278843955d4cc1f@mail.gmail.com> <8140eff40808190459j7c85a939k2e5b2a8669a713dc@mail.gmail.com> Message-ID: <8cd017b80808190554g782ee6a2x67639aed90551096@mail.gmail.com> Yeah I wonder about the need to replicate the functions in such a critical namespace such as System. Renaming the namespaces is a viable option. My application right now actually runs on IronPyton for ASP.Net (July 2007 CTP - gasp) and gasp, it ran on IronPython 2 Alpha and has not been updated ever since. And I need to do DLR hosting stuff, so I have been having IronPythonX2.dll and IronPYthonX2.dll with changes namespace so I can run both the hosting IronPython and IronPython for ASP.Net together. It's pretty ugly but it works for now. Dody G. On Tue, Aug 19, 2008 at 2:59 PM, Fernando Correia < fernandoacorreia at gmail.com> wrote: > Thanks, Dody. I figured that could be an option. Not sure if I can > just remove classes from Microsoft.Scripting.Core, though. I wonder if > they are just copies of those in System.Core or if they are somewhat > tailored for this version of the DLR. > > Oh man, all this stuff about System.Core and Microsoft.Scripting.Core > is quite confusing. Is there some clarification somewhere about the > strategy of this move and how the final product will deal with the > compatibility issues? > > 2008/8/19 Dody Gunawinata : > > Try to build the source yourself and manually refactor the System > namespace > > in Microsoft.Scripting.Core assembly and deal with anything that blows > up. > > This is the simplest workaround right now. I'll do that work today > because > > yeah, my project is tied with this issue as well. I prefer this thing is > > addressed in the next beta because otherwise I have to do the namespace > hack > > again and again. > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian2.schmidt at gmx.de Tue Aug 19 15:52:31 2008 From: christian2.schmidt at gmx.de (Christian Schmidt) Date: Tue, 19 Aug 2008 15:52:31 +0200 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <8cd017b80808190417i31d4b6b0ked7931c450df78ab@mail.gmail.com> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> <48AAAAAA.7020300@gmx.de> <8cd017b80808190417i31d4b6b0ked7931c450df78ab@mail.gmail.com> Message-ID: <48AAD01F.6030006@gmx.de> Hi Dody, > If you are not using this in a .Net 3.5 website project, you can use alias to deal with this Beta 4 issue. I'm not using IP2 in a website project, but would like to use it in a 3.5 project. How do I have to set this alias? Thanks, Christian From christian2.schmidt at gmx.de Tue Aug 19 15:52:04 2008 From: christian2.schmidt at gmx.de (Christian Schmidt) Date: Tue, 19 Aug 2008 15:52:04 +0200 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <8cd017b80808190417g4139b03agcd57b466b66eab6c@mail.gmail.com> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> <48AAAAAA.7020300@gmx.de> <8cd017b80808190417g4139b03agcd57b466b66eab6c@mail.gmail.com> Message-ID: <48AAD004.3000504@gmx.de> Hi Dody, thanks for your help. > delegate object FunctionProcess(object[] params); I've already tried this one and also delegate object FunctionProcess(params object[] p); > scope.GetVariable ("Process") But get an ArgumentException ("Invalid type of return expression value at 0:0-0:0") here. Any ideas? > and modify your Python code to deal with the object[] params. Could you be more specific here? Thanks, Christian From empirebuilder at gmail.com Tue Aug 19 16:01:44 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 17:01:44 +0300 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <48AACFB0.9020202@gmx.de> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> <48AAAAAA.7020300@gmx.de> <8cd017b80808190417i31d4b6b0ked7931c450df78ab@mail.gmail.com> <48AACFB0.9020202@gmx.de> Message-ID: <8cd017b80808190701x50e9f518obedcc2cc9f532261@mail.gmail.com> http://www.c-sharpcorner.com/UploadFile/rambab/Assembly04292006002740AM/Assembly.aspx?ArticleID=69edb807-8118-4933-8366-773e87ee80ad On Tue, Aug 19, 2008 at 4:50 PM, Christian Schmidt < christian2.schmidt at gmx.de> wrote: > Hi Dody, > > If you are not using this in a .Net 3.5 website project, you can use alias >> to deal with this Beta 4 issue. >> > > I'm not using IP2 in a website project, but would like to use it in a 3.5 > project. How do I have to set this alias? > > Thanks, > Christian > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Tue Aug 19 16:11:32 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 17:11:32 +0300 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <48AAD004.3000504@gmx.de> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> <48AAAAAA.7020300@gmx.de> <8cd017b80808190417g4139b03agcd57b466b66eab6c@mail.gmail.com> <48AAD004.3000504@gmx.de> Message-ID: <8cd017b80808190711r7abe5f1cw392e326994bf657c@mail.gmail.com> delegate System.Int32 FunctionProcess(System.Int32[] parameters) This assumes that your Python implement will only do integer operation. If you are going to use the delegate for generic holder of arguments, don't forget to cast for example: delegate object FunctionProcess(object[] parametser) python = @" def myItems(myParams) val1 = Int(myParams[1]) val2 = Int(myParams[2]) return val1 + val2 " You pretty much need to take care of the conversion. I don't think "*params object[]* "is supported on the hosting DLR because IronPython doesn't support this construct. On Tue, Aug 19, 2008 at 4:52 PM, Christian Schmidt < christian2.schmidt at gmx.de> wrote: > Hi Dody, > > thanks for your help. > > > delegate object FunctionProcess(object[] params); > > I've already tried this one and also > delegate object FunctionProcess(params object[] p); > > > scope.GetVariable ("Process") > > But get an ArgumentException ("Invalid type of return expression value at > 0:0-0:0") here. Any ideas? > > > and modify your Python code to deal with the object[] params. > > Could you be more specific here? > > Thanks, > Christian > _______________________________________________ > 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 christian2.schmidt at gmx.de Tue Aug 19 16:50:02 2008 From: christian2.schmidt at gmx.de (Christian Schmidt) Date: Tue, 19 Aug 2008 16:50:02 +0200 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <8cd017b80808190711r7abe5f1cw392e326994bf657c@mail.gmail.com> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> <48AAAAAA.7020300@gmx.de> <8cd017b80808190417g4139b03agcd57b466b66eab6c@mail.gmail.com> <48AAD004.3000504@gmx.de> <8cd017b80808190711r7abe5f1cw392e326994bf657c@mail.gmail.com> Message-ID: <48AADD9A.9080307@gmx.de> Hi Dody, thanks for your patience. > delegate System.Int32 FunctionProcess(System.Int32[] parameters) > > This assumes that your Python implement will only do integer operation. > If you are going to use the delegate for generic holder of arguments, > don't forget to cast > > for example: > delegate object FunctionProcess(object[] parametser) > > python = @" > def myItems(myParams) > val1 = Int(myParams[1]) > val2 = Int(myParams[2]) > > return val1 + val2 > " > > You pretty much need to take care of the conversion. I don't think > "*params object[]* "is supported on the hosting DLR because IronPython > doesn't support this construct. I'd say in python this is def f(*arg) and def f(**dict), or not? Probably I need the "params object[]"-approach, because I'll use the argument's name and not index. The question is, how a PythonFunction can be casted to a delegate of a certain type or if that is not possible, how can the PythonFunction be called from C#? Regards, Christian From dinov at microsoft.com Tue Aug 19 17:50:14 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 19 Aug 2008 08:50:14 -0700 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <48AADD9A.9080307@gmx.de> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> <48AAAAAA.7020300@gmx.de> <8cd017b80808190417g4139b03agcd57b466b66eab6c@mail.gmail.com> <48AAD004.3000504@gmx.de> <8cd017b80808190711r7abe5f1cw392e326994bf657c@mail.gmail.com> <48AADD9A.9080307@gmx.de> Message-ID: <350E7D38B6D819428718949920EC2355421A331375@NA-EXMSG-C102.redmond.corp.microsoft.com> Is there a reason ObjectOperations.Call(scope.GetVariable("Process"), args) doesn't work? Once you have the function in hand you can call using this and it takes a params array. That params array will be splatted for the call expanding to however many arguments there are there. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Christian Schmidt Sent: Tuesday, August 19, 2008 7:50 AM To: dody at nomadlife.org; Discussion of IronPython Subject: Re: [IronPython] IP 2: Execute multiple expression in different scopes Hi Dody, thanks for your patience. > delegate System.Int32 FunctionProcess(System.Int32[] parameters) > > This assumes that your Python implement will only do integer operation. > If you are going to use the delegate for generic holder of arguments, > don't forget to cast > > for example: > delegate object FunctionProcess(object[] parametser) > > python = @" > def myItems(myParams) > val1 = Int(myParams[1]) > val2 = Int(myParams[2]) > > return val1 + val2 > " > > You pretty much need to take care of the conversion. I don't think > "*params object[]* "is supported on the hosting DLR because IronPython > doesn't support this construct. I'd say in python this is def f(*arg) and def f(**dict), or not? Probably I need the "params object[]"-approach, because I'll use the argument's name and not index. The question is, how a PythonFunction can be casted to a delegate of a certain type or if that is not possible, how can the PythonFunction be called from C#? Regards, Christian _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From empirebuilder at gmail.com Tue Aug 19 17:58:06 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 18:58:06 +0300 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <350E7D38B6D819428718949920EC2355421A331375@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> <48AAAAAA.7020300@gmx.de> <8cd017b80808190417g4139b03agcd57b466b66eab6c@mail.gmail.com> <48AAD004.3000504@gmx.de> <8cd017b80808190711r7abe5f1cw392e326994bf657c@mail.gmail.com> <48AADD9A.9080307@gmx.de> <350E7D38B6D819428718949920EC2355421A331375@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <8cd017b80808190858n706a6b21na29355d16bf6eaf3@mail.gmail.com> This is a better approach. On Tue, Aug 19, 2008 at 6:50 PM, Dino Viehland wrote: > Is there a reason ObjectOperations.Call(scope.GetVariable("Process"), args) > doesn't work? Once you have the function in hand you can call using this > and it takes a params array. That params array will be splatted for the > call expanding to however many arguments there are there. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Christian Schmidt > Sent: Tuesday, August 19, 2008 7:50 AM > To: dody at nomadlife.org; Discussion of IronPython > Subject: Re: [IronPython] IP 2: Execute multiple expression in different > scopes > > Hi Dody, > > thanks for your patience. > > > delegate System.Int32 FunctionProcess(System.Int32[] parameters) > > > > This assumes that your Python implement will only do integer operation. > > If you are going to use the delegate for generic holder of arguments, > > don't forget to cast > > > > for example: > > delegate object FunctionProcess(object[] parametser) > > > > python = @" > > def myItems(myParams) > > val1 = Int(myParams[1]) > > val2 = Int(myParams[2]) > > > > return val1 + val2 > > " > > > > You pretty much need to take care of the conversion. I don't think > > "*params object[]* "is supported on the hosting DLR because IronPython > > doesn't support this construct. > > I'd say in python this is def f(*arg) and def f(**dict), or not? > > Probably I need the "params object[]"-approach, because I'll use the > argument's name and not index. > > The question is, how a PythonFunction can be casted to a delegate of a > certain type or if that is not possible, how can the PythonFunction be > called from C#? > > Regards, > Christian > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Aug 19 18:00:13 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 19 Aug 2008 09:00:13 -0700 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> Ok, another thought... can you GAC the DLR assemblies and then add an updated compilers tag to web.config which includes the alias? Something like: -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia Sent: Tuesday, August 19, 2008 4:19 AM To: dody at nomadlife.org; Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) That's a huge issue for my project. I'm trying to leverage the DLR and IronPython on a ASP.NET application that targets 3.5. I hope there is a work-around. 2008/8/19 Dody Gunawinata : > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch of > System.Core facilities in their code base. The nicest thing about .Net 3.5 > is to be able to use LINQ on code behind and right now when I compile my > application, I got a bunch of warnings about duplicated LINQ definition > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > code behind. > > - I think this will prevent the next IP for ASP.Net to be able to use .Net > 3.5 libraries. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Tue Aug 19 18:09:13 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 19 Aug 2008 09:09:13 -0700 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <48A5CD9F.3070608@voidspace.org.uk> References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> <48A5CD9F.3070608@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC2355421A3313AE@NA-EXMSG-C102.redmond.corp.microsoft.com> The fixes for these (specifically the ones I said I had fixes for :) ) are now checked in and the next source code push (as well as Beta 5) will have the fixes. In addition to these issues I've fixed the **kw perf bug recently reported (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17679). I've also attempted to remove some of the overhead of using sets - we had an extra level of indirection that wasn't necessary and we could also reduce some hashing (where we'd hash twice) we had to do now that we don't use .NET dictionaries directly. It'd be interesting to see if that helps on your machine which shows sets running slowly on or not. Finally creation of instances w/ __slots__ was horribly slow and that's fixed as well. Here's the code review mail if anyone's interested in the details: DLR: OptimizedScriptCode shouldn't be re-writing the AST every time through. I've added a cache so we'll only re-write it once. Python: Speed up dictionary creation by avoding repeated locking. Now we new up an object array w/ the values and pass it off to create in one action. List addition should leave a little bit of buffer room for further operations, also adding fast paths for extend with well known types. Finally switching OrderedLocker to being a struct and ensuring it handles the case where the objects are the same. Set: Removing a level of indirection - we now hold directly onto a CommonDictionaryStorage instead of going through PythonDictionary for the same effect. I've also removed several __contains__ checks which aren't necessary because CommonDictionaryStorage guarantees the correct semantics (replacing an existing value only updates the keys) PythonFunction - speed up function creation by looking directly in the global scope dict and creating the FunctinoCode. Lazily creating this does no good as it's always created and the Interlocked.CompareExchange call isn't cheap. Calling new-style classes no longer looks up __init__, it now just does a TryGetBoundValue on it. Creating instances of types w/ __slots__ is very slow. Switched to using an object array and we no longer require code gen for generating the accesors. This all around simplifies the NewTypeMaker code as well as the ReflectedSlotProperty code. 17679 - Performance issue when calling a function with **kw We now go through the DictionaryStorage Clone API when we have a Python dictionary. Also added "HasNonStringAttributes" method onto DictionaryStorage which SymbolId dicts can optimize away. But CommonDictionaryStorage can also optimize it by avoiding lots of locking. Finally we now throw a reasonable exception when we don't get a dictionary. Also making EnvironmentDictionaryStorage not inherit from CommonDictionaryStorage. AddNoLock was certainly not doing the right thing and this way it's clearer what's going on there. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, August 15, 2008 11:41 AM To: Discussion of IronPython Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 Dino Viehland wrote: > Ok, I looked into a bunch of these and here's what I've discovered so far and other random comments... > > Exceptions (100000): 40% slower > IP1: 4703 > IP2: 6125 > Py: 266 > > I haven't looked at this one yet. I do know that we have a number of bug fixes for our exception handling which will slow it down though. I don't consider this to be a high priority though. If we wanted to focus on exception perf I think we'd want to do something radical rather than small tweaks to the existing code. If there's certain scenarios where exception perf is critical though it'd be interesting to hear about those and if we can do anything to improve them. > > I can look at this. > Engine execution: 8000% slower!! > IP1: 1600 > IP2: 115002 > > This is just a silly bug. We're doing a tree re-write of the AST and we do that every time through. Caching that re-write gets us back to 1.x performance. I have a fix for this. > Great! (1.x performance was very impressive.) > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Py: 2766 > > Part of this is from a bug fix but the fix could be more efficient. In 1.x we don't look up __module__ from the global scope. In 2.x we do this lookup but it searches all scopes - which isn't even correct. But we can do a direct lookup which is a little faster - so I have a partial fix for this. This will still be a little slower than 1.x though. > > Ok. > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > Py: 2108 > > Is this critical? I'd rather just live w/ the slowness rather than fixing something that will be gone in 3.x :) > > Not a problem for us - I merely noted it. In 1.x we needed to switch a few classes to old style for performance reasons (but we don't repeatedly redefine them - it was instantiation time). In 2.x we will need to switch back (which is great). > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > Py: 6094 > > The primary issue here is that adding 2 lists ends up creating a new list whose storage is the exact size needed for storing the two lists. When you append to it after adding it we need to allocate a brand new array - and you're not dealing with small arrays here. We can add a little extra space depending on the size of the array to minimize the chance of needing a re-size. That gets us to about 10% slower than CPython. I'm also going to add a strongly typed extend overload which should make those calls a little faster. > > Python lists will typically grow to always have a lot of space. Creating a list with no extra space seems like a problem. My benchmark for this was unrealistic though (we add lists and extend them a lot - but typically they're nothing like that size). > Sets2 (100 000): 500% slower > IP1: 4984 > IP2: 30547 > Py: 1203 > > This one I actually cannot repro yet (I've tried it on 3 machines but they've all been Vista). I'm going to try next on a Srv 2k3 machine and see if I can track it down. But more information would be useful. > Hmmm... I wonder if it is an oddity with my machine. Unfortunately I am not at work today and can't repeat it. I've just run it on Vista (.NET 2.0.50727.3053) running under VMWare Fusion (but on a kick-arse machine). IP1.1.2: 3515 IP2.0B4: 2516 I need to rerun the whole Resolver port on someone else's machine. > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > > This one is actually pretty interesting (even though we're faster in 2.x) - there's an issue with the test here. You've defined "__neq__" instead of "__ne__". Ha! Oops. :-) > That causes the != comparison to ultimately compare based upon object identity - which is extremely slow. There might be some things we can do to make the object identity comparison faster (For example recognizing that we're doing equality and just need a eq or ne answer rather than a 1, -1, 0 comparison value). But I'm going to assume comparing on object identity isn't very important right now - let me know if I'm wrong. We do use identity comparison a lot - but I'm not sure if it is in performance critical parts of our code. I can review this. > But switching this to __ne__ causes us to be a little faster than CPython. They have a great advantage on object identity comparisons - they can just use the objects address. > > Sure. > I was also curious what happens to this case if we use __slots__. That identified yet another massive performance regression which I have a fix for - creating instances that have __slots__ defined is horribly slow. With that bug fixed and using slots and __ne__ instead of __neq__ we can actually run this over 2x faster than CPython (on Vista x86 .NET 3.5SP1 on a 2.4ghz Core 2 w/ 4gb of RAM). > > Cool. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, August 14, 2008 9:42 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 > > Just for fun I also compared with CPython. The results are interesting, I'll turn it into a blog post of course... > > Results in milliseconds with a granularity of about 15ms and so an accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > The version of Python I compared against was Python 2.4. > > Empty loop (overhead): > IP1: 422 > IP2: 438 > Py: 3578 > > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Py: 4063 > > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Py: 4797 > > Function call: > IP1: 937 > IP2: 906 > Py: 3313 > > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Py: 2766 > > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Py: 23921 > > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > Py: 2108 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Py: 62423 > > Sets: > IP1: 37095 > IP2: 30860 > Py: 8047 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > Py: 6094 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > Py: 3609 > > Sets2 (100 000): 500% slower > IP1: 4984 > IP2: 30547 > Py: 1203 > > func_with_args: > IP1: 6312 > IP2: 5906 > Py: 11250 > > method_with_args: > IP1: 20594 > IP2: 11813 > Py: 14875 > > method_with_kwargs: > IP1: 27953 > IP2: 11187 > Py: 20032 > > import: 15% slower > IP1: 28469 > IP2: 32000 > Py: 25782 > > global: 20% slower > IP1: 1047 > IP2: 1203 > Py: 4141 > > Exceptions (100000): 40% slower > IP1: 4703 > IP2: 6125 > Py: 266 > > Engine execution: 8000% slower!! > IP1: 1600 > IP2: 115002 > > > Michael Foord wrote: > >> Hello all, >> >> I've ported Resolver One to run on IronPython 2 Beta 4 to check for >> any potential problems (we will only do a *proper* port once IP 2 is >> out of beta). >> >> The basic porting was straightforward and several bugs have been fixed >> since IP 2 B3 - many thanks to the IronPython team. >> >> The good news is that Resolver One is only 30-50% slower than Resolver >> One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) >> Resolver One is fairly heavily optimised around the performance >> hotspots of IronPython 1, so we expect to have to do a fair bit of >> profiling and refactoring to readjust to the performance profile of IP 2. >> >> Having said that, there are a few oddities (and the areas that slow >> down vary tremendously depending on which spreadsheet we use to >> benchmark it - making it fairly difficult to track down the hotspots). >> >> We have one particular phase of spreadsheet calculation that takes >> 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing >> some micro-benchmarking to try and identify the hotspot. I've >> certainly found part of the problem. >> >> For those that are interested I've attached the very basic >> microbenchmarks I've been using. The nice thing is that in *general* >> IP2 does outperform IP1. >> >> The results that stand out in the other direction are: >> >> Using sets with custom classes (that define '__eq__', '__ne__' and >> '__hash__') seems to be 6 times slower in IronPython 2. >> >> Adding lists together is about 50% slower. >> >> Defining functions seems to be 25% slower and defining old style >> classes about 33% slower. (Creating instances of new style classes is >> massively faster though - thanks!) >> >> The code I used to test sets (sets2.py) is as follows: >> >> from System import DateTime >> >> class Thing(object): >> def __init__(self, val): >> self.val = val >> def __eq__(self, other): >> return self.val == other.val >> >> def __neq__(self): >> return not self.__eq__(other) >> def __hash__(self): >> return hash(self.val) >> def test(s): >> a = set() >> for i in xrange(100000): >> a.add(Thing(i)) >> a.add(Thing(i+1)) >> Thing(i) in a >> Thing(i+2) in a >> return (DateTime.Now -s).TotalMilliseconds >> s = DateTime.Now >> print test(s) >> >> >> Interestingly the time taken is exactly the same if I remove the >> definition of '__hash__'. >> >> The full set of results below: >> >> Results in milliseconds with a granularity of about 15ms and so an >> accuracy of +/- ~60ms. >> All testing with 10 000 000 operations unless otherwise stated. >> >> Empty loop (overhead): >> IP1: 421.9 >> IP2: 438 >> Create instance newstyle: >> IP1: 20360 >> IP2: 1109 >> Create instance oldstyle: >> IP1: 3766 >> IP2: 3359 >> Function call: >> IP1: 937 >> IP2: 906 >> Create function: 25% slower >> IP1: 2828 >> IP2: 3640 >> Define newstyle (1 000 000): >> IP1: 42047 >> IP2: 20484 >> Define oldstyle (1 000 000): 33% slower >> IP1: 1781 >> IP2: 2671 >> >> Comparing (== and !=): >> IP1: 278597 >> IP2: 117662 >> Sets (with numbers): >> IP1: 37095 >> IP2: 30860 >> >> Lists (10 000): 50% slower >> IP1: 10422 >> IP2: 16109 >> >> Recursion (10 000): >> IP1: 1125 >> IP2: 1000 >> >> Sets2 (100 000): 600% slower >> IP1: 4984 >> IP2: 30547 >> >> >> I'll be doing more as the 600% slow down for sets and the 50% slow >> down for lists accounts for some of the dependency analysis problem >> but not all of it. >> >> Many Thanks >> >> Michael Foord >> -- >> http://www.resolversystems.com >> 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/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From christian2.schmidt at gmx.de Tue Aug 19 18:26:00 2008 From: christian2.schmidt at gmx.de (Christian Schmidt) Date: Tue, 19 Aug 2008 18:26:00 +0200 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <350E7D38B6D819428718949920EC2355421A331375@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> <48AAAAAA.7020300@gmx.de> <8cd017b80808190417g4139b03agcd57b466b66eab6c@mail.gmail.com> <48AAD004.3000504@gmx.de> <8cd017b80808190711r7abe5f1cw392e326994bf657c@mail.gmail.com> <48AADD9A.9080307@gmx.de> <350E7D38B6D819428718949920EC2355421A331375@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <48AAF418.80508@gmx.de> Hi Dino, > Is there a reason ObjectOperations.Call(scope.GetVariable("Process"), > args) doesn't work? It seems that ObjectOperations does not have a static method Call. Where do I get an ObjectOperations instance from? I found another solution: Delegate process = scope.GetVariable("process").Target; process.DynamicInvoke(args); One problem I have with the approach is that I can only use up to 5 arguments. For more arguments I get a TargetParameterCountException. Any ideas? Thanks, Christian From curt at hagenlocher.org Tue Aug 19 18:28:55 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 19 Aug 2008 09:28:55 -0700 Subject: [IronPython] IP 2: Execute multiple expression in different scopes In-Reply-To: <48AAF418.80508@gmx.de> References: <48A0257E.7030405@gmx.de> <48AA8DAE.6050507@gmx.de> <8cd017b80808190326y72d7814dt3d10371260ae388c@mail.gmail.com> <48AAAAAA.7020300@gmx.de> <8cd017b80808190417g4139b03agcd57b466b66eab6c@mail.gmail.com> <48AAD004.3000504@gmx.de> <8cd017b80808190711r7abe5f1cw392e326994bf657c@mail.gmail.com> <48AADD9A.9080307@gmx.de> <350E7D38B6D819428718949920EC2355421A331375@NA-EXMSG-C102.redmond.corp.microsoft.com> <48AAF418.80508@gmx.de> Message-ID: There's an "Operations" property on the ScriptEngine that returns an ObjectOperations object. On Tue, Aug 19, 2008 at 9:26 AM, Christian Schmidt < christian2.schmidt at gmx.de> wrote: > Hi Dino, > > Is there a reason ObjectOperations.Call(scope.GetVariable("Process"), >> args) doesn't work? >> > > It seems that ObjectOperations does not have a static method Call. Where do > I get an ObjectOperations instance from? > > I found another solution: > Delegate process = scope.GetVariable("process").Target; > process.DynamicInvoke(args); > > One problem I have with the approach is that I can only use up to 5 > arguments. For more arguments I get a TargetParameterCountException. > > > Any ideas? > > Thanks, > > Christian > _______________________________________________ > 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 Tue Aug 19 18:39:58 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 19:39:58 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <8cd017b80808190939m53273b7wc70dc7d87a9456e2@mail.gmail.com> Yikes.. "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be found". This is weird. On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland wrote: > Ok, another thought... can you GAC the DLR assemblies and then add an > updated compilers tag to web.config which includes the alias? Something > like: > > > > type="Microsoft.CSharp.CSharpCodeProvider, System, > Version=%ASSEMBLY_VERSION%, Culture=neutral, > PublicKeyToken=%ECMA_PUBLICKEY%" warningLevel="1" > compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"/> > > > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia > Sent: Tuesday, August 19, 2008 4:19 AM > To: dody at nomadlife.org; Discussion of IronPython > Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) > > That's a huge issue for my project. I'm trying to leverage the DLR and > IronPython on a ASP.NET application that targets 3.5. I hope there is > a work-around. > > 2008/8/19 Dody Gunawinata : > > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch > of > > System.Core facilities in their code base. The nicest thing about .Net > 3.5 > > is to be able to use LINQ on code behind and right now when I compile my > > application, I got a bunch of warnings about duplicated LINQ definition > > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > > code behind. > > > > - I think this will prevent the next IP for ASP.Net to be able to use > .Net > > 3.5 libraries. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Aug 19 18:43:07 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 19 Aug 2008 09:43:07 -0700 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8cd017b80808190939m53273b7wc70dc7d87a9456e2@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808190939m53273b7wc70dc7d87a9456e2@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355421A33142D@NA-EXMSG-C102.redmond.corp.microsoft.com> Doh! I forgot you probably need to use the fully qualified assembly name - /reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL From: Dody Gunawinata [mailto:empirebuilder at gmail.com] Sent: Tuesday, August 19, 2008 9:40 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) Yikes.. "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be found". This is weird. On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland > wrote: Ok, another thought... can you GAC the DLR assemblies and then add an updated compilers tag to web.config which includes the alias? Something like: -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia Sent: Tuesday, August 19, 2008 4:19 AM To: dody at nomadlife.org; Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) That's a huge issue for my project. I'm trying to leverage the DLR and IronPython on a ASP.NET application that targets 3.5. I hope there is a work-around. 2008/8/19 Dody Gunawinata >: > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch of > System.Core facilities in their code base. The nicest thing about .Net 3.5 > is to be able to use LINQ on code behind and right now when I compile my > application, I got a bunch of warnings about duplicated LINQ definition > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > code behind. > > - I think this will prevent the next IP for ASP.Net to be able to use .Net > 3.5 libraries. _______________________________________________ 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 empirebuilder at gmail.com Tue Aug 19 19:12:46 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 20:12:46 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <350E7D38B6D819428718949920EC2355421A33142D@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808190939m53273b7wc70dc7d87a9456e2@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33142D@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> hmm..still not working. ASP.Net reads those four qualifier as four additional assemblies. Error 10 Source file 'Version=1.0.0.4000,' could not be found Error 11 Source file 'Culture=neutral,' could not be found Error 12 Source file 'PublicKeyToken=31bf3856ad364e35,' could not be found Error 13 Source file 'processorArchitecture=MSIL}' could not be found On Tue, Aug 19, 2008 at 7:43 PM, Dino Viehland wrote: > Doh! I forgot you probably need to use the fully qualified assembly name > - /reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, > Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL > > > > > > > > *From:* Dody Gunawinata [mailto:empirebuilder at gmail.com] > *Sent:* Tuesday, August 19, 2008 9:40 AM > *To:* Dino Viehland > *Cc:* Discussion of IronPython > > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > Yikes.. > > "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be > found". This is weird. > > > type="Microsoft.CSharp.CSharpCodeProvider, System, > Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"> > > > > > On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland > wrote: > > Ok, another thought... can you GAC the DLR assemblies and then add an > updated compilers tag to web.config which includes the alias? Something > like: > > > > type="Microsoft.CSharp.CSharpCodeProvider, System, > Version=%ASSEMBLY_VERSION%, Culture=neutral, > PublicKeyToken=%ECMA_PUBLICKEY%" warningLevel="1" > compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"/> > > > > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia > Sent: Tuesday, August 19, 2008 4:19 AM > To: dody at nomadlife.org; Discussion of IronPython > Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) > > That's a huge issue for my project. I'm trying to leverage the DLR and > IronPython on a ASP.NET application that targets 3.5. I hope there is > a work-around. > > 2008/8/19 Dody Gunawinata : > > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch > of > > System.Core facilities in their code base. The nicest thing about .Net > 3.5 > > is to be able to use LINQ on code behind and right now when I compile my > > application, I got a bunch of warnings about duplicated LINQ definition > > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > > code behind. > > > > - I think this will prevent the next IP for ASP.Net to be able to use > .Net > > 3.5 libraries. > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > nomadlife.org > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Aug 19 19:13:54 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 19 Aug 2008 10:13:54 -0700 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808181401j474d51d7i1481f6e305854416@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808190939m53273b7wc70dc7d87a9456e2@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33142D@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> Have you tried quotes? It should just be getting passed to the command line so maybe quotes need to be present for the compiler to recognize it correctly - or maybe just removing the spaces will work. From: Dody Gunawinata [mailto:empirebuilder at gmail.com] Sent: Tuesday, August 19, 2008 10:13 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) hmm..still not working. ASP.Net reads those four qualifier as four additional assemblies. Error 10 Source file 'Version=1.0.0.4000,' could not be found Error 11 Source file 'Culture=neutral,' could not be found Error 12 Source file 'PublicKeyToken=31bf3856ad364e35,' could not be found Error 13 Source file 'processorArchitecture=MSIL}' could not be found On Tue, Aug 19, 2008 at 7:43 PM, Dino Viehland > wrote: Doh! I forgot you probably need to use the fully qualified assembly name - /reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL From: Dody Gunawinata [mailto:empirebuilder at gmail.com] Sent: Tuesday, August 19, 2008 9:40 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) Yikes.. "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be found". This is weird. On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland > wrote: Ok, another thought... can you GAC the DLR assemblies and then add an updated compilers tag to web.config which includes the alias? Something like: -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia Sent: Tuesday, August 19, 2008 4:19 AM To: dody at nomadlife.org; Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) That's a huge issue for my project. I'm trying to leverage the DLR and IronPython on a ASP.NET application that targets 3.5. I hope there is a work-around. 2008/8/19 Dody Gunawinata >: > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch of > System.Core facilities in their code base. The nicest thing about .Net 3.5 > is to be able to use LINQ on code behind and right now when I compile my > application, I got a bunch of warnings about duplicated LINQ definition > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > code behind. > > - I think this will prevent the next IP for ASP.Net to be able to use .Net > 3.5 libraries. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- nomadlife.org -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Tue Aug 19 19:23:44 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 20:23:44 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808190939m53273b7wc70dc7d87a9456e2@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33142D@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> *I might be doing something wrong*, *but Microsoft.Scripting.Core.dll is definitely in the GAC.* (No space) compilerOptions="/reference:DLR=Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL" generates "Error 10 A /reference option that declares an extern alias can only have one filename. To specify multiple aliases or filenames, use multiple /reference options." (Quotes) compilerOptions='/reference:DLR="Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"' Error 10 Metadata file 'Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL' could not be found On Tue, Aug 19, 2008 at 8:13 PM, Dino Viehland wrote: > Have you tried quotes? It should just be getting passed to the command > line so maybe quotes need to be present for the compiler to recognize it > correctly ? or maybe just removing the spaces will work. > > > > *From:* Dody Gunawinata [mailto:empirebuilder at gmail.com] > *Sent:* Tuesday, August 19, 2008 10:13 AM > > *To:* Dino Viehland > *Cc:* Discussion of IronPython > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > hmm..still not working. ASP.Net reads those four qualifier as four > additional assemblies. > > Error 10 Source file 'Version=1.0.0.4000,' could not be found > Error 11 Source file 'Culture=neutral,' could not be found > Error 12 Source file 'PublicKeyToken=31bf3856ad364e35,' could not be > found > Error 13 Source file 'processorArchitecture=MSIL}' could not be > found > > On Tue, Aug 19, 2008 at 7:43 PM, Dino Viehland > wrote: > > Doh! I forgot you probably need to use the fully qualified assembly name - > /reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, > Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL > > > > > > > > *From:* Dody Gunawinata [mailto:empirebuilder at gmail.com] > *Sent:* Tuesday, August 19, 2008 9:40 AM > *To:* Dino Viehland > *Cc:* Discussion of IronPython > > > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > Yikes.. > > "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be > found". This is weird. > > > type="Microsoft.CSharp.CSharpCodeProvider, System, > Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"> > > > > > On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland > wrote: > > Ok, another thought... can you GAC the DLR assemblies and then add an > updated compilers tag to web.config which includes the alias? Something > like: > > > > type="Microsoft.CSharp.CSharpCodeProvider, System, > Version=%ASSEMBLY_VERSION%, Culture=neutral, > PublicKeyToken=%ECMA_PUBLICKEY%" warningLevel="1" > compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"/> > > > > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia > Sent: Tuesday, August 19, 2008 4:19 AM > To: dody at nomadlife.org; Discussion of IronPython > Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) > > That's a huge issue for my project. I'm trying to leverage the DLR and > IronPython on a ASP.NET application that targets 3.5. I hope there is > a work-around. > > 2008/8/19 Dody Gunawinata : > > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch > of > > System.Core facilities in their code base. The nicest thing about .Net > 3.5 > > is to be able to use LINQ on code behind and right now when I compile my > > application, I got a bunch of warnings about duplicated LINQ definition > > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > > code behind. > > > > - I think this will prevent the next IP for ASP.Net to be able to use > .Net > > 3.5 libraries. > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > nomadlife.org > > > > > -- > nomadlife.org > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Aug 19 19:34:42 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 19 Aug 2008 10:34:42 -0700 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3310FB@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40808181559t575a1c8bvbf6e8c90c2b24b64@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808190939m53273b7wc70dc7d87a9456e2@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33142D@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> Ahh, apparently csc can't pick up assemblies out of the gac... :( But you should be able to copy Microsoft.Scripting.Core.dll anywhere you want and then reference it. Now that it's in the GAC it should get picked up... So I believe the final answer should be something like: /r:DLR="C:\Microsoft.Scripting.Core.dll" Where C:\ is some directory where you decide to stash the DLL. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata Sent: Tuesday, August 19, 2008 10:24 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) I might be doing something wrong, but Microsoft.Scripting.Core.dll is definitely in the GAC. (No space) compilerOptions="/reference:DLR=Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL" generates "Error 10 A /reference option that declares an extern alias can only have one filename. To specify multiple aliases or filenames, use multiple /reference options." (Quotes) compilerOptions='/reference:DLR="Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"' Error 10 Metadata file 'Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL' could not be found On Tue, Aug 19, 2008 at 8:13 PM, Dino Viehland > wrote: Have you tried quotes? It should just be getting passed to the command line so maybe quotes need to be present for the compiler to recognize it correctly - or maybe just removing the spaces will work. From: Dody Gunawinata [mailto:empirebuilder at gmail.com] Sent: Tuesday, August 19, 2008 10:13 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) hmm..still not working. ASP.Net reads those four qualifier as four additional assemblies. Error 10 Source file 'Version=1.0.0.4000,' could not be found Error 11 Source file 'Culture=neutral,' could not be found Error 12 Source file 'PublicKeyToken=31bf3856ad364e35,' could not be found Error 13 Source file 'processorArchitecture=MSIL}' could not be found On Tue, Aug 19, 2008 at 7:43 PM, Dino Viehland > wrote: Doh! I forgot you probably need to use the fully qualified assembly name - /reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL From: Dody Gunawinata [mailto:empirebuilder at gmail.com] Sent: Tuesday, August 19, 2008 9:40 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) Yikes.. "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be found". This is weird. On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland > wrote: Ok, another thought... can you GAC the DLR assemblies and then add an updated compilers tag to web.config which includes the alias? Something like: -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia Sent: Tuesday, August 19, 2008 4:19 AM To: dody at nomadlife.org; Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) That's a huge issue for my project. I'm trying to leverage the DLR and IronPython on a ASP.NET application that targets 3.5. I hope there is a work-around. 2008/8/19 Dody Gunawinata >: > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch of > System.Core facilities in their code base. The nicest thing about .Net 3.5 > is to be able to use LINQ on code behind and right now when I compile my > application, I got a bunch of warnings about duplicated LINQ definition > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > code behind. > > - I think this will prevent the next IP for ASP.Net to be able to use .Net > 3.5 libraries. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- nomadlife.org -- nomadlife.org -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Tue Aug 19 19:46:16 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 20:46:16 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808190939m53273b7wc70dc7d87a9456e2@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33142D@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <8cd017b80808191046x514c214clad95d1f2c358a419@mail.gmail.com> Nope. This compiles well but it won't be available for code behind. ASP.Net can only compiles dll located either on the GAC or under /bin directory. If I put Microsoft.Scripting.Core under /bin and this option, it will generate error "Error 10 An assembly with the same identity 'Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=1f108baf14f877c2' has already been imported. Try removing one of the duplicate references. " On Tue, Aug 19, 2008 at 8:34 PM, Dino Viehland wrote: > Ahh, apparently csc can't pick up assemblies out of the gac? L But you > should be able to copy Microsoft.Scripting.Core.dll anywhere you want and > then reference it. Now that it's in the GAC it should get picked up? So I > believe the final answer should be something like: > > > > /r:DLR="C:\Microsoft.Scripting.Core.dll" > > > > Where C:\ is some directory where you decide to stash the DLL. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata > *Sent:* Tuesday, August 19, 2008 10:24 AM > > *To:* Dino Viehland > *Cc:* Discussion of IronPython > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > *I might be doing something wrong*, *but Microsoft.Scripting.Core.dll is > definitely in the GAC.* > > (No space) > > compilerOptions="/reference:DLR=Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL" > generates > > "Error 10 A /reference option that declares an extern alias can only > have one filename. To specify multiple aliases or filenames, use multiple > /reference options." > > (Quotes) > compilerOptions='/reference:DLR="Microsoft.Scripting.Core, > Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, > processorArchitecture=MSIL"' > > Error 10 Metadata file > 'Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL' > could not be found > > > On Tue, Aug 19, 2008 at 8:13 PM, Dino Viehland > wrote: > > Have you tried quotes? It should just be getting passed to the command > line so maybe quotes need to be present for the compiler to recognize it > correctly ? or maybe just removing the spaces will work. > > > > *From:* Dody Gunawinata [mailto:empirebuilder at gmail.com] > *Sent:* Tuesday, August 19, 2008 10:13 AM > > > *To:* Dino Viehland > *Cc:* Discussion of IronPython > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > hmm..still not working. ASP.Net reads those four qualifier as four > additional assemblies. > > Error 10 Source file 'Version=1.0.0.4000,' could not be found > Error 11 Source file 'Culture=neutral,' could not be found > Error 12 Source file 'PublicKeyToken=31bf3856ad364e35,' could not be > found > Error 13 Source file 'processorArchitecture=MSIL}' could not be > found > > On Tue, Aug 19, 2008 at 7:43 PM, Dino Viehland > wrote: > > Doh! I forgot you probably need to use the fully qualified assembly name - > /reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, > Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL > > > > > > > > *From:* Dody Gunawinata [mailto:empirebuilder at gmail.com] > *Sent:* Tuesday, August 19, 2008 9:40 AM > *To:* Dino Viehland > *Cc:* Discussion of IronPython > > > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > Yikes.. > > "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be > found". This is weird. > > > type="Microsoft.CSharp.CSharpCodeProvider, System, > Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"> > > > > > On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland > wrote: > > Ok, another thought... can you GAC the DLR assemblies and then add an > updated compilers tag to web.config which includes the alias? Something > like: > > > > type="Microsoft.CSharp.CSharpCodeProvider, System, > Version=%ASSEMBLY_VERSION%, Culture=neutral, > PublicKeyToken=%ECMA_PUBLICKEY%" warningLevel="1" > compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"/> > > > > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia > Sent: Tuesday, August 19, 2008 4:19 AM > To: dody at nomadlife.org; Discussion of IronPython > Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) > > That's a huge issue for my project. I'm trying to leverage the DLR and > IronPython on a ASP.NET application that targets 3.5. I hope there is > a work-around. > > 2008/8/19 Dody Gunawinata : > > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch > of > > System.Core facilities in their code base. The nicest thing about .Net > 3.5 > > is to be able to use LINQ on code behind and right now when I compile my > > application, I got a bunch of warnings about duplicated LINQ definition > > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > > code behind. > > > > - I think this will prevent the next IP for ASP.Net to be able to use > .Net > > 3.5 libraries. > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > nomadlife.org > > > > > -- > nomadlife.org > > > > > -- > nomadlife.org > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Aug 19 19:48:52 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 19 Aug 2008 10:48:52 -0700 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8cd017b80808191046x514c214clad95d1f2c358a419@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808190232g731b331ag158cb34ded28f3c3@mail.gmail.com> <8140eff40808190418g35b0fec8x8d6c8148927effdd@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808190939m53273b7wc70dc7d87a9456e2@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33142D@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191046x514c214clad95d1f2c358a419@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355421A3314ED@NA-EXMSG-C102.redmond.corp.microsoft.com> But can't you leave the assembly in the GAC and have ASP.NET pick it up from there? It should be that it can be referenced for compilation from one spot and loaded from the GAC. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata Sent: Tuesday, August 19, 2008 10:46 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) Nope. This compiles well but it won't be available for code behind. ASP.Net can only compiles dll located either on the GAC or under /bin directory. If I put Microsoft.Scripting.Core under /bin and this option, it will generate error "Error 10 An assembly with the same identity 'Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=1f108baf14f877c2' has already been imported. Try removing one of the duplicate references. " On Tue, Aug 19, 2008 at 8:34 PM, Dino Viehland > wrote: Ahh, apparently csc can't pick up assemblies out of the gac... :( But you should be able to copy Microsoft.Scripting.Core.dll anywhere you want and then reference it. Now that it's in the GAC it should get picked up... So I believe the final answer should be something like: /r:DLR="C:\Microsoft.Scripting.Core.dll" Where C:\ is some directory where you decide to stash the DLL. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata Sent: Tuesday, August 19, 2008 10:24 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) I might be doing something wrong, but Microsoft.Scripting.Core.dll is definitely in the GAC. (No space) compilerOptions="/reference:DLR=Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL" generates "Error 10 A /reference option that declares an extern alias can only have one filename. To specify multiple aliases or filenames, use multiple /reference options." (Quotes) compilerOptions='/reference:DLR="Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"' Error 10 Metadata file 'Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL' could not be found On Tue, Aug 19, 2008 at 8:13 PM, Dino Viehland > wrote: Have you tried quotes? It should just be getting passed to the command line so maybe quotes need to be present for the compiler to recognize it correctly - or maybe just removing the spaces will work. From: Dody Gunawinata [mailto:empirebuilder at gmail.com] Sent: Tuesday, August 19, 2008 10:13 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) hmm..still not working. ASP.Net reads those four qualifier as four additional assemblies. Error 10 Source file 'Version=1.0.0.4000,' could not be found Error 11 Source file 'Culture=neutral,' could not be found Error 12 Source file 'PublicKeyToken=31bf3856ad364e35,' could not be found Error 13 Source file 'processorArchitecture=MSIL}' could not be found On Tue, Aug 19, 2008 at 7:43 PM, Dino Viehland > wrote: Doh! I forgot you probably need to use the fully qualified assembly name - /reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL From: Dody Gunawinata [mailto:empirebuilder at gmail.com] Sent: Tuesday, August 19, 2008 9:40 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) Yikes.. "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be found". This is weird. On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland > wrote: Ok, another thought... can you GAC the DLR assemblies and then add an updated compilers tag to web.config which includes the alias? Something like: -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia Sent: Tuesday, August 19, 2008 4:19 AM To: dody at nomadlife.org; Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) That's a huge issue for my project. I'm trying to leverage the DLR and IronPython on a ASP.NET application that targets 3.5. I hope there is a work-around. 2008/8/19 Dody Gunawinata >: > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch of > System.Core facilities in their code base. The nicest thing about .Net 3.5 > is to be able to use LINQ on code behind and right now when I compile my > application, I got a bunch of warnings about duplicated LINQ definition > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > code behind. > > - I think this will prevent the next IP for ASP.Net to be able to use .Net > 3.5 libraries. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- nomadlife.org -- nomadlife.org -- nomadlife.org -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Tue Aug 19 20:08:56 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 21:08:56 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <350E7D38B6D819428718949920EC2355421A3314ED@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808190939m53273b7wc70dc7d87a9456e2@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33142D@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191046x514c214clad95d1f2c358a419@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314ED@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <8cd017b80808191108t903aa02sbc6264d4e12dd736@mail.gmail.com> This is how the web.config refers to the assembly in GAC. and this is the compiler options compilerOptions="/reference:DLR=c:\Microsoft.Scripting.Core.dll" and this is the error. (0,0): error CS1703: An assembly with the same identity 'Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=1f108baf14f877c2' has already been imported. Try removing one of the duplicate references. On Tue, Aug 19, 2008 at 8:48 PM, Dino Viehland wrote: > But can't you leave the assembly in the GAC and have ASP.NET pick it up > from there? It should be that it can be referenced for compilation from one > spot and loaded from the GAC. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata > *Sent:* Tuesday, August 19, 2008 10:46 AM > > *To:* Dino Viehland > *Cc:* Discussion of IronPython > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > Nope. This compiles well but it won't be available for code behind. ASP.Net > can only compiles dll located either on the GAC or under /bin directory. > > If I put Microsoft.Scripting.Core under /bin and this option, it will > generate error > > "Error 10 An assembly with the same identity > 'Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, > PublicKeyToken=1f108baf14f877c2' has already been imported. Try removing one > of the duplicate references. > " > > > > On Tue, Aug 19, 2008 at 8:34 PM, Dino Viehland > wrote: > > Ahh, apparently csc can't pick up assemblies out of the gac? L But you > should be able to copy Microsoft.Scripting.Core.dll anywhere you want and > then reference it. Now that it's in the GAC it should get picked up? So I > believe the final answer should be something like: > > > > /r:DLR="C:\Microsoft.Scripting.Core.dll" > > > > Where C:\ is some directory where you decide to stash the DLL. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata > *Sent:* Tuesday, August 19, 2008 10:24 AM > > > *To:* Dino Viehland > *Cc:* Discussion of IronPython > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > *I might be doing something wrong*, *but Microsoft.Scripting.Core.dll is > definitely in the GAC.* > > (No space) > > compilerOptions="/reference:DLR=Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL" > generates > > "Error 10 A /reference option that declares an extern alias can only > have one filename. To specify multiple aliases or filenames, use multiple > /reference options." > > (Quotes) > compilerOptions='/reference:DLR="Microsoft.Scripting.Core, > Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, > processorArchitecture=MSIL"' > > Error 10 Metadata file > 'Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL' > could not be found > > On Tue, Aug 19, 2008 at 8:13 PM, Dino Viehland > wrote: > > Have you tried quotes? It should just be getting passed to the command > line so maybe quotes need to be present for the compiler to recognize it > correctly ? or maybe just removing the spaces will work. > > > > *From:* Dody Gunawinata [mailto:empirebuilder at gmail.com] > *Sent:* Tuesday, August 19, 2008 10:13 AM > > > *To:* Dino Viehland > *Cc:* Discussion of IronPython > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > hmm..still not working. ASP.Net reads those four qualifier as four > additional assemblies. > > Error 10 Source file 'Version=1.0.0.4000,' could not be found > Error 11 Source file 'Culture=neutral,' could not be found > Error 12 Source file 'PublicKeyToken=31bf3856ad364e35,' could not be > found > Error 13 Source file 'processorArchitecture=MSIL}' could not be > found > > On Tue, Aug 19, 2008 at 7:43 PM, Dino Viehland > wrote: > > Doh! I forgot you probably need to use the fully qualified assembly name - > /reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, > Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL > > > > > > > > *From:* Dody Gunawinata [mailto:empirebuilder at gmail.com] > *Sent:* Tuesday, August 19, 2008 9:40 AM > *To:* Dino Viehland > *Cc:* Discussion of IronPython > > > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > Yikes.. > > "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be > found". This is weird. > > > type="Microsoft.CSharp.CSharpCodeProvider, System, > Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"> > > > > > On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland > wrote: > > Ok, another thought... can you GAC the DLR assemblies and then add an > updated compilers tag to web.config which includes the alias? Something > like: > > > > type="Microsoft.CSharp.CSharpCodeProvider, System, > Version=%ASSEMBLY_VERSION%, Culture=neutral, > PublicKeyToken=%ECMA_PUBLICKEY%" warningLevel="1" > compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"/> > > > > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia > Sent: Tuesday, August 19, 2008 4:19 AM > To: dody at nomadlife.org; Discussion of IronPython > Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) > > That's a huge issue for my project. I'm trying to leverage the DLR and > IronPython on a ASP.NET application that targets 3.5. I hope there is > a work-around. > > 2008/8/19 Dody Gunawinata : > > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch > of > > System.Core facilities in their code base. The nicest thing about .Net > 3.5 > > is to be able to use LINQ on code behind and right now when I compile my > > application, I got a bunch of warnings about duplicated LINQ definition > > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > > code behind. > > > > - I think this will prevent the next IP for ASP.Net to be able to use > .Net > > 3.5 libraries. > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > nomadlife.org > > > > > -- > nomadlife.org > > > > > -- > nomadlife.org > > > > > -- > nomadlife.org > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Aug 19 20:14:40 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 19 Aug 2008 11:14:40 -0700 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8cd017b80808191108t903aa02sbc6264d4e12dd736@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331391@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808190939m53273b7wc70dc7d87a9456e2@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33142D@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191046x514c214clad95d1f2c358a419@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314ED@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191108t903aa02sbc6264d4e12dd736@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355421A33154F@NA-EXMSG-C102.redmond.corp.microsoft.com> What if you don't add the assembly in the tag - I don't think that should be necessary because you're adding it via the command line. And .NET should still be able to find/load it because it's in the GAC. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata Sent: Tuesday, August 19, 2008 11:09 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) This is how the web.config refers to the assembly in GAC. and this is the compiler options compilerOptions="/reference:DLR=c:\Microsoft.Scripting.Core.dll" and this is the error. (0,0): error CS1703: An assembly with the same identity 'Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=1f108baf14f877c2' has already been imported. Try removing one of the duplicate references. On Tue, Aug 19, 2008 at 8:48 PM, Dino Viehland > wrote: But can't you leave the assembly in the GAC and have ASP.NET pick it up from there? It should be that it can be referenced for compilation from one spot and loaded from the GAC. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata Sent: Tuesday, August 19, 2008 10:46 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) Nope. This compiles well but it won't be available for code behind. ASP.Net can only compiles dll located either on the GAC or under /bin directory. If I put Microsoft.Scripting.Core under /bin and this option, it will generate error "Error 10 An assembly with the same identity 'Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=1f108baf14f877c2' has already been imported. Try removing one of the duplicate references. " On Tue, Aug 19, 2008 at 8:34 PM, Dino Viehland > wrote: Ahh, apparently csc can't pick up assemblies out of the gac... :( But you should be able to copy Microsoft.Scripting.Core.dll anywhere you want and then reference it. Now that it's in the GAC it should get picked up... So I believe the final answer should be something like: /r:DLR="C:\Microsoft.Scripting.Core.dll" Where C:\ is some directory where you decide to stash the DLL. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata Sent: Tuesday, August 19, 2008 10:24 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) I might be doing something wrong, but Microsoft.Scripting.Core.dll is definitely in the GAC. (No space) compilerOptions="/reference:DLR=Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL" generates "Error 10 A /reference option that declares an extern alias can only have one filename. To specify multiple aliases or filenames, use multiple /reference options." (Quotes) compilerOptions='/reference:DLR="Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"' Error 10 Metadata file 'Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL' could not be found On Tue, Aug 19, 2008 at 8:13 PM, Dino Viehland > wrote: Have you tried quotes? It should just be getting passed to the command line so maybe quotes need to be present for the compiler to recognize it correctly - or maybe just removing the spaces will work. From: Dody Gunawinata [mailto:empirebuilder at gmail.com] Sent: Tuesday, August 19, 2008 10:13 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) hmm..still not working. ASP.Net reads those four qualifier as four additional assemblies. Error 10 Source file 'Version=1.0.0.4000,' could not be found Error 11 Source file 'Culture=neutral,' could not be found Error 12 Source file 'PublicKeyToken=31bf3856ad364e35,' could not be found Error 13 Source file 'processorArchitecture=MSIL}' could not be found On Tue, Aug 19, 2008 at 7:43 PM, Dino Viehland > wrote: Doh! I forgot you probably need to use the fully qualified assembly name - /reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL From: Dody Gunawinata [mailto:empirebuilder at gmail.com] Sent: Tuesday, August 19, 2008 9:40 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) Yikes.. "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be found". This is weird. On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland > wrote: Ok, another thought... can you GAC the DLR assemblies and then add an updated compilers tag to web.config which includes the alias? Something like: -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia Sent: Tuesday, August 19, 2008 4:19 AM To: dody at nomadlife.org; Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) That's a huge issue for my project. I'm trying to leverage the DLR and IronPython on a ASP.NET application that targets 3.5. I hope there is a work-around. 2008/8/19 Dody Gunawinata >: > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch of > System.Core facilities in their code base. The nicest thing about .Net 3.5 > is to be able to use LINQ on code behind and right now when I compile my > application, I got a bunch of warnings about duplicated LINQ definition > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > code behind. > > - I think this will prevent the next IP for ASP.Net to be able to use .Net > 3.5 libraries. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- nomadlife.org -- nomadlife.org -- nomadlife.org -- nomadlife.org -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Tue Aug 19 20:22:29 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 21:22:29 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <350E7D38B6D819428718949920EC2355421A33154F@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33142D@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191046x514c214clad95d1f2c358a419@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314ED@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191108t903aa02sbc6264d4e12dd736@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33154F@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <8cd017b80808191122m3014781cy4b256a74ec63630a@mail.gmail.com> I can't make it work that way. I'm using the ASP.Net website model. ASP.Net is blind without either or putting the dll under the /bin directory. There are two asp.net application project model in Visual Studio 2008 (it got introduced in 2005). For the Web Application Project, it has explicit reference with alias like a normal library/.net project so "extern alias DLR" will work. But on ASP.Net website project model, there's no such luck. It depends on web.config for it to know which assemblies to load. Dody G. On Tue, Aug 19, 2008 at 9:14 PM, Dino Viehland wrote: > What if you don't add the assembly in the tag - I don't > think that should be necessary because you're adding it via the command > line. And .NET should still be able to find/load it because it's in the > GAC. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata > *Sent:* Tuesday, August 19, 2008 11:09 AM > > *To:* Dino Viehland > *Cc:* Discussion of IronPython > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > > > > > > > > > > This is how the web.config refers to the assembly in GAC. > > and this is the compiler options > > compilerOptions="/reference:DLR=c:\Microsoft.Scripting.Core.dll" > > > and this is the error. > > (0,0): error CS1703: An assembly with the same identity > 'Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, > PublicKeyToken=1f108baf14f877c2' has already been imported. Try removing one > of the duplicate references. > > On Tue, Aug 19, 2008 at 8:48 PM, Dino Viehland > wrote: > > But can't you leave the assembly in the GAC and have ASP.NET pick it up > from there? It should be that it can be referenced for compilation from one > spot and loaded from the GAC. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata > *Sent:* Tuesday, August 19, 2008 10:46 AM > > > *To:* Dino Viehland > *Cc:* Discussion of IronPython > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > Nope. This compiles well but it won't be available for code behind. ASP.Net > can only compiles dll located either on the GAC or under /bin directory. > > If I put Microsoft.Scripting.Core under /bin and this option, it will > generate error > > "Error 10 An assembly with the same identity > 'Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, > PublicKeyToken=1f108baf14f877c2' has already been imported. Try removing one > of the duplicate references. > " > > > On Tue, Aug 19, 2008 at 8:34 PM, Dino Viehland > wrote: > > Ahh, apparently csc can't pick up assemblies out of the gac? L But you > should be able to copy Microsoft.Scripting.Core.dll anywhere you want and > then reference it. Now that it's in the GAC it should get picked up? So I > believe the final answer should be something like: > > > > /r:DLR="C:\Microsoft.Scripting.Core.dll" > > > > Where C:\ is some directory where you decide to stash the DLL. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata > *Sent:* Tuesday, August 19, 2008 10:24 AM > > > *To:* Dino Viehland > *Cc:* Discussion of IronPython > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > *I might be doing something wrong*, *but Microsoft.Scripting.Core.dll is > definitely in the GAC.* > > (No space) > > compilerOptions="/reference:DLR=Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL" > generates > > "Error 10 A /reference option that declares an extern alias can only > have one filename. To specify multiple aliases or filenames, use multiple > /reference options." > > (Quotes) > compilerOptions='/reference:DLR="Microsoft.Scripting.Core, > Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, > processorArchitecture=MSIL"' > > Error 10 Metadata file > 'Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL' > could not be found > > On Tue, Aug 19, 2008 at 8:13 PM, Dino Viehland > wrote: > > Have you tried quotes? It should just be getting passed to the command > line so maybe quotes need to be present for the compiler to recognize it > correctly ? or maybe just removing the spaces will work. > > > > *From:* Dody Gunawinata [mailto:empirebuilder at gmail.com] > *Sent:* Tuesday, August 19, 2008 10:13 AM > > > *To:* Dino Viehland > *Cc:* Discussion of IronPython > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > hmm..still not working. ASP.Net reads those four qualifier as four > additional assemblies. > > Error 10 Source file 'Version=1.0.0.4000,' could not be found > Error 11 Source file 'Culture=neutral,' could not be found > Error 12 Source file 'PublicKeyToken=31bf3856ad364e35,' could not be > found > Error 13 Source file 'processorArchitecture=MSIL}' could not be > found > > On Tue, Aug 19, 2008 at 7:43 PM, Dino Viehland > wrote: > > Doh! I forgot you probably need to use the fully qualified assembly name - > /reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, > Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL > > > > > > > > *From:* Dody Gunawinata [mailto:empirebuilder at gmail.com] > *Sent:* Tuesday, August 19, 2008 9:40 AM > *To:* Dino Viehland > *Cc:* Discussion of IronPython > > > *Subject:* Re: [IronPython] defined in multiple assemblies (framework 3.5) > > > > Yikes.. > > "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be > found". This is weird. > > > type="Microsoft.CSharp.CSharpCodeProvider, System, > Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"> > > > > > On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland > wrote: > > Ok, another thought... can you GAC the DLR assemblies and then add an > updated compilers tag to web.config which includes the alias? Something > like: > > > > type="Microsoft.CSharp.CSharpCodeProvider, System, > Version=%ASSEMBLY_VERSION%, Culture=neutral, > PublicKeyToken=%ECMA_PUBLICKEY%" warningLevel="1" > compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"/> > > > > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia > Sent: Tuesday, August 19, 2008 4:19 AM > To: dody at nomadlife.org; Discussion of IronPython > Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) > > That's a huge issue for my project. I'm trying to leverage the DLR and > IronPython on a ASP.NET application that targets 3.5. I hope there is > a work-around. > > 2008/8/19 Dody Gunawinata : > > - This pretty much locks up IronPython 2 from any .Net 3.5 based website. > > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch > of > > System.Core facilities in their code base. The nicest thing about .Net > 3.5 > > is to be able to use LINQ on code behind and right now when I compile my > > application, I got a bunch of warnings about duplicated LINQ definition > > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in > > code behind. > > > > - I think this will prevent the next IP for ASP.Net to be able to use > .Net > > 3.5 libraries. > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > nomadlife.org > > > > > -- > nomadlife.org > > > > > -- > nomadlife.org > > > > > -- > nomadlife.org > > > > > -- > nomadlife.org > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fernandoacorreia at gmail.com Tue Aug 19 20:32:33 2008 From: fernandoacorreia at gmail.com (Fernando Correia) Date: Tue, 19 Aug 2008 15:32:33 -0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8cd017b80808191122m3014781cy4b256a74ec63630a@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191046x514c214clad95d1f2c358a419@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314ED@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191108t903aa02sbc6264d4e12dd736@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33154F@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191122m3014781cy4b256a74ec63630a@mail.gmail.com> Message-ID: <8140eff40808191132i5edafdcdx2cc1394b5a9104f0@mail.gmail.com> This issue is very bad for my project too. Do you think there is a way we can make IronPython compatible with the Framework 3.5? I find it appalling that we even have to consider that... From empirebuilder at gmail.com Tue Aug 19 20:37:35 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 21:37:35 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8cd017b80808191122m3014781cy4b256a74ec63630a@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191046x514c214clad95d1f2c358a419@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314ED@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191108t903aa02sbc6264d4e12dd736@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33154F@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191122m3014781cy4b256a74ec63630a@mail.gmail.com> Message-ID: <8cd017b80808191137g6714d48fp7b7ffe98f5c8f17b@mail.gmail.com> IronPython for ASP.Net also uses the website model On Tue, Aug 19, 2008 at 9:22 PM, Dody Gunawinata wrote: > I can't make it work that way. I'm using the ASP.Net website model. > > ASP.Net is blind without either or putting the dll under the > /bin directory. > > There are two asp.net application project model in Visual Studio 2008 (it > got introduced in 2005). For the Web Application Project, it has explicit > reference with alias like a normal library/.net project so "extern alias > DLR" will work. > > But on ASP.Net website project model, there's no such luck. It depends on > web.config for it to know which assemblies to load. > > Dody G. > > > On Tue, Aug 19, 2008 at 9:14 PM, Dino Viehland wrote: > >> What if you don't add the assembly in the tag - I don't >> think that should be necessary because you're adding it via the command >> line. And .NET should still be able to find/load it because it's in the >> GAC. >> >> >> >> *From:* users-bounces at lists.ironpython.com [mailto: >> users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata >> *Sent:* Tuesday, August 19, 2008 11:09 AM >> >> *To:* Dino Viehland >> *Cc:* Discussion of IronPython >> *Subject:* Re: [IronPython] defined in multiple assemblies (framework >> 3.5) >> >> >> >> >> >> >> >> >> >> >> >> >> This is how the web.config refers to the assembly in GAC. >> >> and this is the compiler options >> >> compilerOptions="/reference:DLR=c:\Microsoft.Scripting.Core.dll" >> >> >> and this is the error. >> >> (0,0): error CS1703: An assembly with the same identity >> 'Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, >> PublicKeyToken=1f108baf14f877c2' has already been imported. Try removing one >> of the duplicate references. >> >> On Tue, Aug 19, 2008 at 8:48 PM, Dino Viehland >> wrote: >> >> But can't you leave the assembly in the GAC and have ASP.NET pick it up >> from there? It should be that it can be referenced for compilation from one >> spot and loaded from the GAC. >> >> >> >> *From:* users-bounces at lists.ironpython.com [mailto: >> users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata >> *Sent:* Tuesday, August 19, 2008 10:46 AM >> >> >> *To:* Dino Viehland >> *Cc:* Discussion of IronPython >> *Subject:* Re: [IronPython] defined in multiple assemblies (framework >> 3.5) >> >> >> >> Nope. This compiles well but it won't be available for code behind. >> ASP.Net can only compiles dll located either on the GAC or under /bin >> directory. >> >> If I put Microsoft.Scripting.Core under /bin and this option, it will >> generate error >> >> "Error 10 An assembly with the same identity >> 'Microsoft.Scripting.Core, Version=1.0.0.4000, Culture=neutral, >> PublicKeyToken=1f108baf14f877c2' has already been imported. Try removing one >> of the duplicate references. >> " >> >> >> On Tue, Aug 19, 2008 at 8:34 PM, Dino Viehland >> wrote: >> >> Ahh, apparently csc can't pick up assemblies out of the gac? L But you >> should be able to copy Microsoft.Scripting.Core.dll anywhere you want and >> then reference it. Now that it's in the GAC it should get picked up? So I >> believe the final answer should be something like: >> >> >> >> /r:DLR="C:\Microsoft.Scripting.Core.dll" >> >> >> >> Where C:\ is some directory where you decide to stash the DLL. >> >> >> >> *From:* users-bounces at lists.ironpython.com [mailto: >> users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata >> *Sent:* Tuesday, August 19, 2008 10:24 AM >> >> >> *To:* Dino Viehland >> *Cc:* Discussion of IronPython >> *Subject:* Re: [IronPython] defined in multiple assemblies (framework >> 3.5) >> >> >> >> *I might be doing something wrong*, *but Microsoft.Scripting.Core.dll is >> definitely in the GAC.* >> >> (No space) >> >> compilerOptions="/reference:DLR=Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL" >> generates >> >> "Error 10 A /reference option that declares an extern alias can only >> have one filename. To specify multiple aliases or filenames, use multiple >> /reference options." >> >> (Quotes) >> compilerOptions='/reference:DLR="Microsoft.Scripting.Core, >> Version=1.0.0.4000, Culture=neutral, PublicKeyToken=31bf3856ad364e35, >> processorArchitecture=MSIL"' >> >> Error 10 Metadata file >> 'Microsoft.Scripting.Core,Version=1.0.0.4000,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL' >> could not be found >> >> On Tue, Aug 19, 2008 at 8:13 PM, Dino Viehland >> wrote: >> >> Have you tried quotes? It should just be getting passed to the command >> line so maybe quotes need to be present for the compiler to recognize it >> correctly ? or maybe just removing the spaces will work. >> >> >> >> *From:* Dody Gunawinata [mailto:empirebuilder at gmail.com] >> *Sent:* Tuesday, August 19, 2008 10:13 AM >> >> >> *To:* Dino Viehland >> *Cc:* Discussion of IronPython >> *Subject:* Re: [IronPython] defined in multiple assemblies (framework >> 3.5) >> >> >> >> hmm..still not working. ASP.Net reads those four qualifier as four >> additional assemblies. >> >> Error 10 Source file 'Version=1.0.0.4000,' could not be found >> >> Error 11 Source file 'Culture=neutral,' could not be found >> Error 12 Source file 'PublicKeyToken=31bf3856ad364e35,' could not be >> found >> Error 13 Source file 'processorArchitecture=MSIL}' could not be >> found >> >> On Tue, Aug 19, 2008 at 7:43 PM, Dino Viehland >> wrote: >> >> Doh! I forgot you probably need to use the fully qualified assembly name >> - /reference:DLR=Microsoft.Scripting.Core, Version=1.0.0.4000, >> Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL >> >> >> >> >> >> >> >> *From:* Dody Gunawinata [mailto:empirebuilder at gmail.com] >> *Sent:* Tuesday, August 19, 2008 9:40 AM >> *To:* Dino Viehland >> *Cc:* Discussion of IronPython >> >> >> *Subject:* Re: [IronPython] defined in multiple assemblies (framework >> 3.5) >> >> >> >> Yikes.. >> >> "Error 19 Metadata file 'Microsoft.Scripting.Core.dll' could not be >> found". This is weird. >> >> >> > type="Microsoft.CSharp.CSharpCodeProvider, System, >> Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >> compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"> >> >> >> >> >> On Tue, Aug 19, 2008 at 7:00 PM, Dino Viehland >> wrote: >> >> Ok, another thought... can you GAC the DLR assemblies and then add an >> updated compilers tag to web.config which includes the alias? Something >> like: >> >> >> >> > type="Microsoft.CSharp.CSharpCodeProvider, System, >> Version=%ASSEMBLY_VERSION%, Culture=neutral, >> PublicKeyToken=%ECMA_PUBLICKEY%" warningLevel="1" >> compilerOptions="/reference:DLR=Microsoft.Scripting.Core.dll"/> >> >> >> >> >> >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto: >> users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia >> Sent: Tuesday, August 19, 2008 4:19 AM >> To: dody at nomadlife.org; Discussion of IronPython >> Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) >> >> That's a huge issue for my project. I'm trying to leverage the DLR and >> IronPython on a ASP.NET application that targets 3.5. I hope there is >> a work-around. >> >> 2008/8/19 Dody Gunawinata : >> > - This pretty much locks up IronPython 2 from any .Net 3.5 based >> website. >> > The ASP.Net MVC framework is based on .Net 3.5 too and they use a bunch >> of >> > System.Core facilities in their code base. The nicest thing about .Net >> 3.5 >> > is to be able to use LINQ on code behind and right now when I compile my >> > application, I got a bunch of warnings about duplicated LINQ definition >> > methods existing in 2 assemblies. Now I cannot use Action<> or Func<> in >> > code behind. >> > >> > - I think this will prevent the next IP for ASP.Net to be able to use >> .Net >> > 3.5 libraries. >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> >> >> -- >> nomadlife.org >> >> >> >> >> -- >> nomadlife.org >> >> >> >> >> -- >> nomadlife.org >> >> >> >> >> -- >> nomadlife.org >> >> >> >> >> -- >> nomadlife.org >> > > > > -- > nomadlife.org > > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Aug 19 20:38:55 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 19 Aug 2008 11:38:55 -0700 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8140eff40808191132i5edafdcdx2cc1394b5a9104f0@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808191012g1d74eb81pb64694c8b88c215@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A331480@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191046x514c214clad95d1f2c358a419@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314ED@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191108t903aa02sbc6264d4e12dd736@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33154F@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191122m3014781cy4b256a74ec63630a@mail.gmail.com> <8140eff40808191132i5edafdcdx2cc1394b5a9104f0@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355421A3315A4@NA-EXMSG-C102.redmond.corp.microsoft.com> I'm continuing to look into it... We're going to have conflicting names because Microsoft.Scripting.Core includes a superset of the functionality in the v3.5 System.Core - and changing that would complicate our internal builds quite a bit. But hopefully we can find a way to get the aliases working in web site mode. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia Sent: Tuesday, August 19, 2008 11:33 AM To: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) This issue is very bad for my project too. Do you think there is a way we can make IronPython compatible with the Framework 3.5? I find it appalling that we even have to consider that... _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From ronnie.maor at gmail.com Tue Aug 19 20:40:55 2008 From: ronnie.maor at gmail.com (Ronnie Maor) Date: Tue, 19 Aug 2008 21:40:55 +0300 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <350E7D38B6D819428718949920EC2355421A3313AE@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> <48A5CD9F.3070608@voidspace.org.uk> <350E7D38B6D819428718949920EC2355421A3313AE@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <2fd6b9d0808191140q3967b93cu8bbddd4f81166cd2@mail.gmail.com> nice! thanks for **kw fix. that was really bugging us. looks like 2.0b5 is where we'll start seriously looking at switching to 2.0. do you know when it's expected? On Tue, Aug 19, 2008 at 7:09 PM, Dino Viehland wrote: > The fixes for these (specifically the ones I said I had fixes for :) ) are > now checked in and the next source code push (as well as Beta 5) will have > the fixes. > > In addition to these issues I've fixed the **kw perf bug recently reported > (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17679). > I've also attempted to remove some of the overhead of using sets - we had > an extra level of indirection that wasn't necessary and we could also reduce > some hashing (where we'd hash twice) we had to do now that we don't use .NET > dictionaries directly. It'd be interesting to see if that helps on your > machine which shows sets running slowly on or not. Finally creation of > instances w/ __slots__ was horribly slow and that's fixed as well. Here's > the code review mail if anyone's interested in the details: > > DLR: OptimizedScriptCode shouldn't be re-writing the AST every time > through. I've added a cache so we'll only re-write it once. > > Python: > Speed up dictionary creation by avoding repeated locking. > Now we new up an object array w/ the values and pass it off to create in > one action. > > List addition should leave a little bit of buffer room for > further operations, also adding fast paths for extend with well known types. > Finally switching OrderedLocker to being a struct and ensuring it handles > the case where the objects are the same. > > Set: Removing a level of indirection - we now hold directly > onto a CommonDictionaryStorage instead of going through PythonDictionary for > the same effect. I've also removed several __contains__ checks which aren't > necessary because CommonDictionaryStorage guarantees the correct semantics > (replacing an existing value only updates the keys) > > PythonFunction - speed up function creation by looking > directly in the global scope dict and creating the FunctinoCode. Lazily > creating this does no good as it's always created and the > Interlocked.CompareExchange call isn't cheap. > > Calling new-style classes no longer looks up __init__, it now just does a > TryGetBoundValue on it. > > Creating instances of types w/ __slots__ is very slow. > Switched to using an object array and we no longer require code gen for > generating the accesors. This all around simplifies the NewTypeMaker code > as well as the ReflectedSlotProperty code. > > 17679 - Performance issue when calling a function with **kw > We now go through the DictionaryStorage Clone API when we > have a Python dictionary. Also added "HasNonStringAttributes" method onto > DictionaryStorage which SymbolId dicts can optimize away. But > CommonDictionaryStorage can also optimize it by avoiding lots of locking. > Finally we now throw a reasonable exception when we don't get a dictionary. > > Also making EnvironmentDictionaryStorage not inherit from > CommonDictionaryStorage. AddNoLock was certainly not doing the right thing > and this way it's clearer what's going on there. > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, August 15, 2008 11:41 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython > 1 > > Dino Viehland wrote: > > Ok, I looked into a bunch of these and here's what I've discovered so far > and other random comments... > > > > Exceptions (100000): 40% slower > > IP1: 4703 > > IP2: 6125 > > Py: 266 > > > > I haven't looked at this one yet. I do know that we have a number of bug > fixes for our exception handling which will slow it down though. I don't > consider this to be a high priority though. If we wanted to focus on > exception perf I think we'd want to do something radical rather than small > tweaks to the existing code. If there's certain scenarios where exception > perf is critical though it'd be interesting to hear about those and if we > can do anything to improve them. > > > > > I can look at this. > > > Engine execution: 8000% slower!! > > IP1: 1600 > > IP2: 115002 > > > > This is just a silly bug. We're doing a tree re-write of the AST and we > do that every time through. Caching that re-write gets us back to 1.x > performance. I have a fix for this. > > > > Great! (1.x performance was very impressive.) > > > Create function: 25% slower > > IP1: 2828 > > IP2: 3640 > > Py: 2766 > > > > Part of this is from a bug fix but the fix could be more efficient. In > 1.x we don't look up __module__ from the global scope. In 2.x we do this > lookup but it searches all scopes - which isn't even correct. But we can do > a direct lookup which is a little faster - so I have a partial fix for this. > This will still be a little slower than 1.x though. > > > > > Ok. > > > Define oldstyle (1 000 000): 33% slower > > IP1: 1781 > > IP2: 2671 > > Py: 2108 > > > > Is this critical? I'd rather just live w/ the slowness rather than > fixing something that will be gone in 3.x :) > > > > > > Not a problem for us - I merely noted it. In 1.x we needed to switch a > few classes to old style for performance reasons (but we don't > repeatedly redefine them - it was instantiation time). In 2.x we will > need to switch back (which is great). > > > Lists (10 000): 50% slower > > IP1: 10422 > > IP2: 16109 > > Py: 6094 > > > > The primary issue here is that adding 2 lists ends up creating a new list > whose storage is the exact size needed for storing the two lists. When you > append to it after adding it we need to allocate a brand new array - and > you're not dealing with small arrays here. We can add a little extra space > depending on the size of the array to minimize the chance of needing a > re-size. That gets us to about 10% slower than CPython. I'm also going to > add a strongly typed extend overload which should make those calls a little > faster. > > > > > > Python lists will typically grow to always have a lot of space. Creating > a list with no extra space seems like a problem. My benchmark for this > was unrealistic though (we add lists and extend them a lot - but > typically they're nothing like that size). > > > > Sets2 (100 000): 500% slower > > IP1: 4984 > > IP2: 30547 > > Py: 1203 > > > > This one I actually cannot repro yet (I've tried it on 3 machines but > they've all been Vista). I'm going to try next on a Srv 2k3 machine and see > if I can track it down. But more information would be useful. > > > > Hmmm... I wonder if it is an oddity with my machine. Unfortunately I am > not at work today and can't repeat it. I've just run it on Vista (.NET > 2.0.50727.3053) running under VMWare Fusion (but on a kick-arse machine). > > IP1.1.2: 3515 > IP2.0B4: 2516 > > I need to rerun the whole Resolver port on someone else's machine. > > > Comparing (== and !=): > > IP1: 278597 > > IP2: 117662 > > > > This one is actually pretty interesting (even though we're faster in 2.x) > - there's an issue with the test here. You've defined "__neq__" instead of > "__ne__". > > Ha! Oops. :-) > > That causes the != comparison to ultimately compare based upon object > identity - which is extremely slow. There might be some things we can do to > make the object identity comparison faster (For example recognizing that > we're doing equality and just need a eq or ne answer rather than a 1, -1, 0 > comparison value). But I'm going to assume comparing on object identity > isn't very important right now - let me know if I'm wrong. > We do use identity comparison a lot - but I'm not sure if it is in > performance critical parts of our code. I can review this. > > > But switching this to __ne__ causes us to be a little faster than > CPython. They have a great advantage on object identity comparisons - they > can just use the objects address. > > > > > Sure. > > > I was also curious what happens to this case if we use __slots__. That > identified yet another massive performance regression which I have a fix for > - creating instances that have __slots__ defined is horribly slow. With > that bug fixed and using slots and __ne__ instead of __neq__ we can actually > run this over 2x faster than CPython (on Vista x86 .NET 3.5SP1 on a 2.4ghz > Core 2 w/ 4gb of RAM). > > > > > Cool. > > Michael > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > > Sent: Thursday, August 14, 2008 9:42 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and > IronPython 1 > > > > Just for fun I also compared with CPython. The results are interesting, > I'll turn it into a blog post of course... > > > > Results in milliseconds with a granularity of about 15ms and so an > accuracy of +/- ~60ms. > > All testing with 10 000 000 operations unless otherwise stated. > > > > The version of Python I compared against was Python 2.4. > > > > Empty loop (overhead): > > IP1: 422 > > IP2: 438 > > Py: 3578 > > > > Create instance newstyle: > > IP1: 20360 > > IP2: 1109 > > Py: 4063 > > > > Create instance oldstyle: > > IP1: 3766 > > IP2: 3359 > > Py: 4797 > > > > Function call: > > IP1: 937 > > IP2: 906 > > Py: 3313 > > > > Create function: 25% slower > > IP1: 2828 > > IP2: 3640 > > Py: 2766 > > > > Define newstyle (1 000 000): > > IP1: 42047 > > IP2: 20484 > > Py: 23921 > > > > Define oldstyle (1 000 000): 33% slower > > IP1: 1781 > > IP2: 2671 > > Py: 2108 > > > > Comparing (== and !=): > > IP1: 278597 > > IP2: 117662 > > Py: 62423 > > > > Sets: > > IP1: 37095 > > IP2: 30860 > > Py: 8047 > > > > Lists (10 000): 50% slower > > IP1: 10422 > > IP2: 16109 > > Py: 6094 > > > > Recursion (10 000): > > IP1: 1125 > > IP2: 1000 > > Py: 3609 > > > > Sets2 (100 000): 500% slower > > IP1: 4984 > > IP2: 30547 > > Py: 1203 > > > > func_with_args: > > IP1: 6312 > > IP2: 5906 > > Py: 11250 > > > > method_with_args: > > IP1: 20594 > > IP2: 11813 > > Py: 14875 > > > > method_with_kwargs: > > IP1: 27953 > > IP2: 11187 > > Py: 20032 > > > > import: 15% slower > > IP1: 28469 > > IP2: 32000 > > Py: 25782 > > > > global: 20% slower > > IP1: 1047 > > IP2: 1203 > > Py: 4141 > > > > Exceptions (100000): 40% slower > > IP1: 4703 > > IP2: 6125 > > Py: 266 > > > > Engine execution: 8000% slower!! > > IP1: 1600 > > IP2: 115002 > > > > > > Michael Foord wrote: > > > >> Hello all, > >> > >> I've ported Resolver One to run on IronPython 2 Beta 4 to check for > >> any potential problems (we will only do a *proper* port once IP 2 is > >> out of beta). > >> > >> The basic porting was straightforward and several bugs have been fixed > >> since IP 2 B3 - many thanks to the IronPython team. > >> > >> The good news is that Resolver One is only 30-50% slower than Resolver > >> One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) > >> Resolver One is fairly heavily optimised around the performance > >> hotspots of IronPython 1, so we expect to have to do a fair bit of > >> profiling and refactoring to readjust to the performance profile of IP > 2. > >> > >> Having said that, there are a few oddities (and the areas that slow > >> down vary tremendously depending on which spreadsheet we use to > >> benchmark it - making it fairly difficult to track down the hotspots). > >> > >> We have one particular phase of spreadsheet calculation that takes > >> 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing > >> some micro-benchmarking to try and identify the hotspot. I've > >> certainly found part of the problem. > >> > >> For those that are interested I've attached the very basic > >> microbenchmarks I've been using. The nice thing is that in *general* > >> IP2 does outperform IP1. > >> > >> The results that stand out in the other direction are: > >> > >> Using sets with custom classes (that define '__eq__', '__ne__' and > >> '__hash__') seems to be 6 times slower in IronPython 2. > >> > >> Adding lists together is about 50% slower. > >> > >> Defining functions seems to be 25% slower and defining old style > >> classes about 33% slower. (Creating instances of new style classes is > >> massively faster though - thanks!) > >> > >> The code I used to test sets (sets2.py) is as follows: > >> > >> from System import DateTime > >> > >> class Thing(object): > >> def __init__(self, val): > >> self.val = val > >> def __eq__(self, other): > >> return self.val == other.val > >> > >> def __neq__(self): > >> return not self.__eq__(other) > >> def __hash__(self): > >> return hash(self.val) > >> def test(s): > >> a = set() > >> for i in xrange(100000): > >> a.add(Thing(i)) > >> a.add(Thing(i+1)) > >> Thing(i) in a > >> Thing(i+2) in a > >> return (DateTime.Now -s).TotalMilliseconds > >> s = DateTime.Now > >> print test(s) > >> > >> > >> Interestingly the time taken is exactly the same if I remove the > >> definition of '__hash__'. > >> > >> The full set of results below: > >> > >> Results in milliseconds with a granularity of about 15ms and so an > >> accuracy of +/- ~60ms. > >> All testing with 10 000 000 operations unless otherwise stated. > >> > >> Empty loop (overhead): > >> IP1: 421.9 > >> IP2: 438 > >> Create instance newstyle: > >> IP1: 20360 > >> IP2: 1109 > >> Create instance oldstyle: > >> IP1: 3766 > >> IP2: 3359 > >> Function call: > >> IP1: 937 > >> IP2: 906 > >> Create function: 25% slower > >> IP1: 2828 > >> IP2: 3640 > >> Define newstyle (1 000 000): > >> IP1: 42047 > >> IP2: 20484 > >> Define oldstyle (1 000 000): 33% slower > >> IP1: 1781 > >> IP2: 2671 > >> > >> Comparing (== and !=): > >> IP1: 278597 > >> IP2: 117662 > >> Sets (with numbers): > >> IP1: 37095 > >> IP2: 30860 > >> > >> Lists (10 000): 50% slower > >> IP1: 10422 > >> IP2: 16109 > >> > >> Recursion (10 000): > >> IP1: 1125 > >> IP2: 1000 > >> > >> Sets2 (100 000): 600% slower > >> IP1: 4984 > >> IP2: 30547 > >> > >> > >> I'll be doing more as the 600% slow down for sets and the 50% slow > >> down for lists accounts for some of the dependency analysis problem > >> but not all of it. > >> > >> Many Thanks > >> > >> Michael Foord > >> -- > >> http://www.resolversystems.com > >> 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/ > > http://www.voidspace.org.uk/ > > http://www.trypython.org/ > > http://www.ironpython.info/ > > http://www.resolverhacks.net/ > > http://www.theotherdelia.co.uk/ > > > > _______________________________________________ > > 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/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.theotherdelia.co.uk/ > http://www.resolverhacks.net/ > > _______________________________________________ > 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 Aug 19 20:47:10 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 19 Aug 2008 11:47:10 -0700 Subject: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 In-Reply-To: <2fd6b9d0808191140q3967b93cu8bbddd4f81166cd2@mail.gmail.com> References: <48A42FD7.5090509@resolversystems.com> <48A46054.2040600@voidspace.org.uk> <48A5CD9F.3070608@voidspace.org.uk> <350E7D38B6D819428718949920EC2355421A3313AE@NA-EXMSG-C102.redmond.corp.microsoft.com> <2fd6b9d0808191140q3967b93cu8bbddd4f81166cd2@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355421A3315C0@NA-EXMSG-C102.redmond.corp.microsoft.com> Somewhere around 4 weeks from now. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ronnie Maor Sent: Tuesday, August 19, 2008 11:41 AM To: Discussion of IronPython Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 nice! thanks for **kw fix. that was really bugging us. looks like 2.0b5 is where we'll start seriously looking at switching to 2.0. do you know when it's expected? On Tue, Aug 19, 2008 at 7:09 PM, Dino Viehland > wrote: The fixes for these (specifically the ones I said I had fixes for :) ) are now checked in and the next source code push (as well as Beta 5) will have the fixes. In addition to these issues I've fixed the **kw perf bug recently reported (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17679). I've also attempted to remove some of the overhead of using sets - we had an extra level of indirection that wasn't necessary and we could also reduce some hashing (where we'd hash twice) we had to do now that we don't use .NET dictionaries directly. It'd be interesting to see if that helps on your machine which shows sets running slowly on or not. Finally creation of instances w/ __slots__ was horribly slow and that's fixed as well. Here's the code review mail if anyone's interested in the details: DLR: OptimizedScriptCode shouldn't be re-writing the AST every time through. I've added a cache so we'll only re-write it once. Python: Speed up dictionary creation by avoding repeated locking. Now we new up an object array w/ the values and pass it off to create in one action. List addition should leave a little bit of buffer room for further operations, also adding fast paths for extend with well known types. Finally switching OrderedLocker to being a struct and ensuring it handles the case where the objects are the same. Set: Removing a level of indirection - we now hold directly onto a CommonDictionaryStorage instead of going through PythonDictionary for the same effect. I've also removed several __contains__ checks which aren't necessary because CommonDictionaryStorage guarantees the correct semantics (replacing an existing value only updates the keys) PythonFunction - speed up function creation by looking directly in the global scope dict and creating the FunctinoCode. Lazily creating this does no good as it's always created and the Interlocked.CompareExchange call isn't cheap. Calling new-style classes no longer looks up __init__, it now just does a TryGetBoundValue on it. Creating instances of types w/ __slots__ is very slow. Switched to using an object array and we no longer require code gen for generating the accesors. This all around simplifies the NewTypeMaker code as well as the ReflectedSlotProperty code. 17679 - Performance issue when calling a function with **kw We now go through the DictionaryStorage Clone API when we have a Python dictionary. Also added "HasNonStringAttributes" method onto DictionaryStorage which SymbolId dicts can optimize away. But CommonDictionaryStorage can also optimize it by avoiding lots of locking. Finally we now throw a reasonable exception when we don't get a dictionary. Also making EnvironmentDictionaryStorage not inherit from CommonDictionaryStorage. AddNoLock was certainly not doing the right thing and this way it's clearer what's going on there. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, August 15, 2008 11:41 AM To: Discussion of IronPython Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 Dino Viehland wrote: > Ok, I looked into a bunch of these and here's what I've discovered so far and other random comments... > > Exceptions (100000): 40% slower > IP1: 4703 > IP2: 6125 > Py: 266 > > I haven't looked at this one yet. I do know that we have a number of bug fixes for our exception handling which will slow it down though. I don't consider this to be a high priority though. If we wanted to focus on exception perf I think we'd want to do something radical rather than small tweaks to the existing code. If there's certain scenarios where exception perf is critical though it'd be interesting to hear about those and if we can do anything to improve them. > > I can look at this. > Engine execution: 8000% slower!! > IP1: 1600 > IP2: 115002 > > This is just a silly bug. We're doing a tree re-write of the AST and we do that every time through. Caching that re-write gets us back to 1.x performance. I have a fix for this. > Great! (1.x performance was very impressive.) > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Py: 2766 > > Part of this is from a bug fix but the fix could be more efficient. In 1.x we don't look up __module__ from the global scope. In 2.x we do this lookup but it searches all scopes - which isn't even correct. But we can do a direct lookup which is a little faster - so I have a partial fix for this. This will still be a little slower than 1.x though. > > Ok. > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > Py: 2108 > > Is this critical? I'd rather just live w/ the slowness rather than fixing something that will be gone in 3.x :) > > Not a problem for us - I merely noted it. In 1.x we needed to switch a few classes to old style for performance reasons (but we don't repeatedly redefine them - it was instantiation time). In 2.x we will need to switch back (which is great). > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > Py: 6094 > > The primary issue here is that adding 2 lists ends up creating a new list whose storage is the exact size needed for storing the two lists. When you append to it after adding it we need to allocate a brand new array - and you're not dealing with small arrays here. We can add a little extra space depending on the size of the array to minimize the chance of needing a re-size. That gets us to about 10% slower than CPython. I'm also going to add a strongly typed extend overload which should make those calls a little faster. > > Python lists will typically grow to always have a lot of space. Creating a list with no extra space seems like a problem. My benchmark for this was unrealistic though (we add lists and extend them a lot - but typically they're nothing like that size). > Sets2 (100 000): 500% slower > IP1: 4984 > IP2: 30547 > Py: 1203 > > This one I actually cannot repro yet (I've tried it on 3 machines but they've all been Vista). I'm going to try next on a Srv 2k3 machine and see if I can track it down. But more information would be useful. > Hmmm... I wonder if it is an oddity with my machine. Unfortunately I am not at work today and can't repeat it. I've just run it on Vista (.NET 2.0.50727.3053) running under VMWare Fusion (but on a kick-arse machine). IP1.1.2: 3515 IP2.0B4: 2516 I need to rerun the whole Resolver port on someone else's machine. > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > > This one is actually pretty interesting (even though we're faster in 2.x) - there's an issue with the test here. You've defined "__neq__" instead of "__ne__". Ha! Oops. :-) > That causes the != comparison to ultimately compare based upon object identity - which is extremely slow. There might be some things we can do to make the object identity comparison faster (For example recognizing that we're doing equality and just need a eq or ne answer rather than a 1, -1, 0 comparison value). But I'm going to assume comparing on object identity isn't very important right now - let me know if I'm wrong. We do use identity comparison a lot - but I'm not sure if it is in performance critical parts of our code. I can review this. > But switching this to __ne__ causes us to be a little faster than CPython. They have a great advantage on object identity comparisons - they can just use the objects address. > > Sure. > I was also curious what happens to this case if we use __slots__. That identified yet another massive performance regression which I have a fix for - creating instances that have __slots__ defined is horribly slow. With that bug fixed and using slots and __ne__ instead of __neq__ we can actually run this over 2x faster than CPython (on Vista x86 .NET 3.5SP1 on a 2.4ghz Core 2 w/ 4gb of RAM). > > Cool. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, August 14, 2008 9:42 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 > > Just for fun I also compared with CPython. The results are interesting, I'll turn it into a blog post of course... > > Results in milliseconds with a granularity of about 15ms and so an accuracy of +/- ~60ms. > All testing with 10 000 000 operations unless otherwise stated. > > The version of Python I compared against was Python 2.4. > > Empty loop (overhead): > IP1: 422 > IP2: 438 > Py: 3578 > > Create instance newstyle: > IP1: 20360 > IP2: 1109 > Py: 4063 > > Create instance oldstyle: > IP1: 3766 > IP2: 3359 > Py: 4797 > > Function call: > IP1: 937 > IP2: 906 > Py: 3313 > > Create function: 25% slower > IP1: 2828 > IP2: 3640 > Py: 2766 > > Define newstyle (1 000 000): > IP1: 42047 > IP2: 20484 > Py: 23921 > > Define oldstyle (1 000 000): 33% slower > IP1: 1781 > IP2: 2671 > Py: 2108 > > Comparing (== and !=): > IP1: 278597 > IP2: 117662 > Py: 62423 > > Sets: > IP1: 37095 > IP2: 30860 > Py: 8047 > > Lists (10 000): 50% slower > IP1: 10422 > IP2: 16109 > Py: 6094 > > Recursion (10 000): > IP1: 1125 > IP2: 1000 > Py: 3609 > > Sets2 (100 000): 500% slower > IP1: 4984 > IP2: 30547 > Py: 1203 > > func_with_args: > IP1: 6312 > IP2: 5906 > Py: 11250 > > method_with_args: > IP1: 20594 > IP2: 11813 > Py: 14875 > > method_with_kwargs: > IP1: 27953 > IP2: 11187 > Py: 20032 > > import: 15% slower > IP1: 28469 > IP2: 32000 > Py: 25782 > > global: 20% slower > IP1: 1047 > IP2: 1203 > Py: 4141 > > Exceptions (100000): 40% slower > IP1: 4703 > IP2: 6125 > Py: 266 > > Engine execution: 8000% slower!! > IP1: 1600 > IP2: 115002 > > > Michael Foord wrote: > >> Hello all, >> >> I've ported Resolver One to run on IronPython 2 Beta 4 to check for >> any potential problems (we will only do a *proper* port once IP 2 is >> out of beta). >> >> The basic porting was straightforward and several bugs have been fixed >> since IP 2 B3 - many thanks to the IronPython team. >> >> The good news is that Resolver One is only 30-50% slower than Resolver >> One on IronPython 1! (It was 300 - 400% slower on top of IP 2 B3.) >> Resolver One is fairly heavily optimised around the performance >> hotspots of IronPython 1, so we expect to have to do a fair bit of >> profiling and refactoring to readjust to the performance profile of IP 2. >> >> Having said that, there are a few oddities (and the areas that slow >> down vary tremendously depending on which spreadsheet we use to >> benchmark it - making it fairly difficult to track down the hotspots). >> >> We have one particular phase of spreadsheet calculation that takes >> 0.4seconds on IP1 and around 6 seconds on IP2, so I have been doing >> some micro-benchmarking to try and identify the hotspot. I've >> certainly found part of the problem. >> >> For those that are interested I've attached the very basic >> microbenchmarks I've been using. The nice thing is that in *general* >> IP2 does outperform IP1. >> >> The results that stand out in the other direction are: >> >> Using sets with custom classes (that define '__eq__', '__ne__' and >> '__hash__') seems to be 6 times slower in IronPython 2. >> >> Adding lists together is about 50% slower. >> >> Defining functions seems to be 25% slower and defining old style >> classes about 33% slower. (Creating instances of new style classes is >> massively faster though - thanks!) >> >> The code I used to test sets (sets2.py) is as follows: >> >> from System import DateTime >> >> class Thing(object): >> def __init__(self, val): >> self.val = val >> def __eq__(self, other): >> return self.val == other.val >> >> def __neq__(self): >> return not self.__eq__(other) >> def __hash__(self): >> return hash(self.val) >> def test(s): >> a = set() >> for i in xrange(100000): >> a.add(Thing(i)) >> a.add(Thing(i+1)) >> Thing(i) in a >> Thing(i+2) in a >> return (DateTime.Now -s).TotalMilliseconds >> s = DateTime.Now >> print test(s) >> >> >> Interestingly the time taken is exactly the same if I remove the >> definition of '__hash__'. >> >> The full set of results below: >> >> Results in milliseconds with a granularity of about 15ms and so an >> accuracy of +/- ~60ms. >> All testing with 10 000 000 operations unless otherwise stated. >> >> Empty loop (overhead): >> IP1: 421.9 >> IP2: 438 >> Create instance newstyle: >> IP1: 20360 >> IP2: 1109 >> Create instance oldstyle: >> IP1: 3766 >> IP2: 3359 >> Function call: >> IP1: 937 >> IP2: 906 >> Create function: 25% slower >> IP1: 2828 >> IP2: 3640 >> Define newstyle (1 000 000): >> IP1: 42047 >> IP2: 20484 >> Define oldstyle (1 000 000): 33% slower >> IP1: 1781 >> IP2: 2671 >> >> Comparing (== and !=): >> IP1: 278597 >> IP2: 117662 >> Sets (with numbers): >> IP1: 37095 >> IP2: 30860 >> >> Lists (10 000): 50% slower >> IP1: 10422 >> IP2: 16109 >> >> Recursion (10 000): >> IP1: 1125 >> IP2: 1000 >> >> Sets2 (100 000): 600% slower >> IP1: 4984 >> IP2: 30547 >> >> >> I'll be doing more as the 600% slow down for sets and the 50% slow >> down for lists accounts for some of the dependency analysis problem >> but not all of it. >> >> Many Thanks >> >> Michael Foord >> -- >> http://www.resolversystems.com >> 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/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > http://www.theotherdelia.co.uk/ > > _______________________________________________ > 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/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ _______________________________________________ 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 empirebuilder at gmail.com Tue Aug 19 21:01:23 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 19 Aug 2008 22:01:23 +0300 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <350E7D38B6D819428718949920EC2355421A3315A4@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191046x514c214clad95d1f2c358a419@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314ED@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191108t903aa02sbc6264d4e12dd736@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33154F@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191122m3014781cy4b256a74ec63630a@mail.gmail.com> <8140eff40808191132i5edafdcdx2cc1394b5a9104f0@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3315A4@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <8cd017b80808191201n15e80c56i72ae612efdde3f35@mail.gmail.com> OK. Thanks a lot. In the meantime, I'll proceed try to modifying the namespaces in Microsoft.Scripting.Core (if it's actually possible. Hopefully there's no internal classes being used) Dody G. On Tue, Aug 19, 2008 at 9:38 PM, Dino Viehland wrote: > I'm continuing to look into it... We're going to have conflicting names > because Microsoft.Scripting.Core includes a superset of the functionality in > the v3.5 System.Core - and changing that would complicate our internal > builds quite a bit. But hopefully we can find a way to get the aliases > working in web site mode. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Fernando Correia > Sent: Tuesday, August 19, 2008 11:33 AM > To: Discussion of IronPython > Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) > > This issue is very bad for my project too. Do you think there is a way > we can make IronPython compatible with the Framework 3.5? > > I find it appalling that we even have to consider that... > _______________________________________________ > 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 ronnie.maor at gmail.com Tue Aug 19 21:02:01 2008 From: ronnie.maor at gmail.com (Ronnie Maor) Date: Tue, 19 Aug 2008 22:02:01 +0300 Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes In-Reply-To: References: Message-ID: <2fd6b9d0808191202y2adfc3e5q75879f5a1bec4174@mail.gmail.com> we are currently running it on 32 bit OSes only. Windows 2003 and XP. On Tue, Aug 19, 2008 at 12:42 AM, Dave Fugate wrote: > Hi everyone, one of the things the IronPython test team does daily is run > a set of standardized benchmarks against the latest internal build of > IronPython. We're in the process of reevaluating the platforms we measure > these benchmarks on with the end goal of increasing the number of tests we > can run. For example, if we could cut x64 Vista from the list of platforms, > the x64 Vista machine(s) could be reimaged to run *new* benchmarks we > wouldn't have had the resources for before. Alternatively, we might reimage > the x64 Vista machine(s) as some other platform we don't currently test > under. Of course in such a scenario we'd still run other classifications of > tests under x64 Vista. > > > > I wanted to hear peoples' opinions on the importance of measuring > IronPython performance under x64 Windows OSes before we make any decisions > on this. First off, how many people out there are actually running > IronPython under a 64-bit OS? Would it be sufficient for us to report news > on IronPython performance in terms of 32-bit platforms? > > > > Thanks, > > > > The IronPython Team > > _______________________________________________ > 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 Aug 19 23:03:23 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 19 Aug 2008 14:03:23 -0700 Subject: [IronPython] defined in multiple assemblies (framework 3.5) In-Reply-To: <8cd017b80808191201n15e80c56i72ae612efdde3f35@mail.gmail.com> References: <8140eff40808181153t34eead77u54fddfd40e3558a@mail.gmail.com> <8cd017b80808191023u5dce211eq12d075d1737bf807@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191046x514c214clad95d1f2c358a419@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3314ED@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191108t903aa02sbc6264d4e12dd736@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A33154F@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191122m3014781cy4b256a74ec63630a@mail.gmail.com> <8140eff40808191132i5edafdcdx2cc1394b5a9104f0@mail.gmail.com> <350E7D38B6D819428718949920EC2355421A3315A4@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80808191201n15e80c56i72ae612efdde3f35@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355421A331786@NA-EXMSG-C102.redmond.corp.microsoft.com> Ok, I believe I've gotten this to work. I know very little about ASP.NET so I'm just going to walk through the steps to setup a new Web Site which can use the DLR. The key limitation here is that if you're referring to a type out of Microsoft.Scripting.Core.dll you'll need to do it from a .CS file. If you like inline