From ironpython at alexh.sent.com Fri Oct 1 10:07:00 2004 From: ironpython at alexh.sent.com (Alex Hoffman) Date: Fri, 01 Oct 2004 18:07:00 +1000 Subject: [IronPython] Re: users-ironpython.com Digest, Vol 2, Issue 18 In-Reply-To: <008901c4a551$64aba100$0100a8c0@vulcain> References: <20040924193401.89823.qmail@web14302.mail.yahoo.com> <008901c4a551$64aba100$0100a8c0@vulcain> Message-ID: <415D1024.80906@alexh.sent.com> >>> ... could be embedded into your application ... I'm not too sure that would work. IronPython generates assemblies which would be loaded into the primary AppDomain. Because they cannot be unloaded (until end of process), additional memory would be consumed each time a script was compiled. Somehow loading generated assemblies into a second AppDomain wouldn't really work either, because then one would have to use remoting just to communicate with your apps functionality. Alex Hoffman Lloyd Dupont wrote: > I've been confirmed beta tester of MSH, should be able to start > testing tomorrow (well, this wek-end) > however I have the feeling, somehow, that python has a definitive edge > which is: > > Python could be embeded into your application, to provide configurable > UI. > Well, any kind of configuration in fact, that's really great! > Infact even run-time modification (maybe there is security setting to > investigate before though :S) > > > ----- Original Message ----- From: "Randall Burns" > > To: > Sent: Saturday, September 25, 2004 5:34 AM > Subject: [IronPython] Re: users-ironpython.com Digest, Vol 2, Issue 18 > > >> How do folks see the new Microsoft command shell >> relates to IronPython? Will Iron Python be able to >> leverage any of this work? >> >> http://developers.slashdot.org/article.pl?sid=04/09/21/0153251&tid=201&tid=156&tid=8 >> >> >> >> >> __________________________________ >> Do you Yahoo!? >> New and Improved Yahoo! Mail - Send 10MB messages! >> http://promotions.yahoo.com/new_mail >> _______________________________________________ >> users-ironpython.com mailing list >> users-ironpython.com at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From ironpython at alexh.sent.com Fri Oct 1 10:11:39 2004 From: ironpython at alexh.sent.com (Alex Hoffman) Date: Fri, 01 Oct 2004 18:11:39 +1000 Subject: [IronPython] Re: MSH vs IronPython In-Reply-To: References: Message-ID: <415D113B.2060603@alexh.sent.com> I couldn't have said it better myself :) Larry O'Brien wrote: >>>What capabilities does MSH have that couldn't be added to Python (or some >>>other extensible scriptable language) by building an appropriate library? >>> >>> > >I suspect that the lion's share of work in MSH has not been the scripting >syntax but has had to do with the infrastructure for creating a "pipes and >filters" shell architecture that passes around .NET objects. > >I agree that there are aspects of the MSH syntax that seem gratuitously >contrarian -- after 15 years of training the developer community to think >"noun.verb()" they adopt "verb-noun". But it's not really the developers to >whom they're trying to give a tool, it's the administrators (there's >overlap, but not nearly complete) and perhaps in some usability study >"verb-noun" has been shown... I dunno', seems gratuitous to me. > >But I think it would be a mistake to assume that a Python interactive prompt >would _necessarily_ be more productive and easier to understand by the >majority of users. In the best of all possible worlds, I would love to have >a .profile that essentially provided a Python console as _my_ interactive >prompt but which would still support push-location pop-location. And Joe >Administrator can have a "pure" MSH shell and Jane Unix could have a >bash-like shell. > >I don't know if MS has made any statements about whether that kind of >customization will be possible within MSH. > >Cheers, >Larry > > > > >_______________________________________________ >users-ironpython.com mailing list >users-ironpython.com at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From senthilkumar.chockalingam at kla-tencor.com Fri Oct 1 12:28:25 2004 From: senthilkumar.chockalingam at kla-tencor.com (senthilkumar) Date: Fri, 1 Oct 2004 15:58:25 +0530 Subject: [IronPython] How to catch exception Message-ID: How to use try-catch block in the python file. I want to write my block of code within try catch block. The code may be instance of component in GAC and its method invocation. Thanks and Regards Senthil Kumar From l.oluyede at gmail.com Fri Oct 1 13:21:42 2004 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Fri, 1 Oct 2004 13:21:42 +0200 Subject: [IronPython] How to catch exception In-Reply-To: References: Message-ID: <9eebf574041001042140c4b941@mail.gmail.com> On Fri, 1 Oct 2004 15:58:25 +0530, senthilkumar wrote: > How to use try-catch block in the python file. I want to write my block of > code within try catch block. The code may be instance of component in GAC > and its method invocation. Python does have: try...except or try..finally try: # your code except: # handle the exception For more info see there: http://docs.python.org/tut/node10.html -- Lawrence "If the implementation is hard to explain, it's a bad idea." from The Zen of Python by Tim Peters From rodsenra at gpr.com.br Fri Oct 1 14:37:57 2004 From: rodsenra at gpr.com.br (Rodrigo Senra) Date: Fri, 1 Oct 2004 09:37:57 -0300 Subject: [IronPython] Re: MSH vs IronPython In-Reply-To: References: <4.3.2.7.2.20040930104423.05093130@mail.comcast.net> Message-ID: <20041001093757.4eb22f6f@fenix.gpr.com.br> On Thu, 30 Sep 2004 07:21:35 -1000 "Larry O'Brien" wrote about RE: [IronPython] Re: MSH vs IronPython: -------------------------------------------- | >>What capabilities does MSH have that couldn't be added to Python (or some | >>other extensible scriptable language) by building an appropriate library? | | | I agree that there are aspects of the MSH syntax that seem gratuitously | contrarian +1 | But I think it would be a mistake to assume that a Python interactive prompt | would _necessarily_ be more productive Well, for me ipython *is* more productive (http://ipython.scipy.org/) If you haven't tried it yet, you ought to. | and easier to understand by the majority of users. That is something very hard to define: the majority of users. But, I doubt that those in need for a scripting shell would feel greater difficulty with a python-based one than with MSH. | In the best of all possible worlds, I would love to have | a .profile that essentially provided a Python console as _my_ interactive | prompt but which would still support push-location pop-location. And Joe | Administrator can have a "pure" MSH shell and Jane Unix could have a | bash-like shell. I do sympathize wuth this view. However, it raises the issue of script portability. That was one of the reasons I started to use Python for admins scripts whenever possible. best regards, Rod Senra From jvm_cop at spamcop.net Fri Oct 1 17:12:12 2004 From: jvm_cop at spamcop.net (J. Merrill) Date: Fri, 01 Oct 2004 11:12:12 -0400 Subject: [IronPython] Re: MSH vs IronPython In-Reply-To: <20041001093757.4eb22f6f@fenix.gpr.com.br> References: <4.3.2.7.2.20040930104423.05093130@mail.comcast.net> Message-ID: <4.3.2.7.2.20041001111028.051e53b0@mail.comcast.net> I had been ignorant of this. What's the relationship between this project and JimH's original IronPython project? If it started with the same code and is being more actively developed, I'm on board!! At 08:37 AM 10/1/2004, Rodrigo Senra wrote (in part) > Well, for me ipython *is* more productive (http://ipython.scipy.org/) > If you haven't tried it yet, you ought to. J. Merrill / Analytical Software Corp From jvm_cop at spamcop.net Fri Oct 1 20:18:32 2004 From: jvm_cop at spamcop.net (J. Merrill) Date: Fri, 01 Oct 2004 14:18:32 -0400 Subject: [IronPython] Re: MSH vs IronPython In-Reply-To: <4.3.2.7.2.20041001111028.051e53b0@mail.comcast.net> References: <20041001093757.4eb22f6f@fenix.gpr.com.br> <4.3.2.7.2.20040930104423.05093130@mail.comcast.net> Message-ID: <4.3.2.7.2.20041001141721.05219dd0@mail.comcast.net> Never mind -- I hadn't figured out that this is a shell for non-.NET Python. It might be useful but isn't related to .NET at all. At 11:12 AM 10/1/2004, J. Merrill wrote >I had been ignorant of this. What's the relationship between this project and JimH's original IronPython project? If it started with the same code and is being more actively developed, I'm on board!! > >At 08:37 AM 10/1/2004, Rodrigo Senra wrote (in part) > >> Well, for me ipython *is* more productive (http://ipython.scipy.org/) >> If you haven't tried it yet, you ought to. J. Merrill / Analytical Software Corp From parault2 at wanadoo.fr Sat Oct 2 17:35:53 2004 From: parault2 at wanadoo.fr (Pat29) Date: Sat, 2 Oct 2004 17:35:53 +0200 Subject: [IronPython] Exceptions with double values Message-ID: <000601c4a895$857f1c30$3c6efea9@homecdz4laljze> After launched the IronPython interpreter, i tried these simple inputs: >>> 1.5 or >>> 1.5 + 2.5 Each time, an exception raised and i was disappointed. On my home computer, it's the same thing with this C# code snippet: string x = "1.5"; string y = 2.5"; Console.WriteLine("x + y = {0}", Convert.ToDouble(x) + Convert.ToDouble(y)); But the following code will work fine: string x = "1,5"; string y = 2,5"; Console.WriteLine("x + y = {0}", Convert.ToDouble(x) + Convert.ToDouble(y)); Like all .NET assemblies, the IronPython interpreter will use the current Culture informations. For some no English user like me, it's the reason that you get an exception with double values in the interpreter or in the b3/b5 modules when you try the parrotbench test. But i wanted to do this benchmark and the idea was to change the Culture informations. After to have modified the parrotrun.py file (renamed parrotrunUS.py) like this: ......... ......... """ This provides a more convenient harness for running this benchmark and collecting separate timings for each component. """ from time import clock import sys #Begin new code from System import Threading from System import Globalization Threading.Thread.CurrentThread.CurrentCulture = Globalization.CultureInfo.CreateSpecificCulture("en-US") #End new code t0 = clock() import b0 import b1 ......... ......... The test had worked. You can do the same thing with the interpreter >>>from System import Threading >>>from System import Globalization >>>Threading.Thread.CurrentThread.CurrentCulture = Globalization.CultureInfo.CreateSpecificCulture("en-US") >>> 1.54 + 2.28 >>>3.82 This modification is only usefull for some people. @+ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at sofsis.cl Sun Oct 3 23:52:19 2004 From: bob at sofsis.cl (Phillip Neumann) Date: Sun, 03 Oct 2004 21:52:19 +0000 Subject: [IronPython] TreeStore ... Message-ID: <1096840339.9188.6.camel@localhost> Im sorry if my messages are seen as spam or something... but im really interesting in using IronPYthon for my future projects.. is it possible to use Gtk.TreeStore from IronPython? how? thanks in advance! -- Phillip Neumann From johannes at eble-uebersetzungen.de Mon Oct 4 12:49:47 2004 From: johannes at eble-uebersetzungen.de (Johannes Eble) Date: Mon, 4 Oct 2004 12:49:47 +0200 Subject: [IronPython] Ironpython and vs.net? Message-ID: <000401c4a9ff$de691600$6402a8c0@hannes> Hello community, I wonder if there were any effords to integrate ironpython into the VS.NET IDE? It would be great if a plugin such as the Python.NET exists with Ironpython. Best regards Johannes From senthilkumar.chockalingam at kla-tencor.com Mon Oct 4 13:32:43 2004 From: senthilkumar.chockalingam at kla-tencor.com (senthilkumar) Date: Mon, 4 Oct 2004 17:02:43 +0530 Subject: [IronPython] raw_input Message-ID: a = raw_input("Enter the value to the variable") When executed the below error is thrown >>> a = raw_input("Enter the value to the variable") IronPython.Objects.PythonNameError: name 'raw_input' is not defined at IronPython.Objects.Frame.GetGlobal(String name) in F:\IronPython-0.6\IronP ython\Objects\Frame.cs:line 57 at input_0.Run(Frame frame) at IronPythonConsole.IronPython.DoInteractive() in f:\ironpython-0.6\ironpyth onconsole\ironpython.cs:line 189 >>> Any suggestion Thanks and regards Senthil Kumar From richard.torkar at htu.se Mon Oct 4 13:40:30 2004 From: richard.torkar at htu.se (Richard Torkar) Date: Mon, 04 Oct 2004 13:40:30 +0200 Subject: [IronPython] raw_input In-Reply-To: References: Message-ID: <1096890030.4043.16.camel@localhost.localdomain> On Mon, 2004-10-04 at 17:02 +0530, senthilkumar wrote: > a = raw_input("Enter the value to the variable") > > When executed the below error is thrown > > >>> a = raw_input("Enter the value to the variable") > IronPython.Objects.PythonNameError: name 'raw_input' is not defined > at IronPython.Objects.Frame.GetGlobal(String name) in > F:\IronPython-0.6\IronP > ython\Objects\Frame.cs:line 57 > at input_0.Run(Frame frame) > at IronPythonConsole.IronPython.DoInteractive() in > f:\ironpython-0.6\ironpyth > onconsole\ironpython.cs:line 189 > >>> I've noticed this too. I believe that this error is due to the fact that several pieces are not implemented yet. The raw_input method is one such thing! :) /Richard From pythonmailing at web.de Tue Oct 5 14:29:21 2004 From: pythonmailing at web.de (Marek Kubica) Date: Tue, 5 Oct 2004 14:29:21 +0200 Subject: [IronPython] TreeStore ... In-Reply-To: <1096840339.9188.6.camel@localhost> References: <1096840339.9188.6.camel@localhost> Message-ID: <20041005142921.00002063@galileo> On Sun, 03 Oct 2004 21:52:19 +0000 Phillip Neumann wrote: > Im sorry if my messages are seen as spam or something... > > but im really interesting in using IronPYthon for my future projects.. > > is it possible to use Gtk.TreeStore from IronPython? > how? Should be possible with Gtk#... greets, Marek From bob at sofsis.cl Tue Oct 5 23:57:04 2004 From: bob at sofsis.cl (Phillip Neumann) Date: Tue, 05 Oct 2004 21:57:04 +0000 Subject: [IronPython] TreeStore ... In-Reply-To: <1096840339.9188.6.camel@localhost> References: <1096840339.9188.6.camel@localhost> Message-ID: <1097013424.847.51.camel@localhost> Ok. Here is what im doing in C# that i wish to do with python: C# file: -------- using System; using Gtk; public class TreeViewSample { public static void Main (string [] args) { Application.Init (); Window win = new Window ("Demo"); win.SetDefaultSize (400,250); TreeStore store = new TreeStore (typeof (string), typeof (string)); TreeIter iter = store.AppendValues ("Hello","all"); TreeView tv = new TreeView (); tv.Model = store; tv.HeadersVisible = true; tv.AppendColumn ("Demo", new CellRendererText (), "text", 0); tv.AppendColumn ("Data", new CellRendererText (), "text", 1); win.Add (tv); win.ShowAll (); Application.Run (); } } -------> Works perfectly IronPython try: ------------------ import System from Gtk import * class TreeViewSample: def __init__(self): Application.Init (); win = Window("Demo"); win.SetDefaultSize (400,250) store = TreeStore ( str, str) store.AppendValues ("Hello","all") #Ones the Store works, i hope TreeView works too... #tv = TreeView () #tv.Model = store #tv.HeadersVisible = true #tv.AppendColumn ("Demo", CellRendererText (), "text", 0) #tv.AppendColumn ("Data", CellRendererText (), "text", 1) #win.Add (tv) win.ShowAll () Application.Run () TreeViewSample() killfill at book ~/MONO> ironpython pythontry.py Unhandled Exception: System.ArgumentException: parameters in <0x00085> System.Reflection.MonoCMethod:Invoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) in <0x0001d> System.Reflection.MonoCMethod:Invoke (System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) in <0x00044> System.Reflection.ConstructorInfo:Invoke (object[]) in <0x000f9> IronPython.Objects.ReflectedMethodBase:Call (object[]) in <0x00029> IronPython.Objects.ReflectedType:Call (object[]) in <0x00210> IronPython.Objects.Ops:Call (object,object,object) in <0x000f9> __main__:__init__$f0 (object) in <0x0006d> (wrapper delegate-invoke) System.MulticastDelegate:invoke_object_object (object) in <0x00026> IronPython.Objects.Function1:Call (object) in <0x00053> IronPython.Objects.Function1:Call (object[]) in <0x000b8> IronPython.Objects.Ops:Call (object,object[]) in <0x00021> IronPython.Objects.Method:Call (object[]) in <0x000b8> IronPython.Objects.Ops:Call (object,object[]) in <0x00046> IronPython.Objects.Ops:TryToInvoke (object,string,object&,object[]) in <0x0004c> IronPython.Objects.OldClass:Call (object[]) in <0x001b3> IronPython.Objects.Ops:Call (object) in <0x000c2> __main__:init () in <0x002a0> IronPythonConsole.IronPython:DoFile (string[]) in <0x0005d> IronPythonConsole.IronPython:Main (string[]) ive try to use instead of str System.String and GLib.Type.String but the result is the same. Anyone ever made use a TreeView in Ironpython?.... thank you very much -- Phillip Neumann From vargaz at gmail.com Wed Oct 6 13:50:55 2004 From: vargaz at gmail.com (Zoltan Varga) Date: Wed, 6 Oct 2004 13:50:55 +0200 Subject: [IronPython] TreeStore ... In-Reply-To: <1097013424.847.51.camel@localhost> References: <1096840339.9188.6.camel@localhost> <1097013424.847.51.camel@localhost> Message-ID: <295e750a0410060450712f9e67@mail.gmail.com> Hi, This doesn't work because the TreeStore ctor is defined as: public TreeStore (params GLib.GType[] types) while IronPython converts the arguments to an object[] array, not to the array type required by the method. The place where this needs to be fixed is ReflectedMethodBase.BindArgs (), specially this line: if (IsParamArray(pi)) { //!!! add error checking and non-object arrays so this is a bug/limitation in the current IronPython release. Zoltan On Tue, 05 Oct 2004 21:57:04 +0000, Phillip Neumann wrote: > Ok. > > Here is what im doing in C# that i wish to do with python: > > C# file: > -------- > > using System; > using Gtk; > > public class TreeViewSample { > > public static void Main (string [] args) > { > Application.Init (); > Window win = new Window ("Demo"); > win.SetDefaultSize (400,250); > > TreeStore store = new TreeStore (typeof (string), typeof > (string)); > TreeIter iter = store.AppendValues ("Hello","all"); > > TreeView tv = new TreeView (); > tv.Model = store; > tv.HeadersVisible = true; > tv.AppendColumn ("Demo", new CellRendererText (), "text", 0); > tv.AppendColumn ("Data", new CellRendererText (), "text", 1); > > win.Add (tv); > win.ShowAll (); > Application.Run (); > } > > } > > -------> Works perfectly > > IronPython try: > ------------------ > import System > from Gtk import * > > class TreeViewSample: > def __init__(self): > Application.Init (); > win = Window("Demo"); > win.SetDefaultSize (400,250) > > store = TreeStore ( str, str) > store.AppendValues ("Hello","all") > > #Ones the Store works, i hope TreeView works too... > #tv = TreeView () > #tv.Model = store > #tv.HeadersVisible = true > #tv.AppendColumn ("Demo", CellRendererText (), "text", 0) > #tv.AppendColumn ("Data", CellRendererText (), "text", 1) > > #win.Add (tv) > win.ShowAll () > Application.Run () > > TreeViewSample() > > killfill at book ~/MONO> ironpython pythontry.py > > Unhandled Exception: System.ArgumentException: parameters > in <0x00085> System.Reflection.MonoCMethod:Invoke > (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) > in <0x0001d> System.Reflection.MonoCMethod:Invoke > (System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) > in <0x00044> System.Reflection.ConstructorInfo:Invoke (object[]) > in <0x000f9> IronPython.Objects.ReflectedMethodBase:Call (object[]) > in <0x00029> IronPython.Objects.ReflectedType:Call (object[]) > in <0x00210> IronPython.Objects.Ops:Call (object,object,object) > in <0x000f9> __main__:__init__$f0 (object) > in <0x0006d> (wrapper delegate-invoke) > System.MulticastDelegate:invoke_object_object (object) > in <0x00026> IronPython.Objects.Function1:Call (object) > in <0x00053> IronPython.Objects.Function1:Call (object[]) > in <0x000b8> IronPython.Objects.Ops:Call (object,object[]) > in <0x00021> IronPython.Objects.Method:Call (object[]) > in <0x000b8> IronPython.Objects.Ops:Call (object,object[]) > in <0x00046> IronPython.Objects.Ops:TryToInvoke > (object,string,object&,object[]) > in <0x0004c> IronPython.Objects.OldClass:Call (object[]) > in <0x001b3> IronPython.Objects.Ops:Call (object) > in <0x000c2> __main__:init () > in <0x002a0> IronPythonConsole.IronPython:DoFile (string[]) > in <0x0005d> IronPythonConsole.IronPython:Main (string[]) > > ive try to use instead of str System.String and GLib.Type.String but the > result is the same. > > Anyone ever made use a TreeView in Ironpython?.... > > thank you very much > > > > -- > Phillip Neumann > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From jvm_cop at spamcop.net Thu Oct 7 03:36:26 2004 From: jvm_cop at spamcop.net (J. Merrill) Date: Wed, 06 Oct 2004 21:36:26 -0400 Subject: [IronPython] TreeStore ... In-Reply-To: <1097013424.847.51.camel@localhost> References: <1096840339.9188.6.camel@localhost> <1096840339.9188.6.camel@localhost> Message-ID: <4.3.2.7.2.20041006212536.0511af08@mail.comcast.net> At 05:57 PM 10/5/2004, Phillip Neumann wrote (in part) >C# file: >-------- > TreeStore store = new TreeStore (typeof (string), typeof >(string)); > >IronPython try: >------------------ >import System >from Gtk import * > > >class TreeViewSample: > def __init__(self): > Application.Init (); > win = Window("Demo"); > win.SetDefaultSize (400,250) > > store = TreeStore ( str, str) Try using Type.GetType('System.String') to get the equivalent of C# typeof(string) (I did not try myself.) J. Merrill / Analytical Software Corp From foxpdll at comch.ru Thu Oct 7 07:12:49 2004 From: foxpdll at comch.ru (=?windows-1251?B?z/Du9vv46O0gxOzo8vDo6Q==?=) Date: Thu, 7 Oct 2004 09:12:49 +0400 Subject: [IronPython] cvs or uptade? Message-ID: is there cvs or update for ipython? i had found only a link to IronPython-0.6.zip file how can i download latest fixed version or cvs for example? id like to use an ironpython at work but cant do that becouse some little bug founded but not fixed in thouse version which i use. From srikanth.remani at gmail.com Fri Oct 8 00:12:07 2004 From: srikanth.remani at gmail.com (Srikanth Remani) Date: Thu, 7 Oct 2004 17:12:07 -0500 Subject: [IronPython] how to import custom dlls Message-ID: Hi, I am trying to import a Custom library which is developed in C# to be included in .py script, eg. AB.MyNSpace and included the directory where AB.NSpace.dll is present. I am unable to import the namespace using from AB.MyNSpace import * where am i going wrong. thank you, S R I From jim at ironpython.com Fri Oct 8 01:34:22 2004 From: jim at ironpython.com (Jim Hugunin) Date: Thu, 7 Oct 2004 16:34:22 -0700 Subject: [IronPython] Dynamic Language Position on the CLR team at Microsoft Message-ID: <20041007233424.5E4C8149692@pillage.dreamhost.com> You may have noticed that I've been really bad about participating in this mailing list and making new releases of IronPython since I joined Microsoft two months ago. A big part of my problem has been that there are a TON of interesting things going on around this company that touch on the dynamic language space. All of these distractions have left me without the time to spend working directly with this important community. The good news is that I now get to hire another member to join the CLR team working full-time on dynamic languages. Having another person working on this project should give us enough time to really make an impact on this exciting space -- and not incidentally will give both of us the time to participate in the fun technical discussions that should be happening on this list. ------------------------------- Make the Common Language Runtime (CLR) an outstanding platform for dynamic languages and environments. You will be a key developer working on the CLR managed services team. Your first task will be to help finish the implementation of Python for the CLR (see http://ironpython.com/) so that we can show other developers how a high-performance production-quality dynamic language is implemented for this platform. Future work will likely involve addressing difficult implementation challenges for other dynamic languages and environments. A central part of this job will be working with the developer community. You will work both with developers who are trying to use dynamic languages on the CLR and those who are trying to develop dynamic languages for this platform. You will also work to identify and implement improvements to the CLR to enable us to provide the best possible experience for dynamic languages in the future. We're looking for a talented developer with exceptional programming ability and great communication skills. It's a plus if you have expertise in compiler implementation, reflection, VM implementation and/or dynamic languages. Applicants should have at least 4 years experience in software development and a BS/MS in computer science or related field. http://www.microsoft.com/careers/search/details.aspx?JobID=6391a54a-bfd7-438 4-b18f-cecb0acf86e0 --------------------------------------------- If you're interested in this position, I'd encourage you to both apply through the official channels and to send me your resume directly (jimhug at you know what company.com). Thanks - Jim From jim at ironpython.com Fri Oct 8 01:36:23 2004 From: jim at ironpython.com (Jim Hugunin) Date: Thu, 7 Oct 2004 16:36:23 -0700 Subject: [IronPython] how to import custom dlls In-Reply-To: Message-ID: <20041007233626.50BB814968D@pillage.dreamhost.com> Srikanth Remani wrote: > I am trying to import a Custom library which is developed in C# to be > included in .py script, > > eg. AB.MyNSpace and included the directory where AB.NSpace.dll is > present. I am unable to import the namespace using > > from AB.MyNSpace import * > > where am i going wrong. You need to tell IronPython about your custom dlls explicitly. Future versions might try to improve on the user experience here, but for now you can use one of the two special functions added to sys. See README.html in the distribution for pointers to these functions. -Jim From jim at ironpython.com Fri Oct 8 02:09:05 2004 From: jim at ironpython.com (Jim Hugunin) Date: Thu, 7 Oct 2004 17:09:05 -0700 Subject: [IronPython] Lightweight Code Generation? In-Reply-To: <4.3.2.7.2.20040917133941.04af0910@mail.comcast.net> Message-ID: <20041008000908.44CA4149690@pillage.dreamhost.com> The current use of the on disk snippets.dll is a total and absolute hack to make debugging easier during the development of IronPython. As things get closer to a 1.0 release of IronPython, this will need to be replaced with an in-memory only version, plus a debugging mode for developers who have problems. If you look at the code from IronPythonConsole, you'll notice that a try/finally is used to ensure that snippets.dll gets written even when an exception is going to be thrown. This should emphasize the debugging nature of the current design. This situation can be made a lot better without using any new 2.0 features. In particular, this particular dll can easily be kept just in memory with barely any change to the existing code. In fact, one of the advantages of continuing to use the 1.1 AssemblyBuilders is that they have this nice feature of either being just in-memory or being writable to disk. DynamicMethods, the new LCG mechanism in Whidbey/.NET 2.0, are a different story. The HUGE benefit of these methods are that they can be garbage collected. This would matter in a long running process that used eval occasionally, or possibly even in a short-running process that used eval a lot. With AssemblyBuilders any generated code uses memory that can never be reclaimed. With DynamicMethods you will get back the memory when there are no more references to the code as you'd hope. The downside to DynamicMethods is that they can't be written to disk, which means they can be a PITA to debug when something goes wrong. Most of the code for building DynamicMethods is identical to the code for the AssemblyBuilder approach currently used; however, there will be some significant differences. Perhaps the most obvious difference is that the current Python code generation uses CLR static fields for storing Python constants. DynamicMethods are just methods, so they don't let you create static field, so this code generation would have to be modified to get the constants from somewhere else. This is a big enough change to have some risk of inconsistent behavior and thus will need to be handled carefully. The huge benefit of being able to reclaim the memory from the code in a DynamicMethod is so important that I'm sure this feature will be enabled in some way in IronPython-1.0. The exact mechanisms used will take some careful engineering. -Jim > -----Original Message----- > From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users- > ironpython.com-bounces at lists.ironpython.com] On Behalf Of J. Merrill > Sent: Friday, September 17, 2004 10:50 AM > To: users-ironpython.com at lists.ironpython.com > Subject: Re: [IronPython] Lightweight Code Generation? > > It would certainly be easy enough to get rid of that "single instance per > directory" side effect. .NET supports in-memory-only assemblies, but > having the assembly on disk certainly must make it easier to do certain > kinds of debugging (e.g. you could run Reflector on it to see what's going > on, if it doesn't work the way you think it should). > > For at least that reason, I'd want to have the option to have any dynamic > assemblies be on-disk. If using the new functionality would mean that > there'd have to be two different implementations, one to satisfy the "on- > disk assembly" requirement and one that uses the new functionality, that > would leave open the possibility that things would work differently in > those two scenarios -- which I'd think could make people mistrust FePy > completely. > > But if the new mechanisms lets you save the resulting dynamic code as an > assembly (if needed), it might be worth the "no .NET 1.1 framework > support" problems to use those new features. > > At 08:56 PM 9/16/2004, Curt Hagenlocher wrote (in part) > > >Right now, FePy has to generate an assembly to contain all of > >its dynamic code. It generates this assembly to the file > >snippets.dll. I'm not sure if it has to generate the assembly > >to a file (versus in-memory), but one side effect of this is > >that you can only run a single instance of FePy from the same > >directory at the same time. > > > >Being able to generate dynamic code that lives in memory and > >doesn't have to be part of an on-disk assembly could be very > >useful. > > > >-- > >Curt Hagenlocher > >curt at hagenlocher.org > > > J. Merrill / Analytical Software Corp > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From ld at galador.net Fri Oct 8 02:40:48 2004 From: ld at galador.net (Lloyd Dupont) Date: Fri, 8 Oct 2004 10:40:48 +1000 Subject: [IronPython] Dynamic Language Position on the CLR team at Microsoft References: <20041007233424.5E4C8149692@pillage.dreamhost.com> Message-ID: <002501c4accf$876816d0$730010ac@5dservices.com.au> great news :D !! ----- Original Message ----- From: "Jim Hugunin" To: Sent: Friday, October 08, 2004 9:34 AM Subject: [IronPython] Dynamic Language Position on the CLR team at Microsoft > You may have noticed that I've been really bad about participating in this > mailing list and making new releases of IronPython since I joined > Microsoft > two months ago. A big part of my problem has been that there are a TON of > interesting things going on around this company that touch on the dynamic > language space. All of these distractions have left me without the time > to > spend working directly with this important community. > > The good news is that I now get to hire another member to join the CLR > team > working full-time on dynamic languages. Having another person working on > this project should give us enough time to really make an impact on this > exciting space -- and not incidentally will give both of us the time to > participate in the fun technical discussions that should be happening on > this list. > > ------------------------------- > Make the Common Language Runtime (CLR) an outstanding platform for dynamic > languages and environments. You will be a key developer working on the CLR > managed services team. Your first task will be to help finish the > implementation of Python for the CLR (see http://ironpython.com/) so that > we > can show other developers how a high-performance production-quality > dynamic > language is implemented for this platform. Future work will likely involve > addressing difficult implementation challenges for other dynamic languages > and environments. A central part of this job will be working with the > developer community. You will work both with developers who are trying to > use dynamic languages on the CLR and those who are trying to develop > dynamic > languages for this platform. You will also work to identify and implement > improvements to the CLR to enable us to provide the best possible > experience > for dynamic languages in the future. > > We're looking for a talented developer with exceptional programming > ability > and great communication skills. It's a plus if you have expertise in > compiler implementation, reflection, VM implementation and/or dynamic > languages. Applicants should have at least 4 years experience in software > development and a BS/MS in computer science or related field. > > http://www.microsoft.com/careers/search/details.aspx?JobID=6391a54a-bfd7-438 > 4-b18f-cecb0acf86e0 > > --------------------------------------------- > > If you're interested in this position, I'd encourage you to both apply > through the official channels and to send me your resume directly (jimhug > at > you know what company.com). > > Thanks - Jim > > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From ironpython at alexh.sent.com Fri Oct 8 09:19:09 2004 From: ironpython at alexh.sent.com (Alex Hoffman) Date: Fri, 08 Oct 2004 17:19:09 +1000 Subject: [IronPython] Lightweight Code Generation? In-Reply-To: <20041008000908.44CA4149690@pillage.dreamhost.com> References: <20041008000908.44CA4149690@pillage.dreamhost.com> Message-ID: <41663F6D.1030005@alexh.sent.com> I'd be really interested in hearing more about your intended use of the LCG mechanism in 2.0. In the past, I had intended introducing a shell or "interactive" mode to a "scripting" type product I had written (http://alintex.com/products.aspx). The intention was to build on the current CodeDom functionality and use Reflection.Emit to generate opcodes based on parsed code at the "command line" in a similar way to what IronPython does now. For example one could type in vb.net (following the example in your blog entry) ... >>> imports Systems.Windows.Forms >>> print 2+2 4 >>> w = new Form >>> b = new Button >>> b.Text = "push me" >>> w.Controls.Add(b) >>> w.ShowDialog() dialog pops up here But I effectively abandoned that because of the imprecise syntax and vocab of say VB.NET (I left out how to handle the click event on button b above for a reason), but also because I thought that constantly consuming (unrecoverable) memory each time someone hit the enter key was unacceptable. I guess it could be revisited in light of dynamic methods. Alex Hoffman Jim Hugunin wrote: >The current use of the on disk snippets.dll is a total and absolute hack to >make debugging easier during the development of IronPython. As things get >closer to a 1.0 release of IronPython, this will need to be replaced with an >in-memory only version, plus a debugging mode for developers who have >problems. If you look at the code from IronPythonConsole, you'll notice >that a try/finally is used to ensure that snippets.dll gets written even >when an exception is going to be thrown. This should emphasize the >debugging nature of the current design. > >This situation can be made a lot better without using any new 2.0 features. >In particular, this particular dll can easily be kept just in memory with >barely any change to the existing code. In fact, one of the advantages of >continuing to use the 1.1 AssemblyBuilders is that they have this nice >feature of either being just in-memory or being writable to disk. > >DynamicMethods, the new LCG mechanism in Whidbey/.NET 2.0, are a different >story. The HUGE benefit of these methods are that they can be garbage >collected. This would matter in a long running process that used eval >occasionally, or possibly even in a short-running process that used eval a >lot. With AssemblyBuilders any generated code uses memory that can never be >reclaimed. With DynamicMethods you will get back the memory when there are >no more references to the code as you'd hope. The downside to >DynamicMethods is that they can't be written to disk, which means they can >be a PITA to debug when something goes wrong. > >Most of the code for building DynamicMethods is identical to the code for >the AssemblyBuilder approach currently used; however, there will be some >significant differences. Perhaps the most obvious difference is that the >current Python code generation uses CLR static fields for storing Python >constants. DynamicMethods are just methods, so they don't let you create >static field, so this code generation would have to be modified to get the >constants from somewhere else. This is a big enough change to have some >risk of inconsistent behavior and thus will need to be handled carefully. > >The huge benefit of being able to reclaim the memory from the code in a >DynamicMethod is so important that I'm sure this feature will be enabled in >some way in IronPython-1.0. The exact mechanisms used will take some >careful engineering. > >-Jim > > > > >>-----Original Message----- >>From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users- >>ironpython.com-bounces at lists.ironpython.com] On Behalf Of J. Merrill >>Sent: Friday, September 17, 2004 10:50 AM >>To: users-ironpython.com at lists.ironpython.com >>Subject: Re: [IronPython] Lightweight Code Generation? >> >>It would certainly be easy enough to get rid of that "single instance per >>directory" side effect. .NET supports in-memory-only assemblies, but >>having the assembly on disk certainly must make it easier to do certain >>kinds of debugging (e.g. you could run Reflector on it to see what's going >>on, if it doesn't work the way you think it should). >> >>For at least that reason, I'd want to have the option to have any dynamic >>assemblies be on-disk. If using the new functionality would mean that >>there'd have to be two different implementations, one to satisfy the "on- >>disk assembly" requirement and one that uses the new functionality, that >>would leave open the possibility that things would work differently in >>those two scenarios -- which I'd think could make people mistrust FePy >>completely. >> >>But if the new mechanisms lets you save the resulting dynamic code as an >>assembly (if needed), it might be worth the "no .NET 1.1 framework >>support" problems to use those new features. >> >>At 08:56 PM 9/16/2004, Curt Hagenlocher wrote (in part) >> >> >> >>>Right now, FePy has to generate an assembly to contain all of >>>its dynamic code. It generates this assembly to the file >>>snippets.dll. I'm not sure if it has to generate the assembly >>>to a file (versus in-memory), but one side effect of this is >>>that you can only run a single instance of FePy from the same >>>directory at the same time. >>> >>>Being able to generate dynamic code that lives in memory and >>>doesn't have to be part of an on-disk assembly could be very >>>useful. >>> >>>-- >>>Curt Hagenlocher >>>curt at hagenlocher.org >>> >>> >>J. Merrill / Analytical Software Corp >> >>_______________________________________________ >>users-ironpython.com mailing list >>users-ironpython.com at lists.ironpython.com >>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > >_______________________________________________ >users-ironpython.com mailing list >users-ironpython.com at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From jvm_cop at spamcop.net Sat Oct 9 05:03:10 2004 From: jvm_cop at spamcop.net (J. Merrill) Date: Fri, 08 Oct 2004 23:03:10 -0400 Subject: [IronPython] Lightweight Code Generation? In-Reply-To: <41663F6D.1030005@alexh.sent.com> References: <20041008000908.44CA4149690@pillage.dreamhost.com> <20041008000908.44CA4149690@pillage.dreamhost.com> Message-ID: <4.3.2.7.2.20041008224656.03d8dee8@mail.comcast.net> I agree that it's unfortunate to lose memory at each press of the Enter key, but we are not talking about gobs and gobs of memory, are we? The usefulness of the interactive mode is so much greater than the few MB of unrecoverable memory that would accumulate during a very long session. (Even if we can't recover the memory, if it gets paged out and never comes back it should not have a great impact.) I for one would trade "you need to exit and start again every 3 hours" for the ability to work in the dynamic, interactive, "hold the data in your hands" mode that (Iron)Python provides. The fact that we can use a great deal of what .NET has to offer (and eventually will be able to use it all) while writing in Python is great. The fact the MS seems to have made a poor implementation decision in the 1.x framework -- one that decrees that no code that's been loaded into an AppDomain can be unloaded without destroying the entire AppDomain -- should not prevent us from having a productive environment. Taking advantage of -- and perhaps enhancing prior to release -- the new functionality would be great. However, there are other things that I think are more important to be ready for an eventual 1.0 release of FePy. Jim is perhaps uniquely positioned to have an impact on the future course of the new capabilities. Hopefully the issues he mentioned in his other post can be resolved by changes to the CLR -- now that he's on the team. At 03:19 AM 10/8/2004, Alex Hoffman wrote (in part) >But I effectively abandoned that ... because I thought that constantly consuming (unrecoverable) memory each time someone hit the enter key was unacceptable. J. Merrill / Analytical Software Corp From ld at galador.net Sat Oct 9 06:26:11 2004 From: ld at galador.net (Lloyd Dupont) Date: Sat, 9 Oct 2004 14:26:11 +1000 Subject: [IronPython] one nide idea References: <20041008000908.44CA4149690@pillage.dreamhost.com><20041008000908.44CA4149690@pillage.dreamhost.com> <4.3.2.7.2.20041008224656.03d8dee8@mail.comcast.net> Message-ID: <002e01c4adb8$2b1ee810$0100a8c0@vulcain> would be to have the GUI designer to generate Python code. so as to have all the business logic in precompiled and some user updatable GUI in python scripts... From ironpython at alexh.sent.com Sat Oct 9 10:48:22 2004 From: ironpython at alexh.sent.com (Alex Hoffman) Date: Sat, 09 Oct 2004 18:48:22 +1000 Subject: [IronPython] Lightweight Code Generation? In-Reply-To: <4.3.2.7.2.20041008224656.03d8dee8@mail.comcast.net> References: <20041008000908.44CA4149690@pillage.dreamhost.com> <20041008000908.44CA4149690@pillage.dreamhost.com> <4.3.2.7.2.20041008224656.03d8dee8@mail.comcast.net> Message-ID: <4167A5D6.7060600@alexh.sent.com> Have a long session - you'll see that "gobs" of memory can be consumed. However, it's true that increasing memory usage in an interactive session might be acceptable in some scenarios. But in others it might not. That's especially the case if the product doesn't come from Microsoft ;) My concern was not really the short interactive session, but related to providing a solution for integrated scripting (called embedded scripting in Python?). Where one can add functionality to an application through scripting at runtime. If one provided a .NET language (including Python) "script control", one would have to supply it with a warning not to modify the script too much! Either that or implement a second AppDomain recycling scheme that meant that the script was effectively operating in a sandbox. Unfortunately unloading an assembly from the primary AppDomain surely goes beyond any member of the CLR team's influence. It is core to the architecture of the CLR - not a feature that can just be bolted on or included in the "next release". To give you some idea, the whole VSA (Visual Tools for Applications) product effectively died at the hands of this issue (and a changing ASP market). It meant that Microsoft had to forget a run time scripting environment and instead release a design time scripting solution - Visual Studio Tools For Office. It's such a big issue that VBA is still their strategic integrated scripting solution years after .NET's release. As mentioned it's maybe worth a revisit given LCG and dynamic properties. Alex Hoffman J. Merrill wrote: >I agree that it's unfortunate to lose memory at each press of the Enter key, but we are not talking about gobs and gobs of memory, are we? The usefulness of the interactive mode is so much greater than the few MB of unrecoverable memory that would accumulate during a very long session. (Even if we can't recover the memory, if it gets paged out and never comes back it should not have a great impact.) > >I for one would trade "you need to exit and start again every 3 hours" for the ability to work in the dynamic, interactive, "hold the data in your hands" mode that (Iron)Python provides. The fact that we can use a great deal of what .NET has to offer (and eventually will be able to use it all) while writing in Python is great. > >The fact the MS seems to have made a poor implementation decision in the 1.x framework -- one that decrees that no code that's been loaded into an AppDomain can be unloaded without destroying the entire AppDomain -- should not prevent us from having a productive environment. > >Taking advantage of -- and perhaps enhancing prior to release -- the new functionality would be great. However, there are other things that I think are more important to be ready for an eventual 1.0 release of FePy. > >Jim is perhaps uniquely positioned to have an impact on the future course of the new capabilities. Hopefully the issues he mentioned in his other post can be resolved by changes to the CLR -- now that he's on the team. > >At 03:19 AM 10/8/2004, Alex Hoffman wrote (in part) > > >>But I effectively abandoned that ... because I thought that constantly consuming (unrecoverable) memory each time someone hit the enter key was unacceptable. >> >> > > >J. Merrill / Analytical Software Corp > >_______________________________________________ >users-ironpython.com mailing list >users-ironpython.com at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From jim at ironpython.com Sat Oct 9 19:08:29 2004 From: jim at ironpython.com (Jim Hugunin) Date: Sat, 9 Oct 2004 10:08:29 -0700 Subject: [IronPython] Lightweight Code Generation? In-Reply-To: <4167A5D6.7060600@alexh.sent.com> Message-ID: <20041009170832.517081496A6@pillage.dreamhost.com> Alex Hoffman write: > Unfortunately unloading an assembly from the primary AppDomain surely > goes beyond any member of the CLR team's influence. It is core to the > architecture of the CLR - not a feature that can just be bolted on or > included in the "next release". Unloading assemblies is a big issue and one that I'm unlikely to change in the very near future. Here's a link to my boss's blog where he talks about this issue: http://blogs.msdn.com/jasonz/archive/2004/05/31/145105.aspx I agree that there is potentially value in hosting embedded scripts in a separate AppDomain with restricted permissions in order to increase reliability. I really like to ability to monitor scripts and kill them if they use too much memory or time. One of the many tasks on my giant todo list is to write a hosting example that shows how separate AppDomains can be used effectively to host a scripting solution. Until I do that, I can't really comment on how much of a problem this is in practice. > As mentioned it's maybe worth a revisit given LCG and dynamic properties. LCG is the right way to fix this problem in the near term. Once again, I'll send you off to one of my co-worker's blogs for a concrete example: http://blogs.msdn.com/joelpob/archive/2004/03/31/105282.aspx It should be a trivial matter to support this form of generation as an option in IronPython that is used only on systems that support DynamicMethod. This would mean that 1.1 systems would have an interactive interpreter with a memory leak, but that on 2.0 that same interactive interpreter would stop leaking making it viable in a greater range of circumstances. -Jim From ld at galador.net Sat Oct 9 22:53:56 2004 From: ld at galador.net (Lloyd Dupont) Date: Sun, 10 Oct 2004 06:53:56 +1000 Subject: [IronPython] Lightweight Code Generation? References: <20041009170832.517081496A6@pillage.dreamhost.com> Message-ID: <000a01c4ae42$27ca7230$0100a8c0@vulcain> what about [2.0] DynamicMethod? I heard they could be garbage collected... I mean each line of python code could be staright executed in the current context (without creating new assemblies and stuff), but function could generated as DynamicMethod this way you don't have any kind of 'memory leak', do you? ----- Original Message ----- From: "Jim Hugunin" To: "'Alex Hoffman'" ; Sent: Sunday, October 10, 2004 3:08 AM Subject: RE: [IronPython] Lightweight Code Generation? > Alex Hoffman write: >> Unfortunately unloading an assembly from the primary AppDomain surely >> goes beyond any member of the CLR team's influence. It is core to the >> architecture of the CLR - not a feature that can just be bolted on or >> included in the "next release". > > Unloading assemblies is a big issue and one that I'm unlikely to change in > the very near future. Here's a link to my boss's blog where he talks > about > this issue: > http://blogs.msdn.com/jasonz/archive/2004/05/31/145105.aspx > > I agree that there is potentially value in hosting embedded scripts in a > separate AppDomain with restricted permissions in order to increase > reliability. I really like to ability to monitor scripts and kill them if > they use too much memory or time. One of the many tasks on my giant todo > list is to write a hosting example that shows how separate AppDomains can > be > used effectively to host a scripting solution. Until I do that, I can't > really comment on how much of a problem this is in practice. > >> As mentioned it's maybe worth a revisit given LCG and dynamic properties. > > LCG is the right way to fix this problem in the near term. Once again, > I'll > send you off to one of my co-worker's blogs for a concrete example: > http://blogs.msdn.com/joelpob/archive/2004/03/31/105282.aspx > > It should be a trivial matter to support this form of generation as an > option in IronPython that is used only on systems that support > DynamicMethod. This would mean that 1.1 systems would have an interactive > interpreter with a memory leak, but that on 2.0 that same interactive > interpreter would stop leaking making it viable in a greater range of > circumstances. > > -Jim > > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From brian at sweetapp.com Sun Oct 10 13:52:08 2004 From: brian at sweetapp.com (Brian Quinlan) Date: Sun, 10 Oct 2004 13:52:08 +0200 Subject: [IronPython] In fix for strings Message-ID: <41692268.1010105@sweetapp.com> IronPython 0.6.0 doesn't support the "in" operator correctly for string types. To demonstrate: >>> 'abc' in 'abcd' False Here is my fix (sorry for the lack of a diff - I don't have access to the original source right now). Add to StringOps class: public static bool Contains(string s, object o) { if (o is string) return s.IndexOf((string) o) != -1; else throw Ops.TypeError("requires string as left operand"); } Add to Ops.In: public static object In(object x, object y) { if (y is string) { return bool2object(StringOps.Contains((string) y, x)); } else if (y is IDictionary) { ... Cheers, Brian From andrew at adersoftware.com Mon Oct 11 02:26:41 2004 From: andrew at adersoftware.com (Andrew Deren) Date: Sun, 10 Oct 2004 19:26:41 -0500 Subject: [IronPython] Lightweight Code Generation? In-Reply-To: <20041009170832.517081496A6@pillage.dreamhost.com> Message-ID: <200410101824568.SM00276@ANDREW> I meant to send the below to the list, but somehow it got sent only to Jim, so maybe someone else could answer that too. Would you know where I can find more info on dynamic methods? One thing I'm especially looking for is a way to call other dynamically created methods from one. Is it even possible? If I have a script that defines custom functions, I would need to emit those too. Would I create separate DynamicMethod for each one of them? Thanks. -----Original Message----- From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Jim Hugunin Sent: Saturday, October 09, 2004 12:08 PM To: 'Alex Hoffman'; users-ironpython.com at lists.ironpython.com Subject: RE: [IronPython] Lightweight Code Generation? Alex Hoffman write: > Unfortunately unloading an assembly from the primary AppDomain surely > goes beyond any member of the CLR team's influence. It is core to the > architecture of the CLR - not a feature that can just be bolted on or > included in the "next release". Unloading assemblies is a big issue and one that I'm unlikely to change in the very near future. Here's a link to my boss's blog where he talks about this issue: http://blogs.msdn.com/jasonz/archive/2004/05/31/145105.aspx I agree that there is potentially value in hosting embedded scripts in a separate AppDomain with restricted permissions in order to increase reliability. I really like to ability to monitor scripts and kill them if they use too much memory or time. One of the many tasks on my giant todo list is to write a hosting example that shows how separate AppDomains can be used effectively to host a scripting solution. Until I do that, I can't really comment on how much of a problem this is in practice. > As mentioned it's maybe worth a revisit given LCG and dynamic properties. LCG is the right way to fix this problem in the near term. Once again, I'll send you off to one of my co-worker's blogs for a concrete example: http://blogs.msdn.com/joelpob/archive/2004/03/31/105282.aspx It should be a trivial matter to support this form of generation as an option in IronPython that is used only on systems that support DynamicMethod. This would mean that 1.1 systems would have an interactive interpreter with a memory leak, but that on 2.0 that same interactive interpreter would stop leaking making it viable in a greater range of circumstances. -Jim _______________________________________________ users-ironpython.com mailing list users-ironpython.com at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jim at ironpython.com Mon Oct 11 05:46:41 2004 From: jim at ironpython.com (Jim Hugunin) Date: Sun, 10 Oct 2004 20:46:41 -0700 Subject: [IronPython] Lightweight Code Generation? In-Reply-To: <200410101824568.SM00276@ANDREW> Message-ID: <20041011034644.8BEA41496AB@pillage.dreamhost.com> Andrew Deren wrote: > Would you know where I can find more info on dynamic methods? One thing > I'm > especially looking for is a way to call other dynamically created methods > from one. Is it even possible? > If I have a script that defines custom functions, I would need to emit > those > too. Would I create separate DynamicMethod for each one of them? The best pointers I know are Joel's hello world from my last message and the docs that ship with the various Whidbey betas. You can get the betas and the docs from msdn. Here's a link to the docs online: http://msdn2.microsoft.com/library/System.Reflection.Emit.DynamicMethod Every function that you want to create should go in its own DynamicMethod. I assume that you can call a DynamicMethod in generated bytecode by just using ILGenerator.Emit(OpCodes.Call, myDynamicMethod) as you would for emitting a call to any MethodInfo. I have to admit that I've never tried this so I'm assuming there's no issue using this with DynamicMethods. Have you tried this? The reason that I've never tried this is that the IronPython implementation never has a reason to call DynamicMethods directly. DynamicMethods are used to build Function objects that are called using standard method calls. This is needed because functions in Python are first-class entities. Thank - Jim From jim at ironpython.com Mon Oct 11 05:46:41 2004 From: jim at ironpython.com (Jim Hugunin) Date: Sun, 10 Oct 2004 20:46:41 -0700 Subject: [IronPython] Lightweight Code Generation? In-Reply-To: <000a01c4ae42$27ca7230$0100a8c0@vulcain> Message-ID: <20041011034645.04775149690@pillage.dreamhost.com> Lloyd Dupont wrote: > what about [2.0] DynamicMethod? > I heard they could be garbage collected... > > I mean each line of python code could be staright executed in the current > context (without creating new assemblies and stuff), but function could > generated as DynamicMethod > > this way you don't have any kind of 'memory leak', do you? Absolutely. DynamicMethods are the new class in 2.0 that people call Lightweight Code Generation (LCG). These are the near-term solution to the need to reclaim memory from generated code. Here's my quote from your own message Jim H. wrote previously: > > It should be a trivial matter to support this form of generation as an > > option in IronPython that is used only on systems that support > > DynamicMethod. This would mean that 1.1 systems would have an > interactive > > interpreter with a memory leak, but that on 2.0 that same interactive > > interpreter would stop leaking making it viable in a greater range of > > circumstances. The leak on 1.1-based systems is there because they don't support DynamicMethod so all code generation will have to be through AssemblyBuilders which will leak over time. -Jim From curt at hagenlocher.org Mon Oct 11 16:13:02 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 11 Oct 2004 07:13:02 -0700 Subject: [IronPython] Lightweight Code Generation? Message-ID: <200410111413.HAA08312@dopey.hagenlocher.org> "Jim Hugunin" writes: > The leak on 1.1-based systems is there because they don't support > DynamicMethod so all code generation will have to be through > AssemblyBuilders which will leak over time. For newcomers to the discussion, it should be pointed out that IronPython would only leak over time in a 1.1 CLR when a) used interactively b) used in a program that performs exec / eval Long-running programs that don't exec/eval would not be building new code, and therefore wouldn't leak memory. -- Curt Hagenlocher curt at hagenlocher.org From jlam at iunknown.com Tue Oct 12 04:13:22 2004 From: jlam at iunknown.com (John Lam) Date: Mon, 11 Oct 2004 22:13:22 -0400 Subject: [IronPython] Lightweight Code Generation? Message-ID: <60069A30D8D33343A5C1BD01920B271F3B4A@thefirm.webappdesign.com> >> b) used in a program that performs exec / eval But those are all the fun programs :) -John http://www.iunknown.com From alleykat at gmail.com Tue Oct 12 04:56:57 2004 From: alleykat at gmail.com (Travis Watkins) Date: Mon, 11 Oct 2004 21:56:57 -0500 Subject: [IronPython] SharpZipLib Message-ID: Hello, I just found IronPython a couple days ago and thought I would try it out. I'm trying to use SharpZipLib [1] so I added it to the GAC with "gacutil /i ICSharpCode.SharpZipLib.dll". However, when I try to do "from ICSharpCode.SharpZipLib.GZip import *" I get the following: Unhandled Exception: IronPython.Objects.PythonImportError: can't load ICSharpCode.SharpZipLib.GZip Do I have to do something special to load this? Thanks for your help. [1] http://www.icsharpcode.net/OpenSource/SharpZipLib/ From progoth at gmail.com Tue Oct 12 05:19:21 2004 From: progoth at gmail.com (Steven Scott) Date: Mon, 11 Oct 2004 23:19:21 -0400 Subject: [IronPython] SharpZipLib In-Reply-To: References: Message-ID: this has been answered many times, I believe import sys sys.LoadAssemblyByName( 'ICSharpCode.SharpZipLib' ) from ICSharpCode.SharpZipLib import * On Mon, 11 Oct 2004 21:56:57 -0500, Travis Watkins wrote: > Hello, I just found IronPython a couple days ago and thought I would > try it out. I'm trying to use SharpZipLib [1] so I added it to the GAC > with "gacutil /i ICSharpCode.SharpZipLib.dll". However, when I try to > do "from ICSharpCode.SharpZipLib.GZip import *" I get the following: > Unhandled Exception: IronPython.Objects.PythonImportError: can't load > ICSharpCode.SharpZipLib.GZip > > Do I have to do something special to load this? Thanks for your help. > > [1] http://www.icsharpcode.net/OpenSource/SharpZipLib/ > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Steven Scott From alleykat at gmail.com Tue Oct 12 08:51:05 2004 From: alleykat at gmail.com (Travis Watkins) Date: Tue, 12 Oct 2004 01:51:05 -0500 Subject: [IronPython] SharpZipLib In-Reply-To: References: Message-ID: Whoops, sorry, I couldn't seem to find anything about it. Anyway, that code works. Thanks for your help. From nicolas at lehuen.com Tue Oct 12 10:44:54 2004 From: nicolas at lehuen.com (Nicolas Lehuen) Date: Tue, 12 Oct 2004 10:44:54 +0200 Subject: [IronPython] IronPython cs Cpython wrt GIL In-Reply-To: Message-ID: <20041012084821.21DA9985A6@che.dreamhost.com> Hi, There has been yet another thread on the Global Interpreter Lock found in Cpython on comp.lang.python. Is there any such "annoyance" in IronPython (and, come to think of it, Jython) ? If not, I guess it would be a big advantage of IronPython (or Jython) vs CPython on multi-CPU or hyperthreading CPUs ? Regards, Nicolas Lehuen From firemoth at gmail.com Tue Oct 12 16:12:12 2004 From: firemoth at gmail.com (Timothy Fitz) Date: Tue, 12 Oct 2004 10:12:12 -0400 Subject: [IronPython] SharpZipLib In-Reply-To: References: Message-ID: <972ec5bd04101207123a557c02@mail.gmail.com> He makes a good point, we need an FAQ of some sort, or more preferably a WIKI (Seeing as how busy Mr. Hugunin is, until he hires someone) On Tue, 12 Oct 2004 01:51:05 -0500, Travis Watkins wrote: > Whoops, sorry, I couldn't seem to find anything about it. Anyway, that > code works. Thanks for your help. > > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From progoth at gmail.com Tue Oct 12 16:23:44 2004 From: progoth at gmail.com (Steven Scott) Date: Tue, 12 Oct 2004 10:23:44 -0400 Subject: [IronPython] SharpZipLib In-Reply-To: <972ec5bd04101207123a557c02@mail.gmail.com> References: <972ec5bd04101207123a557c02@mail.gmail.com> Message-ID: That's a good point...and a good idea... If nobody else steps up I could easily host a Wiki. On Tue, 12 Oct 2004 10:12:12 -0400, Timothy Fitz wrote: > He makes a good point, we need an FAQ of some sort, or more preferably > a WIKI (Seeing as how busy Mr. Hugunin is, until he hires someone) > > > > > On Tue, 12 Oct 2004 01:51:05 -0500, Travis Watkins wrote: > > Whoops, sorry, I couldn't seem to find anything about it. Anyway, that > > code works. Thanks for your help. > > > > > > _______________________________________________ > > users-ironpython.com mailing list > > users-ironpython.com at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Steven Scott From jvm_cop at spamcop.net Tue Oct 12 17:40:06 2004 From: jvm_cop at spamcop.net (J. Merrill) Date: Tue, 12 Oct 2004 11:40:06 -0400 Subject: [IronPython] SharpZipLib Message-ID: <4.3.2.7.2.20041012113957.0476d008@mail.comcast.net> A Wiki would indeed be a very good contribution (that MS could presumably host without any pain) to this effort. At 10:12 AM 10/12/2004, Timothy Fitz wrote >He makes a good point, we need an FAQ of some sort, or more preferably >a WIKI (Seeing as how busy Mr. Hugunin is, until he hires someone) > >On Tue, 12 Oct 2004 01:51:05 -0500, Travis Watkins wrote: >> Whoops, sorry, I couldn't seem to find anything about it. Anyway, that >> code works. Thanks for your help. J. Merrill / Analytical Software Corp From kfarmer at thuban.org Tue Oct 12 19:16:02 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 12 Oct 2004 10:16:02 -0700 Subject: [IronPython] SharpZipLib Message-ID: I've seen a lot of wiki (the vast bulk) turn into an unnavigable mess. Would there be enough volunteers to direct the information and keep things useful? There are other collaboration options out there as well -- SharePoint, various other community sites, etc. ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of J. Merrill Sent: Tue 10/12/2004 8:40 AM To: users-ironpython.com at lists.ironpython.com Subject: Re: [IronPython] SharpZipLib A Wiki would indeed be a very good contribution (that MS could presumably host without any pain) to this effort. At 10:12 AM 10/12/2004, Timothy Fitz wrote >He makes a good point, we need an FAQ of some sort, or more preferably >a WIKI (Seeing as how busy Mr. Hugunin is, until he hires someone) From firemoth at gmail.com Tue Oct 12 21:30:54 2004 From: firemoth at gmail.com (Timothy Fitz) Date: Tue, 12 Oct 2004 15:30:54 -0400 Subject: [IronPython] SharpZipLib In-Reply-To: References: Message-ID: <972ec5bd04101212306556216@mail.gmail.com> I could easily administrate / moderate. (Hey, college has advantages) If someone wants to set one up interim before we get an official one, contact me. (I can't host one, sadly) On Tue, 12 Oct 2004 10:16:02 -0700, Keith J. Farmer wrote: > I've seen a lot of wiki (the vast bulk) turn into an unnavigable mess. Would there be enough volunteers to direct the information and keep things useful? > > There are other collaboration options out there as well -- SharePoint, various other community sites, etc. > > ________________________________ > > From: users-ironpython.com-bounces at lists.ironpython.com on behalf of J. Merrill > Sent: Tue 10/12/2004 8:40 AM > To: users-ironpython.com at lists.ironpython.com > Subject: Re: [IronPython] SharpZipLib > > > A Wiki would indeed be a very good contribution (that MS could presumably host without any pain) to this effort. > > At 10:12 AM 10/12/2004, Timothy Fitz wrote > >He makes a good point, we need an FAQ of some sort, or more preferably > >a WIKI (Seeing as how busy Mr. Hugunin is, until he hires someone) > > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From lobrien at knowing.net Tue Oct 12 21:33:56 2004 From: lobrien at knowing.net (Larry O'Brien) Date: Tue, 12 Oct 2004 09:33:56 -1000 Subject: [IronPython] SharpZipLib In-Reply-To: <972ec5bd04101212306556216@mail.gmail.com> Message-ID: If no one else objects, I'll put up a place-holder in the next couple hours and give Timothy admin rights... -----Original Message----- From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Timothy Fitz Sent: Tuesday, October 12, 2004 9:31 AM To: Keith J. Farmer; J. Merrill; IronPython Subject: Re: [IronPython] SharpZipLib I could easily administrate / moderate. (Hey, college has advantages) If someone wants to set one up interim before we get an official one, contact me. (I can't host one, sadly) On Tue, 12 Oct 2004 10:16:02 -0700, Keith J. Farmer wrote: > I've seen a lot of wiki (the vast bulk) turn into an unnavigable mess. Would there be enough volunteers to direct the information and keep things useful? > > There are other collaboration options out there as well -- SharePoint, various other community sites, etc. > > ________________________________ > > From: users-ironpython.com-bounces at lists.ironpython.com on behalf of J. Merrill > Sent: Tue 10/12/2004 8:40 AM > To: users-ironpython.com at lists.ironpython.com > Subject: Re: [IronPython] SharpZipLib > > > A Wiki would indeed be a very good contribution (that MS could presumably host without any pain) to this effort. > > At 10:12 AM 10/12/2004, Timothy Fitz wrote > >He makes a good point, we need an FAQ of some sort, or more preferably > >a WIKI (Seeing as how busy Mr. Hugunin is, until he hires someone) > > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ users-ironpython.com mailing list users-ironpython.com at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jim at ironpython.com Wed Oct 13 05:36:40 2004 From: jim at ironpython.com (Jim Hugunin) Date: Tue, 12 Oct 2004 20:36:40 -0700 Subject: [IronPython] IronPython cs Cpython wrt GIL In-Reply-To: <20041012084821.21DA9985A6@che.dreamhost.com> Message-ID: <20041013033642.A809A1496A1@pillage.dreamhost.com> Nicolas Lehuen wrote: > There has been yet another thread on the Global Interpreter Lock found in > Cpython on comp.lang.python. Is there any such "annoyance" in IronPython > (and, come to think of it, Jython) ? If not, I guess it would be a big > advantage of IronPython (or Jython) vs CPython on multi-CPU or > hyperthreading CPUs ? IronPython has no GIL today and it's unlikely that it will ever have one. This could be useful for running multi-threaded Python programs. The IronPython core itself should be mostly thread-safe; however, that hasn't been tested so there are almost certainly some issues there. I have full confidence that the IronPython core functionality will have no difficulty becoming fully thread safe as it moves to 1.0. My area of concern is around the standard objects. IronPython lists and dictionaries are not currently thread-safe. This is in line with the CLR collection APIs that assume the developer using lists and dictionaries will handle any needed synchronization. However, because of Python's GIL, Python lists and dictionaries behave as if they are thread-safe to the Python programmer. For compatibility with multi-threaded Python programs, IronPython will probably need to use thread-safe lists and dicts for these standard Python objects and this will impose some small but noticeable performance overhead. I'd like to come up with a more clever solution to this dilemma so that synchronization overhead is only imposed when it's truly needed, but I can't come up with a solution that wouldn't inflict undue compatibility burdens on Python devs. -Jim From lobrien at knowing.net Wed Oct 13 07:47:54 2004 From: lobrien at knowing.net (Larry O'Brien) Date: Tue, 12 Oct 2004 19:47:54 -1000 Subject: [IronPython] Wiki Away In-Reply-To: Message-ID: I've put up a FlexWiki at http://www.knowing.net/FePython/default.aspx/ There's absolutely zero content, so Wiki-away! Cheers, Larry From jvm_cop at spamcop.net Wed Oct 13 22:59:36 2004 From: jvm_cop at spamcop.net (J. Merrill) Date: Wed, 13 Oct 2004 16:59:36 -0400 Subject: [IronPython] IronPython cs Cpython wrt GIL In-Reply-To: <20041013033642.A809A1496A1@pillage.dreamhost.com> References: <20041012084821.21DA9985A6@che.dreamhost.com> Message-ID: <4.3.2.7.2.20041013165225.0480ced0@mail.comcast.net> At 11:36 PM 10/12/2004, Jim Hugunin wrote (in part) >My area of concern is around the standard objects. IronPython lists and >dictionaries are not currently thread-safe. This is in line with the CLR >collection APIs that assume the developer using lists and dictionaries will >handle any needed synchronization. However, because of Python's GIL, Python >lists and dictionaries behave as if they are thread-safe to the Python >programmer. For compatibility with multi-threaded Python programs, >IronPython will probably need to use thread-safe lists and dicts for these >standard Python objects and this will impose some small but noticeable >performance overhead. I'd like to come up with a more clever solution to >this dilemma so that synchronization overhead is only imposed when it's >truly needed, but I can't come up with a solution that wouldn't inflict >undue compatibility burdens on Python devs. > >-Jim Providing a notation that FePy-specific programs can use to say "I'll handle the synch work" should be enough. If we don't go to the trouble of adding that notation (and doing the synch work!), we'll get the overhead that's now "enjoyed" by traditional Python developers; if we do, we'll get extra speed (and extra danger if we screw up). Of course that means you've got to implement the thread-safe versions, keeping the existing ones around for use when we set that flag. Using a CLR-style attribute (ManualSynchAttribute?) would be the .NET clean way for us to make that notation; a comment in a special format would be another (kludgier) way. J. Merrill / Analytical Software Corp From levicook at gmail.com Wed Oct 13 23:52:09 2004 From: levicook at gmail.com (Levi Cook) Date: Wed, 13 Oct 2004 16:52:09 -0500 Subject: [IronPython] IronPython cs Cpython wrt GIL In-Reply-To: <4.3.2.7.2.20041013165225.0480ced0@mail.comcast.net> References: <20041012084821.21DA9985A6@che.dreamhost.com> <20041013033642.A809A1496A1@pillage.dreamhost.com> <4.3.2.7.2.20041013165225.0480ced0@mail.comcast.net> Message-ID: It's pretty clear, despite the performance burden, that lists and dicts need to be thread safe by default. Making it configurable is an interesting option. Maybe I didn't follow correctly, but altering Python's grammar to accommodate this doesn't feel like a good idea. Some more options... a) A system wide runtime config file that the interpreter consults on startup b) Use an environment variable c) A commandline arg b) IronPython specific builtins (if you really cared you could put something like this in your pythonrc file) try: list = felist except NameError: list = list I haven't thought about this enough to say what combination of the above would be best. For whatever it's worth, extending Python's syntax would push me away from IronPython down the road. Then again, I might have misinterpreted the last message. If so, sorry for rambling :) - Levi On Wed, 13 Oct 2004 16:59:36 -0400, J. Merrill wrote: > At 11:36 PM 10/12/2004, Jim Hugunin wrote (in part) > >My area of concern is around the standard objects. IronPython lists and > >dictionaries are not currently thread-safe. This is in line with the CLR > >collection APIs that assume the developer using lists and dictionaries will > >handle any needed synchronization. However, because of Python's GIL, Python > >lists and dictionaries behave as if they are thread-safe to the Python > >programmer. For compatibility with multi-threaded Python programs, > >IronPython will probably need to use thread-safe lists and dicts for these > >standard Python objects and this will impose some small but noticeable > >performance overhead. I'd like to come up with a more clever solution to > >this dilemma so that synchronization overhead is only imposed when it's > >truly needed, but I can't come up with a solution that wouldn't inflict > >undue compatibility burdens on Python devs. > > > >-Jim > > Providing a notation that FePy-specific programs can use to say "I'll handle the synch work" should be enough. If we don't go to the trouble of adding that notation (and doing the synch work!), we'll get the overhead that's now "enjoyed" by traditional Python developers; if we do, we'll get extra speed (and extra danger if we screw up). > > Of course that means you've got to implement the thread-safe versions, keeping the existing ones around for use when we set that flag. > > Using a CLR-style attribute (ManualSynchAttribute?) would be the .NET clean way for us to make that notation; a comment in a special format would be another (kludgier) way. > > J. Merrill / Analytical Software Corp > > > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From curt at hagenlocher.org Thu Oct 14 00:15:50 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 13 Oct 2004 15:15:50 -0700 Subject: [IronPython] IronPython cs Cpython wrt GIL Message-ID: <200410132215.PAA12487@dopey.hagenlocher.org> Levi Cook writes: > It's pretty clear, despite the performance burden, that lists and > dicts need to be thread safe by default. ... or at least as thread-safe as Python. What's the granularity of Python's lock? Per-statement? -- Curt Hagenlocher curt at hagenlocher.org From curt at hagenlocher.org Thu Oct 14 00:30:53 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 13 Oct 2004 15:30:53 -0700 Subject: [IronPython] IronPython cs Cpython wrt GIL Message-ID: <200410132230.PAA12514@dopey.hagenlocher.org> Curt Hagenlocher wrote: > What's the granularity of Python's lock? Per-statement? And before anyone answers, here's how I remember the situation, pre-2.0. The interpreter lock was held per-Python statement. BUT, many of the internal library calls were hardcoded to release the lock before executing a C library call and then reacquire the lock after the call was done. Am I close? -- Curt Hagenlocher curt at hagenlocher.org From indigo at bitglue.com Thu Oct 14 00:59:52 2004 From: indigo at bitglue.com (Phil Frost) Date: Wed, 13 Oct 2004 18:59:52 -0400 Subject: [IronPython] IronPython cs Cpython wrt GIL In-Reply-To: <200410132230.PAA12514@dopey.hagenlocher.org> References: <200410132230.PAA12514@dopey.hagenlocher.org> Message-ID: <20041013225952.GA25920@unununium.org> On Wed, Oct 13, 2004 at 03:30:53PM -0700, Curt Hagenlocher wrote: > Curt Hagenlocher wrote: > > > What's the granularity of Python's lock? Per-statement? > > And before anyone answers, here's how I remember the situation, > pre-2.0. > > The interpreter lock was held per-Python statement. BUT, many > of the internal library calls were hardcoded to release the > lock before executing a C library call and then reacquire the > lock after the call was done. > > Am I close? The lock is actually held when CPython is running its eval loop, and is released every 100 python instructions by default. When C extensions are making calls to blocking functions that don't manipulate python objects, they release the lock, for the call. Thus, the overhead of the lock is significantly lowered since it is not manipulated for every statement. However, it's such a problem with SMP boxen that I'd rather have a finer granularity lock. SMP is becoming more common each day, so I think this will only become a bigger problem. I think a good solution is to provide a builtin mixin class that adds a lock around all operations on a class. For the sake of compatability including this could be the default. From kfarmer at thuban.org Thu Oct 14 02:50:14 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 13 Oct 2004 17:50:14 -0700 Subject: [IronPython] IP 1.0 timeframe? Message-ID: Hey, Jim -- Have things settled down enough to get an idea of the timeframe for releasing 1.0? (Q2 2005...?) Is VS.NET support planned? Can you convince ASML2 and Comega to release more? :) From nicolas at lehuen.com Thu Oct 14 11:54:14 2004 From: nicolas at lehuen.com (Nicolas Lehuen) Date: Thu, 14 Oct 2004 11:54:14 +0200 Subject: [IronPython] IronPython cs Cpython wrt GIL In-Reply-To: <20041013033642.A809A1496A1@pillage.dreamhost.com> Message-ID: <20041014095431.4534F985A6@che.dreamhost.com> > Nicolas Lehuen wrote: > > There has been yet another thread on the Global Interpreter > Lock found > > in Cpython on comp.lang.python. Is there any such "annoyance" in > > IronPython (and, come to think of it, Jython) ? If not, I guess it > > would be a big advantage of IronPython (or Jython) vs CPython on > > multi-CPU or hyperthreading CPUs ? > > IronPython has no GIL today and it's unlikely that it will > ever have one. > This could be useful for running multi-threaded Python > programs. The IronPython core itself should be mostly > thread-safe; however, that hasn't been tested so there are > almost certainly some issues there. I have full confidence > that the IronPython core functionality will have no > difficulty becoming fully thread safe as it moves to 1.0. > > My area of concern is around the standard objects. > IronPython lists and dictionaries are not currently > thread-safe. This is in line with the CLR collection APIs > that assume the developer using lists and dictionaries will > handle any needed synchronization. However, because of > Python's GIL, Python lists and dictionaries behave as if they > are thread-safe to the Python programmer. For compatibility > with multi-threaded Python programs, IronPython will probably > need to use thread-safe lists and dicts for these standard > Python objects and this will impose some small but noticeable > performance overhead. I'd like to come up with a more clever > solution to this dilemma so that synchronization overhead is > only imposed when it's truly needed, but I can't come up with > a solution that wouldn't inflict undue compatibility burdens > on Python devs. > > -Jim Hi Jim, I'm not sure that lists and dictionaries behave as if they are thread-safe. What's sure is that a lot of Python developer act as if they are ;). I've joined a recent comp.lang.python thread where I ranted about the quasi-prehistoric thread support in Python, quite representative of the fact that a lot of Python developer don't worry about locking issues (as an illustration, a very core tool such as a reentrant lock is still implemented in pure Python, see threading.Rlock ; this should definitely be implemented in C). I think that the Python locking model for lists is quite the same as for Java's Vector (not ArrayList or a synchronized ArrayList), that is to say that you can safely assume that multiple threads can concurrently read or write in the structure without breaking it (which could append if two threads tried to reallocate the underlying array to a greater size, for example, but the GIL makes sure that won't never append). But this assumption won't be sufficient to make sure that multiple threads using the same list can have a consistent behaviour with respect to the algorithms they implement ; developers need to explicitely use locking semantics, be it in Python, Java or C#. Enter the dreadful problem of having to write code like : object.lock.acquire() try: # do something finally: object.lock.release() Whereas in Java you'd just write : synchronized(object) { // do something } The GIL is purely a design choice : having a big lock vs a lock per object and synchronisation to make sure that objects are kept in a coherent state. This seems a big difference, but at the end, for the developper, the behaviour of the language is nearly the same, since all native code is executed atomically from a byte-code point of view. The good news is that without the GIL, we can expect IronPython to perform even better than Cpython on multi-CPU / multi-core CPU machines. Regards, Nicolas From andy at nospam.com Thu Oct 14 16:37:30 2004 From: andy at nospam.com (Andy Sy) Date: Thu, 14 Oct 2004 22:37:30 +0800 Subject: [IronPython] IronPython cs Cpython wrt GIL In-Reply-To: <20041014095431.4534F985A6@che.dreamhost.com> References: <20041014095431.4534F985A6@che.dreamhost.com> Message-ID: <416E8F2A.9020300@nospam.com> Nicolas Lehuen wrote: >>handle any needed synchronization. However, because of >>Python's GIL, Python lists and dictionaries behave as if they >>are thread-safe to the Python programmer. For compatibility >>with multi-threaded Python programs, IronPython will probably >>need to use thread-safe lists and dicts for these standard >>Python objects and this will impose some small but noticeable >>performance overhead. I'd like to come up with a more clever >>solution to this dilemma so that synchronization overhead is >>only imposed when it's truly needed, but I can't come up with >>a solution that wouldn't inflict undue compatibility burdens >>on Python devs. > > I'm not sure that lists and dictionaries behave as if they are thread-safe. > What's sure is that a lot of Python developer act as if they are ;). I've > joined a recent comp.lang.python thread where I ranted about the > quasi-prehistoric thread support in Python, quite representative of the fact > that a lot of Python developer don't worry about locking issues (as an > illustration, a very core tool such as a reentrant lock is still implemented > in pure Python, see threading.Rlock ; this should definitely be implemented > in C). If I recall correctly from when I used them last in a threaded program, lists and dicts are indeed NOT thread-safe and is exactly why a Queue module is present. -- reply-to: a n d y @ n e t f x p h . c o m Lobbying for reply-to munging... From alleykat at gmail.com Thu Oct 14 17:25:48 2004 From: alleykat at gmail.com (Travis Watkins) Date: Thu, 14 Oct 2004 10:25:48 -0500 Subject: [IronPython] System.Byte[] Message-ID: In C# I have 'byte[] buffer = new byte[2048];' but I can't seem to get the same thing with IronPython. How do you create a variable with the System.Byte[] type in IronPython? From brian at zope.com Thu Oct 14 18:00:12 2004 From: brian at zope.com (Brian Lloyd) Date: Thu, 14 Oct 2004 12:00:12 -0400 Subject: [IronPython] System.Byte[] In-Reply-To: Message-ID: > In C# I have 'byte[] buffer = new byte[2048];' but I can't seem to get > the same thing with IronPython. How do you create a variable with the > System.Byte[] type in IronPython? A tricky way would be: # gotta get this in an odd way - you cant say System.Byte # directly, because that gives you a Python type object # rather than an actual System.Type instance... clrtype = System.Type.GetType('System.Byte') buffer = System.Array.CreateInstance(clrtype, 2048) Brian Lloyd brian at zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From kfarmer at thuban.org Thu Oct 14 19:58:47 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Thu, 14 Oct 2004 10:58:47 -0700 Subject: [IronPython] System.Byte[] Message-ID: Sounds like a call for a CLR namespace in Python to disambiguate System -- or at least aliases for the CLR types. ----- Keith J. Farmer http://www.thuban.org kfarmer at thuban.org -----Original Message----- From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Brian Lloyd Sent: 14 Oct 2004 09:00 # gotta get this in an odd way - you cant say System.Byte # directly, because that gives you a Python type object # rather than an actual System.Type instance... clrtype = System.Type.GetType('System.Byte') buffer = System.Array.CreateInstance(clrtype, 2048) From nicolas at lehuen.com Thu Oct 14 21:46:19 2004 From: nicolas at lehuen.com (Nicolas Lehuen) Date: Thu, 14 Oct 2004 21:46:19 +0200 Subject: [IronPython] IronPython cs Cpython wrt GIL In-Reply-To: <416E8F2A.9020300@nospam.com> Message-ID: <20041014194636.2B0E4985AA@che.dreamhost.com> > -----Message d'origine----- > De : users-ironpython.com-bounces at lists.ironpython.com > [mailto:users-ironpython.com-bounces at lists.ironpython.com] De > la part de Andy Sy > Envoy? : jeudi 14 octobre 2004 16:38 > ? : users-ironpython.com at lists.ironpython.com > Objet : Re: [IronPython] IronPython cs Cpython wrt GIL > ... > > > > I'm not sure that lists and dictionaries behave as if they > are thread-safe. > > What's sure is that a lot of Python developer act as if > they are ;). > > I've joined a recent comp.lang.python thread where I ranted > about the > > quasi-prehistoric thread support in Python, quite representative of > > the fact that a lot of Python developer don't worry about locking > > issues (as an illustration, a very core tool such as a > reentrant lock > > is still implemented in pure Python, see threading.Rlock ; > this should > > definitely be implemented in C). > > If I recall correctly from when I used them last in a > threaded program, lists and dicts are indeed NOT thread-safe > and is exactly why a Queue module is present. Thread safety can have different meanings. Do you mean that if I read/write concurrently in a dict, I can break it (i.e. put it in a incoherent state, for example due to two or three rehashing taking place at the same time and overwriting the hash buckets) ? Or simply that I cannot predict the global behaviour and that code like this is bound to have surprises : if mydict.has_key('foo'): # oh non, I don't want any foo here del mydict['foo'] Two threads can run concurrently this code, so that they both pass the has_key test and one of the two raises a KeyError since the other has already removed the foo key. My guess is that because of the GIL and the way native calls are performed while the GIL is locked (except when it performs I/O), you cannot "break" a dict (in the sense given above), as hard as you may try. In that sense, it is thread-safe. But, the code above is bound to fail if you don't perform some kind of user-level locking using threading.Lock or threading.Rlock. In that sense, it is NOT thread-safe. And there is no way it can be thread safe without the developer paying attention to what (s)he does. The Queue module is just a list with proper user-level locking to make sure that you can put() and get() objects in a safe way from different threads. Have a look at it, it's just a standard list with locking based on thread.allocate_lock() (which is the low-level object used by threading.Lock and threading.RLock()). It is not a one-size-fits-all solution to threading problems, just a handy way to communicate between threads. Regards, Nicolas From jim at ironpython.com Fri Oct 15 05:04:01 2004 From: jim at ironpython.com (Jim Hugunin) Date: Thu, 14 Oct 2004 20:04:01 -0700 Subject: [IronPython] System.Byte[] In-Reply-To: Message-ID: <20041015030408.EF2CC149699@pillage.dreamhost.com> This particular issue is just a weakness in the current IronPython-0.6. System.Byte should definitely be auto-converted to a System.Type object when passed to a method that requires one. This means that you should be able to do: System.Array.CreateInstance(System.Byte, 2048) I expect this will just work in IronPython-0.7. Even though this case will work, there still needs to be a better way of going back and forth between Python and CLR type objects. For example, I'd like to call System.Byte.GetMethods(). This won't currently work because Python type objects don't have this method. I'd like some way of doing this without going through the string-based reflection API that's required today. -Jim Keith J. Farmer wrote: > Sounds like a call for a CLR namespace in Python to disambiguate System > -- or at least aliases for the CLR types. > > -----Original Message----- > From: users-ironpython.com-bounces at lists.ironpython.com > [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of > Brian Lloyd > Sent: 14 Oct 2004 09:00 > > # gotta get this in an odd way - you cant say System.Byte > # directly, because that gives you a Python type object > # rather than an actual System.Type instance... > clrtype = System.Type.GetType('System.Byte') > > buffer = System.Array.CreateInstance(clrtype, 2048) > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jim at ironpython.com Fri Oct 15 05:12:03 2004 From: jim at ironpython.com (Jim Hugunin) Date: Thu, 14 Oct 2004 20:12:03 -0700 Subject: [IronPython] IP 1.0 timeframe? In-Reply-To: Message-ID: <20041015031207.1E52F149699@pillage.dreamhost.com> Keith J. Farmer wrote: > Have things settled down enough to get an idea of the timeframe for > releasing 1.0? (Q2 2005...?) > > Is VS.NET support planned? Sorry, but I still can't make any new statements about release plans. This list will be among the first to know when I can say something new. > Can you convince ASML2 and Comega to release more? :) I've been having a lot of fun talks with Erik Meijer who was one of the main designers for Comega. It is pretty cool. You'll have to wait and see what comes out of that work next. I've never heard of ASML2 before. Do you have a pointer to that project? -Jim From kfarmer at thuban.org Fri Oct 15 07:02:42 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Thu, 14 Oct 2004 22:02:42 -0700 Subject: [IronPython] IP 1.0 timeframe? Message-ID: AsmL2 -- http://research.microsoft.com/fse/asml/ My only complaint with AsmL so far is the fact that it isn't separated from C# in the IDE. Excerpt: """ AsmL is the Abstract State Machine Language. It is an executable specification language based on the theory of Abstract State Machines. The current version, AsmL 2 (AsmL for Microsoft .NET), is embedded into Microsoft Word and Microsoft Visual Studio.NET. It uses XML and Word for literate specifications. It is fully interoperable with other .NET languages. AsmL generates .NET assemblies which can either be executed from the command line, linked with other .NET assemblies, or packaged as COM components. What is it good for? AsmL is useful in any situation where you need a precise, non-ambiguous way to specify a computer system, either software or hardware. AsmL specifications are an ideal way for teams to communicate design decisions. Program managers, developers, and testers can all use an AsmL specification to achieve a single, unified understanding. One of the greatest benefits of an AsmL specification is that you can execute it. That means it is useful before you commit yourself to coding the entire system. By exploring your design, you can answer the following questions: Does it do everything you intended it to? How do the features interact? Are there any unintended behaviors? """ ----- Keith J. Farmer http://www.thuban.org kfarmer at thuban.org -----Original Message----- From: Jim Hugunin [mailto:jim at ironpython.com] Sent: 14 Oct 2004 20:12 I've never heard of ASML2 before. Do you have a pointer to that project? From csharpener at softhome.net Fri Oct 15 21:58:51 2004 From: csharpener at softhome.net (John Tobler) Date: Fri, 15 Oct 2004 12:58:51 -0700 Subject: [IronPython] IP 1.0 timeframe? In-Reply-To: References: Message-ID: <41702BFB.90008@softhome.net> Keith J. Farmer wrote: >AsmL2 -- http://research.microsoft.com/fse/asml/ > >My only complaint with AsmL so far is the fact that it isn't separated >from C# in the IDE. > > Be a little careful with AsmL. While I think it is very cool, it is a research project at Microsoft Research and there are no guarantees it will ever be released for public use. As long as you realize it is a research toy and not a production system upon which to bet your company's future, you can have some real fun with it. If you don't like using Visual Studio to write your AsmL, you can do it in Microsoft Word. Enjoy, John Tobler csharpener AT softhome.net CSharpener's Weblog: http://weblogs.asp.net/jtobler/ From kfarmer at thuban.org Fri Oct 15 22:51:39 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Fri, 15 Oct 2004 13:51:39 -0700 Subject: [IronPython] IP 1.0 timeframe? Message-ID: You misunderstood me -- I want it to be completed and released as a fully supported language, as well as Cw and (hopefully) IP. I also want it to have its own life in VS, as a peer to the other languages (Cw does, I'd expect IP to), rather than living within some other language's realm. I really don't care about programming in MS Word. I remember writing to the AsmL folks once, asking about this, and the response was that they were looking into it, but it's been a good year since I've heard anything new. Between AsmL, Cw, and IronPython, I think we could have a pretty good set of languages for development: Cw for the hard-core data layer, AsmL for state machines and specifications, and IP for the PyZen. ________________________________ From: John Tobler [mailto:csharpener at softhome.net] Sent: Fri 10/15/2004 12:58 PM Be a little careful with AsmL. While I think it is very cool, it is a research project at Microsoft Research and there are no guarantees it will ever be released for public use. As long as you realize it is a research toy and not a production system upon which to bet your company's future, you can have some real fun with it. If you don't like using Visual Studio to write your AsmL, you can do it in Microsoft Word. From andrew at adersoftware.com Sun Oct 17 05:15:10 2004 From: andrew at adersoftware.com (Andrew Deren) Date: Sat, 16 Oct 2004 22:15:10 -0500 Subject: [IronPython] IP 1.0 timeframe? In-Reply-To: <41702BFB.90008@softhome.net> Message-ID: <20041016211649.SM00276@ANDREW> If you're interested in learning more about asml (and it's concepts) there will be a seminar at university of Chicago: UNIVERSITY OF CHICAGO LOGIC SEMINAR TIME: Friday, November 5, 2004, 1:30-2:20 ROOM: Ryerson 251 TITLE: Abstract State Machines: From Foundations to Microsoft Tools SPEAKER: Yuri Gurevich, Microsoft Research ABSTRACT: What is computer science about? Largely about algorithms. Programming languages, compilers, operating systems, communication protocols, etc. are algorithms. (More exactly, each of these gives rise to a number of algorithms depending on the chosen abstraction level.) And what's an algorithm? One may think that the question was answered in full long ago by Church and Turing but it wasn't; there is more to an algorithm than the function it computes. (And what function does an operating system compute?) This line of research led to the definition of abstract state machines and the ASM thesis: For every algorithm A, there is an ASM that is behaviorally equivalent to A. If A is sequential-time then the ASM simulates A step for step. International experimentation with ASMs supports the thesis, and ever larger portions of the thesis have been (and are being) proved from the first principles; see articles 141, 157, 166 and 170. ASMs are a natural vehicle for executable specifications. That caught the attention of Microsoft Research and lead to the formation of a group on Foundations of Software Engineering. Some people think that executable specification is a contradiction in terms. We think that executable specifications will change the way software is designed, developed, tested and documented. The specification languages AsmL and Spec#, developed by the FSE group, make writing relatively large ASMs practical. Our tools allow the developers (more and more) to experiment with their design, validate and enforce it. The tools empower numerous testers and enable them to be involved earlier in the software development cycle. We'll demonstrate SpecExplorer, our latest tool. BIOGRAPHICAL SKETCH: Yuri Gurevich is a Sr. Researcher at Microsoft Research in Redmond, WA. He is also Professor Emeritus at the University of Michigan, an ACM Fellow, a Guggenheim Fellow, and Dr. Honoris Causa of the Limburg University in Belgium. HOST: Robert Soare -----Original Message----- From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of John Tobler Sent: Friday, October 15, 2004 2:59 PM To: Keith J. Farmer Cc: users-ironpython.com at lists.ironpython.com Subject: Re: [IronPython] IP 1.0 timeframe? Keith J. Farmer wrote: >AsmL2 -- http://research.microsoft.com/fse/asml/ > >My only complaint with AsmL so far is the fact that it isn't separated >from C# in the IDE. > > Be a little careful with AsmL. While I think it is very cool, it is a research project at Microsoft Research and there are no guarantees it will ever be released for public use. As long as you realize it is a research toy and not a production system upon which to bet your company's future, you can have some real fun with it. If you don't like using Visual Studio to write your AsmL, you can do it in Microsoft Word. Enjoy, John Tobler csharpener AT softhome.net CSharpener's Weblog: http://weblogs.asp.net/jtobler/ _______________________________________________ users-ironpython.com mailing list users-ironpython.com at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fantasysoft at hotmail.com Mon Oct 18 06:13:42 2004 From: fantasysoft at hotmail.com (=?gb2312?B?zLcg07G7qg==?=) Date: Mon, 18 Oct 2004 04:13:42 +0000 Subject: [IronPython] A little bug about "in" operator Message-ID: Among three kinds of special data types in Python: Dictionary,List and Tuple, the operator "in" works well in Dict and List, but Tuple. Here is the sample code: >>> t = (1,2,3) >>> t (1,2,3) >>> 2 in t True it's OK >>> 5 in t False it' OK, too >>> 's' in t True It's wrong here. And in CPython, the statement of " 's' in t " produces the correct result: False. _________________________________________________________________ ???? MSN Explorer: http://explorer.msn.com/lccn From jvm_cop at spamcop.net Mon Oct 18 14:46:57 2004 From: jvm_cop at spamcop.net (J. Merrill) Date: Mon, 18 Oct 2004 08:46:57 -0400 Subject: [IronPython] IP 1.0 timeframe? In-Reply-To: <20041016211649.SM00276@ANDREW> References: <41702BFB.90008@softhome.net> Message-ID: <4.3.2.7.2.20041018084525.04fdc008@mail.comcast.net> Note that this is not to the mailing list. Does any of you know whether there will be an MP3 / WAV / DOC (or even PPT) version of the presentation available? A trip to Chicago for a 50-minute seminar would probably not, overall, be a productive use of my time -- though I'm quite interested in the topic. Thanks. At 11:15 PM 10/16/2004, Andrew Deren wrote: >If you're interested in learning more about asml (and it's concepts) there >will be a seminar at university of Chicago: > > UNIVERSITY OF CHICAGO LOGIC SEMINAR > >TIME: Friday, November 5, 2004, 1:30-2:20 >ROOM: Ryerson 251 > >TITLE: Abstract State Machines: From Foundations to Microsoft Tools > >SPEAKER: Yuri Gurevich, Microsoft Research >[snip] J. Merrill / Analytical Software Corp From Nirmal_C at Dell.com Mon Oct 18 15:23:17 2004 From: Nirmal_C at Dell.com (Nirmal_C at Dell.com) Date: Mon, 18 Oct 2004 08:23:17 -0500 Subject: [IronPython] IP 1.0 timeframe? Message-ID: <4D8F2325E068D94F8F750FDFB1BD36C3228F29@blrx2kmbgl101.blr.amer.dell.com> ASML Syntax looks very much Pythoni'c ;-) -----Original Message----- From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer Sent: Saturday, October 16, 2004 2:22 AM To: users-ironpython.com at lists.ironpython.com Subject: RE: [IronPython] IP 1.0 timeframe? You misunderstood me -- I want it to be completed and released as a fully supported language, as well as Cw and (hopefully) IP. I also want it to have its own life in VS, as a peer to the other languages (Cw does, I'd expect IP to), rather than living within some other language's realm. I really don't care about programming in MS Word. I remember writing to the AsmL folks once, asking about this, and the response was that they were looking into it, but it's been a good year since I've heard anything new. Between AsmL, Cw, and IronPython, I think we could have a pretty good set of languages for development: Cw for the hard-core data layer, AsmL for state machines and specifications, and IP for the PyZen. ________________________________ From: John Tobler [mailto:csharpener at softhome.net] Sent: Fri 10/15/2004 12:58 PM Be a little careful with AsmL. While I think it is very cool, it is a research project at Microsoft Research and there are no guarantees it will ever be released for public use. As long as you realize it is a research toy and not a production system upon which to bet your company's future, you can have some real fun with it. If you don't like using Visual Studio to write your AsmL, you can do it in Microsoft Word. _______________________________________________ users-ironpython.com mailing list users-ironpython.com at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From alleykat at gmail.com Tue Oct 19 06:26:15 2004 From: alleykat at gmail.com (Travis Watkins) Date: Mon, 18 Oct 2004 23:26:15 -0500 Subject: [IronPython] DLLs, namespaces Message-ID: Any guess on when we can make DLL files and maybe namespaces? I can't seem to figure out how to make a program in IronPython with multiple files without using a DLL. From joncosby at mindspring.com Wed Oct 20 00:44:13 2004 From: joncosby at mindspring.com (Jon Cosby) Date: Tue, 19 Oct 2004 15:44:13 -0700 Subject: [IronPython] Snippets Message-ID: What are "snippets" and "__main__" in the IronPython bin? They don't appear to be necessary to run the application, but I could be missing something. Jon Cosby From jim at ironpython.com Wed Oct 20 01:12:25 2004 From: jim at ironpython.com (Jim Hugunin) Date: Tue, 19 Oct 2004 16:12:25 -0700 Subject: [IronPython] Snippets In-Reply-To: Message-ID: <20041019231227.31C9E86267@plunder.dreamhost.com> Jon Cosby wrote: > What are "snippets" and "__main__" in the IronPython bin? They don't > appear > to be necessary to run the application, but I could be missing something. These files are generated by running a Python script. The ones in the .zip file are there because I didn't fully clean-up after running some tests just before shipping. If you run your own Python script you'll find that these two files get created. If you're interested in better understanding how IronPython works, these files can be very valuable. __main__.exe is the compiled form of whatever Python script you run. __main__ is the name given to the executing module when you run a script on the commandline. If you import other Python modules, they will have corresponding compiled files created. These files are equivalent to standard CPython's .pyc files except that they hold IL bytecode for the CLR instead of Python-specific bytecodes. snippets.dll will only be written to disk after a run of Python completes. It will even be generated after running at the interactive interpreter prompt. This assembly contains helper classes that are generated during the run. It includes classes to improve the performance of calling some CLR classes from Python as well as CLR classes generated to represent any new-style Python classes you might create in your program. This file is intended to only be in-memory. In the future it will only be written to disk if you run in an advanced debugging mode. Right now it is always written out because I assume that anyone running IronPython-0.6 wants to be in advanced debugging mode all the time. A good tool for looking at this file is ildasm which ships with the .NET SDK. BTW - __main__.exe is also generated primarily for debugging and understanding purposes. It should not be generated in the future because CPython doesn't create a corresponding __main__.pyc file. In the future there will be a IronPythonCompiler (hopefully with an easier to type name) to generate a exe or dll statically from a Python script. -Jim From curt at hagenlocher.org Wed Oct 20 01:44:04 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 19 Oct 2004 16:44:04 -0700 Subject: [IronPython] Snippets Message-ID: <200410192344.QAA04603@dopey.hagenlocher.org> > snippets.dll will only be written to disk after a run of Python > completes. > [...] > A good tool for looking at this file is ildasm > which ships with the .NET SDK. An even better tool for looking at this file is Reflector http://www.aisto.com/roeder/dotnet/ -- Curt Hagenlocher curt at hagenlocher.org From firemoth at gmail.com Wed Oct 20 07:30:59 2004 From: firemoth at gmail.com (Timothy Fitz) Date: Wed, 20 Oct 2004 01:30:59 -0400 Subject: [IronPython] A little bug about "in" operator In-Reply-To: <972ec5bd0410191201742bdfab@mail.gmail.com> References: <972ec5bd0410191201742bdfab@mail.gmail.com> Message-ID: <972ec5bd0410192230266a3bad@mail.gmail.com> While attempting to troubleshoot I noticed another error, >>> t = (None,2,3) >>> 's' in t And out comes an error about NoneType not being itterable. I won't have a chance to work on this again until thursday, anybody else attempting to fix it? On Mon, 18 Oct 2004 04:13:42 +0000, ? ?? wrote: > Among three kinds of special data types in Python: Dictionary,List and > Tuple, the operator "in" works well in Dict and List, but Tuple. Here is > the sample code: > > >>> t = (1,2,3) > >>> t > (1,2,3) > >>> 2 in t > True it's OK > >>> 5 in t > False it' OK, too > > >>> 's' in t > True It's wrong here. > > And in CPython, the statement of " 's' in t " produces the correct result: > False. > > _________________________________________________________________ > ???? MSN Explorer: http://explorer.msn.com/lccn > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From firemoth at gmail.com Wed Oct 20 23:59:52 2004 From: firemoth at gmail.com (Timothy Fitz) Date: Wed, 20 Oct 2004 17:59:52 -0400 Subject: [IronPython] Re: A little bug about "in" operator In-Reply-To: <972ec5bd0410192230266a3bad@mail.gmail.com> References: <972ec5bd0410191201742bdfab@mail.gmail.com> <972ec5bd0410192230266a3bad@mail.gmail.com> Message-ID: <972ec5bd0410201459854c2f2@mail.gmail.com> [? ??] > >>> t = (1,2,3) > >>> t > (1,2,3) > >>> 2 in t > True > >>> 5 in t > False > >>> 's' in t > True I think Line 329 of Object\Ops.cs should test for support of the ISequence interface. public static object In(object x, object y) { if (y is IDictionary) { return bool2object(((IDictionary)y).Contains(x)); } else if (y is IList) { return bool2object( ((IList)y).Contains(x) ); } else if (y is ISequence) { return ((ISequence)y).__contains__(x); } else { IEnumerator e = GetEnumerator(y); while (e.MoveNext()) { if (Ops.IsTrue(Ops.Equal(e.Current, x))) return TRUE; } return FALSE; } } Unfortunately, this leads to the conclusion that the fallback code here isn't working. On further inspection, Ops.Equal is returning Ops.NotImplemented, which is actually a string. A string tests true. The ISequence fix rids you of the tuple problem, however A: Ops.NotImplemented should be a class, and B: IntOps.Equals should handle the string case in some way or another. From firemoth at gmail.com Thu Oct 21 00:08:22 2004 From: firemoth at gmail.com (Timothy Fitz) Date: Wed, 20 Oct 2004 18:08:22 -0400 Subject: [IronPython] Re: A little bug about "in" operator In-Reply-To: <972ec5bd0410201459854c2f2@mail.gmail.com> References: <972ec5bd0410191201742bdfab@mail.gmail.com> <972ec5bd0410192230266a3bad@mail.gmail.com> <972ec5bd0410201459854c2f2@mail.gmail.com> Message-ID: <972ec5bd0410201508277da9db@mail.gmail.com> > Unfortunately, this leads to the conclusion that the fallback code > here isn't working. On further inspection, Ops.Equal is returning > Ops.NotImplemented, which is actually a string. A string tests true. > The ISequence fix rids you of the tuple problem, however A: > Ops.NotImplemented should be a class, and B: IntOps.Equals should > handle the string case in some way or another. P.S. Anything wrong with solving A via changing public static object NotImplemented = ""; //!!! need really singleton objects to public static object NotImplemented = new PythonExceptionNew(""); ?