From Martin.Maly at microsoft.com Mon Oct 1 17:19:25 2007 From: Martin.Maly at microsoft.com (Martin Maly) Date: Mon, 1 Oct 2007 08:19:25 -0700 Subject: [IronPython] Bug report In-Reply-To: <000001c7c77c$3155d7d0$3069a8c0@china.freeborders> References: <000001c7c77c$3155d7d0$3069a8c0@china.freeborders> Message-ID: I don't believe it is a bug. Notice that when you appended C:\\bin, you used double back-slash "\\", but when appending the C:\Windows\Bin you only used single backslash. Python standard then says: Unlike Standard C, all unrecognized escape sequences are left in the string unchanged, i.e., the backslash is left in the string. Therefore, the firs backslash "\w" is left in the string, but the 2nd one (\b) is replaced because it is a valid escape sequence (backspace). You can use either r"C:\windows\bin" or "C:\\windows\\bin" to achieve what you need. Martin From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of ??? Sent: Monday, July 16, 2007 12:38 AM To: Dino Viehland; 'Discussion of IronPython' Subject: [IronPython] Bug report Hi Dino, I met a IronPython bug, does this bug has been reported? IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import sys >>> sys.path.append("c:\\bin") >>> sys.path ['D:\\Python\\IronPython', 'D:\\Python\\IronPython\\Lib', 'c:\\bin'] >>> sys.path.append("c:\windows") >>> sys.path ['D:\\Python\\IronPython', 'D:\\Python\\IronPython\\Lib', 'c:\\bin', 'c:\\windows'] >>> sys.path.append("c:\windows\bin") >>> sys.path ['D:\\Python\\IronPython', 'D:\\Python\\IronPython\\Lib', 'c:\\bin', 'c:\\windows', 'c:\\windows\x08in'] >>> Andy.Tao -------------- next part -------------- An HTML attachment was scrubbed... URL: From mclinton at procard.com Mon Oct 1 17:22:01 2007 From: mclinton at procard.com (Matt Clinton) Date: Mon, 1 Oct 2007 09:22:01 -0600 Subject: [IronPython] [python] Re: Object DBs - Zope/Plone vs LINQ? In-Reply-To: <7AD436E4270DD54A94238001769C2227CCBD18D1C0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <20253b0c0709271336v79b6911ex6130164ac528be57@mail.gmail.com><046C79B13A2D204A9FFB87C2EA406CA7028CF30A@glesexcc03.procard.local><46FD8B81.5040207@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CCBD18D1C0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <046C79B13A2D204A9FFB87C2EA406CA7028CF4B2@glesexcc03.procard.local> Thanks for the rich responses - illuminating. To be a little more specific, I was thinking about the Object/Relational Designer in the LINQ article: not so much the SQL-variant syntax to access traditional DBs (sweet as that is, there's plenty of good ways already, ala DBI), but was wondering the language-support level for database-like collections of pythonic objects, like ZODB. It looks to me like IPy has two ways to get to roughly the same end: one down the CPy route, the other through LINQ. As usual, "both" is probably the preferred answer. Thanks again, -- Matt From kfarmer at thuban.org Mon Oct 1 22:50:50 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 1 Oct 2007 13:50:50 -0700 Subject: [IronPython] [python] Re: Object DBs - Zope/Plone vs LINQ? References: <20253b0c0709271336v79b6911ex6130164ac528be57@mail.gmail.com><046C79B13A2D204A9FFB87C2EA406CA7028CF30A@glesexcc03.procard.local><46FD8B81.5040207@voidspace.org.uk><7AD436E4270DD54A94238001769C2227CCBD18D1C0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <046C79B13A2D204A9FFB87C2EA406CA7028CF4B2@glesexcc03.procard.local> Message-ID: Being a pattern, LINQ supports operations over object collections just as well as it supports building expression trees to translate into SQL (or XQuery, or web service calls...). The benefit, of course, is that you use the same query syntax no matter the nature of the data source. It would probably be interesting porting the Enumerable static class (which holds all the LINQ to Object language extensions) to pure python, so that IP code that made use of it could still function under CPy. ________________________________ From: users-bounces at lists.ironpython.com on behalf of Matt Clinton Sent: Mon 10/1/2007 8:22 AM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Object DBs - Zope/Plone vs LINQ? Thanks for the rich responses - illuminating. To be a little more specific, I was thinking about the Object/Relational Designer in the LINQ article: not so much the SQL-variant syntax to access traditional DBs (sweet as that is, there's plenty of good ways already, ala DBI), but was wondering the language-support level for database-like collections of pythonic objects, like ZODB. It looks to me like IPy has two ways to get to roughly the same end: one down the CPy route, the other through LINQ. As usual, "both" is probably the preferred answer. Thanks again, -- Matt _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From daftspaniel at gmail.com Mon Oct 1 23:52:39 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Mon, 1 Oct 2007 22:52:39 +0100 Subject: [IronPython] INI File For IronPython Message-ID: <20253b0c0710011452r39145030p17db93d4f9988a87@mail.gmail.com> Hey Folks, Just wanted to pick a few brains... I was working on storage for GUI applications using INI files and CPython libs. I am looking to remove the dependency on Python 2 and do it all in DotNet. However as far as I can see there is not direct support for settings files - at least this is what I gather from all the implementations on the web of various XML/registry solutions none of which look too polished next to ConfigObj or the Python standard lib. How have other people solved this? Just need the basic name/value pair to sart with. Thanks, Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From aschaeffer at northps.com Tue Oct 2 00:09:01 2007 From: aschaeffer at northps.com (Andrew Schaeffer) Date: Mon, 1 Oct 2007 18:09:01 -0400 Subject: [IronPython] INI File For IronPython In-Reply-To: <20253b0c0710011452r39145030p17db93d4f9988a87@mail.gmail.com> References: <20253b0c0710011452r39145030p17db93d4f9988a87@mail.gmail.com> Message-ID: <735AC5A411C8A14498A8E7C129FCFADB0710477FED@119565-MAIL1.northps.com> Use .NET app.config file. Key-value pair settings can be stored in the section. For example, You can access the key-value pair through (depending on which version of .NET you are using) the System.Configuration Namespace. // .NET 1.x System.Configuration.ConfigurationSettings.AppSettings["LoginAttempts"]; // .NET 2.0 System.Configuration.ConfigurationManager.AppSettings["LoginAttempts"]; -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Monday, October 01, 2007 5:53 PM To: Discussion of IronPython Subject: [IronPython] INI File For IronPython Hey Folks, Just wanted to pick a few brains... I was working on storage for GUI applications using INI files and CPython libs. I am looking to remove the dependency on Python 2 and do it all in DotNet. However as far as I can see there is not direct support for settings files - at least this is what I gather from all the implementations on the web of various XML/registry solutions none of which look too polished next to ConfigObj or the Python standard lib. How have other people solved this? Just need the basic name/value pair to sart with. Thanks, Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Tue Oct 2 00:12:30 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 01 Oct 2007 23:12:30 +0100 Subject: [IronPython] [python] INI File For IronPython In-Reply-To: <20253b0c0710011452r39145030p17db93d4f9988a87@mail.gmail.com> References: <20253b0c0710011452r39145030p17db93d4f9988a87@mail.gmail.com> Message-ID: <470170CE.701@voidspace.org.uk> Davy Mitchell wrote: > Hey Folks, > > Just wanted to pick a few brains... > > I was working on storage for GUI applications using INI files and > CPython libs. I am looking to remove the dependency on Python 2 and do > it all in DotNet. However as far as I can see there is not direct > support for settings files - at least this is what I gather from all > the implementations on the web of various XML/registry solutions none > of which look too polished next to ConfigObj or the Python standard > lib. > > How have other people solved this? Just need the basic name/value pair > to sart with. > Why not just use ConfigObj ? :-) Michael > Thanks, > Davy > > From joesox at gmail.com Tue Oct 2 07:33:38 2007 From: joesox at gmail.com (JoeSox) Date: Mon, 1 Oct 2007 22:33:38 -0700 Subject: [IronPython] INI File For IronPython In-Reply-To: <20253b0c0710011452r39145030p17db93d4f9988a87@mail.gmail.com> References: <20253b0c0710011452r39145030p17db93d4f9988a87@mail.gmail.com> Message-ID: <785694cd0710012233l39ca89cfm398594afa66b69fd@mail.gmail.com> On 10/1/07, Davy Mitchell wrote: > Hey Folks, > > Just wanted to pick a few brains... > > I was working on storage for GUI applications using INI files and > CPython libs. I am looking to remove the dependency on Python 2 and do > it all in DotNet. However as far as I can see there is not direct > support for settings files - at least this is what I gather from all > the implementations on the web of various XML/registry solutions none > of which look too polished next to ConfigObj or the Python standard > lib. > > How have other people solved this? Just need the basic name/value pair > to sart with. I didn't have too many settings for one app I am working on and I also wanted to keep it simple as possible. So I am using the same python module file that IronPython is importing. This allows the module to work in native Python environments (including non Windows OSs) and in its IronPython GUI. As long as the features don't change too drastically all that needs to be updated is the python module. An autoupdate feature in its IronPython GUI downloads the new mod and autobacksup the previous one, just incase. Feel free to look at pswrdgeniron (IronPython GUI for pswrdgen). http://www.codeproject.com/useritems/pswrdgeniron.asp The module opens itself and reads in the first few lines, which each setting is defined in order on a line. I used format of "VARNAME::value" with the value encoded as a string so it is easy to split and assign to a self.VARNAME. From there it's easy to bridge to IronPython. http://joeswammi.com/python/docs/pswrdgen/index.html -- Later, JoeSox From storm.openmail at gmail.com Tue Oct 2 16:35:04 2007 From: storm.openmail at gmail.com (Martin) Date: Tue, 2 Oct 2007 16:35:04 +0200 Subject: [IronPython] -X:PreferComDispatch Message-ID: Hi, Can anyone eleaborate a bit more on the -X:PreferComDispatch option? Does it mean extended support for standard libraries? What does the prefer part stand for as in prefer com over what? BR Martin From dinov at exchange.microsoft.com Tue Oct 2 17:56:03 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 2 Oct 2007 08:56:03 -0700 Subject: [IronPython] -X:PreferComDispatch In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C2227CCBD18D5D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> This enables using new support for COM objects that uses COM's IDispatch interface instead of trying to get a TypeInfo for the object and use that to invoke it. With it enabled we'll first check for IDispatch then to see if we can get the TypeInfo, w/o it we'll check for the TypeInfo (via IProvideClassInfo or via IDispatch) and then try IDispatch if that fails. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Martin Sent: Tuesday, October 02, 2007 7:35 AM To: Discussion of IronPython Subject: [IronPython] -X:PreferComDispatch Hi, Can anyone eleaborate a bit more on the -X:PreferComDispatch option? Does it mean extended support for standard libraries? What does the prefer part stand for as in prefer com over what? BR Martin _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From leculver at microsoft.com Tue Oct 2 18:54:54 2007 From: leculver at microsoft.com (Lee Culver) Date: Tue, 2 Oct 2007 09:54:54 -0700 Subject: [IronPython] -X:PreferComDispatch In-Reply-To: <7AD436E4270DD54A94238001769C2227CCBD18D5D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C2227CCBD18D5D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <6512F99DEFF77C418E6738CE6E12FD4E5BB720A2B6@NA-EXMSG-C105.redmond.corp.microsoft.com> Interesting. Which of the two is "better"? Is there a performance tradeoff turning it on or off with COM objects which do or do not implement IDispatch? Thanks, -Lee -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, October 02, 2007 8:56 AM To: Discussion of IronPython Subject: Re: [IronPython] -X:PreferComDispatch This enables using new support for COM objects that uses COM's IDispatch interface instead of trying to get a TypeInfo for the object and use that to invoke it. With it enabled we'll first check for IDispatch then to see if we can get the TypeInfo, w/o it we'll check for the TypeInfo (via IProvideClassInfo or via IDispatch) and then try IDispatch if that fails. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Martin Sent: Tuesday, October 02, 2007 7:35 AM To: Discussion of IronPython Subject: [IronPython] -X:PreferComDispatch Hi, Can anyone eleaborate a bit more on the -X:PreferComDispatch option? Does it mean extended support for standard libraries? What does the prefer part stand for as in prefer com over what? BR Martin _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Tue Oct 2 22:12:06 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 2 Oct 2007 13:12:06 -0700 Subject: [IronPython] -X:PreferComDispatch In-Reply-To: <6512F99DEFF77C418E6738CE6E12FD4E5BB720A2B6@NA-EXMSG-C105.redmond.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C2227CCBD18D5D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <6512F99DEFF77C418E6738CE6E12FD4E5BB720A2B6@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <7AD436E4270DD54A94238001769C2227CCBD5EF218@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I pinged the dev who's been working on this (he's actually on another team), here's the response I got: We have not done comprehensive performance tests to find out differences between the two. Some time ago I tried to put a timer into test_cominterop.py where it iterated through an Excel 20x20 table and set values to it. In this test IDispatch-based calls turned out to be a bit faster. Which of the two is better? IDispatch based implementation requires TypeLibs, while the other approach would need to have Interop Assemblies deployed. So, from this perspective IDispatch-based option is more flexible (although there is still a long road to have full fidelity between the two). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Lee Culver Sent: Tuesday, October 02, 2007 9:55 AM To: Discussion of IronPython Subject: Re: [IronPython] -X:PreferComDispatch Interesting. Which of the two is "better"? Is there a performance tradeoff turning it on or off with COM objects which do or do not implement IDispatch? Thanks, -Lee -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, October 02, 2007 8:56 AM To: Discussion of IronPython Subject: Re: [IronPython] -X:PreferComDispatch This enables using new support for COM objects that uses COM's IDispatch interface instead of trying to get a TypeInfo for the object and use that to invoke it. With it enabled we'll first check for IDispatch then to see if we can get the TypeInfo, w/o it we'll check for the TypeInfo (via IProvideClassInfo or via IDispatch) and then try IDispatch if that fails. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Martin Sent: Tuesday, October 02, 2007 7:35 AM To: Discussion of IronPython Subject: [IronPython] -X:PreferComDispatch Hi, Can anyone eleaborate a bit more on the -X:PreferComDispatch option? Does it mean extended support for standard libraries? What does the prefer part stand for as in prefer com over what? BR Martin _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From daftspaniel at gmail.com Tue Oct 2 22:49:47 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Tue, 2 Oct 2007 21:49:47 +0100 Subject: [IronPython] INI File For IronPython In-Reply-To: <785694cd0710012233l39ca89cfm398594afa66b69fd@mail.gmail.com> References: <20253b0c0710011452r39145030p17db93d4f9988a87@mail.gmail.com> <785694cd0710012233l39ca89cfm398594afa66b69fd@mail.gmail.com> Message-ID: <20253b0c0710021349g314aa6bfw81c9659f19bd7b25@mail.gmail.com> On 10/2/07, JoeSox wrote: > Feel free to look at pswrdgeniron (IronPython GUI for pswrdgen). > http://www.codeproject.com/useritems/pswrdgeniron.asp > The module opens itself and reads in the first few lines, which each > setting is defined in order on a line. I used format of > "VARNAME::value" with the value encoded as a string so it is easy to > split and assign to a self.VARNAME. From there it's easy to bridge to > IronPython. Interesting - reminds me of Pythoncard's resource file. Well a little :-) > Why not just use ConfigObj ? I am using ConfigObj :-) Just considering losing the CPython dependency if there was a drop-in DotNet replacement... Cheers, Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From daftspaniel at gmail.com Tue Oct 2 22:38:13 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Tue, 2 Oct 2007 21:38:13 +0100 Subject: [IronPython] INI File For IronPython In-Reply-To: <735AC5A411C8A14498A8E7C129FCFADB0710477FED@119565-MAIL1.northps.com> References: <20253b0c0710011452r39145030p17db93d4f9988a87@mail.gmail.com> <735AC5A411C8A14498A8E7C129FCFADB0710477FED@119565-MAIL1.northps.com> Message-ID: <20253b0c0710021338h54d62230we6b74b984d1773e4@mail.gmail.com> On 10/1/07, Andrew Schaeffer wrote: > Use .NET app.config file. Thanks for this Andrew. Works well for read-only stuff. Limitation for me is the need for a exe. To get the following example to work you need a ipy.exe.config IronPython console: IronPython 2.0A4 (2.0.10904.02) on .NET 2.0.50727.312 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference("System.Configuration") >>> from System.Configuration import * >>> print ConfigurationManager.AppSettings["Title"] Watcher Cheers, Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From fuzzyman at voidspace.org.uk Wed Oct 3 00:00:20 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 02 Oct 2007 23:00:20 +0100 Subject: [IronPython] [python] Re: INI File For IronPython In-Reply-To: <20253b0c0710021349g314aa6bfw81c9659f19bd7b25@mail.gmail.com> References: <20253b0c0710011452r39145030p17db93d4f9988a87@mail.gmail.com> <785694cd0710012233l39ca89cfm398594afa66b69fd@mail.gmail.com> <20253b0c0710021349g314aa6bfw81c9659f19bd7b25@mail.gmail.com> Message-ID: <4702BF74.7040909@voidspace.org.uk> Davy Mitchell wrote: > On 10/2/07, JoeSox wrote: > >> Feel free to look at pswrdgeniron (IronPython GUI for pswrdgen). >> http://www.codeproject.com/useritems/pswrdgeniron.asp >> The module opens itself and reads in the first few lines, which each >> setting is defined in order on a line. I used format of >> "VARNAME::value" with the value encoded as a string so it is easy to >> split and assign to a self.VARNAME. From there it's easy to bridge to >> IronPython. >> > > Interesting - reminds me of Pythoncard's resource file. Well a little :-) > > >> Why not just use ConfigObj ? >> > > I am using ConfigObj :-) Just considering losing the CPython > dependency if there was a drop-in DotNet replacement... > I mean that ConfigObj should work with IronPython - if it doesn't I'll fix it. Michael > Cheers, > Davy > > From daftspaniel at gmail.com Wed Oct 3 00:12:50 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Tue, 2 Oct 2007 23:12:50 +0100 Subject: [IronPython] [python] Re: INI File For IronPython In-Reply-To: <4702BF74.7040909@voidspace.org.uk> References: <20253b0c0710011452r39145030p17db93d4f9988a87@mail.gmail.com> <785694cd0710012233l39ca89cfm398594afa66b69fd@mail.gmail.com> <20253b0c0710021349g314aa6bfw81c9659f19bd7b25@mail.gmail.com> <4702BF74.7040909@voidspace.org.uk> Message-ID: <20253b0c0710021512g8b7c443v2923426b660c28@mail.gmail.com> On 10/2/07, Michael Foord wrote: > I mean that ConfigObj should work with IronPython - if it doesn't I'll > fix it. It is working great with IP :-) Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From daftspaniel at gmail.com Wed Oct 3 00:17:29 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Tue, 2 Oct 2007 23:17:29 +0100 Subject: [IronPython] Bug in Alpha4 with __class__.__name__ ? Message-ID: <20253b0c0710021517g7c3b80aeg60480834b3390bd9@mail.gmail.com> IronPython console: IronPython 2.0A4 (2.0.10904.02) on .NET 2.0.50727.31 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference("System.Windows.Forms") >>> from System.Windows.Forms import * >>> control = TextBox() >>> print control.__class__.__name__ Traceback (most recent call last): File , line 0, in ##19 File , line 0, in _stub_##21 AttributeError: 'DynamicTypeTypeSlot' object has no attribute '__name__' IronPython console: IronPython 2.0A3 (2.0.10724.00) on .NET 2.0.50727.312 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference("System.Windows.Forms") >>> from System.Windows.Forms import * >>> control = TextBox() >>> print control.__class__.__name__ TextBox Cheers, Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From sh at defuze.org Wed Oct 3 00:18:44 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Tue, 02 Oct 2007 16:18:44 -0600 Subject: [IronPython] Any news about the next release? Message-ID: <4702C3C4.6030002@defuze.org> Hi all, I was wondering if there was any news about the next available release? Will it be a beta or still an alpha? When may we expect it? Just to feed my curiosity :) Thanks, - Sylvain From dfugate at microsoft.com Wed Oct 3 00:28:22 2007 From: dfugate at microsoft.com (Dave Fugate) Date: Tue, 2 Oct 2007 15:28:22 -0700 Subject: [IronPython] Bug in Alpha4 with __class__.__name__ ? In-Reply-To: <20253b0c0710021517g7c3b80aeg60480834b3390bd9@mail.gmail.com> References: <20253b0c0710021517g7c3b80aeg60480834b3390bd9@mail.gmail.com> Message-ID: <7346A825E148B049A9AD1D3ED46A2D91169A9DBE55@NA-EXMSG-C106.redmond.corp.microsoft.com> Thanks for the report Davy. Looks like it's been fixed with some recent changes in the last month (see below), but I'll be sure to add a test against this. E:\ >ipy IronPython console: IronPython 2.0 (2.0.0.00) on .NET 2.0.50727.1416 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference("System.Windows.Forms") >>> from System.Windows.Forms import * >>> control = TextBox() >>> print control.__class__.__name__ TextBox >>> Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Tuesday, October 02, 2007 3:17 PM To: Discussion of IronPython Subject: [IronPython] Bug in Alpha4 with __class__.__name__ ? IronPython console: IronPython 2.0A4 (2.0.10904.02) on .NET 2.0.50727.31 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference("System.Windows.Forms") >>> from System.Windows.Forms import * >>> control = TextBox() >>> print control.__class__.__name__ Traceback (most recent call last): File , line 0, in ##19 File , line 0, in _stub_##21 AttributeError: 'DynamicTypeTypeSlot' object has no attribute '__name__' IronPython console: IronPython 2.0A3 (2.0.10724.00) on .NET 2.0.50727.312 Copyright (c) Microsoft Corporation. All rights reserved. >>> import clr >>> clr.AddReference("System.Windows.Forms") >>> from System.Windows.Forms import * >>> control = TextBox() >>> print control.__class__.__name__ TextBox Cheers, Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dfugate at microsoft.com Wed Oct 3 00:42:11 2007 From: dfugate at microsoft.com (Dave Fugate) Date: Tue, 2 Oct 2007 15:42:11 -0700 Subject: [IronPython] Any news about the next release? In-Reply-To: <4702C3C4.6030002@defuze.org> References: <4702C3C4.6030002@defuze.org> Message-ID: <7346A825E148B049A9AD1D3ED46A2D91169A9DBE77@NA-EXMSG-C106.redmond.corp.microsoft.com> Hi, IronPython 2.0 Alpha 5 will be released after we wrap up work on a number of high priority bug fixes. This is scheduled to be completed at the end of this week which means it's likely 2.0A5 will become available sometime next week. Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch Sent: Tuesday, October 02, 2007 3:19 PM To: users at lists.ironpython.com Subject: [IronPython] Any news about the next release? Hi all, I was wondering if there was any news about the next available release? Will it be a beta or still an alpha? When may we expect it? Just to feed my curiosity :) Thanks, - Sylvain _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From kf9150 at gmail.com Wed Oct 3 00:45:00 2007 From: kf9150 at gmail.com (Kelie) Date: Tue, 2 Oct 2007 12:45:00 -1000 Subject: [IronPython] word wrap problem with posts from this newsgroup Message-ID: <42b9a3ff0710021545v208fa6es7053e5e70cdc195b@mail.gmail.com> hello, why many posts in this newsgroup don't wrap properly in browser? tried both ie and firefox and had the same problem. so i had to drag the horizontal scroll bar when viewing posts. is it just me? thanks. -- Kelie From fuzzyman at voidspace.org.uk Wed Oct 3 00:45:30 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 02 Oct 2007 23:45:30 +0100 Subject: [IronPython] [python] Re: Any news about the next release? In-Reply-To: <7346A825E148B049A9AD1D3ED46A2D91169A9DBE77@NA-EXMSG-C106.redmond.corp.microsoft.com> References: <4702C3C4.6030002@defuze.org> <7346A825E148B049A9AD1D3ED46A2D91169A9DBE77@NA-EXMSG-C106.redmond.corp.microsoft.com> Message-ID: <4702CA0A.8050703@voidspace.org.uk> Dave Fugate wrote: > Hi, IronPython 2.0 Alpha 5 will be released after we wrap up work on a number of high priority bug fixes. This is scheduled to be completed at the end of this week which means it's likely 2.0A5 will become available sometime next week. > And what about 1.1.1 ? Some of us are still using the stable release... ;-) Michael > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch > Sent: Tuesday, October 02, 2007 3:19 PM > To: users at lists.ironpython.com > Subject: [IronPython] Any news about the next release? > > Hi all, > > I was wondering if there was any news about the next available release? > Will it be a beta or still an alpha? When may we expect it? > > Just to feed my curiosity :) > > Thanks, > - Sylvain > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From sh at defuze.org Wed Oct 3 00:47:58 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Tue, 02 Oct 2007 16:47:58 -0600 Subject: [IronPython] Any news about the next release? In-Reply-To: <7346A825E148B049A9AD1D3ED46A2D91169A9DBE77@NA-EXMSG-C106.redmond.corp.microsoft.com> References: <4702C3C4.6030002@defuze.org> <7346A825E148B049A9AD1D3ED46A2D91169A9DBE77@NA-EXMSG-C106.redmond.corp.microsoft.com> Message-ID: <4702CA9E.9080209@defuze.org> Oh sweet news. However, what is the big showstopper to become a beta? A fifth alpha means there must be something quite blocking down the line. /me hopes he'll manage to get it compiled with mono this time. - Sylvain Dave Fugate wrote: > Hi, IronPython 2.0 Alpha 5 will be released after we wrap up work on a number of high priority bug fixes. This is scheduled to be completed at the end of this week which means it's likely 2.0A5 will become available sometime next week. > > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch > Sent: Tuesday, October 02, 2007 3:19 PM > To: users at lists.ironpython.com > Subject: [IronPython] Any news about the next release? > > Hi all, > > I was wondering if there was any news about the next available release? > Will it be a beta or still an alpha? When may we expect it? > > Just to feed my curiosity :) > > Thanks, > - Sylvain > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Wed Oct 3 01:00:27 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 3 Oct 2007 08:00:27 +0900 Subject: [IronPython] Any news about the next release? In-Reply-To: <4702CA9E.9080209@defuze.org> References: <4702C3C4.6030002@defuze.org> <7346A825E148B049A9AD1D3ED46A2D91169A9DBE77@NA-EXMSG-C106.redmond.corp.microsoft.com> <4702CA9E.9080209@defuze.org> Message-ID: <5b0248170710021600g43c48fdas63935e80f97672df@mail.gmail.com> 2007/10/3, Sylvain Hellegouarch : > /me hopes he'll manage to get it compiled with mono this time. I forgot to mention this, but there is a Mono bug to track IronPython 2.0 Alpha x>1 (Alpha 1 compiles fine) compilation problem. https://bugzilla.novell.com/show_bug.cgi?id=325478 -- Seo Sanghyeon From dfugate at microsoft.com Wed Oct 3 01:46:59 2007 From: dfugate at microsoft.com (Dave Fugate) Date: Tue, 2 Oct 2007 16:46:59 -0700 Subject: [IronPython] [python] Re: Any news about the next release? In-Reply-To: <4702CA0A.8050703@voidspace.org.uk> References: <4702C3C4.6030002@defuze.org> <7346A825E148B049A9AD1D3ED46A2D91169A9DBE77@NA-EXMSG-C106.redmond.corp.microsoft.com> <4702CA0A.8050703@voidspace.org.uk> Message-ID: <7346A825E148B049A9AD1D3ED46A2D91169A9DBEEC@NA-EXMSG-C106.redmond.corp.microsoft.com> We've been focusing on improving the DLR since the release of IronPython 2.0 Alpha 1, and as such have had few resources to develop concrete plans for a 1.1.1 release. I know there are a few bugs you'd like to get fixed WRT 1.1 (None.__doc__, urllib support, etc). If people vote for these on CodePlex (adding comments that these are desired for 1.1.1) or even bring them up on this list, the priority for 1.1.1 would increase. Also, if you submit any new bugs pertaining to IronPython 1.1 please: * prepend "IronPython 1.1:" to the title * add a "" tag to help us search for them. Thanks, Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Tuesday, October 02, 2007 3:46 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Any news about the next release? Dave Fugate wrote: > Hi, IronPython 2.0 Alpha 5 will be released after we wrap up work on a number of high priority bug fixes. This is scheduled to be completed at the end of this week which means it's likely 2.0A5 will become available sometime next week. > And what about 1.1.1 ? Some of us are still using the stable release... ;-) Michael > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch > Sent: Tuesday, October 02, 2007 3:19 PM > To: users at lists.ironpython.com > Subject: [IronPython] Any news about the next release? > > Hi all, > > I was wondering if there was any news about the next available release? > Will it be a beta or still an alpha? When may we expect it? > > Just to feed my curiosity :) > > Thanks, > - Sylvain > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Wed Oct 3 01:53:27 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 03 Oct 2007 00:53:27 +0100 Subject: [IronPython] Default recursion limit Message-ID: <4702D9F7.5010905@voidspace.org.uk> Hello all, For IronPython the default recursion limit is maxint: 2147483647 This is too deep for .NET - and infinite recursion causes the process to be terminated with a stack overflow exception. You can fix this by calling "sys.setrecursionlimit(something)" with something sensible - but an unfeasibly large value as the default seems incorrect (?). There is a further performance related issue. Generally IronPython is much faster for recursion due to lower overhead in function calls. For recursion depths of about 5000 though, IronPython takes *much* longer to raise an error than CPython (about 10 seconds as opposed to half a second or less). Michael http://www.manning.com/foord From dfugate at microsoft.com Wed Oct 3 01:54:47 2007 From: dfugate at microsoft.com (Dave Fugate) Date: Tue, 2 Oct 2007 16:54:47 -0700 Subject: [IronPython] Any news about the next release? In-Reply-To: <4702CA9E.9080209@defuze.org> References: <4702C3C4.6030002@defuze.org> <7346A825E148B049A9AD1D3ED46A2D91169A9DBE77@NA-EXMSG-C106.redmond.corp.microsoft.com> <4702CA9E.9080209@defuze.org> Message-ID: <7346A825E148B049A9AD1D3ED46A2D91169A9DBEF6@NA-EXMSG-C106.redmond.corp.microsoft.com> The reason we've been releasing 2.0 as monthly alphas is that the Dynamic Language Runtime is still solidifying with improvements being made for IronRuby among other things. While we could release a single alpha (or two) a month prior to 2.0 beta 1, we like to integrate feedback from the community into IronPython frequently. Also, our team tries to follow the agile software development process (i.e., short release cycles). Last but definitely not least, we're aiming to be Python 2.5 compatible with IronPython 2.0 and we're not quite there yet. Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch Sent: Tuesday, October 02, 2007 3:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Any news about the next release? Oh sweet news. However, what is the big showstopper to become a beta? A fifth alpha means there must be something quite blocking down the line. /me hopes he'll manage to get it compiled with mono this time. - Sylvain Dave Fugate wrote: > Hi, IronPython 2.0 Alpha 5 will be released after we wrap up work on a number of high priority bug fixes. This is scheduled to be completed at the end of this week which means it's likely 2.0A5 will become available sometime next week. > > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch > Sent: Tuesday, October 02, 2007 3:19 PM > To: users at lists.ironpython.com > Subject: [IronPython] Any news about the next release? > > Hi all, > > I was wondering if there was any news about the next available release? > Will it be a beta or still an alpha? When may we expect it? > > Just to feed my curiosity :) > > Thanks, > - Sylvain > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Wed Oct 3 02:29:25 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 3 Oct 2007 09:29:25 +0900 Subject: [IronPython] word wrap problem with posts from this newsgroup In-Reply-To: <42b9a3ff0710021545v208fa6es7053e5e70cdc195b@mail.gmail.com> References: <42b9a3ff0710021545v208fa6es7053e5e70cdc195b@mail.gmail.com> Message-ID: <5b0248170710021729g6376f36cm5da22e3acc10469a@mail.gmail.com> 2007/10/3, Kelie : > why many posts in this newsgroup don't wrap properly in browser? tried > both ie and firefox and had the same problem. so i had to drag the > horizontal scroll bar when viewing posts. is it just me? No it isn't. I see the same problem. -- Seo Sanghyeon From sh at defuze.org Wed Oct 3 03:34:59 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Tue, 02 Oct 2007 19:34:59 -0600 Subject: [IronPython] Any news about the next release? In-Reply-To: <7346A825E148B049A9AD1D3ED46A2D91169A9DBEF6@NA-EXMSG-C106.redmond.corp.microsoft.com> References: <4702C3C4.6030002@defuze.org> <7346A825E148B049A9AD1D3ED46A2D91169A9DBE77@NA-EXMSG-C106.redmond.corp.microsoft.com> <4702CA9E.9080209@defuze.org> <7346A825E148B049A9AD1D3ED46A2D91169A9DBEF6@NA-EXMSG-C106.redmond.corp.microsoft.com> Message-ID: <4702F1C3.8060305@defuze.org> Thanks Dave for the much appreciate feedback. - Sylvain Dave Fugate wrote: > The reason we've been releasing 2.0 as monthly alphas is that the Dynamic Language Runtime is still solidifying with improvements being made for IronRuby among other things. While we could release a single alpha (or two) a month prior to 2.0 beta 1, we like to integrate feedback from the community into IronPython frequently. Also, our team tries to follow the agile software development process (i.e., short release cycles). Last but definitely not least, we're aiming to be Python 2.5 compatible with IronPython 2.0 and we're not quite there yet. > > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch > Sent: Tuesday, October 02, 2007 3:48 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Any news about the next release? > > Oh sweet news. > > However, what is the big showstopper to become a beta? A fifth alpha > means there must be something quite blocking down the line. > > /me hopes he'll manage to get it compiled with mono this time. > > - Sylvain > > Dave Fugate wrote: >> Hi, IronPython 2.0 Alpha 5 will be released after we wrap up work on a number of high priority bug fixes. This is scheduled to be completed at the end of this week which means it's likely 2.0A5 will become available sometime next week. >> >> Dave >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch >> Sent: Tuesday, October 02, 2007 3:19 PM >> To: users at lists.ironpython.com >> Subject: [IronPython] Any news about the next release? >> >> Hi all, >> >> I was wondering if there was any news about the next available release? >> Will it be a beta or still an alpha? When may we expect it? >> >> Just to feed my curiosity :) >> >> Thanks, >> - Sylvain >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From Kyle.Howland-Rose at aar.com.au Wed Oct 3 10:10:14 2007 From: Kyle.Howland-Rose at aar.com.au (Howland-Rose, Kyle) Date: Wed, 3 Oct 2007 18:10:14 +1000 Subject: [IronPython] Installing 3rd-party modules Message-ID: <032584705D18504AAD2498139856C9C605363297@SYDEXCVS1.aar.com.au> Hi All, A newb question (sorry). Can anyone point me to doco on how to install third-party modules to IronPython please? Or alternatively how to access modules installed to Python2.4. I am attempting to install simpleparse and egenix mx-base with no luck. Simpleparse has an exe and egenix an .msi. They install brilliantly to Python2.4. They work from there but I can't use them from IP. The IRONPYTHONPATH is set correctly but I guess that is not relevant here. Thanks, Kyle ************************************************************************ Allens Arthur Robinson online: http://www.aar.com.au This email is confidential and may be subject to legal or other professional privilege. It is also subject to copyright. If you have received it in error, confidentiality and privilege are not waived and you must not disclose or use the information in it. Please notify the sender by return email and delete it from your system. Any personal information in this email must be handled in accordance with the Privacy Act 1988 (Cth). ************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Wed Oct 3 10:40:22 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 3 Oct 2007 17:40:22 +0900 Subject: [IronPython] Installing 3rd-party modules In-Reply-To: <032584705D18504AAD2498139856C9C605363297@SYDEXCVS1.aar.com.au> References: <032584705D18504AAD2498139856C9C605363297@SYDEXCVS1.aar.com.au> Message-ID: <5b0248170710030140p5030f1e3n88b5384e67617d39@mail.gmail.com> 2007/10/3, Howland-Rose, Kyle : > I am attempting to install simpleparse and egenix mx-base with no luck. eGenix mxTextTools, a part of eGenix mxBase used by SimpleParse, is a C extension and won't work with IronPython unmodified. mxTextTools certainly is a fine piece of code that would be worth porting to .NET, but it isn't yet. For alternatives, I refer you to Python parsing tools list maintained by Ned Batchelder. http://nedbatchelder.com/text/python-parsers.html I believe Resolver Systems have used PLY with IronPython for parsing with good success. -- Seo Sanghyeon From storm.openmail at gmail.com Wed Oct 3 12:17:13 2007 From: storm.openmail at gmail.com (Martin) Date: Wed, 3 Oct 2007 12:17:13 +0200 Subject: [IronPython] -X:PreferComDispatch In-Reply-To: <7AD436E4270DD54A94238001769C2227CCBD5EF218@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C2227CCBD18D5D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <6512F99DEFF77C418E6738CE6E12FD4E5BB720A2B6@NA-EXMSG-C105.redmond.corp.microsoft.com> <7AD436E4270DD54A94238001769C2227CCBD5EF218@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: This might be a stupid question but does all this have any effect on the number of python standard libraries supported by IronPython. Reason I'm asking if IronPython doesn't require interop assemblies to access COM objects then the issue of supporting pythong standard libraries become atleast less of an issue? On 10/2/07, Dino Viehland wrote: > I pinged the dev who's been working on this (he's actually on another team), here's the response I got: > > We have not done comprehensive performance tests to find out differences between the two. Some time ago I tried to put a timer into test_cominterop.py where it iterated through an Excel 20x20 table and set values to it. In this test IDispatch-based calls turned out to be a bit faster. > > Which of the two is better? IDispatch based implementation requires TypeLibs, while the other approach would need to have Interop Assemblies deployed. So, from this perspective IDispatch-based option is more flexible (although there is still a long road to have full fidelity between the two). > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Lee Culver > Sent: Tuesday, October 02, 2007 9:55 AM > To: Discussion of IronPython > Subject: Re: [IronPython] -X:PreferComDispatch > > Interesting. Which of the two is "better"? Is there a performance tradeoff turning it on or off with COM objects which do or do not implement IDispatch? > > Thanks, > -Lee > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Tuesday, October 02, 2007 8:56 AM > To: Discussion of IronPython > Subject: Re: [IronPython] -X:PreferComDispatch > > This enables using new support for COM objects that uses COM's IDispatch interface instead of trying to get a TypeInfo for the object and use that to invoke it. With it enabled we'll first check for IDispatch then to see if we can get the TypeInfo, w/o it we'll check for the TypeInfo (via IProvideClassInfo or via IDispatch) and then try IDispatch if that fails. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Martin > Sent: Tuesday, October 02, 2007 7:35 AM > To: Discussion of IronPython > Subject: [IronPython] -X:PreferComDispatch > > Hi, > > Can anyone eleaborate a bit more on the -X:PreferComDispatch option? > > Does it mean extended support for standard libraries? What does the > prefer part stand for as in prefer com over what? > > BR > Martin > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From sanxiyn at gmail.com Wed Oct 3 12:21:34 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 3 Oct 2007 19:21:34 +0900 Subject: [IronPython] -X:PreferComDispatch In-Reply-To: References: <7AD436E4270DD54A94238001769C2227CCBD18D5D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <6512F99DEFF77C418E6738CE6E12FD4E5BB720A2B6@NA-EXMSG-C105.redmond.corp.microsoft.com> <7AD436E4270DD54A94238001769C2227CCBD5EF218@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <5b0248170710030321u1d8bd034qae6beda61a51f248@mail.gmail.com> 2007/10/3, Martin : > Reason I'm asking if IronPython doesn't require interop assemblies to > access COM objects then the issue of supporting pythong standard > libraries become atleast less of an issue? I can't see how two are related, given that Python standard library doesn't use COM. -- Seo Sanghyeon From curt at hagenlocher.org Wed Oct 3 14:30:00 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 3 Oct 2007 05:30:00 -0700 Subject: [IronPython] -X:PreferComDispatch In-Reply-To: <5b0248170710030321u1d8bd034qae6beda61a51f248@mail.gmail.com> References: <7AD436E4270DD54A94238001769C2227CCBD18D5D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <6512F99DEFF77C418E6738CE6E12FD4E5BB720A2B6@NA-EXMSG-C105.redmond.corp.microsoft.com> <7AD436E4270DD54A94238001769C2227CCBD5EF218@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <5b0248170710030321u1d8bd034qae6beda61a51f248@mail.gmail.com> Message-ID: > > 2007/10/3, Martin : > > Reason I'm asking if IronPython doesn't require interop assemblies to > > access COM objects then the issue of supporting pythong standard > > libraries become atleast less of an issue? There's "feature compatibility" (both products support COM) and "source compatibility" (my COM-using app runs unchanged under either CPython or IronPython). Whether or not feature compatibility is sufficient is presumably going to be up to the community and the way it votes for changes. On 10/3/07, Sanghyeon Seo wrote: > I can't see how two are related, given that Python standard library > doesn't use COM. There is COM support in the Pythonwin extensions. Some people might consider this to be part of the standard library under Windows, even though it's not an official part of Python. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchopard at cisco.com Wed Oct 3 14:56:15 2007 From: jchopard at cisco.com (Joanna Chopard (jchopard)) Date: Wed, 3 Oct 2007 14:56:15 +0200 Subject: [IronPython] 3rd party module: ldap Message-ID: Hi all, I'm trying to use ldap with ironpython. However, I've downloaded it from this site which installed ldap under C:/Python25/Lib/site-packages Now, after modifying sites.py in ironpython directory, I tried 'import ldap' but with no success. Does anybody have any idea if this should be working? And more generally, how do we use a 3rd party module from ironpython? Thanks for your help, Joanna -------------- next part -------------- An HTML attachment was scrubbed... URL: From sidnei at enfoldsystems.com Wed Oct 3 15:14:36 2007 From: sidnei at enfoldsystems.com (Sidnei da Silva) Date: Wed, 3 Oct 2007 10:14:36 -0300 Subject: [IronPython] 3rd party module: ldap In-Reply-To: References: Message-ID: I believe the ldap module is a C-based extension. Those are not supported by IronPython directly yet. There are some good ldap libraries in .NET though that you might want to use. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 From jchopard at cisco.com Wed Oct 3 15:21:45 2007 From: jchopard at cisco.com (Joanna Chopard (jchopard)) Date: Wed, 3 Oct 2007 15:21:45 +0200 Subject: [IronPython] 3rd party module: ldap In-Reply-To: Message-ID: Thanks Sidnei, for the response. Do you have any specific .NET library that I could use for accessing functions similar to ldap? I'm new to .NET programming, so I'm not too familiar what's available. Thanks in advance for any sharing, Joanna -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sidnei da Silva Sent: Wednesday, October 03, 2007 3:15 PM To: Discussion of IronPython Subject: Re: [IronPython] 3rd party module: ldap I believe the ldap module is a C-based extension. Those are not supported by IronPython directly yet. There are some good ldap libraries in .NET though that you might want to use. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From aschaeffer at northps.com Wed Oct 3 15:48:22 2007 From: aschaeffer at northps.com (Andrew Schaeffer) Date: Wed, 3 Oct 2007 09:48:22 -0400 Subject: [IronPython] 3rd party module: ldap In-Reply-To: References: Message-ID: <735AC5A411C8A14498A8E7C129FCFADB07104781AE@119565-MAIL1.northps.com> Novell provides a C# library for accessing ldap. From their website: "LDAP Libraries for C# enables you to write applications that access, manage, and update information stored in Novell eDirectory(r) or other LDAP-aware directories." http://forge.novell.com/modules/xfmod/project/?ldapcsharp Also, a company called LDAP Services has a robust library. www.ldapservices.com -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Joanna Chopard (jchopard) Sent: Wednesday, October 03, 2007 9:22 AM To: Discussion of IronPython Subject: Re: [IronPython] 3rd party module: ldap Thanks Sidnei, for the response. Do you have any specific .NET library that I could use for accessing functions similar to ldap? I'm new to .NET programming, so I'm not too familiar what's available. Thanks in advance for any sharing, Joanna -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sidnei da Silva Sent: Wednesday, October 03, 2007 3:15 PM To: Discussion of IronPython Subject: Re: [IronPython] 3rd party module: ldap I believe the ldap module is a C-based extension. Those are not supported by IronPython directly yet. There are some good ldap libraries in .NET though that you might want to use. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From graham.bloice at trihedral.com Wed Oct 3 16:18:56 2007 From: graham.bloice at trihedral.com (Graham Bloice) Date: Wed, 03 Oct 2007 15:18:56 +0100 Subject: [IronPython] 3rd party module: ldap In-Reply-To: References: Message-ID: <4703A4D0.8020602@trihedral.com> Joanna Chopard (jchopard) wrote: > Thanks Sidnei, for the response. > > Do you have any specific .NET library that I could use for accessing > functions similar to ldap? > I'm new to .NET programming, so I'm not too familiar what's available. > > Thanks in advance for any sharing, > The .net framework provides extensive directory services support. See http://msdn2.microsoft.com/en-us/library/system.directoryservices(vs.80).aspx -- Regards, Graham Bloice From dinov at exchange.microsoft.com Wed Oct 3 18:58:31 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 3 Oct 2007 09:58:31 -0700 Subject: [IronPython] word wrap problem with posts from this newsgroup In-Reply-To: <5b0248170710021729g6376f36cm5da22e3acc10469a@mail.gmail.com> References: <42b9a3ff0710021545v208fa6es7053e5e70cdc195b@mail.gmail.com> <5b0248170710021729g6376f36cm5da22e3acc10469a@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227CCBD5EF444@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Is there a pattern to it? For example is it people likely to be using Outlook who's mails aren't getting wrapped? :) (It tells me it's going to wrap at 76 columns when I send the mail to the internet but my own mails don't appear to wrap like that when I get them back). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Tuesday, October 02, 2007 5:29 PM To: Discussion of IronPython Subject: Re: [IronPython] word wrap problem with posts from this newsgroup 2007/10/3, Kelie : > why many posts in this newsgroup don't wrap properly in browser? tried > both ie and firefox and had the same problem. so i had to drag the > horizontal scroll bar when viewing posts. is it just me? No it isn't. I see the same problem. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Wed Oct 3 19:35:30 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 3 Oct 2007 10:35:30 -0700 Subject: [IronPython] Default recursion limit In-Reply-To: <4702D9F7.5010905@voidspace.org.uk> References: <4702D9F7.5010905@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C2227CCBD5EF46C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Ahh, stack overflow is fun... The special value of maxint actually means that we stop enforcing recursion altogether. Why did we pick that default? It's a combination of performance and our general thinking of stack overflow. We typically think of SO as programmer error and therefore choose to make the trade-off in terms of better performance vs. better stack overflow handling. Unfortunately it's hard to enforce a recursion limit and do so in a fast manner (it typically involves reading and writing a thread static which isn't that fast in .NET - we actually have a work-around for this which will work good for apps w/ a smaller number of threads, but it's still a significant slowdown). What would be ideal would be if .NET had good stack overflow handling but it's such a hard issue to get right that .NET only enables recovering from SO for advanced hosts (and even then it comes at the cost of losing your app domain). Finally if you don't like our decision it is only one command (or one command-line option) away from being changed. If people don't like this default we could consider changing it but there hasn't been much issue with this to date. The recursion issue is interesting. Somehow this is related to DynamicMethod's - if I run w/ -X:SaveAssemblies -X:StaticMethods this speeds up considerably (on my machine we go from ~3-4 seconds for 5000 frames to .08 or .03 seconds depending on -X:NoTraceback). I expected this to be related to traceback support - that forces us to emit a try/catch instead of a try/fault in a DynamicMethod - which means we catch & rethrow exceptions all the way up the stack and that's going to be horrible for performance. But enabling -X:NoTraceback no DynamicMethod's actually seems to make this go slower! So there's definitely something funky going on here. It might be an issue w/ throwing exceptions & DynamicMethod's inside of the CLR, or it might be something we're doing. I'll need to investigate it a little more. I've opened a low-priority bug to investigate this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13080). If you think that's the wrong priority let me know :) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Tuesday, October 02, 2007 4:53 PM To: Discussion of IronPython Subject: [IronPython] Default recursion limit Hello all, For IronPython the default recursion limit is maxint: 2147483647 This is too deep for .NET - and infinite recursion causes the process to be terminated with a stack overflow exception. You can fix this by calling "sys.setrecursionlimit(something)" with something sensible - but an unfeasibly large value as the default seems incorrect (?). There is a further performance related issue. Generally IronPython is much faster for recursion due to lower overhead in function calls. For recursion depths of about 5000 though, IronPython takes *much* longer to raise an error than CPython (about 10 seconds as opposed to half a second or less). Michael http://www.manning.com/foord _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Wed Oct 3 19:38:28 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 3 Oct 2007 10:38:28 -0700 Subject: [IronPython] [python] Re: Missing Compiler Flag In-Reply-To: <7AD436E4270DD54A94238001769C2227CC5D2AF282@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <46F421EE.4020806@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CC5D2AF1C2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <46F42834.1030003@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CC5D2AF1D5@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <46F43D56.3090806@voidspace.org.uk> <46F44017.1090106@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CC5D2AF282@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <7AD436E4270DD54A94238001769C2227CCBD5EF46F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> BTW the fix for this finally got checked in today (and therefore will be in the next release). We don't yet pass all of test_codeop but we now pass half of it - we still have some issues w/ test_incomplete and test_valid. But the flag is respected and appears to be doing the right thing now. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, September 21, 2007 4:20 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Missing Compiler Flag Awesome, thanks for tracking this down. I'll probably take a look at this next week. This might have also provided some insight into how the Python command line works - so maybe that can be improved as a well (I just fixed a couple of those bugs but I'm sure we've got more lurking out there). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, September 21, 2007 3:05 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Missing Compiler Flag Michael Foord wrote: > Hello Dino, > > I think I've got it. With this flag set, the compile function will > return None *if* an indented line would be valid. > *so*... compile only returns a code object if the source code is complete. An indented code block is only complete when there is a dedent that completes the block. PyCF_DONT_IMPLY_DEDENT is a 'parser flag' which says "don't imply a dedent at the end of a block until we actually get an explicit dedent". All the best, Michael http://www.ironpython.info/ > This allows the interactive interpreter to decide which prompt to > present the user with (and whether to execute the code it has buffered > or to wait for more input). > > For example (from CPython): > > PyCF_DONT_IMPLY_DEDENT = 0x200 > def _compile(source, filename, symbol): > return compile(source, filename, symbol, PyCF_DONT_IMPLY_DEDENT) > > source = 'def x():\n print x' > print _compile(source, 'test', 'single') > None > > Without the flag set returns a code object. > > There is similar code in the DLRConsole but it uses > "Microsoft.Scripting.SourceCodeUnit" which isn't present in 2.0a4. > > All the best, > > Michael > http://www.ironpython.info/ > > > Dino Viehland wrote: > >> Ok, I closed 12908 as a dup. If there's no info on it we can always try reverse engineering it (or see if test_codeop fails when we just ignore the flag instead of throwing - that might be the simplest thing to do). >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Friday, September 21, 2007 1:23 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] [python] Re: Missing Compiler Flag >> >> Dino Viehland wrote: >> >> >>> Strangely it doesn't seem to be in the documentation for compile() either :( >>> >>> Do you know what this option does by any chance :) ? >>> >>> I've opened bug #12908 >>> >>> >> Great - it can go with 12907. :-) >> >> It is something to do with dedenting. ;-) >> >> I can't find much about it on the intarwebz. It is defined in >> pythonrun.h and seems to be used in pythonrun.c and it is involved with >> parsing which makes sense. >> >> I'll try asking around. *sigh* >> >> Michael Foord >> http://www.manning.com/foord >> >> >> >>> (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=12908) so we at least have it tracked... >>> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >>> Sent: Friday, September 21, 2007 12:57 PM >>> To: Discussion of IronPython >>> Subject: [IronPython] Missing Compiler Flag >>> >>> Hello all, >>> >>> There's another problem with the interactive interpreter in IronPython >>> (it affects the ability to use the code standard library module). >>> >>> The PyCF_DONT_IMPLY_DEDENT compiler flag is not recognised in IronPython. >>> >>> The flag is defined in the 'codeop' standard library module: >>> >>> PyCF_DONT_IMPLY_DEDENT = 0x200 # Matches pythonrun.h >>> >>> Attempting to use this in IronPython: >>> >>> >>> compile('print x', 'test', 'single', 0x200, 1) >>> Traceback (most recent call last): >>> File , line 0, in ##1 >>> File , line 0, in Compile##4 >>> ValueError: unrecognized flags >>> >>> Without this flag the code module can't recognize blocks of code with >>> several indented lines. :-( >>> >>> All the best, >>> >>> >>> Michael Foord >>> http://www.manning.com/foord >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >>> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Wed Oct 3 20:22:19 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 03 Oct 2007 19:22:19 +0100 Subject: [IronPython] [python] Re: Missing Compiler Flag In-Reply-To: <7AD436E4270DD54A94238001769C2227CCBD5EF46F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <46F421EE.4020806@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CC5D2AF1C2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <46F42834.1030003@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CC5D2AF1D5@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <46F43D56.3090806@voidspace.org.uk> <46F44017.1090106@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CC5D2AF282@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <7AD436E4270DD54A94238001769C2227CCBD5EF46F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4703DDDB.6010002@voidspace.org.uk> Dino Viehland wrote: > BTW the fix for this finally got checked in today (and therefore will be in the next release). We don't yet pass all of test_codeop but we now pass half of it - we still have some issues w/ test_incomplete and test_valid. But the flag is respected and appears to be doing the right thing now. > That's really great news Dino. Thanks! > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Friday, September 21, 2007 4:20 PM > To: Discussion of IronPython > Subject: Re: [IronPython] [python] Re: Missing Compiler Flag > > Awesome, thanks for tracking this down. I'll probably take a look at this next week. This might have also provided some insight into how the Python command line works - so maybe that can be improved as a well (I just fixed a couple of those bugs but I'm sure we've got more lurking out there). > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, September 21, 2007 3:05 PM > To: Discussion of IronPython > Subject: Re: [IronPython] [python] Re: Missing Compiler Flag > > Michael Foord wrote: > >> Hello Dino, >> >> I think I've got it. With this flag set, the compile function will >> return None *if* an indented line would be valid. >> >> > > *so*... compile only returns a code object if the source code is > complete. An indented code block is only complete when there is a dedent > that completes the block. > > PyCF_DONT_IMPLY_DEDENT is a 'parser flag' which says "don't imply a > dedent at the end of a block until we actually get an explicit dedent". > > All the best, > > Michael > http://www.ironpython.info/ > > > > > >> This allows the interactive interpreter to decide which prompt to >> present the user with (and whether to execute the code it has buffered >> or to wait for more input). >> >> For example (from CPython): >> >> PyCF_DONT_IMPLY_DEDENT = 0x200 >> def _compile(source, filename, symbol): >> return compile(source, filename, symbol, PyCF_DONT_IMPLY_DEDENT) >> >> source = 'def x():\n print x' >> print _compile(source, 'test', 'single') >> None >> >> Without the flag set returns a code object. >> >> There is similar code in the DLRConsole but it uses >> "Microsoft.Scripting.SourceCodeUnit" which isn't present in 2.0a4. >> >> All the best, >> >> Michael >> http://www.ironpython.info/ >> >> >> Dino Viehland wrote: >> >> >>> Ok, I closed 12908 as a dup. If there's no info on it we can always try reverse engineering it (or see if test_codeop fails when we just ignore the flag instead of throwing - that might be the simplest thing to do). >>> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >>> Sent: Friday, September 21, 2007 1:23 PM >>> To: Discussion of IronPython >>> Subject: Re: [IronPython] [python] Re: Missing Compiler Flag >>> >>> Dino Viehland wrote: >>> >>> >>> >>>> Strangely it doesn't seem to be in the documentation for compile() either :( >>>> >>>> Do you know what this option does by any chance :) ? >>>> >>>> I've opened bug #12908 >>>> >>>> >>>> >>> Great - it can go with 12907. :-) >>> >>> It is something to do with dedenting. ;-) >>> >>> I can't find much about it on the intarwebz. It is defined in >>> pythonrun.h and seems to be used in pythonrun.c and it is involved with >>> parsing which makes sense. >>> >>> I'll try asking around. *sigh* >>> >>> Michael Foord >>> http://www.manning.com/foord >>> >>> >>> >>> >>>> (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=12908) so we at least have it tracked... >>>> >>>> -----Original Message----- >>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >>>> Sent: Friday, September 21, 2007 12:57 PM >>>> To: Discussion of IronPython >>>> Subject: [IronPython] Missing Compiler Flag >>>> >>>> Hello all, >>>> >>>> There's another problem with the interactive interpreter in IronPython >>>> (it affects the ability to use the code standard library module). >>>> >>>> The PyCF_DONT_IMPLY_DEDENT compiler flag is not recognised in IronPython. >>>> >>>> The flag is defined in the 'codeop' standard library module: >>>> >>>> PyCF_DONT_IMPLY_DEDENT = 0x200 # Matches pythonrun.h >>>> >>>> Attempting to use this in IronPython: >>>> >>>> >>> compile('print x', 'test', 'single', 0x200, 1) >>>> Traceback (most recent call last): >>>> File , line 0, in ##1 >>>> File , line 0, in Compile##4 >>>> ValueError: unrecognized flags >>>> >>>> Without this flag the code module can't recognize blocks of code with >>>> several indented lines. :-( >>>> >>>> All the best, >>>> >>>> >>>> Michael Foord >>>> http://www.manning.com/foord >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.ironpython.com >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.ironpython.com >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >>> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From daftspaniel at gmail.com Wed Oct 3 21:07:48 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Wed, 3 Oct 2007 20:07:48 +0100 Subject: [IronPython] Bug in Alpha4 with __class__.__name__ ? In-Reply-To: <7346A825E148B049A9AD1D3ED46A2D91169A9DBE55@NA-EXMSG-C106.redmond.corp.microsoft.com> References: <20253b0c0710021517g7c3b80aeg60480834b3390bd9@mail.gmail.com> <7346A825E148B049A9AD1D3ED46A2D91169A9DBE55@NA-EXMSG-C106.redmond.corp.microsoft.com> Message-ID: <20253b0c0710031207r5af18a83td724469781dd3b76@mail.gmail.com> Thanks Dave - looking forward to the next release :-) Davy On 10/2/07, Dave Fugate wrote: > Thanks for the report Davy. Looks like it's been fixed with some recent changes in the last month (see below), but I'll be sure to add a test against this. > > E:\ >ipy > IronPython console: IronPython 2.0 (2.0.0.00) on .NET 2.0.50727.1416 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import clr > >>> clr.AddReference("System.Windows.Forms") > >>> from System.Windows.Forms import * > >>> control = TextBox() > >>> print control.__class__.__name__ > TextBox > >>> > > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell > Sent: Tuesday, October 02, 2007 3:17 PM > To: Discussion of IronPython > Subject: [IronPython] Bug in Alpha4 with __class__.__name__ ? > > IronPython console: IronPython 2.0A4 (2.0.10904.02) on .NET 2.0.50727.31 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import clr > >>> clr.AddReference("System.Windows.Forms") > >>> from System.Windows.Forms import * > >>> control = TextBox() > >>> print control.__class__.__name__ > Traceback (most recent call last): > File , line 0, in ##19 > File , line 0, in _stub_##21 > AttributeError: 'DynamicTypeTypeSlot' object has no attribute '__name__' > > IronPython console: IronPython 2.0A3 (2.0.10724.00) on .NET 2.0.50727.312 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> import clr > >>> clr.AddReference("System.Windows.Forms") > >>> from System.Windows.Forms import * > >>> control = TextBox() > >>> print control.__class__.__name__ > TextBox > > Cheers, > Davy > > -- > Davy Mitchell > Blog - http://www.latedecember.co.uk/sites/personal/davy/ > Twitter - http://twitter.com/daftspaniel > Skype - daftspaniel > needgod.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From fuzzyman at voidspace.org.uk Wed Oct 3 23:14:46 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 03 Oct 2007 22:14:46 +0100 Subject: [IronPython] [python] Re: Default recursion limit In-Reply-To: <7AD436E4270DD54A94238001769C2227CCBD5EF46C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <4702D9F7.5010905@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CCBD5EF46C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <47040646.4020205@voidspace.org.uk> Dino Viehland wrote: > Ahh, stack overflow is fun... The special value of maxint actually means that we stop enforcing recursion altogether. > > Why did we pick that default? It's a combination of performance and our general thinking of stack overflow. We typically think of SO as programmer error and therefore choose to make the trade-off in terms of better performance vs. better stack overflow handling. Unfortunately it's hard to enforce a recursion limit and do so in a fast manner (it typically involves reading and writing a thread static which isn't that fast in .NET - we actually have a work-around for this which will work good for apps w/ a smaller number of threads, but it's still a significant slowdown). What would be ideal would be if .NET had good stack overflow handling but it's such a hard issue to get right that .NET only enables recovering from SO for advanced hosts (and even then it comes at the cost of losing your app domain). > > Finally if you don't like our decision it is only one command (or one command-line option) away from being changed. If people don't like this default we could consider changing it but there hasn't been much issue with this to date. > > The recursion issue is interesting. Somehow this is related to DynamicMethod's - if I run w/ -X:SaveAssemblies -X:StaticMethods this speeds up considerably (on my machine we go from ~3-4 seconds for 5000 frames to .08 or .03 seconds depending on -X:NoTraceback). > > Interesting (it takes about 10 seconds on my machine at the interactive interpreter). What does '-X:StaticMethods' do? So setting a recursionlimit will generally reduce performance? (Our performance tests still pass - so it doesn't look like this is a major issue for us). Thanks Dino Michael http://www.manning.com/foord > I expected this to be related to traceback support - that forces us to emit a try/catch instead of a try/fault in a DynamicMethod - which means we catch & rethrow exceptions all the way up the stack and that's going to be horrible for performance. But enabling -X:NoTraceback no DynamicMethod's actually seems to make this go slower! > > So there's definitely something funky going on here. It might be an issue w/ throwing exceptions & DynamicMethod's inside of the CLR, or it might be something we're doing. I'll need to investigate it a little more. I've opened a low-priority bug to investigate this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13080). If you think that's the wrong priority let me know :) > > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Tuesday, October 02, 2007 4:53 PM > To: Discussion of IronPython > Subject: [IronPython] Default recursion limit > > Hello all, > > For IronPython the default recursion limit is maxint: 2147483647 > > This is too deep for .NET - and infinite recursion causes the process to > be terminated with a stack overflow exception. > > You can fix this by calling "sys.setrecursionlimit(something)" with > something sensible - but an unfeasibly large value as the default seems > incorrect (?). > > There is a further performance related issue. Generally IronPython is > much faster for recursion due to lower overhead in function calls. For > recursion depths of about 5000 though, IronPython takes *much* longer to > raise an error than CPython (about 10 seconds as opposed to half a > second or less). > > Michael > http://www.manning.com/foord > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From dinov at exchange.microsoft.com Wed Oct 3 23:54:26 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 3 Oct 2007 14:54:26 -0700 Subject: [IronPython] [python] Re: Default recursion limit In-Reply-To: <47040646.4020205@voidspace.org.uk> References: <4702D9F7.5010905@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CCBD5EF46C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47040646.4020205@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C2227CCBD5EF5C0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> -X:StaticMethods causes us to never use DynamicMethod's. It's really more of a debugging tool than anything else. The problem w/ DynamicMethods is that they are completely undebuggable. You don't get line number information from them, you can't see the IL of them, and you can't verify the IL by saving it to disk. So we can switch into StaticMethods mode and get all of this dumped out and see what's going wrong in the code. The downside is that we can't generate just a method - we have to generate an entire type. And that entire type is then not collectible by the GC so we leak memory. Yep, so on my machine I see around a ~15% degrade on Pystone. It probably is a function of how many function's you're calling and how much work they do, but there's definitely a cost associated with it. And that cost will rise if you go above ~20 threads or so when the one optimization to make this faster stops working on the higher #'d threads. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Wednesday, October 03, 2007 2:15 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Default recursion limit Dino Viehland wrote: > Ahh, stack overflow is fun... The special value of maxint actually means that we stop enforcing recursion altogether. > > Why did we pick that default? It's a combination of performance and our general thinking of stack overflow. We typically think of SO as programmer error and therefore choose to make the trade-off in terms of better performance vs. better stack overflow handling. Unfortunately it's hard to enforce a recursion limit and do so in a fast manner (it typically involves reading and writing a thread static which isn't that fast in .NET - we actually have a work-around for this which will work good for apps w/ a smaller number of threads, but it's still a significant slowdown). What would be ideal would be if .NET had good stack overflow handling but it's such a hard issue to get right that .NET only enables recovering from SO for advanced hosts (and even then it comes at the cost of losing your app domain). > > Finally if you don't like our decision it is only one command (or one command-line option) away from being changed. If people don't like this default we could consider changing it but there hasn't been much issue with this to date. > > The recursion issue is interesting. Somehow this is related to DynamicMethod's - if I run w/ -X:SaveAssemblies -X:StaticMethods this speeds up considerably (on my machine we go from ~3-4 seconds for 5000 frames to .08 or .03 seconds depending on -X:NoTraceback). > > Interesting (it takes about 10 seconds on my machine at the interactive interpreter). What does '-X:StaticMethods' do? So setting a recursionlimit will generally reduce performance? (Our performance tests still pass - so it doesn't look like this is a major issue for us). Thanks Dino Michael http://www.manning.com/foord > I expected this to be related to traceback support - that forces us to emit a try/catch instead of a try/fault in a DynamicMethod - which means we catch & rethrow exceptions all the way up the stack and that's going to be horrible for performance. But enabling -X:NoTraceback no DynamicMethod's actually seems to make this go slower! > > So there's definitely something funky going on here. It might be an issue w/ throwing exceptions & DynamicMethod's inside of the CLR, or it might be something we're doing. I'll need to investigate it a little more. I've opened a low-priority bug to investigate this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13080). If you think that's the wrong priority let me know :) > > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Tuesday, October 02, 2007 4:53 PM > To: Discussion of IronPython > Subject: [IronPython] Default recursion limit > > Hello all, > > For IronPython the default recursion limit is maxint: 2147483647 > > This is too deep for .NET - and infinite recursion causes the process to > be terminated with a stack overflow exception. > > You can fix this by calling "sys.setrecursionlimit(something)" with > something sensible - but an unfeasibly large value as the default seems > incorrect (?). > > There is a further performance related issue. Generally IronPython is > much faster for recursion due to lower overhead in function calls. For > recursion depths of about 5000 though, IronPython takes *much* longer to > raise an error than CPython (about 10 seconds as opposed to half a > second or less). > > Michael > http://www.manning.com/foord > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Wed Oct 3 23:58:12 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 03 Oct 2007 22:58:12 +0100 Subject: [IronPython] [python] Re: Default recursion limit In-Reply-To: <7AD436E4270DD54A94238001769C2227CCBD5EF5C0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <4702D9F7.5010905@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CCBD5EF46C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47040646.4020205@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CCBD5EF5C0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <47041074.3070403@voidspace.org.uk> Dino Viehland wrote: > -X:StaticMethods causes us to never use DynamicMethod's. It's really more of a debugging tool than anything else. The problem w/ DynamicMethods is that they are completely undebuggable. You don't get line number information from them, you can't see the IL of them, and you can't verify the IL by saving it to disk. So we can switch into StaticMethods mode and get all of this dumped out and see what's going wrong in the code. > > The downside is that we can't generate just a method - we have to generate an entire type. And that entire type is then not collectible by the GC so we leak memory. > > Yep, so on my machine I see around a ~15% degrade on Pystone. It probably is a function of how many function's you're calling and how much work they do, but there's definitely a cost associated with it. And that cost will rise if you go above ~20 threads or so when the one optimization to make this faster stops working on the higher #'d threads. > Ok - thanks Dino. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Wednesday, October 03, 2007 2:15 PM > To: Discussion of IronPython > Subject: Re: [IronPython] [python] Re: Default recursion limit > > Dino Viehland wrote: > >> Ahh, stack overflow is fun... The special value of maxint actually means that we stop enforcing recursion altogether. >> >> Why did we pick that default? It's a combination of performance and our general thinking of stack overflow. We typically think of SO as programmer error and therefore choose to make the trade-off in terms of better performance vs. better stack overflow handling. Unfortunately it's hard to enforce a recursion limit and do so in a fast manner (it typically involves reading and writing a thread static which isn't that fast in .NET - we actually have a work-around for this which will work good for apps w/ a smaller number of threads, but it's still a significant slowdown). What would be ideal would be if .NET had good stack overflow handling but it's such a hard issue to get right that .NET only enables recovering from SO for advanced hosts (and even then it comes at the cost of losing your app domain). >> >> Finally if you don't like our decision it is only one command (or one command-line option) away from being changed. If people don't like this default we could consider changing it but there hasn't been much issue with this to date. >> >> The recursion issue is interesting. Somehow this is related to DynamicMethod's - if I run w/ -X:SaveAssemblies -X:StaticMethods this speeds up considerably (on my machine we go from ~3-4 seconds for 5000 frames to .08 or .03 seconds depending on -X:NoTraceback). >> >> >> > > Interesting (it takes about 10 seconds on my machine at the interactive > interpreter). > > What does '-X:StaticMethods' do? > > So setting a recursionlimit will generally reduce performance? (Our > performance tests still pass - so it doesn't look like this is a major > issue for us). > > Thanks Dino > > Michael > http://www.manning.com/foord > > >> I expected this to be related to traceback support - that forces us to emit a try/catch instead of a try/fault in a DynamicMethod - which means we catch & rethrow exceptions all the way up the stack and that's going to be horrible for performance. But enabling -X:NoTraceback no DynamicMethod's actually seems to make this go slower! >> >> So there's definitely something funky going on here. It might be an issue w/ throwing exceptions & DynamicMethod's inside of the CLR, or it might be something we're doing. I'll need to investigate it a little more. I've opened a low-priority bug to investigate this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13080). If you think that's the wrong priority let me know :) >> >> >> >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Tuesday, October 02, 2007 4:53 PM >> To: Discussion of IronPython >> Subject: [IronPython] Default recursion limit >> >> Hello all, >> >> For IronPython the default recursion limit is maxint: 2147483647 >> >> This is too deep for .NET - and infinite recursion causes the process to >> be terminated with a stack overflow exception. >> >> You can fix this by calling "sys.setrecursionlimit(something)" with >> something sensible - but an unfeasibly large value as the default seems >> incorrect (?). >> >> There is a further performance related issue. Generally IronPython is >> much faster for recursion due to lower overhead in function calls. For >> recursion depths of about 5000 though, IronPython takes *much* longer to >> raise an error than CPython (about 10 seconds as opposed to half a >> second or less). >> >> Michael >> http://www.manning.com/foord >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From sanxiyn at gmail.com Thu Oct 4 01:11:31 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 4 Oct 2007 08:11:31 +0900 Subject: [IronPython] 3rd party module: ldap In-Reply-To: References: Message-ID: <5b0248170710031611r2f9e491bt956c7e820465a319@mail.gmail.com> 2007/10/3, Joanna Chopard (jchopard) : > Do you have any specific .NET library that I could use for accessing > functions similar to ldap? As someone else already mentioned, Novell's LDAP library is a good bet. Novell.Directory.Ldap documentation http://www.go-mono.com/docs/index.aspx?link=N:Novell.Directory.Ldap If you want to see the library used in real programs, try LAT(LDAP Administration Tool) with Gtk# user interface. http://dev.mmgsecurity.com/projects/lat/ -- Seo Sanghyeon From anakinnani at hotmail.com Thu Oct 4 18:29:50 2007 From: anakinnani at hotmail.com (jane janet) Date: Thu, 4 Oct 2007 16:29:50 +0000 Subject: [IronPython] IPEndPoint Message-ID: Hello all, Please help me. I want to know how to do type casting from Socket.RemoteEndPoint to IPEndPoint. I 've no idea with these. Thank you for all help. All the best. _________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Fri Oct 5 02:42:36 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 5 Oct 2007 09:42:36 +0900 Subject: [IronPython] Compilation error Message-ID: <5b0248170710041742j42e3fa0av1504df1d45ea2de3@mail.gmail.com> With latest Mono with some local changes (sorry that means you won't be able to reproduce this) I get compilation error with latest IronPython from CodePlex. IronPython/Runtime/Types/ComDispatch/DispCallable.cs(42,21): error CS0177: The out parameter `parameterModifiers' must be assigned to before control leaves the current method Indeed, in IronPython.Runtime.Types.ComDispatch.GetArgsForCall, the out parameter is never assigned if it returns early because countOfArgs is zero. Doesn't csc catch this? If so that would be a csc bug I think. A trivial fix is available from FePy SVN has patch-cs0177. https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/latest/ -- Seo Sanghyeon From dinov at exchange.microsoft.com Fri Oct 5 02:55:00 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 4 Oct 2007 17:55:00 -0700 Subject: [IronPython] Compilation error In-Reply-To: <5b0248170710041742j42e3fa0av1504df1d45ea2de3@mail.gmail.com> References: <5b0248170710041742j42e3fa0av1504df1d45ea2de3@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227CCBD231097@DF-GRTDANE-MSG.exchange.corp.microsoft.com> It looks like csc doesn't require out params to be assigned if they're value types: class foo { public struct baz { } public object []bar(object[]args, out baz x) { return args; } } But it properly enforces it if it's an int, a DateTime, or a decimal. I'll let them know. ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo [sanxiyn at gmail.com] Sent: Thursday, October 04, 2007 5:42 PM To: Discussion of IronPython Subject: [IronPython] Compilation error With latest Mono with some local changes (sorry that means you won't be able to reproduce this) I get compilation error with latest IronPython from CodePlex. IronPython/Runtime/Types/ComDispatch/DispCallable.cs(42,21): error CS0177: The out parameter `parameterModifiers' must be assigned to before control leaves the current method Indeed, in IronPython.Runtime.Types.ComDispatch.GetArgsForCall, the out parameter is never assigned if it returns early because countOfArgs is zero. Doesn't csc catch this? If so that would be a csc bug I think. A trivial fix is available from FePy SVN has patch-cs0177. https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/latest/ -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Fri Oct 5 03:16:22 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 5 Oct 2007 10:16:22 +0900 Subject: [IronPython] Compilation error In-Reply-To: <7AD436E4270DD54A94238001769C2227CCBD231097@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <5b0248170710041742j42e3fa0av1504df1d45ea2de3@mail.gmail.com> <7AD436E4270DD54A94238001769C2227CCBD231097@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <5b0248170710041816i42e7ad65nbe92f73edff9323c@mail.gmail.com> 2007/10/5, Dino Viehland : > But it properly enforces it if it's an int, a DateTime, or a decimal. I'll let them > know. It would be great if you can fix this in IronPython too. -- Seo Sanghyeon From dinov at exchange.microsoft.com Fri Oct 5 03:20:12 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 4 Oct 2007 18:20:12 -0700 Subject: [IronPython] Compilation error In-Reply-To: <5b0248170710041816i42e7ad65nbe92f73edff9323c@mail.gmail.com> References: <5b0248170710041742j42e3fa0av1504df1d45ea2de3@mail.gmail.com> <7AD436E4270DD54A94238001769C2227CCBD231097@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <5b0248170710041816i42e7ad65nbe92f73edff9323c@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227CCBD231098@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Of course :) ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo [sanxiyn at gmail.com] Sent: Thursday, October 04, 2007 6:16 PM To: Discussion of IronPython Subject: Re: [IronPython] Compilation error 2007/10/5, Dino Viehland : > But it properly enforces it if it's an int, a DateTime, or a decimal. I'll let them > know. It would be great if you can fix this in IronPython too. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Fri Oct 5 03:21:53 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 5 Oct 2007 10:21:53 +0900 Subject: [IronPython] Compilation error In-Reply-To: <7AD436E4270DD54A94238001769C2227CCBD231097@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <5b0248170710041742j42e3fa0av1504df1d45ea2de3@mail.gmail.com> <7AD436E4270DD54A94238001769C2227CCBD231097@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <5b0248170710041821j1e197667q1005a7ad77e3a83a@mail.gmail.com> 2007/10/5, Dino Viehland : > It looks like csc doesn't require out params to be assigned if they're value types: I searched Mono bugzilla, and found that apparently this was mcs behaviour too. Bug 311892 - mcs incorrect CS0177 with out structs https://bugzilla.novell.com/show_bug.cgi?id=311892 I smell something wrong... But it would still be interesting to hear what csc people think. Thanks! -- Seo Sanghyeon From sanxiyn at gmail.com Fri Oct 5 04:21:14 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 5 Oct 2007 11:21:14 +0900 Subject: [IronPython] Japanese contact Message-ID: <5b0248170710041921t3ac65e06u1d97d643e36200f5@mail.gmail.com> Today while surfing the web I found this blog: http://kazamachi.blogspot.com/ The author, Akira Kazamachi, seems to have some useful changes to FePy libraries, which I have never heard of until now. I am always interested in feedbacks and contributions from more people. Does anyone on this list (I believe some of you are Japanese) know who ey is and how to contact em? -- Seo Sanghyeon From hfoffani at gmail.com Fri Oct 5 10:20:33 2007 From: hfoffani at gmail.com (Hernan M Foffani) Date: Fri, 5 Oct 2007 10:20:33 +0200 Subject: [IronPython] Japanese contact In-Reply-To: <5b0248170710041921t3ac65e06u1d97d643e36200f5@mail.gmail.com> References: <5b0248170710041921t3ac65e06u1d97d643e36200f5@mail.gmail.com> Message-ID: <11fab4bc0710050120v50dcd5f2lbd7438c3111d455e@mail.gmail.com> > Today while surfing the web I found this blog: > http://kazamachi.blogspot.com/ Has been an IronPython book published in Japan? -H. From sanxiyn at gmail.com Fri Oct 5 10:28:02 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 5 Oct 2007 17:28:02 +0900 Subject: [IronPython] Japanese contact In-Reply-To: <11fab4bc0710050120v50dcd5f2lbd7438c3111d455e@mail.gmail.com> References: <5b0248170710041921t3ac65e06u1d97d643e36200f5@mail.gmail.com> <11fab4bc0710050120v50dcd5f2lbd7438c3111d455e@mail.gmail.com> Message-ID: <5b0248170710050128ja542d41jba417fe4a384b42b@mail.gmail.com> 2007/10/5, Hernan M Foffani : > Has been an IronPython book published in Japan? Yes. Search for IronPython on Amazon.co.jp. -- Seo Sanghyeon From daftspaniel at gmail.com Fri Oct 5 23:50:09 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Fri, 5 Oct 2007 22:50:09 +0100 Subject: [IronPython] COM Interop - Dot net Interface Support in 2.0A4 Message-ID: <20253b0c0710051450t4e1d1050ve618b7c1708b3669@mail.gmail.com> Sorry if I have missed this, but are COM Interfaces supported in Interop? I guess this would be a DotNet interface at this stage? import clr clr.AddReferenceToFile("Interop.Microsoft.Feeds.Interop.dll") from Microsoft.Feeds.Interop import * t = FeedsManagerClass() print t.RootFolder u = t.RootFolder print u print u.TotalItemCount results in.... <__ComObject object at 0x000000000000002B> <__ComObject object at 0x000000000000002C> SystemError: Could not load type 'Feeds.IFeedFolder' from assembly 'Feeds, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Thanks Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From dinov at exchange.microsoft.com Sat Oct 6 01:28:30 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 5 Oct 2007 16:28:30 -0700 Subject: [IronPython] Compilation error In-Reply-To: <5b0248170710041821j1e197667q1005a7ad77e3a83a@mail.gmail.com> References: <5b0248170710041742j42e3fa0av1504df1d45ea2de3@mail.gmail.com> <7AD436E4270DD54A94238001769C2227CCBD231097@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <5b0248170710041821j1e197667q1005a7ad77e3a83a@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227CCBD5EFCB8@DF-GRTDANE-MSG.exchange.corp.microsoft.com> BTW my simple repro is bogus - it contains no members and section 5.3 of the C# spec defines value types as being definitely assigned when all their members are assigned. The real issue seems to be when the value-type is defined in another assembly and all the members are private. Once those conditions are met csc then doesn't require the assignment. I'm still waiting for a response on that last bit. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Thursday, October 04, 2007 6:22 PM To: Discussion of IronPython Subject: Re: [IronPython] Compilation error 2007/10/5, Dino Viehland : > It looks like csc doesn't require out params to be assigned if they're value types: I searched Mono bugzilla, and found that apparently this was mcs behaviour too. Bug 311892 - mcs incorrect CS0177 with out structs https://bugzilla.novell.com/show_bug.cgi?id=311892 I smell something wrong... But it would still be interesting to hear what csc people think. Thanks! -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Sat Oct 6 02:43:32 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sat, 6 Oct 2007 09:43:32 +0900 Subject: [IronPython] FePy patches Message-ID: <5b0248170710051743k5cfe835cy44eb383b9320180c@mail.gmail.com> I overhauled FePy patches list. http://fepy.sourceforge.net/patches.html There are now separate pages for IronPython 1.x branch and 2.x branch. I cleaned up all patches I wrote for 2.x branch, added some more, and documented them. The simple result is that Mono 1.2.5 should compile and run all 2.x Alpha releases with these patches. Many of them are workarounds for Mono bugs, which aren't very interesting. I hope equivalent of patch-flags-argcount to be applied in 2.0 Alpha 5 to fix #6805, which is already fixed in 1.1. Is there any chance you can take patch-nant-build, that is, include IronPython.build under Src directory? Since that is in patch form, the copy I am using is here: http://sparcs.kaist.ac.kr/~tinuviel/download/IronPython/IronPython.build -- Seo Sanghyeon From sh at defuze.org Sat Oct 6 18:41:11 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Sat, 06 Oct 2007 10:41:11 -0600 Subject: [IronPython] FePy patches In-Reply-To: <5b0248170710051743k5cfe835cy44eb383b9320180c@mail.gmail.com> References: <5b0248170710051743k5cfe835cy44eb383b9320180c@mail.gmail.com> Message-ID: <4707BAA7.9060804@defuze.org> Thanks a lot Seo. I can confirm I managed to compile IP2.0a4 after applying Seo's patchs using the release of mono 1.2.5.1. It even launched and hasn't crashed yet :) Again, thank you Seo. You rock! - Sylvain Sanghyeon Seo wrote: > I overhauled FePy patches list. > http://fepy.sourceforge.net/patches.html > > There are now separate pages for IronPython 1.x branch and 2.x branch. > I cleaned up all patches I wrote for 2.x branch, added some more, and > documented them. The simple result is that Mono 1.2.5 should compile > and run all 2.x Alpha releases with these patches. > > Many of them are workarounds for Mono bugs, which aren't very interesting. > > I hope equivalent of patch-flags-argcount to be applied in 2.0 Alpha 5 > to fix #6805, which is already fixed in 1.1. > > Is there any chance you can take patch-nant-build, that is, include > IronPython.build under Src directory? Since that is in patch form, the > copy I am using is here: > http://sparcs.kaist.ac.kr/~tinuviel/download/IronPython/IronPython.build > From fuzzyman at voidspace.org.uk Sat Oct 6 19:59:14 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 06 Oct 2007 18:59:14 +0100 Subject: [IronPython] IronPython 2 & Calltarget0 Message-ID: <4707CCF2.7060200@voidspace.org.uk> Hello all, I'm sure this question has been answered before - but I'm afraid I can't find it. In IronPython 2, what (or more importantly where...) is the equivalent of CallTarget0 ? Michael Foord http://www.manning.com From fuzzyman at voidspace.org.uk Sat Oct 6 20:22:10 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 06 Oct 2007 19:22:10 +0100 Subject: [IronPython] [python] IronPython 2 & Calltarget0 In-Reply-To: <4707CCF2.7060200@voidspace.org.uk> References: <4707CCF2.7060200@voidspace.org.uk> Message-ID: <4707D252.1080508@voidspace.org.uk> Michael Foord wrote: > Hello all, > > I'm sure this question has been answered before - but I'm afraid I can't > find it. > > In IronPython 2, what (or more importantly where...) is the equivalent > of CallTarget0 ? > Don't worry - I found it in Microsoft.Scripting. For reference, a 'cross version' way of importing CallTarget0 is try: from IronPython.Runtime.Calls import CallTarget0 except ImportError: from Microsoft.Scripting import CallTarget0 All the best, Michael http://www.manning.com/foord > Michael Foord > http://www.manning.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From daftspaniel at gmail.com Sun Oct 7 22:25:33 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Sun, 7 Oct 2007 21:25:33 +0100 Subject: [IronPython] Import Now Message-ID: <20253b0c0710071325q77a49cccxcadfd60ab35ff204@mail.gmail.com> IronPython console: IronPython 2.0A4 (2.0.10904.02) on .NET 2.0.50727.312 Copyright (c) Microsoft Corporation. All rights reserved. >>> from System.DateTime import Now >>> print Now 07/10/2007 21:23:20 >>> print "a few seconds later" + Now.ToString() a few seconds later07/10/2007 21:23:20 >>> from System.DateTime import Now >>> print Now 07/10/2007 21:24:02 >>> Huh?!??! :-) -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From fuzzyman at voidspace.org.uk Sun Oct 7 22:31:29 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 07 Oct 2007 21:31:29 +0100 Subject: [IronPython] [python] Import Now In-Reply-To: <20253b0c0710071325q77a49cccxcadfd60ab35ff204@mail.gmail.com> References: <20253b0c0710071325q77a49cccxcadfd60ab35ff204@mail.gmail.com> Message-ID: <47094221.9080307@voidspace.org.uk> Davy Mitchell wrote: > IronPython console: IronPython 2.0A4 (2.0.10904.02) on .NET 2.0.50727.312 > Copyright (c) Microsoft Corporation. All rights reserved. > >>>> from System.DateTime import Now >>>> print Now >>>> > 07/10/2007 21:23:20 > >>>> print "a few seconds later" + Now.ToString() >>>> > a few seconds later07/10/2007 21:23:20 > >>>> from System.DateTime import Now >>>> print Now >>>> > 07/10/2007 21:24:02 > > > Huh?!??! :-) > > That's kind of what I would expect. :-) Now is actually a (static) member of the DateTime class - but in .NET you can do this kind of import. DateTime instances are immutable - so accessing 'Now' returns the current one (which doesn't then change). When you import again you look-up the new current time. Just import DateTime and access 'Now' whenever you need it... Michael http://www.manning.com/foord From daftspaniel at gmail.com Sun Oct 7 23:08:09 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Sun, 7 Oct 2007 22:08:09 +0100 Subject: [IronPython] [python] Import Now In-Reply-To: <47094221.9080307@voidspace.org.uk> References: <20253b0c0710071325q77a49cccxcadfd60ab35ff204@mail.gmail.com> <47094221.9080307@voidspace.org.uk> Message-ID: <20253b0c0710071408y37075221iad518d3f36515ddb@mail.gmail.com> Yeah sounds reasonable but a little clunky :-) Davy On 10/7/07, Michael Foord wrote: > Davy Mitchell wrote: > > IronPython console: IronPython 2.0A4 (2.0.10904.02) on .NET 2.0.50727.312 > > Copyright (c) Microsoft Corporation. All rights reserved. > > > >>>> from System.DateTime import Now > >>>> print Now > >>>> > > 07/10/2007 21:23:20 > > > >>>> print "a few seconds later" + Now.ToString() > >>>> > > a few seconds later07/10/2007 21:23:20 > > > >>>> from System.DateTime import Now > >>>> print Now > >>>> > > 07/10/2007 21:24:02 > > > > > > Huh?!??! :-) > > > > > > That's kind of what I would expect. :-) > > Now is actually a (static) member of the DateTime class - but in .NET > you can do this kind of import. > > DateTime instances are immutable - so accessing 'Now' returns the > current one (which doesn't then change). When you import again you > look-up the new current time. > > Just import DateTime and access 'Now' whenever you need it... > > Michael > http://www.manning.com/foord > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From daftspaniel at gmail.com Tue Oct 9 20:57:02 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Tue, 9 Oct 2007 19:57:02 +0100 Subject: [IronPython] IP2A4 - Bug when Exception thrown on worker thread Message-ID: <20253b0c0710091157h71d7b5b2xb4af216cc76eaabd@mail.gmail.com> Hi - the following snippit crashes IP2A4. import clr from System.Threading import ApartmentState,Thread, ThreadStart def Run(): print wibble t = Thread(ThreadStart(Run)) t.ApartmentState = ApartmentState.STA t.Start() Thread.Sleep(90000) Unhandled Exception: Microsoft.Scripting.UnboundNameException: name 'wibble' is not defined at IronPython.Runtime.PythonContext.MissingName(SymbolId name) at Microsoft.Scripting.ModuleGlobalWrapper.GetCachedValue() at Microsoft.Scripting.ModuleGlobalWrapper.get_CurrentValue() at __main__$mod_2.Run$1() in bug.py:line 5 at _stub_##17(Object[] , DynamicSite`2 , CodeContext , Object ) at Microsoft.Scripting.Actions.DynamicSite`2.UpdateBindingAndInvoke(CodeConte xt context, T0 arg0) at Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7 .Invoke1(DynamicSite`2 site, CodeContext context, T0 arg0) at Microsoft.Scripting.Actions.DynamicSite`2.Invoke(CodeContext context, T0 a rg0) at System.Void(), using PythonBinder##9(Object[] ) at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, C ontextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From fuzzyman at voidspace.org.uk Tue Oct 9 21:07:14 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 09 Oct 2007 20:07:14 +0100 Subject: [IronPython] [python] IP2A4 - Bug when Exception thrown on worker thread In-Reply-To: <20253b0c0710091157h71d7b5b2xb4af216cc76eaabd@mail.gmail.com> References: <20253b0c0710091157h71d7b5b2xb4af216cc76eaabd@mail.gmail.com> Message-ID: <470BD162.10401@voidspace.org.uk> Davy Mitchell wrote: > Hi - the following snippit crashes IP2A4. > It crashes 1.1 as well. We just kind of accepted that unhandled exceptions on threads cause app domain errors. In CPython it just raises an exception and terminates the thread. Michael http://www.manning.com/foord > import clr > from System.Threading import ApartmentState,Thread, ThreadStart > > def Run(): > print wibble > > t = Thread(ThreadStart(Run)) > t.ApartmentState = ApartmentState.STA > t.Start() > Thread.Sleep(90000) > > Unhandled Exception: Microsoft.Scripting.UnboundNameException: name 'wibble' is > not defined > at IronPython.Runtime.PythonContext.MissingName(SymbolId name) > at Microsoft.Scripting.ModuleGlobalWrapper.GetCachedValue() > at Microsoft.Scripting.ModuleGlobalWrapper.get_CurrentValue() > at __main__$mod_2.Run$1() in bug.py:line 5 > at _stub_##17(Object[] , DynamicSite`2 , CodeContext , Object ) > at Microsoft.Scripting.Actions.DynamicSite`2.UpdateBindingAndInvoke(CodeConte > xt context, T0 arg0) > at Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7 > .Invoke1(DynamicSite`2 site, CodeContext context, T0 arg0) > at Microsoft.Scripting.Actions.DynamicSite`2.Invoke(CodeContext context, T0 a > rg0) > at System.Void(), using PythonBinder##9(Object[] ) > at System.Threading.ThreadHelper.ThreadStart_Context(Object state) > at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, C > ontextCallback callback, Object state) > at System.Threading.ThreadHelper.ThreadStart() > > From dinov at exchange.microsoft.com Tue Oct 9 21:29:47 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 9 Oct 2007 12:29:47 -0700 Subject: [IronPython] [python] IP2A4 - Bug when Exception thrown on worker thread In-Reply-To: <470BD162.10401@voidspace.org.uk> References: <20253b0c0710091157h71d7b5b2xb4af216cc76eaabd@mail.gmail.com> <470BD162.10401@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C2227CCBF4C0DB2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Well, just to be pedantic, in CPython you get: >>> import clr Traceback (most recent call last): File "", line 1, in ImportError: No module named clr >>> from System.Threading import ApartmentState,Thread, ThreadStart Traceback (most recent call last): File "", line 1, in ImportError: No module named System.Threading >>> >>> def Run(): ... print wibble ... >>> t = Thread(ThreadStart(Run)) Traceback (most recent call last): File "", line 1, in NameError: name 'Thread' is not defined >>> t.ApartmentState = ApartmentState.STA Traceback (most recent call last): File "", line 1, in NameError: name 'ApartmentState' is not defined >>> t.Start() Traceback (most recent call last): File "", line 1, in NameError: name 't' is not defined >>> Thread.Sleep(90000) Traceback (most recent call last): File "", line 1, in NameError: name 'Thread' is not defined On the other hand if you do the same thing in both IronPython & CPython: import thread def Run(): print wibble thread.start_new_thread(Run, ()) you get the same results. This is because in .NET threads don't have a backstop for unhandled exceptions (and it's generally considered a good thing, and a positive change in v2.0 - this helps prevent unhandled exceptions from going unnoticed). Obviously Python has made a different choice here (as did .NET v1.x) and so we respect that choice when you use the standard Python functionality. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Tuesday, October 09, 2007 12:07 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] IP2A4 - Bug when Exception thrown on worker thread Davy Mitchell wrote: > Hi - the following snippit crashes IP2A4. > It crashes 1.1 as well. We just kind of accepted that unhandled exceptions on threads cause app domain errors. In CPython it just raises an exception and terminates the thread. Michael http://www.manning.com/foord > import clr > from System.Threading import ApartmentState,Thread, ThreadStart > > def Run(): > print wibble > > t = Thread(ThreadStart(Run)) > t.ApartmentState = ApartmentState.STA > t.Start() > Thread.Sleep(90000) > > Unhandled Exception: Microsoft.Scripting.UnboundNameException: name 'wibble' is > not defined > at IronPython.Runtime.PythonContext.MissingName(SymbolId name) > at Microsoft.Scripting.ModuleGlobalWrapper.GetCachedValue() > at Microsoft.Scripting.ModuleGlobalWrapper.get_CurrentValue() > at __main__$mod_2.Run$1() in bug.py:line 5 > at _stub_##17(Object[] , DynamicSite`2 , CodeContext , Object ) > at Microsoft.Scripting.Actions.DynamicSite`2.UpdateBindingAndInvoke(CodeConte > xt context, T0 arg0) > at Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7 > .Invoke1(DynamicSite`2 site, CodeContext context, T0 arg0) > at Microsoft.Scripting.Actions.DynamicSite`2.Invoke(CodeContext context, T0 a > rg0) > at System.Void(), using PythonBinder##9(Object[] ) > at System.Threading.ThreadHelper.ThreadStart_Context(Object state) > at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, C > ontextCallback callback, Object state) > at System.Threading.ThreadHelper.ThreadStart() > > _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From daftspaniel at gmail.com Tue Oct 9 22:02:45 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Tue, 9 Oct 2007 21:02:45 +0100 Subject: [IronPython] [python] IP2A4 - Bug when Exception thrown on worker thread In-Reply-To: <7AD436E4270DD54A94238001769C2227CCBF4C0DB2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <20253b0c0710091157h71d7b5b2xb4af216cc76eaabd@mail.gmail.com> <470BD162.10401@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227CCBF4C0DB2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <20253b0c0710091302s4c9d6e85u4d38f4a89d67ee05@mail.gmail.com> Thanks Dino and Michael. Just remembered I had the opposite issue with the WinForms Timer a while ago so I guess it makes sense :-) ! Looks like I should be something like... import clr from System.Threading import ApartmentState,Thread, ThreadStart def Run(): try: print wibble except: print "phew!" t = Thread(ThreadStart(Run)) t.ApartmentState = ApartmentState.STA t.Start() Thread.Sleep(90000) Thanks, Davy Mitchell On 10/9/07, Dino Viehland wrote: > Well, just to be pedantic, in CPython you get: > > >>> import clr > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named clr > >>> from System.Threading import ApartmentState,Thread, ThreadStart > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named System.Threading > >>> > >>> def Run(): > ... print wibble > ... > >>> t = Thread(ThreadStart(Run)) > Traceback (most recent call last): > File "", line 1, in > NameError: name 'Thread' is not defined > >>> t.ApartmentState = ApartmentState.STA > Traceback (most recent call last): > File "", line 1, in > NameError: name 'ApartmentState' is not defined > >>> t.Start() > Traceback (most recent call last): > File "", line 1, in > NameError: name 't' is not defined > >>> Thread.Sleep(90000) > Traceback (most recent call last): > File "", line 1, in > NameError: name 'Thread' is not defined > > On the other hand if you do the same thing in both IronPython & CPython: > > import thread > def Run(): > print wibble > > thread.start_new_thread(Run, ()) > > you get the same results. > > This is because in .NET threads don't have a backstop for unhandled exceptions (and it's generally considered a good thing, and a positive change in v2.0 - this helps prevent unhandled exceptions from going unnoticed). Obviously Python has made a different choice here (as did .NET v1.x) and so we respect that choice when you use the standard Python functionality. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Tuesday, October 09, 2007 12:07 PM > To: Discussion of IronPython > Subject: Re: [IronPython] [python] IP2A4 - Bug when Exception thrown on worker thread > > Davy Mitchell wrote: > > Hi - the following snippit crashes IP2A4. > > > > It crashes 1.1 as well. We just kind of accepted that unhandled > exceptions on threads cause app domain errors. > > In CPython it just raises an exception and terminates the thread. > > Michael > http://www.manning.com/foord > > > import clr > > from System.Threading import ApartmentState,Thread, ThreadStart > > > > def Run(): > > print wibble > > > > t = Thread(ThreadStart(Run)) > > t.ApartmentState = ApartmentState.STA > > t.Start() > > Thread.Sleep(90000) > > > > Unhandled Exception: Microsoft.Scripting.UnboundNameException: name 'wibble' is > > not defined > > at IronPython.Runtime.PythonContext.MissingName(SymbolId name) > > at Microsoft.Scripting.ModuleGlobalWrapper.GetCachedValue() > > at Microsoft.Scripting.ModuleGlobalWrapper.get_CurrentValue() > > at __main__$mod_2.Run$1() in bug.py:line 5 > > at _stub_##17(Object[] , DynamicSite`2 , CodeContext , Object ) > > at Microsoft.Scripting.Actions.DynamicSite`2.UpdateBindingAndInvoke(CodeConte > > xt context, T0 arg0) > > at Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7 > > .Invoke1(DynamicSite`2 site, CodeContext context, T0 arg0) > > at Microsoft.Scripting.Actions.DynamicSite`2.Invoke(CodeContext context, T0 a > > rg0) > > at System.Void(), using PythonBinder##9(Object[] ) > > at System.Threading.ThreadHelper.ThreadStart_Context(Object state) > > at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, C > > ontextCallback callback, Object state) > > at System.Threading.ThreadHelper.ThreadStart() > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From riltim at gmail.com Wed Oct 10 22:55:35 2007 From: riltim at gmail.com (Tim Riley) Date: Wed, 10 Oct 2007 16:55:35 -0400 Subject: [IronPython] Hosting a python engine inside a windows form from IronPython code. Message-ID: I am looking for some direction for running a GUI based IronPython console from IronPython code. I have found a sample of hosting IronPython in IronPython that Mr. Foord had created but it doesn't help me out with figuring out how to tie it to a RichTextBox. Has anyone done this and if so do they have any pointers they are willing to share? Thanks, Tim From joesox at gmail.com Wed Oct 10 23:24:04 2007 From: joesox at gmail.com (JoeSox) Date: Wed, 10 Oct 2007 14:24:04 -0700 Subject: [IronPython] Hosting a python engine inside a windows form from IronPython code. In-Reply-To: References: Message-ID: <785694cd0710101424s3416c1f7yf1b6b263cb5cc59e@mail.gmail.com> On 10/10/07, Tim Riley wrote: > I am looking for some direction for running a GUI based IronPython > console from IronPython code. I have found a sample of hosting > IronPython in IronPython that Mr. Foord had created but it doesn't > help me out with figuring out how to tie it to a RichTextBox. Has > anyone done this and if so do they have any pointers they are willing > to share? I am the author of IronTextBox http://www.codeproject.com/useritems/irontextbox.asp which is currently only for IP1 I have started an IP2 version looking at many different ways to due it but I have concluded to wait until IP2 is at least beta. Even then, I do wish IP2 was easier to integrate with textbox and richedit controls. But I really haven't invested much time into IronTextBox 2 so I still might be able to pull something off in the next few months. To be honest I really haven't been using IP2 until recently. Ideally, I would like as close as the Visual Studio IronPython Console as possible (color coding autocomplete etc.) but I was unable to find a hook at the time I was looking. But then the IronTextBox user would have to have Visual Studio installed and that really isn't ideal. -- Later, JoeSox From joesox at gmail.com Wed Oct 10 23:29:37 2007 From: joesox at gmail.com (JoeSox) Date: Wed, 10 Oct 2007 14:29:37 -0700 Subject: [IronPython] Hosting a python engine inside a windows form from IronPython code. In-Reply-To: References: Message-ID: <785694cd0710101429t16ec1e83v368eef7f82d21f7e@mail.gmail.com> On 10/10/07, Tim Riley wrote: > I am looking for some direction for running a GUI based IronPython > console from IronPython code. I have found a sample of hosting > IronPython in IronPython that Mr. Foord had created but it doesn't > help me out with figuring out how to tie it to a RichTextBox. Has > anyone done this and if so do they have any pointers they are willing > to share? Also, I may have miss understood your question so if you are looking at just running the IronPythonEngine in a app, feel free to download my Visual Studio project for pswrdgeniron The main article is here: http://www.codeproject.com/useritems/pswrdgeniron.asp is may be a good example you are looking for and this was developed with IP2 A direct download for the source (without a site membership) can be found here: http://joeswammi.com/downloads/pswrdgeniron.zip pswrdgen and pswrdgeniron main website is http://pswrdgen.googlecode.com -- Later, JoeSox From joesox at gmail.com Wed Oct 10 23:37:48 2007 From: joesox at gmail.com (JoeSox) Date: Wed, 10 Oct 2007 14:37:48 -0700 Subject: [IronPython] Hosting a python engine inside a windows form from IronPython code. In-Reply-To: <785694cd0710101429t16ec1e83v368eef7f82d21f7e@mail.gmail.com> References: <785694cd0710101429t16ec1e83v368eef7f82d21f7e@mail.gmail.com> Message-ID: <785694cd0710101437x580f3af5yc55a41ad550e8dc4@mail.gmail.com> On 10/10/07, JoeSox wrote: > A direct download for the source (without a site membership) can be found here: > http://joeswammi.com/downloads/pswrdgeniron.zip Darn, I guess that is the actual application setup download. Sorry, the svn on googlecode or the pswrdgeniron_src.zip are the only ways to download the VS project source at the moment. There are lots of tutorials from others on this list, also. -- Later, JoeSox From riltim at gmail.com Thu Oct 11 03:57:13 2007 From: riltim at gmail.com (Tim Riley) Date: Wed, 10 Oct 2007 21:57:13 -0400 Subject: [IronPython] Hosting a python engine inside a windows form from IronPython code. In-Reply-To: <785694cd0710101424s3416c1f7yf1b6b263cb5cc59e@mail.gmail.com> References: <785694cd0710101424s3416c1f7yf1b6b263cb5cc59e@mail.gmail.com> Message-ID: Thanks Joe. IronTextBox looks like what I'm looking for. However I can't use it as your source code indicates the code is released under the GPL which I don't think I can use from my MIT licensed project. After reading Michael's tutorial on embedding IronPython in IronPython I think I have a pretty good handle on what I need to do from my code. Thanks again. Tim On 10/10/07, JoeSox wrote: > On 10/10/07, Tim Riley wrote: > > I am looking for some direction for running a GUI based IronPython > > console from IronPython code. I have found a sample of hosting > > IronPython in IronPython that Mr. Foord had created but it doesn't > > help me out with figuring out how to tie it to a RichTextBox. Has > > anyone done this and if so do they have any pointers they are willing > > to share? > > I am the author of IronTextBox > http://www.codeproject.com/useritems/irontextbox.asp > which is currently only for IP1 > > I have started an IP2 version looking at many different ways to due it > but I have concluded to wait until IP2 is at least beta. Even then, I > do wish IP2 was easier to integrate with textbox and richedit > controls. But I really haven't invested much time into IronTextBox 2 > so I still might be able to pull something off in the next few months. > To be honest I really haven't been using IP2 until recently. Ideally, > I would like as close as the Visual Studio IronPython Console as > possible (color coding autocomplete etc.) but I was unable to find a > hook at the time I was looking. But then the IronTextBox user would > have to have Visual Studio installed and that really isn't ideal. > -- > Later, JoeSox > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From ronny.stiftel at gmail.com Thu Oct 11 21:14:43 2007 From: ronny.stiftel at gmail.com (Ronny Stiftel) Date: Thu, 11 Oct 2007 21:14:43 +0200 Subject: [IronPython] Help with unrar.dll in ironpython Message-ID: Hi i am kinda new to ironpython and tried to use unrar in a project. Since i was unable to directly import it i made a .net wrapper dll (see attachment generate.py), works quite well only problem left now is: >> archiveData = unrar.RAROpenArchiveDataEx(OpenMode=1) ValueError: Attempt to update field 'OpenMode' on value type 'RAROpenArchiveDataEx'; value type fields cannot be directly modified guess there is an easy way to solve it, any help would be appreciated regards ronny -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: generate.py URL: From dinov at exchange.microsoft.com Fri Oct 12 01:51:34 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 11 Oct 2007 16:51:34 -0700 Subject: [IronPython] Help with unrar.dll in ironpython In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C2227D37F63001F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> See http://channel9.msdn.com/wiki/default.aspx/IronPython.ValueTypes for an explanation of why you can't update value types. You might be able to call archiveData.set_OpenMode(1) after creating it though. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ronny Stiftel Sent: Thursday, October 11, 2007 12:15 PM To: users at lists.ironpython.com Subject: [IronPython] Help with unrar.dll in ironpython Hi i am kinda new to ironpython and tried to use unrar in a project. Since i was unable to directly import it i made a .net wrapper dll (see attachment generate.py), works quite well only problem left now is: >> archiveData = unrar.RAROpenArchiveDataEx(OpenMode=1) ValueError: Attempt to update field 'OpenMode' on value type 'RAROpenArchiveDataEx'; value type fields cannot be directly modified guess there is an easy way to solve it, any help would be appreciated regards ronny -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Fri Oct 12 19:00:49 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Fri, 12 Oct 2007 18:00:49 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython Message-ID: <470FA841.6020008@resolversystems.com> At Resolver Systems, we started building our core products with the view that most of our clients would want to use them to connect spreadsheet data and designs, Python code, and .NET objects. This was the right decision; lots of people do want to do just that, and we've been working with them so far. However, as we've spoken to more potential clients over the last months, we've learned something new - that there's a lot of interest out there in using a tool like Resolver One to plug together not just spreadsheets, Python and .NET, but also the existing CPython C extensions. Solving the general problem - plugging an arbitrary C extension into IronPython - is a huge project, and we're not even sure we could work out *how much work it is* without a lot of investigation. What we intend to do is to solve a specific problem, to integrate just one extension, and to use that project as a testbed to examine the possibilities for getting other extensions working - and perhaps, in the long term, solving the general problem. We think that any solution like this will be valuable not just to us, but to the IronPython community as a whole. And so, we want to make it Open Source. Right now, we'd particularly like to hear from people about the following: * Who wants to get involved? We're really keen on working with people on this. * Which module should we go for? NumPy looks like a good start, as it gives us a start on getting SciPy working. But perhaps there are better choices. * Should this be a new project, or should we be talking to other people about getting it into other projects? * Which license? If we're to work on it with a view to building it into Resolver One, then it will need to be commercial-software-friendly. Apart from that - we have no view. * What is the best architecture? We're thinking of this as being a bit of C# managed code to interface with the C extension, and a thin Python wrapper on top. The module's existing C extension and Python code would "sandwich" this layer. Let us know if this is a silly idea :-) * Is there anything else we should be thinking about to get this started? Regards, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Fri Oct 12 20:18:54 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Fri, 12 Oct 2007 11:18:54 -0700 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython References: <470FA841.6020008@resolversystems.com> Message-ID: NumPy would be cool :) And it probably gives you a few different data structures to figure out marshalling, no? ________________________________ From: users-bounces at lists.ironpython.com on behalf of Giles Thomas Sent: Fri 10/12/2007 10:00 AM To: Discussion of IronPython Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython At Resolver Systems, we started building our core products with the view that most of our clients would want to use them to connect spreadsheet data and designs, Python code, and .NET objects. This was the right decision; lots of people do want to do just that, and we've been working with them so far. However, as we've spoken to more potential clients over the last months, we've learned something new - that there's a lot of interest out there in using a tool like Resolver One to plug together not just spreadsheets, Python and .NET, but also the existing CPython C extensions. Solving the general problem - plugging an arbitrary C extension into IronPython - is a huge project, and we're not even sure we could work out *how much work it is* without a lot of investigation. What we intend to do is to solve a specific problem, to integrate just one extension, and to use that project as a testbed to examine the possibilities for getting other extensions working - and perhaps, in the long term, solving the general problem. We think that any solution like this will be valuable not just to us, but to the IronPython community as a whole. And so, we want to make it Open Source. Right now, we'd particularly like to hear from people about the following: * Who wants to get involved? We're really keen on working with people on this. * Which module should we go for? NumPy looks like a good start, as it gives us a start on getting SciPy working. But perhaps there are better choices. * Should this be a new project, or should we be talking to other people about getting it into other projects? * Which license? If we're to work on it with a view to building it into Resolver One, then it will need to be commercial-software-friendly. Apart from that - we have no view. * What is the best architecture? We're thinking of this as being a bit of C# managed code to interface with the C extension, and a thin Python wrapper on top. The module's existing C extension and Python code would "sandwich" this layer. Let us know if this is a silly idea :-) * Is there anything else we should be thinking about to get this started? Regards, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5969 bytes Desc: not available URL: From curt at hagenlocher.org Fri Oct 12 20:37:42 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 12 Oct 2007 11:37:42 -0700 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <470FA841.6020008@resolversystems.com> References: <470FA841.6020008@resolversystems.com> Message-ID: On 10/12/07, Giles Thomas wrote: > > What is the best architecture? We're thinking of this as being a bit of > C# managed code to interface with the C extension, and a thin Python wrapper > on top. The module's existing C extension and Python code would "sandwich" > this layer. Let us know if this is a silly idea :-) > My two cents would be this: using Managed C++, try for source compatibility first. It will almost certainly be less work than binary compatibility -- especially given your restricted test case -- and you're not likely to do much coding that wouldn't be needed for binary compatibility anyway. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfugate at microsoft.com Fri Oct 12 23:24:56 2007 From: dfugate at microsoft.com (Dave Fugate) Date: Fri, 12 Oct 2007 14:24:56 -0700 Subject: [IronPython] IronPython 2.0 Alpha 5 In-Reply-To: References: <7346A825E148B049A9AD1D3ED46A2D91169C28048E@NA-EXMSG-C106.redmond.corp.microsoft.com> <7AD436E4270DD54A94238001769C2227D186C3E6D2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <7346A825E148B049A9AD1D3ED46A2D91169C3802AE@NA-EXMSG-C106.redmond.corp.microsoft.com> Hello IronPython Community, We have just released IronPython 2.0 Alpha 5. Over the past month our team has been busy fixing bugs which were typically chosen by the number of votes on CodePlex. A little over forty CodePlex Work Items and around twenty bugs reported internally were closed since the release of IP 2.0A4. There were no major new features added unless you count the fact that we ported the standard 'array' module from IronPython v1.1 to v2.0. This now means that all of the standard modules in v1.1 are available in the latest 2.0 tree. Specifically the following CodePlex Work Items were resolved and I'd like to extend our team's thanks to everyone who reported, commented, and voted on these: ? 9453 ayarrow += works differently on lists ? 3727 bashmohandes Problem when creating new Workflow in Windows Workflow ? 1608 brucec str.__dict__['__dict__'] should not exist ? 5445 IPTeam socket.getaddrinfo(...) does not throw on nonsense parameters ? 5682 IPTeam System.Single boolean ops w/ integer types broken ? 3289 IPTeam Threads should not block the main thread from exiting ? 10778 sanixyn -S command-line option omits "Lib" from sys.path ? 12283 IPTeam sys.argv always empty regardless of params passed to ipyw.exe ? 12851 IPTeam Expressions starting with a backslash in interactive sessions broken ? 10518 Benjamin West urllib is failing to work due to socket disposed exception ? 11759 sanixyn Zero-length regex split ? 5641 Christian Muirhead co_name in code objects is None ? 5712 J?rgen Stenarson iterating over __main__.__dict__ throws ? 2599 Kurt Blackwell __import__ from list is incorrect ? 12708 David Lawler Method dispatch fails with SharpDevelop APIs ? 12908 Michael Foord Support 0x200 (PyCF_DONT_IMPLY_DEDENT) for compile built-in function ? 2728 sanixyn Slicing on old style classes is different ? 6735 sanixyn help incorrectly displays arguments for params functions ? 7426 Sylvain Hellegouarch in operator doesn't check for overloaded __contains__ on dictionary ? 7532 sanixyn func_defaults is empty tuple when there are no defaults ? 7594 sanixyn type.__call__ always passes type(type) as 1st parameter ? 6014 Davy Mitchell Calling super on overridden property causes stack overflow ? 9066 Michael Foord IronPython won't look into arbitrary objects when doing import ? 5602 Eloff (Py2.5) Cannot import random ? 12455 eshaish Importing PYD files ? 5204 gbraad PowerShell hosting IronPython ? 11684 googen PythonEngine has no constructors defined ? 9262 grizlupo not override __eq__ at derived float ? 7279 haypo It's not possible to check is a string is 'str' or 'unicode' ? 7918 jackeyoo CPython has the functions below while IronPython does not implement them ? 10058 johnplatt cPickle module doesn't work for xrange ? 6489 IPTeam Backslash on the interactive console causes syntax error ? 5690 Oceanborn Different parsers, compiler pipeline? ? 6332 pobrien DataGridView doesn't support a list of Python class instances as its DataSource ? 5799 pobrien Unpickler.persistent_load needs to be supported ? 3078 psykotic Bug when dealing with importing of .NET assemblies with class named identically to its containing namespace ? 3410 sanxiyn yield in nested try blocks ? 11812 tscottw dir(bool), dir(True), dir(False) raise SystemError on startup ? 10904 tscottw [Affecting Tutorial on 2.0] Missed feature (optional arguments) in exercise 2.1 in Tutorial 3 ? 7982 whit537 ^L yields SyntaxError IMPORTANT NOTE Internally we have migrated our Visual Studio project and solution files over to a Visual Studio 2008 beta release. While we've modified these files in the source distribution of IronPython to be compatible with Visual Studio 2005 and the msbuild tool, it's possible we may have missed something. If you experience any problems building IronPython from VS tools please let us know. You can download IronPython 2.0 Alpha 5 at: https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=IronPython&ReleaseId=7014 The Dynamic Language Runtime Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfugate at microsoft.com Sat Oct 13 00:42:06 2007 From: dfugate at microsoft.com (Dave Fugate) Date: Fri, 12 Oct 2007 15:42:06 -0700 Subject: [IronPython] Dynamic Language Runtime Position Message-ID: <7346A825E148B049A9AD1D3ED46A2D91169C380333@NA-EXMSG-C106.redmond.corp.microsoft.com> I'd like to announce that the Dynamic Language Runtime team (IronPython and IronRuby) currently has an opening for a 'Software Development Engineer in Test'. Quite simply put our team is in need of another tester with a strong interest in dynamic languages and a background in Python or Ruby. A detailed job description can be found at http://members.microsoft.com/careers/search/details.aspx?JobID=34EDBF1A-395B-4BD7-8811-AC68BD4EFB0C and John Lam's blog has some more info as well - see http://www.iunknown.com/. Some of tasks you might work on include: * Testing the compatibility of IronPython/IronRuby w/ CPython/MRI * Writing tests which exercise DLR functionality. For example, you might try to write a C# application which executes Python/Ruby code via the DLR's hosting APIs * Creating 'real world' dynamic Silverlight applications as a customer might to find bugs in the design of the APIs If you're interested please visit the careers website mentioned above or email your resume to yalvi at microsoft.com with "DLR SDET Position" in the subject field. The Dynamic Language Runtime Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Sat Oct 13 01:38:20 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 12 Oct 2007 16:38:20 -0700 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> Message-ID: <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> +1 on the MC++, this seems like an ideal use of it. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Friday, October 12, 2007 11:38 AM To: Discussion of IronPython Subject: Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython On 10/12/07, Giles Thomas > wrote: What is the best architecture? We're thinking of this as being a bit of C# managed code to interface with the C extension, and a thin Python wrapper on top. The module's existing C extension and Python code would "sandwich" this layer. Let us know if this is a silly idea :-) My two cents would be this: using Managed C++, try for source compatibility first. It will almost certainly be less work than binary compatibility -- especially given your restricted test case -- and you're not likely to do much coding that wouldn't be needed for binary compatibility anyway. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.dahlbacka at gmail.com Sat Oct 13 09:34:39 2007 From: simon.dahlbacka at gmail.com (Simon Dahlbacka) Date: Sat, 13 Oct 2007 10:34:39 +0300 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <57124720710130034j27ff7564ma0ee3c6fee0a9370@mail.gmail.com> On 10/13/07, Dino Viehland wrote: > > +1 on the MC++, this seems like an ideal use of it. > Just a little nitpick, hopefully were talking about C++/CLI and not the antique "Managed Extensions for C++" regards, Simon *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Curt Hagenlocher > *Sent:* Friday, October 12, 2007 11:38 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Announcement: Project to get some CPython C > extensions running under IronPython > > > > On 10/12/07, *Giles Thomas* wrote: > > What is the best architecture? We're thinking of this as being a bit of > C# managed code to interface with the C extension, and a thin Python wrapper > on top. The module's existing C extension and Python code would "sandwich" > this layer. Let us know if this is a silly idea :-) > > My two cents would be this: using Managed C++, try for source > compatibility first. It will almost certainly be less work than binary > compatibility -- especially given your restricted test case -- and you're > not likely to do much coding that wouldn't be needed for binary > compatibility anyway. > > > > -- > > Curt Hagenlocher > > curt at hagenlocher.org > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Sat Oct 13 15:55:15 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sat, 13 Oct 2007 22:55:15 +0900 Subject: [IronPython] Compilation warnings on Mono Message-ID: <5b0248170710130655q25138506r8340b27f66a09126@mail.gmail.com> Attached are compilation warnings on Mono for IronPython 2.0 Alpha 5. Many of them are noises but most of IronPython.Modules warnings (except for socket.cs) are valid. -- Seo Sanghyeon -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: warnings.txt URL: From daftspaniel at gmail.com Sat Oct 13 18:00:54 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Sat, 13 Oct 2007 17:00:54 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <470FA841.6020008@resolversystems.com> References: <470FA841.6020008@resolversystems.com> Message-ID: <20253b0c0710130900g57a8e98cv1c96e449f651a227@mail.gmail.com> On 10/12/07, Giles Thomas wrote: > Python and .NET, but also the existing CPython C extensions. Hi Giles, Sounds like a good idea and the approaches mentioned seemed solid. One strategy I was considering for a port of my Mood News site to Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM object using the win32 stuff and getting it into .Net via the COM interop support. Maybe not practical for Numpy :-) Does have the advantage of not having to modify the original lib... Cheers, Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From ronny.stiftel at gmail.com Sun Oct 14 01:38:11 2007 From: ronny.stiftel at gmail.com (Ronny Stiftel) Date: Sun, 14 Oct 2007 01:38:11 +0200 Subject: [IronPython] Help with unrar.dll in ironpython In-Reply-To: <7AD436E4270DD54A94238001769C2227D37F63001F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C2227D37F63001F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: set_OpenMode(1) wont work and i understand why, but i dunno how to solve it cause its from an imported dll On 10/12/07, Dino Viehland wrote: > > See http://channel9.msdn.com/wiki/default.aspx/IronPython.ValueTypes for > an explanation of why you can't update value types. > > > > You might be able to call archiveData.set_OpenMode(1) after creating it > though. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Ronny Stiftel > *Sent:* Thursday, October 11, 2007 12:15 PM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Help with unrar.dll in ironpython > > > > Hi i am kinda new to ironpython and tried to use unrar in a project. > Since i was unable to directly import it i made a .net wrapper dll (see > attachment generate.py), works quite well only problem left now is: > > >> archiveData = unrar.RAROpenArchiveDataEx(OpenMode=1) > ValueError: Attempt to update field 'OpenMode' on value type > 'RAROpenArchiveDataEx'; value type fields cannot be directly modified > > guess there is an easy way to solve it, any help would be appreciated > > regards > ronny > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hfoffani at gmail.com Sun Oct 14 17:24:22 2007 From: hfoffani at gmail.com (Hernan M Foffani) Date: Sun, 14 Oct 2007 17:24:22 +0200 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <470FA841.6020008@resolversystems.com> References: <470FA841.6020008@resolversystems.com> Message-ID: <11fab4bc0710140824x2e00bcdbga75bb8384754bc25@mail.gmail.com> Definetly it's a huge work. > Which module should we go for? NumPy looks like a good start, as it gives > us a start on getting SciPy working. But perhaps there are better choices. > Should this be a new project, or should we be talking to other people about > getting it into other projects? NumPy is already big. I'd start with a very small project like the sample at http://docs.python.org/ext/simpleExample.html. Sort of a proof of concept. Have you evaluated that you may need to port a big portion of the Python C API (Py* functions and macros.)? > What is the best architecture? We're thinking of this as being a bit of C# > managed code to interface with the C extension, and a thin Python wrapper on > top. The module's existing C extension and Python code would "sandwich" > this layer. Let us know if this is a silly idea :-) As someone else already said, you ought to consider COM too. Another aproach is to completly forget the *CPython* extension. Pick the domain C code core and add a .NET wrapper. Swig can you help here: http://www.swig.org/tutorial.html In these two approaches a Python compatibility layer API will be needed. Thus, the programmer can use the same API from IronPython that she used to use from CPython. > Is there anything else we should be thinking about to get this started? Hummm... I'm tempted to add a silly joke here but I'm going to refrain myself now. ;) Regards, -Hern?n. From fuzzyman at voidspace.org.uk Sun Oct 14 17:28:25 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 14 Oct 2007 16:28:25 +0100 Subject: [IronPython] [python] Re: Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <11fab4bc0710140824x2e00bcdbga75bb8384754bc25@mail.gmail.com> References: <470FA841.6020008@resolversystems.com> <11fab4bc0710140824x2e00bcdbga75bb8384754bc25@mail.gmail.com> Message-ID: <47123599.7050407@voidspace.org.uk> Hernan M Foffani wrote: > Definetly it's a huge work. > > >> Which module should we go for? NumPy looks like a good start, as it gives >> us a start on getting SciPy working. But perhaps there are better choices. >> Should this be a new project, or should we be talking to other people about >> getting it into other projects? >> > > NumPy is already big. I'd start with a very small project like the > sample at http://docs.python.org/ext/simpleExample.html. Sort of a > proof of concept. > We will pick a starting project, that although possibly big, will provide some direct 'business value' when completed. However your suggestion is not a bad way of starting that project (depending on which approach we take of course). > Have you evaluated that you may need to port a big portion of the Python > C API (Py* functions and macros.)? > Yes. :-) > >> What is the best architecture? We're thinking of this as being a bit of C# >> managed code to interface with the C extension, and a thin Python wrapper on >> top. The module's existing C extension and Python code would "sandwich" >> this layer. Let us know if this is a silly idea :-) >> > > As someone else already said, you ought to consider COM too. > > Another aproach is to completly forget the *CPython* extension. Pick > the domain C code core and add a .NET wrapper. Swig can you help here: > http://www.swig.org/tutorial.html > > In these two approaches a Python compatibility layer API will be needed. > Thus, the programmer can use the same API from IronPython that she > used to use from CPython. > Both interesting possibilities - thanks. Michael http://www.manning.com/foord > >> Is there anything else we should be thinking about to get this started? >> > > Hummm... I'm tempted to add a silly joke here but I'm going to refrain > myself now. ;) > > Regards, > -Hern?n. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From haiboluo at exchange.microsoft.com Sun Oct 14 23:33:57 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Sun, 14 Oct 2007 14:33:57 -0700 Subject: [IronPython] Help with unrar.dll in ironpython In-Reply-To: References: <7AD436E4270DD54A94238001769C2227D37F63001F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: Ronny, are you running your script with alpha 4? Seems alpha 4 and 5 (unfortunately) had regression on this scenario. Could you try the alpha 3 binaries? I expect it should work. Thanks! From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ronny Stiftel Sent: Saturday, October 13, 2007 4:38 PM To: Discussion of IronPython Subject: Re: [IronPython] Help with unrar.dll in ironpython set_OpenMode(1) wont work and i understand why, but i dunno how to solve it cause its from an imported dll On 10/12/07, Dino Viehland < dinov at exchange.microsoft.com> wrote: See http://channel9.msdn.com/wiki/default.aspx/IronPython.ValueTypes for an explanation of why you can't update value types. You might be able to call archiveData.set_OpenMode(1) after creating it though. From: users-bounces at lists.ironpython.com [mailto: users-bounces at lists.ironpython.com] On Behalf Of Ronny Stiftel Sent: Thursday, October 11, 2007 12:15 PM To: users at lists.ironpython.com Subject: [IronPython] Help with unrar.dll in ironpython Hi i am kinda new to ironpython and tried to use unrar in a project. Since i was unable to directly import it i made a .net wrapper dll (see attachment generate.py), works quite well only problem left now is: >> archiveData = unrar.RAROpenArchiveDataEx(OpenMode=1) ValueError: Attempt to update field 'OpenMode' on value type 'RAROpenArchiveDataEx'; value type fields cannot be directly modified guess there is an easy way to solve it, any help would be appreciated regards ronny _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Mon Oct 15 06:32:12 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 15 Oct 2007 13:32:12 +0900 Subject: [IronPython] Setting builtin_module_names Message-ID: <5b0248170710142132v59f9e6e9y34c69ae64cb1ce8d@mail.gmail.com> Currently, sys.builtin_module_names is set in IronPython.Runtime.SystemState.LoadBuiltins. But this method is called multiple times with assemblies, by default IronPython.dll and IronPython.Modules.dll. Doesn't this belog to InitializeBuiltins method, after Builtins dictionary is complete? Especially, renaming nt to posix happens after builtin_module_names is set, so this change isn't reflected there. And since os.py in the standard library uses builtin_module_names to detect platform, os.py is broken on Unix. Here's my suggested fix: https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/latest/patch-initialize-builtins -- Seo Sanghyeon From sanxiyn at gmail.com Mon Oct 15 15:38:54 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 15 Oct 2007 22:38:54 +0900 Subject: [IronPython] [ANN] IronPython Community Edition r7 Message-ID: <5b0248170710150638r7f405bb2l2a32d334e7ad4478@mail.gmail.com> This is the seventh release of IronPython Community Edition (IPCE). Download from SourceForge: http://sourceforge.net/projects/fepy FePy project aims to provide enhancements and add-ons for IronPython. http://fepy.sourceforge.net/ This work was in part supported by Mozilla Corporation. FePy project got a blog! http://fepy.blogspot.com/ FePy blog documents two developments not included in this release. Files under trunk/pyprof/, which tries to implement sys.setprofile with Mono profiler API. (Thanks to Miguel de Icaza and Paolo Molaro for help.) Files under bench/, which benchmarks simple IronPython programs to measure progress of Mono runtime. This release comes with both IronPython 1.1 and IronPython 2.0 Alpha 5. IronPython 1.x is stable on Mono. IronPython 2.x isn't. For example, importing string module will crash runtime for Mono 1.2.5. (But os module works fine, which is much more complex. It's a bit of hit and miss.) This release is built with Mono 1.2.5.1. The minimum Mono version needed to compile and run for IronPython 1.x is 1.2.3. For IronPython 2.x it's 1.2.5. Mono 1.2.5 and 1.2.5.1 are same except for ASP.NET bugfixes. DLR-based languages won't work with Mono versions before 1.2.5. Please check your Mono version before reporting any problems. Changes in this release follow. Contributions are credited in parentheses. IronPython IronPython 2.0 Alpha 5. Libraries dbapi module handles DBNull correctly. (Carsten Haese) pyexpat module handles DTD. (Shozo Arai) Bundles Following modules are now included: decimal, modulefinder, pkgutil, smtplib. pystone benchmark. (It's under Lib/test.) irclib, which works great. Try this example as a sanity test. https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/example/irc_test.py Patches Patches are documented here. http://fepy.sourceforge.net/patches.html New in this release: For 1.x patch-ironpython-option-s For 2.x patch-{325478,328022,333647} # Numbers refer to Mono bugs patch-console patch-cs0177 patch-debug-define patch-initialize-builtins Build system Use NAnt to build IronPython 2.x. Use quilt to manage patches. Patches to build all IronPython 2 Alpha releases. - AssemblyVersion.cs was missing in Alpha 3. (Miguel de Icaza) Include both IronPython 1.x and 2.x, but share the library using site.py. Misc Ms-PL is now included in licenses. -- Seo Sanghyeon From giles.thomas at resolversystems.com Mon Oct 15 17:15:35 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Mon, 15 Oct 2007 16:15:35 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <47138417.2030301@resolversystems.com> Curt Hagenlocher wrote: > My two cents would be this: using Managed C++, try for source compatibility first. Binary compatibility would be a great thing in the long term - after all, we don't want to run the risk of branching the target library's codebase! - but my gut feeling is that you're right, Curt: it would be much easier, at least as an exploratory first stage, to target source compatibility only. So perhaps we should start off in that direction. Does anyone know how this would impact the potential for Mono compatibility? Keith J. Farmer wrote: > NumPy would be cool :) That looks like a pretty popular choice generally - quite a few people have posted off-list saying the same. I'll get in touch with the NumPy developers. One further question for this list, before I create a repository and mailing list elsewhere for the project - what should the project be called? The best one we've come up with in-house is "RustPython" (IronPython, *C* extensions, you get the picture) and I'd be really grateful if someone could come up with a less appalling pun... Cheers, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From giles.thomas at resolversystems.com Mon Oct 15 17:16:30 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Mon, 15 Oct 2007 16:16:30 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <20253b0c0710130900g57a8e98cv1c96e449f651a227@mail.gmail.com> References: <470FA841.6020008@resolversystems.com> <20253b0c0710130900g57a8e98cv1c96e449f651a227@mail.gmail.com> Message-ID: <4713844E.5000207@resolversystems.com> Davy, What would the issues be with NumPy - just the size of the API that would have to be wrapped? I must admin that my biggest concern with this would be getting everything running under Mono... Cheers, Giles Davy Mitchell wrote: > On 10/12/07, Giles Thomas wrote: > >> Python and .NET, but also the existing CPython C extensions. >> > > Hi Giles, > > Sounds like a good idea and the approaches mentioned seemed solid. > > One strategy I was considering for a port of my Mood News site to > Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM > object using the win32 stuff and getting it into .Net via the COM > interop support. > > Maybe not practical for Numpy :-) Does have the advantage of not > having to modify the original lib... > > Cheers, > Davy > > -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From mclinton at procard.com Mon Oct 15 17:55:03 2007 From: mclinton at procard.com (Matt Clinton) Date: Mon, 15 Oct 2007 09:55:03 -0600 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <4713844E.5000207@resolversystems.com> References: <470FA841.6020008@resolversystems.com><20253b0c0710130900g57a8e98cv1c96e449f651a227@mail.gmail.com> <4713844E.5000207@resolversystems.com> Message-ID: <046C79B13A2D204A9FFB87C2EA406CA7029D79CE@glesexcc03.procard.local> NumPy is largely about speed, and going through extra interop layers can really bite into that (my $0.02). I think the suggestion for a smaller module to start with was about learning about compatibility with a more manageable chunk of code than the many, many lines of deep number-crunching that NumPy has accumulated, but maybe a few sections of compatibility there (i.e. limited part of the API) would be a similarly tractable goal? Wrapping the plain-C in COM would be a good way to test implementation compatibility, if your plan is to ported raw C to C++, so that the DLR/CLR can get some hooks in and go-quicka: the COM-wrapped CPy extensions may be faster to develop, if not performing as quickly, and if your C++ ports behave the same, you have pretty good confidence. Along the way, they'll help point out what's the framework and what's your code, especially if you can run the same test-cases through straight CPy. Wrapping all the way back through Mono seems an odd goal - isn't IPy compatible enough with CPy in source that your business apps would be light to port back to Cpy-land, if you're on Posix already anyway? For some purposes, it really makes sense, but a NumPy implementation for IPy for Mono? Seem to me that going that deep this soon will make you a valuable contributor to low-level compatibility testing... but I don't have the whole picture of where you're going. If you're going to alloy FePy, would that make a type of SteelPython? - a happier compound than Rust! Cheers, -- Matt ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Giles Thomas Sent: Monday, October 15, 2007 9:17 AM To: Discussion of IronPython Subject: Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython Davy, What would the issues be with NumPy - just the size of the API that would have to be wrapped? I must admin that my biggest concern with this would be getting everything running under Mono... Cheers, Giles Davy Mitchell wrote: On 10/12/07, Giles Thomas wrote: Python and .NET, but also the existing CPython C extensions. Hi Giles, Sounds like a good idea and the approaches mentioned seemed solid. One strategy I was considering for a port of my Mood News site to Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM object using the win32 stuff and getting it into .Net via the COM interop support. Maybe not practical for Numpy :-) Does have the advantage of not having to modify the original lib... Cheers, Davy -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Oct 15 18:01:04 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 15 Oct 2007 17:01:04 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <046C79B13A2D204A9FFB87C2EA406CA7029D79CE@glesexcc03.procard.local> References: <470FA841.6020008@resolversystems.com><20253b0c0710130900g57a8e98cv1c96e449f651a227@mail.gmail.com> <4713844E.5000207@resolversystems.com> <046C79B13A2D204A9FFB87C2EA406CA7029D79CE@glesexcc03.procard.local> Message-ID: <47138EC0.7030804@voidspace.org.uk> Matt Clinton wrote: > > NumPy is largely about speed, and going through extra interop layers > can really bite into that (my $0.02). > The reason that Numpy is much faster is because most of the work happens inside the C code, so a minor performance hit on the way in and out isn't necessarily a problem. > I think the suggestion for a smaller module to start with was about > learning about compatibility with a more manageable chunk of code than > the many, many lines of deep number-crunching that NumPy has > accumulated, but maybe a few sections of compatibility there (i.e. > limited part of the API) would be a similarly tractable goal? > Possibly. > > Wrapping the plain-C in COM would be a good way to test implementation > compatibility, > I'm not sure that COM is the way to go (because it does seem to insert an extra layer into the equation) - but it is certainly on the table. > if your plan is to ported raw C to C++, > That wasn't at all the *original* plan. :-) > so that the DLR/CLR can get some hooks in and go-quicka: > > the COM-wrapped CPy extensions may be faster to develop, if not > performing as quickly, > > and if your C++ ports behave the same, you have pretty good confidence. > > Along the way, they?ll help point out what?s the framework and what?s > your code, especially if you can run the same test-cases through > straight CPy. > > Wrapping all the way back through Mono seems an odd goal ? isn?t IPy > compatible enough with CPy in source that your business apps would be > light to port back to Cpy-land, if you?re on Posix already anyway? > No - our application is currently a .NET only (not Mono) application, with a heavy dependency on .NET for the user interface layer. So back porting the whole app. to CPython is not on the cards (for business reasons as well - getting the finance sector to install new technology is difficult, so a .NET based application will more easily be accepted by companies than a CPython one). > For some purposes, it really makes sense, but a NumPy implementation > for IPy for Mono? > We are not talking particularly about a new implementation, but finding a way of getting the current implementation to work. > Seem to me that going that deep this soon will make you a valuable > contributor to low-level compatibility testing? but I don?t have the > whole picture of where you?re going. > > If you?re going to alloy FePy, would that make a type of SteelPython? > ? a happier compound than Rust! > RustPython is one of the possible names (what happens when you introduce Iron to the Sea... Moray would be another one - a kind of Python that lives in the sea... better names solicited...) :-) Michael http://www.manning.com/foord > Cheers, > > -- Matt > > ------------------------------------------------------------------------ > > *From:* users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Giles Thomas > *Sent:* Monday, October 15, 2007 9:17 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Announcement: Project to get some CPython > C extensions running under IronPython > > Davy, > > What would the issues be with NumPy - just the size of the API that > would have to be wrapped? I must admin that my biggest concern with > this would be getting everything running under Mono... > > > Cheers, > > Giles > > > Davy Mitchell wrote: > > On 10/12/07, Giles Thomas wrote: > >> Python and .NET, but also the existing CPython C extensions. >> > > Hi Giles, > > Sounds like a good idea and the approaches mentioned seemed solid. > > One strategy I was considering for a port of my Mood News site to > Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM > object using the win32 stuff and getting it into .Net via the COM > interop support. > > Maybe not practical for Numpy :-) Does have the advantage of not > having to modify the original lib... > > Cheers, > Davy > > > > > > -- > Giles Thomas > MD & CTO, Resolver Systems Ltd. > giles.thomas at resolversystems.com > +44 (0) 20 7253 6372 > > We're hiring! http://www.resolversystems.com/jobs/ > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 > Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From sidnei at enfoldsystems.com Mon Oct 15 18:35:13 2007 From: sidnei at enfoldsystems.com (Sidnei da Silva) Date: Mon, 15 Oct 2007 13:35:13 -0300 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <47138417.2030301@resolversystems.com> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> Message-ID: On 10/15/07, Giles Thomas wrote: > One further question for this list, before I create a repository and mailing list elsewhere for the project - what should the project be called? The best one we've come up with in-house is "RustPython" (IronPython, *C* extensions, you get the picture) and I'd be really grateful if someone could come up with a less appalling pun... Ah, naming. My preferred subject. ;) Ok, you want it to imply a sense of 'old' or 'rough' or 'rotten' or 'crude', and yet have a cool name. Is 'Python' required to be part of the name? The first cool name that came to my mind was 'Monera'. It is a cool name because it refers (mostly) to prokaryotic organisms (organisms without a nucleus). It also resembles a bit 'Mono', which might be an useful association (Monera -> Mono, ah, so this is some thing related to .NET!). Another idea would be 'OxyPython', since it's the combination of Oxygen + Iron is that forms Rust. :) -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 From giles.thomas at resolversystems.com Mon Oct 15 19:17:14 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Mon, 15 Oct 2007 18:17:14 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> Message-ID: <4713A09A.2090703@resolversystems.com> Hmmm, we didn't really want to get the feeling of oldness or rottenness - it was just side-effect of a terrible pun on C/sea. If the pun not only is really bad but also falls flat, then it's definitely a bad name ;-) OxyPython sounds much cooler; but Python's definitely not required as part of the name. Sidnei da Silva wrote: > On 10/15/07, Giles Thomas wrote: > >> One further question for this list, before I create a repository and mailing list elsewhere for the project - what should the project be called? The best one we've come up with in-house is "RustPython" (IronPython, *C* extensions, you get the picture) and I'd be really grateful if someone could come up with a less appalling pun... >> > > Ah, naming. My preferred subject. ;) > > Ok, you want it to imply a sense of 'old' or 'rough' or 'rotten' or > 'crude', and yet have a cool name. Is 'Python' required to be part of > the name? > > The first cool name that came to my mind was 'Monera'. It is a cool > name because it refers (mostly) to prokaryotic organisms (organisms > without a nucleus). It also resembles a bit 'Mono', which might be an > useful association (Monera -> Mono, ah, so this is some thing related > to .NET!). > > Another idea would be 'OxyPython', since it's the combination of > Oxygen + Iron is that forms Rust. :) > > -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at msistone.com Mon Oct 15 19:49:13 2007 From: andy at msistone.com (Andy Shah) Date: Mon, 15 Oct 2007 10:49:13 -0700 Subject: [IronPython] Announcement: Project to get some CPython Cextensions running under IronPython References: <470FA841.6020008@resolversystems.com><7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com><47138417.2030301@resolversystems.com> Message-ID: <3D7CB0127A254149AB5C0939C828D930060229A2@mosaic.domain-msi.local> I am a nobody in this world... but to extend sidnei's second choice.. and the fact that we are extending *C* extensions... how about "CxyPython" 1) We are talkin of eXtending C (Cx) 2) Makes it sexy... (Cxy) Kind Regards, Anand Praivn Shah. ________________________________ From: users-bounces at lists.ironpython.com on behalf of Sidnei da Silva Sent: Mon 10/15/2007 9:35 AM To: Discussion of IronPython Subject: Re: [IronPython] Announcement: Project to get some CPython Cextensions running under IronPython On 10/15/07, Giles Thomas wrote: > One further question for this list, before I create a repository and mailing list elsewhere for the project - what should the project be called? The best one we've come up with in-house is "RustPython" (IronPython, *C* extensions, you get the picture) and I'd be really grateful if someone could come up with a less appalling pun... Ah, naming. My preferred subject. ;) Ok, you want it to imply a sense of 'old' or 'rough' or 'rotten' or 'crude', and yet have a cool name. Is 'Python' required to be part of the name? The first cool name that came to my mind was 'Monera'. It is a cool name because it refers (mostly) to prokaryotic organisms (organisms without a nucleus). It also resembles a bit 'Mono', which might be an useful association (Monera -> Mono, ah, so this is some thing related to .NET!). Another idea would be 'OxyPython', since it's the combination of Oxygen + Iron is that forms Rust. :) -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From joe at notcharles.ca Mon Oct 15 19:57:58 2007 From: joe at notcharles.ca (Joe Mason) Date: Mon, 15 Oct 2007 13:57:58 -0400 Subject: [IronPython] Announcement: Project to get some CPython Cextensions running under IronPython In-Reply-To: <3D7CB0127A254149AB5C0939C828D930060229A2@mosaic.domain-msi.local> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <3D7CB0127A254149AB5C0939C828D930060229A2@mosaic.domain-msi.local> Message-ID: On 10/15/07, Andy Shah wrote: > I am a nobody in this world... but to extend sidnei's second choice.. and the fact that we are extending *C* extensions... how about "CxyPython" Personally, I like the name "C Extensions for IronPython". It's descriptive. Joe From kfarmer at thuban.org Mon Oct 15 21:48:55 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 15 Oct 2007 12:48:55 -0700 Subject: [IronPython] Announcement: Project to get some CPythonCextensions running under IronPython References: <470FA841.6020008@resolversystems.com><7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com><47138417.2030301@resolversystems.com><3D7CB0127A254149AB5C0939C828D930060229A2@mosaic.domain-msi.local> Message-ID: I prefer Joe's suggestion, personally. But, for completeness: C Extensions for Microsoft .NET Dynamic Language Runtime [version?] with the Python Standard Library -- [Mono | Microsoft .NET | Cross-Platform] Edition ________________________________ From: users-bounces at lists.ironpython.com on behalf of Joe Mason Sent: Mon 10/15/2007 10:57 AM To: Discussion of IronPython Subject: Re: [IronPython] Announcement: Project to get some CPythonCextensions running under IronPython On 10/15/07, Andy Shah wrote: > I am a nobody in this world... but to extend sidnei's second choice.. and the fact that we are extending *C* extensions... how about "CxyPython" Personally, I like the name "C Extensions for IronPython". It's descriptive. Joe _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Mon Oct 15 22:02:12 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 15 Oct 2007 21:02:12 +0100 Subject: [IronPython] [python] Re: Announcement: Project to get some CPythonCextensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com><7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com><47138417.2030301@resolversystems.com><3D7CB0127A254149AB5C0939C828D930060229A2@mosaic.domain-msi.local> Message-ID: <4713C744.3030206@voidspace.org.uk> > Personally, I like the name "C Extensions for IronPython". It's descriptive. > > CexFIP Cex for IronPython ?? :-) Michael > Joe > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From vizcaynot at gmail.com Mon Oct 15 23:11:44 2007 From: vizcaynot at gmail.com (Vizcayno Tamparantan) Date: Mon, 15 Oct 2007 17:11:44 -0400 Subject: [IronPython] Can anybody reproduce this issue under ipy 2.0 a5 (expr if cond else expr)? Message-ID: For ipy 2.0 alpha 5, try this: h = 'hello' b = 'bye' print h if h=='hello' else b print h if h=="hello" else "bye" Results are: >>> h = 'hello' >>> b = 'bye' >>> print h if h=='hello' else b hello >>> print h if h=="hello" else "bye" Traceback (most recent call last): ValueError: Types must match Parameter name: ifTrue In Cpython 2.5 and ipy 2.0 a4 I don't have this problem. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfugate at microsoft.com Mon Oct 15 23:43:42 2007 From: dfugate at microsoft.com (Dave Fugate) Date: Mon, 15 Oct 2007 14:43:42 -0700 Subject: [IronPython] Can anybody reproduce this issue under ipy 2.0 a5 (expr if cond else expr)? In-Reply-To: References: Message-ID: <7346A825E148B049A9AD1D3ED46A2D91169C380877@NA-EXMSG-C106.redmond.corp.microsoft.com> Thanks for reporting this! I've filed the bug report here - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13320. Dave From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Vizcayno Tamparantan Sent: Monday, October 15, 2007 2:12 PM To: users at lists.ironpython.com Subject: [IronPython] Can anybody reproduce this issue under ipy 2.0 a5 (expr if cond else expr)? For ipy 2.0 alpha 5, try this: h = 'hello' b = 'bye' print h if h=='hello' else b print h if h=="hello" else "bye" Results are: >>> h = 'hello' >>> b = 'bye' >>> print h if h=='hello' else b hello >>> print h if h=="hello" else "bye" Traceback (most recent call last): ValueError: Types must match Parameter name: ifTrue In Cpython 2.5 and ipy 2.0 a4 I don't have this problem. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Tue Oct 16 01:17:24 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 16 Oct 2007 00:17:24 +0100 Subject: [IronPython] [python] Re: Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <47138417.2030301@resolversystems.com> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> Message-ID: <4713F504.4070301@voidspace.org.uk> Giles Thomas wrote: > [snip..] > That looks like a pretty popular choice generally - quite a few people have posted off-list saying the same. I'll get in touch with the NumPy developers. > > One further question for this list, before I create a repository and mailing list elsewhere for the project - what should the project be called? The best one we've come up with in-house is "RustPython" (IronPython, *C* extensions, you get the picture) and I'd be really grateful if someone could come up with a less appalling pun... > > Aipysurus - a genus of sea snake with the letters 'py' in its name? http://en.wikipedia.org/wiki/Aipysurus The "Aipysurus laevis" is also known as the golden sea snake! :-) Michael > Cheers, > > Giles > From aschaeffer at northps.com Tue Oct 16 03:22:24 2007 From: aschaeffer at northps.com (Andrew Schaeffer) Date: Mon, 15 Oct 2007 21:22:24 -0400 Subject: [IronPython] [python] Re: Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <4713F504.4070301@voidspace.org.uk> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <4713F504.4070301@voidspace.org.uk> Message-ID: <735AC5A411C8A14498A8E7C129FCFADB0710478C51@119565-MAIL1.northps.com> This may be a stretch here but how about Pymento? >From pimento -- a pepper in the chili family that are grown and used throughout the world because of their many flavors and flexible uses. Drew Schaeffer NorthPoint Solutions, LLC 130 West 42nd Street New York, NY 10036 T: 212-819-1700 F: 212-398-5533 http://www.northps.com -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, October 15, 2007 7:17 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Announcement: Project to get some CPython C extensions running under IronPython Giles Thomas wrote: > [snip..] > That looks like a pretty popular choice generally - quite a few people have posted off-list saying the same. I'll get in touch with the NumPy developers. > > One further question for this list, before I create a repository and mailing list elsewhere for the project - what should the project be called? The best one we've come up with in-house is "RustPython" (IronPython, *C* extensions, you get the picture) and I'd be really grateful if someone could come up with a less appalling pun... > > Aipysurus - a genus of sea snake with the letters 'py' in its name? http://en.wikipedia.org/wiki/Aipysurus The "Aipysurus laevis" is also known as the golden sea snake! :-) Michael > Cheers, > > Giles > _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From giles.thomas at resolversystems.com Tue Oct 16 14:04:04 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Tue, 16 Oct 2007 13:04:04 +0100 Subject: [IronPython] [python] Re: Announcement: Project to get some CPythonCextensions running under IronPython In-Reply-To: <4713C744.3030206@voidspace.org.uk> References: <470FA841.6020008@resolversystems.com><7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com><47138417.2030301@resolversystems.com><3D7CB0127A254149AB5C0939C828D930060229A2@mosaic.domain-msi.local> <4713C744.3030206@voidspace.org.uk> Message-ID: <4714A8B4.1030509@resolversystems.com> In an appropriately Pythonesque manner, this is getting very silly :-) Let's go for "C Extensions for IronPython". I'll set up a mailing list and post the details here. Regards, Giles Michael Foord wrote: >> Personally, I like the name "C Extensions for IronPython". It's descriptive. >> >> >> > > CexFIP > > Cex for IronPython ?? > > :-) > > Michael > > > >> Joe >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Tue Oct 16 14:29:57 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Tue, 16 Oct 2007 13:29:57 +0100 Subject: [IronPython] [python] Re: Announcement: Project to get some CPythonCextensions running under IronPython In-Reply-To: <4714A8B4.1030509@resolversystems.com> References: <470FA841.6020008@resolversystems.com><7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com><47138417.2030301@resolversystems.com><3D7CB0127A254149AB5C0939C828D930060229A2@mosaic.domain-msi.local> <4713C744.3030206@voidspace.org.uk> <4714A8B4.1030509@resolversystems.com> Message-ID: <4714AEC5.9010806@resolversystems.com> I've set up a Google Group for the project; if you're interested in participating, you can sign up here: Thanks, Giles Giles Thomas wrote: > In an appropriately Pythonesque manner, this is getting very silly :-) > > Let's go for "C Extensions for IronPython". I'll set up a mailing > list and post the details here. > > > Regards, > > Giles > > > Michael Foord wrote: >>> Personally, I like the name "C Extensions for IronPython". It's descriptive. >>> >>> >>> >> >> CexFIP >> >> Cex for IronPython ?? >> >> :-) >> >> Michael >> >> >> >>> Joe >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > -- > Giles Thomas > MD & CTO, Resolver Systems Ltd. > giles.thomas at resolversystems.com > +44 (0) 20 7253 6372 > > We're hiring! http://www.resolversystems.com/jobs/ > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 > Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From daftspaniel at gmail.com Tue Oct 16 22:21:53 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Tue, 16 Oct 2007 21:21:53 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <4713844E.5000207@resolversystems.com> References: <470FA841.6020008@resolversystems.com> <20253b0c0710130900g57a8e98cv1c96e449f651a227@mail.gmail.com> <4713844E.5000207@resolversystems.com> Message-ID: <20253b0c0710161321y678cbc10j1909d5a94b83f8d9@mail.gmail.com> > What would the issues be with NumPy - just the size of the API that I was most concerned with data types (and converting) which for statistical based computing needs to be exact. It is a great plus for DotNet to have common types between languages. After working for years in mixed VB6/C++ COM applications I really appreciate that :-) Are Resolver Users looking to reuse their existing code in spreadsheets or just have the same facilities? If the latter then SWIG for Dotnet seems a better option than COM and is more Mono friendly. Cheers, Davy On 10/15/07, Giles Thomas wrote: > > Davy, > > What would the issues be with NumPy - just the size of the API that would > have to be wrapped? I must admin that my biggest concern with this would be > getting everything running under Mono... > > > Cheers, > > Giles > > > Davy Mitchell wrote: > On 10/12/07, Giles Thomas > wrote: > > > Python and .NET, but also the existing CPython C extensions. > > Hi Giles, > > Sounds like a good idea and the approaches mentioned seemed solid. > > One strategy I was considering for a port of my Mood News site to > Ironpython (but not tried yet!) is wrapping a CPython Lib into a COM > object using the win32 stuff and getting it into .Net via the COM > interop support. > > Maybe not practical for Numpy :-) Does have the advantage of not > having to modify the original lib... > > Cheers, > Davy > > > > -- > Giles Thomas > MD & CTO, Resolver Systems Ltd. > giles.thomas at resolversystems.com > +44 (0) 20 7253 6372 > > We're hiring! http://www.resolversystems.com/jobs/ > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 > Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From joshua.pearce at gmail.com Tue Oct 16 23:08:04 2007 From: joshua.pearce at gmail.com (Joshua J. Pearce) Date: Tue, 16 Oct 2007 17:08:04 -0400 Subject: [IronPython] Need a Good Embedded Example Message-ID: <278e6e410710161408h58c0f889r8d2c5281da228ce6@mail.gmail.com> I have been looking for a good example of embedding IronPython in a c# application. I am under the impression that there have been some major changes in the way this is done from version 1.1 to 2.0. This is what I found at the Python Cookbook site: namespace IronPythonScriptHost { class Program { static void Main(string[] args) { string code = "print \"Hello \" + Name"; Script.SetVariable("Name", "Me"); Script.Execute("py", code); } } } That's nice, but doesn't really help me to know how to get variable output from the script back to my c# code. I also need to know how to call scripts with multiple statements and whether all variables need to be set on the script object, or can their declaration just be part of the script code. Is there a good and simple example anywhere that shows how to host the IronPython engine in a c# app and let users manipulate your program objects via ipy scripts? Thanks! -- Joshua Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Tue Oct 16 23:32:44 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 16 Oct 2007 14:32:44 -0700 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <278e6e410710161408h58c0f889r8d2c5281da228ce6@mail.gmail.com> References: <278e6e410710161408h58c0f889r8d2c5281da228ce6@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227D850A1C118@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Are you looking for samples in v1.0 or v2.0? The code you quoted below is some version of v2.0 (we're still working on the final tweaks to what will become the new, final, hosting model). From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Joshua J. Pearce Sent: Tuesday, October 16, 2007 2:08 PM To: users at lists.ironpython.com Subject: [IronPython] Need a Good Embedded Example I have been looking for a good example of embedding IronPython in a c# application. I am under the impression that there have been some major changes in the way this is done from version 1.1 to 2.0. This is what I found at the Python Cookbook site: namespace IronPythonScriptHost { class Program { static void Main(string[] args) { string code = "print \"Hello \" + Name"; Script.SetVariable ("Name", "Me"); Script.Execute("py", code); } } } That's nice, but doesn't really help me to know how to get variable output from the script back to my c# code. I also need to know how to call scripts with multiple statements and whether all variables need to be set on the script object, or can their declaration just be part of the script code. Is there a good and simple example anywhere that shows how to host the IronPython engine in a c# app and let users manipulate your program objects via ipy scripts? Thanks! -- Joshua Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From daftspaniel at gmail.com Tue Oct 16 23:39:57 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Tue, 16 Oct 2007 22:39:57 +0100 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <7AD436E4270DD54A94238001769C2227D850A1C118@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <278e6e410710161408h58c0f889r8d2c5281da228ce6@mail.gmail.com> <7AD436E4270DD54A94238001769C2227D850A1C118@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <20253b0c0710161439j583ab930y9d139025cef7ea5d@mail.gmail.com> Hi Dino, Is this why I am having trouble with the pyc.py sample? It does say 1.01 in the description so maybe I should expect issues :-) Traceback (most recent call last): File pyc.py, line 35, in Initialize File , line 0, in _stub_##227 AttributeError: 'NamespaceTracker' object has no attribute 'CompilerSink' Thanks, Davy On 10/16/07, Dino Viehland wrote: > > > > > Are you looking for samples in v1.0 or v2.0? The code you quoted below is > some version of v2.0 (we're still working on the final tweaks to what will > become the new, final, hosting model). > > > > > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of > Joshua J. Pearce > Sent: Tuesday, October 16, 2007 2:08 PM > To: users at lists.ironpython.com > Subject: [IronPython] Need a Good Embedded Example > > > > > > I have been looking for a good example of embedding IronPython in a c# > application. I am under the impression that there have been some major > changes in the way this is done from version 1.1 to 2.0. > > > > > > This is what I found at the Python Cookbook site: > > > > > > namespace IronPythonScriptHost > { > class Program > { > static void Main(string[] args) > { > string code = "print \"Hello \" + Name"; > Script.SetVariable ("Name", "Me"); > Script.Execute("py", code); > } > } > } > > > > > > That's nice, but doesn't really help me to know how to get variable output > from the script back to my c# code. I also need to know how to call scripts > with multiple statements and whether all variables need to be set on the > script object, or can their declaration just be part of the script code. > > > > > > Is there a good and simple example anywhere that shows how to host the > IronPython engine in a c# app and let users manipulate your program objects > via ipy scripts? > > > > > > Thanks! > > -- > Joshua Pearce > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From dinov at exchange.microsoft.com Wed Oct 17 00:19:34 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 16 Oct 2007 15:19:34 -0700 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <20253b0c0710161439j583ab930y9d139025cef7ea5d@mail.gmail.com> References: <278e6e410710161408h58c0f889r8d2c5281da228ce6@mail.gmail.com> <7AD436E4270DD54A94238001769C2227D850A1C118@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <20253b0c0710161439j583ab930y9d139025cef7ea5d@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227D850A1C155@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Yep, we've temporarily ripped out all pre-compilation support from v2.0 to make the refactoring work easier so pyc definitely won't work there (and there's really no way to make it work there w/o a rather large amount of work). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Tuesday, October 16, 2007 2:40 PM To: Discussion of IronPython Subject: Re: [IronPython] Need a Good Embedded Example Hi Dino, Is this why I am having trouble with the pyc.py sample? It does say 1.01 in the description so maybe I should expect issues :-) Traceback (most recent call last): File pyc.py, line 35, in Initialize File , line 0, in _stub_##227 AttributeError: 'NamespaceTracker' object has no attribute 'CompilerSink' Thanks, Davy On 10/16/07, Dino Viehland wrote: > > > > > Are you looking for samples in v1.0 or v2.0? The code you quoted below is > some version of v2.0 (we're still working on the final tweaks to what will > become the new, final, hosting model). > > > > > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of > Joshua J. Pearce > Sent: Tuesday, October 16, 2007 2:08 PM > To: users at lists.ironpython.com > Subject: [IronPython] Need a Good Embedded Example > > > > > > I have been looking for a good example of embedding IronPython in a c# > application. I am under the impression that there have been some major > changes in the way this is done from version 1.1 to 2.0. > > > > > > This is what I found at the Python Cookbook site: > > > > > > namespace IronPythonScriptHost > { > class Program > { > static void Main(string[] args) > { > string code = "print \"Hello \" + Name"; > Script.SetVariable ("Name", "Me"); > Script.Execute("py", code); > } > } > } > > > > > > That's nice, but doesn't really help me to know how to get variable output > from the script back to my c# code. I also need to know how to call scripts > with multiple statements and whether all variables need to be set on the > script object, or can their declaration just be part of the script code. > > > > > > Is there a good and simple example anywhere that shows how to host the > IronPython engine in a c# app and let users manipulate your program objects > via ipy scripts? > > > > > > Thanks! > > -- > Joshua Pearce > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From lupus at ximian.com Wed Oct 17 16:16:36 2007 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 17 Oct 2007 16:16:36 +0200 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <47138417.2030301@resolversystems.com> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> Message-ID: <20071017141636.GD27285@debian.org> On 10/15/07 Giles Thomas wrote: > Curt Hagenlocher wrote: > > My two cents would be this: using Managed C++, try for source > compatibility first. As python extensions use a C API, I don't see how Managed C++ would provide source compatibility. Managed C++ would be an ill-advided method, IMHO. > Binary compatibility would be a great thing in the long term - after > all, we don't want to run the risk of branching the target library's > codebase! - but my gut feeling is that you're right, Curt: it would be > much easier, at least as an exploratory first stage, to target source > compatibility only. So perhaps we should start off in that direction. I agree you should aim for source compatibility first, it's not like people commonly use binary proprietary python modules (and if they do it's the same people that wrote them and so can recompile). Binary compatibility is harder to prove correct, anyway and you'll have already your share of issues to overcome:) > Does anyone know how this would impact the potential for Mono compatibility? A Managed C++ implementation would be pretty useless for a mono port, but I think it would be pretty useless for the .net runtime, as you need to expose a C API anyway. You'd have two components: the C API headers and some C code (this is required in any case) is the first. Then you need an assembly that translates from the C API to the IronPython model. You can write this in nice C# + a few dllimports or with the ugly managed C++ (assuming managed C++ can actually consume the python headers). lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From curt at hagenlocher.org Wed Oct 17 16:44:04 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 17 Oct 2007 07:44:04 -0700 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <20071017141636.GD27285@debian.org> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> Message-ID: On 10/17/07, Paolo Molaro wrote: > As python extensions use a C API, I don't see how Managed C++ > would provide source compatibility. Managed C++ would be an ill-advided > method, IMHO. > [...] > You'd have two components: the C API headers and some C code (this is > required in any case) is the first. Then you need an assembly that > translates from the C API to the IronPython model. You can write this > in nice C# + a few dllimports or with the ugly managed C++ (assuming > managed C++ can actually consume the python headers). > MC++ lets you create a single module that contains both "normal" machine code and MSIL, and takes care of the transitions between the two. There's no reason you can't compile the existing C code and link it directly with the MC++ wrapper -- which is exactly what I originally meant. > A Managed C++ implementation would be pretty useless for a mono port, > but I think it would be pretty useless for the .net runtime, as you need > to expose a C API anyway. > Of course, if Managed C++ isn't supported by Mono, that's probably a sufficiently good reason not to take this approach. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Wed Oct 17 16:58:19 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Wed, 17 Oct 2007 15:58:19 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> Message-ID: <4716230B.3000303@resolversystems.com> Curt Hagenlocher wrote: > On 10/17/07, *Paolo Molaro* > wrote: > > As python extensions use a C API, I don't see how Managed C++ > would provide source compatibility. Managed C++ would be an > ill-advided > method, IMHO. > [...] > You'd have two components: the C API headers and some C code (this is > required in any case) is the first. Then you need an assembly that > translates from the C API to the IronPython model. You can write this > in nice C# + a few dllimports or with the ugly managed C++ (assuming > managed C++ can actually consume the python headers). > > > MC++ lets you create a single module that contains both "normal" > machine code and MSIL, and takes care of the transitions between the > two. There's no reason you can't compile the existing C code and link > it directly with the MC++ wrapper -- which is exactly what I > originally meant. Curt - how does MC++ relate to using P/Invoke? That is, is it P/Invoke plus some clever packaging stuff to allow you to produce a single assembly with both machine code and MSIL, or is there more to it than that? Or is it something completely different? Regards, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Wed Oct 17 17:17:13 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 17 Oct 2007 08:17:13 -0700 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <4716230B.3000303@resolversystems.com> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <4716230B.3000303@resolversystems.com> Message-ID: On 10/17/07, Giles Thomas wrote: > > Curt - how does MC++ relate to using P/Invoke? That is, is it P/Invoke > plus some clever packaging stuff to allow you to produce a single assembly > with both machine code and MSIL, or is there more to it than that? Or is it > something completely different? > I'd guess they share some internals -- why write the same thunking code twice, after all. But their usage patterns are sufficiently different that I'd argue the internals don't really matter. P/Invoke requires you to declare everything explicitly, while the goal for MC++ is to make interop as transparent as possible. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Wed Oct 17 17:35:21 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Wed, 17 Oct 2007 16:35:21 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <4716230B.3000303@resolversystems.com> Message-ID: <47162BB9.10405@resolversystems.com> Curt Hagenlocher wrote: > I'd guess they share some internals -- why write the same thunking > code twice, after all. But their usage patterns are sufficiently > different that I'd argue the internals don't really matter. P/Invoke > requires you to declare everything explicitly, while the goal for MC++ > is to make interop as transparent as possible. I must admit I'd also misunderstood how a MC++ option would work, in the same way as Paolo Molaro, but this sounds really useful. Is there any particular resource you'd recommend for learning more about it? Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From giles.thomas at resolversystems.com Wed Oct 17 18:13:58 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Wed, 17 Oct 2007 17:13:58 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <20253b0c0710161321y678cbc10j1909d5a94b83f8d9@mail.gmail.com> References: <470FA841.6020008@resolversystems.com> <20253b0c0710130900g57a8e98cv1c96e449f651a227@mail.gmail.com> <4713844E.5000207@resolversystems.com> <20253b0c0710161321y678cbc10j1909d5a94b83f8d9@mail.gmail.com> Message-ID: <471634C6.9050505@resolversystems.com> Davy Mitchell wrote: > Are Resolver Users looking to reuse their existing code in > spreadsheets or just have the same facilities? If the latter then SWIG > for Dotnet seems a better option than COM and is more Mono friendly. > I think having the same facilities is vital, but having the same interface is very important. If I understand it correctly, the problem with SWIG is that it relies on there already existing a solid, well-designed C API which can be wrapped - which is the case for NumPy, but isn't for C extensions in general AFAIK. Regards, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From curt at hagenlocher.org Wed Oct 17 18:23:23 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 17 Oct 2007 09:23:23 -0700 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <47162BB9.10405@resolversystems.com> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <4716230B.3000303@resolversystems.com> <47162BB9.10405@resolversystems.com> Message-ID: On 10/17/07, Giles Thomas wrote: > > > I must admit I'd also misunderstood how a MC++ option would work, in the > same way as Paolo Molaro, but this sounds really useful. Is there any > particular resource you'd recommend for learning more about it? Perhaps you should read this link first: http://www.mono-project.com/CPlusPlus I've obviously given the impression that I have quite a bit more experience with MC++ than is actually the case. Although I spent some time studying the technology for possible use, my real-world experience with it is pretty limited. A good friend made extensive use of it at his previous job. They reported lots of problems under 1.0 and 1.1, but were quite happy with the robustness and syntactical improvements made for 2.0. He says that -- for integrating a "legacy" C or C++ codebase into the CLR environment -- he would use it again in a heartbeat. But I would expect that Mono-compatibility is especially critical for this project. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From lupus at ximian.com Wed Oct 17 18:26:36 2007 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 17 Oct 2007 18:26:36 +0200 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> Message-ID: <20071017162636.GH27285@debian.org> On 10/17/07 Curt Hagenlocher wrote: > On 10/17/07, Paolo Molaro wrote: > > As python extensions use a C API, I don't see how Managed C++ > > would provide source compatibility. Managed C++ would be an ill-advided > > method, IMHO. > > [...] > > You'd have two components: the C API headers and some C code (this is > > required in any case) is the first. Then you need an assembly that > > translates from the C API to the IronPython model. You can write this > > in nice C# + a few dllimports or with the ugly managed C++ (assuming > > managed C++ can actually consume the python headers). > > > > MC++ lets you create a single module that contains both "normal" machine > code and MSIL, and takes care of the transitions between the two. There's > no reason you can't compile the existing C code and link it directly with > the MC++ wrapper -- which is exactly what I originally meant. The python API requires a couple dozen structure definitions plus a few dozen dllimport declarations. This can be about 200 lines of trivial to write declarative stuff. The rest of the code is likely in the order of 50 K lines, so now ask yourself: would you rather write a) 50 K lines of nice C# code + 200 lines of trivial declarations or b) 50 K lines of orrible C++ code? I know what I would answer:) The managed C++ discussion is focused on avoiding the 200 lines of trivial declarations, when the issue is the 50 KLOC. Managed C++ might make sense if you have lots of legacy C++ code you need to integrate (at least until MS itself will pull the plug on it). For new code like this case, managed C++ is the wrong tool, IMHO. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Wed Oct 17 18:34:48 2007 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 17 Oct 2007 18:34:48 +0200 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <47162BB9.10405@resolversystems.com> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <4716230B.3000303@resolversystems.com> <47162BB9.10405@resolversystems.com> Message-ID: <20071017163448.GI27285@debian.org> On 10/17/07 Giles Thomas wrote: > I must admit I'd also misunderstood how a MC++ option would work, in the > same way as Paolo Molaro, but this sounds really useful. Is there any I don't think I misunderstood anything:) I said that there are two modules, the C one and the one that bridges the C code to the ironpython world. That the two modules can be combined into the same binary image doesn't change the fact that they are two different things, it's just an implementation detail. Thanks! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From giles.thomas at resolversystems.com Wed Oct 17 18:39:32 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Wed, 17 Oct 2007 17:39:32 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <20071017163448.GI27285@debian.org> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <4716230B.3000303@resolversystems.com> <47162BB9.10405@resolversystems.com> <20071017163448.GI27285@debian.org> Message-ID: <47163AC4.6080705@resolversystems.com> Sounds like I misunderstood you too, then :-) Paolo Molaro wrote: > On 10/17/07 Giles Thomas wrote: > >> I must admit I'd also misunderstood how a MC++ option would work, in the >> same way as Paolo Molaro, but this sounds really useful. Is there any >> > > I don't think I misunderstood anything:) > I said that there are two modules, the C one and the one that bridges > the C code to the ironpython world. That the two modules can be combined > into the same binary image doesn't change the fact that they are two > different things, it's just an implementation detail. > Thanks! > > lupus > > -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Wed Oct 17 18:45:50 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 17 Oct 2007 09:45:50 -0700 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <20071017162636.GH27285@debian.org> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <20071017162636.GH27285@debian.org> Message-ID: On 10/17/07, Paolo Molaro wrote: > > > The python API requires a couple dozen structure definitions plus a few > dozen dllimport declarations. This can be about 200 lines of trivial > to write declarative stuff. I'm having trouble understanding what you mean by this. Let's say I've got an extension method that looks like this: PyObject * ModifyColumns(PyObject * self, PyObject * args) { PyObject * columns; if (!PyArg_ParseTuple(args, "O", &columns)) { return NULL; } if (!PySequence_Check(columns)) { PyErr_SetString(PyExc_ValueError, "parameter must be a sequence"); return NULL; } PyObject * result = PyTuple_New(PySequence_Length(columns)); for (int i = 0; i < PySequence_Length(columns); i++) { PyObject * value = PySequence_GetItem(sequence, i); // Do something to value // And make sure you don't screw up the reference count PySequence_SetItem(result, i, value); } return result; } In order to use this extension from IronPython, I need C implementations of each of those API functions. The PySequence_ methods should to be able to understand CLR arrays or any other IEnumerable-like object. I'm not sure what PyTuple_New should return, but whatever it is will need to have PyObject*-like semantics. How does DllImport fit into this picture? How can I avoid implementing all these functions in C or C++? -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua.pearce at gmail.com Wed Oct 17 19:00:05 2007 From: joshua.pearce at gmail.com (Joshua J. Pearce) Date: Wed, 17 Oct 2007 13:00:05 -0400 Subject: [IronPython] Need a Good Embedded Example Message-ID: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> I am looking for an embedded IronPython 2.0 example beyond the simple hello world one I quoted before. What I want to know is: 1) How to get variable output from the script back to my c# code. 2) How to call scripts with multiple statements. 3) Do all variables need to be set on the script object, or can their declaration just be part of the script code? 4) Is there a good and simple example anywhere that shows how to host the IronPython engine in a c# app and let users manipulate your program objects via ipy scripts? 5) How can I expose c# methods to as IPY functions? Thanks, -- Joshua Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From lupus at ximian.com Wed Oct 17 19:02:05 2007 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 17 Oct 2007 19:02:05 +0200 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <20071017162636.GH27285@debian.org> Message-ID: <20071017170205.GK27285@debian.org> On 10/17/07 Curt Hagenlocher wrote: > On 10/17/07, Paolo Molaro wrote: > > The python API requires a couple dozen structure definitions plus a few > > dozen dllimport declarations. This can be about 200 lines of trivial > > to write declarative stuff. > > I'm having trouble understanding what you mean by this. Let's say I've got > an extension method that looks like this: > > PyObject * ModifyColumns(PyObject * self, PyObject * args) > { [...] > In order to use this extension from IronPython, I need C implementations of > each of those API functions. The PySequence_ methods should to be able to > understand CLR arrays or any other IEnumerable-like object. I'm not sure > what PyTuple_New should return, but whatever it is will need to have > PyObject*-like semantics. > > How does DllImport fit into this picture? How can I avoid implementing all > these functions in C or C++? You do need to write C code as the API is a C API. I didn't list in the last mail because the C implementation of these functions is not a difference between the C# impl and the C++ impl of the rest of the code. The dllimport declarations I mentioned above would pinvoke to these C functions. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From tony at v-sim.com Wed Oct 17 20:07:34 2007 From: tony at v-sim.com (Tony Djordjevski) Date: Wed, 17 Oct 2007 14:07:34 -0400 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <20071017170205.GK27285@debian.org> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <20071017162636.GH27285@debian.org> <20071017170205.GK27285@debian.org> Message-ID: <47164F66.9030606@v-sim.com> Paolo Molaro wrote: > On 10/17/07 Curt Hagenlocher wrote: >> On 10/17/07, Paolo Molaro wrote: >>> The python API requires a couple dozen structure definitions plus a few >>> dozen dllimport declarations. This can be about 200 lines of trivial >>> to write declarative stuff. >> I'm having trouble understanding what you mean by this. Let's say I've got >> an extension method that looks like this: >> >> PyObject * ModifyColumns(PyObject * self, PyObject * args) >> { > [...] >> In order to use this extension from IronPython, I need C implementations of >> each of those API functions. The PySequence_ methods should to be able to >> understand CLR arrays or any other IEnumerable-like object. I'm not sure >> what PyTuple_New should return, but whatever it is will need to have >> PyObject*-like semantics. >> >> How does DllImport fit into this picture? How can I avoid implementing all >> these functions in C or C++? > > You do need to write C code as the API is a C API. I didn't list in the > last mail because the C implementation of these functions is not a > difference between the C# impl and the C++ impl of the rest of the code. > The dllimport declarations I mentioned above would pinvoke to these C > functions. > Those C functions you speak about will need to execute managed code. So, either way, what needs to be done is to allow "Reverse P/Invoke" or some form of DllExport. Assuming this project is successful, native C/C++ will have to, at some point, execute managed code. There are only two ways that I know of that you can accomplish this in .NET: 1. C++ Interop 2. Modifying a compiled assembly Option 1 has the disadvantage of not working in Mono (for now), but I think is a "cleaner" solution. Option 2 requires a post build event and I have no idea how that will affect Mono, as I don't use Mono or ever tried this approach. This article briefly discusses the method: http://www.codeproject.com/useritems/DllExport.asp The Cecil project might help with this, though I'm not sure: http://www.mono-project.com/Cecil PostSharp might be able to do this as well (again, I've never used it): http://www.postsharp.org/ Regards, Tony From dinov at exchange.microsoft.com Wed Oct 17 20:29:45 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 17 Oct 2007 11:29:45 -0700 Subject: [IronPython] Setting builtin_module_names In-Reply-To: <5b0248170710142132v59f9e6e9y34c69ae64cb1ce8d@mail.gmail.com> References: <5b0248170710142132v59f9e6e9y34c69ae64cb1ce8d@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227D850A1C362@DF-GRTDANE-MSG.exchange.corp.microsoft.com> You're right - I think the logic might have been to reflect "new" built-in modules which are added externally, but it doesn't look like CPython does this (for example _socket isn't in the list). I'll check-in a fix for this for the next release. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Sunday, October 14, 2007 9:32 PM To: Discussion of IronPython Subject: [IronPython] Setting builtin_module_names Currently, sys.builtin_module_names is set in IronPython.Runtime.SystemState.LoadBuiltins. But this method is called multiple times with assemblies, by default IronPython.dll and IronPython.Modules.dll. Doesn't this belog to InitializeBuiltins method, after Builtins dictionary is complete? Especially, renaming nt to posix happens after builtin_module_names is set, so this change isn't reflected there. And since os.py in the standard library uses builtin_module_names to detect platform, os.py is broken on Unix. Here's my suggested fix: https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/latest/patch-initialize-builtins -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From mosterhouse2000 at yahoo.com Wed Oct 17 21:36:25 2007 From: mosterhouse2000 at yahoo.com (Allison Day) Date: Wed, 17 Oct 2007 12:36:25 -0700 (PDT) Subject: [IronPython] Using IP with Idle Message-ID: <552914.35876.qm@web60311.mail.yahoo.com> I have been using python in a unix environment for years and am a complete noob to iron python, windows, and .net as of yesterday (GAAAACK! says the Linux Guy :-) so please be patient. I was looking to use Idle with Ironpython but am not sure how to do this or if it can be done. I saw a reference or two to Idle in the archives, but nothing concrete. I've set the windows path to: C:\Program Files\activeTcl\bin;C:\Program Files\MTS 793\ntbin;C:\Program Files\Common Files\MTS Shared;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;c:\IronPython-1.1; I was reading a few IP articles and they mentioned setting the path, so I tried that and then importing System, but System isn't found. I don't yet understand the relationship between CPython and IP, so maybe idle can't be used. I want idle for the editing capabilities and so on that I'm used to using in the unix environment. So can Idle be used and if not, what else has the formatting that idle does? One guy here using a regular text editor and runs a batch file, but I'm hoping for a little more interactive environment. For licensing reasons, visual studio is a not an option for me at the moment but might be in the future. Again, I'm a complete Noob so forgive me if this question is too easy. Thanks. A.D. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Wed Oct 17 21:42:44 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 17 Oct 2007 20:42:44 +0100 Subject: [IronPython] [python] Using IP with Idle In-Reply-To: <552914.35876.qm@web60311.mail.yahoo.com> References: <552914.35876.qm@web60311.mail.yahoo.com> Message-ID: <471665B4.2020704@voidspace.org.uk> Allison Day wrote: > I have been using python in a unix environment for years and am a > complete noob to iron python, windows, and .net as of yesterday > (GAAAACK! says the Linux Guy :-) so please be patient. > > I was looking to use Idle with Ironpython but am not sure how to do > this or if it can be done. I saw a reference or two to Idle in the > archives, but nothing concrete. I've set the windows path to: > > C:\Program Files\activeTcl\bin;C:\Program Files\MTS > 793\ntbin;C:\Program Files\Common Files\MTS > Shared;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;c:\IronPython-1.1; > > I was reading a few IP articles and they mentioned setting the path, > so I tried that and then importing System, but System isn't found. I > don't yet understand the relationship between CPython and IP, so maybe > idle can't be used. I want idle for the editing capabilities and so > on that I'm used to using in the unix environment. > > So can Idle be used and if not, what else has the formatting that idle > does? One guy here using a regular text editor and runs a batch file, > but I'm hoping for a little more interactive environment. For > licensing reasons, visual studio is a not an option for me at the > moment but might be in the future. Well, you can edit IronPython code with IDLE - but I don't think you'll be able to run it. Keeping a command line window opening whilst editing with IDLE is pretty easy. Alternatively use a slightly more 'featured' editor that allows you to run files with an external command (most text editors will do this - plus it can be done with Python IDEs like SPE, Wing and probably Komodo). Michael http://www.manning.com/foord > > Again, I'm a complete Noob so forgive me if this question is too > easy. Thanks. > > A.D. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From David.Lawler at franke.com Wed Oct 17 21:50:28 2007 From: David.Lawler at franke.com (David.Lawler at franke.com) Date: Wed, 17 Oct 2007 15:50:28 -0400 Subject: [IronPython] How to find class and module variables when debugging IronPython In-Reply-To: <7AD436E4270DD54A94238001769C2227D850A1C362@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: When debugging an IronPython script I can see local variables in mdbg or cordebug. However, I cannot find a way to get class (self) and module variables. Is there anyway to do this? It's ok if it requires several steps like going up the stack frame and finding a symbol reference and then reading the value out of a symbol table. Thanks, David From dinov at exchange.microsoft.com Wed Oct 17 21:58:20 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 17 Oct 2007 12:58:20 -0700 Subject: [IronPython] How to find class and module variables when debugging IronPython In-Reply-To: References: <7AD436E4270DD54A94238001769C2227D850A1C362@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <7AD436E4270DD54A94238001769C2227D850A1C3C2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Haibo's blog has some info on this: http://blogs.msdn.com/haibo_luo/archive/2007/08/03/4210344.aspx It has a debugger proxy which enables old-class members to show up in VS. For other class members you'll generally look in self.__dict__ or self.__class__.__dict__ for class members. I don't think there's a great way to look at module globals right now. Technically if you know the module type you could find it's static __dict__ field but there's no easy way to find the module type. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David.Lawler at franke.com Sent: Wednesday, October 17, 2007 12:50 PM To: Discussion of IronPython Subject: [IronPython] How to find class and module variables when debugging IronPython When debugging an IronPython script I can see local variables in mdbg or cordebug. However, I cannot find a way to get class (self) and module variables. Is there anyway to do this? It's ok if it requires several steps like going up the stack frame and finding a symbol reference and then reading the value out of a symbol table. Thanks, David _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Wed Oct 17 22:01:43 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 17 Oct 2007 21:01:43 +0100 Subject: [IronPython] [python] Re: Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <4716230B.3000303@resolversystems.com> Message-ID: <47166A27.5000408@voidspace.org.uk> Curt Hagenlocher wrote: > On 10/17/07, *Giles Thomas* > wrote: > > Curt - how does MC++ relate to using P/Invoke? That is, is it > P/Invoke plus some clever packaging stuff to allow you to produce > a single assembly with both machine code and MSIL, or is there > more to it than that? Or is it something completely different? > > > I'd guess they share some internals -- why write the same thunking > code twice, after all. But their usage patterns are sufficiently > different that I'd argue the internals don't really matter. P/Invoke > requires you to declare everything explicitly, while the goal for MC++ > is to make interop as transparent as possible. I would be sad if we chose any approach that couldn't work on Mono. :-( Michael http://www.manning.com/foord > > -- > Curt Hagenlocher > curt at hagenlocher.org > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From joesox at gmail.com Wed Oct 17 22:19:16 2007 From: joesox at gmail.com (JoeSox) Date: Wed, 17 Oct 2007 13:19:16 -0700 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> Message-ID: <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> On 10/17/07, Joshua J. Pearce wrote: > I am looking for an embedded IronPython 2.0 example beyond the simple hello > world one I quoted before. > > What I want to know is: > > 1) How to get variable output from the script back to my c# code. I have a quick section in this article... http://www.codeproject.com/useritems/pswrdgeniron.asp You can view the source here... http://pswrdgen.googlecode.com/svn/trunk/pswrdgeniron/pswrdgeniron/Form1.cs Microsoft.Scripting.ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable > 2) How to call scripts with multiple statements. multiple statements? Do you mean call the methods in an imported script? > 3) Do all variables need to be set on the script object, or can their > declaration just be part of the script code? It depends what you are doing and how your app is designed. > 4) Is there a good and simple example anywhere that shows how to host the > IronPython engine in a c# app and let users manipulate your program objects > via ipy scripts? My article above. > 5) How can I expose c# methods to as IPY functions? Not sure I understand your question here. Can't you have a c# method then do something like pe.Execute("my py code here")? -- Later, JoeSox From daftspaniel at gmail.com Wed Oct 17 23:16:46 2007 From: daftspaniel at gmail.com (daftspaniel at gmail.com) Date: Wed, 17 Oct 2007 14:16:46 -0700 Subject: [IronPython] [python] Using IP with Idle In-Reply-To: <471665B4.2020704@voidspace.org.uk> References: <552914.35876.qm@web60311.mail.yahoo.com> <471665B4.2020704@voidspace.org.uk> Message-ID: <1192655806.248702.272260@q5g2000prf.googlegroups.com> Komodo Edit should suit a Unix minded person - it has autocompletion, strong macros and you can run a command shell from within the interface. Cheers, Davy Mitchell On Oct 17, 8:42 pm, Michael Foord wrote: > Allison Day wrote: > > I have been using python in a unix environment for years and am a > > complete noob to iron python, windows, and .net as of yesterday > > (GAAAACK! says the Linux Guy :-) so please be patient. > > > I was looking to use Idle with Ironpython but am not sure how to do > > this or if it can be done. I saw a reference or two to Idle in the > > archives, but nothing concrete. I've set the windows path to: > > > C:\Program Files\activeTcl\bin;C:\Program Files\MTS > > 793\ntbin;C:\Program Files\Common Files\MTS > > Shared;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;c:\IronPython-1.1; > > > I was reading a few IP articles and they mentioned setting the path, > > so I tried that and then importing System, but System isn't found. I > > don't yet understand the relationship between CPython and IP, so maybe > > idle can't be used. I want idle for the editing capabilities and so > > on that I'm used to using in the unix environment. > > > So can Idle be used and if not, what else has the formatting that idle > > does? One guy here using a regular text editor and runs a batch file, > > but I'm hoping for a little more interactive environment. For > > licensing reasons, visual studio is a not an option for me at the > > moment but might be in the future. > > Well, you can edit IronPython code with IDLE - but I don't think you'll > be able to run it. > > Keeping a command line window opening whilst editing with IDLE is pretty > easy. Alternatively use a slightly more 'featured' editor that allows > you to run files with an external command (most text editors will do > this - plus it can be done with Python IDEs like SPE, Wing and probably > Komodo). > > Michaelhttp://www.manning.com/foord > > > > > Again, I'm a complete Noob so forgive me if this question is too > > easy. Thanks. > > > A.D. > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > >http://mail.yahoo.com > > > ------------------------------------------------------------------------ > > > _______________________________________________ > > Users mailing list > > Us... at lists.ironpython.com > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com From curt at hagenlocher.org Wed Oct 17 23:30:46 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 17 Oct 2007 14:30:46 -0700 Subject: [IronPython] [python] Re: Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <47166A27.5000408@voidspace.org.uk> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <4716230B.3000303@resolversystems.com> <47166A27.5000408@voidspace.org.uk> Message-ID: On 10/17/07, Michael Foord wrote: > > I would be sad if we chose any approach that couldn't work on Mono. :-( I agree. Assuming this rules out MC++, I think the next best approach is (as Paolo suggests) to try to shift as much of the work to C# as possible. Here's an architecture to think about. Consider the following example for PySequence_Length: In C: typedef int (__stdcall *PFN_iO)(PyObject *); PFN_iO PFN_PySequence_Length; void Set_PySequence_Length(PFN_iO callback) { PFN_PySequence_Length = callback; } int PySequence_Length(PyObject * object) { return PFN_PySequence_Length(object); } In C#: public delegate int PFN_iO(IntPtr object); [DllImport("extension.DLL")] public static extern void Set_PySequence_Length(PFN_iO callback); public static int PySequence_Length(IntPtr obj_in) { object o = ObjectConverter(obj_in); // Do something with o return result; } public static void SetApiFunctionsAtStartup() { Set_PySequence_Length(PySequence_Length); } Ignoring exception-handling for now, the idea is to keep most of the implementation in C# and to have the C# code register callback functions as actual implementations for the parts of the Python API that we're going to duplicate. This is idea is dependent on a kind of "global registry" of objects with representations on both sides of the border. Such a registry will almost certainly be required in order to translate between the two -- if for no other reason than to handle reference-counting and/or garbage collection. Any PyObject being passed across the boundary would then actually be some kind of index into the registry. A "PyTuple_New" would call through the delegate into C# where (say) a List would be created and added to the registry, with its unique identifer being passed back to the C caller as a "PyObject *". INCREF and DECREF on the C side would affect a reference count in the registry. Once the DECREF takes the reference count down to zero, the object is removed. At that point, it may very well still be a valid CLR object in use by other parts of the program -- just not by the C extension. Objects actually defined in the C extension would be required to use either PyObject_New or Py_NewReference as part of their initialization in order for the proper fixups to happen. What do you think? -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From daftspaniel at gmail.com Wed Oct 17 23:49:35 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Wed, 17 Oct 2007 22:49:35 +0100 Subject: [IronPython] [python] Using IP with Idle In-Reply-To: <471665B4.2020704@voidspace.org.uk> References: <552914.35876.qm@web60311.mail.yahoo.com> <471665B4.2020704@voidspace.org.uk> Message-ID: <20253b0c0710171449y5722baa1l22fa395054f2b83b@mail.gmail.com> Sorry if this shows up twice :-) Komodo Edit should suit a Unix minded person - it has autocompletion, strong macros and you can run a command shell interactively from within the interface. Cheers, Davy Mitchell On 10/17/07, Michael Foord wrote: > Allison Day wrote: > > I have been using python in a unix environment for years and am a > > complete noob to iron python, windows, and .net as of yesterday > > (GAAAACK! says the Linux Guy :-) so please be patient. > > > > I was looking to use Idle with Ironpython but am not sure how to do > > this or if it can be done. I saw a reference or two to Idle in the > > archives, but nothing concrete. I've set the windows path to: > > > > C:\Program Files\activeTcl\bin;C:\Program Files\MTS > > 793\ntbin;C:\Program Files\Common Files\MTS > > Shared;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;c:\IronPython-1.1; > > > > I was reading a few IP articles and they mentioned setting the path, > > so I tried that and then importing System, but System isn't found. I > > don't yet understand the relationship between CPython and IP, so maybe > > idle can't be used. I want idle for the editing capabilities and so > > on that I'm used to using in the unix environment. > > > > So can Idle be used and if not, what else has the formatting that idle > > does? One guy here using a regular text editor and runs a batch file, > > but I'm hoping for a little more interactive environment. For > > licensing reasons, visual studio is a not an option for me at the > > moment but might be in the future. > > Well, you can edit IronPython code with IDLE - but I don't think you'll > be able to run it. > > Keeping a command line window opening whilst editing with IDLE is pretty > easy. Alternatively use a slightly more 'featured' editor that allows > you to run files with an external command (most text editors will do > this - plus it can be done with Python IDEs like SPE, Wing and probably > Komodo). > > Michael > http://www.manning.com/foord > > > > > Again, I'm a complete Noob so forgive me if this question is too > > easy. Thanks. > > > > A.D. > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From kfarmer at thuban.org Thu Oct 18 00:01:46 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 17 Oct 2007 15:01:46 -0700 Subject: [IronPython] [python] Re: Announcement: Project to get someCPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com><7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com><47138417.2030301@resolversystems.com><20071017141636.GD27285@debian.org><4716230B.3000303@resolversystems.com><47166A27.5000408@voidspace.org.uk> Message-ID: Forgive my non-C-ness (it's been a long time since I wrote a native module for Python), but aren't you now buying into a major re-implementation of all the native Python standard library into C#? Assuming for a moment that few sane people will want to re-compile them from source, it seems much easier to just use the current C++/CLI compiler from MS (not MC++), as recommended on the Mono site: http://www.mono-project.com/CPlusPlus (#CodeGeneration) Then conditionally switch out the CRT references with a CLR version: #ifdef CLR Tasty, non-CRT happy-happy #else Evil, CRT hurty-hurty #endif .. Then maybe re-submit back to CPython-land. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Wednesday, October 17, 2007 2:31 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Announcement: Project to get someCPython C extensions running under IronPython On 10/17/07, Michael Foord wrote: I would be sad if we chose any approach that couldn't work on Mono. :-( I agree. Assuming this rules out MC++, I think the next best approach is (as Paolo suggests) to try to shift as much of the work to C# as possible. Here's an architecture to think about. Consider the following example for PySequence_Length: In C: typedef int (__stdcall *PFN_iO)(PyObject *); PFN_iO PFN_PySequence_Length; void Set_PySequence_Length(PFN_iO callback) { PFN_PySequence_Length = callback; } int PySequence_Length(PyObject * object) { return PFN_PySequence_Length(object); } In C#: public delegate int PFN_iO(IntPtr object); [DllImport("extension.DLL")] public static extern void Set_PySequence_Length(PFN_iO callback); public static int PySequence_Length(IntPtr obj_in) { object o = ObjectConverter(obj_in); // Do something with o return result; } public static void SetApiFunctionsAtStartup() { Set_PySequence_Length(PySequence_Length); } Ignoring exception-handling for now, the idea is to keep most of the implementation in C# and to have the C# code register callback functions as actual implementations for the parts of the Python API that we're going to duplicate. This is idea is dependent on a kind of "global registry" of objects with representations on both sides of the border. Such a registry will almost certainly be required in order to translate between the two -- if for no other reason than to handle reference-counting and/or garbage collection. Any PyObject being passed across the boundary would then actually be some kind of index into the registry. A "PyTuple_New" would call through the delegate into C# where (say) a List would be created and added to the registry, with its unique identifer being passed back to the C caller as a "PyObject *". INCREF and DECREF on the C side would affect a reference count in the registry. Once the DECREF takes the reference count down to zero, the object is removed. At that point, it may very well still be a valid CLR object in use by other parts of the program -- just not by the C extension. Objects actually defined in the C extension would be required to use either PyObject_New or Py_NewReference as part of their initialization in order for the proper fixups to happen. What do you think? -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at notcharles.ca Thu Oct 18 00:05:11 2007 From: joe at notcharles.ca (Joe Mason) Date: Wed, 17 Oct 2007 18:05:11 -0400 Subject: [IronPython] [python] Re: Announcement: Project to get someCPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <4716230B.3000303@resolversystems.com> <47166A27.5000408@voidspace.org.uk> Message-ID: On 10/17/07, Keith J. Farmer wrote: > Forgive my non-C-ness (it's been a long time since I wrote a native module > for Python), but aren't you now buying into a major re-implementation of all > the native Python standard library into C#? Couldn't the C/C# API just use IronPython objects and methods to "implement" the Python standard library? From kfarmer at thuban.org Thu Oct 18 00:21:23 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 17 Oct 2007 15:21:23 -0700 Subject: [IronPython] [python] Re: Announcement: Project to getsomeCPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com><7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com><47138417.2030301@resolversystems.com><20071017141636.GD27285@debian.org><4716230B.3000303@resolversystems.com><47166A27.5000408@voidspace.org.uk> Message-ID: Best if Michael et al chime in, but my impression was that they're working under the assumption that you cannot get C++ code to compile to pure managed (False, use C++/CLI as recommended on the Mono site), and that it must *compile* under Mono (laudable, but I doubt it's necessary -- I've never bothered to recompile the Python Libraries). A larger worry I have is the possibility that some of this will end up being unsafe code, at which point you will have difficulties in full trust scenarios, such as web servers. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Joe Mason Sent: Wednesday, October 17, 2007 3:05 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Announcement: Project to getsomeCPython C extensions running under IronPython On 10/17/07, Keith J. Farmer wrote: > Forgive my non-C-ness (it's been a long time since I wrote a native module > for Python), but aren't you now buying into a major re-implementation of all > the native Python standard library into C#? Couldn't the C/C# API just use IronPython objects and methods to "implement" the Python standard library? _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From curt at hagenlocher.org Thu Oct 18 00:22:03 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 17 Oct 2007 15:22:03 -0700 Subject: [IronPython] [python] Re: Announcement: Project to get someCPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <4716230B.3000303@resolversystems.com> <47166A27.5000408@voidspace.org.uk> Message-ID: On 10/17/07, Joe Mason wrote: > > On 10/17/07, Keith J. Farmer wrote: > > Forgive my non-C-ness (it's been a long time since I wrote a native > module > > for Python), but aren't you now buying into a major re-implementation of > all > > the native Python standard library into C#? > > Couldn't the C/C# API just use IronPython objects and methods to > "implement" the Python standard library? Yes, that would be the idea. I think it's best when thinking about the architecture to have a specific example to refer to. With that in mind, I'm going to repeat some code I wrote earlier in the thread (with a few modifications). PyObject * ReverseSequence(PyObject * self, PyObject * args) { PyObject * columns; if (!PyArg_ParseTuple(args, "O", &columns)) { return NULL; } if (!PySequence_Check(columns)) { PyErr_SetString(PyExc_ValueError, "must be a sequence"); return NULL; } int length = PySequence_Length(columns); PyObject * result = PyTuple_New(length); for (int i = 0; i < length; i++) { PyObject * value = PySequence_GetItem(sequence, i); // Don't remember if I need to INCREF value PySequence_SetItem(result, length - i - 1, value); } return result; } Obviously, this isn't a "real-world" example, but it does show a few requirements for the compatibility layer. 1) The code expects a sequence. What kind of data should we be allowed to pass to it from IronPython? 2) The code returns a "tuple". How will this tuple be translated into a CLR object for consumption by IronPython? -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Thu Oct 18 00:23:59 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 17 Oct 2007 15:23:59 -0700 Subject: [IronPython] [python] Re: Announcement: Project to getsomeCPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> <20071017141636.GD27285@debian.org> <4716230B.3000303@resolversystems.com> <47166A27.5000408@voidspace.org.uk> Message-ID: On 10/17/07, Keith J. Farmer wrote: > > > A larger worry I have is the possibility that some of this will end up > being unsafe code, at which point you will have difficulties in full trust > scenarios, such as web servers. This project will by definition be producing "unsafe" code. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Thu Oct 18 00:25:16 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 17 Oct 2007 15:25:16 -0700 Subject: [IronPython] [python] Re: Announcement: Project to getsomeCPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com><47138417.2030301@resolversystems.com><20071017141636.GD27285@debian.org><4716230B.3000303@resolversystems.com><47166A27.5000408@voidspace.org.uk> Message-ID: I think my point is that if you switch which dialect of C you're compiling with, such marshalling issues could (potentially) go away. Again, I'm na?ve here. I've not made it my business to write native libraries for Python. Just one, and that was years ago. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Wednesday, October 17, 2007 3:22 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Announcement: Project to getsomeCPython C extensions running under IronPython On 10/17/07, Joe Mason wrote: On 10/17/07, Keith J. Farmer wrote: > Forgive my non-C-ness (it's been a long time since I wrote a native module > for Python), but aren't you now buying into a major re-implementation of all > the native Python standard library into C#? Couldn't the C/C# API just use IronPython objects and methods to "implement" the Python standard library? Yes, that would be the idea. I think it's best when thinking about the architecture to have a specific example to refer to. With that in mind, I'm going to repeat some code I wrote earlier in the thread (with a few modifications). PyObject * ReverseSequence(PyObject * self, PyObject * args) { PyObject * columns; if (!PyArg_ParseTuple(args, "O", &columns)) { return NULL; } if (!PySequence_Check(columns)) { PyErr_SetString(PyExc_ValueError, "must be a sequence"); return NULL; } int length = PySequence_Length(columns); PyObject * result = PyTuple_New(length); for (int i = 0; i < length; i++) { PyObject * value = PySequence_GetItem(sequence, i); // Don't remember if I need to INCREF value PySequence_SetItem(result, length - i - 1, value); } return result; } Obviously, this isn't a "real-world" example, but it does show a few requirements for the compatibility layer. 1) The code expects a sequence. What kind of data should we be allowed to pass to it from IronPython? 2) The code returns a "tuple". How will this tuple be translated into a CLR object for consumption by IronPython? -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Thu Oct 18 00:28:43 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 17 Oct 2007 15:28:43 -0700 Subject: [IronPython] [python] Re: Announcement: Project togetsomeCPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com><20071017141636.GD27285@debian.org><4716230B.3000303@resolversystems.com><47166A27.5000408@voidspace.org.uk> Message-ID: See my earlier email. I think you *could* keep it in C, compile into pure IL. At that point you have to deal with pointer-driven algorithms (eg, NumPy), but you could generate safe code. Anyway, I need to go eat. I think some serious thought should be given to C++/CLI as an option to produce an IL version of these libraries. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Wednesday, October 17, 2007 3:24 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Announcement: Project togetsomeCPython C extensions running under IronPython On 10/17/07, Keith J. Farmer wrote: A larger worry I have is the possibility that some of this will end up being unsafe code, at which point you will have difficulties in full trust scenarios, such as web servers. This project will by definition be producing "unsafe" code. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Thu Oct 18 00:34:06 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 17 Oct 2007 15:34:06 -0700 Subject: [IronPython] [python] Re: Announcement: Project togetsomeCPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> <4716230B.3000303@resolversystems.com> <47166A27.5000408@voidspace.org.uk> Message-ID: On 10/17/07, Keith J. Farmer wrote: > > See my earlier email. I think you **could** keep it in C, compile into > pure IL. At that point you have to deal with pointer-driven algorithms (eg, > NumPy), but you could generate safe code. > The basic data type in a CPython extension is a "PyObject *". That asterisk there is an old-fashioned way of saying "unsafe code". :) -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Thu Oct 18 01:05:14 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 17 Oct 2007 16:05:14 -0700 Subject: [IronPython] [python] Re: Announcement: ProjecttogetsomeCPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com><4716230B.3000303@resolversystems.com><47166A27.5000408@voidspace.org.uk> Message-ID: I know what pointers are - I just don't like them. In C++/CLI you'd use a caret to get a safe handle to said object. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Wednesday, October 17, 2007 3:34 PM To: Discussion of IronPython Subject: Re: [IronPython] [python] Re: Announcement: ProjecttogetsomeCPython C extensions running under IronPython On 10/17/07, Keith J. Farmer wrote: See my earlier email. I think you *could* keep it in C, compile into pure IL. At that point you have to deal with pointer-driven algorithms (eg, NumPy), but you could generate safe code. The basic data type in a CPython extension is a "PyObject *". That asterisk there is an old-fashioned way of saying "unsafe code". :) -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua.pearce at gmail.com Thu Oct 18 02:29:27 2007 From: joshua.pearce at gmail.com (Joshua J. Pearce) Date: Wed, 17 Oct 2007 20:29:27 -0400 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> Message-ID: <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> OK, please forgive my earlier vagueness. What I want to do is as follows: pe = PythonEngine.CurrentEngine; //create a instance of my applications business logic layer class myAppService = new AppService(_token); //I want to be able to somehow make methods from the myAppService class available to be called from Iron Python code. //I know I could import the AppService dll and create my own instance in the IP engine, but that's way too much overhead. //How can I say: "Hey, pe, here is a method on my object, myAppService, that I want you to make available when you execute a command? Thanks, -Josh Pearce On 10/17/07, JoeSox wrote: > > On 10/17/07, Joshua J. Pearce wrote: > > I am looking for an embedded IronPython 2.0 example beyond the simple > hello > > world one I quoted before. > > > > What I want to know is: > > > > 1) How to get variable output from the script back to my c# code. > > I have a quick section in this article... > http://www.codeproject.com/useritems/pswrdgeniron.asp > > You can view the source here... > > http://pswrdgen.googlecode.com/svn/trunk/pswrdgeniron/pswrdgeniron/Form1.cs > > > Microsoft.Scripting.ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable > > > 2) How to call scripts with multiple statements. > > multiple statements? Do you mean call the methods in an imported script? > > > 3) Do all variables need to be set on the script object, or can their > > declaration just be part of the script code? > > It depends what you are doing and how your app is designed. > > > 4) Is there a good and simple example anywhere that shows how to host > the > > IronPython engine in a c# app and let users manipulate your program > objects > > via ipy scripts? > > My article above. > > > 5) How can I expose c# methods to as IPY functions? > > Not sure I understand your question here. Can't you have a c# method > then do something like pe.Execute("my py code here")? > -- > Later, JoeSox > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Joshua Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Thu Oct 18 02:42:05 2007 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Thu, 18 Oct 2007 00:42:05 -0000 Subject: [IronPython] My takes on C Extensions for IronPython Message-ID: <1192668125.063702.76860@i38g2000prf.googlegroups.com> The discussion is getting very confusing, so here are some of my takes on the issues. On the issue of P/Invoke declarations for Python/C API, Paolo Molaro wrote: "The python API requires a couple dozen structure definitions plus a few dozen dllimport declarations. This can be about 200 lines of trivial to write declarative stuff." It's certainly more than 200 lines, and it's not completely trivial because some parts of Python/C API are C macros, not C functions. (Reference counting is the most important, but also getting type(=vtable) of Python objects and like.) The good news is that this part is already developed, debugged, and pretty much finished -- for Python 2.3 to 2.6, and for wide and narrow unicode builds of Python. Get it here (~ 1600 lines): http://pythonnet.svn.sourceforge.net/svnroot/pythonnet/trunk/pythonnet/src/runtime/runtime.cs Assuming that ZPL (which is OSI-certified) is okay, it would be strange not to use this. On the issue of compiling C or C++ to CLI, Keith J. Famer wrote: "My impression was that they're working under the assumption that you cannot get C++ code to compile to pure managed (False, use C++/CLI as recommended on the Mono site), and that it must *compile* under Mono (laudable, but I doubt it's necessary -- I've never bothered to recompile the Python Libraries)." Readers not familiar with the issue should read Mono documentation mentioned: http://www.mono-project.com/CPlusPlus I understand MC++ or Managed C++ is used to refer related technologies, but in the narrow sense it is a compiler that shipped with .NET 1.x which produced mix of managed and x86 code. I believe .NET 2.x compiler, i.e. C++/CLI is what is currently discussed. It would be nice to be able to compile without Microsoft tools, but I don't think it's essential. If assembly compiled with C++/CLI / clr:pure can be made to run on Mono that's fine. Also Mono page doesn't mention this, but GCC backend to emit CLI code *is* complete and working. It's available right now from GCC SVN. But it's yet another project, not Google Summer of Code attempts. This project is backed by STMicroelectronics, a big corporation, probably for its own use. http://gcc.gnu.org/projects/cli.html Remember, Mono doesn't need to be the sole provider of non-Microsoft CLI tools. :) I believe GCC/CLI can be made to help this project. Okay, enough said for this mail... -- Seo Sanghyeon From sanxiyn at gmail.com Thu Oct 18 03:58:29 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 18 Oct 2007 10:58:29 +0900 Subject: [IronPython] Compilation error In-Reply-To: <7AD436E4270DD54A94238001769C2227CCBD5EFCB8@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <5b0248170710041742j42e3fa0av1504df1d45ea2de3@mail.gmail.com> <7AD436E4270DD54A94238001769C2227CCBD231097@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <5b0248170710041821j1e197667q1005a7ad77e3a83a@mail.gmail.com> <7AD436E4270DD54A94238001769C2227CCBD5EFCB8@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <5b0248170710171858u71f7c275wbfe70cf0756de4c0@mail.gmail.com> 2007/10/6, Dino Viehland : > BTW my simple repro is bogus - it contains no members and section 5.3 of the C# spec defines value types as being definitely assigned when all their members are assigned. The real issue seems to be when the value-type is defined in another assembly and all the members are private. Once those conditions are met csc then doesn't require the assignment. > > I'm still waiting for a response on that last bit. Gert Driesen from Mono project reported this as Feedback 304489 at Microsoft Connect. http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=304489 After 3 days, it was marked "Resolved (By Design)", without any explanation. I'm still curious. -- Seo Sanghyeon From joe at notcharles.ca Thu Oct 18 05:42:58 2007 From: joe at notcharles.ca (Joe Mason) Date: Wed, 17 Oct 2007 23:42:58 -0400 Subject: [IronPython] [python] Re: Announcement: ProjecttogetsomeCPython C extensions running under IronPython In-Reply-To: References: <470FA841.6020008@resolversystems.com> <47166A27.5000408@voidspace.org.uk> Message-ID: On 10/17/07, Keith J. Farmer wrote: > I know what pointers are ? I just don't like them. > > In C++/CLI you'd use a caret to get a safe handle to said object. But... but that's not source compatible? Joe From dinov at exchange.microsoft.com Thu Oct 18 06:53:24 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 17 Oct 2007 21:53:24 -0700 Subject: [IronPython] Compilation error In-Reply-To: <5b0248170710171858u71f7c275wbfe70cf0756de4c0@mail.gmail.com> References: <5b0248170710041742j42e3fa0av1504df1d45ea2de3@mail.gmail.com> <7AD436E4270DD54A94238001769C2227CCBD231097@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <5b0248170710041821j1e197667q1005a7ad77e3a83a@mail.gmail.com> <7AD436E4270DD54A94238001769C2227CCBD5EFCB8@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <5b0248170710171858u71f7c275wbfe70cf0756de4c0@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227D850A1C5B5@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Looks like the internal bug got closed as By Design as well, I've reactivated it. Maybe it's not clear to them that their making a distinction based upon what assembly the struct is defined in. I added the below repro snippet to the internal bug: using System; using System.Reflection; class foo { public void bar(out ParameterModifier x) { } } vs: using System; class foo { public void bar(out ParameterModifier x) { } } // ParameterModifier from mscorlib has the same members: struct ParameterModifier { private bool[] _byRef; } The 1st doesn't require assignment yet the 2nd does. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Wednesday, October 17, 2007 6:58 PM To: Discussion of IronPython Subject: Re: [IronPython] Compilation error 2007/10/6, Dino Viehland : > BTW my simple repro is bogus - it contains no members and section 5.3 of the C# spec defines value types as being definitely assigned when all their members are assigned. The real issue seems to be when the value-type is defined in another assembly and all the members are private. Once those conditions are met csc then doesn't require the assignment. > > I'm still waiting for a response on that last bit. Gert Driesen from Mono project reported this as Feedback 304489 at Microsoft Connect. http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=304489 After 3 days, it was marked "Resolved (By Design)", without any explanation. I'm still curious. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From lupus at ximian.com Thu Oct 18 12:24:49 2007 From: lupus at ximian.com (Paolo Molaro) Date: Thu, 18 Oct 2007 12:24:49 +0200 Subject: [IronPython] My takes on C Extensions for IronPython In-Reply-To: <1192668125.063702.76860@i38g2000prf.googlegroups.com> References: <1192668125.063702.76860@i38g2000prf.googlegroups.com> Message-ID: <20071018102449.GP27285@debian.org> I'll just reply here and try to summarize some things. On 10/18/07 Seo Sanghyeon wrote: > It's certainly more than 200 lines, and it's not completely trivial > because some parts of Python/C API are C macros, not C functions. > (Reference counting is the most important, but also getting > type(=vtable) of Python objects and like.) > > The good news is that this part is already developed, debugged, and > pretty much finished -- for Python 2.3 to 2.6, and for wide and narrow > unicode builds of Python. Get it here (~ 1600 lines): That code has each dllimport method spanning 5 lines of code. I don't consider a cut and pasted [DllImport()] attribute as something that is hard to write:) So this complete work that covers 4 major versions of python is less than 200 p/invokes. It's missing a few structure definitions. Nothing an intern can't write in an afternoon. My point still stands: interoperating with the C code is not an issue. > I understand MC++ or Managed C++ is used to refer related > technologies, but in the narrow sense it is a compiler that shipped > with .NET 1.x which produced mix of managed and x86 code. I > believe .NET 2.x compiler, i.e. C++/CLI is what is currently > discussed. Yes, Managed C++ referes to the old broken and already abandoned technology, but it's sometimes used also to refer to the new C++/CLI lanaguage, likely because C++/CLI is not a really good name:) > It would be nice to be able to compile without Microsoft tools, but I > don't think it's essential. If assembly compiled with C++/CLI / > clr:pure can be made to run on Mono that's fine. First, someone should investigate if clr:pure actually provides seamless integration with C code. I doubt it works, but I'll wait for someone using windows to confirm this. The issue then is that, even if the above would work, the MS C++/CLI compiler will emit code that depends on the windows ABI (specifically always considering long to be 32 bits, they even put this in the standard, sigh). What this means for people not familiar with low-level details, is that such code is not portable and hence won't work on Linux 64 bit systems (this is always assuming the interoperability with C code works at all even on 32 bit systems). So, while it's not essential that this code be built with non-Microsoft tools, only the MS tools are able to compile that code and they compile it incorrectly (and as the C++/CLI standard requires, sadly, so there is no chance this will be ever fixed). > Also Mono page doesn't mention this, but GCC backend to emit CLI code > *is* complete and working. It's available right now from GCC SVN. But > it's yet another project, not Google Summer of Code attempts. This > project is backed by STMicroelectronics, a big corporation, probably > for its own use. > http://gcc.gnu.org/projects/cli.html > > Remember, Mono doesn't need to be the sole provider of non-Microsoft > CLI tools. :) I believe GCC/CLI can be made to help this project. See above for the portability issues: they'd have to either not follow the standard or to produce non-working code. Also the gcc CLI backend is not really complete and even if it were it doesn't mean that C++/CLI would be any easier to implement on top of it. My estimate is that C++/CLI on top of gcc will require at least 4-5 years, if someone implements it at all (there is not much demand for it, there are the portability and standard issues I mentioned above and by that time Mono will have an extension to semalessly dllimport C++ code, lowering demand for C++/CLI even more). In 4-5 years Microsoft itself will pull the plug on C++/CLI, so I think basing a new design on it is a mistake. Anyway, I'm not the one who's going to write the code, so more power to people that will, I just wanted to make people aware that using managed C++ or C++/CLI will prevent the sw to work on anything but windows with the .net runtime. Happy hacking! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From sanxiyn at gmail.com Thu Oct 18 12:52:56 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 18 Oct 2007 19:52:56 +0900 Subject: [IronPython] My takes on C Extensions for IronPython In-Reply-To: <20071018102449.GP27285@debian.org> References: <1192668125.063702.76860@i38g2000prf.googlegroups.com> <20071018102449.GP27285@debian.org> Message-ID: <5b0248170710180352j246e8a3ct51ccf4d0c7b313c@mail.gmail.com> 2007/10/18, Paolo Molaro : > My point still stands: interoperating with the C code is not an issue. Agreed. > Also the gcc CLI backend > is not really complete and even if it were it doesn't mean that C++/CLI > would be any easier to implement on top of it. I'm not interested in C++/CLI, and I don't think it's needed for CPython anyway. -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Thu Oct 18 12:59:39 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 18 Oct 2007 11:59:39 +0100 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> Message-ID: <47173C9B.9000007@voidspace.org.uk> Hello Joshua, I'll take a look at this. It is really easy for IronPython 1 and everything has changed for IP 2 (and the docs are not exactly complete). It just takes a bit of exploration. You need to be able to set some globals in the default module (where you can make your .NET objects available to IP code - and then pull the globals back out after executing the Python). Michael http://www.manning.com/foord Joshua J. Pearce wrote: > OK, please forgive my earlier vagueness. What I want to do is as follows: > > pe = PythonEngine.CurrentEngine; > > //create a instance of my applications business logic layer class > myAppService = new AppService(_token); > > //I want to be able to somehow make methods from the myAppService > class available to be called from Iron Python code. > //I know I could import the AppService dll and create my own instance > in the IP engine, but that's way too much overhead. > > //How can I say: "Hey, pe, here is a method on my object, > myAppService, that I want you to make available when you execute a > command? > > Thanks, > > -Josh Pearce > > > > > On 10/17/07, *JoeSox* > wrote: > > On 10/17/07, Joshua J. Pearce > wrote: > > I am looking for an embedded IronPython 2.0 example beyond the > simple hello > > world one I quoted before. > > > > What I want to know is: > > > > 1) How to get variable output from the script back to my c# code. > > I have a quick section in this article... > http://www.codeproject.com/useritems/pswrdgeniron.asp > > You can view the source here... > http://pswrdgen.googlecode.com/svn/trunk/pswrdgeniron/pswrdgeniron/Form1.cs > > > Microsoft.Scripting.ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable > > > 2) How to call scripts with multiple statements. > > multiple statements? Do you mean call the methods in an imported > script? > > > 3) Do all variables need to be set on the script object, or can > their > > declaration just be part of the script code? > > It depends what you are doing and how your app is designed. > > > 4) Is there a good and simple example anywhere that shows how to > host the > > IronPython engine in a c# app and let users manipulate your > program objects > > via ipy scripts? > > My article above. > > > 5) How can I expose c# methods to as IPY functions? > > Not sure I understand your question here. Can't you have a c# method > then do something like pe.Execute("my py code here")? > -- > Later, JoeSox > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > Joshua Pearce > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From joesox at gmail.com Thu Oct 18 15:53:04 2007 From: joesox at gmail.com (JoeSox) Date: Thu, 18 Oct 2007 06:53:04 -0700 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> Message-ID: <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> On 10/17/07, Joshua J. Pearce wrote: > OK, please forgive my earlier vagueness. What I want to do is as follows: > > pe = PythonEngine.CurrentEngine; > > //create a instance of my applications business logic layer class > myAppService = new AppService(_token); > > //I want to be able to somehow make methods from the myAppService class > available to be called from Iron Python code. > > //I know I could import the AppService dll and create my own instance in the > IP engine, but that's way too much overhead. > > //How can I say: "Hey, pe, here is a method on my object, myAppService, that > I want you to make available when you execute a command? What are the return values of myAppService.ServiceMethod()? Depending upon these values, you will need to handle them before sending them to the pe. So it sounds like you need something like: public int COUNT; private void MyIPGetCount() { //Call your Service method and assign return value to a global COUNT = myAppService.getcount(); //Create variable bridge from C# to IronPython engine //I like to pretend I am just using a IP command line to help figure out what I need to do pe.ExecuteCommand("PyCount = 0"); //Set the IronPython bridge variables... ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable("PyCount", COUNT); pe.ExecuteCommand("PyCountTwo = PyCount"); } This is a simplified version of what I am guess what you need to do but there you go. -- Later, JoeSox From joshua.pearce at gmail.com Thu Oct 18 16:48:02 2007 From: joshua.pearce at gmail.com (Joshua J. Pearce) Date: Thu, 18 Oct 2007 10:48:02 -0400 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> Message-ID: <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> Joesox, Thank you very much! Now, what if I the getcount() method was actually getcount(string arg1), is there a way to call it from within the IP script? Or do I need to parse the IP script ahead of time, and call the function myself? That would be like writing my own scripting language, so I hope there is a way to call the method from within IP scripts. Many thanks! - Josh Pearce On 10/18/07, JoeSox wrote: > > On 10/17/07, Joshua J. Pearce wrote: > > OK, please forgive my earlier vagueness. What I want to do is as > follows: > > > > pe = PythonEngine.CurrentEngine; > > > > //create a instance of my applications business logic layer class > > myAppService = new AppService(_token); > > > > //I want to be able to somehow make methods from the myAppService class > > available to be called from Iron Python code. > > > > //I know I could import the AppService dll and create my own instance in > the > > IP engine, but that's way too much overhead. > > > > //How can I say: "Hey, pe, here is a method on my object, myAppService, > that > > I want you to make available when you execute a command? > > > What are the return values of myAppService.ServiceMethod()? > Depending upon these values, you will need to handle them before > sending them to the pe. > > So it sounds like you need something like: > > public int COUNT; > > private void MyIPGetCount() > { > //Call your Service method and assign return value to a global > COUNT = myAppService.getcount(); > > //Create variable bridge from C# to IronPython engine > //I like to pretend I am just using a IP command line to help > figure out what I need to do > pe.ExecuteCommand("PyCount = 0"); > > //Set the IronPython bridge variables... > ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable > ("PyCount", > COUNT); > pe.ExecuteCommand("PyCountTwo = PyCount"); > } > > This is a simplified version of what I am guess what you need to do > but there you go. > -- > Later, JoeSox > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Joshua Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From joesox at gmail.com Thu Oct 18 17:45:06 2007 From: joesox at gmail.com (JoeSox) Date: Thu, 18 Oct 2007 08:45:06 -0700 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> Message-ID: <785694cd0710180845t26ebf8dr6f54039d2b5cc249@mail.gmail.com> On 10/18/07, Joshua J. Pearce wrote: > Joesox, > > Thank you very much! Now, what if I the getcount() method was actually > getcount(string arg1), is there a way to call it from within the IP script? I don't see why you would want to if you are using an IronPythonEngine Just do... //Call your Service method and assign return value to a global COUNT = myAppService.getcount("my arg1"); > Or do I need to parse the IP script ahead of time, and call the function > myself? That would be like writing my own scripting language, so I hope > there is a way to call the method from within IP scripts. I still don't see why you would need it in the script if you are using C#. -- Later, JoeSox From joshua.pearce at gmail.com Thu Oct 18 18:22:20 2007 From: joshua.pearce at gmail.com (Joshua J. Pearce) Date: Thu, 18 Oct 2007 12:22:20 -0400 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <785694cd0710180845t26ebf8dr6f54039d2b5cc249@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> <785694cd0710180845t26ebf8dr6f54039d2b5cc249@mail.gmail.com> Message-ID: <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> Ah, because I am trying to use Iron Python as a scripting language for my application. I want to expose a limited subset of my appservice functions to the scripting language,and let users write scripts. On 10/18/07, JoeSox wrote: > > On 10/18/07, Joshua J. Pearce wrote: > > Joesox, > > > > Thank you very much! Now, what if I the getcount() method was actually > > getcount(string arg1), is there a way to call it from within the IP > script? > > I don't see why you would want to if you are using an IronPythonEngine > > Just do... > //Call your Service method and assign return value to a global > COUNT = myAppService.getcount("my arg1"); > > > Or do I need to parse the IP script ahead of time, and call the function > > myself? That would be like writing my own scripting language, so I hope > > there is a way to call the method from within IP scripts. > > I still don't see why you would need it in the script if you are using C#. > -- > Later, JoeSox > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Joshua Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Oct 18 19:04:25 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 18 Oct 2007 18:04:25 +0100 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> Message-ID: <47179219.70604@voidspace.org.uk> Joshua J. Pearce wrote: > Joesox, > > Thank you very much! Now, what if I the getcount() method was actually > getcount(string arg1), is there a way to call it from within the IP > script? Or do I need to parse the IP script ahead of time, and call > the function myself? That would be like writing my own scripting > language, so I hope there is a way to call the method from within IP > scripts. You should be able to place objects into the 'user scope' using the same SetVariable technique. That way the user can call methods on these objects from their code. ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable("SomeName", SomeObject); SomeObject is then available to user code as SomeName... Michael http://www.manning.com/foord > > Many thanks! > > - Josh Pearce > > On 10/18/07, *JoeSox* > wrote: > > On 10/17/07, Joshua J. Pearce > wrote: > > OK, please forgive my earlier vagueness. What I want to do is as > follows: > > > > pe = PythonEngine.CurrentEngine ; > > > > //create a instance of my applications business logic layer class > > myAppService = new AppService(_token); > > > > //I want to be able to somehow make methods from the > myAppService class > > available to be called from Iron Python code. > > > > //I know I could import the AppService dll and create my own > instance in the > > IP engine, but that's way too much overhead. > > > > //How can I say: "Hey, pe, here is a method on my object, > myAppService, that > > I want you to make available when you execute a command? > > > What are the return values of myAppService.ServiceMethod()? > Depending upon these values, you will need to handle them before > sending them to the pe. > > So it sounds like you need something like: > > public int COUNT; > > private void MyIPGetCount() > { > //Call your Service method and assign return value to a global > COUNT = myAppService.getcount (); > > //Create variable bridge from C# to IronPython engine > //I like to pretend I am just using a IP command line to help > figure out what I need to do > pe.ExecuteCommand("PyCount = 0"); > > //Set the IronPython bridge variables... > ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable("PyCount", > COUNT); > pe.ExecuteCommand("PyCountTwo = PyCount"); > } > > This is a simplified version of what I am guess what you need to do > but there you go. > -- > Later, JoeSox > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > Joshua Pearce > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From joesox at gmail.com Thu Oct 18 19:18:00 2007 From: joesox at gmail.com (JoeSox) Date: Thu, 18 Oct 2007 10:18:00 -0700 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> <785694cd0710180845t26ebf8dr6f54039d2b5cc249@mail.gmail.com> <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> Message-ID: <785694cd0710181018y2ba09584q9cafad3a85e703b1@mail.gmail.com> On 10/18/07, Joshua J. Pearce wrote: > Ah, because I am trying to use Iron Python as a scripting language for my > application. I want to expose a limited subset of my appservice functions to > the scripting language,and let users write scripts. Personally, I would just use Python as the scripting for a number of reasons. 1) IronPython is a .Net library not a language 2) IronPython supports Python language modules (to a certain point) 3) Possibly provides compatibility to CPython and IronPython I believe this would be a better design for your application and be better in the long run, esp. as IronPython grows and changes rapidly. This is mainly why I designed pswrdgen and pswrdgeniron this way. However, just my two cents and not fully aware of your apps specific details. -- Later, JoeSox From lupus at ximian.com Thu Oct 18 19:16:51 2007 From: lupus at ximian.com (Paolo Molaro) Date: Thu, 18 Oct 2007 19:16:51 +0200 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <47164F66.9030606@v-sim.com> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <20071017162636.GH27285@debian.org> <20071017170205.GK27285@debian.org> <47164F66.9030606@v-sim.com> Message-ID: <20071018171651.GW27285@debian.org> On 10/17/07 Tony Djordjevski wrote: > > You do need to write C code as the API is a C API. I didn't list in the > > last mail because the C implementation of these functions is not a > > difference between the C# impl and the C++ impl of the rest of the code. > > The dllimport declarations I mentioned above would pinvoke to these C > > functions. > > Those C functions you speak about will need to execute managed code. > > So, either way, what needs to be done is to allow "Reverse P/Invoke" or > some form of DllExport. Assuming this project is successful, native > C/C++ will have to, at some point, execute managed code. > > There are only two ways that I know of that you can accomplish this in .NET: > 1. C++ Interop > 2. Modifying a compiled assembly or 3, the easiest of all: using function pointers in the C code which the runtimes will generate automatically when passing a delegate to a p/invoked method. Besides being trivial compared to both 1 and 2, it works on Mono and it works on the MS CLR. Happy hacking! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From tony at v-sim.com Thu Oct 18 19:36:08 2007 From: tony at v-sim.com (Tony Djordjevski) Date: Thu, 18 Oct 2007 13:36:08 -0400 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <20071018171651.GW27285@debian.org> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <20071017162636.GH27285@debian.org> <20071017170205.GK27285@debian.org> <47164F66.9030606@v-sim.com> <20071018171651.GW27285@debian.org> Message-ID: <47179988.2040801@v-sim.com> Paolo Molaro wrote: > On 10/17/07 Tony Djordjevski wrote: >>> You do need to write C code as the API is a C API. I didn't list in the >>> last mail because the C implementation of these functions is not a >>> difference between the C# impl and the C++ impl of the rest of the code. >>> The dllimport declarations I mentioned above would pinvoke to these C >>> functions. >> Those C functions you speak about will need to execute managed code. >> >> So, either way, what needs to be done is to allow "Reverse P/Invoke" or >> some form of DllExport. Assuming this project is successful, native >> C/C++ will have to, at some point, execute managed code. >> >> There are only two ways that I know of that you can accomplish this in .NET: >> 1. C++ Interop >> 2. Modifying a compiled assembly > > or 3, the easiest of all: using function pointers in the C code which > the runtimes will generate automatically when passing a delegate > to a p/invoked method. > Besides being trivial compared to both 1 and 2, it works on Mono and it > works on the MS CLR. > Happy hacking! > > lupus > You're right. I actually forgot about that one, hence my post. Best Regards, Tony From joshua.pearce at gmail.com Thu Oct 18 19:55:40 2007 From: joshua.pearce at gmail.com (Joshua J. Pearce) Date: Thu, 18 Oct 2007 13:55:40 -0400 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <785694cd0710181018y2ba09584q9cafad3a85e703b1@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> <785694cd0710180845t26ebf8dr6f54039d2b5cc249@mail.gmail.com> <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> <785694cd0710181018y2ba09584q9cafad3a85e703b1@mail.gmail.com> Message-ID: <278e6e410710181055w7340efd2lb25590d55370aa33@mail.gmail.com> My application is ASP.NET, I hardly think integrating CPython is going to be a better choice. I really hope I can be clear this time and not encourage suggestions to do all kinds of other stuff that what I am asking about, so here it goes: Is is possible to 'expose' c# methods that exist in the same scope as an IPY engine, to that engine so that an arbitrary one of those methods might be called by python code code that that engine executes? Thanks, Josh Pearce On 10/18/07, JoeSox wrote: > > On 10/18/07, Joshua J. Pearce wrote: > > Ah, because I am trying to use Iron Python as a scripting language for > my > > application. I want to expose a limited subset of my appservice > functions to > > the scripting language,and let users write scripts. > > Personally, I would just use Python as the scripting for a number of > reasons. > 1) IronPython is a .Net library not a language > 2) IronPython supports Python language modules (to a certain point) > 3) Possibly provides compatibility to CPython and IronPython > > I believe this would be a better design for your application and be > better in the long run, esp. as IronPython grows and changes rapidly. > This is mainly why I designed pswrdgen and pswrdgeniron this way. > However, just my two cents and not fully aware of your apps specific > details. > -- > Later, JoeSox > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Joshua Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From joesox at gmail.com Thu Oct 18 20:50:28 2007 From: joesox at gmail.com (JoeSox) Date: Thu, 18 Oct 2007 11:50:28 -0700 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <278e6e410710181055w7340efd2lb25590d55370aa33@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> <785694cd0710180845t26ebf8dr6f54039d2b5cc249@mail.gmail.com> <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> <785694cd0710181018y2ba09584q9cafad3a85e703b1@mail.gmail.com> <278e6e410710181055w7340efd2lb25590d55370aa33@mail.gmail.com> Message-ID: <785694cd0710181150w7b2d6e07lecb5afd8653a14f@mail.gmail.com> On 10/18/07, Joshua J. Pearce wrote: > My application is ASP.NET, I hardly think integrating CPython is going to be a better choice. You never mentioned you were using ASP.NET. You have mentioned C#. > Is is possible to 'expose' c# methods that exist in the same scope as an IPY > engine, Can you clarify what you mean by this line for me? Can you provide a C# method that exists in the same scope as an IPY engine? There must be a custom interface, how would an outside script know about a custom method outside it's scope without an custom interface? Michael and myself have both provided examples. If you have a C# method it must be represented by something else in the script or python code that IronPythonEngine is using, then update the script or python code loaded in the IronPythonEngine using the examples provided. Since I have not seen your source, I don't know why you believe importing the AppService dll and create your own instance in the IP engine will be too much overhead. That sounds like the bet way to go but I am not familiar with your source. Good Luck! -- Later, JoeSox From joshua.pearce at gmail.com Thu Oct 18 21:27:29 2007 From: joshua.pearce at gmail.com (Joshua J. Pearce) Date: Thu, 18 Oct 2007 15:27:29 -0400 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <785694cd0710181150w7b2d6e07lecb5afd8653a14f@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <785694cd0710171319x19277bb1t2a438f3fc647bb68@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> <785694cd0710180845t26ebf8dr6f54039d2b5cc249@mail.gmail.com> <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> <785694cd0710181018y2ba09584q9cafad3a85e703b1@mail.gmail.com> <278e6e410710181055w7340efd2lb25590d55370aa33@mail.gmail.com> <785694cd0710181150w7b2d6e07lecb5afd8653a14f@mail.gmail.com> Message-ID: <278e6e410710181227h21c5a19dg203bfab80f52b3e8@mail.gmail.com> I am very sorry! I just noticed this: ScriptDomainManager.CurrentMan ager.Host.DefaultModule.SetVariable("SomeName", SomeObject); SomeObject is then available to user code as SomeName... That is exactly what I want to do!!! Thank you very much! On 10/18/07, JoeSox wrote: > > On 10/18/07, Joshua J. Pearce wrote: > > My application is ASP.NET, I hardly think integrating CPython is going > to be a better choice. > > You never mentioned you were using ASP.NET. You have mentioned C#. > > > Is is possible to 'expose' c# methods that exist in the same scope as an > IPY > > engine, > > Can you clarify what you mean by this line for me? Can you provide a > C# method that exists in the same scope as an IPY engine? > > There must be a custom interface, how would an outside script know > about a custom method outside it's scope without an custom interface? > Michael and myself have both provided examples. > > If you have a C# method it must be represented by something else in > the script or python code that IronPythonEngine is using, then update > the script or python code loaded in the IronPythonEngine using the > examples provided. > > Since I have not seen your source, I don't know why you believe > importing the AppService dll and create your own instance in the IP > engine will be too much overhead. That sounds like the bet way to go > but I am not familiar with your source. > Good Luck! > -- > Later, JoeSox > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Joshua Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrdev at gmail.com Fri Oct 19 17:37:16 2007 From: cbrdev at gmail.com (Clems no) Date: Fri, 19 Oct 2007 17:37:16 +0200 Subject: [IronPython] thread.interrupt_main() not implemented Message-ID: Hello, When i want to use thread.interrupt_main() in iron python script, i've got this error: NotImplementedError: interrupt_main not implemented Is there an equivalent in ironpython? Thanks, cbr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Fri Oct 19 18:15:02 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Fri, 19 Oct 2007 17:15:02 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <20071018171651.GW27285@debian.org> References: <470FA841.6020008@resolversystems.com> <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <20071017162636.GH27285@debian.org> <20071017170205.GK27285@debian.org> <47164F66.9030606@v-sim.com> <20071018171651.GW27285@debian.org> Message-ID: <4718D806.4000608@resolversystems.com> Paolo Molaro wrote: > or 3, the easiest of all: using function pointers in the C code which the runtimes will generate automatically when passing a delegate to a p/invoked method. > Besides being trivial compared to both 1 and 2, it works on Mono and it works on the MS CLR. > I'm glad you mentioned that; we use it in our P/Invoked code (for the callback when iteration over windows), and it works just fine; I was beginning to worry that it might not work on Mono. A question - if we were trying to produce something that, at a source level, looked like the CPython extensions API, is there any easy way that we could get that to be able to call back to IronPython? I can imagine something like an init() function on the managed side that could pass a number of delegates over to the unmanaged code so that they could be called back at a later point, but is there a more elegant solution? Cheers, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From curt at hagenlocher.org Fri Oct 19 18:29:50 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 19 Oct 2007 09:29:50 -0700 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <4718D806.4000608@resolversystems.com> References: <470FA841.6020008@resolversystems.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <20071017162636.GH27285@debian.org> <20071017170205.GK27285@debian.org> <47164F66.9030606@v-sim.com> <20071018171651.GW27285@debian.org> <4718D806.4000608@resolversystems.com> Message-ID: On 10/19/07, Giles Thomas wrote: > > > A question - if we were trying to produce something that, at a source > level, looked like the CPython extensions API, is there any easy way > that we could get that to be able to call back to IronPython? I can > imagine something like an init() function on the managed side that could > pass a number of delegates over to the unmanaged code so that they could > be called back at a later point, but is there a more elegant solution? You could define a COM / COM-like interface (or set of interfaces), implement them in C# and pass them to the C code. This is definitely cleaner but has the disadvantage of a tighter binding between the two parts and a potentially much more painful versioning story. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Fri Oct 19 18:59:29 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 19 Oct 2007 09:59:29 -0700 Subject: [IronPython] thread.interrupt_main() not implemented In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C2227D850A1C985@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I think you could work around this by remembering the main .NET thread and calling Abort on it: from System import Threading main = Thread.CurrentThread # and then later on... main.Abort() But I'd suggest that interrupting a thread at an arbitrary point is a little dangerous (as it may have some state which isn't entirely consistent that it's trying to update). From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Clems no Sent: Friday, October 19, 2007 8:37 AM To: users at lists.ironpython.com Subject: [IronPython] thread.interrupt_main() not implemented Hello, When i want to use thread.interrupt_main() in iron python script, i've got this error: NotImplementedError: interrupt_main not implemented Is there an equivalent in ironpython? Thanks, cbr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lupus at ximian.com Fri Oct 19 19:08:24 2007 From: lupus at ximian.com (Paolo Molaro) Date: Fri, 19 Oct 2007 19:08:24 +0200 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <4718D806.4000608@resolversystems.com> References: <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <20071017162636.GH27285@debian.org> <20071017170205.GK27285@debian.org> <47164F66.9030606@v-sim.com> <20071018171651.GW27285@debian.org> <4718D806.4000608@resolversystems.com> Message-ID: <20071019170823.GD27285@debian.org> On 10/19/07 Giles Thomas wrote: > A question - if we were trying to produce something that, at a source > level, looked like the CPython extensions API, is there any easy way > that we could get that to be able to call back to IronPython? I can > imagine something like an init() function on the managed side that could > pass a number of delegates over to the unmanaged code so that they could > be called back at a later point, but is there a more elegant solution? You can use a struct that contains all the needed delegates and pass that on the p/invoke call. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From giles.thomas at resolversystems.com Fri Oct 19 19:11:36 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Fri, 19 Oct 2007 18:11:36 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <20071019170823.GD27285@debian.org> References: <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <47138417.2030301@resolversystems.com> <20071017141636.GD27285@debian.org> <20071017162636.GH27285@debian.org> <20071017170205.GK27285@debian.org> <47164F66.9030606@v-sim.com> <20071018171651.GW27285@debian.org> <4718D806.4000608@resolversystems.com> <20071019170823.GD27285@debian.org> Message-ID: <4718E548.80004@resolversystems.com> Paolo Molaro wrote: > You can use a struct that contains all the needed delegates and pass > that on the p/invoke call. > > I guess that's a bit cleaner, as is Curt's COM version. But I was really hoping to be able to avoid the init call from the managed side entirely. Regards, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From curt at hagenlocher.org Fri Oct 19 19:16:34 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 19 Oct 2007 10:16:34 -0700 Subject: [IronPython] thread.interrupt_main() not implemented In-Reply-To: <7AD436E4270DD54A94238001769C2227D850A1C985@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C2227D850A1C985@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: thread.interrupt_main has somewhat different semantics than Thread.Abort; it basically triggers a keyboard interrupt on the main thread -- this is, of course, an exception that can be caught and handled by user code on that thread. On 10/19/07, Dino Viehland wrote: > I think you could work around this by remembering the main .NET thread > and calling Abort on it: > > > > from System import Threading > > main = Thread.CurrentThread > > > > # and then later on? > > > > main.Abort() > > > > But I'd suggest that interrupting a thread at an arbitrary point is a > little dangerous (as it may have some state which isn't entirely consistent > that it's trying to update). > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Clems no > *Sent:* Friday, October 19, 2007 8:37 AM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] thread.interrupt_main() not implemented > > > > Hello, > > When i want to use thread.interrupt_main() in iron python script, i've got > this error: > NotImplementedError: interrupt_main not implemented > > Is there an equivalent in ironpython? > > Thanks, > > cbr. > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Fri Oct 19 19:28:31 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 19 Oct 2007 10:28:31 -0700 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: <4718E548.80004@resolversystems.com> References: <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <20071017162636.GH27285@debian.org> <20071017170205.GK27285@debian.org> <47164F66.9030606@v-sim.com> <20071018171651.GW27285@debian.org> <4718D806.4000608@resolversystems.com> <20071019170823.GD27285@debian.org> <4718E548.80004@resolversystems.com> Message-ID: On 10/19/07, Giles Thomas wrote: > > Paolo Molaro wrote: > > You can use a struct that contains all the needed delegates and pass > > that on the p/invoke call. > > > I guess that's a bit cleaner, as is Curt's COM version. But I was > really hoping to be able to avoid the init call from the managed side > entirely. Hypothetically, you could muck about with the unmanaged interfaces to the managed code execution engine and pull in the information that way. How much of the MSCOREE-exposed functionality does Mono implement? Mind you, I don't actually think this is a good idea. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Fri Oct 19 19:31:22 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Fri, 19 Oct 2007 18:31:22 +0100 Subject: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython In-Reply-To: References: <7AD436E4270DD54A94238001769C2227D6053F7E39@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <20071017162636.GH27285@debian.org> <20071017170205.GK27285@debian.org> <47164F66.9030606@v-sim.com> <20071018171651.GW27285@debian.org> <4718D806.4000608@resolversystems.com> <20071019170823.GD27285@debian.org> <4718E548.80004@resolversystems.com> Message-ID: <4718E9EA.6090906@resolversystems.com> Curt Hagenlocher wrote: > > Hypothetically, you could muck about with the unmanaged interfaces to > the managed code execution engine and pull in the information that > way. How much of the MSCOREE-exposed functionality does Mono implement? > > Mind you, I don't actually think this is a good idea. It does sound risky. Perhaps just going with a struct as lupus suggested is the simplest cross-platform solution, even if it does require an initialisation function of some sort. Cheers, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From dinov at exchange.microsoft.com Fri Oct 19 19:34:12 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 19 Oct 2007 10:34:12 -0700 Subject: [IronPython] thread.interrupt_main() not implemented In-Reply-To: References: <7AD436E4270DD54A94238001769C2227D850A1C985@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <7AD436E4270DD54A94238001769C2227D850A1C9B5@DF-GRTDANE-MSG.exchange.corp.microsoft.com> And we implement that using Thread.Abort (which is the only way we really have to interrupt a thread at an arbitrary point in time) :) When the user catches it they'll see it as a KeyboardInterruptException, and we'll do the right thing for Thread.ResetAbort(). If you want to get the exact behavior we cause with Ctrl-C it's actually: import clr clr.AddReference('Microsoft.Scripting') from Microsoft.Scripting.Shell import KeyboardInterruptException main.Abort(KeyboardInterruptException("")) in v1.x it's: import clr clr.AddReference('IronPython') from IronPython.Runtime.Exceptions import PythonKeyboardInterruptException main.Abort(PythonKeyboardInterruptException("")) and then the user can catch it as a they'd catch a normal keyboard interrupt. I think the only reason we don't have this implemented by default is that in some situations (e.g. outside the console) we won't actually know what the "main" thread is. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Friday, October 19, 2007 10:17 AM To: Discussion of IronPython Subject: Re: [IronPython] thread.interrupt_main() not implemented thread.interrupt_main has somewhat different semantics than Thread.Abort; it basically triggers a keyboard interrupt on the main thread -- this is, of course, an exception that can be caught and handled by user code on that thread. On 10/19/07, Dino Viehland > wrote: I think you could work around this by remembering the main .NET thread and calling Abort on it: from System import Threading main = Thread.CurrentThread # and then later on... main.Abort() But I'd suggest that interrupting a thread at an arbitrary point is a little dangerous (as it may have some state which isn't entirely consistent that it's trying to update). From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Clems no Sent: Friday, October 19, 2007 8:37 AM To: users at lists.ironpython.com Subject: [IronPython] thread.interrupt_main() not implemented Hello, When i want to use thread.interrupt_main() in iron python script, i've got this error: NotImplementedError: interrupt_main not implemented Is there an equivalent in ironpython? Thanks, cbr. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Fri Oct 19 19:38:57 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 19 Oct 2007 10:38:57 -0700 Subject: [IronPython] thread.interrupt_main() not implemented In-Reply-To: <7AD436E4270DD54A94238001769C2227D850A1C9B5@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C2227D850A1C985@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <7AD436E4270DD54A94238001769C2227D850A1C9B5@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: Ah! On 10/19/07, Dino Viehland wrote: > > And we implement that using Thread.Abort (which is the only way we really > have to interrupt a thread at an arbitrary point in time) J When the user > catches it they'll see it as a KeyboardInterruptException, and we'll do the > right thing for Thread.ResetAbort(). > > > > If you want to get the exact behavior we cause with Ctrl-C it's actually: > > > > import clr > > clr.AddReference('Microsoft.Scripting') > > from Microsoft.Scripting.Shell import KeyboardInterruptException > > main.Abort(KeyboardInterruptException("")) > > > > in v1.x it's: > > > > import clr > > clr.AddReference('IronPython') > > from IronPython.Runtime.Exceptions import PythonKeyboardInterruptException > > main.Abort(PythonKeyboardInterruptException("")) > > > > and then the user can catch it as a they'd catch a normal keyboard > interrupt. I think the only reason we don't have this implemented by > default is that in some situations (e.g. outside the console) we won't > actually know what the "main" thread is. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Curt Hagenlocher > *Sent:* Friday, October 19, 2007 10:17 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] thread.interrupt_main() not implemented > > > > thread.interrupt_main has somewhat different semantics than Thread.Abort; > it basically triggers a keyboard interrupt on the main thread -- this is, of > course, an exception that can be caught and handled by user code on that > thread. > > > > On 10/19/07, *Dino Viehland* wrote: > > I think you could work around this by remembering the main .NET thread > and calling Abort on it: > > > > from System import Threading > > main = Thread.CurrentThread > > > > # and then later on? > > > > main.Abort() > > > > But I'd suggest that interrupting a thread at an arbitrary point is a > little dangerous (as it may have some state which isn't entirely consistent > that it's trying to update). > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Clems no > *Sent:* Friday, October 19, 2007 8:37 AM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] thread.interrupt_main() not implemented > > > > Hello, > > When i want to use thread.interrupt_main() in iron python script, i've got > this error: > NotImplementedError: interrupt_main not implemented > > Is there an equivalent in ironpython? > > Thanks, > > cbr. > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Fri Oct 19 20:28:51 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Fri, 19 Oct 2007 19:28:51 +0100 Subject: [IronPython] My takes on C Extensions for IronPython In-Reply-To: <1192668125.063702.76860@i38g2000prf.googlegroups.com> References: <1192668125.063702.76860@i38g2000prf.googlegroups.com> Message-ID: <4718F763.7070105@resolversystems.com> Seo Sanghyeon wrote: > The discussion is getting very confusing, > It is indeed! > The good news is that this part is already developed, debugged, and pretty much finished -- for Python 2.3 to 2.6, and for wide and narrow unicode builds of Python. Get it here (~ 1600 lines): > http://pythonnet.svn.sourceforge.net/svnroot/pythonnet/trunk/pythonnet/src/runtime/runtime.cs > > Assuming that ZPL (which is OSI-certified) is okay, it would be strange not to use this. > I'm a bit confused here... Unless I'm completely misunderstanding the code, it looks like it's a set of DllImports allowing you to access the CPython C extensions API from managed code. This let's you write managed code that extends CPython - which I assume is the Python.NET developers' intention - but we're trying to write unmanaged code to extend IronPython. Am I missing some obvious way in which we could use it? I guess it would work as a template to follow when writing the equivalent for calling into IronPython...? Regards, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From joshua.pearce at gmail.com Fri Oct 19 23:06:30 2007 From: joshua.pearce at gmail.com (Joshua J. Pearce) Date: Fri, 19 Oct 2007 17:06:30 -0400 Subject: [IronPython] Need a Good Embedded Example In-Reply-To: <278e6e410710181227h21c5a19dg203bfab80f52b3e8@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> <785694cd0710180845t26ebf8dr6f54039d2b5cc249@mail.gmail.com> <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> <785694cd0710181018y2ba09584q9cafad3a85e703b1@mail.gmail.com> <278e6e410710181055w7340efd2lb25590d55370aa33@mail.gmail.com> <785694cd0710181150w7b2d6e07lecb5afd8653a14f@mail.gmail.com> <278e6e410710181227h21c5a19dg203bfab80f52b3e8@mail.gmail.com> Message-ID: <278e6e410710191406s635b2cdub705107b3d196b78@mail.gmail.com> What am I doing wrong? I have a form with two text boxes and a button. When I type, "tb.clear()" into the first textbox and click the button, I get the a MissingMemberException which states, "'TextBox' object has no attribute 'clear'". public partial class Form1 : Form { public static PythonEngine pe = PythonEngine.CurrentEngine; public Form1() { InitializeComponent(); ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable("tb", textBox2); } private void button1_Click(object sender, EventArgs e) { pe.ExecuteCommand(textBox1.Text); } } Thanks, Josh Pearce On 10/18/07, Joshua J. Pearce wrote: > > I am very sorry! I just noticed this: > > ScriptDomainManager.CurrentMan > ager.Host.DefaultModule.SetVariable("SomeName", > SomeObject); > > SomeObject is then available to user code as SomeName... > > That is exactly what I want to do!!! > > Thank you very much! > > > > On 10/18/07, JoeSox wrote: > > > > On 10/18/07, Joshua J. Pearce wrote: > > > My application is ASP.NET, I hardly think integrating CPython is going > > to be a better choice. > > > > You never mentioned you were using ASP.NET. You have mentioned C#. > > > > > Is is possible to 'expose' c# methods that exist in the same scope as > > an IPY > > > engine, > > > > Can you clarify what you mean by this line for me? Can you provide a > > C# method that exists in the same scope as an IPY engine? > > > > There must be a custom interface, how would an outside script know > > about a custom method outside it's scope without an custom interface? > > Michael and myself have both provided examples. > > > > If you have a C# method it must be represented by something else in > > the script or python code that IronPythonEngine is using, then update > > the script or python code loaded in the IronPythonEngine using the > > examples provided. > > > > Since I have not seen your source, I don't know why you believe > > importing the AppService dll and create your own instance in the IP > > engine will be too much overhead. That sounds like the bet way to go > > but I am not familiar with your source. > > Good Luck! > > -- > > Later, JoeSox > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > -- > Joshua Pearce > -- Joshua Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronnie.maor at gmail.com Fri Oct 19 23:38:13 2007 From: ronnie.maor at gmail.com (Ronnie Maor) Date: Fri, 19 Oct 2007 23:38:13 +0200 Subject: [IronPython] bug with copy.copy of System.Int64? Message-ID: <2fd6b9d0710191438x102618c5ra180249ed03363cd@mail.gmail.com> I stumbled across the following problem copying System.Int64: C:\>ipy IronPython 1.1 (1.1) on .NET 2.0.50727.832 Copyright (c) Microsoft Corporation. All rights reserved. >>> import copy >>> from System import Int64 >>> x = Int64(3) >>> x 3L >>> copy.copy(x) 0L >>> copy.deepcopy(x) 0L Has anyone else come across this problem? Are there other types that will produce wrong copies? My current workaround is to convert the Int64 to a long. Some more notes: I'm using IronPython 1.1 with CPython 2.4 standard library. Doesn't happen with Int32 thanks Ronnie -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sat Oct 20 00:00:09 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 19 Oct 2007 23:00:09 +0100 Subject: [IronPython] [python] Re: Need a Good Embedded Example In-Reply-To: <278e6e410710191406s635b2cdub705107b3d196b78@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <278e6e410710171729i33995f0ew251e0c4496181e20@mail.gmail.com> <785694cd0710180653t4caba227q843767b30b45749@mail.gmail.com> <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> <785694cd0710180845t26ebf8dr6f54039d2b5cc249@mail.gmail.com> <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> <785694cd0710181018y2ba09584q9cafad3a85e703b1@mail.gmail.com> <278e6e410710181055w7340efd2lb25590d55370aa33@mail.gmail.com> <785694cd0710181150w7b2d6e07lecb5afd8653a14f@mail.gmail.com> <278e6e410710181227h21c5a19dg203bfab80f52b3e8@mail.gmail.com> <278e6e410710191406s635b2cdub705107b3d196b78@mail.gmail.com> Message-ID: <471928E9.1040508@voidspace.org.uk> Joshua J. Pearce wrote: > What am I doing wrong? I have a form with two text boxes and a button. > When I type, "tb.clear()" into the first textbox and click the button, > I get the a MissingMemberException which states, "'TextBox' object has > no attribute 'clear'". Do you mean "tb.Clear()" ? Michael > > > public partial class Form1 : Form > { > public static PythonEngine pe = PythonEngine.CurrentEngine; > public Form1() > { > InitializeComponent(); > > ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable("tb", > textBox2); > } > > > private void button1_Click(object sender, EventArgs e) > { > pe.ExecuteCommand (textBox1.Text); > > } > } > > > Thanks, > > Josh Pearce > > > On 10/18/07, *Joshua J. Pearce* < joshua.pearce at gmail.com > > wrote: > > I am very sorry! I just noticed this: > > ScriptDomainManager.CurrentMan > ager.Host.DefaultModule.SetVariable("SomeName", > SomeObject); > > SomeObject is then available to user code as SomeName... > > That is exactly what I want to do!!! > > Thank you very much! > > > > On 10/18/07, *JoeSox* > > wrote: > > On 10/18/07, Joshua J. Pearce > wrote: > > My application is ASP.NET , I hardly think > integrating CPython is going to be a better choice. > > You never mentioned you were using ASP.NET . > You have mentioned C#. > > > Is is possible to 'expose' c# methods that exist in the same > scope as an IPY > > engine, > > Can you clarify what you mean by this line for me? Can you > provide a > C# method that exists in the same scope as an IPY engine? > > There must be a custom interface, how would an outside script know > about a custom method outside it's scope without an custom > interface? > Michael and myself have both provided examples. > > If you have a C# method it must be represented by something > else in > the script or python code that IronPythonEngine is using, then > update > the script or python code loaded in the IronPythonEngine using > the > examples provided. > > Since I have not seen your source, I don't know why you believe > importing the AppService dll and create your own instance in > the IP > engine will be too much overhead. That sounds like the bet > way to go > but I am not familiar with your source. > Good Luck! > -- > Later, JoeSox > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > Joshua Pearce > > > > > -- > Joshua Pearce > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at exchange.microsoft.com Sat Oct 20 00:57:09 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 19 Oct 2007 15:57:09 -0700 Subject: [IronPython] bug with copy.copy of System.Int64? In-Reply-To: <2fd6b9d0710191438x102618c5ra180249ed03363cd@mail.gmail.com> References: <2fd6b9d0710191438x102618c5ra180249ed03363cd@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227D850A1CB3C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> This is because we don't define a custom __getnewargs__ for .NET data types. Therefore when the copy module tries to create the new instance it has no arguments and creates the default value - you'll get the same behavior with any random value type that isn't also a type in Python's type system. For other random .NET types you may or may not get a new instance (depending on whether or not the type has a parameterless constructor). We of course do define this for types like int because our int is Python's int. We could presumably support this with some value types: for example the primitive types such as Int64 (decimal, char, etc...) and types like enums where it's well-understood how to construct the value type. But we couldn't support it on arbitrary types. We could also even considering pushing this further and support any type which is serializable (at which point __reduce_ex__ would return a function which does the deserialization, and __getnewargs__ would return the serialized data). I've opened a feature request on CodePlex (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13401) to track this. If you (and anyone else who thinks this would be cool) would vote for the feature then it'll help us get the right priority on it. Thanks for the report! From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ronnie Maor Sent: Friday, October 19, 2007 2:38 PM To: users at lists.ironpython.com Subject: [IronPython] bug with copy.copy of System.Int64? I stumbled across the following problem copying System.Int64: C:\>ipy IronPython 1.1 (1.1) on .NET 2.0.50727.832 Copyright (c) Microsoft Corporation. All rights reserved. >>> import copy >>> from System import Int64 >>> x = Int64(3) >>> x 3L >>> copy.copy(x) 0L >>> copy.deepcopy(x) 0L Has anyone else come across this problem? Are there other types that will produce wrong copies? My current workaround is to convert the Int64 to a long. Some more notes: I'm using IronPython 1.1 with CPython 2.4 standard library. Doesn't happen with Int32 thanks Ronnie -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua.pearce at gmail.com Sat Oct 20 02:04:06 2007 From: joshua.pearce at gmail.com (Joshua J. Pearce) Date: Fri, 19 Oct 2007 20:04:06 -0400 Subject: [IronPython] [python] Re: Need a Good Embedded Example In-Reply-To: <471928E9.1040508@voidspace.org.uk> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> <785694cd0710180845t26ebf8dr6f54039d2b5cc249@mail.gmail.com> <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> <785694cd0710181018y2ba09584q9cafad3a85e703b1@mail.gmail.com> <278e6e410710181055w7340efd2lb25590d55370aa33@mail.gmail.com> <785694cd0710181150w7b2d6e07lecb5afd8653a14f@mail.gmail.com> <278e6e410710181227h21c5a19dg203bfab80f52b3e8@mail.gmail.com> <278e6e410710191406s635b2cdub705107b3d196b78@mail.gmail.com> <471928E9.1040508@voidspace.org.uk> Message-ID: <278e6e410710191704w7baff007k1a6eb9b60cc27f6e@mail.gmail.com> Thanks! Where can I find help with getting the python engine to deal with the indents involved with loops, defs, and such? I read Mike Stalls article, 10 Easy Steps to Embedding..., but I still can't understand the difference between evaluate and execute methods. I am trying to use IPY as a scripting language for my ASP.NET app, so I really need to know how to build my own shell in C# in addition to the help you all have already given me in using my c# classes in the python code. Thanks! On 10/19/07, Michael Foord wrote: > > Joshua J. Pearce wrote: > > What am I doing wrong? I have a form with two text boxes and a button. > > When I type, "tb.clear()" into the first textbox and click the button, > > I get the a MissingMemberException which states, "'TextBox' object has > > no attribute 'clear'". > > Do you mean "tb.Clear()" ? > > Michael > > > > > > > > public partial class Form1 : Form > > { > > public static PythonEngine pe = PythonEngine.CurrentEngine; > > public Form1() > > { > > InitializeComponent(); > > > > ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable("tb", > > textBox2); > > } > > > > > > private void button1_Click(object sender, EventArgs e) > > { > > pe.ExecuteCommand (textBox1.Text); > > > > } > > } > > > > > > Thanks, > > > > Josh Pearce > > > > > > On 10/18/07, *Joshua J. Pearce* < joshua.pearce at gmail.com > > > wrote: > > > > I am very sorry! I just noticed this: > > > > ScriptDomainManager.CurrentMan > > ager.Host.DefaultModule.SetVariable("SomeName", > > SomeObject); > > > > SomeObject is then available to user code as SomeName... > > > > That is exactly what I want to do!!! > > > > Thank you very much! > > > > > > > > On 10/18/07, *JoeSox* > > > wrote: > > > > On 10/18/07, Joshua J. Pearce > > wrote: > > > My application is ASP.NET , I hardly think > > integrating CPython is going to be a better choice. > > > > You never mentioned you were using ASP.NET . > > You have mentioned C#. > > > > > Is is possible to 'expose' c# methods that exist in the same > > scope as an IPY > > > engine, > > > > Can you clarify what you mean by this line for me? Can you > > provide a > > C# method that exists in the same scope as an IPY engine? > > > > There must be a custom interface, how would an outside script > know > > about a custom method outside it's scope without an custom > > interface? > > Michael and myself have both provided examples. > > > > If you have a C# method it must be represented by something > > else in > > the script or python code that IronPythonEngine is using, then > > update > > the script or python code loaded in the IronPythonEngine using > > the > > examples provided. > > > > Since I have not seen your source, I don't know why you believe > > importing the AppService dll and create your own instance in > > the IP > > engine will be too much overhead. That sounds like the bet > > way to go > > but I am not familiar with your source. > > Good Luck! > > -- > > Later, JoeSox > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > > -- > > Joshua Pearce > > > > > > > > > > -- > > Joshua Pearce > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Joshua Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From vizcaynot at gmail.com Sat Oct 20 06:01:20 2007 From: vizcaynot at gmail.com (Vizcayno Tamparantan) Date: Sat, 20 Oct 2007 00:01:20 -0400 Subject: [IronPython] A help with an Active Directory object please. Message-ID: Sorry for the long content!! I am trying to recover, in date format, the "AccountExpires" attribute from an Active Directory database. When an account never expires, "AccountExpires" attribute can have two possible values: zero or 9223372036854775807, the last large value is System.Int64 but I need to convert it to IADsLargeInteger which is an "COM Interop Type" object of Active Directory that then, lets me convert to date format. I have the next C# example I took from a publication that would like to write in ipy: using ActivedsNET; public static IADsLargeInteger GetLargeInteger(long value) { IADsLargeInteger largeInteger = new LargeInteger(); largeInteger.HighPart = (int) (value << 32); largeInteger.LowPart = (int) (value & 0xFFFFFFFF); return largeInteger; } Observe that I need to have ActivedsNET which is a runtime-callable wrapper (RCW). After some investigation to get this as an assembly, I used next SDK command: tlbimp.exe activeds.tlb /out:activedsNET.dll /namespace:ActivedsNET getting next warning messages during conversion: TlbImp : warning TI0000 : The type library importer could not convert the signature for the member 'ADS_OCTET_STRING.lpValue'. TlbImp : warning TI0000 : The type library importer could not convert the signature for the member '__MIDL___MIDL_itf_ads_0000_0002.lpValue'. . . . TlbImp : warning TI0000 : At least one of the arguments for ' IDirectorySchemaMgmt.EnumAttributes' cannot be marshaled by the runtime marshaler. Such arguments will therefore be passed as a pointer and may require unsafe code to manipulate. TlbImp : warning TI0000 : At least one of the arguments for ' IDirectorySchemaMgmt.EnumClasses' cannot be marshaled by the runtime marshaler. Such arguments will therefore be passed as a pointer and may require unsafe code to manipulate. Type library imported to c:\os\ipy\src\activedsNET.dll After getting the .dll expected, I attempted to import into ipy 2.0a4 and ipy 2.0a5 having the next behavior: >>> import clr >>> clr.AddReferenceToFile("activedsNET.dll") #Seems not be problem here >>> dir(activedsNET) Traceback (most recent call last): File , line 0, in ##245 NameError: name 'activedsNET' is not defined >>> dir() ['__builtins__', '__doc__', '__name__', 'clr', 'sys'] #ActivedsNET is not showed >>> What do you think is bad here? Is this possible to help me with the info I gave? or do you need additional one. Really, thanks for your attention. Vizcayno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sat Oct 20 12:04:38 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 20 Oct 2007 11:04:38 +0100 Subject: [IronPython] [python] Re: Need a Good Embedded Example In-Reply-To: <278e6e410710191704w7baff007k1a6eb9b60cc27f6e@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <278e6e410710180748n2a050f8ibab4f7dfb9aab21@mail.gmail.com> <785694cd0710180845t26ebf8dr6f54039d2b5cc249@mail.gmail.com> <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> <785694cd0710181018y2ba09584q9cafad3a85e703b1@mail.gmail.com> <278e6e410710181055w7340efd2lb25590d55370aa33@mail.gmail.com> <785694cd0710181150w7b2d6e07lecb5afd8653a14f@mail.gmail.com> <278e6e410710181227h21c5a19dg203bfab80f52b3e8@mail.gmail.com> <278e6e410710191406s635b2cdub705107b3d196b78@mail.gmail.com> <471928E9.1040508@voidspace.org.uk> <278e6e410710191704w7baff007k1a6eb9b60cc27f6e@mail.gmail.com> Message-ID: <4719D2B6.7070203@voidspace.org.uk> Joshua J. Pearce wrote: > Thanks! Where can I find help with getting the python engine to deal > with the indents involved with loops, defs, and such? Well - indents and loops and such is just ordinary Python code. Do you want this code to be entered one line at a time, like an interactive interpreter? If you're executing code from a multiline textblock - then it shouldn't be a problem as you won't be executing code one line at a time... In Mike Stall's article 'Evaluate' executes a single expression and returns the result. 'Execute' executes a block of code. That article is from 2005 though. Michael http://www.manning.com/foord > I read Mike Stalls article, 10 Easy Steps to Embedding..., but I still > can't understand the difference between evaluate and execute methods. > > I am trying to use IPY as a scripting language for my ASP.NET > app, so I really need to know how to build my own > shell in C# in addition to the help you all have already given me in > using my c# classes in the python code. > > Thanks! > > On 10/19/07, *Michael Foord* > wrote: > > Joshua J. Pearce wrote: > > What am I doing wrong? I have a form with two text boxes and a > button. > > When I type, "tb.clear()" into the first textbox and click the > button, > > I get the a MissingMemberException which states, "'TextBox' > object has > > no attribute 'clear'". > > Do you mean "tb.Clear()" ? > > Michael > > > > > > > > public partial class Form1 : Form > > { > > public static PythonEngine pe = PythonEngine.CurrentEngine; > > public Form1() > > { > > InitializeComponent(); > > > > > ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable("tb", > > textBox2); > > } > > > > > > private void button1_Click(object sender, EventArgs e) > > { > > pe.ExecuteCommand (textBox1.Text); > > > > } > > } > > > > > > Thanks, > > > > Josh Pearce > > > > > > On 10/18/07, *Joshua J. Pearce* < joshua.pearce at gmail.com > > > >> wrote: > > > > I am very sorry! I just noticed this: > > > > ScriptDomainManager.CurrentMan > > ager.Host.DefaultModule.SetVariable("SomeName", > > SomeObject); > > > > SomeObject is then available to user code as SomeName... > > > > That is exactly what I want to do!!! > > > > Thank you very much! > > > > > > > > On 10/18/07, *JoeSox* >> > > wrote: > > > > On 10/18/07, Joshua J. Pearce < joshua.pearce at gmail.com > > > >> wrote: > > > My application is ASP.NET > , I hardly think > > integrating CPython is going to be a better choice. > > > > You never mentioned you were using ASP.NET > . > > You have mentioned C#. > > > > > Is is possible to 'expose' c# methods that exist in > the same > > scope as an IPY > > > engine, > > > > Can you clarify what you mean by this line for me? Can you > > provide a > > C# method that exists in the same scope as an IPY engine? > > > > There must be a custom interface, how would an outside > script know > > about a custom method outside it's scope without an custom > > interface? > > Michael and myself have both provided examples. > > > > If you have a C# method it must be represented by something > > else in > > the script or python code that IronPythonEngine is > using, then > > update > > the script or python code loaded in the IronPythonEngine > using > > the > > examples provided. > > > > Since I have not seen your source, I don't know why you > believe > > importing the AppService dll and create your own > instance in > > the IP > > engine will be too much overhead. That sounds like the bet > > way to go > > but I am not familiar with your source. > > Good Luck! > > -- > > Later, JoeSox > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > Users at lists.ironpython.com > > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > > > -- > > Joshua Pearce > > > > > > > > > > -- > > Joshua Pearce > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > Joshua Pearce > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From sanxiyn at gmail.com Sat Oct 20 15:37:49 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sat, 20 Oct 2007 22:37:49 +0900 Subject: [IronPython] A help with an Active Directory object please. In-Reply-To: References: Message-ID: <5b0248170710200637x71ff605fpfa454880d2684b2b@mail.gmail.com> 2007/10/20, Vizcayno Tamparantan : > >>> import clr > >>> clr.AddReferenceToFile("activedsNET.dll") #Seems not be problem here > >>> dir(activedsNET) > Traceback (most recent call last): > File , line 0, in ##245 > NameError: name 'activedsNET' is not defined > > >>> dir() > ['__builtins__', '__doc__', '__name__', 'clr', 'sys'] #ActivedsNET is not > showed Adding the reference and importing the namespace are separate steps. Therefore, to use System.Xml namespace contained in System.Xml.dll, you do: import clr clr.AddReference('System.Xml') import System.Xml Referenced assemblies may contain multiple namespaces. -- Seo Sanghyeon From vizcaynot at gmail.com Mon Oct 22 02:39:26 2007 From: vizcaynot at gmail.com (Vizcayno) Date: Mon, 22 Oct 2007 00:39:26 -0000 Subject: [IronPython] A help with an Active Directory object please. In-Reply-To: <5b0248170710200637x71ff605fpfa454880d2684b2b@mail.gmail.com> References: <5b0248170710200637x71ff605fpfa454880d2684b2b@mail.gmail.com> Message-ID: <1193013566.972434.136120@k35g2000prh.googlegroups.com> Sanghyeon: Many thanks for your help. It worked. One more help related to this thread, please; how would you write the next C# code in Ipy or at least, would you give me some guidelines. I especially have difficult to represent the line: IADsLargeInteger largeInteger = new LargeInteger(); using ActivedsNET; public static IADsLargeInteger GetLargeInteger(long value) { IADsLargeInteger largeInteger = new LargeInteger(); largeInteger.HighPart = (int) (value << 32); largeInteger.LowPart = (int) (value & 0xFFFFFFFF); return largeInteger; } Thank you again!! Vizcayno. On 20 oct, 09:37, "Sanghyeon Seo" wrote: > 2007/10/20, Vizcayno Tamparantan : > > > >>> import clr > > >>> clr.AddReferenceToFile("activedsNET.dll") #Seems not be problem here > > >>> dir(activedsNET) > > Traceback (most recent call last): > > File , line 0, in ##245 > > NameError: name 'activedsNET' is not defined > > > >>> dir() > > ['__builtins__', '__doc__', '__name__', 'clr', 'sys'] #ActivedsNET is not > > showed > > Adding the reference and importing the namespace are separate steps. > Therefore, to use System.Xml namespace contained in System.Xml.dll, > you do: > > import clr > clr.AddReference('System.Xml') > import System.Xml > > Referenced assemblies may contain multiple namespaces. > > -- > Seo Sanghyeon > _______________________________________________ > Users mailing list > Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Mon Oct 22 02:48:39 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 22 Oct 2007 09:48:39 +0900 Subject: [IronPython] A help with an Active Directory object please. In-Reply-To: <1193013566.972434.136120@k35g2000prh.googlegroups.com> References: <5b0248170710200637x71ff605fpfa454880d2684b2b@mail.gmail.com> <1193013566.972434.136120@k35g2000prh.googlegroups.com> Message-ID: <5b0248170710211748t62f4c817nd3026f1b9ead3221@mail.gmail.com> 2007/10/22, Vizcayno : > I especially have difficult to represent the line: > IADsLargeInteger largeInteger = new LargeInteger(); I think largeInteger = ActivedsNET.LargeInteger() In IronPython instances are constructed by calling types. -- Seo Sanghyeon From cbrdev at gmail.com Mon Oct 22 11:09:43 2007 From: cbrdev at gmail.com (Clems no) Date: Mon, 22 Oct 2007 11:09:43 +0200 Subject: [IronPython] thread.interrupt_main() not implemented In-Reply-To: References: <7AD436E4270DD54A94238001769C2227D850A1C985@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <7AD436E4270DD54A94238001769C2227D850A1C9B5@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: it's exactly what i need Thank you Dino 2007/10/19, Curt Hagenlocher : > > Ah! > > On 10/19/07, Dino Viehland wrote: > > > > And we implement that using Thread.Abort (which is the only way we > > really have to interrupt a thread at an arbitrary point in time) J When > > the user catches it they'll see it as a KeyboardInterruptException, and > > we'll do the right thing for Thread.ResetAbort(). > > > > > > > > If you want to get the exact behavior we cause with Ctrl-C it's > > actually: > > > > > > > > import clr > > > > clr.AddReference('Microsoft.Scripting') > > > > from Microsoft.Scripting.Shell import KeyboardInterruptException > > > > main.Abort(KeyboardInterruptException("")) > > > > > > > > in v1.x it's: > > > > > > > > import clr > > > > clr.AddReference('IronPython') > > > > from IronPython.Runtime.Exceptions import > > PythonKeyboardInterruptException > > > > main.Abort(PythonKeyboardInterruptException("")) > > > > > > > > and then the user can catch it as a they'd catch a normal keyboard > > interrupt. I think the only reason we don't have this implemented by > > default is that in some situations ( e.g. outside the console) we won't > > actually know what the "main" thread is. > > > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > > users-bounces at lists.ironpython.com] *On Behalf Of *Curt Hagenlocher > > *Sent: * Friday, October 19, 2007 10:17 AM > > *To:* Discussion of IronPython > > *Subject:* Re: [IronPython] thread.interrupt_main() not implemented > > > > > > > > thread.interrupt_main has somewhat different semantics than Thread.Abort; > > it basically triggers a keyboard interrupt on the main thread -- this is, of > > course, an exception that can be caught and handled by user code on that > > thread. > > > > > > > > On 10/19/07, *Dino Viehland* wrote: > > > > I think you could work around this by remembering the main .NET thread > > and calling Abort on it: > > > > > > > > from System import Threading > > > > main = Thread.CurrentThread > > > > > > > > # and then later on? > > > > > > > > main.Abort() > > > > > > > > But I'd suggest that interrupting a thread at an arbitrary point is a > > little dangerous (as it may have some state which isn't entirely consistent > > that it's trying to update). > > > > > > > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > > users-bounces at lists.ironpython.com] *On Behalf Of *Clems no > > *Sent:* Friday, October 19, 2007 8:37 AM > > *To:* users at lists.ironpython.com > > *Subject:* [IronPython] thread.interrupt_main() not implemented > > > > > > > > Hello, > > > > When i want to use thread.interrupt_main() in iron python script, i've > > got this error: > > NotImplementedError: interrupt_main not implemented > > > > Is there an equivalent in ironpython? > > > > Thanks, > > > > cbr. > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua.pearce at gmail.com Mon Oct 22 17:47:47 2007 From: joshua.pearce at gmail.com (Joshua J. Pearce) Date: Mon, 22 Oct 2007 11:47:47 -0400 Subject: [IronPython] [python] Re: Need a Good Embedded Example In-Reply-To: <4719D2B6.7070203@voidspace.org.uk> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> <785694cd0710181018y2ba09584q9cafad3a85e703b1@mail.gmail.com> <278e6e410710181055w7340efd2lb25590d55370aa33@mail.gmail.com> <785694cd0710181150w7b2d6e07lecb5afd8653a14f@mail.gmail.com> <278e6e410710181227h21c5a19dg203bfab80f52b3e8@mail.gmail.com> <278e6e410710191406s635b2cdub705107b3d196b78@mail.gmail.com> <471928E9.1040508@voidspace.org.uk> <278e6e410710191704w7baff007k1a6eb9b60cc27f6e@mail.gmail.com> <4719D2B6.7070203@voidspace.org.uk> Message-ID: <278e6e410710220847p5ffc5a30naf846e6a25d096e2@mail.gmail.com> I tried to following code in my simple test app: var1 = "Josh" for i in range(5): print i pe.ExecuteCommand threw a SyntaxErrorException, "unexpected token 'for' exception. It works fine if execute it in a file like, ipy test.py at the command line. If I leave off the "var1 = "Josh", and the for loop starts at the first line, it works. The problem I am having probably stems from my lack of understanding of the ipy engine, but I though that this statement: If you're executing code from a multiline textblock - then it shouldn't be a problem as you won't be executing code one line at a time... suggested my code would work. - Josh Pearce On 10/20/07, Michael Foord wrote: > > Joshua J. Pearce wrote: > > Thanks! Where can I find help with getting the python engine to deal > > with the indents involved with loops, defs, and such? > Well - indents and loops and such is just ordinary Python code. Do you > want this code to be entered one line at a time, like an interactive > interpreter? > > If you're executing code from a multiline textblock - then it shouldn't > be a problem as you won't be executing code one line at a time... > > In Mike Stall's article > > 'Evaluate' executes a single expression and returns the result. > > 'Execute' executes a block of code. > > That article is from 2005 though. > > Michael > http://www.manning.com/foord > > > I read Mike Stalls article, 10 Easy Steps to Embedding..., but I still > > can't understand the difference between evaluate and execute methods. > > > > I am trying to use IPY as a scripting language for my ASP.NET > > app, so I really need to know how to build my own > > shell in C# in addition to the help you all have already given me in > > using my c# classes in the python code. > > > > Thanks! > > > > On 10/19/07, *Michael Foord* > > wrote: > > > > Joshua J. Pearce wrote: > > > What am I doing wrong? I have a form with two text boxes and a > > button. > > > When I type, "tb.clear()" into the first textbox and click the > > button, > > > I get the a MissingMemberException which states, "'TextBox' > > object has > > > no attribute 'clear'". > > > > Do you mean "tb.Clear()" ? > > > > Michael > > > > > > > > > > > > > public partial class Form1 : Form > > > { > > > public static PythonEngine pe = PythonEngine.CurrentEngine > ; > > > public Form1() > > > { > > > InitializeComponent(); > > > > > > > > ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable > ("tb", > > > textBox2); > > > } > > > > > > > > > private void button1_Click(object sender, EventArgs e) > > > { > > > pe.ExecuteCommand (textBox1.Text); > > > > > > } > > > } > > > > > > > > > Thanks, > > > > > > Josh Pearce > > > > > > > > > On 10/18/07, *Joshua J. Pearce* < joshua.pearce at gmail.com > > > > > > >> wrote: > > > > > > I am very sorry! I just noticed this: > > > > > > ScriptDomainManager.CurrentMan > > > ager.Host.DefaultModule.SetVariable("SomeName", > > > SomeObject); > > > > > > SomeObject is then available to user code as SomeName... > > > > > > That is exactly what I want to do!!! > > > > > > Thank you very much! > > > > > > > > > > > > On 10/18/07, *JoeSox* > > >> > > > wrote: > > > > > > On 10/18/07, Joshua J. Pearce < joshua.pearce at gmail.com > > > > > > >> wrote: > > > > My application is ASP.NET > > , I hardly think > > > integrating CPython is going to be a better choice. > > > > > > You never mentioned you were using ASP.NET > > . > > > You have mentioned C#. > > > > > > > Is is possible to 'expose' c# methods that exist in > > the same > > > scope as an IPY > > > > engine, > > > > > > Can you clarify what you mean by this line for me? Can > you > > > provide a > > > C# method that exists in the same scope as an IPY engine? > > > > > > There must be a custom interface, how would an outside > > script know > > > about a custom method outside it's scope without an custom > > > interface? > > > Michael and myself have both provided examples. > > > > > > If you have a C# method it must be represented by > something > > > else in > > > the script or python code that IronPythonEngine is > > using, then > > > update > > > the script or python code loaded in the IronPythonEngine > > using > > > the > > > examples provided. > > > > > > Since I have not seen your source, I don't know why you > > believe > > > importing the AppService dll and create your own > > instance in > > > the IP > > > engine will be too much overhead. That sounds like the > bet > > > way to go > > > but I am not familiar with your source. > > > Good Luck! > > > -- > > > Later, JoeSox > > > _______________________________________________ > > > Users mailing list > > > Users at lists.ironpython.com > > > Users at lists.ironpython.com > > > > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > > > > > > > > > -- > > > Joshua Pearce > > > > > > > > > > > > > > > -- > > > Joshua Pearce > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > Users mailing list > > > Users at lists.ironpython.com > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > > -- > > Joshua Pearce > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Joshua Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Oct 22 22:24:25 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 22 Oct 2007 21:24:25 +0100 Subject: [IronPython] [python] Re: Need a Good Embedded Example In-Reply-To: <278e6e410710220847p5ffc5a30naf846e6a25d096e2@mail.gmail.com> References: <278e6e410710171000m4a606281p5d0b5eeda6973652@mail.gmail.com> <278e6e410710180922l21e8d4aepcccee7ffb5a6afdf@mail.gmail.com> <785694cd0710181018y2ba09584q9cafad3a85e703b1@mail.gmail.com> <278e6e410710181055w7340efd2lb25590d55370aa33@mail.gmail.com> <785694cd0710181150w7b2d6e07lecb5afd8653a14f@mail.gmail.com> <278e6e410710181227h21c5a19dg203bfab80f52b3e8@mail.gmail.com> <278e6e410710191406s635b2cdub705107b3d196b78@mail.gmail.com> <471928E9.1040508@voidspace.org.uk> <278e6e410710191704w7baff007k1a6eb9b60cc27f6e@mail.gmail.com> <4719D2B6.7070203@voidspace.org.uk> <278e6e410710220847p5ffc5a30naf846e6a25d096e2@mail.gmail.com> Message-ID: <471D06F9.1020702@voidspace.org.uk> Joshua J. Pearce wrote: > I tried to following code in my simple test app: > > var1 = "Josh" > for i in range(5): > print i > > pe.ExecuteCommand threw a SyntaxErrorException, "unexpected token > 'for' exception. > Try using Execute instead of ExecuteCommand. Michael http://www.manning.com/foord > It works fine if execute it in a file like, ipy test.py at the command > line. > > If I leave off the "var1 = "Josh", and the for loop starts at the > first line, it works. > The problem I am having probably stems from my lack of understanding > of the ipy engine, but I though that this statement: > > If you're executing code from a multiline textblock - then it shouldn't > be a problem as you won't be executing code one line at a time... > > suggested my code would work. > > - Josh Pearce > > On 10/20/07, *Michael Foord* > wrote: > > Joshua J. Pearce wrote: > > Thanks! Where can I find help with getting the python engine to deal > > with the indents involved with loops, defs, and such? > Well - indents and loops and such is just ordinary Python code. Do > you > want this code to be entered one line at a time, like an interactive > interpreter? > > If you're executing code from a multiline textblock - then it > shouldn't > be a problem as you won't be executing code one line at a time... > > In Mike Stall's article > > 'Evaluate' executes a single expression and returns the result. > > 'Execute' executes a block of code. > > That article is from 2005 though. > > Michael > http://www.manning.com/foord > > > I read Mike Stalls article, 10 Easy Steps to Embedding..., but I > still > > can't understand the difference between evaluate and execute > methods. > > > > I am trying to use IPY as a scripting language for my ASP.NET > > > app, so I really need to know how to build my own > > shell in C# in addition to the help you all have already given me in > > using my c# classes in the python code. > > > > Thanks! > > > > On 10/19/07, *Michael Foord* < fuzzyman at voidspace.org.uk > > > >> wrote: > > > > Joshua J. Pearce wrote: > > > What am I doing wrong? I have a form with two text boxes > and a > > button. > > > When I type, "tb.clear()" into the first textbox and click the > > button, > > > I get the a MissingMemberException which states, "'TextBox' > > object has > > > no attribute 'clear'". > > > > Do you mean "tb.Clear()" ? > > > > Michael > > > > > > > > > > > > > public partial class Form1 : Form > > > { > > > public static PythonEngine pe = > PythonEngine.CurrentEngine; > > > public Form1() > > > { > > > InitializeComponent(); > > > > > > > > > ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable("tb", > > > textBox2); > > > } > > > > > > > > > private void button1_Click(object sender, EventArgs e) > > > { > > > pe.ExecuteCommand (textBox1.Text); > > > > > > } > > > } > > > > > > > > > Thanks, > > > > > > Josh Pearce > > > > > > > > > On 10/18/07, *Joshua J. Pearce* < joshua.pearce at gmail.com > > > > > > > > > >>> wrote: > > > > > > I am very sorry! I just noticed this: > > > > > > ScriptDomainManager.CurrentMan > > > ager.Host.DefaultModule.SetVariable("SomeName", > > > SomeObject); > > > > > > SomeObject is then available to user code as SomeName... > > > > > > That is exactly what I want to do!!! > > > > > > Thank you very much! > > > > > > > > > > > > On 10/18/07, *JoeSox* < joesox at gmail.com > > > > > > > >>> > > > wrote: > > > > > > On 10/18/07, Joshua J. Pearce < > joshua.pearce at gmail.com > > > > > > > > >>> wrote: > > > > My application is ASP.NET > > > , I hardly think > > > integrating CPython is going to be a better choice. > > > > > > You never mentioned you were using ASP.NET > > > . > > > You have mentioned C#. > > > > > > > Is is possible to 'expose' c# methods that exist in > > the same > > > scope as an IPY > > > > engine, > > > > > > Can you clarify what you mean by this line for > me? Can you > > > provide a > > > C# method that exists in the same scope as an IPY > engine? > > > > > > There must be a custom interface, how would an outside > > script know > > > about a custom method outside it's scope without > an custom > > > interface? > > > Michael and myself have both provided examples. > > > > > > If you have a C# method it must be represented by > something > > > else in > > > the script or python code that IronPythonEngine is > > using, then > > > update > > > the script or python code loaded in the > IronPythonEngine > > using > > > the > > > examples provided. > > > > > > Since I have not seen your source, I don't know > why you > > believe > > > importing the AppService dll and create your own > > instance in > > > the IP > > > engine will be too much overhead. That sounds > like the bet > > > way to go > > > but I am not familiar with your source. > > > Good Luck! > > > -- > > > Later, JoeSox > > > _______________________________________________ > > > Users mailing list > > > Users at lists.ironpython.com > > > > > Users at lists.ironpython.com > > >> > > > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > > > > > > > > > -- > > > Joshua Pearce > > > > > > > > > > > > > > > -- > > > Joshua Pearce > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > Users mailing list > > > Users at lists.ironpython.com > > > > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > > > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > > > -- > > Joshua Pearce > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > Joshua Pearce > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From fuzzyman at voidspace.org.uk Tue Oct 23 11:56:30 2007 From: fuzzyman at voidspace.org.uk (Fuzzyman) Date: Tue, 23 Oct 2007 10:56:30 +0100 Subject: [IronPython] CPython Extensions from IronPython Message-ID: <471DC54E.10403@voidspace.org.uk> Hello all, Yesterday I spent some time looking at hosting the CPython interpreter from IronPython. Thanks to Jonathon Hogg for suggesting we try embedding and Seo for pointing us to Python.NET. Thanks also to Resolver for letting me spend time on this. Basically the Python.NET has already wrapped CPython as an assembly for embedding in .NET applications. It is quite a thin wrapper around the embedding API, so you have to acquire and release the GIL around everything and you send and receive PyObjects. I'll write up what I've done and post it, with the code, to my blog - and send a heads up to these lists. What I have achieved is only proof of concept and far from the final solution. It is not even clear that this is the final approach we will take. The next step is for us to experiment with replicating the CPython API and recompiling extensions with managed C++. This should give us an idea of which path will be most fruitful. The work I have done so far has some serious limitations, but it does work, so if you have a desperate need to use CPython extensions from IronPython you can probably build on what I have done. I have passing data-structures in both directions working (ints, floats, strings, tuples, lists and dictionaries), with object proxying for everything else. The GIL is acquired and released for you around everything. I have successfully used matplotlib with Tkinter from IronPython with this! I still have issues with passing booleans and None in and out, plus other basic types like complex numbers aren't converted for you (not difficult problems I just haven't sorted it out). Additionally data structures are copied in and out which is expensive - and you lose changes that CPython makes to mutable data structures you pass in. Magic methods aren't yet proxied because I am just using '__getattr__' for proxying attribute access and '__call__' for proxying calls. A '__getattribute__' approach, or implementing the magic methods on the proxy objects would get round some of these problems - but not (I think) solve type checking issues. For more efficient work you can leave data as PyObject structures rather than copy. One avenue of investigation would be to see if we can make these PyObject structures (managed wrappers around the CPython data) behave like their equivalent IronPython objects. This would allow some source code to operate unmodified. Oh - and my approach only works with IronPython 2 because of the annoying bug when passing Arrays as arguments in IronPython 1. This can be worked around, but targeting IronPython 2 may be better as we could look at using the DLR to help with making PyObjects behave like IronPython data types. All the best, Michael Foord http://www.manning.com/foord From Noah.McCalment at mts.com Tue Oct 23 18:42:07 2007 From: Noah.McCalment at mts.com (McCalment, Noah) Date: Tue, 23 Oct 2007 11:42:07 -0500 Subject: [IronPython] IronPython and C# asynchronous events Message-ID: All, I've been having some trouble connecting IronPython to events in C#. The issue is illustrated in the short test class and test script attached to this email. Specifically, the problem is this: When an external event is raised to this C# class, the event handler calls a function which iterates through the list of subscribers. When these subscribers are invoked synchronously, there is no issue; everything works fine. However, if the subscribers are invoked asynchronously, IronPython methods cannot be directly added to the subscriber list. An ArgumentNullException exception is thrown inside the .Net runtime library, somewhere in the bowels of the remoting subsystem. My questions are these: 1) Is it possible to make asynchronous events "just work", i.e. allow IronPython scripts to simply call += on an event member in a C# class and have the subscriber fire whether it is synchronous or asynchronous? 2) I have found a workaround that involves using reflection to retrieve a MethodInfo object that gets passed to Delegate.CreateDelegate(). However, this requires me to dynamically compile a C# helper class to handle events, because I cannot find a way to retrieve a MethodInfo for a stock IronPython method. Is this possible, and if so, how? Thanks for your time, Noah -------------- next part -------------- A non-text attachment was scrubbed... Name: TestEvents.py Type: application/octet-stream Size: 259 bytes Desc: TestEvents.py URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Class1.cs Type: application/octet-stream Size: 1358 bytes Desc: Class1.cs URL: From fuzzyman at voidspace.org.uk Tue Oct 23 18:59:02 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 23 Oct 2007 17:59:02 +0100 Subject: [IronPython] [python] IronPython and C# asynchronous events In-Reply-To: References: Message-ID: <471E2856.30201@voidspace.org.uk> Hello Noah, We've had no problems with synchronous and asynchronous events from IronPython (possibly try using the CallTarget0 delegate?), which suggests something wrong with your code. Michael http://www.manning.com/foord McCalment, Noah wrote: > All, > > I've been having some trouble connecting IronPython to events in C#. > The issue is illustrated in the short test class and test script > attached to this email. Specifically, the problem is this: When an > external event is raised to this C# class, the event handler calls a > function which iterates through the list of subscribers. When these > subscribers are invoked synchronously, there is no issue; everything > works fine. However, if the subscribers are invoked asynchronously, > IronPython methods cannot be directly added to the subscriber list. An > ArgumentNullException exception is thrown inside the .Net runtime > library, somewhere in the bowels of the remoting subsystem. My > questions are these: 1) Is it possible to make asynchronous events "just > work", i.e. allow IronPython scripts to simply call += on an event > member in a C# class and have the subscriber fire whether it is > synchronous or asynchronous? 2) I have found a workaround that involves > using reflection to retrieve a MethodInfo object that gets passed to > Delegate.CreateDelegate(). However, this requires me to dynamically > compile a C# helper class to handle events, because I cannot find a way > to retrieve a MethodInfo for a stock IronPython method. Is this > possible, and if so, how? > > Thanks for your time, > Noah > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at exchange.microsoft.com Tue Oct 23 19:04:03 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 23 Oct 2007 10:04:03 -0700 Subject: [IronPython] Compilation error In-Reply-To: <5b0248170710171858u71f7c275wbfe70cf0756de4c0@mail.gmail.com> References: <5b0248170710041742j42e3fa0av1504df1d45ea2de3@mail.gmail.com> <7AD436E4270DD54A94238001769C2227CCBD231097@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <5b0248170710041821j1e197667q1005a7ad77e3a83a@mail.gmail.com> <7AD436E4270DD54A94238001769C2227CCBD5EFCB8@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <5b0248170710171858u71f7c275wbfe70cf0756de4c0@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227D851081823@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Ok, after a little back and forth, here's what I've founded out: The spec is a little unclear in that it doesn't mention whether private members need to be assigned or not. All the spec says is: * A struct-type variable is considered definitely assigned if each of its instance variables is considered definitely assigned. And doesn't mention private members at all (of course one could argue therefore private members need assignment :) ). The current interpretation by csc is that private members need to be assigned, but it never looks at the private members of a struct in an external assembly - so it just doesn't see them. That leads to the difference in behavior between members in the same assembly and in another assembly. I've been told the C# team is going to look at this after Orcas and will need to investigate what the proper behavior is. But it doesn't seem to be clear to them whether they should require assignment for private members or not require assignment for private members. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Wednesday, October 17, 2007 6:58 PM To: Discussion of IronPython Subject: Re: [IronPython] Compilation error 2007/10/6, Dino Viehland : > BTW my simple repro is bogus - it contains no members and section 5.3 of the C# spec defines value types as being definitely assigned when all their members are assigned. The real issue seems to be when the value-type is defined in another assembly and all the members are private. Once those conditions are met csc then doesn't require the assignment. > > I'm still waiting for a response on that last bit. Gert Driesen from Mono project reported this as Feedback 304489 at Microsoft Connect. http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=304489 After 3 days, it was marked "Resolved (By Design)", without any explanation. I'm still curious. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From Noah.McCalment at mts.com Tue Oct 23 19:10:48 2007 From: Noah.McCalment at mts.com (McCalment, Noah) Date: Tue, 23 Oct 2007 12:10:48 -0500 Subject: [IronPython] [python] IronPython and C# asynchronous events In-Reply-To: <471E2856.30201@voidspace.org.uk> References: <471E2856.30201@voidspace.org.uk> Message-ID: Unless I'm missing something concerning the use of CallTarget0, this doesn't work either. Neither my class code nor my script code is anything terribly complicated, so if you can point out what I'm doing wrong in either case, I'd be more than happy to admit my mistake. Noah -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Tuesday, October 23, 2007 11:59 AM To: Discussion of IronPython Subject: Re: [IronPython] [python] IronPython and C# asynchronous events Hello Noah, We've had no problems with synchronous and asynchronous events from IronPython (possibly try using the CallTarget0 delegate?), which suggests something wrong with your code. Michael http://www.manning.com/foord McCalment, Noah wrote: > All, > > I've been having some trouble connecting IronPython to events in C#. > The issue is illustrated in the short test class and test script > attached to this email. Specifically, the problem is this: When an > external event is raised to this C# class, the event handler calls a > function which iterates through the list of subscribers. When these > subscribers are invoked synchronously, there is no issue; everything > works fine. However, if the subscribers are invoked asynchronously, > IronPython methods cannot be directly added to the subscriber list. An > ArgumentNullException exception is thrown inside the .Net runtime > library, somewhere in the bowels of the remoting subsystem. My > questions are these: 1) Is it possible to make asynchronous events "just > work", i.e. allow IronPython scripts to simply call += on an event > member in a C# class and have the subscriber fire whether it is > synchronous or asynchronous? 2) I have found a workaround that involves > using reflection to retrieve a MethodInfo object that gets passed to > Delegate.CreateDelegate(). However, this requires me to dynamically > compile a C# helper class to handle events, because I cannot find a way > to retrieve a MethodInfo for a stock IronPython method. Is this > possible, and if so, how? > > Thanks for your time, > Noah > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Wed Oct 24 00:12:53 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 23 Oct 2007 23:12:53 +0100 Subject: [IronPython] Experimental C Extensions from IronPython with Python.NET - code and article Message-ID: <471E71E5.6090309@voidspace.org.uk> Hello all, I've just posted the experimental code for accessing CPython extensions from IronPython. Blog entry: http://www.voidspace.org.uk/python/weblog/arch_d7_2007_10_20.shtml#e862 Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml Comments, bugfixes and improvements welcomed! Despite some serious limitations it works! I have already had matplotlib with numpy and Tkinter working from IronPython. All the best, Michael http://www.manning.com/foord From sanxiyn at gmail.com Wed Oct 24 04:54:39 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 24 Oct 2007 11:54:39 +0900 Subject: [IronPython] Experimental C Extensions from IronPython with Python.NET - code and article In-Reply-To: <471E71E5.6090309@voidspace.org.uk> References: <471E71E5.6090309@voidspace.org.uk> Message-ID: <5b0248170710231954k5c16ccc8kd906d7ee27fc0884@mail.gmail.com> 2007/10/24, Michael Foord : > I've just posted the experimental code for accessing CPython extensions > from IronPython. > > Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml > > Comments, bugfixes and improvements welcomed! * Strings from .NET come in as unicode on the CPython type An evil workaround is to define PyStringConvert as: def PyStringConvert(obj): # evil return PyString(obj).GetAttr('encode').Invoke() This could be improved on Python.NET side. Any idea? * Can't yet pass in keyword args to function calls. This is related to the previous item, because: >>> def f(a): pass >>> f(**{u'a': 1}) TypeError: f() keywords must be strings With the previous workaround in place, replace PythonObject.__call__ with: def __call__(self, *args, **kw): args = ConvertToPy(args) kw = ConvertToPy(kw) return ConvertToIpy(self.real.Invoke(args, kw)) This is more straightforward than creating PyObject[]. -- Seo Sanghyeon From davidjensen at usa.net Wed Oct 24 14:57:57 2007 From: davidjensen at usa.net (David Jensen) Date: Wed, 24 Oct 2007 08:57:57 -0400 Subject: [IronPython] dynamic languages and .net 1.0 Message-ID: <054LJXm567908S30.1193230677@cmsweb30.cms.usa.net> A small question. I assume .net support for dynamic languages, interpreters, reflection was not in .net 1.0. Microsoft started as a compiler company and I thought Bill Gates was strongly in favor of interpreted languages. I thought it was odd that Microsoft apparently did not supply interpreted languages in .net 1.0. Is this because "reflection?" was more difficult to implement or were interpreters a lower priority? From curt at hagenlocher.org Wed Oct 24 15:04:40 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 24 Oct 2007 06:04:40 -0700 Subject: [IronPython] dynamic languages and .net 1.0 In-Reply-To: <054LJXm567908S30.1193230677@cmsweb30.cms.usa.net> References: <054LJXm567908S30.1193230677@cmsweb30.cms.usa.net> Message-ID: On 10/24/07, David Jensen wrote: > > A small question. I assume .net support for dynamic languages, > interpreters, > reflection was not in .net 1.0. Microsoft started as a compiler company > and > I thought Bill Gates was strongly in favor of interpreted languages. I > thought > it was odd that Microsoft apparently did not supply interpreted languages > in > .net 1.0. Is this because "reflection?" was more difficult to implement or > were interpreters a lower priority? Reflection was fully baked in the initial release of .NET. Microsoft is pretty good at implementing what its customers are asking for, though obviously they can't achieve instant turnaround. Don't be misled by the current popularity of dynamic languages; when the CLR was being designed ten years ago, it's likely that none of Microsoft's customers was asking for them. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ygutfreund at draper.com Wed Oct 24 15:47:32 2007 From: ygutfreund at draper.com (Gutfreund, Yechezkal) Date: Wed, 24 Oct 2007 09:47:32 -0400 Subject: [IronPython] dynamic languages and .net 1.0 In-Reply-To: References: <054LJXm567908S30.1193230677@cmsweb30.cms.usa.net> Message-ID: <98B94F0758D7394CA057AE4898CBC85E0631DAAF@exchbk1.draper.com> 1. I asked for them back in the 1980s. But I am only one bleeding edge Ph.D. CS guy, so no one listens to me. 2. I am impressed with the current level of Visual Basic support (which, while not being as dynamic as Python, does have late binding). Is there a roadmap as to when and how deeply Python support in VS Studio will be. I.e. when will Python be as baked-into VS Studio & .NET framework as VB currently is? (or perhaps an easier way of asking & answering - what will still be missing when VSstudio 2008 and .NET 3.0 (or 3.5) is released). From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Wednesday, October 24, 2007 9:05 AM To: Discussion of IronPython Subject: Re: [IronPython] dynamic languages and .net 1.0 On 10/24/07, David Jensen wrote: A small question. I assume .net support for dynamic languages, interpreters, reflection was not in .net 1.0. Microsoft started as a compiler company and I thought Bill Gates was strongly in favor of interpreted languages. I thought it was odd that Microsoft apparently did not supply interpreted languages in .net 1.0. Is this because "reflection?" was more difficult to implement or were interpreters a lower priority? Reflection was fully baked in the initial release of .NET. Microsoft is pretty good at implementing what its customers are asking for, though obviously they can't achieve instant turnaround. Don't be misled by the current popularity of dynamic languages; when the CLR was being designed ten years ago, it's likely that none of Microsoft's customers was asking for them. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Wed Oct 24 18:38:55 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 24 Oct 2007 09:38:55 -0700 Subject: [IronPython] dynamic languages and .net 1.0 In-Reply-To: References: <054LJXm567908S30.1193230677@cmsweb30.cms.usa.net> Message-ID: <7AD436E4270DD54A94238001769C2227D851081B3B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> While reflection was there one thing that was missing is good dynamic code generation support. We got that in v2.0 in the form of DynamicMethods. That lets us spin up little snippets of code that are fully collectible by the GC so it really enables a lot of scenarios that were difficult or painful before (and interesting enough one impetus for that was SQL server - not exactly what you think of when you think dynamic languages :)). From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Wednesday, October 24, 2007 6:05 AM To: Discussion of IronPython Subject: Re: [IronPython] dynamic languages and .net 1.0 On 10/24/07, David Jensen > wrote: A small question. I assume .net support for dynamic languages, interpreters, reflection was not in .net 1.0. Microsoft started as a compiler company and I thought Bill Gates was strongly in favor of interpreted languages. I thought it was odd that Microsoft apparently did not supply interpreted languages in .net 1.0. Is this because "reflection?" was more difficult to implement or were interpreters a lower priority? Reflection was fully baked in the initial release of .NET. Microsoft is pretty good at implementing what its customers are asking for, though obviously they can't achieve instant turnaround. Don't be misled by the current popularity of dynamic languages; when the CLR was being designed ten years ago, it's likely that none of Microsoft's customers was asking for them. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From kf9150 at gmail.com Wed Oct 24 18:53:57 2007 From: kf9150 at gmail.com (Kelie) Date: Wed, 24 Oct 2007 06:53:57 -1000 Subject: [IronPython] list of python built-in modules that are NOT supported by IronPython available? In-Reply-To: <42b9a3ff0710240117l7e2760b4mec297eac0310d0a4@mail.gmail.com> References: <42b9a3ff0710240117l7e2760b4mec297eac0310d0a4@mail.gmail.com> Message-ID: <42b9a3ff0710240953x46a4d4e9s4db1b55d3e24e1f1@mail.gmail.com> Hello, Is there a list of python built-in modules that are NOT supported by IronPython? I just tried importing sqlite3 module and failed. Thanks, -- Kelie From dinov at exchange.microsoft.com Wed Oct 24 19:10:59 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 24 Oct 2007 10:10:59 -0700 Subject: [IronPython] list of python built-in modules that are NOT supported by IronPython available? In-Reply-To: <42b9a3ff0710240953x46a4d4e9s4db1b55d3e24e1f1@mail.gmail.com> References: <42b9a3ff0710240117l7e2760b4mec297eac0310d0a4@mail.gmail.com> <42b9a3ff0710240953x46a4d4e9s4db1b55d3e24e1f1@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227D851081B7B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> It's pretty easy to get the list: IronPython console: IronPython 2.0 (2.0.0.00) on .NET 2.0.50727.1408 Copyright (c) Microsoft Corporation. All rights reserved. >>> import sys >>> sys.builtin_module_names ('__builtin__', 'datetime', 'errno', 'math', 'md5', 're', 'collections', 'select', 'cStringIO', 'nt', 'socket', 'thread', 'binascii', 'time', 'struct', '_random ', 'exceptions', '_codecs', 'copy_reg', 'cPickle', 'gc', 'marshal', 'operator', '_sre', 'imp', 'itertools', 'sha', '_weakref', 'array', '_locale') >>> ^Z Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> ipylist = ('__builtin__', 'datetime', 'errno', 'math', 'md5', 're', 'collections', 'select', 'cStringIO', 'nt', 'socket', 'thread', 'binascii', 'time', 'str uct', '_random', 'exceptions', '_codecs', 'copy_reg', 'cPickle', 'gc', 'marshal', 'operator', '_sre', 'imp', 'itertools', 'sha', '_weakref', 'array', '_locale') >>> ipyset = set(ipylist) >>> cpyset = set(sys.builtin_module_names) >>> cpyset - ipyset set(['_bisect', '_codecs_hk', '_sha512', 'audioop', '_multibytecodec', 'parser', '_sha', '_winreg', '__main__', 'msvcrt', '_heapq', '_codecs_jp', 'mmap', '_subp rocess', '_sha256', '_codecs_tw', '_functools', 'zipimport', '_codecs_iso2022', 'xxsubtype', '_codecs_cn', '_lsprof', '_struct', '_types', 'sys', '_codecs_kr', '_ast', 'rgbimg', '_csv', 'signal', 'zlib', '_hotshot', '_md5', 'imageop', 'cmath', '_symtable', 'strop']) >>> But it unfortunately doesn't include extension modules. From my Py2.5 installation it comes with: bz2.pyd pyexpat.pyd select.pyd unicodedata.pyd winsound.pyd _bsddb.pyd _ctypes.pyd _ctypes_test.pyd _elementtree.pyd _hashlib.pyd _msi.pyd _socket.pyd _sqlite3.pyd _ssl.pyd _testcapi.pyd _tkinter.pyd And the only one of these that we currently implement is select. Note this is on ipy v2.0 but I believe currently v1.1 and v2.0 have the same set of built-in modules. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kelie Sent: Wednesday, October 24, 2007 9:54 AM To: users at lists.ironpython.com Subject: [IronPython] list of python built-in modules that are NOT supported by IronPython available? Hello, Is there a list of python built-in modules that are NOT supported by IronPython? I just tried importing sqlite3 module and failed. Thanks, -- Kelie _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Thu Oct 25 00:45:14 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 24 Oct 2007 23:45:14 +0100 Subject: [IronPython] [python] Experimental C Extensions from IronPython with Python.NET In-Reply-To: <471E71E5.6090309@voidspace.org.uk> References: <471E71E5.6090309@voidspace.org.uk> Message-ID: <471FCAFA.2080606@voidspace.org.uk> Hello all, I've uploaded the download code with a slightly improved version. Thanks to Seo it now supports passing keyword arguments to the hosted CPython functions/methods. http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml Thanks Michael http://www.manning.com/foord Michael Foord wrote: > Hello all, > > I've just posted the experimental code for accessing CPython extensions > from IronPython. > > Blog entry: > http://www.voidspace.org.uk/python/weblog/arch_d7_2007_10_20.shtml#e862 > Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml > > Comments, bugfixes and improvements welcomed! > > Despite some serious limitations it works! I have already had matplotlib > with numpy and Tkinter working from IronPython. > > All the best, > > Michael > http://www.manning.com/foord > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups "C Extensions for IronPython" group. > To post to this group, send email to c-extensions-for-ironpython at googlegroups.com > To unsubscribe from this group, send email to c-extensions-for-ironpython-unsubscribe at googlegroups.com > For more options, visit this group at http://groups.google.com/group/c-extensions-for-ironpython?hl=en > -~----------~----~----~----~------~----~------~--~--- > > From sanxiyn at gmail.com Thu Oct 25 06:22:22 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 25 Oct 2007 13:22:22 +0900 Subject: [IronPython] dynamic languages and .net 1.0 In-Reply-To: <7AD436E4270DD54A94238001769C2227D851081B3B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <054LJXm567908S30.1193230677@cmsweb30.cms.usa.net> <7AD436E4270DD54A94238001769C2227D851081B3B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <5b0248170710242122t6107a725s6c524934d723e5e3@mail.gmail.com> 2007/10/25, Dino Viehland : > While reflection was there one thing that was missing is good dynamic code > generation support. We got that in v2.0 in the form of DynamicMethods. > That lets us spin up little snippets of code that are fully collectible by > the GC so it really enables a lot of scenarios that were difficult or > painful before. To appreciate the importance of LCG(Lightweight Code Generation) in .NET 2.0, you may want to read this piece by a JRuby developer: Lessons learned from JRuby compiler work http://groups.google.com/group/jvm-languages/browse_thread/thread/dbc3a4a382868904 His first agenda is "We need lightweight method objects". His explanation gives an idea of "that were difficult or painful before". -- Seo Sanghyeon From sanxiyn at gmail.com Thu Oct 25 06:27:09 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 25 Oct 2007 13:27:09 +0900 Subject: [IronPython] list of python built-in modules that are NOT supported by IronPython available? In-Reply-To: <7AD436E4270DD54A94238001769C2227D851081B7B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <42b9a3ff0710240117l7e2760b4mec297eac0310d0a4@mail.gmail.com> <42b9a3ff0710240953x46a4d4e9s4db1b55d3e24e1f1@mail.gmail.com> <7AD436E4270DD54A94238001769C2227D851081B7B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <5b0248170710242127w4faeaf2dr30324149768bba62@mail.gmail.com> 2007/10/25, Dino Viehland : > And the only one of these that we currently implement is select. Note this is on ipy v2.0 but I believe currently v1.1 and v2.0 have the same set of built-in modules. They do, with the addition of array module in 2.0 Alpha 5. -- Seo Sanghyeon From dinov at exchange.microsoft.com Thu Oct 25 06:50:15 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 24 Oct 2007 21:50:15 -0700 Subject: [IronPython] list of python built-in modules that are NOT supported by IronPython available? In-Reply-To: <5b0248170710242127w4faeaf2dr30324149768bba62@mail.gmail.com> References: <42b9a3ff0710240117l7e2760b4mec297eac0310d0a4@mail.gmail.com> <42b9a3ff0710240953x46a4d4e9s4db1b55d3e24e1f1@mail.gmail.com> <7AD436E4270DD54A94238001769C2227D851081B7B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <5b0248170710242127w4faeaf2dr30324149768bba62@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227D88D78BD34@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Yeah, it took me a long time to port that to 2.0... And unfortunately there's also still one regression in it vs. v1.1 (from the std lib tests) - subtyping array.array, overriding __getitem__, and calling the base class when __slots__ is defined on the sub-type is broken. And that's true for all classes and virtual methods, not just array and __getitem__ (another reason for "alpha" 5 ;) ). Amazingly this is the only test that seems to hit this pattern. But other than that small issue it's finally there :). ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo [sanxiyn at gmail.com] Sent: Wednesday, October 24, 2007 9:27 PM To: Discussion of IronPython Subject: Re: [IronPython] list of python built-in modules that are NOT supported by IronPython available? 2007/10/25, Dino Viehland : > And the only one of these that we currently implement is select. Note this is on ipy v2.0 but I believe currently v1.1 and v2.0 have the same set of built-in modules. They do, with the addition of array module in 2.0 Alpha 5. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Sun Oct 28 04:09:53 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sun, 28 Oct 2007 12:09:53 +0900 Subject: [IronPython] Good example of with statement usage in IronPython/COM Message-ID: <5b0248170710272009o775ada5cuad0c58e5b91f8625@mail.gmail.com> I found this interesting blog post which has a good example of with statement (Python 2.5 feature) usage in IronPython/COM. http://d.hatena.ne.jp/akiramei/20071026/1193419839 It's written in Japanese, but the code speaks for itself. The last line would translate to something like "It's getting shorter, but nesting is a bit too deep..." -- Seo Sanghyeon From Shri.Borde at microsoft.com Sun Oct 28 06:41:23 2007 From: Shri.Borde at microsoft.com (Shri Borde) Date: Sat, 27 Oct 2007 22:41:23 -0700 Subject: [IronPython] Good example of with statement usage in IronPython/COM In-Reply-To: <5b0248170710272009o775ada5cuad0c58e5b91f8625@mail.gmail.com> References: <5b0248170710272009o775ada5cuad0c58e5b91f8625@mail.gmail.com> Message-ID: <50B69702CA6E6D4E849D30CD4989AB8EB64032C83B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> There was a leak in IronPython where we were keeping COM objects alive once the IPy code manipulated the COM object. The code in the blog seems to be dealing with this bug with the use of the auto method which calls Marshal.ReleaseComObject in the finally. The bug is fixed in the 2.0 tree and so it should be possible to shorten the code a lot and end up with just a few levels of nesting. Shri -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Saturday, October 27, 2007 8:10 PM To: Discussion of IronPython Subject: [IronPython] Good example of with statement usage in IronPython/COM I found this interesting blog post which has a good example of with statement (Python 2.5 feature) usage in IronPython/COM. http://d.hatena.ne.jp/akiramei/20071026/1193419839 It's written in Japanese, but the code speaks for itself. The last line would translate to something like "It's getting shorter, but nesting is a bit too deep..." -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Sun Oct 28 06:44:22 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sun, 28 Oct 2007 14:44:22 +0900 Subject: [IronPython] Good example of with statement usage in IronPython/COM In-Reply-To: <50B69702CA6E6D4E849D30CD4989AB8EB64032C83B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <5b0248170710272009o775ada5cuad0c58e5b91f8625@mail.gmail.com> <50B69702CA6E6D4E849D30CD4989AB8EB64032C83B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <5b0248170710272244n6f13decdn48b667503d806fc7@mail.gmail.com> 2007/10/28, Shri Borde : > There was a leak in IronPython where we were keeping COM objects alive once the IPy code manipulated the COM object. The code in the blog seems to be dealing with this bug with the use of the auto method which calls Marshal.ReleaseComObject in the finally. The bug is fixed in the 2.0 tree and so it should be possible to shorten the code a lot and end up with just a few levels of nesting. Oops, it was a bug then. -- Seo Sanghyeon From Shri.Borde at microsoft.com Sun Oct 28 06:50:18 2007 From: Shri.Borde at microsoft.com (Shri Borde) Date: Sat, 27 Oct 2007 22:50:18 -0700 Subject: [IronPython] Good example of with statement usage in IronPython/COM In-Reply-To: <5b0248170710272244n6f13decdn48b667503d806fc7@mail.gmail.com> References: <5b0248170710272009o775ada5cuad0c58e5b91f8625@mail.gmail.com> <50B69702CA6E6D4E849D30CD4989AB8EB64032C83B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <5b0248170710272244n6f13decdn48b667503d806fc7@mail.gmail.com> Message-ID: <50B69702CA6E6D4E849D30CD4989AB8EB64032C83C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Well, still a good use of "with" for an elegant workaround :) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Saturday, October 27, 2007 10:44 PM To: Discussion of IronPython Subject: Re: [IronPython] Good example of with statement usage in IronPython/COM 2007/10/28, Shri Borde : > There was a leak in IronPython where we were keeping COM objects alive once the IPy code manipulated the COM object. The code in the blog seems to be dealing with this bug with the use of the auto method which calls Marshal.ReleaseComObject in the finally. The bug is fixed in the 2.0 tree and so it should be possible to shorten the code a lot and end up with just a few levels of nesting. Oops, it was a bug then. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From evan at yelp.com Wed Oct 31 09:22:27 2007 From: evan at yelp.com (Evan Klitzke) Date: Wed, 31 Oct 2007 01:22:27 -0700 Subject: [IronPython] Linux Support Message-ID: Hi all, I've been looking at IronPython a bit lately as an alternative to CPython. I've had some difficulties, however, getting it working on Linux. I've just spent a few minutes trying to get it running under mono, and I haven't been that impressed. Among various problems: * Bad permissions in the .zip for 2.0a5 that make some files not writable (not sure if it's possible to get the permissions right in a zip archive, but still annoying) * Makefile for 2.0a5 doesn't work * Have to edit the Makefile for 1.1 to get it to work on Linux * ipy.exe wants the user to use Ctrl-Z to exit (rather than Ctrl-D), but this of course suspends the process on Linux Most of these are pretty trivial problems, and things that I would think ought to have simple fixes (e.g. write the Makefile to figure out what OS it's on, have ipy.exe use Unix conventions on Unix systems), which is why I'm somewhat surprised that a user trying to run IronPython runs into these problems. Then I had problems using modules in the standard library. This post indicates that I should be able to import most modules from CPython. So I set my IRONPYTHONPATH using Unix path convention and nothing works. Eventually I figure out that I need to use the Windows convention and use semicolons as the path separator (which is inconvenient because semicolons need to be escaped in bash). After I running ipy.exe hangs and I get an IOError (I think it tried to import too many After finally getting everything set up, I had problems getting nontrivial programs to actually run, because of lacking module support (in my case, MySQLdb, which uses the C API). The whole ordeal is really frustrating, and it makes me wonder -- what is the status for supporting Mono/Linux with IronPython? Is there anyone in charge of this right now? Does the IronPython team actually test IronPython on Mono? Are there plans to make running IronPython on Mono/Linux more sane in the future, or is the Linux support just incidental for now? Is anyone active in writing compatibility modules (such as MySQLdb) for commonly used modules that can't be dropped in as replacements? -- Evan Klitzke From fuzzyman at voidspace.org.uk Wed Oct 31 09:46:01 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 31 Oct 2007 08:46:01 +0000 Subject: [IronPython] Linux Support In-Reply-To: References: Message-ID: <472840C9.5040304@voidspace.org.uk> Evan Klitzke wrote: > Hi all, > > I've been looking at IronPython a bit lately as an alternative to > CPython. I've had some difficulties, however, getting it working on > Linux. I've just spent a few minutes trying to get it running under > mono, and I haven't been that impressed. Among various problems: > Hello Evan, Linux and Mono support is through the FePy project. http://fepy.sourceforge.net It addresses the build concerns you raise and provides some modules that don't come with the standard IronPython build. You can't use CPython extensions (the ones written in C anyway) with IronPython though, and should look for .NET equivalents. All the best, Michael http://www.manning.com/foord From PrinceOfDataMining at gmail.com Wed Oct 31 16:43:53 2007 From: PrinceOfDataMining at gmail.com (Samuel) Date: Wed, 31 Oct 2007 15:43:53 -0000 Subject: [IronPython] how to make idlelib work in ipy? Message-ID: <1193845433.022480.99400@v23g2000prn.googlegroups.com> or have other gui-ide for ipy? Thanks. From dinov at exchange.microsoft.com Wed Oct 31 17:11:02 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 31 Oct 2007 09:11:02 -0700 Subject: [IronPython] how to make idlelib work in ipy? In-Reply-To: <1193845433.022480.99400@v23g2000prn.googlegroups.com> References: <1193845433.022480.99400@v23g2000prn.googlegroups.com> Message-ID: <7AD436E4270DD54A94238001769C2227D88F6B2848@DF-GRTDANE-MSG.exchange.corp.microsoft.com> If you have VS Pro you can get the VS SDK sample which provides intellisence, project support, etc... in a rather experimental form. There's also SharpDevelop which as of earlier this month provides IronPython integration: http://community.sharpdevelop.net/blogs/mattward/archive/2007/10/21/IronPythonIntegrationInSharpDevelop22.aspx It looks like idlelib depends on at least Tkinter (which depends on the native extension module _tkinter) so we don't currently support idlelib. The experimental work being done by Michael Foord, Resolver, and others (http://groups.google.com/group/c-extensions-for-ironpython) might make this a possibility in the future. But I'm guessing they would welcome contributors :) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Samuel Sent: Wednesday, October 31, 2007 8:44 AM To: users at lists.ironpython.com Subject: [IronPython] how to make idlelib work in ipy? or have other gui-ide for ipy? Thanks. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dfugate at microsoft.com Wed Oct 31 17:40:29 2007 From: dfugate at microsoft.com (Dave Fugate) Date: Wed, 31 Oct 2007 09:40:29 -0700 Subject: [IronPython] how to make idlelib work in ipy? In-Reply-To: <7AD436E4270DD54A94238001769C2227D88F6B2848@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <1193845433.022480.99400@v23g2000prn.googlegroups.com> <7AD436E4270DD54A94238001769C2227D88F6B2848@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <7346A825E148B049A9AD1D3ED46A2D9116C1519A23@NA-EXMSG-C106.redmond.corp.microsoft.com> I believe the "Microsoft ASP.NET Futures" release (http://www.microsoft.com/downloads/details.aspx?FamilyID=A5189BCB-EF81-4C12-9733-E294D13A58E6&displaylang=en) also provides Python intellisence to Visual Studio 2005/2008. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, October 31, 2007 9:11 AM To: Discussion of IronPython Subject: Re: [IronPython] how to make idlelib work in ipy? If you have VS Pro you can get the VS SDK sample which provides intellisence, project support, etc... in a rather experimental form. There's also SharpDevelop which as of earlier this month provides IronPython integration: http://community.sharpdevelop.net/blogs/mattward/archive/2007/10/21/IronPythonIntegrationInSharpDevelop22.aspx It looks like idlelib depends on at least Tkinter (which depends on the native extension module _tkinter) so we don't currently support idlelib. The experimental work being done by Michael Foord, Resolver, and others (http://groups.google.com/group/c-extensions-for-ironpython) might make this a possibility in the future. But I'm guessing they would welcome contributors :) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Samuel Sent: Wednesday, October 31, 2007 8:44 AM To: users at lists.ironpython.com Subject: [IronPython] how to make idlelib work in ipy? or have other gui-ide for ipy? Thanks. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From michael.foord at resolversystems.com Wed Oct 31 18:25:50 2007 From: michael.foord at resolversystems.com (Michael Foord) Date: Wed, 31 Oct 2007 17:25:50 +0000 Subject: [IronPython] Import decimal failure with Turkish Locale (IP 1.1) Message-ID: <4728BA9E.8040107@resolversystems.com> Hello all, We've just had a user report an odd crash of Resolver. Importing the standard library module 'decimal.py' blows up, meaning that Resolver can't start. We've eventually tracked it down. His machine has a Turkish locale. The decimal module looks up global names by taking method names and looking for an uppercase version (around line 2171 of the Python 2.4 standard library module): rounding_functions = [name for name in Decimal.__dict__.keys() if name.startswith('_round_')] for name in rounding_functions: #name is like _round_half_even, goes to the global ROUND_HALF_EVEN value. globalname = name[1:].upper() val = globals()[globalname] Decimal._pick_rounding_function[val] = name The issue is because one of the method names is '_round_ceiling'. In the Turkish locale, the uppercase version of this is "ROUND_CE?L?NG" (in Turkish uppercase of "i" is "I" with a dot on top of it). Obviously the lookup of the corresponding global fails. In CPython the name is a byte-string, and so '.upper' just uses the ascii uppercase rather than the locale sensitive version - so we see failing to import 'decimal.py' as an IronPython bug. As this badly impacts Resolver we would *love* to see this fixed soon... Resolver is built on IronPython 1.1. Any word from you IP guys on how quickly you can turnaround a new release of the 1.1 branch that addresses this issue? All the best, Michael Foord http://www.manning.com/foord http://www.resolversystems.com/ From curt at hagenlocher.org Wed Oct 31 19:15:28 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 31 Oct 2007 11:15:28 -0700 Subject: [IronPython] Import decimal failure with Turkish Locale (IP 1.1) In-Reply-To: <4728BA9E.8040107@resolversystems.com> References: <4728BA9E.8040107@resolversystems.com> Message-ID: On 10/31/07, Michael Foord wrote: > > > The issue is because one of the method names is '_round_ceiling'. In the > Turkish locale, the uppercase version of this is "ROUND_CE?L?NG" (in > Turkish uppercase of "i" is "I" with a dot on top of it). Obviously the > lookup of the corresponding global fails. > > In CPython the name is a byte-string, and so '.upper' just uses the > ascii uppercase rather than the locale sensitive version - so we see > failing to import 'decimal.py' as an IronPython bug. As this badly > impacts Resolver we would *love* to see this fixed soon... Why not change decimal.py to use ToUpperInvariant()? Are you sharing the file with CPython? -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From giles.thomas at resolversystems.com Wed Oct 31 19:44:31 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Wed, 31 Oct 2007 18:44:31 +0000 Subject: [IronPython] Linux Support In-Reply-To: <472840C9.5040304@voidspace.org.uk> References: <472840C9.5040304@voidspace.org.uk> Message-ID: <4728CD0F.3090607@resolversystems.com> It's worth mentioning that there is a project to get CPython C extensions working under IronPython: The list is quiet at the moment, but work is going on... hopefully we'll have something more to report soon. Cheers, Giles Michael Foord wrote: > Evan Klitzke wrote: > >> Hi all, >> >> I've been looking at IronPython a bit lately as an alternative to >> CPython. I've had some difficulties, however, getting it working on >> Linux. I've just spent a few minutes trying to get it running under >> mono, and I haven't been that impressed. Among various problems: >> >> > > Hello Evan, > > Linux and Mono support is through the FePy project. > > http://fepy.sourceforge.net > > It addresses the build concerns you raise and provides some modules that > don't come with the standard IronPython build. > > You can't use CPython extensions (the ones written in C anyway) with > IronPython though, and should look for .NET equivalents. > > All the best, > > > Michael > http://www.manning.com/foord > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Wed Oct 31 23:16:55 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 31 Oct 2007 15:16:55 -0700 Subject: [IronPython] Import decimal failure with Turkish Locale (IP 1.1) In-Reply-To: References: <4728BA9E.8040107@resolversystems.com> Message-ID: <7AD436E4270DD54A94238001769C2227D8A90ECCEA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> This would have been my suggestion - this is a tough issue - do you have an expected behavior you'd like to see? I can imagine a few: 1. IronPython supports both byte-array strings and normal strings, and therefore "it just works" 2. IronPython never uses the current locale for string operations, effectively breaking Unicode 3. IronPython does a conversion into ASCII before doing attribute access, and somehow converts the upper case turkish I into an ASCII turkish I. Those 3 options are problematic at best. An easier solution would be what Curt suggested (I'm assuming you're redistributing the standard library yourself). I was also thinking that there should be a preexisting way to do this in Python but I don't see an upper function that lets you specify the locale or force it to do so against an invariance culture. Maybe just a call to string.translate instead? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Wednesday, October 31, 2007 11:15 AM To: Discussion of IronPython Subject: Re: [IronPython] Import decimal failure with Turkish Locale (IP 1.1) On 10/31/07, Michael Foord wrote: The issue is because one of the method names is '_round_ceiling'. In the Turkish locale, the uppercase version of this is "ROUND_CE?L?NG" (in Turkish uppercase of "i" is "I" with a dot on top of it). Obviously the lookup of the corresponding global fails. In CPython the name is a byte-string, and so '.upper' just uses the ascii uppercase rather than the locale sensitive version - so we see failing to import 'decimal.py' as an IronPython bug. As this badly impacts Resolver we would *love* to see this fixed soon... Why not change decimal.py to use ToUpperInvariant()? Are you sharing the file with CPython? -- Curt Hagenlocher curt at hagenlocher.org