From jim at ironpython.com Mon Aug 9 05:40:00 2004 From: jim at ironpython.com (Jim Hugunin) Date: Sun, 8 Aug 2004 20:40:00 -0700 Subject: [IronPython] Welcome! Message-ID: <20040809034007.53E5E13D8A0@sack.dreamhost.com> This list was created in response to the many questions that I have received about IronPython since the first public release just over a week ago. Please ask your questions, make your suggestions and report your bugs here for everyone to share. I'll try to answer questions on this list in a timely fashion; however, I'm in the middle of starting a new job and moving my family across several states so don't be surprised if I "disappear" from time to time. -Jim Hugunin From danlash at gmail.com Mon Aug 9 21:15:28 2004 From: danlash at gmail.com (Dan Lash) Date: Mon, 9 Aug 2004 15:15:28 -0400 Subject: [IronPython] Threading/Delegates Message-ID: I've just been playing around with IronPython and some of the .NET framework the past few days, and I tried porting over an example off of the MSDN library about threading. The first thing I noticed is that I can't seem to get any class declarations going. Even this doesn't work: class Test: def Hello(): print "Hello" IronPython gives: System.Reflection.TargetException: Non-static field requires a target. at System.Reflection.RuntimeFieldInfo.InternalGetValue(Object obj, Boolean re quiresAccessCheck) at System.Reflection.RuntimeFieldInfo.GetValue(Object obj) at IronPython.Objects.module.__getattribute__(String name) at IronPython.Objects.ModuleDictionary.get_Item(Object key) at IronPython.Objects.Frame.GetGlobal(String name) at input_0.Run(Frame frame) at IronPythonConsole.IronPython.DoInteractive() But I guess that may be another issue, what I wanted to get going was the following: from System import * from System.Threading import * def ThreadProc(): for i in range(10): Console.WriteLine("ThreadProc: {0}", i) Thread.Sleep(0) def Main(): Console.WriteLine("Main thread: Start a second thread.") t = Thread(ThreadStart(ThreadProc)) t.Start() for i in range(4): Console.WriteLine("Main thread: Do some work.") Thread.Sleep(0) Console.WriteLine("Main thread: Call Join(), to wait until ThreadProc ends.") t.Join() Console.WriteLine("Main thread: ThreadProc.Join has returned. Press Enter to end program.") Console.ReadLine() Which is a port (minus the class) out of: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemthreadingthreadclasstopic.asp Upon further inspection, it doesn't seem that ThreadStart works on any level: System.Exception: bad args to this method at IronPython.Objects.ReflectedMethodBase.Call(Object[] args) at IronPython.Objects.ReflectedType.Call(Object[] args) at IronPython.Objects.Ops.Call(Object func, Object arg0) at input_3.Main$f1() at IronPython.Objects.Function0.Call() at IronPython.Objects.Ops.Call(Object func) at input_5.Run(Frame frame) at IronPythonConsole.IronPython.DoInteractive() Am I missing something here, is my Python syntax wrong? Or is IronPython just not ready for ThreadStart delegates? From thane at magna-capital.com Mon Aug 9 22:18:47 2004 From: thane at magna-capital.com (Thane) Date: Mon, 9 Aug 2004 13:18:47 -0700 Subject: [IronPython] Threading/Delegates In-Reply-To: Message-ID: Dan, I think that IronPython acts more like VB than C#, so be sure to read the VB comments in MSDN code for ideas. (Since VB doesn't require a ThreadStart object, I thought IronPython wouldn't either.) Below is what I think you were trying to do. Note that I put the main print loop in one line so I could copy/paste the command easily. --Thane >>> from System import * >>> from System.Threading import * >>> def foo(): ... for i in range(10): ... print i ... Thread.Sleep(2000) # allow some time to type... ... >>> t = Thread(foo) >>> t >>> () >>> t.Start() >>> 0 () >>> for i in range(20, 30): print i; Thread.Sleep(1000) 20 1 21 22 2 23 24 3 25 26 4 27 28 5 29 >>> 6 7 8 9 () >>> -----Original Message----- From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Dan Lash Sent: Monday, August 09, 2004 12:15 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Threading/Delegates I've just been playing around with IronPython and some of the .NET framework the past few days, and I tried porting over an example off of the MSDN library about threading. The first thing I noticed is that I can't seem to get any class declarations going. Even this doesn't work: class Test: def Hello(): print "Hello" IronPython gives: System.Reflection.TargetException: Non-static field requires a target. at System.Reflection.RuntimeFieldInfo.InternalGetValue(Object obj, Boolean re quiresAccessCheck) at System.Reflection.RuntimeFieldInfo.GetValue(Object obj) at IronPython.Objects.module.__getattribute__(String name) at IronPython.Objects.ModuleDictionary.get_Item(Object key) at IronPython.Objects.Frame.GetGlobal(String name) at input_0.Run(Frame frame) at IronPythonConsole.IronPython.DoInteractive() But I guess that may be another issue, what I wanted to get going was the following: from System import * from System.Threading import * def ThreadProc(): for i in range(10): Console.WriteLine("ThreadProc: {0}", i) Thread.Sleep(0) def Main(): Console.WriteLine("Main thread: Start a second thread.") t = Thread(ThreadStart(ThreadProc)) t.Start() for i in range(4): Console.WriteLine("Main thread: Do some work.") Thread.Sleep(0) Console.WriteLine("Main thread: Call Join(), to wait until ThreadProc ends.") t.Join() Console.WriteLine("Main thread: ThreadProc.Join has returned. Press Enter to end program.") Console.ReadLine() Which is a port (minus the class) out of: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/ frlrfsystemthreadingthreadclasstopic.asp Upon further inspection, it doesn't seem that ThreadStart works on any level: System.Exception: bad args to this method at IronPython.Objects.ReflectedMethodBase.Call(Object[] args) at IronPython.Objects.ReflectedType.Call(Object[] args) at IronPython.Objects.Ops.Call(Object func, Object arg0) at input_3.Main$f1() at IronPython.Objects.Function0.Call() at IronPython.Objects.Ops.Call(Object func) at input_5.Run(Frame frame) at IronPythonConsole.IronPython.DoInteractive() Am I missing something here, is my Python syntax wrong? Or is IronPython just not ready for ThreadStart delegates? _______________________________________________ users-ironpython.com mailing list users-ironpython.com at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From edd at usefulinc.com Mon Aug 9 22:49:07 2004 From: edd at usefulinc.com (Edd Dumbill) Date: Mon, 09 Aug 2004 21:49:07 +0100 Subject: [IronPython] Threading/Delegates In-Reply-To: References: Message-ID: <1092084547.28646.81.camel@saag> On Mon, 2004-08-09 at 15:15 -0400, Dan Lash wrote: > > The first thing I noticed is that I can't seem to get any class > declarations going. Even this doesn't work: > > class Test: > def Hello(): > print "Hello" That's because Python methods need the 'this' reference (pronounced 'self' in Python) as their first argument: class Test: def Hello (self): print "Hello" if __name__ == '__main__': t = Test () t.Hello () -- Edd -- Edd Dumbill, Editor-at-Large, O'Reilly Network More from me on my weblog -- http://usefulinc.com/edd/blog Mono book -- http://usefulinc.com/edd/books/mono-notebook From danlash at gmail.com Mon Aug 9 23:16:38 2004 From: danlash at gmail.com (Dan Lash) Date: Mon, 9 Aug 2004 17:16:38 -0400 Subject: [IronPython] Threading/Delegates In-Reply-To: References: Message-ID: Thanks for the advice about using the VB example. I couldn't find how to get the address of an object in python (as the VB example says to do) so I tried just passing in the method, and it works. And I guess I must have messed up my python class declaration, because I now can get that working too. Heres the code that works: from System import * from System.Threading import * class ThreadTest: def ThreadProc(self): for i in range(10): Console.WriteLine("ThreadProc: {0}", i) Thread.Sleep(500) def __init__(self): Console.WriteLine("Main thread: Start a second thread.", 1) t = Thread(self.ThreadProc) t.Start() for i in range(4): Console.WriteLine("Main thread: Do some work.", 1) Thread.Sleep(500) Console.WriteLine("Main thread: Call Join(), to wait until ThreadProc ends.", 1) t.Join() Console.WriteLine("Main thread: ThreadProc.Join has returned. Press Enter to end program.", 1) Console.ReadLine() tt = ThreadTest() An interesting side note, is if the ThreadProc accepts another argument, lets say "name", and you try to pass that in when you are creating the thread, it actually calls the method right then and there...Oh well. Thanks Thane (c: -Dan On Mon, 9 Aug 2004 13:18:47 -0700, Thane wrote: > Dan, I think that IronPython acts more like VB than C#, so be sure to read > the VB comments in MSDN code for ideas. (Since VB doesn't require a > ThreadStart object, I thought IronPython wouldn't either.) Below is what I > think you were trying to do. Note that I put the main print loop in one > line so I could copy/paste the command easily. > > --Thane > > >>> from System import * > >>> from System.Threading import * > >>> def foo(): > .... for i in range(10): > .... print i > .... Thread.Sleep(2000) # allow some time to type... > .... > >>> t = Thread(foo) > >>> t > > >>> > () > >>> t.Start() > >>> 0 > > () > >>> for i in range(20, 30): print i; Thread.Sleep(1000) > 20 > 1 > 21 > 22 > 2 > 23 > 24 > 3 > 25 > 26 > 4 > 27 > 28 > 5 > 29 > >>> 6 > 7 > 8 > 9 > > () > > > >>> > > -----Original Message----- > From: users-ironpython.com-bounces at lists.ironpython.com > [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Dan > Lash > Sent: Monday, August 09, 2004 12:15 PM > To: users-ironpython.com at lists.ironpython.com > Subject: [IronPython] Threading/Delegates > > I've just been playing around with IronPython and some of the .NET > framework the past few days, and I tried porting over an example off > of the MSDN library about threading. > > The first thing I noticed is that I can't seem to get any class > declarations going. Even this doesn't work: > > class Test: > def Hello(): > print "Hello" > > IronPython gives: > > System.Reflection.TargetException: Non-static field requires a target. > at System.Reflection.RuntimeFieldInfo.InternalGetValue(Object obj, Boolean > re > quiresAccessCheck) > at System.Reflection.RuntimeFieldInfo.GetValue(Object obj) > at IronPython.Objects.module.__getattribute__(String name) > at IronPython.Objects.ModuleDictionary.get_Item(Object key) > at IronPython.Objects.Frame.GetGlobal(String name) > at input_0.Run(Frame frame) > at IronPythonConsole.IronPython.DoInteractive() > > But I guess that may be another issue, what I wanted to get going was > the following: > > from System import * > from System.Threading import * > > def ThreadProc(): > for i in range(10): > Console.WriteLine("ThreadProc: {0}", i) > Thread.Sleep(0) > > def Main(): > Console.WriteLine("Main thread: Start a second thread.") > t = Thread(ThreadStart(ThreadProc)) > t.Start() > for i in range(4): > Console.WriteLine("Main thread: Do some work.") > Thread.Sleep(0) > Console.WriteLine("Main thread: Call Join(), to wait until ThreadProc > ends.") > t.Join() > Console.WriteLine("Main thread: ThreadProc.Join has returned. > Press Enter to end program.") > Console.ReadLine() > > Which is a port (minus the class) out of: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/ > frlrfsystemthreadingthreadclasstopic.asp > > Upon further inspection, it doesn't seem that ThreadStart works on any > level: > > System.Exception: bad args to this method System.Threading.ThreadStart> > at IronPython.Objects.ReflectedMethodBase.Call(Object[] args) > at IronPython.Objects.ReflectedType.Call(Object[] args) > at IronPython.Objects.Ops.Call(Object func, Object arg0) > at input_3.Main$f1() > at IronPython.Objects.Function0.Call() > at IronPython.Objects.Ops.Call(Object func) > at input_5.Run(Frame frame) > at IronPythonConsole.IronPython.DoInteractive() > > Am I missing something here, is my Python syntax wrong? Or is > IronPython just not ready for ThreadStart delegates? > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From Mark.Fernandes at senecac.on.ca Wed Aug 11 01:04:43 2004 From: Mark.Fernandes at senecac.on.ca (Mark Fernandes) Date: Tue, 10 Aug 2004 19:04:43 -0400 Subject: [IronPython] What is the story behind the name? Message-ID: <2f2552c58d.2c58d2f255@senecac.on.ca> Hello Everyone, I realize this question might be off-topic but I hope you will answer. Does anyone know the story behind the name - IronPython. Thanks, Mark Fernandes. From danlash at gmail.com Wed Aug 11 22:58:23 2004 From: danlash at gmail.com (Dan Lash) Date: Wed, 11 Aug 2004 16:58:23 -0400 Subject: [IronPython] Method Arguments Message-ID: Is there a good way to get the constructor and/or method arguments in IronPython? I've been trying to do some simple 3D (DirectX9) examples, and some of the constructors/methods are throwing exceptions. Here's some example code (DX9 SDK must be installed): import sys sys.LoadAssemblyByName("Microsoft.DirectX.Direct3D") from Microsoft.DirectX.Direct3D.CustomVertex import * from Microsoft.DirectX.Direct3D import * from Microsoft.DirectX import * from System.Windows.Forms import * from System.Drawing import * form = Form() presentParams = PresentParameters() presentParams.Windowed = True presentParams.SwapEffect = SwapEffect.Discard device = Device(0, DeviceType.Hardware, form, CreateFlags.SoftwareVertexProcessing, presentParams) device.Clear(ClearFlags.Target, Color.Blue, 1.0, 0) device.BeginScene() device.EndScene() device.Present() The device.Clear method has several overloaded versions of itself as listed on the MSDN website: public void Clear(ClearFlags, Color, float, int); public void Clear(ClearFlags, Color, float, int, Rectangle[]); public void Clear(ClearFlags, int, float, int); public void Clear(ClearFlags, int, float, int, Rectangle[]); After I run device.Clear.GetMaxArgs() it returns 5, but it doesn't say which if the two overloaded versions with 5 arguments that it wants. Is IronPython standardizing which method it is implimenting/calling? The same problem shows up when I try to create a VertexBuffer who has 6 overloaded versions of its' constructor: public VertexBuffer(Device, int, Usage, VertexFormats, Pool); public VertexBuffer(IDirect3DVertexBuffer9); public VertexBuffer(IDirect3DVertexBuffer9, Device, Usage, VertexFormats, Pool); public VertexBuffer(IDirect3DVertexBuffer9, Type, int, Device, Usage, VertexFormats, Pool); public VertexBuffer(IntPtr); public VertexBuffer(Type, int, Device, Usage, VertexFormats, Pool); On both the device.Clear and the VertexBuffer constructor, I've tried every different combination I can think of to no avail. And IronPython doesn't make it easy to see what the arguments are that it wants: System.Exception: bad args to this method at IronPython.Objects.ReflectedMethodBase.Call(Object[] args) at IronPython.Objects.Ops.Call(Object func, Object arg0, Object arg1, Object arg2, Object arg3) at input_15.Run(Frame frame) at IronPythonConsole.IronPython.DoInteractive() So basically I'm wondering if there is a good way to figure out what are the arguments to the version of the method that IronPython is using. Thanks guys, -Dan From comron at umail.ucsb.edu Wed Aug 11 23:09:44 2004 From: comron at umail.ucsb.edu (Comron Sattari) Date: Wed, 11 Aug 2004 14:09:44 -0700 Subject: [IronPython] Compilation to IL Message-ID: Hi, I recently downloaded IronPython and would like to compile my python programs directly to IL, yet I can't seem to figure out how. Am I missing something obvious? Please advise, Comron From curt at hagenlocher.org Thu Aug 12 01:38:16 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 11 Aug 2004 16:38:16 -0700 Subject: [IronPython] Continuations and IronPythonConsole Message-ID: <200408112338.QAA06014@dopey.hagenlocher.org> I use Python largely for a) immediate gratification (ie interactively) and b) as an embedded runtime interpreter. I've been stuck at version 1.52 of CPython for some time now, so my expectations may be a bit different than someone using a more modern version. Naturally, in starting to play with IronPython, I've used solely the IronPythonConsole program. In doing so, I've discovered that continuations largely seem broken. (By continuations, I mean the "..." that the interpreter prints to show that it wants more input.) Here are four separate cases: 1. >>> a = ' causes an infinite loop instead of returning an error 2. >>> a = ''' causes an infinite loop instead of giving a continuation 3. >>> a = ( causes an error instead of giving a continuation 4. >>> def a(): works correctly The first problem can be fixed in Tokenizer.next() at line 333 by adding " || ch == EOF" to the or clause. The second problem can be fixed by adding a new section to that same "if/else if/else if" construction. The new section reads } else if (isTriple && ch == EOF) { setEnd(); return TokenKind.EofToken; } This change works because of special-case code in IronPython.cs that catches exceptions, and, if the token that caused the problem is an EofToken, tells the DoInteractive loop to perform a continuation. Unfortunately, this also exposes a problem in DoInteractive(). Its logic for deciding whether or not a continuation is necessary is primitive and broken. At line 178, the logic says "If this is the first line we've read, then show a continuation unless there was a (non-EOF) exception or the line parsed correctly in its entirety. If we've already read more than one line, then show continuations until the user enters a blank line." What should probably change is that the Stmt class should support a virtual method to indicate whether or not a correct parse indicates the end of the statement, or whether the user should be prompted with continuations until a blank line is entered. This will distinguish statements of the first type from statements like "class" and "def", without having to explicity compare the statement type. It's been ages since I read the CPython source, so I wasn't able to find how this is handled there. I do seem to remember that, at least in 1.x versions, the parser had three different mode flags depending on whether or not it was being invoked interactively, on a single line or on a file. I'm not sure how to solve the third problem. The exception is thrown from Parser.finishTupleValue() when it doesn't get the expected right parenthesis. But I was expecting the nextToken() function to return a NewlineToken, and it didn't. I hope to look into this further in the next few days. Jim, do you expect to keep development private for now? -- Curt Hagenlocher curt at hagenlocher.org From grilo at netcabo.pt Fri Aug 13 00:46:09 2004 From: grilo at netcabo.pt (Joao Grilo) Date: Thu, 12 Aug 2004 23:46:09 +0100 Subject: [IronPython] Two problems Message-ID: <1092350769.79432.8.camel@grilo> Consider the following code: --------------------------------------------------------------- import System import System.Net import System.Net.Sockets def callbackFunction(socket): socket.Close() ## IronPython quirk: must cast "arrays" to lists, for them to work properly hostAddress = list(System.Net.Dns.Resolve(System.Net.Dns.GetHostName()).AddressList)[0] hostEndpoint = System.Net.IPEndPoint(hostAddress, 1800) socket = System.Net.Sockets.Socket(System.Net.Sockets.AddressFamily.InterNetwork, System.Net.Sockets.SocketType.Stream, System.Net.Sockets.ProtocolType.Tcp) socket.Bind(hostEndpoint) socket.Listen(1) print """Runs up to this point""" asyncAccept = socket.BeginAccept(System.AsyncCallback(callbackFunction), socket) print """This won't show at all, due to a core dump""" while asyncAccept.IsCompleted == False: print '.' ----------------------------------------------------------- There are 2 (two) problems to be noted: The Array held by "System.Net.Dns.Resolve(System.Net.Dns.GetHostName()).AddressList" can't be accessed normaly, and *must* be cast to a list() object prior to use it. 1. Shouldn't "Array" objects be automatically converted to lists? I can't get the callbackFunction function to be called at all. It simply core dumps as soon as that line is executed, and it returns this: %ironpython helloworldIronPython.py Runs up to this point ** ERROR **: file object.c: line 1595 (mono_runtime_invoke_array): assertion failed: (((gpointer*)params->vector) [i]) aborting... Abort trap (core dumped) If I run the C# (C Sharp) Server example code found in http://www.go-mono.com/docs/monodoc.ashx?link=T%3aSystem.Net.Sockets.Socket it works perfectly, but not mine. 2. Does my code contain a bug, or is IronPython not doing the right thing? Thank you for your attention. Sincerely yours Jo?o Grilo From curt at hagenlocher.org Fri Aug 13 02:14:09 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 12 Aug 2004 17:14:09 -0700 Subject: [IronPython] Two problems Message-ID: <200408130014.RAA08080@dopey.hagenlocher.org> Joao Grilo writes: > print """Runs up to this point""" > asyncAccept = socket.BeginAccept(System.AsyncCallback (callbackFunction), socket) > print """This won't show at all, due to a core dump""" For what it's worth, Microsoft's 1.1 CLR raises an exception at this point: bad args to this method -- Curt Hagenlocher curt at hagenlocher.org From danlash at gmail.com Fri Aug 13 04:45:14 2004 From: danlash at gmail.com (Dan Lash) Date: Thu, 12 Aug 2004 22:45:14 -0400 Subject: [IronPython] Two problems In-Reply-To: <200408130014.RAA08080@dopey.hagenlocher.org> References: <200408130014.RAA08080@dopey.hagenlocher.org> Message-ID: I think the problem you're having about the AsyncCallback constructor is similar to what I was describing in a previous list-email about some methods arguments' being not so clear in IronPython. As per the the casting to list: it looks like it must be cast explicitly to a list if you want to directly access the items in the list. But you can easily foreach through the "array" without a problem (if that is what you need to do, which I know it's not, but is worth mentioning): >>> import System >>> for address in System.Net.Dns.Resolve(System.Net.Dns.GetHostName()).AddressList: ... print address ... 192.168.1.100 -Dan On Thu, 12 Aug 2004 17:14:09 -0700, Curt Hagenlocher wrote: > Joao Grilo writes: > > > print """Runs up to this point""" > > asyncAccept = socket.BeginAccept(System.AsyncCallback > (callbackFunction), socket) > > print """This won't show at all, due to a core dump""" > > For what it's worth, Microsoft's 1.1 CLR raises an exception > at this point: > bad args to this method > > -- > Curt Hagenlocher > curt at hagenlocher.org > > > _______________________________________________ > 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 Aug 13 06:13:30 2004 From: jim at ironpython.com (Jim Hugunin) Date: Thu, 12 Aug 2004 21:13:30 -0700 Subject: [IronPython] Compilation to IL In-Reply-To: Message-ID: <20040813041335.921AD13D84F@sack.dreamhost.com> I'm sorry that I set expectations too high with my note about static compilation on the original ironpython web page. This is a feature that can and should work well, but today it is only barely there. I've updated the web page to make it clear that this feature isn't really working in 0.6. To see the state-of-the-art today, make a very simple Python script, like hello.py (with 'print "hello world" in it). Then run it by passing it to IronPythonConsole. After you run it, there should be a file "__main__.exe" in the appropriate directory. You should be able to run this file now as a stand-alone executable. You can even rename this file to "hello.exe" if you're feeling really fancy. -Jim -----Original Message----- From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Comron Sattari Sent: Wednesday, August 11, 2004 2:10 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Compilation to IL Hi, I recently downloaded IronPython and would like to compile my python programs directly to IL, yet I can't seem to figure out how. Am I missing something obvious? Please advise, Comron _______________________________________________ users-ironpython.com mailing list users-ironpython.com at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From qumel2k at yahoo.com.sg Fri Aug 13 06:15:17 2004 From: qumel2k at yahoo.com.sg (Firman Indra Buana) Date: 13 Aug 2004 11:15:17 +0700 Subject: [IronPython] Python .Net and Printer In-Reply-To: <20040813041335.921AD13D84F@sack.dreamhost.com> References: <20040813041335.921AD13D84F@sack.dreamhost.com> Message-ID: <1092370516.5560.46.camel@it.kweindo1.com> Is there any possibilities run python on net and get printer attached on local computer and print the document. From jim at ironpython.com Fri Aug 13 06:30:15 2004 From: jim at ironpython.com (Jim Hugunin) Date: Thu, 12 Aug 2004 21:30:15 -0700 Subject: [IronPython] Two problems In-Reply-To: <200408130014.RAA08080@dopey.hagenlocher.org> Message-ID: <20040813043024.D634F13D9DC@sack.dreamhost.com> Curt Hagenlocher wrote: > Joao Grilo writes: > > > print """Runs up to this point""" > > asyncAccept = socket.BeginAccept(System.AsyncCallback > (callbackFunction), socket) > > print """This won't show at all, due to a core dump""" > > For what it's worth, Microsoft's 1.1 CLR raises an exception > at this point: > bad args to this method This shows a bug in both IronPython and Mono. The fact that there is a mono bug is obvious. Managed code shouldn't be able to cause a core dump. The CLR 1.1 response is better. You should report this to the mono team if possible. The IronPython bug is that delegate constructors don't work right in this release. As Thane pointed out in an earlier email, simple delegates in IronPython are supposed to be created automatically, i.e. "socket.BeginAccept(callbackFunction, socket)'. The big bug in IronPython-0.6 is that even this won't work as the created delegate won't have the right signature. You can see Ops.GetDelegate if you're interested in the really weak code that's breaking for you. -Jim From jim at ironpython.com Fri Aug 13 06:30:15 2004 From: jim at ironpython.com (Jim Hugunin) Date: Thu, 12 Aug 2004 21:30:15 -0700 Subject: [IronPython] Method Arguments In-Reply-To: Message-ID: <20040813043026.1706B13D84F@sack.dreamhost.com> Dan Lash wrote: > Is there a good way to get the constructor and/or method arguments in > IronPython? I've been trying to do some simple 3D (DirectX9) examples, > and some of the constructors/methods are throwing exceptions. This can be really annoying. Unfortunately, there's no way to get this extra information in IronPython-0.6. I've been running into this problem myself as I play more with IronPython personally. Sorry I don't have a better answer, but I thought that you might want to know the current state of the art. If you're interested in looking at the source you should see ReflectedMembers.cs for the relevant code. -Jim From curt at hagenlocher.org Fri Aug 13 17:30:37 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 13 Aug 2004 08:30:37 -0700 Subject: [IronPython] Compilation to IL Message-ID: <200408131530.IAA09300@dopey.hagenlocher.org> "Jim Hugunin" writes: > To see the state-of-the-art today, make a very simple Python script, > like hello.py (with 'print "hello world" in it). Then run it by > passing it to IronPythonConsole. After you run it, there should be > a file "__main__.exe" in the appropriate directory. You should be > able to run this file now as a stand-alone executable. Even more interesting: if you have "hello.py" and "oil.py", and hello.py contains the statement "import oil", then when you pass hello.py to IronPythonConsole, you'll get not only "__main__.exe" but also "oil.exe". Running Reflector on these output files is not only a worthwhile exercise, it may also be an easier way to start learning how IronPython works than reading the actual source code. -- Curt Hagenlocher curt at hagenlocher.org From curt at hagenlocher.org Fri Aug 13 18:15:59 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 13 Aug 2004 09:15:59 -0700 Subject: [IronPython] Two problems Message-ID: <200408131615.JAA09385@dopey.hagenlocher.org> Joao Grilo writes: > def callbackFunction(socket): > socket.Close() By the way, this is the wrong signature for an async callback. It actually gets an IAsyncResult as an argument. You'd have to write something like def callbackFunction(ar): ar.AsyncState.Close() "Jim Hugunin" writes: > The big bug in IronPython-0.6 is that even this won't work as the > created delegate won't have the right signature. You can see > Ops.GetDelegate if you're interested in the really weak code > that's breaking for you. The immediate need could probably be fixed by adding the following function to PythonEventHandler: public void Handle(IAsyncResult ar) { Ops.Call(func, ar); } This wouldn't do much, though, for the next delegate that has a different signature. Ultimately, you probably have to reflect the delegate's type and build a class to return to CreateDelegate. -- Curt Hagenlocher curt at hagenlocher.org From nbastin at opnet.com Fri Aug 13 18:30:03 2004 From: nbastin at opnet.com (Nick Bastin) Date: Fri, 13 Aug 2004 12:30:03 -0400 Subject: [IronPython] Parse error on EOF? Message-ID: <076209E1-ED46-11D8-AAEA-000D932927FE@opnet.com> Has anyone seen this before: IronPython.Objects.PythonSyntaxError: unexpected token at /Users/nbastin/Desktop/bj.py:168 in <0x00278> IronPython.AST.Parser:parsePrimary () in <0x00028> IronPython.AST.Parser:parsePower () in <0x00198> IronPython.AST.Parser:parseFactor () in <0x0004c> IronPython.AST.Parser:parseExpr (int) in <0x00020> IronPython.AST.Parser:parseExpr () in <0x00040> IronPython.AST.Parser:parseComparison () in <0x000a8> IronPython.AST.Parser:parseNotTest () in <0x00028> IronPython.AST.Parser:parseAndTest () in <0x00050> IronPython.AST.Parser:parseTest () in <0x00090> IronPython.AST.Parser:parseTestList (bool&) in <0x00058> IronPython.AST.Parser:parseTestListAsExpr () in <0x00088> IronPython.AST.Parser:parseExprStmt () in <0x00370> IronPython.AST.Parser:parseSmallStmt () in <0x00048> IronPython.AST.Parser:parseSimpleStmt () in <0x00114> IronPython.AST.Parser:parseStmt () in <0x000bc> IronPython.AST.Parser:parseSuite () in <0x000bc> IronPython.AST.Parser:parseFuncDef () in <0x000f4> IronPython.AST.Parser:parseStmt () in <0x0009c> IronPython.AST.Parser:parseFileInput () in <0x00058> IronPython.Objects.Importer:LoadFromSource (string,string,IronPython.Objects.List) in <0x00160> IronPython.Objects.Importer:LoadFromPath (string,string,IronPython.Objects.List) in <0x00054> IronPython.Objects.Importer:LoadTop (string) in <0x0010c> IronPython.Objects.Importer:ImportOne (string,bool) in <0x00038> IronPython.Objects.module:Import (string,bool) in <0x00044> IronPython.Objects.Ops:Import (IronPython.Objects.module,string) in <0x00064> input_4:Run (IronPython.Objects.Frame) in <0x00260> IronPythonConsole.IronPython:DoInteractive () There's nothing special about this code, and I've tried encoding the file just about every which way, (ASCII, UTF-8, etc.) but I still get this error. I'm not entirely clear why is unexpected at this point, since it's the end of the file... -- Nick From danlash at gmail.com Fri Aug 13 19:31:05 2004 From: danlash at gmail.com (Dan Lash) Date: Fri, 13 Aug 2004 13:31:05 -0400 Subject: [IronPython] Parse error on EOF? In-Reply-To: <076209E1-ED46-11D8-AAEA-000D932927FE@opnet.com> References: <076209E1-ED46-11D8-AAEA-000D932927FE@opnet.com> Message-ID: What is the code that you're trying to run? Does it run in interactive mode? -Dan On Fri, 13 Aug 2004 12:30:03 -0400, Nick Bastin wrote: > Has anyone seen this before: > > IronPython.Objects.PythonSyntaxError: unexpected token at > /Users/nbastin/Desktop/bj.py:168 > in <0x00278> IronPython.AST.Parser:parsePrimary () > in <0x00028> IronPython.AST.Parser:parsePower () > in <0x00198> IronPython.AST.Parser:parseFactor () > in <0x0004c> IronPython.AST.Parser:parseExpr (int) > in <0x00020> IronPython.AST.Parser:parseExpr () > in <0x00040> IronPython.AST.Parser:parseComparison () > in <0x000a8> IronPython.AST.Parser:parseNotTest () > in <0x00028> IronPython.AST.Parser:parseAndTest () > in <0x00050> IronPython.AST.Parser:parseTest () > in <0x00090> IronPython.AST.Parser:parseTestList (bool&) > in <0x00058> IronPython.AST.Parser:parseTestListAsExpr () > in <0x00088> IronPython.AST.Parser:parseExprStmt () > in <0x00370> IronPython.AST.Parser:parseSmallStmt () > in <0x00048> IronPython.AST.Parser:parseSimpleStmt () > in <0x00114> IronPython.AST.Parser:parseStmt () > in <0x000bc> IronPython.AST.Parser:parseSuite () > in <0x000bc> IronPython.AST.Parser:parseFuncDef () > in <0x000f4> IronPython.AST.Parser:parseStmt () > in <0x0009c> IronPython.AST.Parser:parseFileInput () > in <0x00058> IronPython.Objects.Importer:LoadFromSource > (string,string,IronPython.Objects.List) > in <0x00160> IronPython.Objects.Importer:LoadFromPath > (string,string,IronPython.Objects.List) > in <0x00054> IronPython.Objects.Importer:LoadTop (string) > in <0x0010c> IronPython.Objects.Importer:ImportOne (string,bool) > in <0x00038> IronPython.Objects.module:Import (string,bool) > in <0x00044> IronPython.Objects.Ops:Import > (IronPython.Objects.module,string) > in <0x00064> input_4:Run (IronPython.Objects.Frame) > in <0x00260> IronPythonConsole.IronPython:DoInteractive () > > There's nothing special about this code, and I've tried encoding the > file just about every which way, (ASCII, UTF-8, etc.) but I still get > this error. I'm not entirely clear why is unexpected at this > point, since it's the end of the file... > > -- > Nick > > _______________________________________________ > users-ironpython.com mailing list > users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From nbastin at opnet.com Fri Aug 13 20:21:07 2004 From: nbastin at opnet.com (Nick Bastin) Date: Fri, 13 Aug 2004 14:21:07 -0400 Subject: [IronPython] Parse error on EOF? In-Reply-To: References: <076209E1-ED46-11D8-AAEA-000D932927FE@opnet.com> Message-ID: <8BAEAB8C-ED55-11D8-AAEA-000D932927FE@opnet.com> On Aug 13, 2004, at 1:31 PM, Dan Lash wrote: > What is the code that you're trying to run? Does it run in interactive > mode? It's 169 lines, so I didn't really try to type it into the console. It runs in C Python. -- Nick From andy at leonidae.org Fri Aug 13 23:05:24 2004 From: andy at leonidae.org (Andy Akins) Date: Fri, 13 Aug 2004 16:05:24 -0500 Subject: [IronPython] Newbie question... Message-ID: <7E697D68-ED6C-11D8-8D95-000A95DAF668@leonidae.org> If this is answered elsewhere (like an FAQ or Archive) point the direction and I'll go look it up:). I'm new to Mono/.NET/CLI. I've installed Mono and IronPython on my iBook - I can fire up the interpreter and do simple Python statements. Very cool! My question is - since I also have an installed copy of Python 2.3, is there a way to access the Standard Python Libraries? On the webpage it mentions that IronPython does not come with these, but you can install them yourself. How is this done? I would be interested in seeing if some of my older script will run under Mono... As an aside - I'm very excited about this project. I've wanted to tinker with Mono, but didn't really want to learn C# (nothing against it...just didn't feel the need to learn a new language). This may allow me to experiment and mess around with Mono and the .NET CLI. Andy Akins From nbastin at opnet.com Sat Aug 14 02:13:31 2004 From: nbastin at opnet.com (Nick Bastin) Date: Fri, 13 Aug 2004 20:13:31 -0400 Subject: [IronPython] Writing new modules Message-ID: I'd like to take a hack at implementing _random, but I am a bit confused as to how it works, so I have a few questions. Keep in mind that I'm a bit of a C# newbie, so some of the questions might have obvious answers to people who have more experience. I'll also note that I'm using Mono. It seems as if a module is available to the interpreter merely by existing in IronPython.Modules. Is this correct? There are a lot of extra names in each built-in module that don't exist in CPython, like 'Equals', 'GetHashCode', etc. What are these, and where do they come from? Where are doc strings supposed to be put? I notice that none of the modules seem to have them. sys.modules appears to be completely non-functional. Is this a matter of just not having an implementation, or is there a technical hurdle here? Similarly, simple errors generate long CLR stacks instead of the normal python error messages. Is this just unimplemented, or is it somewhat complicated to get right? -- Nick From curt at hagenlocher.org Sat Aug 14 02:40:40 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 13 Aug 2004 17:40:40 -0700 Subject: [IronPython] Writing new modules Message-ID: <200408140040.RAA10129@dopey.hagenlocher.org> Nick Bastin writes: > There are a lot of extra names in each built-in module that don't > exist in CPython, like 'Equals', 'GetHashCode', etc. What are > these, and where do they come from? These are members of the Object class that are supposed to be overridden by derived classes. It's a CLR thing. > Where are doc strings supposed to be put? I notice that none of the > modules seem to have them. This doesn't look like it's been worked out yet. It looks like an ideal place to create a custom attribute. -- Curt Hagenlocher curt at hagenlocher.org From ender at objectrealms.net Sat Aug 14 08:04:39 2004 From: ender at objectrealms.net (ender) Date: Sat, 14 Aug 2004 01:04:39 -0500 Subject: [IronPython] Newbie question... In-Reply-To: <7E697D68-ED6C-11D8-8D95-000A95DAF668@leonidae.org> References: <7E697D68-ED6C-11D8-8D95-000A95DAF668@leonidae.org> Message-ID: On Aug 13, 2004, at 4:05 PM, Andy Akins wrote: > If this is answered elsewhere (like an FAQ or Archive) point the > direction and I'll go look it up:). I'm new to Mono/.NET/CLI. > > I've installed Mono and IronPython on my iBook - I can fire up the > interpreter and do simple Python statements. Very cool! My question is > - since I also have an installed copy of Python 2.3, is there a way to > access the Standard Python Libraries? On the webpage it mentions that > IronPython does not come with these, but you can install them > yourself. How is this done? you would need to copy them from a cpython installation/source, and you wouldn't be able to use any of the ones coded in c, or those that are dependent on ones coded in c... unless there are ironpython replacements for those modules coded in c. a nice list of modules written in c, is here. http://codespeak.net/pypy/index.cgi?doc/cmodules.html if your interest is just using .net from cpython, another project ( http://zope.org/Members/Brian/PythonNet ) might be more suitable. while, it doesn't run so well under mono (though it will compile) due to various bugs in mono, its works well with MS .NET implementation and i have some systems running it in production. > > I would be interested in seeing if some of my older script will run > under Mono... > > As an aside - I'm very excited about this project. I've wanted to > tinker with Mono, but didn't really want to learn C# (nothing against > it...just didn't feel the need to learn a new language). This may > allow me to experiment and mess around with Mono and the .NET CLI. > > Andy Akins From roman.yakovenko at actimize.com Sun Aug 15 07:23:51 2004 From: roman.yakovenko at actimize.com (Roman Yakovenko) Date: Sun, 15 Aug 2004 08:23:51 +0300 Subject: [IronPython] class member access bug + the way to fix Message-ID: <2D89F6C4A80FA547BF5D5B8FDDD045232539A9@exchange.adrembi.com> reproducible case: class Buggy: class_member = 'find bug' print Buggy.class_member patch: 1. IronPython.Objects.ReflectedType.GetAttr description: you don't find member within slot just ask object whether it has such member or not. 2.IronPython.Objects.OldClass There is a need to override GetAttr function. This function should call to Lookup function P.S. Code was not post because Jim could not accept any patches right now. He is working hard to solve this problem. Anyway if someone needs code - turn to me and I will send patch to you Roman. From roman.yakovenko at actimize.com Sun Aug 15 07:28:38 2004 From: roman.yakovenko at actimize.com (Roman Yakovenko) Date: Sun, 15 Aug 2004 08:28:38 +0300 Subject: [IronPython] error in parser module Message-ID: <2D89F6C4A80FA547BF5D5B8FDDD04523060CB9@exchange.adrembi.com> reproducible code: if __name__ == '__main__': print 'hello world' hint: don't insert whitespace or new lines after 'hello world', file should consist from 2 lines only patch: Fix should be done in IronPython.AST.Parser.parseSuite. The condition of while shoud be changed to: read until EOF extracted P.S. Code was not post because Jim could not accept any patches right now. He is working hard to solve this problem. Anyway if someone needs code - turn to me and I will send patch to you Roman. From hal9000 at hypermetrics.com Sun Aug 15 20:00:06 2004 From: hal9000 at hypermetrics.com (Hal Fulton) Date: Sun, 15 Aug 2004 13:00:06 -0500 Subject: [IronPython] Two questions... Message-ID: <411FA4A6.1070500@hypermetrics.com> I've been playing with IronPython for a few hours, and I have a couple of questions: 1. I'm using Mono on Linux. It's unclear to me how to invoke IP... is it like this? mono __main__.exe scriptname.py When I try that, it complains about winforms or some such. 2. I'm trying to grasp the overall concept here. Is there a good reason this is all written in C#? By that, I mean: Wouldn't it be possible to change just the code generation pieces of the Python interpreter/compiler? It seems to me that "a compiler running on mono" is not necessary if we want "a compiler that generates code that runs on mono." Am I missing something? Thanks, Hal Fulton From pdrayton at microsoft.com Mon Aug 16 04:56:19 2004 From: pdrayton at microsoft.com (Peter Drayton) Date: Sun, 15 Aug 2004 19:56:19 -0700 Subject: [IronPython] Two questions... Message-ID: <8FE51C5062B0B94DAC4EE6E1F0F1F6820326426F@RED-MSG-52.redmond.corp.microsoft.com> 1. For .NET on Windows, one uses IronPythonConsole.exe scriptname.py to execute a script. In case you're curious, __main__.exe is an artifact of the static compilation feature that is only partially implemented for now. I've not tried on Mono, but since IronPythonConsole.exe is itself a managed app, you might try "mono IronPythonConsole.exe scriptname.py". 2. You are correct that compilers /for/ .NET do not have to be written /in/ .NET. Examples of this include the MS C#, VB & MC++ compilers - all written in unmanaged code. However, for languages like Python and JavaScript with dynamic features such as eval, one needs access to a compiler at runtime. While this could be done with an unmanaged compiler linked in via IJW, P/Invoke, etc. it's often easier (and sometime better) to have the compiler itself be managed code. IronPython is one example of this, another is the JScript.NET compiler included in Rotor. --Peter -----Original Message----- From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Hal Fulton Sent: Sunday, August 15, 2004 11:00 AM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Two questions... I've been playing with IronPython for a few hours, and I have a couple of questions: 1. I'm using Mono on Linux. It's unclear to me how to invoke IP... is it like this? mono __main__.exe scriptname.py When I try that, it complains about winforms or some such. 2. I'm trying to grasp the overall concept here. Is there a good reason this is all written in C#? By that, I mean: Wouldn't it be possible to change just the code generation pieces of the Python interpreter/compiler? It seems to me that "a compiler running on mono" is not necessary if we want "a compiler that generates code that runs on mono." Am I missing something? Thanks, Hal Fulton _______________________________________________ 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 Aug 16 19:14:20 2004 From: jim at ironpython.com (Jim Hugunin) Date: Mon, 16 Aug 2004 10:14:20 -0700 Subject: [IronPython] Writing new modules In-Reply-To: Message-ID: <20040816171424.14CC613D87E@sack.dreamhost.com> Nick Bastin wrote: > I'd like to take a hack at implementing _random, but I am a bit > confused as to how it works, so I have a few questions. Keep in mind You should look at the existing modules such as math and re for some examples of how this can be done. I believe this is a VERY simple process. > It seems as if a module is available to the interpreter merely by > existing in IronPython.Modules. Is this correct? This is mostly correct; however, the module also needs to be visible to the interpreter, which for now probably means building it as part of IronPython.dll. This is a configuration issue that will be resolved moving forward. > sys.modules appears to be completely non-functional. Is this a matter > of just not having an implementation, or is there a technical hurdle > here? I believe that sys.modules is only being used today for imports from Python source code to avoid the circular import danger. It's probably completely non-functional for "builtin" modules. > Similarly, simple errors generate long CLR stacks instead of the normal > python error messages. Is this just unimplemented, or is it somewhat > complicated to get right? This mainly reflects the current stage of development. Those long stack traces do include all of your Python stack trace information PLUS all of the implementation details of the C# code. Right now it can be helpful to have all of that information to understand when something goes wrong. As things get more stable, this will have to be revisited and some efforts made to simplify these stack traces. There's an issue here as to how much of the CLR stack trace to elide. Consider this silly program: >>> def cmp(a,b): raise Exception() >>> [1,2,3].sort(cmp) When I run this with CPython, I see this: Traceback (most recent call last): File "", line 1, in -toplevel- [1,2,3].sort(cmp) File "", line 1, in cmp def cmp(a,b): raise Exception() Exception This can confusing because it doesn't show the internal C code that is calling the cmp function. The 'sort' method doesn't appear anywhere in the stack trace. IronPython's result is currently much too long, but I think that it's a good thing that it includes the sort method in its stack trace. We want to be sure not to lose that benefit when shortening the result for readability. -Jim From jim at ironpython.com Mon Aug 16 19:14:20 2004 From: jim at ironpython.com (Jim Hugunin) Date: Mon, 16 Aug 2004 10:14:20 -0700 Subject: [IronPython] Writing new modules In-Reply-To: <200408140040.RAA10129@dopey.hagenlocher.org> Message-ID: <20040816171424.8315213D91D@sack.dreamhost.com> Curt Hagenlocher wrote: > Nick Bastin writes: > > > There are a lot of extra names in each built-in module that don't > > exist in CPython, like 'Equals', 'GetHashCode', etc. What are > > these, and where do they come from? > > These are members of the Object class that are supposed to be > overridden by derived classes. It's a CLR thing. There's an interesting question whether or not these sorts of CLR things should be exposed to Python programmers. These particular methods will disappear when IronPython moves to the CLR-2.0 (Whidbey) release. For that release, C# includes a new feature called static classes that let's you declare a class has only static members. In this case, none of these weird methods from object would be inherited. A more interesting question is what to do about standard Python objects. Here are a couple of things that you can write in IronPython, but that will fail in CPython: >>> l = [1,2] >>> l.Add(3) 2 >>> l [1, 2, 3] >>> l.GetObjectArray() System.Object[](1, 2, 3) >>> l.Clear() >>> l [] This is using the fact that list objects also implement the standard CLR IList interface. This is great for interoperating with other CLR languages (C#, VB, ...); however, it is incompatible with CPython. I've talked about this briefly with Guido, and he's not very happy about adding methods to the standard Python objects. This is a recipe for incompatible code. On the other hand, these methods are very valuable to C#/VB programmers who already know how lists work in their world and who are just getting started in Python. Guido suggested a per-module flag much like the way that floor vs. true division is selected in the current CPython could be used to control whether or not non-Python methods were exposed on standard Python types. I always hate adding flags like this, but it might be the best compromise between the two positions. > > Where are doc strings supposed to be put? I notice that none of the > > modules seem to have them. > > This doesn't look like it's been worked out yet. It looks like > an ideal place to create a custom attribute. I agree that doc strings would be well captured in a custom attribute. However, I'd like to see a solution that is as compatible with C# and other CLR languages as possible. In that case, it would be great to capture the doc information in the XML doc comments that are standard in that world. I don't have any ideas yet for how to expose that kind of doc information dynamically as the __doc__ attribute. -Jim From nbastin at opnet.com Mon Aug 16 19:47:07 2004 From: nbastin at opnet.com (Nick Bastin) Date: Mon, 16 Aug 2004 13:47:07 -0400 Subject: [IronPython] Writing new modules In-Reply-To: <20040816171424.14CC613D87E@sack.dreamhost.com> References: <20040816171424.14CC613D87E@sack.dreamhost.com> Message-ID: <4AF54872-EFAC-11D8-B0C5-000D932927FE@opnet.com> On Aug 16, 2004, at 1:14 PM, Jim Hugunin wrote: > Nick Bastin wrote: >> I'd like to take a hack at implementing _random, but I am a bit >> confused as to how it works, so I have a few questions. Keep in mind > > You should look at the existing modules such as math and re for some > examples of how this can be done. I believe this is a VERY simple > process. Ok, just making sure it was as simple as it appeared.. :-) >> It seems as if a module is available to the interpreter merely by >> existing in IronPython.Modules. Is this correct? > > This is mostly correct; however, the module also needs to be visible > to the > interpreter, which for now probably means building it as part of > IronPython.dll. This is a configuration issue that will be resolved > moving > forward. That's fine, since that's technically how we build CPython as well. This actually generates another question - I don't have VC.NET, but rather am using Mono. Is there any build system set up for non-VC builds, or do I have to make one? >> sys.modules appears to be completely non-functional. Is this a matter >> of just not having an implementation, or is there a technical hurdle >> here? > > I believe that sys.modules is only being used today for imports from > Python > source code to avoid the circular import danger. It's probably > completely > non-functional for "builtin" modules. It's functional for built-in modules, although hopefully built-in modules don't create the problem that it solves (C modules could still introduce a circular dependency, and it does solve that, but doing it in the standard distribution would be Bad(tm)). It also allows for some rather nifty introspection by running programs to determine their environment (and allows you to solve the 'Reload everything that's been loaded since I started' problem). -- Nick From nbastin at opnet.com Mon Aug 16 19:50:26 2004 From: nbastin at opnet.com (Nick Bastin) Date: Mon, 16 Aug 2004 13:50:26 -0400 Subject: [IronPython] Writing new modules In-Reply-To: <20040816171424.8315213D91D@sack.dreamhost.com> References: <20040816171424.8315213D91D@sack.dreamhost.com> Message-ID: On Aug 16, 2004, at 1:14 PM, Jim Hugunin wrote: > Curt Hagenlocher wrote: > >> Nick Bastin writes: >> >>> There are a lot of extra names in each built-in module that don't >>> exist in CPython, like 'Equals', 'GetHashCode', etc. What are >>> these, and where do they come from? >> >> These are members of the Object class that are supposed to be >> overridden by derived classes. It's a CLR thing. > > There's an interesting question whether or not these sorts of CLR > things > should be exposed to Python programmers. These particular methods will FWIW, I think they should be exposed to Python programmers, but not by default, because it introduces a compatibility problem. Really I would suggest something like: from __DOTNET__ import Interfaces This would of course fail on CPython, but at import time instead of runtime, and the developer would be making it clear that you needed to run in the CLR. This could be implemented in the compiler (like __future__), or some sufficiently clever mixin on the built-in types, but I don't know if you can do that in C#. -- Nick From Clive_Tong at scientia.com Fri Aug 13 17:27:50 2004 From: Clive_Tong at scientia.com (Clive Tong) Date: Fri, 13 Aug 2004 15:27:50 +0000 Subject: [IronPython] Problems defining new classes Message-ID: I've just started using IronPython, but have problems getting a class deifntion to work: class foo: pass Gives the error System.Reflection.TargetException: Non-static field requires a target. at System.Reflection.RuntimeFieldInfo.InternalGetValue(Object obj, Boolean requiresAccessCheck) at System.Reflection.RuntimeFieldInfo.GetValue(Object obj) at IronPython.Objects.module.__getattribute__(String name) at IronPython.Objects.ModuleDictionary.get_Item(Object key) at IronPython.Objects.Frame.GetGlobal(String name) at input_0.Run(Frame frame) at IronPythonConsole.IronPython.DoInteractive() The fix seems to be changing the definition of __getattribute__ in objects\module.cs from return fi.GetValue(null); to return fi.GetValue(this); Is this the correct fix ? From fseoane at wanadoo.es Sun Aug 15 20:16:04 2004 From: fseoane at wanadoo.es (Fabian) Date: Sun, 15 Aug 2004 20:16:04 +0200 Subject: [IronPython] cvs Message-ID: <1092593764.1170.2.camel@Eox> Hi!. I was just wondering if there is a cvs (or svn or something like that) for ironpython so that i could get the latest release. Thanks From garth at deadlybloodyserious.com Tue Aug 17 09:36:17 2004 From: garth at deadlybloodyserious.com (Garth T Kidd) Date: Tue, 17 Aug 2004 17:36:17 +1000 Subject: [IronPython] Writing new modules In-Reply-To: <20040816171424.14CC613D87E@sack.dreamhost.com> Message-ID: <20040817073620.A78165DC69@mail03.your-site.com> > Guido suggested a per-module flag much like the way that > floor vs. true division is selected in the current CPython > could be used to control whether or not non-Python methods > were exposed on standard Python types. > > I always hate adding flags like this, but it might be the > best compromise between the two positions. There's a real tension between IronPython as a Python-syntax language relying on the common runtime, and IronPython as something that lets you run arbitary Python code under dotNet. Depending on the project, I might want either or both of those behaviours, and there's a certain chunk of the Python standard library (string methods come to mind) I want even in a "pure" dotNet project. The warnings framework might help here: expose list.Add, but detect it being used and warn people that their code won't work in cPython or Jython. If they don't mind the non-portability, they can easily filter out the warnings. If they do, at least their code will work until they remember the Pythonic method. Some diehard dotNet shops might potentially insist that there be a corresponding way of having warnings issued on calls to list.append ("I don't mind you using that weird-ass language, but at least use the methods the other blokes understand!"), but for the time being I'd a) pray that doesn't become a real issue, and b) plan on leaving those warnings disabled by default. If there must be a mode flag, I'd prefer the default to be exposing both sets of methods so that my code works whichever list expansion method I happen to type at the time. Regards, Garth. From nbastin at opnet.com Tue Aug 17 09:45:51 2004 From: nbastin at opnet.com (Nick Bastin) Date: Tue, 17 Aug 2004 03:45:51 -0400 Subject: [IronPython] Writing new modules In-Reply-To: <20040817073620.A78165DC69@mail03.your-site.com> References: <20040817073620.A78165DC69@mail03.your-site.com> Message-ID: <7648D800-F021-11D8-B0C5-000D932927FE@opnet.com> On Aug 17, 2004, at 3:36 AM, Garth T Kidd wrote: > There's a real tension between IronPython as a Python-syntax language > relying on the common runtime, and IronPython as something that lets > you run > arbitary Python code under dotNet. Depending on the project, I might > want > either or both of those behaviours, and there's a certain chunk of the > Python standard library (string methods come to mind) I want even in a > "pure" dotNet project. > > The warnings framework might help here: expose list.Add, but detect it > being > used and warn people that their code won't work in cPython or Jython. > If > they don't mind the non-portability, they can easily filter out the > warnings. If they do, at least their code will work until they > remember the > Pythonic method. The performance hit in this situation would be unacceptable in many circumstances. You don't want your program filtering out warnings as a normal course of operations, especially when the warnings are issued a lot (which they presumably could be). > Some diehard dotNet shops might potentially insist that there be a > corresponding way of having warnings issued on calls to list.append ("I > don't mind you using that weird-ass language, but at least use the > methods > the other blokes understand!"), but for the time being I'd a) pray that > doesn't become a real issue, and b) plan on leaving those warnings > disabled > by default. I'd like to have Python be a first-class CLR language, but I'm not willing to fundamentally change the core language to get that. If dotNet people don't like list.append(), they can use some other language. That's the whole point of the CLR. -- Nick From kfarmer at thuban.org Tue Aug 17 11:28:06 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 17 Aug 2004 02:28:06 -0700 Subject: [IronPython] Writing new modules Message-ID: Has anyone else played with J# at all? The approach taken there is to define the Java versions of types, separate from the CLR versions. That gives J# access both to the CLR string and the Java string, as well as the numeric types of each, etc. One downside to the current implementation is that there weren't (to my knowledge) any implicit cast operators defined. This commits the sin (IMHO) of exposing the source language to the consumer. I think that sort of thing should be avoided. One way would be to create a thin marshalling layer that allows the IL/bytecode to internally use whatever, if necessary (a smart compiler could detect if the type could be replaced outright), while exposing only the CLR or Python type expected by the target environment. There would be some overhead, but I don't think it'd be terribly bad. After all, equivalent operations exist, more or less, in each environment. It's the value that's of interest in the end. This would allow export to the CPython world as a compiled module, though the source could still be tainted with CLR-isms. A transformation tool, however, could export CPython source that included the marshalling layer explicitly, perhaps referencing a (future) standard Python module. From kfarmer at thuban.org Tue Aug 17 22:33:15 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 17 Aug 2004 13:33:15 -0700 Subject: [IronPython] Writing new modules Message-ID: Of course, I mean this to describe a similar situation to the Managed C++ compiler -- it can take the same source, and target either the managed or unmanaged world. IronPython could take source and target either CLR or CPython, with marshalling performed as needed. If IronPython could easily wrap managed assemblies, that would be a good trick as well, and solve the problem of dealing with non-trivial types. ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Keith J. Farmer Sent: Tue 8/17/2004 2:28 AM be to create a thin marshalling layer that allows the IL/bytecode to internally use whatever, if necessary (a smart compiler could detect if the type could be replaced outright), while exposing only the CLR or Python type expected by the target environment. From garth at deadlybloodyserious.com Tue Aug 17 22:54:13 2004 From: garth at deadlybloodyserious.com (Garth T Kidd) Date: Wed, 18 Aug 2004 06:54:13 +1000 Subject: [IronPython] Writing new modules In-Reply-To: <7648D800-F021-11D8-B0C5-000D932927FE@opnet.com> Message-ID: <20040817205413.8C3E05E77D@mail04.your-site.com> If we don't expose .Add, won't we have trouble passing lists to other .Net modules that expect something listy from their point of view? Regards, Garth. From thane at magna-capital.com Wed Aug 18 01:36:28 2004 From: thane at magna-capital.com (Thane) Date: Tue, 17 Aug 2004 16:36:28 -0700 Subject: [IronPython] Fun with the CLR debugger! Message-ID: One of the things I love about IronPython is the ability to use off-the-shelf CLR debugging tools on Python source code. See http://ironpython.com/misc/CLR-Python-Debugger-Thane.jpg Here's how to replicate this: 1. Find the CLR debugger (MS had stashed this away for some reason). On my system it's in: "C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\GuiDebug\DbgCLR.exe" 2. Select "Program to Debug." from the "Debug" menu item. 3. Type "IronPythonConsole.exe" in the "Program" field (you can browse for it). 4. Input your IronPython directory in the "Working directory" field. Note: this could be the directory of your source code, but I'm keeping everything in the same directory so that it doesn't interfere with CPython. Otherwise just make sure that your environment variables allow IronPythonConsole.exe to be seen from this directory. 5. Enter the Python source filename in the "Arguments" field. Now you can add break points, step-through, etc. Enjoy! --Thane Thane Plummer, Ph.D. CEO Magna Capital, LLC (520) 760-4957 (520) 405-2277 (cell) thane at magna-capital.com www.magna-capital.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Thu Aug 19 10:25:48 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Thu, 19 Aug 2004 01:25:48 -0700 Subject: [IronPython] interpreter component Message-ID: Random idea -- Anybody manage to wrap an IronPython interpreter into a Forms control yet a la PyCrust? Maybe a component with an in/out/error, start/pause/reset, and an exposed memory object that could be hooked into a textbox or the like? It'd be nice to pair up the interpreter's response with the input that triggered it, but especially in a multithreaded case, asynchronous responses not necessarily tied to an input could occur. I imagine this would entail a parallel set of streams and a consumer that would route tagged output. That of course would require that the interpreter generate and keep track of an input tag during processing, and cc the parallel streams. A flagged behavior, I think. Jim -- actually, if MS promoted an interface for interpreters, it could be a big win for plug-in scripting, you think? They already have similar things going on with C#, VB, and CodeDom. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thane at magna-capital.com Thu Aug 19 16:47:23 2004 From: thane at magna-capital.com (Thane) Date: Thu, 19 Aug 2004 07:47:23 -0700 Subject: [IronPython] interpreter component In-Reply-To: Message-ID: I have one for PythonNet written in Python that I've been trying to port to IronPython (see attached screenshot). You may also note that this has a rudimentary .NET backend for matplotlib (http://matplotlib.sourceforge.net ). The port has been difficult, due to the current limitations of IronPython. After doing such an interface for Root, and then Python (both in MFC), it is clear that the optimal solution is to write a .NET control in C# that is _directly_ supported by IronPython. The main problem with the writers of scripting languages is that they treat them like a compiler, and only consider stdin, stdout, and stderr streams. All input/output is written to a CONSOLE. If you know anything about the Windows console you quickly realize how disastrous this is (single threaded, non-standard i/o streams from GUI, not a Windows object, etc.). Guido did a good job of addressing this in Python by allowing these to be redirected (sys.stdin = myfile), but it's clearly not enough. I've heard rumors of a new MS Console object in the Whidbey release. I just hope they do it right. Jim - (since everyone seems to view as our "Python ambassador to Microsoft"), perhaps you could address this in IronPython by simply having an I/O class that initially just exposes the Console ReadLine and WriteLine methods. Then, people who use IronPython to write an app could have a C# class that inherits your I/O class, and they can do whatever they want with the I/O methods. There also needs to be a mechanism to optionally get rid of the Console screen, similar to PythonW.exe. --Thane _____ 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: Thursday, August 19, 2004 1:26 AM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] interpreter component Random idea -- Anybody manage to wrap an IronPython interpreter into a Forms control yet a la PyCrust? Maybe a component with an in/out/error, start/pause/reset, and an exposed memory object that could be hooked into a textbox or the like? It'd be nice to pair up the interpreter's response with the input that triggered it, but especially in a multithreaded case, asynchronous responses not necessarily tied to an input could occur. I imagine this would entail a parallel set of streams and a consumer that would route tagged output. That of course would require that the interpreter generate and keep track of an input tag during processing, and cc the parallel streams. A flagged behavior, I think. Jim -- actually, if MS promoted an interface for interpreters, it could be a big win for plug-in scripting, you think? They already have similar things going on with C#, VB, and CodeDom. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: KtLab_Screenshot_small.jpg Type: image/jpeg Size: 17392 bytes Desc: not available URL: From kfarmer at thuban.org Thu Aug 19 20:04:42 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Thu, 19 Aug 2004 11:04:42 -0700 Subject: [IronPython] interpreter component Message-ID: Everything I've been seeing points to API being exposed to change properties of the console window, not the ability to host an interactive console. Google provides a bunch of links. Did some more thought: Streams -- StandardInput, StandardOutput, StandardError, .. (Trace, Debug, ...) Events -- StandardInputEvent, StandardOutputEvent, StandardErrorEvent, .. (Trace, Debug, ...) Methods -- GetNextEventId(), AsynchronousExecute(id, script) Properties -- InterpreterState Regular input would go in via stdin. The interpreter would then fire a StandardInputEvent with this information, including an identifier that could be correllated to output and error events. >>> if 1=1: [stdout, stdin] ... print "foo" [stdout, stdin] ... print "bar" [stdout, stdin] .. maybe some events for continued input [StandardInputEvent #1] foo [stdout, StandardOutputEvent #1] bar [stdout, StandardOutputEvent #1] >>> [stdout] ________________________________ From: Thane [mailto:thane at magna-capital.com] Sent: 19 Aug 2004 07:47 Python by allowing these to be redirected (sys.stdin = myfile), but it's clearly not enough. I've heard rumors of a new MS Console object in the Whidbey release... I just hope they do it right. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lupus at ximian.com Thu Aug 19 20:29:54 2004 From: lupus at ximian.com (Paolo Molaro) Date: Thu, 19 Aug 2004 20:29:54 +0200 Subject: [IronPython] Two problems In-Reply-To: <20040813043024.D634F13D9DC@sack.dreamhost.com> References: <200408130014.RAA08080@dopey.hagenlocher.org> <20040813043024.D634F13D9DC@sack.dreamhost.com> Message-ID: <20040819182954.GI24652@debian.org> On 08/12/04 Jim Hugunin wrote: > > For what it's worth, Microsoft's 1.1 CLR raises an exception > > at this point: > > bad args to this method > > This shows a bug in both IronPython and Mono. The fact that there is a mono > bug is obvious. Managed code shouldn't be able to cause a core dump. The > CLR 1.1 response is better. You should report this to the mono team if > possible. This bug was fixed in mono cvs in July: http://bugzilla.ximian.com/show_bug.cgi?id=62123 The other bug I think is IronPython not selecting the right method to execute based on the passed arguments when there are overloads. I guess people may be also interested in performance progresses: current mono from cvs is about 50% slower than CPython on parrotbench (excluding the infamous b5 bench): used to be 2x slower as reported in Jim's slides. b5 times improved, too: we are now 10 times slower instead of 70x (this is all due to exception handling so relatively unimportant in the real world). Expect more improvements in the future as well. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From curt at hagenlocher.org Mon Aug 23 22:22:41 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 23 Aug 2004 13:22:41 -0700 Subject: [IronPython] Two problems Message-ID: <200408232022.NAA00658@dopey.hagenlocher.org> I previously wrote: > "Jim Hugunin" writes: > >> The big bug in IronPython-0.6 is that even this won't work as the >> created delegate won't have the right signature. You can see >> Ops.GetDelegate if you're interested in the really weak code >> that's breaking for you. > > The immediate need could probably be fixed by adding the following > function to PythonEventHandler: > [snip] I've created a more sophisticated delegate wrapper now. You can download the additional code from http://www.pureevil.org/software/DelegateMaker.cs.txt You would then need to change ReflectedEvent.__iadd__ to read handler = DelegateMaker.Make(info.EventHandlerType, func); and Ops.GetDelegate to read return DelegateMaker.Make(delegateType, o); -- Curt Hagenlocher curt at hagenlocher.org From edd at usefulinc.com Tue Aug 24 15:39:27 2004 From: edd at usefulinc.com (Edd Dumbill) Date: Tue, 24 Aug 2004 14:39:27 +0100 Subject: [IronPython] can't convert 6 to System.UInt32 Message-ID: <1093354767.18927.58.camel@saag> Hi, I'm starting to port all the examples from "Mono: A Developer's Notebook" to IronPython. The attached example gives the following error under Mono. I'm guessing that what's missing is just a few lines from ConvertTo() Unhandled Exception: System.Exception: can't convert 6 to System.UInt32 in <0x000dc> IronPython.Objects.Ops:ConvertTo (object,System.Type) in <0x000d3> IronPython.Objects.ReflectedProperty:DoSet (object,object) in <0x00091> IronPython.Objects.ReflectedProperty:__set__ (object,object) in <0x000ba> IronPython.Objects.Ops:SetDescriptor (object,object,object) in <0x0006e> IronPython.Objects.ReflectedType:SetAttr (object,string,object) in <0x000e1> IronPython.Objects.Ops:SetAttr (object,string,object) in <0x00010> IronPython.Objects.Ops:SetAttrStackHelper (object,object,string) in <0x000a8> __main__:SetUpGui$f0 () in <0x00061> (wrapper delegate-invoke) System.MulticastDelegate:invoke_object ()in <0x00011> IronPython.Objects.Function0:Call () in <0x0004d> IronPython.Objects.Ops:Call (object) in <0x0024f> __main__:init () in <0x002a0> IronPythonConsole.IronPython:DoFile (string[]) in <0x0005d> IronPythonConsole.IronPython:Main (string[]) -- Edd Dumbill, Editor-at-Large, O'Reilly Network More from me on my weblog -- http://usefulinc.com/edd/blog Mono book -- http://usefulinc.com/edd/books/mono-notebook -------------- next part -------------- A non-text attachment was scrubbed... Name: main.py Type: application/x-python Size: 714 bytes Desc: not available URL: From edd at usefulinc.com Tue Aug 24 16:19:34 2004 From: edd at usefulinc.com (Edd Dumbill) Date: Tue, 24 Aug 2004 15:19:34 +0100 Subject: [IronPython] Writing new modules In-Reply-To: <4AF54872-EFAC-11D8-B0C5-000D932927FE@opnet.com> References: <20040816171424.14CC613D87E@sack.dreamhost.com> <4AF54872-EFAC-11D8-B0C5-000D932927FE@opnet.com> Message-ID: <1093357174.18927.61.camel@saag> On Mon, 2004-08-16 at 13:47 -0400, Nick Bastin wrote: > > > That's fine, since that's technically how we build CPython as well. > This actually generates another question - I don't have VC.NET, but > rather am using Mono. Is there any build system set up for non-VC > builds, or do I have to make one? use prj2make# to convert the VC project, then tweak the Makefile http://forge.novell.com/modules/xfmod/project/?prj2make-sharp I attach a Makefile I made in this way for building IronPython.dll -- it assumes you have the binary .dll for IronMath and the SystemUtil.dll already built. It shouldn't be hard to make the rest of the Makefiles in similar way. -- Edd -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: text/x-makefile Size: 2462 bytes Desc: not available URL: From edd at usefulinc.com Tue Aug 24 16:28:56 2004 From: edd at usefulinc.com (Edd Dumbill) Date: Tue, 24 Aug 2004 15:28:56 +0100 Subject: [IronPython] can't convert 6 to System.UInt32 In-Reply-To: <1093354767.18927.58.camel@saag> References: <1093354767.18927.58.camel@saag> Message-ID: <1093357736.18927.64.camel@saag> On Tue, 2004-08-24 at 14:39 +0100, Edd Dumbill wrote: > I'm guessing that what's missing is just a few lines from > ConvertTo() Attached is a silly little patch I made to make System.Single and System.UInt32 work, both of which I needed for my little Gtk# demo. It's probably not the Right Way to do things, but it's let me get a bit further. -- Edd -------------- next part -------------- A non-text attachment was scrubbed... Name: ironpy.diff Type: text/x-patch Size: 1462 bytes Desc: not available URL: From brian at sweetapp.com Tue Aug 24 16:33:22 2004 From: brian at sweetapp.com (Brian Quinlan) Date: Tue, 24 Aug 2004 16:33:22 +0200 Subject: [IronPython] Keyword arguments Message-ID: <412B51B2.1040109@sweetapp.com> Currently it appears, at least for constructors, that IronPython is transforming keyword arguments into attribute assignments e.g. >>> Rectangle(2,3,2,3) {X=2,Y=3,Width=2,Height=3} >>> Rectangle(2,3,2,3, Height=20, Location=Point(5, 5), X=10) {X=10,Y=5,Width=2,Height=20} You can see that for the last rectangle ctor, IronPython did the equivalent of this C# code: r = new Rectangle(2, 3, 2, 3); r.Height = 20; r.Location = new Point(5, 5); r.X = 10; I would argue strongly that this is a bad idea; keyword arguments should have the same semantics as they do in CPython. The most obvious reason that I can think of is that keyword arguments, used as in CPython, can clarify the meaning of various arguments. Compatibility is also an issue as is 3rd party tools support. I actually noticed this problem while writing a script to add .NET Framework intellisense support to ActiveState's Python IDE. If anyone is interested in either the source or the datafile, please let me know. Cheers, Brian From edd at usefulinc.com Tue Aug 24 16:52:59 2004 From: edd at usefulinc.com (Edd Dumbill) Date: Tue, 24 Aug 2004 15:52:59 +0100 Subject: [IronPython] constructor inheritance not working Message-ID: <1093359179.18927.71.camel@saag> test case against Mono attached, just unzip and run make briefly, the problem is this. given public class TestCtor { public int Val; public TestCtor (int val) { Val = val; } public TestCtor () : this (5) { } } When the second constructor is called from IronPython, the inherited constructor isn't being called, and so Val remains uninitialised. This ctor use is quite a common pattern in Gtk#, which is where I first encountered the issue. -- Edd -------------- next part -------------- A non-text attachment was scrubbed... Name: testctor.zip Type: application/zip Size: 797 bytes Desc: not available URL: From edd at usefulinc.com Tue Aug 24 18:33:14 2004 From: edd at usefulinc.com (Edd Dumbill) Date: Tue, 24 Aug 2004 17:33:14 +0100 Subject: [IronPython] constructor inheritance not working In-Reply-To: <1093359179.18927.71.camel@saag> References: <1093359179.18927.71.camel@saag> Message-ID: <1093365194.18927.80.camel@saag> On Tue, 2004-08-24 at 15:52 +0100, Edd Dumbill wrote: > When the second constructor is called from IronPython, the inherited > constructor isn't being called, and so Val remains uninitialised. This > ctor use is quite a common pattern in Gtk#, which is where I first > encountered the issue. Several correspondents tell me this works OK with the Microsoft runtime, so I've filed it as a Mono bug; http://bugzilla.ximian.com/show_bug.cgi?id=63843 -- Edd From niki at vintech.bg Tue Aug 24 16:51:02 2004 From: niki at vintech.bg (Niki Spahiev) Date: Tue, 24 Aug 2004 17:51:02 +0300 Subject: [IronPython] Keyword arguments In-Reply-To: <412B51B2.1040109@sweetapp.com> References: <412B51B2.1040109@sweetapp.com> Message-ID: <412B55D6.5020702@vintech.bg> Brian Quinlan wrote: > I actually noticed this problem while > writing a script to add .NET Framework intellisense support to > ActiveState's Python IDE. If anyone is interested in either the source > or the datafile, please let me know. If you mean Pythonwin IDE, i would like to get both. Niki Spahiev From david.ascher at gmail.com Tue Aug 24 18:55:10 2004 From: david.ascher at gmail.com (David Ascher) Date: Tue, 24 Aug 2004 09:55:10 -0700 Subject: [IronPython] Keyword arguments In-Reply-To: <412B55D6.5020702@vintech.bg> References: <412B51B2.1040109@sweetapp.com> <412B55D6.5020702@vintech.bg> Message-ID: On Tue, 24 Aug 2004 17:51:02 +0300, Niki Spahiev wrote: > Brian Quinlan wrote: > > > I actually noticed this problem while > > writing a script to add .NET Framework intellisense support to > > ActiveState's Python IDE. If anyone is interested in either the source > > or the datafile, please let me know. > > If you mean Pythonwin IDE, i would like to get both. No, he means Komodo (www.activestate.com/Komodo). Brian is doing (great) unauthorized hacking of the new 'code intellgence' system in Komodo. --david From david.ascher at gmail.com Tue Aug 24 18:55:52 2004 From: david.ascher at gmail.com (David Ascher) Date: Tue, 24 Aug 2004 09:55:52 -0700 Subject: [IronPython] Keyword arguments In-Reply-To: References: <412B51B2.1040109@sweetapp.com> <412B55D6.5020702@vintech.bg> Message-ID: On Tue, 24 Aug 2004 09:55:10 -0700, David Ascher wrote: > No, he means Komodo (www.activestate.com/Komodo). Brian is doing > (great) unauthorized hacking of the new 'code intellgence' system in > Komodo. Brain typo: not unauthorized, unofficial. We're totally cool with it. --david From brian at sweetapp.com Tue Aug 24 19:25:01 2004 From: brian at sweetapp.com (Brian Quinlan) Date: Tue, 24 Aug 2004 19:25:01 +0200 Subject: [IronPython] Keyword arguments In-Reply-To: <412B55D6.5020702@vintech.bg> References: <412B51B2.1040109@sweetapp.com> <412B55D6.5020702@vintech.bg> Message-ID: <412B79ED.1090503@sweetapp.com> Niki Spahiev wrote: > If you mean Pythonwin IDE, i would like to get both. Unfortunately, there is very little intellisense infrastructure to work with in PythonWin. PythonWin uses introspection for the interactive shell but is just uses regular expressions for the editor window. I considered generating Python stubs from .NET assemblies for interactive exploration in various interactive shells and class browsers. I'll still might do it (especially if other people are interested). But making intellisense work well in PythonWin's editor windows would be a big project. Cheers, Brian From brian at sweetapp.com Tue Aug 24 19:30:42 2004 From: brian at sweetapp.com (Brian Quinlan) Date: Tue, 24 Aug 2004 19:30:42 +0200 Subject: [IronPython] Keyword arguments In-Reply-To: References: <412B51B2.1040109@sweetapp.com> <412B55D6.5020702@vintech.bg> Message-ID: <412B7B42.8000701@sweetapp.com> David Ascher wrote: > No, he means Komodo (www.activestate.com/Komodo). Brian is doing > (great) unauthorized hacking of the new 'code intellgence' system in > Komodo. Continuing from my last message, Komodo (unlike PythonWin) actually has the potential to maybe one day have good intellisense :-) It already has some nice functionality but getting Python intellisense working well is a really tough problem. It's really the same problem as writing a static type inferencer and no project that has attempted that has yet succeeded. Fortunately, the .NET API is nicely static so you can actually provide pretty good intellisense for that. Cheers, Brian From e8johan at yahoo.se Wed Aug 25 07:27:42 2004 From: e8johan at yahoo.se (=?iso-8859-1?q?Johan=20Thelin?=) Date: Wed, 25 Aug 2004 07:27:42 +0200 (CEST) Subject: [IronPython] C# Forms in Python Message-ID: <20040825052742.62486.qmail@web53001.mail.yahoo.com> Hi! I just wanted to tell you about a small tool that I hacked together to convert C# Forms designed in Visual Studio to Python classes. The project home page is here: http://www.digitalfanatics.org/e8johan/projects/cs2py/ and the announcement with a list of limitations is here: http://advogato.org/person/e8johan/diary.html?start=20 . Enjoy! Cheers! /Johan H?strusk och gr? moln - k?p en resa till solen p? Yahoo! Resor p? adressen http://se.docs.yahoo.com/travel/index.html From david.ascher at gmail.com Wed Aug 25 07:32:15 2004 From: david.ascher at gmail.com (David Ascher) Date: Tue, 24 Aug 2004 22:32:15 -0700 Subject: [IronPython] C# Forms in Python In-Reply-To: <20040825052742.62486.qmail@web53001.mail.yahoo.com> References: <20040825052742.62486.qmail@web53001.mail.yahoo.com> Message-ID: On Wed, 25 Aug 2004 07:27:42 +0200 (CEST), Johan Thelin wrote: > Hi! > > I just wanted to tell you about a small tool that I > hacked together to convert C# Forms designed in Visual > Studio to Python classes. The project home page is > here: > http://www.digitalfanatics.org/e8johan/projects/cs2py/ > and the announcement with a list of limitations is > here: > http://advogato.org/person/e8johan/diary.html?start=20 > .. Enjoy! Cool idea. Please consider a license that would make it possible to bundle it with IronPython at some point without forcing Jim to reconsider his license choice (the GPL doesn't fit that). --david From edd at usefulinc.com Wed Aug 25 12:27:59 2004 From: edd at usefulinc.com (Edd Dumbill) Date: Wed, 25 Aug 2004 11:27:59 +0100 Subject: [IronPython] More makefiles Message-ID: <1093429679.18927.95.camel@saag> I made Makefiles to build IronPython from scratch under Mono. They can be checked out of subversion from here: http://svn.usefulinc.com/svn/repos/trunk/ironpython/makefiles/ I use a silly little hack to build IronPython.dll twice, the first time without the SystemUtil reference, avoiding the need to have a SystemUtil.dll binary as a build prerequisite. Things that need adding to the Makefiles include * option to exclude external code * installation rules * convenience wrapper script generation If you're using these Makefiles on Windows I you will need cygwin. -- Edd From lupus at ximian.com Wed Aug 25 12:55:47 2004 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 25 Aug 2004 12:55:47 +0200 Subject: [IronPython] constructor inheritance not working In-Reply-To: <1093359179.18927.71.camel@saag> References: <1093359179.18927.71.camel@saag> Message-ID: <20040825105547.GD2761@debian.org> On 08/24/04 Edd Dumbill wrote: > public class TestCtor { > public int Val; > > public TestCtor (int val) > { > Val = val; > } > > public TestCtor () : this (5) > { > } > } > > When the second constructor is called from IronPython, the inherited > constructor isn't being called, and so Val remains uninitialised. This > ctor use is quite a common pattern in Gtk#, which is where I first > encountered the issue. As mentioned in another post, it looks like IronPython doesn't select the best method to invoke, in particular, if it finds a method with more args first, it will happily call that supplying default arguments for the missing params. At least this is what it seems from a quick lokk at the code. So the issue is not that mono doesn't call the inherited ctor, but that the base ctor is called directly by IronPython. If you invert the two TestCtor constructors in the source and recompile, the test runs fine in mono (would be interesting to know if it will work on the MS runtime, for some reason it hangs for me when running this sample, so I can't test it myself). There is still a minute chance this is due to some different behaviour in reflection between mono and MS, haven't investigated further. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From nbornstein at gmail.com Wed Aug 25 13:50:49 2004 From: nbornstein at gmail.com (Niel Bornstein) Date: Wed, 25 Aug 2004 07:50:49 -0400 Subject: [IronPython] constructor inheritance not working In-Reply-To: <20040825105547.GD2761@debian.org> References: <1093359179.18927.71.camel@saag> <20040825105547.GD2761@debian.org> Message-ID: <170bf63040825045062717788@mail.gmail.com> On Wed, 25 Aug 2004 12:55:47 +0200, Paolo Molaro wrote: > If you invert the two TestCtor constructors in the source and recompile, > the test runs fine in mono (would be interesting to know if it will work > on the MS runtime, for some reason it hangs for me when running this > sample, so I can't test it myself). There is still a minute chance this > is due to some different behaviour in reflection between mono and MS, > haven't investigated further. After switching the order of constructors in testctor.cs: C:\development\IronPython-0.6>csc testctor.cs Microsoft (R) Visual C# .NET Compiler version 7.10.3052.4 for Microsoft (R) .NET Framework version 1.1.4322 Copyright (C) Microsoft Corporation 2001-2002. All rights reserved. C:\development\IronPython-0.6>csc /target:library testctor.cs Microsoft (R) Visual C# .NET Compiler version 7.10.3052.4 for Microsoft (R) .NET Framework version 1.1.4322 Copyright (C) Microsoft Corporation 2001-2002. All rights reserved. C:\development\IronPython-0.6>testctor.exe a is 5, b is 3 C:\development\IronPython-0.6>bin\IronPythonConsole.exe testctor.py a is 5 b is 3 So it works fine in MS .NET 1.1. Niel From brian at sweetapp.com Wed Aug 25 16:24:31 2004 From: brian at sweetapp.com (Brian Quinlan) Date: Wed, 25 Aug 2004 16:24:31 +0200 Subject: [IronPython] Komodo .NET intellisense In-Reply-To: <412B55D6.5020702@vintech.bg> References: <412B51B2.1040109@sweetapp.com> <412B55D6.5020702@vintech.bg> Message-ID: <412CA11F.50404@sweetapp.com> Attached is my script for modifying the ActiveState Komodo intellisense database to provide intellisense for Windows forms. The script presumes that you've copied \python\Lib\site-packages\codeintel\python.cix TO \python\Lib\site-packages\codeintel\python-orig.cix Once you've done that, there are three paths that you'll have to change near the end of the script. Now run the script. Now you'll have to delete the Komodo database file (or fix my script to provide correct time stamps) from: C:\Documents and Settings\Brian Quinlan\Application Data\ActiveState\Komodo\3.0\\codeintel.db Then launch Komodo and rebuild the Komodo intellisense database (see "Preferences..."). Let me know if you need any help or what the prebuilt file (it's half a meg compressed so I'm not going to post it to the list). Cheers, Brian -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: netcix.py URL: From curt at hagenlocher.org Wed Aug 25 18:57:23 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 25 Aug 2004 09:57:23 -0700 Subject: [IronPython] Interaction with other CLR code Message-ID: <200408251657.JAA04515@dopey.hagenlocher.org> One of the things which would make IronPython more interesting would be to allow it to interact with other CLR code on a "first class" basis. As I see it, there are two components to this problem: 1. A Python object should have the ability to look like a more "regular" CLR object. 2. It should be possible to load a Python object from an assembly using a different (arbitrary) language. The first problem is potentially a lot simpler than the second, and the remainder of this message will focus on it. The easiest way to expose an object's methods to decide that we're going to do it through a CLR interface. The actual interface implementation will consist of shim functions which defer to the Python implementation in the usual dynamically dispatched manner. I see at least three architectures: 1. Create a shim class per interface. The classes can be cached, so that they only need to be emitted once per interface. Either a new instance of the shim class can be instantiated every time it's needed or the shims can be stored on the object. This approach allows silent type coercion when passing a Python-defined object to a function that expects a specific interface as a parameter -- though that is of questionable value. The usual way to wrap the object in an interface would be to call a system-defined function for that purpose. 2. Create a shim class per set of interfaces. This approach is similar to the first, except that a single shim class can implement multiple interfaces. This would require more complicated caching logic, and may result in more emitted classes being defined. What you would gain is the ability to cast IFoo to IBar, if the object in question defines both. 3. Define all the interfaces directly on the CLR base class for the Python class. For "classic" Python classes, the base class is always IronPython.Objects.OldClass, and it probably doesn't make sense to provide interface support here. But "new style" classes have a dynamically-generated base class currently created as "IronPython.NewTypes." + typename of CLR base class. (The default CLR base class is, of course, System.Object.) Taking this approach would again require more complicated class caching logic, and would result in more emitted code, but it probably results in the most natural usage pattern, allowing the following: class foo(ISerializable, IList): [...] As an aside, it is currently possible to do the following: class foo(Some.Other.CLR.Class): [...] and have "foo" actually derive from that class. There isn't any way to override the virtual methods in Some.Other.CLR.Class, though. -- Curt Hagenlocher curt at hagenlocher.org From ksriram at gmx.net Wed Aug 25 18:59:44 2004 From: ksriram at gmx.net (Sriram Krishnan) Date: Wed, 25 Aug 2004 22:29:44 +0530 Subject: [IronPython] Interaction with other CLR code In-Reply-To: <200408251657.JAA04515@dopey.hagenlocher.org> Message-ID: <20040825165953.8DA7D985D7@che.dreamhost.com> >>For "classic" Python classes, the base class is always IronPython.Objects.OldClass, and it probably doesn't make sense to provide interface support here. But "new style" classes have a dynamically-generated base class currently created as "IronPython.NewTypes." + typename of CLR base class. I'm a newbie here - could you clarify what you mean by old style classes and new-style classes? Thanks, Sriram --------------------------------------------------- I blog at http://www.dotnetjunkies.com/weblog/sriram ---------------------------------------------------- From curt at hagenlocher.org Wed Aug 25 19:04:37 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 25 Aug 2004 10:04:37 -0700 Subject: [IronPython] Interaction with other CLR code Message-ID: <200408251704.KAA04556@dopey.hagenlocher.org> "Sriram Krishnan" writes: > I'm a newbie here - could you clarify what you mean by old style > classes and new-style classes? See http://www.python.org/2.2/descrintro.html for details. -- Curt Hagenlocher curt at hagenlocher.org From brian at zope.com Wed Aug 25 20:37:52 2004 From: brian at zope.com (Brian Lloyd) Date: Wed, 25 Aug 2004 14:37:52 -0400 Subject: [IronPython] Questions for Jim.... Message-ID: Hi all - Most of these questions are for Jim, but I think the answers would probably be helpful to others, so I thought I'd post them to the list... Contribution: I'd really like to contribute to get IP to a production-ready release. Contributing builtin-module implementations would be right up my alley given my, er, copious free time ;) There isn't a public repository at the moment, so what is the best way to do that? Email things to Jim? Related to that, the current 0.6 code is released under CPL 1.0. Should contributions be sent under the same license? That seems obvious, but worth verifying since I don't know that MS' stance regarding IP and contributions to it has been described explicitly. Two others related to libraries (built-in or otherwise). "Batteries included" is a catchphrase for CPython, referring to the included library of standard modules. While I can divine how to implement a 'built-in' module in C# based on the 0.6 code, it looks like we still need a way to replicate one of the befefits of the CPython libraries (specifically that you can implement a library in Python, at least as a prototype, then move it to 'native' code later w/o changing the Python interface). That is also probably a key to 'keeping up with the latest Python version' for the CLR implementation, since most new library module are implemented in Python first. I don't see a way to do that currently (but maybe I'm missing something?) Finally, Python is an ideal language for writing unit tests. While a reasonably large part of the Python community is 'test-infected', there are currently no unit tests for most of the built-in and standard libaries in Python. Implementing new built-in and standard libs for IP could be an opportunity to create those unit tests and contribute them back to the Python community at large to be used in the CPython implementation as well. I would argue that getting unittest.py (or a managed equivalent) working in the near term should be a reasonably high priority (and would also provide the infrastructure to better gauge the state of the managed Python runtime as a whole). Sorry for the litany of questions, but I wanted to get them all out while I was thinking about it ;) Brian Lloyd brian at zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From luismg at gmx.net Thu Aug 26 04:23:04 2004 From: luismg at gmx.net (Luis M. Gonzalez) Date: Wed, 25 Aug 2004 23:23:04 -0300 Subject: [IronPython] Windows Forms Message-ID: <000801c48b13$9fe9b6b0$0a01000a@luis> Sorry for this silly question... I wonder if there is a way to hide the console box while running an IronPython winforms app. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thane at magna-capital.com Thu Aug 26 06:32:03 2004 From: thane at magna-capital.com (Thane) Date: Wed, 25 Aug 2004 21:32:03 -0700 Subject: [IronPython] Windows Forms In-Reply-To: <000801c48b13$9fe9b6b0$0a01000a@luis> Message-ID: The short answer is, "no", and the question's not silly. You can minimize the window, but I suspect you want the whole Console window to disappear. The solution to this is a bit complicated, as you may have guessed from the two flavors of CPython (python.exe and pythonw.exe). It can be done, and hopefully Jim will add this to his long wish list of IronPython features. _____ From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Luis M. Gonzalez Sent: Wednesday, August 25, 2004 7:23 PM To: users-ironpython.com at lists.ironpython.com Subject: [IronPython] Windows Forms Sorry for this silly question... I wonder if there is a way to hide the console box while running an IronPython winforms app. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at ironpython.com Thu Aug 26 08:12:03 2004 From: jim at ironpython.com (Jim Hugunin) Date: Wed, 25 Aug 2004 23:12:03 -0700 Subject: [IronPython] Keyword arguments In-Reply-To: <412B51B2.1040109@sweetapp.com> Message-ID: <20040826061210.4CD9013DFC5@sack.dreamhost.com> Brian Quinlan wrote: > Currently it appears, at least for constructors, that IronPython is > transforming keyword arguments into attribute assignments e.g. > I would argue strongly that this is a bad idea; keyword arguments should > have the same semantics as they do in CPython. The most obvious reason > that I can think of is that keyword arguments, used as in CPython, can > clarify the meaning of various arguments. Compatibility is also an issue > as is 3rd party tools support. I actually noticed this problem while > writing a script to add .NET Framework intellisense support to > ActiveState's Python IDE. If anyone is interested in either the source > or the datafile, please let me know. I really like this feature and it's unlikely that it will disappear in the future without a strong argument. I originally designed it for Jython as the way that I could make code using swing as easy to write as TkInter code. I think it serves that same purpose to make Windows.Forms or GTK# code friendlier to scripting. This is one of the ideas in Jython that the groovy developers liked enough to borrow for their language. This is NOT a change to CPython's semantics. Keyword arguments are used to allow the initialization of attributes (and fields) only for code from standard CLR libraries that weren't designed with Python or any scripting language in mind. Constructors for Python classes should continue to behave exactly as they do in CPython. I'm not at all worried about compatibility with 3rd party tools. Anyone who wants to support the CLR libraries in a 3rd party IDE integration is going to have to do some special work to understand those libraries. It shouldn't be very hard to modify any symbol tables to pretend that the constructors for CLR classes include the appropriate well-defined optional keyword parameters. -Jim From brian at sweetapp.com Thu Aug 26 14:19:01 2004 From: brian at sweetapp.com (Brian Quinlan) Date: Thu, 26 Aug 2004 14:19:01 +0200 Subject: [IronPython] Keyword arguments In-Reply-To: <20040826061210.4CD9013DFC5@sack.dreamhost.com> References: <20040826061210.4CD9013DFC5@sack.dreamhost.com> Message-ID: <412DD535.9060405@sweetapp.com> Jim Hugunin wrote: > I really like this feature and it's unlikely that it will disappear in the > future without a strong argument. I originally designed it for Jython as > the way that I could make code using swing as easy to write as TkInter code. > I think it serves that same purpose to make Windows.Forms or GTK# code > friendlier to scripting. This is one of the ideas in Jython that the groovy > developers liked enough to borrow for their language. I actually like the feature as well. A lot of .NET Framework constructors are option-starved and this is a reasonable way of working around this problem. Of coures you could write a simple function to do this as well (maybe make it a built-in). def create_and_set(type, *args, **kws): # XXX need better name i = type(*args) for k, v in kws.items: setattr(i, k, v) return i create_and_set(Form, Location=Point(2,3), ...) OR construct(Form, Location=Point(2,3), ...) OR ctor(Form, Location=Point(2,3), ...) OR build(Form, Location=Point(2,3), ...) OR create(Form, Location=Point(2,3), ...) I'm not sure that I like any of those names but the syntax seems reasonable and the semantics are easily understood by the Python programmer. > This is NOT a change to CPython's semantics. Keyword arguments are used to > allow the initialization of attributes (and fields) only for code from > standard CLR libraries that weren't designed with Python or any scripting > language in mind. Constructors for Python classes should continue to behave > exactly as they do in CPython. I'm not sure how you can argue that this is not a semantic change. CLR method signatures look a lot like regular Python signatures (with the addition of type information). You are imposing two different semantics that the user has to remember i.e. when you are calling a Python method, keywords arguments mean THIS but when calling a CLR method keyword arguments mean THAT. This is a technically unnecessary distinction. And what happens if I get a compiled Python assembly from someone - what do keywords mean in that case? Either way it will be confusing. I'm probably not smart enough to effectively make this argument - I'll try to recruit someone smarter who agrees with me if you need more encouragement. Cheers, Brian From robertoschler at hotmail.com Thu Aug 26 18:10:33 2004 From: robertoschler at hotmail.com (Robert Oschler) Date: Thu, 26 Aug 2004 12:10:33 -0400 Subject: [IronPython] IronPython - thread to Python? Message-ID: I saw an entry on one of my favorite "news" blogs, Daily Python: http://www.pythonware.com/daily/ On 2004-08-23 Ted Leung had this to say: "I think that the threat from IronPython is much worse than the Bill describes. Not only does IronPython have the potential to make scripting on the JVM DOA, it also has the power to destroy Python as we know it." This seems a bit melodramatic, doesn't it? Thanks. http://www.robotsrule.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Thu Aug 26 19:26:55 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 26 Aug 2004 10:26:55 -0700 Subject: [IronPython] Interaction with other CLR code Message-ID: <200408261726.KAA06641@dopey.hagenlocher.org> Some more thoughts on this topic. Unresolved: 1. How to handle properties? If we were to map properties in a CLR interface onto Python properties, we wouldn't be able to handle indexed properties. Indexed properties could be handled through get_PROPERTYNAME and set_PROPERTYNAME functions on the Python objects. Then, do you use a Python property to implement a nonindexed CLR proprty and a Python function to implement an indexed CLR property, or is this too inconsistent? 2. What should be done with out parameters? > 1. Create a shim class per interface. The classes can be cached, > so that they only need to be emitted once per interface. Actually, you might even be able to do better than that and store these assemblies on disk in a well-defined place, meaning that on subsequent runs you could skip the codegen phase. > The usual way to wrap the > object in an interface would be to call a system-defined function > for that purpose. I've got this code working now and will post it after some minor cleanup. -- Curt Hagenlocher curt at hagenlocher.org From luismg at gmx.net Thu Aug 26 20:47:56 2004 From: luismg at gmx.net (Luis M. Gonzalez) Date: Thu, 26 Aug 2004 15:47:56 -0300 Subject: [IronPython] C# Forms in Python Message-ID: <000a01c48b9d$396d3080$0a01000a@luis> That's a very clever tool Johan! I've been playing with it and I love it. Are you planing to keep on developing it? I found that one of the things that doesn't translate to python are the menus. Anyway, It's a great tool for placing each widget in the right place, task that it's very difficult to achieve by coding. Keep up the good work! Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbastin at opnet.com Thu Aug 26 20:54:53 2004 From: nbastin at opnet.com (Nick Bastin) Date: Thu, 26 Aug 2004 14:54:53 -0400 Subject: [IronPython] IronPython - thread to Python? In-Reply-To: References: Message-ID: <6A35A566-F791-11D8-8D32-000D932927FE@opnet.com> On Aug 26, 2004, at 12:10 PM, Robert Oschler wrote: > I saw an entry on one of my favorite "news" blogs, Daily Python: > ? > http://www.pythonware.com/daily/ > ? > On 2004-08-23 Ted Leung had this to say: > ? > "I think that the threat from IronPython is much worse than the Bill > describes. Not only does IronPython have the potential to make > scripting on the JVM DOA, it also has the power to destroy Python as > we know it." > ? > This seems a bit melodramatic, doesn't it? You should definitely read Ted's whole blog, and not just the blurb. He makes some good points, and his blog is generally a good read. He makes his living writing code in python, so I wouldn't just write off his opinions... -- Nick From kfarmer at thuban.org Thu Aug 26 21:28:16 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Thu, 26 Aug 2004 12:28:16 -0700 Subject: [IronPython] IronPython - thread to Python? Message-ID: I agree that it's melodramatic, despite some points. The thing that people seem to gloss over is that Microsoft has done *nothing* to purchase IronPython (assuming Jim would tell us if they had). That's prior art, owned by Jim, distributed under an OS license, and undoubtedly Jim declared it as his when he filled out the usual paperwork as a new hire. All Microsoft has done is hire Jim, who would give them the insight to make the CLR more friendly to development such as this. They *could*, of course, make their own implementation, and submit it to ECMA. In that event, given their attitudes of late, I predict they'd be in consultation with Guido to formalize the language for submission, and then go on their own paths toward implementation. Same thing that's going on with C#, .NET Fx, and Mono: standardize the language, implement on your own, provide your own framework libraries as desired. Frankly, I think taking Python and submitting it to ECMA would be one of the better things that could happen to it. At least then people can quit worrying over the platform and appreciate the language itself. I'd be happy myself to get back to Python if it were on the CLR, which is why I'm interested in IronPython. ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Nick Bastin Sent: Thu 8/26/2004 11:54 AM On Aug 26, 2004, at 12:10 PM, Robert Oschler wrote: > I saw an entry on one of my favorite "news" blogs, Daily Python: > > http://www.pythonware.com/daily/ > > On 2004-08-23 Ted Leung had this to say: > > "I think that the threat from IronPython is much worse than the Bill > describes. Not only does IronPython have the potential to make > scripting on the JVM DOA, it also has the power to destroy Python as > we know it." > > This seems a bit melodramatic, doesn't it? You should definitely read Ted's whole blog, and not just the blurb. He makes some good points, and his blog is generally a good read. He makes his living writing code in python, so I wouldn't just write off his opinions... From kfarmer at thuban.org Thu Aug 26 21:29:06 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Thu, 26 Aug 2004 12:29:06 -0700 Subject: [IronPython] C# Forms in Python Message-ID: Out of curiosity -- MyXaml (www.myxaml.org) and Python.. think that'd be interesting? From fredrik at pythonware.com Thu Aug 26 21:44:55 2004 From: fredrik at pythonware.com (Fredrik Lundh) Date: Thu, 26 Aug 2004 21:44:55 +0200 Subject: [IronPython] IronPython - thread to Python? References: Message-ID: Robert Oschler wrote: > > "I think that the threat from IronPython is much worse than the Bill describes. > > Not only does IronPython have the potential to make scripting on the JVM > > DOA, it also has the power to destroy Python as we know it." > > This seems a bit melodramatic, doesn't it? fact is, every new release of CPython destroys Python as we know it. From david.ascher at gmail.com Thu Aug 26 22:33:56 2004 From: david.ascher at gmail.com (David Ascher) Date: Thu, 26 Aug 2004 13:33:56 -0700 Subject: [IronPython] IronPython - thread to Python? In-Reply-To: References: Message-ID: On Thu, 26 Aug 2004 21:44:55 +0200, Fredrik Lundh wrote: > fact is, every new release of CPython destroys Python as we know it. Le roi est mort, vive le roi! as I say ;-) From e8johan at yahoo.se Fri Aug 27 07:29:02 2004 From: e8johan at yahoo.se (=?iso-8859-1?q?Johan=20Thelin?=) Date: Fri, 27 Aug 2004 07:29:02 +0200 (CEST) Subject: [IronPython] C# Forms in Python In-Reply-To: <000a01c48b9d$396d3080$0a01000a@luis> Message-ID: <20040827052902.61149.qmail@web53001.mail.yahoo.com> > I've been playing with it and I love it. Are you > planing to keep on developing it? Yes, I do. The problem is that I'm between computers right now (I'm trying to find time to setup the new one) so my development time is a bit busy. > I found that one of the things that doesn't > translate to python are the menus. I didn't try menus, but I'll try them out. BTW: Does anyone know why the form itself doesn't resize. The code is there, but the form does not respond to it. (It is probably me being stupid and missing something simple). /Johan H?strusk och gr? moln - k?p en resa till solen p? Yahoo! Resor p? adressen http://se.docs.yahoo.com/travel/index.html From curt at hagenlocher.org Fri Aug 27 17:54:13 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 27 Aug 2004 08:54:13 -0700 Subject: [IronPython] Interaction with other CLR code Message-ID: <200408271554.IAA08498@dopey.hagenlocher.org> I previously wrote: > 1. How to handle properties? If we were to map properties in a > CLR interface onto Python properties, we wouldn't be able to > handle indexed properties. Of course, I've been spending too much time in IL lately, and forgot that C# doesn't really handle indexed properties. The only property that can be indexed is the "Item" property, which in C# has the flavor of overriding the [] operator. Perhaps this should be specially mapped onto __getitem__ and __setitem__. VB apparently provides full support for indexed properties, but I don't want to learn the syntax just to test this. I've attached a ZIP archive that contains four files: a new file DelegateMaker.cs, which contains most of the new code a modified sys.cs, which contains the new function WrapObject a test program consisting of two files: itest.cs and itest.py Put DelegateMaker.cs into the Objects directory and add it either to your VS.NET project or your makefile. Replace sys.cs. Build the test dll with "csc /target:library itest.cs", then run the .py file. The .py file defines a class "foo", an instance of which is wrapped in the "TestInterface" interface defined by itest.cs. This wrapper is then passed to the "DoTest" function also defined in itest.cs. One limitation of the current code is that the wrapper object itself doesn't get along very nicely with IronPython. You really can't do anything with it other than pass it to other CLR code. I'd appreciate hearing of your experiences from anyone who tries this out. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- A non-text attachment was scrubbed... Name: InterfaceWrapper.zip Type: application/x-zip-compressed Size: 5946 bytes Desc: not available URL: From andy at msistone.com Sat Aug 28 01:40:42 2004 From: andy at msistone.com (Andy Shah) Date: Fri, 27 Aug 2004 16:40:42 -0700 Subject: [IronPython] How would you use IronPython with WMI? Message-ID: <3D7CB0127A254149AB5C0939C828D9305803@mosaic.domain-msi.local> How does one use IronPython with WMI ? I have a short code gleaned from a website http://www.c-sharpcorner.com/Code/2004/March/WMIEventDetecting.asp converted to python from System.Management.Instrumentation import * f = TestWMI.ROOT.CIMV2.Printer("Canon-Import") MessageBox.Show(p.Caption) MessageBox.Show(p.HorizontalResolution.ToString()) MessageBox.Show(p.VerticalResolution.ToString()) ... and it does not work.... this is the error i am getting... Unhandled Exception: IronPython.Objects.PythonAttributeError: 'package#' object has no attribute 'Management' at IronPython.Objects.Ops.GetAttr(Object o, String name) at IronPython.Objects.Importer.ImportFrom(Object mod, String name) at IronPython.Objects.Importer.ImportOne(String fullName, Boolean keepTop) at IronPython.Objects.module.Import(String fullName, Boolean keepTop) at IronPython.Objects.Ops.ImportStar(module mod, String fullName) at __main__.init() in C:\ip\examples\test.py:line 1 at IronPythonConsole.IronPython.DoFile(String[] args) at IronPythonConsole.IronPython.Main(String[] args) What should i do to get WMI working for IronPython? Kind Regards, Andy. From curt at hagenlocher.org Sat Aug 28 01:55:49 2004 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 27 Aug 2004 16:55:49 -0700 Subject: [IronPython] How would you use IronPython with WMI? Message-ID: <200408272355.QAA09249@dopey.hagenlocher.org> > from System.Management.Instrumentation import * You need to add the following code before this line. import sys sys.LoadAssemblyByName('System.Management.dll') -- Curt Hagenlocher curt at hagenlocher.org From kfarmer at thuban.org Sat Aug 28 02:13:09 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Fri, 27 Aug 2004 17:13:09 -0700 Subject: [IronPython] How would you use IronPython with WMI? Message-ID: Try 'System.Management' (omit the .dll) ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Curt Hagenlocher Sent: Fri 8/27/2004 4:55 PM import sys sys.LoadAssemblyByName('System.Management.dll') From kfarmer at thuban.org Sat Aug 28 02:17:34 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Fri, 27 Aug 2004 17:17:34 -0700 Subject: [IronPython] How would you use IronPython with WMI? Message-ID: I had switched to debug mode, trying to look into a bug. Couldn't compile -- SystemUtils was missing. I think I committed a sin when I added a reference to vjslib (the J# library) and replaced the call to SystemUtil.IdentityHashCode(o) in Ops.Id with a call to java.lang.System.identityHashCode(o). It compiled and ran, at least. I'm guess that it's equivalent? Java's the only place I saw on google that had such a method name. From kfarmer at thuban.org Sat Aug 28 03:05:17 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Fri, 27 Aug 2004 18:05:17 -0700 Subject: [IronPython] How would you use IronPython with WMI? Message-ID: import sys sys.LoadAssemblyByName("System.Management") from System.Management import * def doSearch(searchString): for x in ManagementObjectSearcher(searchString).Get(): for y in x.Properties: print str(y.Name) + ": " + str(y.Value) print "-----" doSearch("select name, horizontalResolution, verticalResolution from win32_printer") ... I'd never done this sort of thing before. Thanks :) ________________________________ From: users-ironpython.com-bounces at lists.ironpython.com on behalf of Andy Shah Sent: Fri 8/27/2004 4:40 PM How does one use IronPython with WMI ? I have a short code gleaned from a website http://www.c-sharpcorner.com/Code/2004/March/WMIEventDetecting.asp converted to python from System.Management.Instrumentation import * f = TestWMI.ROOT.CIMV2.Printer("Canon-Import") MessageBox.Show(p.Caption) MessageBox.Show(p.HorizontalResolution.ToString()) MessageBox.Show(p.VerticalResolution.ToString()) From kfarmer at thuban.org Sat Aug 28 03:45:43 2004 From: kfarmer at thuban.org (Keith J. Farmer) Date: Fri, 27 Aug 2004 18:45:43 -0700 Subject: [IronPython] More WMI Message-ID: >>> def showAll(root): ... nsClass = ManagementClass(ManagementScope(root), ManagementPath("__namespace"), None) ... for namespace in nsClass.GetInstances(): ... print "-----" ... for nsProp in namespace.Properties: ... print str(nsProp.Name), ":", str(nsProp.Value) ... print "--" ... searcher = ManagementObjectSearcher(ManagementScope("root\\" + str(namespace.GetPropertyValue("Name"))), WqlObjectQuery("select * from meta_class"), None) ... for wmiClass in searcher.Get(): ... print "Class:", wmiClass.GetPropertyValue("__CLASS") showAll("root") .. lots of scroll. Bug: "root\\" needs to actually be the real path of the parent namespace if you expect to show anything under, say, "root\CIMV2" From senthilkumar.chockalingam at kla-tencor.com Sat Aug 28 09:26:29 2004 From: senthilkumar.chockalingam at kla-tencor.com (senthilkumar) Date: Sat, 28 Aug 2004 12:56:29 +0530 Subject: [IronPython] Using IronPython Message-ID: Hi I'm new to IronPython. Actually i have to run python commands from C#.Net windows forms. How do i start? Please help me. Thanks in Advance Senthil Kumar From david.powell at kcl.ac.uk Tue Aug 31 13:37:15 2004 From: david.powell at kcl.ac.uk (david Powell) Date: Tue, 31 Aug 2004 12:37:15 +0100 Subject: [IronPython] dll Message-ID: <20040831113713.71059985A0@che.dreamhost.com> >From the mailing list I can see that typing at the command prompt C:\IronPython\bin> IronPythonConsole colors.py Produces the executable __main__.exe. But is it possible at this stage to produce a dll that can be referenced by C# or VB.NET? regards David -------------- next part -------------- An HTML attachment was scrubbed... URL: From edd at usefulinc.com Tue Aug 31 16:59:54 2004 From: edd at usefulinc.com (Edd Dumbill) Date: Tue, 31 Aug 2004 15:59:54 +0100 Subject: [IronPython] Why not post patches? In-Reply-To: <2D89F6C4A80FA547BF5D5B8FDDD04523060CB9@exchange.adrembi.com> References: <2D89F6C4A80FA547BF5D5B8FDDD04523060CB9@exchange.adrembi.com> Message-ID: <1093964394.4135.9.camel@saag> On Sun, 2004-08-15 at 08:28 +0300, Roman Yakovenko wrote: > P.S. Code was not post because Jim could not accept > any patches right now. He is working hard to solve > this problem. Anyway if someone needs code - turn to > me and I will send patch to you Why don't you just send patches to the mailing list? It doesn't force Jim to do anything, but it makes life easier for those of us who are experimenting. My biggest wish right now would be a public source repository to make it easy for others to help with development, or some indication of how interested people can help. I've seen several posts from very able folk wanting to get involved, but so far no indication whether this would be welcome or not. Clearly we all think IronPython is amazing work and want to contribute to it. -- Edd From jeffg at ActiveState.com Tue Aug 31 20:40:12 2004 From: jeffg at ActiveState.com (Jeff Griffiths) Date: Tue, 31 Aug 2004 11:40:12 -0700 Subject: [IronPython] Why not post patches? In-Reply-To: <1093964394.4135.9.camel@saag> References: <2D89F6C4A80FA547BF5D5B8FDDD04523060CB9@exchange.adrembi.com> <1093964394.4135.9.camel@saag> Message-ID: <4134C60C.3060307@activestate.com> Edd Dumbill wrote: > I've seen several posts from very able folk wanting to get involved, > but so far no indication whether this would be welcome or not. > Clearly we all think IronPython is amazing work and want to > contribute to it. ...which sort of begs another question: If there is to be an 'IronPython project' ( yes! ) how will that work? Does Jim have time or inclination to manage this? Should someone else / some group step in / should there be a process for making decisions like that? I mean, someone could just start a sourceforge project ( assuming sourceforge is working again ) but that may not be Jim's preference, or that of other interested people. cheers, JeffG ( just playing the devil's advocate here ) > > -- Edd > > > _______________________________________________ users-ironpython.com > mailing list users-ironpython.com at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com